测试用例编写指南v210120.docx

测试用例编写指南v210120.docx

《测试用例编写指南v210120.docx》由会员分享，可在线阅读，更多相关《测试用例编写指南v210120.docx（77页珍藏版）》请在冰豆网上搜索。

测试用例编写指南v210120

文件类别：

指南

文件版本：

2.1

文件编号：

LC_CMMI4_GTC

哈尔滨乐辰科技有限责任公司

测试用例编写指南

受控状态：

__受控______

文档密级：

普通

文档状态：

[]草案[√]正式发布[]正在修订

变更履历

序号

版本

变更描述

修订人/日期

审核/日期

批准/日期

1

1.0

创建

Grace/2007-4-25

2

1.0

发布/增加页眉页脚

Grace/2007-4-30

EPG/2007-5-16

JasonXue/2007-5-16

3

2.0

重新梳理

Sally/2008-12-17

4

2.1

评审后修改

Sally/2009-01-20

Blue/2009-1-21

JasonXue/2009-4-20

5

6

7

8

9

10

目录

第1章前言4

1.1目的及使用范围4

1.2专业术语4

第2章用例设计的一般原则6

第3章测试用例设计步骤7

第4章单元测试用例设计10

4.1单元测试的概述10

4.2单元测试常用方法11

4.3设计单元测试用例12

第5章集成测试用例设计13

5.1集成测试方法13

5.1.1一次性组装方式（BIGBANG）13

5.1.2增殖式组装方式（IncrementalIntegration）14

5.2集成测试的实施16

5.3集成测试完成标准17

5.4集成测试常用方案选择17

5.4.1自底向上集成测试17

5.4.2核心系统先行集成测试18

5.4.3高频集成测试19

5.5设计测试用例样例20

第6章黑盒测试用例设计技术23

6.1等价类划分23

6.2边界值分析25

6.3因果图分析25

6.4状态转换测试33

6.5正交试验法40

6.6错误猜测53

第7章白盒测试用例设计技术53

7.1逻辑覆盖方法55

7.2基本路径测试法59

7.3循环测试64

7.4软件设计说明导出的测试用例65

7.5代码检查法65

7.6静态结构分析法67

7.7静态质量度量法68

第8章测试用例设计68

第9章相关文件69

第1章

前言

1.1目的及使用范围

指导读者编写有效的测试用例。

提供详细的按照开发阶段来划分的各阶段测试用例的编写指导及样例，提高测试用例的编写质量。

本文档结合《验证过程文件》使用，适用于公司内部所有项目/产品。

可根据项目实际情况选择使用合适的测试用例方法。

1.2专业术语

单元测试（UnitTest）

单元测试又称模块测试，是针对软件设计的最小单位（程序的模块）——进行正确性检验的测试工作，其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计的约束等要求，发现各模块内部可能存在的各种错误。

它所测试的内容包括单元的内部结构（如逻辑和数据流）以及单元的功能和可观测的行为。

单元测试需要从程序的内部结构出发设计测试用列，多个模块可以平等地独立进行单元测试。

使用白盒测试方法测试单元的内部结构，使用黑盒测试方法测试单元的功能和可观测的行为。

进行单元测试主要采用编码员之间交叉测试，因为通常编码人员比较容易发现其他人员编写代码中的缺陷，所以必须采用交叉测试。

集成测试：

也叫组装测试或联合测试。

在单元测试的基础上，将所有模块按照设计要求，如根据结构图，组装成为子系统或系统，进行集成测试。

集成测试是检验程序单元或部件的接口关系，逐步集成为符合系统设计要求的程序部件或整个系统。

实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。

程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。

确认测试：

确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。

确认测试是检测与证实软件是否满足软件需求说明书所规定的要求。

系统测试：

系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。

系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。

验收测试：

验收测试按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。

黑盒测试（Black-BoxTesting）

黑盒测试是基于系统需求规格，在不知道系统或组件的内部结构的情况下进行的测试。

通常又将黑盒测试叫做：

基于规格的测试（Specification-BasedTesting）、输入输出测试（Input/OutputTesting）、功能测试（FunctionalTesting）。

白盒测试（White-BoxTesting）

白盒测试是基于被测对象的结构，按照程序内部的逻辑结构和编码结构设计测试数据，白盒测试是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。

使用这种测试方法，测试人员可以看到被测程序的内部结构，并根据程序的内部结构设计测试数据，使程序中的每个语句、每个条件分支、每个控制路径都在程序测试中受到检验。

因此，白盒测试又叫结构测试。

灰盒测试：

介于白盒测试和墨盒测试之间的测试，灰盒测试关注输出对输入的正确性；同时也关注内部表现，但是这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。

