⭐️前言⭐️

入职以后接触到了公司的具体业务，提升了设计测试用例的能力，于是沉淀出这篇文档与大家分享。

🍉欢迎点赞 👍 收藏 ⭐留言评论 📝私信必回哟😁

🍉博主将持续更新学习记录收获，友友们有任何问题可以在评论区留言

🍉博客中涉及源码及博主日常练习代码均已上传GitHub

---

🍅测试用例的基本要素

测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
测试用例的出现主要解决了测什么和怎么测的问题；测试用例的好坏与产品测试质量有很大的关联关系。
是否能够设计出覆盖率广、优美的测试用例其实也是一名QA的能力体现，不仅要熟悉业务、了解系统，还应该多思考，不拘束于惯性思维，才能设计出富有艺术性的测试用例。

🍅如何写好测试用例

流程上

1、测试需求分析，确定测试点
在进行用例编写之前，一定要先进行需求分析，通过PRD和需求评审会议来去了解需求的整个背景实现+分析需求的合理性+明确需求的范围（增量还是存量、历史问题还是新问题）+挖掘PRD中隐藏的需求。在通过需求交底的过程中，通过沟通和对测试需求的分析，列出需求的框架，包括各个功能点、测试的场景等，确定一些测试可以提前介入的工作。

注意：对需求有问题一定要及时记录，并找PM沟通确认，并三方同步。

2、梳理测试逻辑，分析测试点优先级
测试用例整体是要有逻辑的，通过对测试点的分析来对case进行类别的划分，相同类别或者归属于统一操作流程的case放在一个FM下编写。
梳理好整体逻辑后还需要针对case来进行优先级的划分P0（准入用例）、P1（一般测试用例）、P2（较为细致但不影响整体的用例），通过优先级的划分来让用例的设计更有侧重点。

3、细化测试点变成可执行的case
列举出测试点后，通过详细但不繁琐、简洁且明确的话描述用例的操作步骤、预期结果、text，根据测试点，细化出具体的测试用例，要注意各个点的组合测试的情况（测试点之间的关联关系）

测试点需要细化到什么样的程度，控制好度，简洁明了、覆盖全面。

4、及时更新测试用例
在用例编写阶段，需求很可能是会有变动，通过同步变动以后，要及时更新测试用例，及时维护测试用例才能使得这个用例是一个有效的测试用例，否则很可能会成为一个错误的指导。
此外在用例评审阶段，注意检查用例是否有测试点遗漏，场景遗漏，测试case描述模糊（切忌直接copyPRD，要理解需求转化成自己的描述），预期结果描述模糊等问题，针对其他用例评审人提出的问题，要及时更正用例。

维度上

1、借助测试策略和测试方法
● 测试策略：比如功能测试、性能测试、界面测试、兼容性测试、易用性测试、安全性测试等方面。
● 测试方法：等价类、边界值、判定表、正交排列、场景设计、错误猜测等方法
2、注意测试点在流程中的体现
● 当前测试点受到哪些测试点的影响（依赖于哪些测试点）、其会影响到哪些测试点。
● 单元测试和集成测试
● 管理态和运行态
3、在时间维度上考虑
该测试点是否受时间先后影响（是新增需求还是历史问题）

测试用例需要描述清楚，因为测试用例不仅自己看，还有可能会让其他不同的角色看，还有可能在不同的时间点看。

🍅如何提升用例编写的能力

1、熟悉业务，了解系统
任何系统都有大的业务背景，只有熟悉了业务知识才能更有效的使用系统，任何系统在使用过程中，都有一个熟悉的过程，对系统越熟悉，越容易发现系统问题和业务问题。
2、多站在用户的角度来分析
多站在用户的角度来分析客户需要什么和客户想要什么，客户不想要什么，即了解客户的使用场景，这样有利于我们更好的挖掘测试需求，哪些是更为重点的，哪些是用户基本不会用到的场景。
3、发散思维
不要固化思维方式，多思考来发散思维，提升自己设计测试用例的能力。

---

⭐️最后的话⭐️
总结不易，希望uu们不要吝啬你们的👍哟(＾Ｕ＾)ノ~ＹＯ！！如有问题，欢迎评论区批评指正😁