在说怎么写测试用例之前呢，先来聊聊为什么要写测试用例。

理由有5点：

1. 理顺思路，避免漏测和重复测试

2. 帮助预估测试排期，把控进度

3. 方便bug回归验证

4. 便于发现、记录并复现问题

5. 标记测试结果，即对于测试结果有个交代

知道了写用例目的之后，你还需要知道，什么样的测试用例才是好的！

优秀测试用例的特征：

1. 包含基本信息，包括测试人/开发/产品/需求文档链接地址/技术文档链接地址，等等你测试过程中需要的物料。

2. 每一条用例，有很明显的突出测试预期和测试目的。

3. 所有用例都是可执行的。

4. 逻辑脉络清晰，几乎不存在重复的用例，简约而不简单。

5. 用例做到分级分层。

6. 待测功能点覆盖全面。

同时还是想要强调2个观点：

1. 不要纠结测试用例的格式或形式！

2. 测试用例并不是写得越细越好！

有了以上基础，接下来才能够讲明白如何去写好测试用例，不，确切的说是写好测试方案。

（为什么这里会提到测试方案呢？因为测试用例是测试方案的一部分，你不能仅仅只是会去写用例和执行用例，你还需要针对不同的测试场景去制定测试方案）

写测试用例（测试方案）的步骤

一、基础信息

摘自美团技术团队文章

这里再补充一点：测试排期/上线时间/Bug提交地址 等

所以，基础信息至少要包含：

1. 标题：【xxx】测试用例

2. 新功能简介（或者需求目的目标）

3. 参考资料

4. 干系人

5. 测试排期

6. 上线时间

7. Bug提交地址

如果项目有 业务流程图 或者 系统框架图，也可以po到测试方案里面去体现，方便熟悉业务目的或者上下游系统间的依赖。

二、测试方法

根据需求的不同，又可以分为多种测试手段（手段）

最主要的：

1. 功能测试

2. 单元测试

3. 性能测试

4. 稳定性测试

5. 兼容性测试

6. 安全测试

7. UAT测试

等等。

需要全部都写吗？

不需要！

根据测试项目的实际情况而定，比方说：你只是测试一个搜索框改了个默认提示文案，你就没必要去单独再去硬套模版测试性能了。

其实谈到写测试用例，大家更多的还是在写功能测试用例，所以这块重点讲。

功能测试用例，要做好分层设计（至少2层）：

第一层：冒烟测试用例

第二层：常规测试用例

冒烟测试用例，其实也可以当作是 提测准入测试用例 以及 验收回归测试用例

这部分用例相当于P0级的测试用例，主要是为了保证主流程是完全走通的，如果走不通，则测试有权利打回给开发，让开发把主流程跑通后，测试再继续往下进行。

摘自美团技术团队文章

常规测试用例

设计测试用例的时候，是有一些策略和方法可循的。

测试方法不必多言，掌握几种常用的黑盒测试方法即可：

1. 等价类

2. 边界值

3. 场景法

4. 判定法

5. 正交试验法

6. 因果图

7. 状态迁移图

其中用得最多的，恐怕就是 等价类、边界值、场景法 了。

测试策略就比较有讲究，需要大量的测试实践，才能形成一套自己的测试策略。

我总结了几条：

1、二八原则：重点抓主流程进行测试，不过分钻牛角尖。

• 80%的问题，集中在20%的模块里

• 80%的Bug，由20%的开发者写出（日久见人心，你懂）

2、要模拟真实的用户场景，不要YY出来一个永远都不可能发生的场景。

3、相互依赖的服务之间，最容易滋生Bug。

4、金字塔原理编写法，可以自上而下或者自下而上，杜绝重复用例。

三、数据构造

很多人不注重数据的重复利用，每次测试，都花费大量时间在构造数据上。

但是假如你在些测试方案时，就把数据构造和数据构造的方法写上去，

包括一些SQL、表格数据、json数据、账号密码等等测试数据

当下次还有相同的测试场景时，可以翻一翻之前的测试方案，就不用再花费太多精力在构造数据上了。

写测试用例的五大注意事项：

第一步、明确测试范围

有些需求是多个部门一起合作的，可能会有多个测试和你一起分工合作。

你需要明确自己主要负责测试哪些地方，细化到功能模块。

这个时候，你应该明确两点：

1. 你测试的模块到底依赖哪些其他模块

2. 有哪些模块依赖你所负责测试的模块

设计测试用例的时候，把重点放在设计你自己负责的测试范围上；

对于有依赖的模块，也需要考虑降级和容错，也就是你要考虑，你负责的模块出问题了，对人家造成什么影响；

或者，人家负责的模块出问题了，对你所负责的模块有什么影响。

明确测试范围的2个好方法：

1. 需求评审会一般产品会按功能模块去划分，分别评审，你需要和与你对接的产品和开发步调一致。

2. 测前沟通，找开发和产品去做测试前的沟通，必要时，甚至要找关联的测试人员去做一次沟通，明确测试范围。

第二步、熟悉需求文档

需求文档至少要看三遍！

在你熟悉需求文档的时候，也相当于已经进入测试了，像一些公司美其名曰：文档测试。

产品经理写需求没想到的，你想到了，都可以大胆的提出来，要有质疑的精神。

另外这里还有一个小建议：尽量让产品经理把产品的流程图画上，流程图可以反映出数据流向是怎样的，这可比文字更加直观。

这样你会对整个需求文档有更深的理解。

第三步、熟悉开发文档

开发的系统设计文档、接口设计文档、数据库表结构，如果有的话，最好都看一遍。

第四步、设计和编写测试用例

现在大部分测试工程师手工测试都喜欢用Excel或者Xmind来编写测试用例。

• Excel 比较适合用例较少、操作步骤简单、可能性有限、结果预期比较明确的功能。

• Xmind 比较适合用例较多、功能相对复杂、结果预期比较多样的功能。

以下分别举两个使用场景：

（1）假如说测app的话，个人感觉用Xmind可能会更合适，

用Excel的话，由于功能比较繁琐，可能用例条数会很庞大，一方面测试起来，看太多表格，容易头晕。另一方面维护起来也比较麻烦。

而Xmind可以只是把功能点写上，本身结构化的设计思维会让测试思路比较清晰，测试用例维护起来比较方便。

（2）对于上线后的回归测试验证点（CheckList），我们可以用Excel去表达，主要是针对主流程主功能的正向操作进行验证，逐条操作也防止漏测。

但其实用哪种软件编辑测试用例，都是看个人的使用习惯，关键是自己能看懂，别人也可以看懂就可以了。

设计测试用例时的，需要结合需求文档，把测试点罗列清楚，尽量用简洁的语句表述，非常忌讳写出过于啰嗦的用例。

另外，设计测试用例的几条思路我也简单介绍一下：

1. 按模块把功能点罗列全，切记不要照抄需求文档，这样写不写有什么区别？

2. 软件测试的基本测试方法要有效利用上，像边界值法、等价划分类、场景法等等，都是特别实用测试方法。

3. 不要在细枝末节上纠结太多，根据二八法则，80%的bug都集中在主流程里面，要确保主功能主流程没问题。

第五、用例评审

测试用例设计完，一定要和产品研发一起评审测试用例，漏掉的测试点要及时补充。

作者：程序员臻叔

原文链接：https://www.zhihu.com/question/393584042/answer/1490343045