△ 测试结果更容易跟踪

　　● 控制测试用例的操作时间

　　– 对于Matrix用例，一个好的测试用例的长度的衡量标准是是否能再20分钟内测试完毕

　　● 测试用例依赖关系的利弊

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

　　– 考虑是否真的需要其他的测试的结果作为数据输入，如果是，那么测试必需是累积的。应尽量避免这种情况

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

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

　　测试用例设计的五大误区

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

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

　　● 过分抬高测试用例设计标准，达到“使一个没有接触过系统的人员也能进行测试“的程度

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

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

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

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

　　测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行 性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，这就有回到测试用例的设计标准上了，还是那句话：根据实际情况选择适合自己团队的规范标准。

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

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

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

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