【软件测试】

软件测试是什么？

软件测试是以发现软件的缺陷为目的，使软件运行，并将软件不运行所产生的危险性降低到允许的范围

软件测试是为了发现错误而执行程序的过程。

设计测试用例，并利用这些测试用例去运行程序，以 发现错误。

IEEE提出的软件工程标准术语，软件测试定义如下： “使用人工和自动手段来运行或测试某个系统的过程， 其目的在于检验它是否满足规定的需求或者是弄清预 期结果与实际结果之间的差别。”

软件测试的目的

发现程序的错误

发现程序中的错误并 进行修正，将软件不 工作的风险程度降低 到一个可以接受的程 度，而不是为了证明 软件没有问题

验证需求的正确

软件测试的目的就是 验证软件是否满足客户 的需求，确保提交到客 户的产品能够满足客户 的需求

质量保证的需要

软件质量保证是软件 开发周期中一个重要 环节，以软测试为中 心的软件质量保证技 术在软件质量保证过 程中起重要的作用

学习测试技术的目的

从一个测试例子说起

式样要求

•Ｉ大于等于0时，打印“Ｉ≧０”

•Ｉ小于0时，打印“Ｉ＜０”

程序实现

ＰＲＯＧＲＡＭ ＳＡＭＰＬＥ

ＩＦ（Ｉ．ＧＥ．０）ＴＨＥＮ （ＧＥ表示“≧”）

        ＰＲＩＮＴ＊，‘Ｉ≧０’ （PRINT时显示‘Ｉ≧０’)

ＥＬＳＥ

        ＰＲＩＮＴ＊，‘Ｉ＜０’

ＥＮＤ ＩＦ

ＥＮＤ

Ａ：６种测试用例：

case １：Ｉ＝１ 测试结果：打印“Ｉ≧０”

case ２：Ｉ＝５ 测试结果：打印“Ｉ≧０”

case ３：Ｉ＝１０ 测试结果：打印“Ｉ≧０”

case ４：Ｉ＝－１ 测试结果：打印“Ｉ＜０”

case ５：Ｉ＝－５ 测试结果：打印“Ｉ＜０”

case ６：Ｉ＝－１０ 测试结果：打印“Ｉ＜０”

Ｂ：2种测试用例：

case １：Ｉ＝１ 测试结果：打印“Ｉ≧０”

case ２：Ｉ＝－１ 测试结果：打印“Ｉ＜０”

Ｃ：３种测试用例：

case １：Ｉ＝１ 测试结果：打印“Ｉ≧０”

case ２：Ｉ＝０ 测试结果：打印“Ｉ≧０”

case ３：Ｉ＝－１ 测试结果：打印“Ｉ＜０”

各自测试的说明

• Ａ：我实行了非常多的测试用例。所以3人之中我实施了 最好的测试!

• Ｂ：Ａ实施了多余无用的测试。其实，这时候只要两个 测试用例就足够了。我实施了非常有效率的测试!

• Ｃ：Ａ实施了多余无用的测试。而Ｂ的测试用例又太少 了，尤其是边界值左右的测试用例不足!

实施测试就需要掌握测试技术 三人谁实施了更好的测试用例，即掌握了正确的测试方法？

提示：如程序中“I>=0”误写成了“I>0”，谁能发现问题？

开发者测试的目的就是“保证自己设计东西的质量”！

什么是缺陷

软件缺陷是对软件产品预期属性的偏离现象

判断缺陷的规则
1. 软件未达到产品说明书标明的功能
2. 软件出现了产品说明书指明不会出现的错误
3. 软件功能超出产品说明书指明范围（额外的创造是不需要的）
4. 软件未达到产品说明书虽未指出但应达到的目标
5. 软件测试员认为软件难以理解、不易使用、运行速度缓慢
6. 最终用户认为不好

软件缺陷是不可能完全避免

开发过程中沟通不足

软件复杂度越来越高

程序编写时产生错误

需求理解不足及变化

项目进度和日程压力

开发文档的重视不够

软件开发工具的缺陷

 

软件测试的内容

验证设计

证实需求

发现缺陷

预防缺陷 

软件测试的规律

木桶原理

•在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素 是分析、设计和实现，测试应该是融于其中的补充检查手段。测试是提高产 品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一 种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将 是一个恐怖而漫长的灾难。

BUG的80-20原则

