软件测试知识点

题型

10个选择

4-5个解答

3-4个设计

•第一章 软件测试概述

•软件 = 程序 + 数据 + 文档

软件的特点：

软件是一种逻辑体，而不是具体的物理体，因而它具有抽象性

对软件质量的控制， 必须在开发方面下功夫。 必须进行多次的修改和维护。

软件移植问题。复杂的。昂贵。

定义：使用人工或自动化手段，来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果 之间的差别

目的：发现\修改缺陷,提高用户的满意程度，优化软件品质

软件缺陷：

从产品内部看：软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；

从产品外部看：软件缺陷是系统所需要实现的某种功能的失效或违背。

软件测试只能证明软件存在错误，但不能证明软件没有错误。

(测试用例（Test Case）是为某个特殊目标而编制的一组测试，输入、执行条件以及预期结果。测试用例是执行测试的最小实体)

软件测试分类：静态测试（特点：不必运行程序，发挥人的逻辑思维优势，无需条件，易展开）（代码审查，代码检查，桌面检查 ，静态分析，数据流、控制流、接口分析、表达式分析）

动态测试（特点：要求在代码实现的前提下进行，运行被测试的程序，要进行测试数据准备）（黑盒测试，白盒测试，灰盒测试）

（软件测试的原则：

1、尽早地和及时地测试

2、测试前应当准备好测试数据和与之对应的预期结果这两部分

3、测试输入数据应包括合理的输入条件和不合理输入条件

4、程序提交测试后，应当由专门的测试人员进行测试

5、严格执行测试计划，排除测试的随意性

6、应对每一个测试结果做全面的检查

7、充分注意测试当中的群体现象

8、保存测试计划、测试用例、出错统计和最终分析报告，为维护工作提供充分的资料）

评审：管理评审，流程评审，技术评审，文档评审

需求验证

目标：需求验证的目标是尽可能发现存在的错误，以减少 因为需求错误而带来的工作量问题。

方法：

正式 不正式

审查 小组审查 走查 结对编程 同级轮查 临时评审

过程

•第二章 黑盒测试

定义：在测试时，把被测程序视为一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下进行。

优点

（1）有针对性地寻找问题，并且定位问题更准确。 （2）黑盒测试可以证明产品是否达到用户要求的功能，符合用户的工作要求。 （3）能重复执行相同的动作，测试工作中最枯燥的部分可交由机器完成。

缺点

（1）需要充分了解产品用到的技术，测试人员需要具有较多经验。 （2）在测试过程中很多是手工测试操作。 （3）测试人员要负责大量文档、报表的编制和整理工作。

● 静态黑盒测试方法：文档测试，特别是产品需求文档、用户手册、帮助文件等的审查。

● 动态黑盒测试方法：通过数据输入并运行程序来检验输出结果，如功能测试、验收测试和一些性能测试等。

•等价类划分

把所有可能的输入数据(有效的和无效的)划分成若干个等价的子集(称为等价类)，使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同。

有效等价类

对于程序的需求规格说明书来说是合理的、有意义的输入数据组成的集合。

无效等价类

与有效等价类正好相反，无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。

划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并集是整个集合（完备性）

等价类六个划分原则

●按区间划分：在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。

●按数值集合划分：在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类；

●在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。

●按数值划分：在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。

●按限制条件或规则划分：在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

●细分等价类：在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

设计用例三个划分原则

为每一个等价类规定一个唯一的编号

设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止。

设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止

•边界值分析

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

做小题

最小值

略大于最小值

值域内任意值

最大值

略小于最大值

每次保留程序中一个变量，让其余的变量取正常值，被保留的变量依次取min、min+、nom、max-和max。

常见的边界值

1)对16-bit 的整数而言 -32768 和 32767是边界

2）报表的第一行和最后一行

3)数组元素的第一个和最后一个

4)循环的第 0 次、第 1 次和倒数第 2 次、最后一次

做大题边界值分析原则：

（1）如果条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。

（2）如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1，比最大个数多1的数作为测试数据。

（3）规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。

（4）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例

（5）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例

