测试用例就是一个测试矩阵，任何人没有必要注重形式问题，如果你现在或者未来的公司有套非常完善的文档管理体系，那么你可以参考标准模版，如果没有可以试试这个格式： ID-ACT-DATA-EXPECTED-ACTUAL-T/F-DATE

ID -- 代表用例标号。

ACT -- 代表一种动作，手动执行或者自动执行，或者是一种异常状态都可以占用此位置。

DATA -- 代表数据，通常引用三种数据“正常”、“异常”、“错误”，分别对应关键字“PASS”、“ERROR”、“FAIL”。为什么会在一个文档中体现这些内容——主要是为了以后的测试自动化，一个不能将手动测试转为自动测试的人员注定是平庸的。

EXPECTED、ACTUAL -- 分别代表期望和实际，考察这两种值的差异是“正常”、“异常”、“错误”。

T/F -- 代表测试人员对这个测试的判断是否通过或者不通过。即使在ACTUAL与EXPECTED不同时，有时测试人员根据单项测试还是可以给个T，让市场或者高层去做决策。

DATE -- 代表测试人员测试并作出决定“PASS”、“ERROR”、“FAIL”的时间。

还应加上测试用例的设计者和对应的测试需求，将测试用例和测试用例执行的记录分开，便于日后工作的延伸。
保持测试用例简洁和朴实的风格。简洁不等于简单，真正简洁、朴实的测试用例是非常有效和实际的。
关于测试用例的数量，有的动态库中，测试用例就有3000多个，非常厉害。曾经有个500强的面试题中就有一个问题：你能为登录的动作写多少测试用例？实际上基本的就是三个：LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，其它的测试用例就是他们的衍生。因为包装的UI，封装的API，还有各种各样的MESSAGE，所以可能会出现很多种ERROR，也就可以写出很多测试用例。如果资源充分，测试用例的数量多一些对于检验产品的质量是有好处。但实际情况往往是资源有限的，必须挑选出最有价值的测试来执行。下面的基本原则可作为参考来保证测试用例的质量：

   1、接到任务不急于作而在于多思考，首先在纸上构造好业务流图。
   2、业务流程图构造好，快速挑选出公用的测试用例
   3、构造测试用例，先写符合主路径的三种“PASS”、“ERROR”、“FAIL”
   4、精化测试用例，努力为ERROR多构造1-7种假设
   5、执行测试用例，增加FAIL的标准化失败的测试，但是对应减少PASS测试用例

6。进一步精化测试用例，使“PASS”、“ERROR”、“FAIL”所占的比例分别为%20、%70、%10

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。