软件测试 | 测试用例应该怎么写，常见的坑，不会测试用例的看过来......

---

前言

测试用例最基本的8个元素，分别是测试用例编号、功能模块名称、测试用例标题、重要级别、前置条件、输入数据、操作步骤以及预期结果。

当然，不同的公司的测试用例可能也有些不同，我们在实际操作中可以根据情况进行补充，例如增加测试人员、测试时间、备注等等信息。

为了保证测试用例的覆盖率，企业中编写测试用例也是有相应流程的。首先是需求分析，然后是提取测试点，再然后是测试用例设计，最后是测试用例评审。接下来我们通过案例来实现一下。

假如现在我们要针对以下这样一个类似计算器的产品进行测试，要求是主要测试计算器的加法功能，计算两个1-1000整数的和。

一、测试用例是什么？

测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行时一系列有次序的、受控制的状态变化过程。

二、设计用例是否有必要？

将测试内容记录下来，避免了在执行的时候部分测试点被遗漏，另外也便于用例评审，用例总结，对后期测试工作起到改进作用。

因此，测试用例必须要写，颗粒度可以视情况而定，针对测试人员少，上线时间紧的项目，可做思维导图载出测试点。

三、如何写测试点？

根据需求及设计交互稿，先列功能点，后扩展功能点为测试点（作为测试的标题），有必要的时候借助产品、开发、后端的力量，保证用例的覆盖度、学会借力。

测试点（注：这里不是测试用例，用例一般都比较详细，开发不一定会花费很多时间去做自测）写完后，可发给开发做自测，部分遗漏点可以在测试时进行记录与补充。

四、设计用例的益处？

设计用例的过程可以更深刻的理解需求，熟悉各功能点，保证尽可能全的覆盖到各测试点，也便于用例评审。

五、测试用例有哪些测试方法？

等价类划分法，边界值法，功能图法、错误推测法、因果图法、场景法。

六、如何保证用例的覆盖度？

首先一定要熟悉需求，需求分析，拆解非常重要，需要熟悉过程中，不理解或者有疑问的地方，一定要找产品进行及时沟通，确定结果。

其次项目开发过程中，每期的测试用例都要不短总结，学会总结，尽可能的保证少漏，其实这个与测试。

思维密切相关，工作经验的积累，以及测试思维的形成，都有助于你设计一份较完整的测试用例。

七、用例写完，我们先要做什么？

先自检，自检完毕，列出仍有疑问的点，评审之前，把用例提前发给相关的开发，产品，预留时间告诉他们先看，在统一时间进行评审。

八、哪些人应该参加用例评审？

产品。开发（客户端、后端、前端等，每个公司情况不一，可按实际来），测试需一起进行用例评审，评审力度需要加大，不能只是走个过场，需要有产出，否则有可能体会不出用例评审的作用。

如果开发不重视，可拉上研发总监一起评审，我之前评审过的用例，每次在评审时，产品不同岗位的人员，都能提出相关的一些用例中没有包含的问题，都需重新调整用例，最后在进行二次评审，在用例的评审过程中，针对大家提出的问题，可以简单的进行记录。

评审后再进行详细补充，第一次评审过的用例重新整理完成之后，再次通知相关的评审参与人，这样做的目的是告诉大家，我们做了什么事，做的结果如何，后续还有什么改进的地方，及时总结，目标明确，可带动大家积极参与。

九、用例评审有必要逐条念吗？

用例评审没有必要逐条念标题和预期结果，这样很浪费时间，比如，一个项目的用例整理之后都是上百条。

如果逐条念很耗费时间，建议可以根据条件总结性的过，大部分用例结果是已知的，步骤和预期结果是不用讲的，除非个别有疑惑的测试点，可以花费时间一起讨论沟通下（建议：使用思维导图进行用例的讲解，对某些特殊说明点可以参照用例进行）。

十、对于开发不自测的，我们该如何做？

建议加入提测环节，测试给出提测标准，没达标就打回，或者先给产品进行功能主流程验收（设计对UI进行验收），产品说通过验收了再给测试提测，要开发自测可自上而下进行推动，加入某个环节也需要技术总监的支持。

开发自测可以使测试人员轻松点，一些比较容易发现的问题可在进入测试人员测试阶段可避免，这样下来整体节约了时间，而测试也有更多的时间去测试复杂的逻辑问题，而不是只测需求功能问题。

同时，给研发一点压力，开发的功能模块质量也会有提高，多次提测不通过也可作为研发考核的一个标准。

十一、总结

漫漫长路，是什么让他们走向成功？悄然岁月，是什么让他们创造了奇迹？是坚持，坚持，再坚持！如果不是坚持，历史长河就掀不起他们的波澜，成功就泯灭于最初的放弃。

只有一条路不能选择——那就是放弃的路；只有一条路不能拒绝——那就是成长的路。

积极的人在每一次忧患中都看到一个机会，而消极的人则在每个机会都看到某种忧患。