•一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免 80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有 在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能 多地发现错误，无法保证能够发现所有的错误。

•80% 的软件缺陷常常生存在软件 20% 的空间里。如要有效的软件测试，则 应重点关注高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。

软件测试的发展

传统测试

• 在开发的后期才介入和进行

• 其概念是基于代码运行的活动

• 以发现错误为目的的范畴

现代测试

• 已扩展到整个软件生命周期

• 其概念已扩展到静态的概念

• 已扩展到缺陷预防的范畴

软件测试人员的基本素质

探索精神
故障排除能手
不懈努力
创造性
追求完美
判断准确
老练稳重
说服力

1.他们不会害怕进入陌生环境，喜欢拿到新软件，安装在自己机器上，观看结果

2.他们善于发现问题的症结，喜欢猜谜

3.他们总是不停尝试。可能会碰到转瞬即逝或者难以重建的软件缺陷。他们不会心存侥幸，而是尽一切可能去寻找

4.只测试显而易见的事实，那不是一个很好的测试员。他们的工作是想出富有创意甚至超常的手动来寻找软件缺陷

5.他们力求完美，但是知道某些无法企及时，不去苛求，而是尽力接近目标

6.他们要决定测试内容、测试时间，以及看到的问题是否算作真正的缺陷

7.他们不害怕坏消息，他们必须告诉程序员。优秀的软件测试员知道怎样老练地处理这些问题，和不够冷静的程序员怎样合作

8.他们找出的软件缺陷有时被认为不重要，不用修复。测试员要善于表达观点，表明软件缺陷为何必须修复，并通过实际演示力陈观点

软件测试的几个基本概念

测试阶段划分

• 单体测试：是指对单个模块或者是一个函数等更小单位的测试
• 集成测试：是指都多个模块组合起来后进行的测试
• 系统测试：是指整个系统的所有模块都结合起来以后进行的测试
• 回归测试：是指修复或调整好软件环境之后进行测试
• 差分测试：是指只对整个系统中新变更功能的相关部分的测试

测试方法划分

• 手动测试：是指测试人员，根据功能规格说明书、编写的测试大纲或者其他测试文档，直接运行程序而完成的测试
• 自动化测试：是指测试人员，使用自动测试工具，让程序自动运行而进行的测试

软件测试活动从不同的角度和手段考虑，可以分为：

• 静态测试与动态测试
• 白盒测试与黑盒测试
• 手工测试与自动测试
• 随机测试与穷举测试

静态测试

不运行被测试的软件系统，而是采用其他手段和技术对测 试软件进行检测的一种测试技术，如：

• 代码检查
• 文档评审(各种评审是一 种有效的静态测试方法)
• 控制流分析
• 数据流分析
• 信息流分析

动态测试

按照预先设计的数据和步骤去运行被测软件系统，从而对 被测试软件系统进行检测的一种测试技术：

• 单元测试
• 集成测试
• 系统测试
• 验收测试

白盒测试

• 白盒测试又称结构测 试、逻辑驱动测试或 基于程序的测试。是依据被测试程序分析程序内部构造和设计用例，来对内部控制流程进行测试，可完全不考虑程序的整体功能实现情况。

• 白盒测试是基于程序结构的逻辑驱动测试。

白盒测试方法

语句覆盖：又称行覆盖、段覆盖、基本块覆盖，这是最常见的一种覆盖方 式，就是度量被测代码中每个可执行语句是否被执行到了。

条件覆盖：又称分支覆盖。设计足够的测试用例，使得程序中的每一个取“ 真”分支和取“假”分支至少经历一次。

判定覆盖：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能 值至少满足一次 。通常一个判定语句是由多个条件组合而成。

路径覆盖：又称断言覆盖。它度量了是否函数的每一个分支都被执行了。 有多个分支嵌套时，需要对多个分支进行排列组合。可想而知 ，测试路径随着分支的数量指数级别增加。

程序插桩：简单的说就是借助被测程序中插入操作来实现测试目的的方法 。常用的就是断言语句，了解程序执行中的一些动态信息。

• 设计思想：调试程序时我们常通过在程序中插入一些打印语句来输出我们 关心的信息，如程序实际执行路径，特定变量的的取值等，程序插装就是利用这种思想来获得我们需要的各种信息。
• 关注重点：• 探测哪些信息 • 在程序什么位置进行探测 • 需要设置多少个探测点

测试设计用例分析_白盒测试1

 基本路径测试

