软件测试

填空题

名词解释

• 变异测试 P67
• 软件质量保证SQA P13
• 集成测试的定义 P143

简答题

• 黑盒、白盒测试有哪些
• 4个软件测试层次 P33
• V模型 P15 / W模型 P77
• 软件测试的分类P26
• 敏捷测试原则和特征(传统测试和敏捷测试的区别) P81
• 两种集成方法的比较 P145

综合题

• 场景测试
• 基本路径覆盖
  • 给流程图画控制流图

软件测试基本概念

一。中英对照

• 测试用例(TC)： Test Case
• 软件测试：Software Test
• 软件质量保证： SQA
• 测试驱动开发： TDD
• 软件调试： Debugging
• 最小化修复量： Minimal Fixing

二。定义

1.软件测试

​ 软件测试就是按照测试方案喝流程对产品进行功能性和非功能性测试。甚至根据需求，编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。

非功能性测试

• 安全性
• 性能
• 兼容性

正向思维软件测试(验证软件是否正常工作) p11

• 评价一个程序或系统的特性或能力并确定是否达到预期结果
  • 在设计规定的环境下运行软件的所有功能，直至全通过

逆向思维软件测试(假定有错)

• 测试是为了发现错误而针对某个程序或系统的执行过程
  • 寻找容易犯错误的地方和系统的薄弱环节，试图破坏系统直至找不出问题

2.测试用例

​ 测试执行之前设计的一套详细的测试方案。包括测试环境、测试步骤、测试数据和预期结果

• 测试用例 = 输入 + 输入出 + 测试环境
  • 测试环境 = 硬件 + 软件 + 网络

3.软件质量保证（SQA) p13

​ 软件质量保证活动是通过对软件产品有计划地进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获得有用信息，形成分析结果以知道软件过程

4.测试驱动开发(TDD) p15

​ 测试在前、编码在后的开发发放。在编程之前先写测试脚本或设计测试用例。

5.V模型

测试和开发时并行、协作的关系

6.软件缺陷

​ 任何程序、系统中的问题和产品设计书中的不一致，不能满足用户的需求都叫做软件缺陷。

fault

• 静态(客观存在的)存在于代码中的缺陷

error

• 执行到代码缺陷时，产生的一个错误的中间状态

failure(失效)

• 错误的中间状态由程序传播出去，被测试人员或用户观测到的运行结果

7.产品质量模型 p20

缺陷是质量的对立面

• 功能适应性(Funcitonal Suitability)
• 效率(Efficiency)
• 兼容性(Compatibility)
• 易用性(Usability)
• 可靠性(Reliability)
• 安全性(Security)
• 可维护性(Maintainability)
• 可移植性(Portability)

8.软件测试的分类 P26

1.按测试层次分类

2.按测试目的分类

3.按测试方法或测试方式分类

9.静态测试和动态测试 P28

静态测试

• 不执行程序，而是通过人工评审、代码扫描、静态分析发现错误
• 包括对软件产品的需求和设计规格说明书的评审、对程序代码的审查和静态分析等。

动态测试

• 通过运行程序发现错误
• 通过观察代码运行过程，获取系统行为、变量实时结果、内存、堆栈、线程和测试覆盖度等各方面的信息，以判断系统是否存在问题。

产品评审 P28

目的

• 通过软件评审尽早发现产品中的缺陷

定义

• 评审是对软件元素或项目状态的一种评估手动，以确定其是否与计划的结果保持一致，并使其得到改进

形式：

1)互为评审

• 同行评审

2)走查

• 由他人从头到尾进行检测

3)会议评审

• 最正式的一种集体检查

10.主动测试和被动测试 P30

主动测试

• 测试人员主动向被测对象发送请求或借助数据、事件驱动被测对象的行为，从而验证被测试对象的反应或输出结果
  • 比较常见的方法
  • 不适应于产品在线测试

被动测试

• 测试人员不干预产品的运行，而是被动地监控产品的运行，通过一定的被动机制来获得系统运行的数据，包括输入、输出数据
  • 适合性能测试和在线监控

11.黑盒测试和白盒测试 P31

白盒测试

