软件测试复习概要

• 软件测试常用的概念，常用的分类，测试的目的，方法等
• 软件测试静态测试的概念，技术，分类，执行过程，涉及的活动，测试的对象等
• 软件测试的模型分类，个各模型的特点，适用场景，规划的阶段及其关系，表达的图形等
• 面向对象的软件测试概念，与软件开发以及普通测试的关系等
• 集成测试、系统测试的概念，划分的阶段，先后执行的顺序，输入、输出成果物等
• 黑盒测试、白盒测试的概念，常用的方法，测试用例的设计过程，以及执行的过程如何实施等
• 等价类划分、边界值测试、三明治集成测试等概念、用例设计、实施过程
• 因果图法的概念，用例设计，执行步骤等
• 基本路径测试法概念，用例设计过程，实施执行过程等（控制流图画法、环形复杂度计算、基本路径获取、用例设计及执行等）
• 单元测试的概念，主要任务，使用的方法等
• 软件测试与调试的区别与联系，软件缺陷的概念及其相关知识

1. 软件测试

1.1 软件测试概念

1. IEEE 在1983年将软件测试定义为“使用人工或者自动化手段运行或测定某个系统的过程，其目的在于检验他是否满足规定的需求或者是弄清预期结果与实际结果之间的差别“，该定义明确地提出了软件测试以检验是否为目标。
2. Myers则认为软件测试“是为了发现错误而执行的程序过程”，明确提出了“寻找错误”是测试目的。
3. 从软件质量保证的角度看，软件测试是一种重要的软件质量保证活动，其动机是通过一些经济、高效的方法，捕捉软件中的错误，从而达到保证软件内在质量的目的。

1.2. 软件测试目的

• 软件测试是为了发现错误而执行程序的过程
• 测试是为了证明程序有错，而不是证明程序无错
• 一个好的测试用例在于他能发现至今未发现的错误
• 一个成功的测试是发现了至今未发现的错误的测试

1.3. 软件测试技术分类

分类方法
从是否需要执行被测软件的角度	静态测试、动态测试
从软件测试用例实际方法	黑盒测试、白盒测试
按照软件测试的策略和过程	单元测试、集成测试、确认测试、系统测试、验收测试

2 静态测试

2.1. 静态测试概念

那些不利用计算机运行被测程序，而是通过其他手段达到测试目的的方法称作静态测试。换句话说，就是计算机并不真正运行被测试的程序，如在项目开发中存在着大量的规格说明，而说明规格是无法用计算机来运行的，所以对于这些软件的规格说明的测试就属于静态测试。

2.2. 静态测试主要方法

• 主要方法：代码检查、走查、桌面检查、同行评分

  • 代码检查: 所谓代码检查，是以组为单位阅读代码，他是一系列规则和错误检查技术的集合。对代码检查的大多数讨论都集中在规程、所要填写的表格等。这里对整个规程进行简短的概述。

    • 为代码检查分发材料、安排进程
    • 在代码检查中起主要作用
    • 记录发现的所有错误
    • 确保所有错误能够及时得到修正

  • 代码走查：代码走查与代码检查很相似，都是以小组我单位进行代码阅读，是一系列规程和错误检查技术的集合。代码走查的过程与代码检查大体相同，代码走查也是采用持续一至两个小时的不间断会议的形式。但是稍微所有不同，采用的错误检查技术也不一样。
    代码走查小组有3~5人组成，其中一个人扮演类似代码检查过程中“协调人员”的角色，一个人担任秘书（负责记录所有查出的错误），还有一个人担任测试人员。建议在代码走查小组这最好包括如下人员：
    （1）一位经验丰富的程序员；
    （2）一位程序设计语言专家；
    （3）一位初级程序员（可以给出新颖、不带偏见的观点）；
    （4）将要负责程序维护的人员
    （5）一位其他项目的人员
    （6）一位来自该软件编程小组的程序员

  • 桌面检查: 可以把桌面检查看作是由个人进行的代码检查或代码走查，即一个人阅读程序，对照错误列表检查程序，使用测试数据对程序进行推演。对于大多数人而言，桌面检查的效率是相当低的。其中的一个原因就是这个过程本身不受到任何约束。另外一个重要原因就是程序员常常不能够有效地测试自己编写的程序。因此最好由其他人而非该程序的编写人员进行桌面检查（例如可以让程序员之间相互交换各自编写的程序，避免自己对自己编写的程序进行桌面检查）。但是使用桌面检查的方法进行软件测试所得到的效果无法同代码走查或代码检查相比。代码检查和代码走查小组由多人组成，能够产生相互促进的效应。如果小组会议能够营造一种良性竞争的气氛，那么工作人员就能够乐于通过发现问题来展示自己的能力。而在桌面检查中，是无法做到这一点的。简而言之，桌面检查胜过没有检查，但测试效果远远不能同代码检查和代码走查相比。

  • 同行评分：虽然这种人工评审方法的目的是为了程序员提供一个自我评价的手段，与程序测试并无关系（其目标不是为了发现错误）。但是因为他与代码阅读的思想有关，是一种依据程序整体质量、可维护性、可扩展性、易用行和清晰性对匿名程序进行评价的技术。因此，有必要对其进行简单的了解。大致过程如下：首先挑选一位程序员担任评分过程的管理员，管理员再挑选出大约6~20名具备相似背景的参与者（例如，不同把Java应用程序员与汇编语言系统程序员编为一组）。每个参与者都提供两者由自己编写的程序以供评审，其中的一个程序是能代表参与者自身能力的最好作品，而另一个就是参与者认为质量较差的作品。

