测试用例管理规范(V1.0)

测试用例管理规范（V1.0）1 总则1.1 说明软件最终呈现在用户面前的质量，与测试执行的程度和力度密不可分。

测试用例设计的基本目的，是确定一组最有可能发现某个错误或者某类错误的一组测试数据。

测试用例不但构成了设计和制定测试过程的基础，而且测试的深度与测试用例的数量成正比。

判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这个又是以确定和执行的测试用例的数量为依据的。

如今，用户对手机软件质量要求日趋严苛，几乎对每一种现实中可能发生的操作都要求软件保证正确。

在这种情况下，完全覆盖测试和大量用例验证不可避免，而测试工作量又与用例数量成正比，因此，该如何兼顾测试工作量和效率，如何测试，用什么方式测试，在什么环境和什么条件下测试，如何避免重复测试，已成为测试人员必须考虑的问题。

本规范就是从以上列举的方面出发，通过对测试用例科学化的组织、归纳和管理，来指导测试行为，提高测试效率，保证软件质量。

1.2 测试用例意义1.2.1 对降低项目风险的意义。

在设计测试用例的过程中，测试人员可以根据自己的理解，对需求提出不同的看法，或者发现需求中某些功能描述得不够详细或者有歧义的地方，可提早发现问题，降低项目风险。

1.2.2 对测试与开发的意义。

测试用例的质量在一定程度上决定了测试工作的有效程度。

一个好的测试用例使得测试工作事半功倍，并且能尽早的发现一些隐藏的BUG，测试用例的设计是软件开发中的重中之重。

1.2.3 对测试过程的意义。

测试的目的是在有限的资源下，尽可能多的找出系统的缺陷。

这就要求在测试中，尽可能完全的走完系统的所有流程，保证所有的功能点都经过测试。

而测试过程是由人来执行的，不可避免的会遗漏一些应该测试的内容，这样就很容易出现测试不全面的问题。

再者，对手机软件开发而言，需求变更频繁，经常需要对同一个功能反复测试多遍。

很有可能第一轮测试得比较全面，当进行第二轮测试的时候，可能也会遗漏某些功能点。

为规避这种风险，通常引入测试用例来指导我们的测试行为。

当需求入基线后，测试人员开始介入项目，对需求进行分析，并设计出详细的测试用例，以对测试行为进行科学化的组织和归纳。

这样在测试执行时，只需按照设计好的过程去执行，就可避免由于人为原因而造成的测试不全面的问题。

2 适用范围本规范适用于软件测试组。

手机软件黑盒测试整个过程。

手机软件自动化测试、白盒测试部分过程。

测试用例建设整个周期。

3 测试用例编写规范3.1 测试用例编写格式及要求3.1.1 测试用例定义测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。

测试用例是执行的最小实体。

简单地说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果。

3.1.2 测试用例特征1）最有可能抓住错误的。

2）不是重复的、冗余的。

3）一组相似测试用例中最有效的。

4）既不是太简单，也不是太复杂。

3.1.3 测试用例必要元素及描述1）用例编号。

用来标识测试用例，编号是唯一的，由测试组根据具体情况统一管理，便于查找测试用例，以及测试用例的跟踪、更新、维护。

2）用例标题。

对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。

3）测试目的。

测试用例的编写目的，在于验证一个什么样的功能点。

4）预置条件。

执行测试用例必须的条件。

5）正确顺序及操作步骤。

提供测试执行过程的步骤。

对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

6）预期结果及判定原则。

提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。

如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

7）测试用例级别。

用来衡量测试用例的重要性，测试组根据具体情况制定统一标准。

关于测试用例的优先级别的设定：高 - 基本的功能中 - 错误的条件，界限用例（最大值，最小值...）低 - 极端的条件，边缘用例3.2 测试用例设计方法与技巧3.2.1测试用例设计原则1）测试用例的代表性。

能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等。

2）测试结果的可判定性。

即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

3）测试结果的可再现性。

即对同样的测试用例，系统的执行结果应当是相同的。

4）可操作性。

测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果。

3.2.2 测试用例设计方法3.2.2.1等价类划分等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不用考虑程序的内部结构，只依据程序的规格说明来设计测试用例。

所谓等价类划分是指一组被选择的值，这些值分别代表了众多可能的输入值，程序对其处理的方式都是一样的。