（6）分析规格说明,找出其它可能的边界条件

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

健壮性测试是作为边界值分析的一个简单的扩充，它除了对变量的5个边界值分析取值外，还需要增加一个略大于最大值(max+)以及略小于最小值(min-)（大题建议加上）会产生6n+1个测试用例。

•决策表法（判断表驱动法）

最为严格、最具有逻辑性的测试方法。

概念：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

适用于：在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，输入输出比较多，输入之间和输出之间相互制约的条件比较多。

•条件桩：列出了问题的所有条件，通常认为列出的条件的次序无关紧要

•动作桩：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束

•条件项：列出针对它所列条件的取值，在所有可能情况下的真假值

•动作项：列出条件项的各种取值情况下应该采取的动作

规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则

步骤：

•1. 确定规则的个数。

–有n个条件的判定表有2n个规则（每个条件取真、假值）

•2. 列出所有的条件桩和动作桩。

•3. 填入条件项。

•4. 填入动作项，得到初始判定表

•5. 简化决策表，合并相似规则

–若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并。

–合并后的条件项用符号“-”表示，说明执行的动作与该条件的取值无关，称为无关条件。

从最后一行一Y一N到两Y两N到4Y4N循环

优点：能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。

缺点：不能表达重复执行的动作，例如循环结构。

•因果图

定义：一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法。

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

最终生成的还是判定表

步骤：

（1）分析软件规格说明中哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。 （2）分析软件规格说明中的语义，找出原因与结果之间、原因与原因之间对应的关系， 根据这些关系画出因果图。 （3）由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。 （4）把因果图转换为决策表。 （5）根据决策表中的每一列设计测试用例

四种因果关系符号

恒等：若 c1 是1，则 e1 也为1，否则 e1 为0

非：若 c1 是1，则 e1 为0，否则e1为1

或：若 c1 或 c2 或 c3 是1，则 e1 为1，否则 e1 为0

与：若 c1 和 c2 都是1，则 e1 为1，否则 e1 为0

约束：

E约束(互斥)：原因a和原因b中最多有一个可能成立，即a和b不会同时成立。 I约束(包含)：a、b、c这三个原因中至少有一个必须成立。 O约束(唯一)：原因a和b中必须有一个，且仅有一个成立。 R约束(要求)：原因a出现时，原因b也必须出现，a出现时，不可能b不出现。 M约束(强制)：若结果a为1，则结果b强制为0。当a为0，b的值不确定

优点：

（1）考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系。 （2）能够帮助测试人员按照一定的步骤，高效率的开发测试用例。 （3）因果图法是将自然语言规格说明转化成形式语言规格说明的一种严格的方法，可以指出规格说明存在的不完整性和二义性。

缺点：测试用例数目可能会很大，不便于维护

•错误推测法

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

•正交试验法

定义：正交实验设计方法是依据Galois理论,从大量的（实验）数据（测试例）中挑选适量的、有代表性的点（例）,从而合理地安排实验（测试）的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等

步骤

1. 提取功能说明，构造因子—状态表

2. 加权筛选，生成因素分析表

3. 利用正交表构造测试数据集，正交表的推导依据Galois理论

4. 利用正交表每行数据构造测试用例

因子：影响实验指标的条件称为因子。水平，因子的取值。

在行数为mn型的正交表中（m,n是正整数），

试验次数（行数）=∑（每列水平数-1）+1=因子数*（水平数-1）+1 = 试验次数

L8 （2）77表示此表列的数目（最多可安排的因子数），2为因子的水平数，8为此表行的数目（试验次数）

•场景法

定义：现在的软件都是用事件来触发流程的，事件触发时的情景并成了场景，而同一事件不同的触发顺序和处理结果就形成事件流

步骤：

1.设计用例流

2.场景设计

3.创建场景用例表

3.建立测试数据表

测试方法选择的综合策略

1. 首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法

2. 在任何情况下，都必须使用边界值分析法，经验表明，用这种方法设计出的用例，发现程序错误的能力最强

3. 可以用错误推测法追加一些用例，这需要依靠测试工程师的经验