•   把流程图改成流图
•   建立独立路径

        独立路径是指程序中至少引进一个新的处理语句集合或者一个新条件的任一路径。即独立路径必须至少包含一条在定义该路径之前不曾用到的新边 

•   建立独立路径集合，组成路径覆盖测试所采用的测试用例集

测试设计用例分析_白盒测试2

独立路径建立

路径1：1->11
路径2：1->2->3->4->5->10->1->11 
路径3：1->2->3->6->8->9->10->1->11  
路径4：1->2->3->6->7->9->10->1->11
这里的每一条新的路径都包含了一条新边 
而路径1->2->3->4->5->10->1->2->3->6->8->9->10->1->11，对于上面4条来说不是独立路径，因为它只是已有路径的简单合并，并未包含任何新边
独立路径集合：路径1～路径4

黑盒测试

• 黑盒测试主要关注被测 软件的功能和非功能属性的实现，测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性。

• 黑盒测试把软件系统看成一个黑盒子，完全不考虑软件内部逻辑结构 和处理过程。

• 黑盒测试是基于规格和数据驱动的测试，依据是需求规格说明书。

黑盒测试设计

等价类划分

•   等价类划分是指分步骤地把过多的测试用例减少到同样有效的小范围的过程
•   等价类是指测试相同目标或者暴露相同软件缺陷的一组测试用例

等价类划分的步骤

•   无效等价类和有效等价类的确定
•   以最少的测试设计覆盖最多的有效等价类，直到完成覆盖为止
•   选择一个测试设计去包含一个无效等价类，直到测试设计包含所有的无效等价类为止

等价划分的方法

•   输入条件代表一个范围或者需要一个特定的值，则可以定义一个有效等价类和两个无效等价类 
•   输入条件代表集合的某个元素或者是该输入条件是布尔式的，则可以定义一个有效等价类和一个无效等价类 
•   如果确认已划分的等价类中各元素在程序中的处理方式是不同的，则应将此等价类进一步划小 
•   默认值、空白、空值或者无输入等条件要作为特殊的等价类

把输入输出划分为一定的区域：

• 用一个值等价代替区域内的其它值，测试单元行为
• 区域内其它值被忽略

输入输出不仅仅包括进程的参数：

• 外部数据，全局变量
• 时间
• 次序/历史
• 状态

每一区域都应设计测试用例，区域分类如下：

• 有效等价类
• 无效等价类

实例说明 
设有条件式: 0<X<=10,则：
无效等价类1：
X<=0,如0,-1,-2,-3…..
有效等价类：
0<X<=10,如1,2…9,10
无效等价类2：
X>10，如11,12,13…

测试用例
• 测试用例1:
X=-1，覆盖无效等价类1；
• 测试用例2:
X=1，覆盖有效等价类；
• 测试用例3：
X=12，覆盖无效等价类2。

依据等价类划分进行测试，需要做到：
• 等价类划分需要和边界值分析结合来设计测试用例；
• 有效等价类测试用例需要包含有效等价类内的边界值以及中间值；
• 每个无效等价类都要分别测试，测试用例需要包含各无效等价类内的边界值。

边界值分析

边界值分析是指软件计划的操作界限所在的边缘条件

着眼于某条件的真、假交界处的值，以极限值来测试：

• 错误可能经常发生在边界的取值；
• 边界值分析使用与等价类划分同样的区域。

设计用例原则 :

• 若输入规定了取值范围等，则应取范围的边界值；
• 对于客户需求的每个输出条件也应取范围的边界值；
• 如果客户需求中的输入和输出是有限的集合，则应当
• 取集合中的第一个和最后一个元素作为测试用例；
• 分析客户需求，找到其他可能的边界值。

边界值的数据类型：
包括数值、速度、字符、地址、位置、尺寸、数量等

边界特征：
第一个/最后一个、最小值/最大值、开始/完成、超过/在内、空/满、最短/最长、最慢/最快、最早/最迟、最大/最小、最高/最低、和相邻/最远等特征

边界值分析的方法
  输入条件代表以α和β为边界的范围时，测试用例应当包含α、β以及略大于α和略小于β的值 
  输入条件代表一组值，测试用例应当执行其中的最大值和最小值，还应当执行略大于最小值和略小于最大值的值 
  对于前两个方法，也要考虑输出条件，测试用例应当包括能够产生最大和最小的输出值的数据 
  如果程序数据结构有预定义的边界(比如要求数组有100项)，要测试其边界的数据项 
