前面开了测试用例最佳实践这个话题，没想到反对声音很多。另外，所列部分条目，没有直观的例子，有些同僚不理解什么意思。决定再开个话题进行详细剖析说明。

关于 “最佳实践” 的说法

我的定义是能把工作做得更好的工作实践，同时也是一个目标。这些条目，我们可以根据实际情况做相应的取舍，没有强制必须全部做到。但是我们应当把它们作为一个目标，力求全部做到。

是束缚自己吗？

有些评论说这是吃力不讨好，我觉得恰恰相反。首先应该明确，这些不是规则，而是工作方法。采用这些方法，我们能把工作做得更好，直接来说就是更能保障质量，那么相应的，我们的绩效也会更好。反过来，如果不遵循这些实践，大概率我们也无法保证质量，也就没办法把本职工作做好，相应的绩效也会不好。

无论功能大小，必须写测试用例

关于这一条，大家反对最多。关于写不写，我只列出写测试用例的好处：

• 理清思路，避免遗漏。这是最大的好处和目的，因为用例可以让我们减少漏测。
• 跟踪测试进度。从用例的执行情况，可以大致估算测试进度。不然只能靠感觉评估。
• 回归测试时很有用。
• 问题定责。线上出现问题，从用例中可以判断是漏测还是用例没覆盖。
• 好的用例设计可以避免冗余测试，节省时间，提升测试效率。当然设计起来也挺难。
• 与同事协同的需要。如果有用例，那么与其他同事协同会更方便。
• 文档传承。用例是测试人员很重要的文档沉淀，不仅能体现自己的工作成果和专业性，而且对新人通过用例熟悉业务也是很有帮助的。

有人说自己不写用例，直接写代码。这种情况本质上是写了用例的，代码就是你的用例。
有人说自己时间不够，只用思维导图做了测试分析，列测试点。这种情况其实也是写了测试用例的，只是用例的质量差。
有人是时间不够，没法写。有两个办法，第一是自己想办法缩短写用例的时间，比如测试用例最佳实践中提到的第 5、6、7 点就是针对缩短写用例的时间的，第二是跟团队争取时间，我相信只要有质量意识的团队，不至于不会给这个时间，再不济我们也可以通过宣讲的方式跟团队逐渐传播相关的质量意识，相信团队会慢慢理解的。

测试用例必须得到严格和完整的执行

写用例只是第一步，我们的目的终究是揭露问题，如果没有严格地执行，那写了也等于 0。

除了一次性项目，测试用例需要持续维护

部分团队特别是采用敏捷的团队，项目迭代很快，并行项目很多，很难有精力去维护用例，特别是用例很多的情况下。但是仔细想一想，用例需要维护的场景，一般是回归测试，或者功能改变，不管是哪一种情况，只要我们是对着用例测试的，那么自然而然就会需要对用例做修改的。如果时间实在不够，我建议是记录下改动点，项目紧张时刻过后再找时间修改用例，也是可以接受的。

可以使用版本控制软件对测试用例进行版本控制

我目前能想到的是三种情形：
1、如果团队使用项目管理软件维护用例，那么一些项目管理软件是自带版本控制功能的。如果用例有修改，可以直接在原来的基础上新建一个版本，比如 PingCode：

2、有些团队有专门的服务器用于沉淀文档，一般会有配套的 SVN 等版本控制软件，那么可以用此类软件来进行管理。
3、如果没有专门的软件进行管理，也应该在用例文档中记录下每次改动的内容。以 Excel 文档为例，可以有以下内容记录用例的每次修改：

使用模板，模板必须简洁，尽量提供预选项，并且提供必要的统计功能。

使用模板可以使得我们能更快捷地编写测试用例。
模板必须简洁是指根据团队需要，尽量只包含必要的字段。
提供预选项是指可以提供预选项的字段，尽量提供，这样我们在编写用例的时候，直接通过选择的方式即可填写对应字段。比如以下用例模板，用例级别字段提供了预选项：

提供必要的统计功能，避免二次的人工统计。比如统计各个实际结果值的用例数、已实现自动化的用例数等等。

应该尽量设计通用的测试用例，避免过于细致的描述。

举一个简单的例子说明。比如现在要测试销售订单列表的搜索功能。
其中的一条用例，操作步骤可以这样写：
点击销售订单图标，进入销售订单列表，点击搜索框，输入订单编号，回车，观察结果是否正确。

上面这种写法就是没有通用性、描述过于细致的写法。

如果采用通用的、避免描述过于细致的写法，可以这样写：
进入单据列表，点击搜索框，输入单据编号，回车，观察结果是否正确。

使用这种写法，屏蔽具体的单据类型，对执行用例并无影响，但是用例具有通用性。比如下次你要测试采购订单列表的搜索功能的时候，这条用例是可以直接复制、不做修改就可以直接使用的。

除了这种情形，还有其他情形。比如跨平台的用例，做到 Android 和 IOS 平台可以使用同一条用例。

可以抽象出公共用例，变成可复用的用例模块

比如我们可以抽象出打印功能、上传图片等公共用例，在测试具体的单据的相关功能的时候，可以直接引用用例即可，这样就节省了很多时间。

维护快速迭代 checklist，应对紧急发布

与其盲目的测试，还不如维护一份 checklist。刚开始可以很简单，只覆盖主流程功能。后面可以慢慢加上一些典型问题，每遇到一个典型问题就加进去。