• 也称为结构化测试或逻辑驱动测试
• 已知产品的内部工作过程，清楚最终生成软件产品的计算机程序结构及其语句，按照程序内部的结构测试程序，测试程序内部的变量状态，逻辑结构、运行路径等，检验程序中的每条通路是否都能按预定要求正确工作，检查程序内部动作或运行是否符合设计规格要求，所有内部成分是否按规定正常进行

黑盒测试

• 数据驱动测试方法或基于需求规格的测试。
• 测试时，把程序看作一个不能打开的黑盒子
• 在完全不考虑程序内部结构和内部特性的情况下，测试人员针对软件直接进行测试，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当地接收输入数据而输出正常结果等，
• 检查相应文档是否采用了正确的模板、是否满足规范要求

	白盒	黑盒
静态测试	静态-白盒测试方法(对源程序代码的语法检查、扫描、评审等)	静态-黑盒测试方法(对需求文档、需求规格说明书的审查获得，一些非技术性文档测试等)
动态测试	**动态-白盒测试方法(**在单元测试中，一边运行代码，一边对结果进行检查、验证和调试等)	动态-黑盒测试方法(在运行程序时，通过数据驱动对软件进行功能测试，从用户角度验证软件的各项功能)

12.软件测试层次 P33

考定义和V模型

1）单元测试

• 单元测试是在编码阶段针对每个程序单元进行的测试，测试对象是程序系统中最小单元(类、函数、模块、组件)

• 单元测试主要使用白盒测试方法，从程序的内部结构出发设计测试用例

• 单元测试是测试执行的开始阶段

2）面向接口的集成测试

• 是在单元测试的基础上，按设计要求不断进行集成而进行的相应测试
• 目的是发现单元之间的接口问题
  • 如接口参数类型不匹配
  • 接口数据在传输中丢失
  • 数据误差不断积累
• 分为一次性集成方式和渐增式集成方式
  • 一半要求采用渐增式集成方式

3）系统测试

• 在集成测试完成之后，针对应用系统进行测试
• 包括系统功能性测试和非功能性测试
  • 非功能性测试包括(负载测试、性能测试、灾难恢复性测试、安全测试和可靠性测试)

4）面向业务的验收测试

• 目的式向业务用户表明系统能够像预定要求那样工作，验证软件的功能和性能及其特性是否与用户的要求一致
• 分为Alpha测试和Beta测试
  • Alpha测试是软件开发公司内部人员开始使用新产品
  • 经过Alpha测试和修正的软件产品成为Beta版本。

软件测试方法

软件测试基本要求

全覆盖，无冗余

中英对应

Ad-hoc测试方法：自由测试

ALAC测试方法: 像客户那样做

Pareto 80/20: 2/8定律

基于缺陷模式的测试： DPBT(Defect-Pattern-Based Testing)

基于模型的测试：MBT(Model-Based Testing)

---

黑盒测试

一。基于输入域的方法 P45

1.等价类划分法

等价类基本原理：分而不交，合而不变，类内等价

基本思想：用一组有限的数据去代表近似无限的数据

1）等价类测试分类

• 弱一般等价类测试
• 强一般等价类测试
• 弱健壮等价类测试
• 强健壮等价类测试

2）有效等价类和无效等价类

有效等价类

• 输入完全满足程序输入的规格说明、有意义的输入数据所构成的集合
• 利用有效等价类可以检验程序是否满足规格说明所规定的功能和性能

无效等价类

• 不满足程序输入要求或者无效的输入数据构成的集合
• 使用无效等价类可以测试程序/系统的容错性——对异常输入情况的出了

2.边界值分析法(BVA)

1）边界值

有效边界值

• min
• min+
• norm
• max-
• max

无效边界值

• min-
• max+

2）边界值测试数量

1.边界值分析

• 只测有效区

$$
4n+1
$$

2.健壮性测试

• 有效 + 无效
  $$
  6n + 1
  $$

3.最坏情况
$$
5^n
$$

4.健壮最坏情况
$$
7^n
$$

二。基于组合及优化的方法 P49

适用于多因素或多变量的输入情况

1.判定表法

条件桩：

• 列出问题的所有条件

动作桩

• 列出可能针对问题所采取的操作

条件项：

