测试用例编写指南总结初稿

manbuyunduanlg

这是我对测试用例编写的总结初稿，供大家参考，有什么写的不对的地方，欢迎批评指正。

如何以最少的人力、资源投入，在最短的时间内完成测试，发现系统的缺陷，保证系统的优良品质，是我们搜索和追求的目标。影响系统测试的因素很多，例如系统本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如测试队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响等等。 如何保障系统测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减小到最小。即便最初的测试用例考虑不周全，随着测试的进行和系统版本的更新，也将日趋完善。
因此测试用例的设计和编制是系统测试活动中最重要的。测试用例是测试工作的指导，是系统测试的必须遵守的准则，更是系统测试质量稳定的根本保障。
测试需求收集完毕后，就要开始设计测试用例了。测试用例是什么？测试用例就是一个文档，是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序或核实是否满足某个特定需求，以及该程序的某个特性是否正常工作。
要是最终用户对系统感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不通的方式并由不同的测试人员来实施。
使用测试用例的重要性主要原因有以下几个方面：
（1）在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率；
（2）测试用例的使用令测试的实施重点突出、目的明确；
（3）测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件，因此，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心；
（4）测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排；
（5）在系统版本更新后只需修正少部分的测试用例便可开展测试工作，降低工作强度、缩短项目周期。
以下章节对如何编制测试用例，直至用例发布做详细说明。
1.
测试用例在testlink上创建格式规则

（1）
首先由testlink管理员创建“测试产品”标识，一般按照产品名称来创建等；

（2）
第二，在“测试用例”标签页，创建根目录，点击新建测试套件，测试套件名称创建原则也是一般按照产品名称来创建；

（3）
创建根目录下一级测试子集：在根目录下创建一级测试子集，创建编号规则：Chapter1-*****、Chapter2-*****，具体子集创建规则参照本文档第二章测试用例架构规则；

（4）
创建二级测试子集：在一级测试子集目录下创建二级测试子集，创建编号规则：Chapter1-*****下二级测试子集创建编号规则[1-1]******，[1-2]******。。。，

Chapter2-*****下二级测试子集创建编号规则[2-1]******，[2-2]******。。。，

。。。。。。

（5）
第三级为单条测试用例，创建编号规则：统一文件夹下采用同一号段

[1-1]******下测试用例编号规则[1-1-1]******，[1-1-2]******。。。，

[1-2]******下测试用例编号规则[1-2-1]******，[1-2-2]******。。。，

。。。

[2-1]******下测试用例编号规则[2-1-1]******，[2-1-2]******。。。，

[2-2]******下测试用例编号规则[2-2-1]******，[2-2-2]******。。。，

。。。

测试用例的编号一个最基本的原则是应该具有唯一性，便于查找测试用例，也便于测试用例的跟踪，以及便于填写需求跟踪矩阵。另一个基本原则是更改、添加，以及后期补充测试用例时不能造成用例编号的紊乱。

如果因为项目实际需要创建三级测试子集的，那么第四级为单条测试用例，最好将测试用例控制在第三级。

2.
测试用例架构规则

测试用例的整体架构指的是一个项目确立后，从哪方面来设计整个系统的测试用例结构，测试用例架构设计对测试子集的划分很重要，划分的好，则可以提高测试执行效率，又可以使测试步骤清晰化，使测试人员准确快速的完成测试执行操作。

一般可以按照系统需求规格书的顺序、系统的各子系统来划分，如果系统需求规格书写的规范，有条理，采用这个顺序写就可以做需求矩阵时省时省力。另一个方法是按照系统的子系统来划分结构，一个系统不论大小都是由各个子系统集成而成，通过各个子系统为架构来设计测试用例，就可以使测试目标非常明确，测试效率大大提高，并且测试很有针对性，可以根据项目的具体需求来确定测试用例的整体架构，除此之外，对测试用例子集的划分还需要从发现测试用例中以下几个方面的共性来考虑：

（1）
测试前提条件有共性的测试用例；

（2）
采用的测试工具有共性的测试用例；

（3）
测试环境，组网限制方面有共性的测试用例；如测试DICOM Send，DICOM Print，MPPS等功能；

（4）
测试执行策略的原因有共性的测试用例；如有些测试用例需要修改某些参数，并需要再次加载的，或需要系统重启的，因为重新加载或系统重启花费时间比较长，为了提高效率，可以将其放在一起成为一个测试用例子集。

3.
测试用例设计规则

（1）
测试用例的全面性：

测试用例应尽可能代表并覆盖各种合理的和不合理的，合法的和非法的，边界的和越界的，以及极限的输入数据，操作和环境设置等；还应该考虑是否存在跨年、跨月的数据，以及大量数据并发测试；

（2）
测试用例的适用性

测试用例对于当前的测试环境和测试人员而言是可以执行的。如果测试用例是理论上可行的或者超过了测试人员的技能范围，该测试用例就是不适用的，即使有个别测试人员能够执行该测试用例，该测试用例也是不适合维护的；

（3）
测试用例的可重用性

测试用例的设计要求是可控的，它能够使任何人在任何时间进行测试都能获得同样的结果，也即对同样的测试用例，系统的执行结果应当是相同的，如果出现仅测试用例编写者能够进行测试并获得结果，或者不同的测试人员获得不同的结果的情况，该测试用例就应该被重新设计了。此种除了一种特殊情况：该缺陷的出现频率不是“总是”。

（4）
测试用例的可跟踪性

测试用例是针对特定的测试需求来设计的， 每条测试用例都应该有与之对应的系统需求，同样，系统需求规格书中的每条需求都要有用例与之对应。

