文/秋之川
这是《落叶》文集里第 346 片落叶，希望你能喜欢，不为别的，只为这份坚持。
第二十一章 你真的会设计测试用例吗？
今天了解到大家的测试点都梳理好了，于是把大家喊到一起，讨论下设计测试用例的思路，也想了解一下大家的设计风格，确保最终的产物风格不会偏差太多。
会议开始的头一分钟，我问了大家一个问题：“你们真的会设计测试用例吗？”下一分钟，满屋子就都是等价类、边界值、场景法、因果图和判定表的声音了，大家纷纷阐述着自己所掌握的测试用例设计方法。
我敲了敲白板，吸引了一下大家注意力，然后问大家：
- 这些测试用例设计方法是在设计初期就要用的吗？
- 什么时候该用等价类设计？什么时候该用因果图设计？
- 使用这些方法是否能保证很高的测试用例覆盖率？
这几个问题让声音慢慢地小了下去，大家逐渐地进入了思考模式。我说，你们可以带着这些问题，会后好好想一想，我先说下我的观点：
我并不是反对大家使用这些方法，相反地，这些设计方法肯定会给测试用例的设计工作带来很大的帮助。但从实际做项目的角度出发，我并不认为，在一开始的时候，它们就会派上用场，在测试点刚刚梳理完成的时候，我们首先应该建立的是用户场景，或者说是业务场景，再基于实际的场景，去分析测试用例里对应的几个关键参数：
- 前置条件
- 输入数据
- 期望结果
得出这些关键参数之后，结合着你们所说的那些设计方法，再开始设计测试用例，会不会更好一些。
另外，我认为，测试用例设计的好不好，并不是看它用了多么专业的方法，而是要看它是否可以完全丢给另外一个不了解系统的人去执行，那个人只要按照测试用例里的前置条件、输入数据、步骤和期望结果，就可以独立完成测试。
同时，在开始设计具体的测试用例之前，也应该先根据产品的结构和特性，设计合理的测试用例框架，便于后期升级和扩展，尽可能地降低后期用例维护的成本。
《告诉你如何从执行测试到管理测试》带你迈出第（21）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
