测试用例的编写-重在平衡

测试用例的编写是测试过程中的一个环节，位于在真正开始测试执行之前，在测试分析完成之后。

用例（case）主要有两个作用：一是提供可执行/可操作的用例执行方式说明；二是在测试执行过程中记录用例的通过情况及bug跟踪。

为满足上述目的，可见用例需满足以下几个要求：

1.可执行

可执行是用例最基本的要求。可执行包括要明确呈现给用例的执行人员要做什么样的数据/环境准备，操作步骤，操作过程中涉及到的标识符（如页面url，页面中的输入框和按钮，app中的操作栏和按钮等），环境初始化中的配置项和相应的值，数据存储介质（如mysql/hbase等）中需要进行初始化的数据。

根本目的在于，使有一定背景知识的操作人员，根据用例中的执行步骤，能够完整地执行整个操作过程，得出一个确定的结果。

所以，任何操作用例都是有受众的，受众即是具体执行测试用的测试执行人员。把受众假设为毫无背景知识的人，是最稳妥的方式，这样写出来的用例，按照step by step的方式，告诉用户如何进行用例的执行，尽可能全量地包含所有操作过程中可能遇到的问题点。这样的用例，集盒起来，其实也是一个技术性的操作手册。

但是，这样的用例编写是有代价的，更为细致的用例必然会消耗更多的用例编写精力，而且测试执行人员也并非零背景知识的参与人员。在如何尽可能详细表达测试需要执行的步骤和节约用例编写成本之间取得一个平衡。这也是用例编写人员的核心竞争力之一，即如何简约地描述测试执行。

2.结果明确

一个用例，只有在有明确的验证点的情况下，才能够判断用例执行是否通过。像“系统运行正常”，“输入数据友好”，“界面呈现正常”等类似的结果描述是不合格的用例结果描述方式，因为结果包含的含义太宽泛，以至于用例执行人员无法判定用例执行到底是否通过，如果后续还有用例自动化的。

合格的用例，对结果的描述应当是确定并且唯一的，如“数据库××表中××字段的值为×××”，“页面弹出提示信息××××”，“跳转到××页面，url为http://****”。

3.与功能点同步

用例是伴随一个产品的某个功能点而生，因而也有它自己的生命周期。用例要随着该部分功能点的调整而调整，随着功能下线而下线，保持产品的用例库同步和精简，防止用例库“年久失修”。这样的用例库一般就面临着“推倒重建”，而这种代价，实际上比实时维护用例库要高的多，因为重新写用例，意味着要重新再去熟悉和学习一遍当前系统的功能。用例本身可作为学习一个功能的入口，而非相反。

4.控制用例粒度

一个用例所涉及的功能点应当尽可能单一。你当然可以写一个用例测试“系统启动正常”，但是可能包含了1000个操作步骤和500个测试验证点，但是这样对用例执行人员和测试结果统计来说，就是灾难。一个用例测试了系统的全部功能，还会对用例的生命周期的维护产生很大的影响，可能别人鼓起用例去维护这个用例时，先要花半天的时间，找到更新的点在哪里。

先想到上述点，随着对用例的理解加深和思考，会更新本文，也欢迎补充。