灰盒测试结合的白盒测试和墨盒测试的要素，它考虑了用户端、特定的系统知识和操作环境，它在系统组件协同性环境中评价应用软件的设计。

软件测试方法和技术的分类与开发过程相关联，它贯穿了整个软件生命周期。

走查、单元测试、集成测试、系统测试用于整个开发过程的不同阶段。

开发文档和源程序可以应用单元测试或应用评审走查的方法；单元测试可应用白盒测试的方法；集成测试应用近似灰盒测试的方法；而系统测试和确认测试应用黑盒测试方法。

测试用例：

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

所谓测试用例设计就是将软件测试的行为活动，作为一个科学化的组织归纳，设计软件测试用例的目的，是为了能将软件测试的行为转换为可管理的模式。

第2章用例设计的一般原则

1、测试用例的代表性：

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

2、测试结果的可判定性：

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

3、测试结果的可再现性：

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

4、一个测试用例一个功能点：

每个测试用例都要有个测点，找准一个测点则可，不能同时覆盖很多功能点，否则执行起来牵连太大，

5、测试用例的易读：

从执行者的角度去写测试用例，最好不要有太多的术语在里面，如果要有最好指明具体位置；

6、测试用例的执行粒度：

粒度越小越好；

7、步骤清晰：

一个测试用例多个步骤，可一个重点，步骤指明人们怎么去操作，expect则指明这样操作之后应该看到什么结果---最好不要用正确，正常，错误之类的含糊主观的字眼。

8、总体设计：

先正常，后异常，这样可以确保正常情况下功能能够走通。

第3章测试用例设计步骤

设计测试用例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。

测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。

测试用例设计一般从以下两方面入手

1、测试需求分析

从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。

测试需求的特点是：

包含软件需求，具有可测试性。

测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。

测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。

2、业务流程分析

软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。

为了不遗漏测试点，需要清楚的了解软件产品的业务流程。

建议在做复杂的测试用例设计前，先画出软件的业务流程。

如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。

如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。

业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。

从业务流程上，应得到以下信息：

A.主流程是什么

B.条件备选流程是什么

C.数据流向是什么

D.关键的判断条件是什么

测试用例设计一般包括以下几个步骤：

步骤1：

首先使被测单元运行

任何单元测试说明的第一个测试用例应该是以一种可能的简单方法执行被测单元。

看到被测单元第一个测试用例的运行成功可用增强人的自信心。

如果不能正确执行，最好选择一个尽可能简单的输入对被测单元进行测试/调试。

这个阶段适合的技术有：

A.模块设计导出的测试

B.对等区间划分

步骤2：

正确性测试（PositiveTesting）

正确性测试的测试用例用于验证被测单元能够执行应该完成的工作。

测试设计者应该查阅相关的设计说明；每个测试用例应该测试模块设计说明中一项或多项陈述。

如果涉及多个设计说明，最好使测试用例的序列对应一个模块单元的主设计说明。

适合的技术：

A.设计说明导出的测试

B.对等区间划分

C.状态转换测试

步骤3：

破坏性测试（NegativeTesting）

破坏性测试用于验证软件不执行其不应该完成的工作。

这一步骤主要依赖于错误猜测，需要依靠测试设计者的经验判断可能出现问题的位置。

适合的技术有：

A.错误猜测

B.边界值分析

C.内部边界值测试

D.状态转换测试

步骤4：

设计需求中其它测试特性用例设计

如果需要，应该针对性能、余量、安全需要、保密需求等设计测试用例。

在有安全保密需求的情况下，重视安全保密分析和验证是方便的。

针对安全保密问题的测试用例应该在测试说明中进行标注。

同时应该加入更多的测试用例测试所有的保密和安全冒险问题。

适合的技术：

设计说明导出的测试

步骤5：

覆盖率测试用例设计

应该或已有测试用例所达到的代码覆盖率。

应该增加更多的测试用例到单元测试说明中以达到特定测试的覆盖率目标。

一旦覆盖测试设计好，就可以构造测试过程和执行测试。

覆盖率测试一般要求语句覆盖率（100%）、分支覆盖率（100%）等。

适合的技术：

A.分支测试

B.条件测试

C.数据定义－使用测试

D.状态转换测试

步骤6：

测试执行

使用上述5个步骤设计的测试说明在大多数情况下可以实现一个比较完整的单元测试。

到这一步，就可以使用测试说明构造实际的测试过程和用于执行测试的测试过程。

该测试过程可能是特定测试工具的一个测试脚本。

测试过程的执行可以查出模块单元的错误，然后进行修复和重新测试。

在测试过程中的动态分析可以产生代码覆盖率测量值，以指示覆盖目标已经达到。

因此需要在测试设计说明中需要增加一个完善代码覆盖率的步骤。

步骤7：

完善代码覆盖