3. 软件测试与调试的区别与联系

白盒测试与调试的最终目的都是为了让被测应用(AUT)可以正常安全地运行，都是保证软件质量过程的一个环节。那么，白盒测试与调试有哪些不同呢？

从承担的任务来看，白盒测试同其他类型测试一样，他的任务是发现所开发的项目中的缺陷；但是，调试不属于测试，其任务是纠正软件中的缺陷。

从最终的结果来看，白盒测试有预知的结果，不可预知的知识程序是否通过测试，并且成功测试的结果是发现错误的症状，从而引起调试的进行；而调试的结果是消除项目中的错误。

从执行的过程来看，软件测试只是发现程序中有错误的迹象，没有错误定位，也不需要找到出错原因；软件调试是根据测试报告的记录，在软件测试后纠正错误的工作，包括确定错误位置和修改错误。测试是一个错误发现、改正错误、重新测试的过程；而调试是一个推理过程。

从准备工作来看，测试从已知的调试开始，使用预先定义的程序；调试是以不可知的内部条件开始，做统一性调试。

从执行的计划性来看，测试是有计划的并要进行测试设计；而调试则不受时间约束。

从测试的执行人员来看，测试经常是由独立的测试组在不了解软件设计的条件下完成的，而调试必须由程序员来完成。

测试的执行是有规程的，而调试的执行往往要求程序员进行必要推理以至知觉的“飞跃”。

从执行的人员来看，测试经常是由独立的测试组在不了解软件设计的条件下完成的，而调试必须由程序员来完成。

从所使用的工具来看，大多数白盒测试的执行和设计可由工具支持，而调试程序员能利用的工具主要是调试器。

4. 软件缺陷的概念

1. 软件没有实现产品的说明书所描述的功能。
2. 软件实现了产品说明书描述不应有的功能。
3. 软件执行了产品说明书没讲的操作。
4. 软件没有实现产品说明书没讲但应该实现的功能。
5. 从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。

5. 单元测试

5.1. 单元测试定义

单元测试是在软件开发过程中要进行的最低级别的测试活动，或者说是针对软件设计的最小单位—程序模块，进行正确性检查的测试工作。其目的在于发现每个程序模块内部可能存在的差错。在单元测试活动中，软件的独立单元在与程序的其他部分相隔离的情况下进行测试。

5.2. 单元测试主要任务

主要工作分为两个步骤：人工静态检查和动态执行跟踪。前者主要是保证代码算法的逻辑正确性（尽量通过人工检查发现代码的逻辑错误）、清晰性、规范性、一致性、算法高效性，并尽可能地发现程序程序中没有发现的错误。后者就是通过设计测试用例，执行待测程序来跟踪比较实际结果与预期结果来发现错误。