边界值分析的注意事项
  在软件的每一个部分不断寻找边界时极为重要的，更多的边界将会被发现，从而找出更多的软件缺陷
  软件内部存在的边界是不能忽略的(2进制、ASCII、Unicode等) 

实例说明 
设有条件式: 0<X<=10,则：
• X<=0：-1，0，1
• 0<X<=10：-1，0，1，9，10，11
• X>10：9,10,11
测试用例:
只要测试X=-1,0,1,9,10,11这6个测试CASE就达到了边界值测试要求

依据边界值分析测试，需要做到：
• 边界值分析需要和等价类划分结合来设计测试用例；
• 边界值测试要选取正好等于、刚刚大于、或刚刚小于边界的值作为数据进行测试；
• 根据客户需求及硬件限制等状况找到各种可能的边界是进行边界值分析的关键。

状态迁移测试

状态迁移测试的目的：
通过给定的触发条件验证软件对应的状态迁移和处理是否正确。
状态迁移测试概述：
又称功能图分析方法或者流程测试，用这种方法可以逆向的设计测试用
例，比如状态和事件的非法组合。
状态迁移测试的原则：
根据状态迁移图，列出状态事件表，推导出测试路径，编写合法测试用例，同期编写出非法测试用例。

判定表驱动

内容概述
在一些数据处理问题中，某些操作是否实施依赖于多个逻辑条件的取值。也即在这些逻辑条件取值的组合所构成的多种情况下，分别执行不同的操作。判定表可以有效测试这类问题的正确与否。
基本应用
决策表的纵向描述输入条件和处理结果，横向描述测试项目编号。在表的各单元格中填写○/—（真/假）或具体的输入值。这样就可防止测试项目的遗漏，测试的重复进行，证明覆盖率，便于维护。
适用条件
• 客户需求以判定表形式给出，或是很容易转换成判定表；
• 条件或者规则的排列顺序不会也不应影响执行哪些操作；

错误推测法

内容概述
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例。
基本思想
列出程序中所有可能有错误和易发生错误的特殊情况据此选择测试用例。
推测依据
• 该模块中常见的错误
• 以前产品测试中曾经发现的错误等
• 已发现缺陷的测试方法的推广
• 容易发生错误的情况 

基于客户需求的测试

• 功能测试
• 性能测试
• 容错测试
• 安全测试

黑盒综合测试策略
• 首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。
• 在任何情况下，都必须使用边界值分析法。经验表明，用这种方法设计出的测试用例发现程序错误的的能力最强。
• 可以使用错误推测法追加一些测试用例，这需要依靠测试人员的智慧和经验。
• 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
• 如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选用判定表驱动法。
• 根据即客户需求和系统设计的要求进行必要的容错、性能和安全测试。

测试设计用例分析_黑盒测试

功能说明：
通过输入a、b、c的值来判断是否为等腰三角形，要求a、b、c为正整数且取值范围为（0,9999］
请建立测试用例进行测试

 

白盒和黑盒测试的差异点

软件产品周期简介

 根据需求文档进行分析制定测试策略和测试计划
 分别根据需求分析、概要设计和详细设计的输出进行测试设计
 使用测试设计文档，进行各个阶段的测试执行
 当软件产品周期，需求文档变化时，将重新进行前三个工作
 产品Release之后进行测试工作的总结

测试设计

根据测试阶段的不同，测试设计包括以下几种：
系统测试的测试设计
集成测试的测试设计
性能测试的测试设计
单体测试的测试设计

系统集成测试的测试设计

测试大纲的编写

•  提出功能点
•  功能点细化
•  测试方法和测试结果填写

1.根据需求分析文档得到软件产品应该包括的功能点（包括大小功能点），组成测试大纲的第一部分，要求测试大纲必须覆盖软件产品应该包括的全部功能点
2.分析需求分析文档得到每个功能点的细化部分，组成测试大纲的第二部分，要求覆盖需求文档中所有可测试的内容
3.对每个功能点的细化部分，确定其测试方法（或者测试步骤）和预计的正确测试结果
测试用例的编写

•   编写覆盖主要的功能点的测试用例，以供功能验证时使用
•   需要特殊条件才能测试的功能点，必须编写测试用例

性能测试的测试设计

