测试规程与用例设计

测试规程/用例设计

测试规程（test procedure）是一个提供详细的测试用例执行指令的文档。测试规程应该更注重测试的流程、方法等比较泛的内容，以方便我们对测试用列的编写有一个整体的概念和把握。不同的公司规范、要求和详尽程度可能不同。

测试用例（test case）对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

测试规程与测试用例的区别：理想化的测试用例确实需要很多测试数据集合，但是现实中对某一软件进行测试时，由于涉及的面太广，无法一一列举出所有数据，所以要根据公司的规范来做相应的调整。所以，测试规程的文档编辑量较轻，但是只适合熟练的测试人员执行，而测试用例的执行者可以使任何人。

测试用例的设计：

测试用例可以分为基本事件、备选事件和异常事件。

设计基本事件的用例：参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

设计备选事件和异常事件的用例：采用的基本方法仍然是等价类划分、边界值、因果图等，根据软件的不同性质和测试的不同目标灵活运用，至于最终设计的测试用例是否能暴露更多的隐藏缺陷，全凭用例设计人员的丰富经验和精心设计了。例如，测试一个手机终端的电话本模块。测试人员需要考虑，将相同的号码A存储到不同联系人名B和C 中，号码A呼入和呼出时，显示的联系人名应该是B还是C呢。类似这样的备选事件，往往在需求阶段描述的并不详尽，需要测试人员及早提出并与项目组达成一致。

测试用例在软件测试中的作用：

指导测试的实施

规划测试数据的准备

编写测试脚本的"设计规格说明书"

评估测试结果的度量基准

分析缺陷的标准

此阶段的难点和重点：

测试用例设计的几大基本点

使用合理的语言

测试人员该做什么，系统输出什么应该写得很清楚明白，也就是说首先要分清楚测试用例的输入和预期输出

一种最好的避免含义混淆的方法是在操作步骤中采用动词+名词的结构，动词总是测试

人员要做得事情，名词总是测试人员操作的对象、事物

将同一个事物命名为同一个名称，不管这个事物是否通过不同的方式出现测试用例的易测性

简洁性：简洁性的衡量方法就是执行测试花费时间的长短以及在测试过程中是否能保持

整个测试的纯净

正确性：正确性意味着测试人员根据测试用例进行的测试获得的测试结果（通过或不通过）是正确的

控制测试用例的长度

在Step-by-step用例中一个比较好的长度是不多于15步：

执行每个测试用例花费更少的时间

测试人员很少犯错误、丢失步骤或需要帮助

测试经理能够准确地估计测试的时间

测试结果更容易跟踪

控制测试用例的操作时间

对于Matrix用例，一个好的测试用例的长度的衡量标准是是否能在20分钟内测试完毕测试用例依赖关系的利弊

具有依赖关系的测试用例是一些需要依靠先前的测试用例执行的结果来执行的用例

考虑是否真的需要其他的测试的结果作为数据输入，如果是，那么测试必需是累积的。

应尽量避免这种情况

保持测试用例依赖关系的正确性和一致性

以一种合理的顺序来安排测试用例的顺序

测试用例设计的五大误区

过分追求“能发现到目前为止没有发现的缺陷的用例是好的用例”

实际测试中，很多人一心想要设计出发现“难于发现的缺陷”而陷入盲区，忘记了测试的真实目的所在。测试只需要保证两点就能达到测试目的：1）、程序做了它应该做的事情；2）、程序没有做它不该做的事情。在做好这两点基础上，才谈得上改进测试用例，使其“发现没有的缺陷“。

过分抬高测试用例设计标准，达到“使一个没有接触过系统的人员也能进行测试“的程度不知道有没有公司真正做到这点，能够将每个测试用例都写得如此详细。之前看了微软关于一个工具的GUI测试用例，它分了几部分，第一部分是一些启动/进入模块的case，感觉确实很详细，基本达到能认识英文就能操作的层次。然后在后期关于具体功能测试时，依然出现前置条件（测试环境）不充分的问题，比如在某一部分的Case中，测试环境中要求将文件A先拷贝到指定目录下，然后再进行Test Step。在这部分的第一个Case中有关测试环境环境的搭建，但是后面几个Case就没有了（如果只做后面几个Case的话，按照Step来操作直接就Fail 了）…微软尚且如此，偶相信其他公司也不会高明到哪里去。

测试的目的是尽可能发现程序中存在的缺陷。每个公司实际情况不同，每个项目的实际情况也不同，所以需要因地制宜，根据实际情况制定测试用例的设计标准。如果项目周期短，工作量大，甚至可以考虑使用测试规程来代替测试用例指导实际的测试执行。

测试用例没有包含实际的数据

先看一个例子，某测试人员需要检查编辑框内是否不允许输入英文，他设计的测试步骤为“输入任意英文字符”。大家觉得是否很熟悉？

测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中

包含输入数据会带来维护、与测试环境同步之类的问题，这就有回到测试用例的设计标准上了，还是那句话：根据实际情况选择适合自己团队的规范标准。

需求/设计变更，而测试用例确没有修改

看似明显的错误，却是在在执行阶段经常出现的老毛病。往往在软件需求和设计已经变更了多次，测试人员觉得这些问题自己知道就行，测试用例没有任何修改。结果导致新加入的测试人员在执行测试用例不知所措，也使测试用例间接变成一堆废纸。

测试用例中预期输出过于简单

很多测试用例中，“预期输出”仅简单描述为应用程序的直观反映，其实，“预期输出”还需要更深一层的描述。例如，对一个存储系统，输入存储数据，点击确定，预期输出为“系统提示成功”。这样的用例完整吗呢？系统提示成功就表示数据成功存储了？显然，还需要去相应界面查看数据是否更新。