测试用例管理规范(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 及时确认发现的问题

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

4.5 保持与开发人员良好的沟通

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

5 测试用例更新及维护

随着项目的增加，用例库的数据随着项目的进展动态变化也是需要维护的，主要包括：不合适用例的修改、冗余用例的删除、测试用例的增加，并对进行的操作在备注中添加修改者以及修改时间和改动原因。

6 测试用例建设及总体规划

6.1 概要

从软件测试角度来看，手机软件测试属黑盒测试范畴，仍是建立在测试用例基础上的手工测试。因此，加强测试用例建设是很重要的。测试用例建设，一是在于积累覆盖手机各功能点的测试用例；二是在于形成良好的测试用例评审制度；三是在于建立一套科学的执行测试用例的方式，指导测试行为，提高测试效率；四是培养测试人员自觉更新维护测试用例的意识及测试经验。测试用例建设是一项长期的工作。提高测试用例质量、增加测试用例数量，以满足覆盖手机所有功能点的测试需求，是当前测试用例建设的首要任务。从时间上来说，我们需要至少半年的时间来进行测试用例各方面的积累。包括编写方法与技巧、评审制度、执行方式、管理与维护。从数量上来说，至少应完成8000至10000有效测试用例，才能覆盖手机基本功能点，满足多方面测试需求。

6.2 测试用例建设必要性

在测试执行过程中，因测试人员个人能力、经验的差异，导致对模块功能测试的全面性会有所不同。因此，测试执行前，准备大量有针对性地测试用例，来覆盖各模块的所有功能点，

以及弥补测试人员个人考虑问题的局限性是非常必要的。

6.3 测试用例建设目标

6.3.1 测试用例编写

编写了测试用例，并不意味着就可以做好测试工作。测试用例只是用来达到测试覆盖和进行测试经验积累的一种手段。因此，测试用例建设的目标之一，是通过对测试用例的编写，让测试人员加深对各模块相关知识的了解，提高测试能力，积累测试经验。

6.3.2 测试用例评审

缺乏评审，测试用例的有效性将大打折扣。既不能保证测试用例的质量，又会造成各方资源的浪费，增加测试人员工作量。因此，坚持定期的对编写的测试用例进行评审，对保证测试用例的质量具有至关重要的作用。

6.3.3 测试用例执行与维护

测试用例的编写过程和质量，并不是测试用例工作的全部，测试用例的执行、维护才是这项工作的重点。编写好的测试用例必须认真执行与维护，否则，将不会对实际的测试工作带来明显的效果，反而会造成测试工作量的增加和资源浪费。测试用例编写出来了，但它毕竟是一份文档，是死的，我们需要活用它。也就是说，测试用例还需要一个相配套的使用策略。比如，对某个软件版本的测试，根据实际的项目情况（如测试时限，人员及其水平，目标软件的品质等）对测试用例库进行筛选和打包，制定合适的测试方案。这样才能较好地实现测试用例的效果。因此，建立一套科学的测试用例执行方式，自觉的测试用例维护意识，是测试用例建设的重要目标。

6.4 测试用例建设实施过程

6.4.1 从不同测试需求覆盖手机功能点

测试用例应能满足手机功能性测试与非功能性测试的需求。测试用例必须覆盖手机各功能的所有功能点。

功能性测试包括：

1）常规测试。主要针对手机功能实现的正确性进行验证。从模拟用户体验的角度出发，设计测试场景，进行正确的操作，输入正常的参数，检验手机功能的正确性。

2）异常测试。主要针对手机功能实现的健壮性进行验证。设计异常操作场景，设计异常输入值等，检验手机功能在遭遇异常时的表现情况。

非功能性测试包括：

1）交叉测试。让手机保持在某一状态，在遇到意外事件干扰时，检验手机功能表现情况。2）兼容性测试。检验手机功能的兼容能力。比如对SIM卡的兼容性，对TF卡的兼容性，对不同网络，不同品牌手机的兼容性等等。

3）可靠性测试。主要针对手机相关功能使用成功率的测试。比如，拨号连接成功的概率，发送信息成功的概率等等。

4）极限测试。检验手机软件某些功能在一些极限条件下的表现。比如，在SIM卡容量将满时，在手机内存空间不足时，进行其他操作，如W AP上网，收发信息等手机软件的表现。

5）压力测试。在不断增加输入条件，以及输入参数值的情况下，观察软件相应功能的表现。

如，在关机状态下，连续的向测试机发送50条信息，观察手机在开机后接收信息时的表

现。

6）UI测试。按手机功能需求规格书要求，设计测试用例，检验手机功能操作流程，UI界面等是否符合功能规格书的要求。

7）性能测试。对手机整体功能的验证，主要是对手机软件反应速度，单个操作响应时间的测试。如，在存储大量短信的情况下，手机软件反应速度；或登陆W AP时的响应时间等。

6.4.2 分不同模块管理和维护

手机功能点庞杂，需运用大量的测试用例进行覆盖和验证。手机功能需求变更频繁，测试要求严格，需适时的对测试用例进行更新和维护，以满足实际测试需求。面对这种情况，应采用分模块管理和维护的策略，一方面可以分担测试用例更新和维护的工作量，同时也可以提高测试用例更新和维护的速度，保证测试用例的质量。

具体方式如下：

1）每位测试员负责二至三个模块的测试用例编写。

2）测试员间需常交换负责的模块，从不同角度完善模块用例。

3）坚持评审，清除无效用例。

4）适时添加多方面获取的有效用例。

5）定期管理和维护，保持用例库的稳定，健壮。保证各模块用例的完善，和有效性。

6）根据不同平台，不同项目的测试需求更新和调度测试用例。

6.5 测试用例建设注意事项

1）测试用例非常重要，但不要对测试用例期望过高，测试用例并非万能。成功的测试，应同步采用多种策略。

2）测试用例是一件要求非常细致的工作，应合理分配投入的资源，平均分担工作量。

3）加深对测试用例的理解，应坚持长期学习设计测试用例所需要的技术知识。测试用例的设计离不开技术（虽然在有些情况下可以不需要），否则，将导致测试用例的设计很片面，且过于主观，实际意义不大。

4）坚持严格评审。

5）定期按需更新。

6）科学组织，执行。