根据性能指标，选择测试用例
根据需求文档得到用户明确要求的性能指标
根据收集的性能指标，建立性能测试的测试大纲

版本升级的项目，各功能的性能指标不得低于旧版本的性能指标
模型产品，新模型各功能的性能指标以不低于旧模型的性能为要求

单体测试的测试设计

白盒测试的测试设计方法
命令覆盖
要求程序中每一可执行语句至少执行一次 
分支覆盖
要求程序中每个判定的True分支和False分支至少执行一次 
条件覆盖
要求使程序的每个条件语句的True和False取值至少满足一次 
路径覆盖
要求设计足够的测试用例，要求覆盖程序中所有的路径 

根据测试阶段的不同，测试执行分成

•   单体测试的测试执行
•   单集成测试的测试执行
•   集成测试和系统测试的测试执行
•   性能测试的测试执行

单体测试的测试执行

•  根据白盒测试设计和黑盒测试设计得到测试用例
•   编写对待测代码进行输入和得到输出程序，或者找到能对待测代码进行输入和得到输出的调试方法
•   使用测试用例逐一输入，收集输出结果，检查输出结果是否正确
•   代码检查是单体测试必须的步骤

单集成测试的测试执行-1

  自顶向下法
自顶向下法的步骤
1.将主控模块作为测试驱动器，所有的稳定桩替换为隶属于主控模块的模块
2.根据集成的实现方法(深度优先或者广度优先)，下层的稳定桩一次一个地被替换为真正的模块
3.在每一个模块集成的时候都要进行测试
4.在完成了每一次测试之后，又一个稳定桩被用真正的模块替换

单集成测试的测试执行-2

  自底向上法
自底向上法的步骤：
1.低层模块组合成能够实现软件特定子功能的簇
2.写一个驱动程序(一个供测试用的控制程序)来协调测试用例的输入输出
3.对簇进行测试
4.移走驱动程序，沿着程序结构的层次向上对簇进行组合 

 集成测试和系统测试的执行－1

• 判定需求，执行测试设计和测试用例，填写结果
•  及时准确反馈产品缺陷
•  定期完成修改的确认
•  分析缺陷发生趋势，制定测试策略
•  需求变更时，对应变更测试设计文档

 集成测试和系统测试的执行－2

 判定需求，执行测试设计和测试用例，填写结果

• 获得测试版本的同时要获得版本对应的测试需求，根据需求选择相关的测试设计文档和测试用例文档
• 根据选择的文档进行测试，要求至少完成一遍的覆盖，覆盖测试后填写测试结果（OK和NG）
• 完成版本的测试时，把完成的文档测试结果和该版本发现的缺陷一起提交

集成测试和系统测试的执行－3

及时准确反馈产品缺陷

•   测试中发现缺陷（包括不确定的）时，首先要进行记录，其次在进行是否缺陷的分析
•   当天发现的缺陷要尽量在当天完成登陆
•   要准确填写错误等级和再现率

错误等级

• A类为严重影响系统运行（并且不可恢复）
• B类为影响系统运行（可以恢复）
• C类为不影响系统运行但必须修改
• D类为所提建议 

再现率

• 要求记录准确的测试和再现次数，尽量不要出现1/1的情况
• 再现时注意环境的正确，在已经出现缺陷的环境上继续再现的意义不大
• 再现前要尽量通过分析降低再现的难度和再现的步骤

集成测试和系统测试的执行－4

及时准确反馈产品缺陷
补充发现缺陷的相关信息（DEBUG信息，缺陷发生的图片，死机时的堆栈信息，发生缺陷的现场等）

集成测试和系统测试的执行－5

定期完成修改的确认

•   当发布新的版本到测试时，要得到该版本开发人员投入的已经修改的缺陷，进行确认
•   合理的分配测试时间，当测试工作量比较大时，首先完成变更点的测试，然后再进行确认测试

集成测试和系统测试的执行－6

 分析缺陷发生趋势，制定测试策略
 1.收集测试数据，分析并使用
区分整个测试时间里，测试时间占用情况的分类
功能覆盖测试
脱离测试设计文档的自由测试
差分测试 （针对功能点变更进行的测试）
发现缺陷的再现测试
确认测试
开发人员调试
2.根据不同分类收集测试数据
根据测试时间占用情况的分类进行测试数据的收集
分析测试效率，发现问题
对于功能覆盖测试、自由测试和差分测试都是有效的测试时间，基本上90％以上的缺陷都是这个期间发现的，因此可以得到测试组以及每个测试人员的测试效率，然后再结合实际进行分析，就能得到测试组或者某个测试成员的测试状态如何

