/catalog/2416e7f1c515497f98c8b7cb9874d41d//catalog/821d36aa8dfd499ca4af14ac5eb2b6b3//Document/282631823061061.html/Document/264572214259781.html/Document/264193141411909.html/Document/263120166727749.html/Document/262780577878085.html/Document/262434321498181.html/Document/261700928712773.html/Document/260317655674949.html/Document/259254117072965.html/Document/257842584657989.html/Document/257479171993669.html/Document/255707511132229.html/Document/255351757029445.html/Document/250725636485189.html/Document/249686534438981.html/Document/248257145659461.html

一个优秀的功能测试用例应该包含哪些内容?

一个好的功能测试测试用例需要包含:对一个特定的测试对象(test object)在规定的条件或环境下(前置条件和后置条件)输入一组输入数据或执行操作步骤后,生成一组相应的期望的结果。


测试用例=〈输入数据+,期望的结果+,测试对象,边界条件*〉


这些因素就组合成了一个测试用例。我们的测试用例分为逻辑测试用例和具体测试用例。逻辑测试用例没有具体的数据的描述,它是对测试数据的抽象描述。具体测试用例是对测试数据的具体化,具体的测试用例对于我们后续的回归有非常重要的作用。

功能测试

下表是定义一个测试用例所需的项:

功能测试

其实我个人认为,这里面还应该包含测试用例的设计方法,比如说我们这个测试用例是用等价类划分法设计的?还是边界值法设计的?如果加上这样一列的话,可以起到更加有效的说明作用。


这个也是看要求的,像比较大型的如金融行业,对用例要求比较精准的情况下,我们就要标注这个测试用例的设计方法。
为了方便追溯,测试用例还应该包含编写人是谁,执行人是谁。

如果测试用例的内容是一个可执行的序列,我们称之为测试套件(“手动测试脚本”)

下面是一个测试用例模板的举例,这是一个比较通用的测试用例的模版,包含编号、模块、功能、测试需求、正向还是反向用例、测试步骤、预期结果、实际结果、如果实际结果和预期结果不符,就是一个缺陷,我们后面还会讲,如何精准地把这个缺陷描述给开发人员。开发人员进行bug修复之后,我们就可以有一个再测试影响分析以及执行结果。最后为了可追溯性,会有一个编写人和执行人。