• 针对所列条件的具体赋值，即每个条件可以取真值或假值

动作项：

• 列出在条件项组合情况下应该采取的动作
  • 根据条件项和规则而变

规则：

• 任何一个条件组合的特定取值及其相应要执行的操作

条件桩	条件项
动作桩	动作项

2.因果图法

3.Pairwise方法(两两组合)

:star:4.正交实验法

因子：

• 影响测试结果的条件因素称为因子

水平数：

• 各个因子的取值作为状态，状态数称为水平数

设计测试用例的步骤

白盒测试

一。基于逻辑覆盖的方法 P55

1.语句覆盖(最弱白盒测试)

根据每个可执行语句是否被执行，选足够多测试用例使每一条语句都要被测试覆盖(100%覆盖)

2.判定覆盖(DC)

基本思想：设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。

3.条件覆盖

设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次（让每个条件都能取真或者假）

4.判定-条件覆盖

判定覆盖和条件覆盖设计方法的交集。

设计足够的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次

5.条件组合覆盖

设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次

:star:6.基本路径覆盖 P60

设计所有的测试用例，来覆盖程序中的所有可能的、独立的执行路径

判定结点：

• 该结点有两条及以上路径可走

圈复杂度：

• 代码逻辑复杂度的度量，复杂度越高，出错概率越高。

其他

一。基于缺陷模型的测试(DPBT)

软件缺陷：

• 过去测试人员犯的错误

缺陷模式

• 对过去发现的各种具体缺陷进行归纳整理，抽象出共性，生成缺陷模式，基于这种模式来预防问题

在软件测试中，知道其缺陷模式，就可以根据缺陷模型来匹配，发现类似问题

二。基于模型的测试(MBT)

模型是对系统的抽象，是对被测系统预期行为动作的抽象描述，实际上就是用语言把一个系统的行为描述出来，定义系统的各种状态及其之间的转换关系。

常见的MBT方法

:star:三。基于场景的测试用例

测试用例 = 用户行为 + 场景 + 测试数据

场景的定义

基本流和备选流

基本流和备选流的识别原则

:star:四。变异测试(Mutation Testing)

变异测试是一种在细节方面改进程序源码的软件测试方法

软件测试流程和规范

W模型 P77

对V模型进行的改进。由两个V字模型组成，分别代表测试于开发过程

W模型增加了软件各开发阶段中应同步进行的验证和确认工作

1）测试过程和开发过程是同时开始、同时结束、两者保持同步的关系

2）测试过程是对开发过程中阶段性成果和最终的产品进行验证的过程，所有两者是相互依赖的。

• 前期，测试过程更多依赖于开发过程
• 后期，开发过程更多依赖于测试过程

3）测试过程中的工作重点和开发工作的重点可能是不一样的，两者有各自的特点。

• 资源管理、风险管理方面不同

TMAP 测试管理方法

一种业务驱动的、基于风险策略的、结构化的测试方法体系

目的：

• 更早发现缺陷，以最小的成本，有效地，彻底地完成测试任务，以减少软件发布后的支持成本

:star:敏捷测试过程 P81

:star:敏捷测试原则

1. 尽早和持续地开展测试
2. 基于风险的测试策略是必需的
3. 测试计划、设计和执行力求简单
4. 能及时完成对软件质量全面评估
5. 软件本身是测试研究和分析最主要的对象
6. 在满足所要求的质量前提下，测试进行得越快越好
7. 对测试技术精益求精
8. 不断反思，持续优化测试流程与设计

:star:传统测试和敏捷测试的区别

敏捷测试具有鲜明的敏捷开发的特征

比如测试驱动开发(TDD)和验收测试驱动开发(ATDD)

1. 传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚

   敏捷测试可以没有“测试人员”角色，强调整个团队对测试赋值

2. 传统测试具有明显的阶段性

   敏捷开发更强调持续测试、持续的质量反馈，没有明确的阶段性界限

3. 传统测试强调测试的计划性

   敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的编号

4. 传统测试强调测试是由“验证”和“确认”两种获得构成的。

   敏捷测试始终以用户需求未中心，不离用户需求，将验证和确认统一起来