集成测试和系统测试的执行－7

需求变更时，对应变更测试设计文档

• 对应产品开发过程中的需求变更方法，要和项目开始前的需求分析方法相同，对需求变更的部分及时修改或者填写测试设计文档

性能测试的测试执行

选择性能测试的对象，建立性能测试测试大纲
 收集评价用的性能数据，向测试大纲进行补充
 定期根据性能测试测试大纲，对产品进行性能测试数据收集
 及时反馈性能数据

• 对提前收集的性能数据分析，评估当前的产品不能达到性能要求时立即向开发人员反馈性能数据
• 对性能测试阶段收集的性能数据，进行分析后提交开发人员

反馈性能数据的目的：

• 评估和预定的性能指标的差异
• 帮助开发人员分析造成性能指标差异的原因

例题

Myers问题: 读入三个整数值。这三个数值表示了一个三角形三条边的长度。程序将输出一条信息，说明该三角形是不等边三角形，等腰三角形，还是等边三角形。(并不要求写出程序)写出你认为能充分地测试这个问题的测试实例（即特定的数据集）。

（格式可写成：测试实例说明     测试实例值       期望输出）。 

备注：假设该系统整数的取值范围是[-65536~65535]

例题答案

*1    合法的不等边三角形                 5    3    4               不等边三角形 
*2    合法的等腰三角形                    3    3    4                等腰三角形 
*3     合法的等边三角形                    3    3    3        等边三角形 
*4     两个相同值边的互换（第一次）      50   50   25              等腰三角形 
5     两个相同值边的互换（第二次）       25   50   50               等腰三角形 
6     两个相同值边的互换（第三次）       50   25   50               等腰三角形 

*7    一条边为0                           1000  1000  0               非法 
*8     一条边值为负                         3     3    -4               非法 
*9     两条相同边的第一次互换（非法）    5     5    10               非法 
10    两条相同边的第二次互换（非法）     10    5    5                非法 
11    两条相同边的第三次互换（非法）    5     10   5                非法 
*12    两条较小的边长之和小于最大的边长 8     2    5                非法 
13    上例的二条边第二次交换                2     8    5                非法 
14    上例的二条边再次交换                  2    5    8                 非法 
15    上例的二条边再次交换                  8    5    2                 非法 
16    上例的二条边再次交换                 5    8    2                 非法 
17    上例的二条边再次交换                  5    2    8              非法

软件测试模型

测试过程模型
随着测试技术的蓬勃发展，测试过程的管理显得犹为重要。测试专家提出了许多的测试过程管理模型， 这些模型定义了测试活动的流程和方法，为测试管理工作提供了指导。

• V模型
• W模型
• X模型
• H模型

V型模型
• 由Paul Rook提出
• ２０世纪８０年代后期创建
• 旨在改进软件开发的效率和效果
• 反映出了测试与分析设计的关系
• 与瀑布模型同样受到批评和质疑

W型模型
• Evolutif公司提出
• 增加了软件各开发阶段中应同步进行的验证和确认活动
• 两个V字型模型组成，分别代表测试与开发过程
• 明确表示出了测试与开发的并行关系 

X型模型
• Goldsmith提出对单独程序段进行独立的编码和测试，不断的集成后形成可执行的程序
• 集成的程序可以是最终的成品，也可是整个集成产品的一部分
• 变更可以发生在各个部分

H型模型
下图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其它流程可以是任意的开发流程，例如设计流程或者编码流程。即只要测试条件成熟且准备活动完毕，测试执行活动就可进行。 H模型中软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行。

测试模型的选择

理想的测试模型策略
以W模型作为框架，及早的、全面的开展测试，在软件单元测试和模块集成过程中考虑X模型思路。同时灵活运用H模型独立测试的思想，在达到恰当的就绪点时就应该开展独立的测试工作，同时将测试工作进行迭代，最终保证完成测试目标。

推荐的测试模型策略
• 以W测试模型作为项目开发应用的基本测试模型
• 需求分析的同时进行验收测试case的做成
• 系统设计的同时进行系统测试case的做成
• 概要设计的同时进行集成测试case的做成
• 详细设计的同时进行单元测试case的做成

软件测试流程