目前采用系统需求跟踪矩阵来实现系统需求规格书中各需求的跟踪。在testlink中可以将系统需求规格书与相应的测试用例链接。

manbuyunduanlg

（5）       测试用例的纯净性

不会因为执行该测试用例而影响其他测试用例的执行，用例中应说明将应用系统恢复到最初状态，而不影响后续测试的进行。

具有依赖关系的测试用例是一些需要依靠先前的测试用例执行的结果来执行的用例，考虑是否真的需要其它的测试的结果作为数据的输入，如果是，那么测试必须是累积的，测试用例的执行序列早期发现的bug可能导致与之依赖的用例无法执行，应尽量避免这种情况。

保持测试用例依赖关系的正确性和一致性，以一种合理的顺序累安排测试用例的顺序。

（6）       测试用例的可判定性

根据测试用例测试，其测试执行结果的正确性是可判定的，每一个测试用例都应有相应的测试结果。测试结果（通过或失败）一定要明确，避免使用模糊字眼。比如左右、若、否则、大概、可能之类的词。

（7）       测试用例的正确性

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

（8）       测试用例的仿真性

测试用例的名、地名、电话号码、身高、体重等应具有模拟功能，符合一般的命名惯例。

（9）       测试用例的可操作性

测试用例中应写清测试的操作步骤，不同的操作步骤应对应相应的预期操作结果，尽量减少一条测试用例的步骤数，最好做到一个步骤一个预期结果。在step-by-step用例中一个比较好的长度是不多于15步，执行每个测试用例花费更少的时间，测试人员很少犯错误、丢失步骤或需要帮助，测试负责人能够准确的估计测试的时间，测试结果更容易跟踪等。

（10）   使用合理的语言

测试人员该做什么，系统输出什么应该写的很清楚明白，也就是说首先要分清楚测试用例的操作步骤和预期测试结果。

一种最好的避免含义混淆的方法是在操作步骤中采用动词+名词的结构，动词总是测试人员要做的事情，名词总是测试人员操作的对象、事物。将同一个事物命名为同一个名称，不管这个事物是否通过不同的方式出现，以免产生混乱。

（11）   使用克隆

模仿某个测试用例来写别的测试用例；

某些操作手册中的步骤，文字也可以被克隆；

保存以前写过的测试用例，以便以后进行克隆；

使用克隆测试用例时，不要忘了把原来的测试用例的编号改为新的测试用例的编号。

（12）   使用测试用例管理软件（目前使用testlink）

有编写测试用例更加方便；

很容易添加、修改、删除用例；

支持多用户同时编写；

跟踪测试用例设计过程以及测试用例执行过程；

需求与用例关联；

测试结果的统计；

使用克隆用例和步骤更加方便等

（13）   没有重复、冗余的测试用例

（14）   测试前提：就是执行当前测试用例的前提条件，如果不满足这些条件，则无法进行测试

（15）   测试标题：测试用例的标题是对测试用例的简单描述，用概括的语言描述该测试用例的测试点、每个测试用例的标题不能够重复，因为每个测试用例的测试点是不一样的，如果测试点相似，可以用序号标明、用例标题严忌模糊不清，一定要清楚表达出测试用例的用途。

（16）   测试步骤：就是执行当前测试所要经过的操作步骤，需要给出每一步操作的描述，测试人员可以根据测试用例的操作步骤，完成测试用例的执行。好的测试用例其测试步骤写的简单明了，不熟悉系统的人拿到测试用例也能操作，能够得到一样的预期结果；

（17）   预期结果：提供当前测试用例的预期输出结果，每一个测试步骤应该对应一个预期结果。用来与实际测试结果比较，如果相同则该测试用例通过，如果不同测该测试用例失败；

4.     执行测试用例

（1）       定义测试用例的执行顺序

在测试用例执行过程中，会发现某些测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响，或依赖某些共同的测试工具。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。

比如某些异常测试用例会导致系统频繁重新启动，系统的每次重新启动都会消耗大量的时间，导致之部分测试用例执行也消耗很多的时间。那么编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度亦然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测，误测就不可避免，严重影响了系统测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。

（2）       记录测试用例实测结果

实测结果：此项在测试执行时填写，指明该测试用例是否通过。需要测试数据的用例（带有误差允许范围等），无论是否通过，都要记下实测得值。非数据测试用例，如果不通过，需要列出实测输出内容。

（3）       加强测试过程记录

测试执行过程中，一定要加强测试过程记录，如果测试步骤/预期结果与测试用例中描述的有差异，而且能够确认是测试用例有问题，一定要记录下来，作为日后更新测试用例的依据。测试过程中发现了bug，除了记录实测结果外，如果系统提供了日志功能，一定在每个bug被发现时把测试用例执行时的相关日志文件记录下来，以便开发人员可以通过这些日志记录方便的定位问题，而不用测试人员重新搭建测试环境，为开发人员重现问题。

（4）       及时确认发现的问题

测试执行过程中，如果确认发现了系统的缺陷，那么可以毫不犹豫的提交bug至mantis，如果发现了可疑问题，又无法定位是否为系统缺陷，那么一定要保留现场，然后通知相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为系统缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重现问题的测试环境配置，然后回到自己的开发环境上重现问题，继续定位问题。

（5）       与开发人员良好的沟通

测试执行过程中，当你提交了bug报告单，可能被开发人员无情驳回，拒绝修改。这种情况经常发生，这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义系统缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。

（6）       及时更新测试用例

测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。
总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

archonwang

看了下，比较空，作为总则可以。但是未必能指导具体实施。