4. 对照程序逻辑，检查出已设计出的测试用例的逻辑覆盖程度，如果没有足够覆盖，应当再补充足够的测试用例

5. 如果程序说明中有输入条件的组合情况，则一开始就可以选用因果图或判定表驱动法设计测试用例

6. 对于参数配置类型的软件，要用正交试验法选择较少的组合方式，达到最佳效果

7. 对于业务流清晰的系统，可利用场景法贯穿整个测试案例过程，在案例中综合使用各种设计方法

•第三章 白盒测试

定义：基于系统或者组件的内部实现结构和逻辑寻找缺陷的测试技术

原则：

保证一个模块中的所有独立路径至少被测试一次。 所有逻辑值均需测试真 (true) 和假 (false) 两种情况。 检查程序的内部数据结构，保证其结构的有效性。 在上下边界及可操作范围内运行所有循环。

基本路径法

根据程序的控制流图找出一个模块所需测试的基本路径，根据这些基本路径设计构造相应的测试用例.

步骤

1.根据模块逻辑构造控制流图（Flow Graph）（控制流图是由节点和边组成的有向图） 2.计算控制流图的环复杂度 (Cyclomatic Complexity)

用V（G）表示

3.列出包含起始节点和终止节点的基本路径

基本路径：

1.是一条从起始节点到终止节点的路径. ​ 2.至少包含一条其它基本路径没有包含的边.

3.对于循环而言，基本路径应包含不执行循环和执行一次循环体。

4.检查一下列出的基本路径数目是否超过控制流图的环复杂度 5.设计覆盖这些基本路径的测试用例

逻辑覆盖法

语句覆盖：使得程序中的每个可执行语句至少执行一次。

判断覆盖：使得程序中的每个判定至少都获得一次“真”值和“假”值，

条件覆盖：使得程序中每个判定包含的每个条件的可能取值（真/假）都至少满足一次

判定/条件覆盖：使得程序中每个判定包含的每个条件的所有情况（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。

组合覆盖：使得程序中每个判定的所有可能的条件取值组合都至少出现一次。

路径覆盖：要求覆盖程序中所有可能的路径。

 

测试覆盖准则：

[规则1] 对于A rel B型 (rel可以是<、= 或 >) 的分支谓词，应适当的选择A与B的值，使得测试执行到该分支语句时，A<B、A=B、A>B的情况分别出现一次。

[规则2] 对于A rel C型 (rel可以是>或<, A是变量，C是常量)的分支谓词：当rel为<时，应适当的选择A的值，使A=C-M （M是距C最小的机器容许正数，若A和C都为正整数时，M=1）；当rel为>时，应适当的选择A的值，使A=C+M。

[规则3] 对外部输入变量赋值，使其在每一个测试用例中均有不同的值与符号，并与同一组测试用例中其他变量的值与符号不同。

循环测试

循环类型：

1.简单循环

直接跳过循环体 只执行一遍循环体 连续执行两遍循环体 如果循环次数为n，执行m（ m < n）遍循环体 如果循环次数为n，那么执行n -1遍循环体 如果循环次数为n，那么执行n遍循环体 如果循环次数为n，那么执行n + 1遍循环体

2.嵌套循环

从最内层测试开始，其它层的循环变量置为最小值 按照简单循环的测试方法测试最内层的循环体，外层循环仍旧取最小值 向外扩展循环体，测试下一个循环 所有外层循环变量取最小值 其余内层嵌套的循环体取典型值 继续本步骤直到所有的循环体均测试完毕

3.连接循环

