如何编写测试用例【理论篇】_测试case怎么写

前言：这是纯理论部分，比较枯燥。有基础的同学可用跳过这一篇

一、【测试用例】概念

        测试用例也叫测试案例（test case）：在测试执行之前，由测试人员编写的用来指导测试过的重要文档。测试用例的常见核心组成：用例编号、用例标题、测试目的、测试步骤、预期结果、优先级等

二、黑盒测试用例设计时需要用到的方法（后续文章每一个方法都会详细说明）

• 等价类划分
• 边界值
• 判定表（决策表）
• 因果图
• 正交排列
• 测试大纲
• 场景法
• 错误推论

三、设计测试用例可以参考的资料

1. 需求相关文档：需求规格说明书、原型。——这些由产品经理提供
2. 技术相关文档：数据库设计说明、接口设计说明。——这些由程序员提供
3. UI交互文档：UI稿、交互设计稿。——这些由设计组提供
4. 其他： 
   1. 被测系统：在测试执行之前，由测试人员编写的用来指导测试过的重要文档。测试用例的常见核心组成：用例编号、用例标题、测试目的、测试步骤、预期结果等
   2. 与同事沟通：与测试人员、产品经理、开发人员、设计组、用户之间的沟通讨论获取隐藏需求，从而补充测试用例
   3. 竞品、网络资源：有时在项目资料不齐全的情况下（如：原型缺失、接口设计说明不齐全），测试人员需要发挥一切想象力去寻找类似的可用资源

四、用例设计思想

        1. 穷举测试思想（不可取）：将所有有可能的数据或情况都进行测试。

                优点：测试的全面

                缺陷：效率低，且不可能实现

        2. 理想测试思想（被大众认可）：用最少的测试数据，达到最佳的测试效果

                优点：测试效率高

                缺陷：毕竟没有测试全部的场景和数据，有遗漏bug的风险

                因此，在测试时间充足的情况下，尽可能的去补充测试，将遗漏bug的风险降到最低

五、测试用例的作用

1. 提高测试效率，避免穷举测试的窘境
2. 保证了测试覆盖率，测的全面
3. 在进行重复性测试时，可以重复使用测试用例，提高了用例的复用率，节约测试时间
4. 通过测试用例可以监督测试人员的工作、进度、保证测试质量
5. 为其他类型的测试工作（如：性能测试、自动化测试、开发自测等），提供参考用例

六、测试用例编写注意事项

1.  在编写测试用例之前，需要去了解公司对用例的要求：的用例标题格式、组成部分、附件命名格式、提交用例的工具、提交用例的时间，避免后续因为这些边边角角的问题去浪费时间修改用例
2. 用例一定要经过评审才能执行：小功能可以一对一评审，常规功能需要组织评审会。用例评审的目的最重要的目的是[检查用例的覆盖率]、[确认产品经理、程序员、测试人员的对需求理解保持一致]、[避免后续因为“这不是bug”扯皮甩锅]
3. 用例的格式只是建议，不是强制的：我们可以根据项目特性、项目组习惯、对开发的了解程度来调整测试用例编写的方式、用例的精细颗粒度。不一定非要按照格式一模一样的去编写，这样反而显得很死板，一条好的测试用例应当是可以指导测试工作的，而不是定死了测试工作步骤。
4. 不是每一步操作步骤，都需要对应一个预期结果：我们在设计操作步骤时，会写一个预期结果，但经常会遇到“这个步骤”只是一个用户动作，且系统不会给用户任何反馈的步骤，例如：

        

        步骤1和步骤2 在描述用户要如何输入内容，如果用户完成这些动作时，系统不会给出任何反馈，就不需要给出预期结果。如果强制要给步骤1和步骤2写预期结果，像下图这样，标红的部分就会显得很呆滞：

 

         因此，如果有些操作步骤，系统没有给出任何反馈的情况下，可以不强行编写对应的预期结果，即节约了编写用例的时间，和开发看用例的时间，又增强了用例的可读性，如下图：

七、常见的用例格式：

        1.使用表格编写测试用例

        2.使用思维导图编写测试用例

        3.使用工具编写测试用例（禅道为例）

 今天分享到这！想学测试，那么测试用例就是基础。各位加油！