单元测试

内容概述
单元是软件说明书中提供的最小组件，如函数，子程序，过程，类和包等。单元测试就是针对软件中这些最小组件进行正确性验证的测试工作。对于C语言的程序单元测试主要针对函数，变量，子程序等，而对C++语言的程序单元测试主要针对类。
测试目的
经常与单元测试联系起来的另外一些开发活动包括代码Review，静态分析和动态分析。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。单元测试的目的在于发现各模块内部可能存在的各种错误，以保证进行集成测试前模块内部处理没有问题。单元测试主要是基于白盒测试（逻辑测试），但机能测试采用黑盒测试。

一些错误的认识

• 太浪费时间了，现在要赶进度，时间上根本不允许，或随便做做应付领导。
• 我是一个很棒的程序员，我写的代码肯定是没有问题的。
• 做单元测试太烦了，直接集成，到时有问题在集成测试时肯定能发现，实在不行在系统测试总该能发现吧。
• 单元测试仅仅是证明这些代码做了什么，根本发现不了什么问题。

对于以上错误认识的产生归根结底还是由于对单元测试的理解不够，没有真正认识到单元测试的重要性。
单元测试是软件测试的基础，因此单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。

单元测试的重要性

时间方面：
如果认真的做好了单元测试，在系统集成联调时非常顺利，因此会节约很多时间，反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题，而这种问题在集成时遇到往往调查困难，花费大量时间才发现是个很低级的错误，正所谓得不偿失。
测试效果：
根据以往的测试经验来看，单元测试的效果是非常明显的，首先它是测试阶段的基础，做好了单元测试，在做后期的集成测试和系统测试时就很顺利。其次在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发现而在集成测试和系统测试很难发现的问题。再次单元测试关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。

测试成本：
在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所花的成本将成倍数上升。比如单元测试时发现1个问题需1个小时，则在集成测试时就需2个小时，在系统测试时则需3个小时，同理还有定位问题和解决问题的费用也是成倍数上升的，这就是我们要尽可能早的排除尽可能多的bug来减少后期成本的因素之一。
产品质量：
单元测试的好与坏直接影响到产品的质量，可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标，或者导致更严重的后果，如果我们做好了单元测试这种情况是可以完全避免的。千里之堤毁于蚁穴，QC或者产品投入使用后发生的一些问题往往是一些简单的原因导致的。

总之，单元测试是构筑产品质量的基石，我们不能为节省时间不做单元测试或随便做做而让我们在后期浪费太多不值得的时间，我们也不愿意因为由于节省那些时间导致开发出来的整个产品失败或重来！

测试环境
• 单元本身不是独立的程序，需要开发驱动模块和桩模块
• 驱动模块：用来驱动被测模块的主程序，来保证测试的实施
• 桩模块：用来代替所测模块调用的子模块

单元测试标准
1.必须达到一定覆盖度要求：
• 对于没有任何分支判断的函数达到100%语句覆盖就可以；
• 对于有分支判定，但判定中条件只有一个的函数需要达到100%判定覆盖和语句覆盖；
• 对于有分支判定，但判定中的条件为组合条件的函数需要达到100%判定-条件组合覆盖。
2.进行逻辑覆盖测试的同时，还必须对输入输出进行正常值、边界值、异常值的测试。

实际应用
单体测试报告书作为单体测试的具体应用，结合测试理论和方法对单元测试内容进行明确要求，概要说明如下：
• 应用的测试方法
白盒测试：逻辑覆盖/程序结构分析（控制流/数据流/信息流）
黑盒测试：等价类划分/边界值分析/错误推测法
• 应用的测试工具
WINAMS： 适用于采用瑞萨系列芯片的模型
Simulator：适用于采用NEC等芯片的模型
VC++工具： 各种芯片的模型都可以使用，但效率相对较低
• 应用的代码检查工具
SQMLINT： 适用于采用瑞萨系列芯片的模型
PCLINT: 各种芯片的模型都可以适用
QAC: 各种芯片的模型都可以适用
注：代码检查工具作为静态测试的手段，可帮助发现程序中存在逻辑错误问题。 

 

 

 

集成测试

内容概述
是在单元测试基础上，将所有模块按概要设计要求组装成子系统或系统，验证组装后功能及模块间接口是否正确的测试工作。
测试目的
集成模式的目的是检验软件模块对《概要设计说明书》（含接口定义书等）的符合程度。同时也包含系统进行集成的过程。
测试级别
• 模块内集成
• 子系统内集成
• 子系统间集成 
集成方式
• 自底向上结合
• 自顶向下结合

 实际应用