如果相连接的循环体互相独立，按照简单循环测试每一个循环体 如果相连接的循环体1的循环变量的最终结果是循环体2循环变量的初始值，那么采用嵌套循环的方法来测试(靠前认为是内层循环）

4.非结构循环

重新设计循环结构

数据流测试

变量的定义节点 如果程序中某一语句i的执行能改变某程序变量V的值，则称V被语句i定义,可记作Def（V，i）。

变量的使用节点 如果某一语句j的执行引用了内存中变量V的值，则称变量V被语句j使用，可记作Use（V,j）

示例

fooA() { 1x = read(); 2if (x > 0) 3 print x-1; 4 else 5 print x; }

指出变量X的定义节点、使用节点和定义-使用路径 定义节点：Def(x,1) 使用节点：USE(x,2), USE(x,3), USE(x,4) 定义-使用路径：1，2； 1，2，3； 1，2，4

程序插桩

通过在源代码中加入记录信息语句，以便进行运行信息的追踪和调试，统计有关的运行资源状况。

如print语句（最简单的插桩） 插桩技术是实现各种覆盖测试的必要手段。

最少测试用例数计算

 

N-S图

•第四章 单元测试

定义：是对软件基本组成单元进行的测试。是检验程序最小单位，即检查模块有无错误，它是在编码完成后必须进行的测试工作。

作用：编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码。

主要任务：

模块接口（对模块接口进行测试，检查进出程序单元的数据流是否正确。须在其它测试之前进行）

局部数据结构（测试模块内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。）

边界条件（采用边界值分析方法设计测试用例，重点关注程序边界处。）

独立的路径(针对程序路径进行测试，尤为重要。重点关注由于计算错误、不正确的判定或不正常的控制流而产生的错误)

错误处理。（重点关注模块在工作中发生错误时，出错处理设施是否有效。）

步骤：

执行单元测试的一般步骤为编译运行程序→静态测试→动态测试

辅助测试模块

驱动模块：用来模拟被测试模块的上一级模块，相当于被测模块的主程序。

桩模块：用来模拟被测模块工作过程中所调用的模块。

•第五章 集成测试

概念：集成测试又称组装测试，是在单元测试的基础上，将所有模块按照设计要求组装成子系统或系统进行的测试活动。又称子系统测试、联合测试。

目的：确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确，所测试的内容包括单元间的接口以及集成后的功能。

集成测试有以下不可替代的特点： 单元测试具有不彻底性，对于模块间接口信息内容的正确性、相互调用关系是否符合设计无能为力。只能靠集成测试来进行保障。 同系统测试相比，由于集成测试用例是从程序结构出发的，目的性、针对性更强，测试项发现问题的效率更高，定位问题的效率也较高； 能够较容易地测试到系统测试用例难以模拟的特殊异常流程，从纯理论的角度来讲，集成测试能够模拟所有实际情况； 定位问题较快，由于集成测试具有可重复强、对测试人员透明的特点，发现问题后容易定位，所以能够有效地加快进度，减少隐患。

层次：

（1）模块内集成测试。 （2）子系统内集成测试：先测试子系统内的功能模块，然后将各个功能模块组合起来确认子系统的功能是否达到预期要求。 （3）子系统间集成测试：测试的单元是子系统之间的接口。子系统是可单独运行的程序或进程。

静态测试技术——针对概要设计的测试

动态测试技术——灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

灰盒测试的优点： 能够进行基于需求的测试和基于路径的覆盖测试。 可深入被测对象的内部，便于错误的识别分析和解决。 能够保证设计的黑盒测试用例的完整性，防止功能或功能组合的遗漏 能够减小需求或设计不详细或不完整性对测试有效性造成影响。

集成测试策略：

1.非增量式集成策略——一步到位（大爆炸式集成）

对所有模块进行个别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。

适用于： 一个维护型或被测试系统较小的项目

优点：

①方法简单 ②允许多测试人员同时并行工作，人力物力资源利用率较高

缺点： ①必须为每个模块准备相应的驱动模块和桩模块，测试成本较高 ②一旦集成后包含多种错误，难以纠正

2.增量式集成策略——逐步实现

逐次将未曾集成测试的模块和已经集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。

（1）自顶向下增量式测试

深度优先：首先集成在结构中的一个主控路径下的所有模块，主控路径的选择是任意的。

广度优先：首先沿着水平方向，把每一层中所有直接隶属于上一层的模块集成起来，直到底层。

步骤：

（1）主控模块作为测试驱动器。

（2）根据集成的方式（深度或广度），下层的桩模块一次一次地被替换为真正的模块。 （3）在每个模块被集成时，都必须进行单元测试。重复第2步，直到整个系统被测试完成

优点：

较早地验证了主要控制和判断点； ​ 按深度优先可以首先实现和验证一个完整的软件功能； ​ 功能较早证实，带来信心； ​ 只需一个驱动，减少驱动器开发的费用； ​ 支持故障隔离。

缺点：

桩的开发量大； ​ 底层验证被推迟； ​ 底层组件测试不充分。

（2）自底向上增量式测试

步骤：

（1）起始于模块依赖关系树的底层叶子模块，也可以把两个或多个叶子模块合并到一起进行测试 ​ （2）使用驱动模块对步骤１选定的模块（或模块组）进行测试 ​ （3）用实际模块代替驱动模块，与它已测试的直属子模块组装成一个更大的模块进行测试 ​ （4）重复上面的行为，直到系统最顶层模块被加入到已测系统中

优点： ​ 对底层组件行为较早验证； ​ 工作最初可以并行集成，比自顶向下效率高； ​ 减少了桩的工作量； ​ 能较好锁定软件故障所在位置。

缺点：

驱动的开发工作量大；

对高层的验证被推迟，设计上的错误不能被及时发现。

适用范围：

适应于底层接口比较稳定； ​ 高层接口变化比较频繁； ​ 底层组件较早被完成。

（3）三明治增量式测试（混合增量式测试）

优点： ​ 集合了自顶向下和自底向上两种策略的优点 ​ 缺点： ​ 中间层测试不充分 ​ 适用范围： ​ 适应于大部分软件开发项目

改进后的三明治集成方法（改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得比较彻底 。）

不同集成策略比较

非增量式测试与增量式测试的比较 非增量式测试的方法是先分散测试，然后集中起来再一次完成集成测试。假如在模块的接口处存在错误，只会在最后的集成测试时一下子暴露出来。 增量式测试是逐步集成和逐步测试的方法，把可能出现的差错分散暴露出来，便于找出问题和修改。而且一些模块在逐步集成的测试中，得到了较多次的考验，因此，可能会取得较好的测试效果。增量式测试要比非增量式测试具有一定的优越性

自顶向下与自底向上增量式测试的比较 自顶向下增量式测试： ——主要优点在于它可以自然的做到逐步求精，一开始就能让测试者看到系统的框架。 ——主要缺点是需要提供桩模块，并且在输入/输出模块接入系统以前，在桩模块中表示测试数据有一定困难。 自底向上增量式测试： ——优点在于，由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也无困难。 ——主要缺点在于，直到最后一个模块被加进去之后才能看到整个程序（系统）的框架。

参与集成测试的人员：

系统设计人员，软件测试部，开发人员

集成测试流程

 

•第六章 系统测试

概念

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

目的

通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方；

层次

用户层测试

用户支持测试

用户界面测试 ​ 安全性测试 ​ 可维护测试

应用层测试

系统性能 ​ 系统可靠性、稳定性 ​ 版本兼容性 ​ 系统安装升级

功能层测试

指标/协议层测试

 

策略

1.功能测试（是系统测试中最基本的测试，不管软件内部的实现逻辑。主要根据产品的需求规格说明书和测试需求列表验证产品的功能实现是否符合产品的需求规格）

逻辑功能测试（logic function testing） 界面测试（UI testing） 易用性测试（usability testing） 安装测试（installation testing） 兼容性测试（compatibility testing）

2.性能测试（性能测试是用来保证系统发布后，产品的性能满足用户要求。性能测试在软件质量保证中起重要作用。）

一般性能测试（指让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。） 稳定性测试（连续运行被测系统，检查系统运行时的稳定程度。） 负载测试（让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。） 压力测试（通常持续不断地给被测系统增加压力，直到被测系统压垮为止，来测试系统所能承受的最大压力。）

3.软件性能指标

响应时间，并发用户数，吞吐量，资源占用率

4.验收测试

α测试：由用户在开发环境下进行的测试

β测试：由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。

步骤