5. 传统测试关注测试文档，包括测试计划、测试用例、缺陷报告和测试报告等。

   敏捷测试更关注产品本身，关注可以交付的客户价值。强调面对面的沟通、协作，强调支持质量反馈、缺陷预防

6. 传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响。

   敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。

单元测试和集成测试

驱动程序和桩程序 P124

运行被测试单元，为了隔离单元，根据被测试单元的接口，开发相应的驱动程序(Driver)和桩程序(Stub)

驱动程序(Driver)

​ 用于模拟被测模块的上级模块，能够调用被测模块。在测试过程中，驱动模块接收测试数据，调用被测模块并将相关的数据传送给被测模块。

桩程序(Stub)

​ 用以模拟被测模块工作过程中所调用的下层模块。桩模块由被测模块调用，一般只进行很少的数据处理。

系统集成的模式与方法

集成测试(Integration Test)的定义 P143

​ 将已分别通过测试的单元按设计要求集成起来再进行的测试，以检查这些单元之间的接口是否存在问题。包括接口参数的一致性引用、业务流程端到端的正确性等。

​ 集成测试是指根据实际情况对程序中已通过单元测试的单元采用适当的集成策略组装起来，检查各个单元之间的接口以及集成之后的功能是否正确；

单体架构的集成参数 P144

1）非渐增式测试模式

​ 先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式

• 容易出现混乱

2）渐增式测试模式(一般采用)

​ 把下一个要测试的模块同已经测试好的模块结合起来测试。测试是在模块一个一个的扩展下进行，其测试的范围逐渐增大。

1.自顶向下法(Top-down Integration)

• 从主控模块(主程序)开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。
  • 可以使用深度优先的策略或者宽度优先的策略

优点

• 不需要测试驱动程序
• 能够在测试阶段的早期实现并验证系统的主要功能
• 在早期发现上层模块的接口错误

缺点

• 需要桩程序
• 可能遇到与此相联系的测试困难
• 底层关键模块中的错误发现较晚
• 早期不能充分展开人力

2.自底向上法(Bottom-up Integration)

• 从“原子”模块(软件结构最底层的模块)开始集成以进行测试

​

第六章 系统测试(System Test)

系统测试

系统测试分为功能性测试和非功能性测试

​ 软件测试针对被测试的、已集成的系统(System Under Test, SUT)来进行验证，如观察其的整体表现行为是否符合预期、是否满足用户需求。

回归测试 (Regression Test) P186

定义

​ 无论在进行系统测试还是功能测试时，当发现一些严重的缺陷需要修正时，会构造一个新的软件包(Full Build)或新的软件补丁包(Patch)，然后进行测试。

​ 这时的测试不仅要验证被修复的软件缺陷是否真正被解决了，而且要保证以前所有运行正常的功能依旧能保持正常，而不要收到这次修改的影响。

​ 虽然已发现的程序缺陷被修复了，但可能在其他受影响的区域出现新的软件缺陷(回归缺陷)，如果没有回归测试，就会造成严重后果

目的

​ 在程序有修改的情况下保证原有功能正常的一种测试策略和方法，这时测试不需要进行全面测试，而是根据修改的情况进行有效测试。

负载 (Workload) P194

系统负载模式

软件缺陷 P360

严重性和优先级

严重性

1.致命的(Fatal)

• 致命的错误，造成系统或应用程序崩溃(Crash)、死机、系统悬挂或数据丢失、主要功能完全丧失

2.严重的(Critical)

• 功能或特性(Feature)没有实现，主要功能部分丧失，次要功能完全丧失，致命的错误声明

3.一般的(Major)

• 不太严重的错误，虽然不影响系统的基本使用，但没有很好地实现功能，没有达到预期结果
  • 次要功能丧失，提示信息不太准确，用户界面差，操作时间长

4.微小的(Minor)

• 对功能几乎没有影响，产品及属性仍可使用
  • 个别错别字、文字排列不整齐

优先级

缺陷优先级	描述
立即解决 P1级	缺陷导致系统几乎不能使用或测试不能继续，需要立即修复
高优先级 P2级	缺陷严重，影响测试，需要优先考虑
正常排队 P3级	缺陷需要正常排队或等到修复
低优先级 P4级	缺陷可以在开发人员有时间的时候被纠正