由于模块单元的设计文档规范不一，测试设计中可能引入人为的错误，测试执行后，复杂的决策条件、循环和分支的覆盖率目标可能并没有达到，这时需要进行分析找出原因，导致一些重要执行路径没有被覆盖的可能原因有：

A.不可行路径或条件――应该标注测试说明证明该路径或条件没有测试的原因。

B.不可到达或冗余代码――正确处理方法是删除这种代码。

这种分析容易出错，特别是使用防卫式程序设计技术（DefensiveProgrammingTechniques）时，如有疑义，这些防卫性程序代码就不要删除。

C.测试用例不足――应该重新提炼测试用例，设计更多的测试用例添加到测试说明中以覆盖没有执行过的路径。

理想情况下，覆盖完善阶段应该在不阅读实际代码的情况下进行。

然而，实际上，为达到覆盖率目标，看一下实际代码也是需要的。

覆盖完善步骤的重要程度相对小一些。

最有效的测试来自于分析和说明，而不是来自于试验，依赖覆盖完善步骤补充一份不好的测试设计。

适合的技术：

A.分支测试

B.条件测试

C.设计定义――试验测试

D.状态转换测试

第4章单元测试用例设计

4.1单元测试的概述

单元通俗地说就是指一个实现简单功能的函数。

单元测试就是指用一组特定的输入（测试用例）测试函数是否功能正常，并且返回了正确的输出。

单元测试的目的是检查程序的行为是否符合设计规格，程序的行为就是某种输入时会产生什么输出，因此，一个典型的测试用例完成以下工作：

设定输入数据、执行程序、验证输出是否符合预期。

函数的输入数据一般包括：

A.参数；

B.成员变量，只考虑函数需要读取的成员变量；

C.全局变量，只考虑函数需要读取的全局变量；

以上三项，当涉及到复杂数据类型时，只考虑函数需要读取的域，例如，一个结构对象，有十个域，而函数只读取其中一个域，则不必考虑其他九个域。

D.其他数据，如函数需要读取文件或数据库中的数据，则要先在文件或数据库中设置好这些数据。

显然，所有可能输入都进行测试，既不可能也无意义，我们应该用一定的规则选择有代表性的数据作为输入。

输入可分为三大类：

正常输入，边界输入，非法输入，每大类还可再分为若干小类，划分小类的依据是：

同一小类中每个数据都具有等价的测试效果，也就是说，小类中任取一个数据作为输入，如果测试通过，可以肯定同小类的其他输入也可以测试通过，这就是平常说的“等价类法”。

正常输入

例如：

字符串的Trim函数，功能是将字符串前后的空格去除，那么正常的输入可以有四类：

A.前面有空格；

B.后面有空格；

C.前后均有空格；

D.前后均无空格。

边界输入

上例中空字符串可以看作是边界输入。

再如：

一个表示年龄的参数，它的有效范围是0-100，那么边界输入有两个：

0和100。

非正常输入

垃圾数据或使代码不能完成正常功能的数据，如：

一个文件操作的函数，非正常输入有这么几类：

A.文件不存在；

B.目录不存在；

C.文件正在被其他程序打开；

D.权限错误。

预期输出

一个完整的测试用例应该有预期输出，预期输出就是程序运行后的预期结果，通常表现在对某些数据的修改，即预期输出要自动判断程序所改写的数据的结果值是否符合预期。

程序可能修改的数据包括：

A.返回值；

B.输出参数；

C.成员变量，只考虑函数所改写的成员变量；

D.全局变量，只考虑函数所改写的全局变量；

以上四项，当涉及到复杂数据类型时，只考虑函数所改写的域，例如，一个结构对象，有十个域，而函数只改写了其中一个域，则不必考虑其他九个域。

E.其他数据，如函数改写文件或数据库中的数据，也是一种输出，不过通常难于自动判断是否符合预期，可用人工查看来代替。

4.2单元测试常用方法

逻辑覆盖法

逻辑覆盖是通过对程序逻辑结构的遍历实现程序的覆盖。

它是一系统测试过程和总称，这组测试过程逐渐进行越来越完整的通路测试。

从覆盖源程序语句的详尽程序分析，逻辑覆盖标准包括以下不同的覆盖标准：

1.语句覆盖（SC）：

语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。

2.判定覆盖（DC）（也叫分支覆盖）：

设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。

3.条件覆盖（CC）：

设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。

4.判定---条件覆盖（CDC）：

设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。

5.条件组合测试（MCC）：

设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。

6.修正条件判定覆盖（MCDC）这个覆盖方式需要设计足够的测试用例来确定各个条件能够影响到包含的判定的结果。

基本路径测试法：

设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次。

用例的设计方案主要的有下面几种：

条件测试，基本路径测试，循环测试。

方法详细介绍在第8章白盒测试用例设计技术。