(1) 正确性是指代码逻辑必须正确，能够实现预期的功能
(2) 清晰性是指代码必须简明、易懂，注释准确没有歧义；
(3) 规范性是指代码必须符合企业或部门所定义的共同规范，包括命名规则，代码风格
(4) 一致性是指代码必须在命名上（如相同功能的变量尽量采用相同的标示符）、风格上都保持统一；
(5) 高效性是指代码不但要满足以上性质，而且需要尽可能降低代码的执行时间。

5.3. 单元测试使用方法

基于代码的白盒测试

6. 集成测试

6.1 集成测试定义

根据实际情况对成语模块采用适当的集成测试策略组装起来，对系统接口以及集成后的功能进行正确性检验的测试工作。

6.2 集成测试策略

6.2.1 三明治集成

(1) 目的：综合利用自顶向下和自底向上两种集成测试策略的优点
(2) 定义：三明治集成是一种混合增值式测试策略，综合了自顶向下和自顶向上两种集成方法的优点，因此也属于基于功能分解测试。

6.3 集成测试过程

7. 系统测试

7.1. 系统测试的定义

将已经集成好的软件系统，作为整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。

7.2. 集成测试过程

8. 软件测试模型

8.1. V模型

用户需求 验收测试
需求分析和系统设计 确认测试和系统测试
概要设计 集成测试
详细设计 单元测试
编码

经典的V模型阶段可以分为

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

模型特点：V模型的价值主要在于他非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间的对应关系:

• 单元测试的主要目的是根据详细设计说明书来验证和确认每个单元模块是否符合预期的要求，发现编码过程中可能存在的各种错误。
• 集成测试主要目的是根据概要设计来验证和确认各个模块是否已正确集成到一起，主要是检查各单元与其他模块之间的接口上可能存在的错误。
• 系统测试主要目的是根据需求定义，验证和确认系统作为一个整体是否能够正常有效地运行，例如，判断系统是否达到了用户预期的性能。

8.2. W模型

W模型中测试与开发对应关系如下：
开发：需求分析、概要设计、　　详细设计、　　编码、　　软件集成、系统集成、部署
　　　　　↑　　　　↑　　　　　　　↑　　　　　↑　　　　　　↑　　　　↑　　　↑

测试：需求评审、概要设计评审、详细设计评审、单元测试、集成测试、系统测试、验收测试

W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。 但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

8.3. H模型

在H模型中，软件测试的过程活动完全独立，形成了一个完全独立的流程，贯穿于整个产品的周期，与其他流程并发进行，某个测试点准备就绪后就可以从测试准备阶段进行到测试执行阶段；软件测试可以根据被测产品的不同分层进行。

H模型揭示了：
（1）软件测试不仅仅指测试的执行，还包括很多其他活动。
（2）软件测试是一个独立的流程，贯穿产品的整个开发周期，与其他流程并发进行。
（3）软件测试要尽早准备，尽早执行。
（4）软件测试根据被测物的不同是分层次的，不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。

9. 面向对象测试

9.1.1 面向对象测试基本概念

面向软件测试技术是新兴的软件测试技术，是专门针对使用面向对象技术开发的软件而提出的一种测试技术。其目的是为了解决传统的软件测试技术，面对面向对象技术开发的软件多少显得有些力不从心的现象。面向对象开发技术和传统的开发技术相比，新增了多态、继承、封装等特点。这些新特点使得开发出来的程序，具有更好的结构更规范的编程风格, 极大地优化了数据使用的安全性, 提高了代码的重用率。由此可见，它们是面向对象开发技术产生巨大吸引力的重要因素。然而，另一方面也影响了软件测试的方法和内容；增加了软件测试的难度；带来了传统软件设计技术所不存在的错误；或者使得传统软件测试中的重点不再显得突出；或者使原来测试经验认为和实践证明的次要方面成为了主要问题。

10. 黑白盒测试

10.1. 黑盒测试概念

黑盒测试也称作功能测试和行为测试，主要是根据功能需求来测试程序是否按照预期工作。黑盒测试的目的是尽量发现代码所表现的外部行为的错误，主要有以下几类：

（1）功能不正确或不完整；
（2）接口错误；
（3）接口所使用的数据结构错误；
（4）行为或性能错误；
（5）初始化和终止错误。

10.2. 黑盒测试用例设计

常用的黑盒测试用例设计方法主要有以下几中：等价类划分法、边界值分析法、因果图法、决策表法和错误推测法等方法。