结合测试报告书作为集成测试的具体应用，结合测试理论和方法对集成测试内容进行明确要求，概要说明如下：
• 应用的测试方法
白盒测试：程序结构分析（控制流/数据流/信息流）
黑盒测试：基于客户需求的测试/等价类划分/边界值分析/错误推测法/判定表驱动
• 应用的测试工具
实机测试：通过样机或调试板等实机测试环境进行确认
Simulator:通过Simulator工具对模块间SEQUENCE等进行模拟测试
• 测试的主要内容
1）模块间的接口检证
2）模块间的SEQUENCE检证
3）模块及模块间机能检证
4）模块及模块间性能检证
5）模块与硬件关联检证
6）模块间容错处理检证

 

 

 

 

 

 系统测试

内容概述
是将已集成完的软件系统作为整个基于计算机系统的一个元素，与硬件、外设、数据等其他系统元素结合，在实际环境下对计算机系统进行的测试工作。
测试目的
系统测试的目的在于通过与《需求规格说明书》（即客户需求）做比较，发现软件与系统需求定义不符合或者矛盾的地方。
实际应用
• 由评价人员实施
• 基于客户需求的测试-主要是功能测试
• 主要是黑盒测试

 差异点分析

测试方法不同
• 系统测试主要属于黑盒测试
• 单元测试主要属于白盒测试
• 集成测试属于白盒和黑盒结合测试，也称灰盒测试
考察范围不同
• 单元测试主要测试模块内部的逻辑处理
• 集成测试主要测试模块间的接口，以及单元组合后的整体功能
• 系统测试主要测试整个系统对于客户需求是否满足
评估基准不同
• 系统测试的评估基准是测试用例对需求规格的覆盖率
• 单元测试和集成测试主要的评估主要是代码的覆盖率

验收测试

内容概述
是为用户方组织的有效性和系统测试，它的测试数据通常是系统测试的测试数据的子集，这是软件在投入使用前的最后测试。
测试目的
其目的是在产品投入使用前向软件的购买者展示该软件系统满足客户的需求。有时验收测试也可能由客户方来实施，如信赖性测试。
测试方法
• 性能测试
• 功能测试
• 随机测试
• 可靠性测试

回归测试

内容概述
软件在测试或其他活动中发现的缺陷经过修改后，或进行式样变更对应后，就需要对已经进行过的测试的某些子集重新进行一遍测试。
测试目的
其目的是验证缺陷得到了正确的修复，或变更符合客户的需求，同时修正或变更没影响到其他功能。回归测试可能发生在单体，集成，系统测试任何阶段。
测试策略
• 完全重复测试
• 选择性重复测试

回归测试要求

• 在单元、集成和系统测试阶段的代码修改都要进行回归测试；
• 单元测试后进行的代码修改需要由开发人员实施单元测试回归，即对代码变更可能影响到的单元测试用例实施测试；
• 集成测试后进行的代码修改需要由开发人员实施单元和集成测试回归，即对代码变更可能影响到的单元和集成测试用例实施测试；
• 系统测试后进行的代码修改需要由开发人员实施单元和集成测试回归，同时评价人员要进行系统测试回归；
• 在实施回归测试时必要的情况下还需要追加必要的单元、集成和系统测试用例来确保代码变更可能影响到的范围都能被测试到；
• 系统测试阶段实施的回归测试需要开发人员和评价分别实施相应的回归测试，并非只是由评价人员实施； 

软件测试总结

• 测试应当分级别；
• 测试应当有重点；
• 测试应当尽早、频繁和全面的进行；
• 测试是开发的朋友，不是开发的敌人；
• 测试人员应当客观公正的记录和报告缺陷；
• 测试自动化能解决一部分问题，但不是全部；
• 测试是个持续进行的过程，而不是一个阶段；
• 测试必须被计划、被控制，并且提供时间和资源；
• 测试应当在测试成本和软件质量效益间找到一个平衡点；
• 测试不是为了证明程序的正确性，而是为了证明程序有问题；
• 测试是不可能穷尽的，当测试出口条件满足时就可停止测试；
• 测试不仅包含功能性的验证，还应包含性能性、可靠性，安全性等方面的验证。