在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。

穷举测试是不可能的。

现在进行单元测试选用的是现在一般用的比较多的基本路径测试法。

4.3设计单元测试用例

基本路径测试法举例：

见8.2白盒测试用例设计技术中的基本路径测试方法举例

第5章集成测试用例设计

集成测试计划：

集成测试计划由项目经理在设计阶段制定，它是和设计规格说明同时完成的。

在这份计划里主要包含的内容有：

测试的描述和范围、测试环境、时间表、集成次序、测试用例、测试的预期结果等。

集成测试计划完成后需进行同行评审，评审方法参见《评审指南》。

小型项目可不单独制定集成测试计划，而将内容合并在项目主计划中；大中型项目如果集成测试后续有系统测试，集成测试计划也可合并到系统测试计划中。

5.1集成测试方法

集成测试应该考虑以下问题：

1.在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

2.各个子功能组合起来，能否达到预期要求的父功能；

3.一个模块的功能是否会对另一个模块的功能产生不利的影响；

4.全局数据结构是否有问题；

5.单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

因此，单元测试后，有必要进行集成测试，发现并排除在模块连接中可能发生的上述问题，最终构成要求的软件子系统或系统。

对子系统，集成测试也叫部件测试。

任何合理地组织集成测试，即选择什么方式把模块组装起来形成一个可运行的系统,直接影响到模块测试用例的形式、所用测试工具的类型、模块编号和测试的次序、生成测试用例和调试的费用。

通常，有两种不同的组装方式：

一次性组装方式和增值式组装方式。

5.1.1一次性组装方式（BIGBANG）

一次性组装方式是一种非增值组装方式（NON－INCREMENTALINTEGRATION），也叫整体拼装。

按这种组装方式，首先对每个模块分别进行单元测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。

这种一次性组装方式试图在辅助模块的协助下，在模块单元测试的基础上，将所测模块连接起来进行测试。

但是由于程序中不可避免地存在模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。

其结果发现有错误，但茫然找不到原因。

查错和改错都会遇到困难。

5.1.2增殖式组装方式（IncrementalIntegration）

增殖式组装方式又称渐增式组装。

首先是对一个个模块进行模块单元测试，然后将这些模块组装成较大系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。

最后增殖逐步组装成为要求的软件系统。

5.1.2.1自顶向下的增殖方式（Top-DownIntegration）

这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。

其步骤如下：

（1）以主模块为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块对主模块进行测试。

（2）采用深度优先（depth-first）或宽度优先（breadth-first）的策略，用实际模块替换相应桩模块，再用桩代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。

（3）进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引起的错误的可能。

（4）判断是否所有的模块都已组装到系统中？

是则结束测试，否则转到

（2）去执行。

自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。

在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而较早就能遇到。

如果这主要控制有问题，尽早发现它能够减少以后的返工，所以这是十分必要的。

如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。

此外，功能可行性较早得到证实，还能够给开发者和用户带来成功的信心。

自顶各下的组装和测试存在一个逻辑次序问题。

在为了充分测试较高层的处理而需要较低层处理的信息时，就会出现这类问题。

在自顶向下组装阶段，还需要用桩模块代替较低层的模块，

为了能够准确地实施测试，应当让桩模块正确而有效地模拟子模块的功能和合理的接口，不能是只包含返回语句或只显示该模块已调用信息，不执行任何功能的哑模块。

如果不能使桩模块正确地向上传递有用的信息，可以采用以下解决办法。

（1）将很多测试推迟到桩模块用实际模块替代了之后进行；

（2）进一步开发能模拟实际模块功能的桩模块；

（3）自底向上组装和测试软件；

5.1.2.2自底向上的增殖方式

这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。

因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。

在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。

自底向上增殖的步骤如下：

（1）由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。

（2）用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。

（3）为子系统配备驱动模块，进行新的测试。

（4）判断是否已组装到达主模块。

是则结束测试，否则执行

（2）。

随着组装层次的向上移动，驱动模块将大为减少。

如果对程序模块结构的最上面两层模块采用自顶向下进行组装和测试，可以明显地减少驱动模块的数目，而且可以大大减少把几个系统组装起来所需要做的工作。

5.1.2.3混合增殖式测试

自顶向下增殖的方式和自底向上增殖的方式各有优缺点。

一般来讲，一种方式的优点是另一种方式的缺点。

自顶向下增殖方式的缺点是需要建立桩模块。

要使桩模块能够模拟实际子模块的功能十分困难，因为桩模块在接收了所测模块发送的信息后需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。

同时涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，导致过多的回归测试，而自顶向下增殖方式的优点能够较早地发现在主要控制方面的问题。

自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。

就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。

但这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。

此外自底向上增殖的方式可以实施多个模块的并