等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。

等价类的划分有两种不同的情况：有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。

无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。

在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。

3.2.2.2边界值分析在设计测试用例确定输入和输出参数时，大多数情况下都是用边界值分析方法，采用边界值分析设计的测试用例发现程序错误能力最强。

边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。

人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。

因此针对各种边界情况设计测试用例，可以查出更多的错误。

3.2.2.3错误推测法测试员也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。

这就是错误推测法。

错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

3.2.2.4因果图如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选用因果图法。

如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。

因果图方法最终生成的就是判定表。

它适合于检查程序输入条件的各种组合情况。

3.2.3 测试用例设计注意事项1）需要有一个具有自我解释功能的标题，将测试的目的说清楚。

（如，插入大小为10K的jpg图片至当前页。

）2）足够详细准确的内容，即使是一个对所要测试的内容根本不了解的新手，也能准确的按照所写的测试用例完成测试3）拒绝重复的测试用例4）不要有模糊的，个性化的和想当然的测试用例。

（如，插入各种大小的jpg图片至当前页。

）5）尽量提供一些于测试用例相关的参考6）做好测试用例自检（a）测试用例的标题是否体现了该用例详细而精确的目的性（b）测试用例对于一个新手来说是否能让他们精确的执行（c）测试用例是否有重复（d）测试用例中的步骤是否清晰，让人一看就能很明白的执行（e）定义的执行结果是否能让人很清楚的意识到执行完这个用例后是成功还是失败3.2.4测试用例评审3.2.4.1 测试用例评审意义测试用例设计完毕后，必须进行同行评审。

测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见评定设计的测试用例是否合格，是否需要更新测试用例。

如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。

因此，定期的对设计完成的测试用例进行评审，对提高测试效率是至关重要的。

3.2.4.2 测试用例评审内容测试用例在设计之后需要经过评审，需要评审的内容如下：1）用例是否完整？是否每一个需求都有其对应的测试用例来验证。

2）是否每一个设计元素都有其对应的测试用例来验证。

3）事件顺序，能否产生唯一的测试目标行为。

4）是否每个测试用例都阐述了预期结果。

5）是否每个测试用例、或每组相关的测试用例都确定了初始的测试目标状态和测试数据状态。

6）测试用例是否包含了所有单一的边界。

7）测试用例是否包含了所有的业务数据流。

8）是否所有的测试用例名称，ID都与测试工件命名约定一致。

9）测试用例评审时需要参加的人员：项目经理，系统分析员，测试设计员，测试员。

补充：目前测试组测试用例评审工作开展要求1）测试用例在评审时间上，占整个测试用例编写时间的40%以上。

2）各模块未评审的测试用例数量累计到100条时，必须进行评审。

3）测试用例评审内容见：3.2.3.2 测试用例评审内容。

4）测试用例评审人员为测试组全体人员。

5）评审进行方式：由测试组其他测试人员对模块负责人所编写的测试用例进行评审。

评审通过的测试用例将加入到测试用例中；评审未通过的测试用例，将被从测试用例库中删除。

4 测试用例执行规范4.1 定义用例执行顺序在测试用例执行过程中，定义测试用例的执行顺序，对测试的执行效率影响非常大。

比如某些测试用例的执行会消耗大量的时间，甚至需要多方外界条件的协助。

那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行。

如果在测试进度很紧张的情况下，优先执行这部分测试用例，不仅影响进度，耗费多方资源，还会严重影响测试人员的心情，进而导致匆忙地执行后面的测试用例。

这样测试用例的误测、漏测就不可避免，严重影响软件测试效率。

因此，合理定义测试用例的执行顺序是非常重要的。

4.2 明确记录测试过程测试执行过程中，必须有明确的测试过程记录。

如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定要在每个测试用例执行后，记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。

而不用测试人员重新搭建测试环境，为开发人员重现问题。

4.3 全面观察用例执行结果测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，对于较复杂的功能，即便实际测试结果与测试的预期结果一致，也要重复测试一到两次。

全方位观察软件产品的输出可以发现很多隐蔽的问题。

4.4 及时确认发现的问题测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。

如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。

如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，应配合开发人员记录重现问题的测试环境配置，交由开发人员继续定位问题。