10.2.1. 等价类划分法

等价类划分法是一种重要的、常用的黑盒测试方法，它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。

等价类划分法：是把所有可能的输入数据，即程序的输入域划分为若干部分（子集），然后从每一个子集中选取少数具有代表的数据作为测试用例。

等价类：指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，它们具有等价特性，即每一类的代表性数据在测试中的作用都等价于这一类中的其他数据。这样，对于表特征该类的数据输入将能代表这个子集合的输入。因此，可以合理地假定：测试某等价类的代表值等效于对于这类其他值的测试。

“保险公司绩保费费率的程序”例题见《软件测试技术》(第二版) P91。

10.2.2. 边界值分析法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为等价类划分方法的补充，在这个情况下，其测试用例来自等价类的边界。

边界值分析使用与等价类划分方法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。

例题：
$$有二元函数 f(x,y), 其中x\in[1,12],y\in[1,31];则采用边界值分析法设计的测试用例是:$$

            {<1,15>;<2,15>;<11,15>;<11,15>;<12,15>;<6,15>;<6,1>;<6,2>;<6,30>;<6,31>}

推论：对于一个含有n个变量的程序，采用边界值分析法测试程序会产生 4n+1 个测试用例.

10.2.3. 因果图法

一些程序的功能可以用判定表（或称决策表）的形式来表示，并根据输入条件的组合情况规定相应的操作。因果图法就是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

采用因果图法设计测试用例的步骤：

（1）列出模块的原因（输入条件）和效果（动作），且给每个原因和效果一个标识符；
（2）列出原因——效果图；
（3）由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定情况，在因果图上使用特殊的符号标明约束条件；
（4）把因果图转换成判定表；
（5）把判定表的每一列写成一个测试用例。

“因果图法” 例题见《软件测试技术》(第二版) P100。

10.2.4. 决策表法

在所有的黑盒测试中，机遇决策表（也称判定表）的测试是最为严格、最具有逻辑性的测试方法。

构造决策表的 4 个步骤：

（1）确定规则的个数，有 n 个条件的决策表有 2^n 个规则（每个条件取真、假值）；
（2）列出所有的条件桩和动作桩
（3）填入动作项，得到初始决策表；
（4）简化决策表，合并相似规则。

若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并。合并后的条件项用符号——表示，说明执行的动作与该条件的取值无关，称为无关条件。

“三角形问题决策表” 例题见《软件测试技术》（第二版）P102

10.2.5. 错误推测法

错误推测法的概念：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

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

10.3. 白盒测试概念

白盒测试就是一种用于检查代码是否按照预期工作的验证技术，又称结构测试、逻辑驱动测试或基于程序的测试。白盒测试的主要特点就是正对被测程序的源代码，测试者可能完全不考虑程序的功能。

10.4. 白盒测试用例设计

常用的白盒测试用例设计方法主要有以下几中：逻辑覆盖测试、边界值测试、基本路径测试、循环语句测试、程序插桩测试、数据流测试、变异测试。

10.4.1 逻辑覆盖测试

类型	定义
语句覆盖	程序中的每个可执行语句至少执行一次
判定覆盖	程序中每个判定的取真分支和取假分支的情况至少经历一次，即判断的真假值均曾被满足
条件覆盖	要使每个判断中每个条件的可能取值至少满足一次
判定-条件覆盖	使得判断中每个条件的所有可能至少出现一次，并且每个判断判定结果也至少出现一次
路径覆盖	测试用例覆盖程序中所有可能的路径

IF((A > 1) AND (B = 0) THEN
    X=X/A
IF((A = 2) OR (X > 1) THEN
    X=X+1

sta=>start: Start
cond1=>condition: (A>1) AND (B=0)
cond2=>condition: (A=2) OR (X>1)
io1=>operation: X=X/A
io2=>operation: X=X+1

e=>end: End

sta->cond1(yes)->io1->cond2(yes)->io2->e
sta->cond1(no,left)->cond2(no,left)->e

10.4.2. 边界值分析

等价类划分和边界值分析为软件测试提供了一种设计白盒测试用例的策略。

10.4.3. 基本路径测试

10.4.4 循环语句测试

10.4.5 插桩测试

10.4.6 数据流测试

10.4.7 变异测试