软件测试 复习

目录

第一章

1.3 软件测试是？

 .4 测试与质量保证

.5 与开发

 .6 测试驱动开发

第二章

2.1 软件质量

    软件缺陷

.2 软件测试分类

.3 动/静态

.4 主/被动

.5 黑/白盒

.6 层次 单元→集成→系统→验收

.7 测试工作

第三章

基于直觉/经验  Ad-hoc测试方法和ALAC测试 + 错误推测法

基于输入域

等价类划分方法

边界值分析方法：

基于组合及其优化

判定表方法

因果图

两两组合（Pairwise）方法

正交实验法

基于逻辑覆盖

第五章

5.4 单元测试

5.7 系统集成 (概念

第六章

6.1 功能测试

 .2 回归测试

第七章

7.1性能测试

.2 安全性测试

 .3兼容性测试

.4可靠性测试

---

教材：软件测试方法和技术 4th

第一章

1.3 软件测试是？

软件测试是由“验证（Verification）”和“有效性确认（Validation）”活动构成的整体

“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性

“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。

1、验证和确认实践中对应于评审和测试。

2、验证和确认的方法基本相同，但目的、对象、依据等有区别。

4、验证和确认的根本目的在于发现缺陷、确保正确性。

 .4 测试与质量保证

软件质量保证（Software Quality Assurance，SQA）活动是通过对软件产品有计划的进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获取有用信息，形成分析结果以指导软件过程。

联系：

1. SQA指导、监督软件测试的计划和执行，督促测试工作的结果客观、准确和有效，并协助测试流程的改进。
2. 软件测试是SQA重要手段之一，为SQA提供所需的数据，作为质量评价的客观依据。

不同：

SQA是一项管理工作，侧重于对流程的评审和监控。测试是一项技术性的工作，侧重对产品进行评估和验证

 .

.5 与开发

×传统瀑布模型 √ V模型

软件测试贯穿整个软件生命周期，从需求评审、设计评审开始，测试就介入软件产品的开发活动或软件项目实施中。软件测试与软件开发是一对一的关系，测试的工作是对开发成果的校验。测试和开发在整个软件开发生命周期中交互协作，一起致力于共同目标——按时、高质量地完成项目。

 .6 测试驱动开发

测试在前、编码在后：TDD测试驱动开发

第二章

软件质量与缺陷的辩证关系

缺陷是相对质量而存在的，违背了质量、违背了客户的意愿，不能满足客户的要求，就会引起缺陷或产生缺陷。缺陷是质量的对立面。

2.1 软件质量

含义：软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和

软件质量=（内部质量+外部质量） 产品质量 +使用质量

       三者关系 p20

产品质量八大特性：

1. 功能适应性：正确 完备 适合
2. 效率
3. 兼容性
4. 易用性 易学/操作 界面友好
5. 可靠性：MTT/BF 平均失效前/故障间隔时间
6. 安全性：保密 完整 抗抵赖 可审核
7. 可维护性： 模块化 复用 易分析/修改/测试
8. 可移植性： 适应 易安装/替换

使用质量= 功能、效率、安全性（功能特性）+ 信任、满意、远离风险、语境覆盖（非功能）

    软件缺陷

定义：软件缺陷是指计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误或者隐藏的功能缺陷、瑕疵，其结果会导致软件产品在某种程度上不能满足用户需求；

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

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

产生：① 技术问题

算法错误，语法错误，计算和精度问题，接口参数传递不匹配

②  团队工作

沟通不充分，误解

团队文化，对质量不够重视

与用户的沟通存在困难，对需求存在误解或理解不全面

③  软件本身

 文档错误、用户使用场合(user scenario)，

时间上不协调、或不一致性所带来的问题

系统的自我恢复或数据的异地备份、灾难性恢复等问题

软件缺陷的构成

.2 软件测试分类

按测试的对象或范围分类，如单元测试、文档测试、系统测试等

按测试目的分类，如功能测试、回归测试、性能测试、可靠性测试、安全性测试和兼容性测试等

根据测试过程中被测软件是否被执行，分为静态测试和动态测试

根据是否针对系统的内部结构和具体实现算法来完成测试，可分为白盒测试和黑盒测试

.3 动/静态

静态测试：包括对软件产品的需求和设计规格说明书的评审、对程序代码的审查和静态分析等。

静态分析：对模块的源代码进行研读和查错。

软件评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。检验工作产品是否正确地满足了以往工作产品中建立的规范。

作用：可以更早地发现需求工程、软件设计等各个方面的问题，大大减少大量的后期返工，将质量成本从昂贵的后期返工转化为前期的缺陷发现。

形式：互为评审 (Peer review) 轮查 (Pass-round)

走查 (walk-through) 会议评审 (Inspection)

.4 主/被动

测试人员主动发送请求/被动监控

.5 黑/白盒

白盒：结构化/逻辑驱动测试 已知产品的内部工作过程

黑盒：数据驱动/基于需求规格的测试 按需求规格说明书的规定检测系统的功能

.6 层次 单元→集成→系统→验收

单元测试针对程序系统中的最小单元---模块或组件进行测试，一般和编码同步进行。主要采用白盒测试方法 (代码评审50%～70%代码的缺陷。

集成测试，也称组装测试、联合测试，主要目标是发现与接口有关的模块之间问题。两种集成方式：一次性集成方式和增殖式集成方式。

系统功能测试：完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用

系统非功能性测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括：恢复测试 安全测试  强度测试

性能测试

验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样

  .7 测试工作

测试计划内容：

1. 目标和范围
2. 项目估算
3. 风险计划
4. 进度安排
5. 资源配置
6. 跟踪和控制机制

测试用例：输入数据+预期结果      为了特定测试目的而设计的测试条件、测试数据及相关的测试操作过程等的一个特定使用实例或场景。

作用：

§ 指导测试的实施

§ 规划测试数据的准备

§ 评估测试结果的度量基准

§ 保证软件可维护性和可复用性

§ 分析缺陷的标准

第三章

软件测试方法

白盒方法

基于直觉/经验  Ad-hoc测试方法和ALAC测试 + 错误推测法

自由测试（Ad-hoc Testing）强调测试人员根据自己的经验，不受测试用例的束缚，放开思路、灵活地进行各种测试。主要包含以下经验。

（1）软件开发的经验和知识；

（2）与失效和缺陷打交道的经验；

（3）对被测软件系统的经验和知识；

（4）软件系统涉及的业务知识；

（5）其他方面的经验，如心理学、社会学等。

ALAC，是Act-like-a-customer（象客户那样做）的简写，ALAC测试方法是一种基于客户使用产品的知识开发出来的测试方法。出发点 Pareto 80/20规律

80%时间使用20%的常用功能，80%的错误集中在20%的程序模块

错误推测法是测试者根据经验、知识和直觉来发现软件错误，来推测程序中可能存在的各种错误，从而有针对性的进行测试。

基于输入域

等价类划分方法

等价类是某个输入域的子集，在该子集每个输入数据的作用等效。

等价类划分法：将输入数据分成若干个子集，从每个子集中选取一个代表性数据作为测试用例。(有效/无效 等价类 均≥1)

a) 建立等价类表，列出所有划分出的等价类：

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

c) 设计一个新的测试用例，使其 尽可能多地覆盖尚未覆盖的 有效等价类

d) 重复c)，最后使得所有有效等价类均被测试用例所覆盖；

e) 设计一个新的测试用例，使其 只覆盖一个无效等价类。

f) 重复e)使所有无效等价类均被覆盖

边界值分析方法：

1. 确定边界情况
2. 选取正好=、刚刚>或<边界值作为测试数据

基本思想是利用输入变量值的最小值，稍大于最小值，正常值，稍小于最大值和最大值。

健壮性用例数量：6n+1 多一个略超过最大值以及一个略小于最小值的取值

局限性：假设输入变量是真正独立的。如果不能保证这种假设，则这类方法不能产生令人满意的测试用例。

基于组合及其优化

优：低成本实现+维护、易于自动化+较少测试案例发现更多错误、用户可自定义限制

缺：经常需要专家领域知识、不能测试所有可能的组合，不能测试复杂的交互

判定表方法

多因素组合输入 条件+动作

在所有的黑盒测试方法中，基于决策表的测试是最严格，最具有逻辑严格性的测试方法。

判定表最突出的优点是，它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。

条件桩部分列出了问题的所有条件 ,
动作桩则给出了问题规定的可能采取的操作。条件/动作项只能取布尔值。

适用于要发生大量决策的情况(例如三角形问题) ，或在输入变量之间存在重要的逻辑关系的情况( 例如NextDate 函数)，或规格说明以决策表形式给出，或是容易转换成决策表（条件规则的排列顺序不影响执行的操作。）

因果图

因果图方法适合于描述对于多种条件的组合，产生多个相应动作的测试方法， 能够帮助测试人员按照一定的步骤，高效率地开发测试用例，以检测 程序输入条件的各种组合情况。 序输入条件的各种组合情况。

1 ．分析程序规格说明的描述中，哪些是原因，哪些是结果。原因常常是输入条件或是输入

条件的等价类，而结果则是输出条件。

2  ．找出原因与结果之间，原因与原因之间的对应关系，并将其表示成连接各个原因与各个结果的 “ 因果图 ” 。

3  ．把因果图转换成判定表。

输入条件：E约束（异）至多有一个可能1 

I约束（或）至少有一个为1

O约束（唯一）必须有且仅有一个为1

输出条件：R约束（要求）必须同时为1：a 是１时，b 必须是１

                M约束（强制）前者为1则后者为0

两两组合（Pairwise）方法

基本原理：大部分缺陷是在两个变量取值冲突的测试时被发现的，不要测试所有的组合，测试所有的“ “Pairwise ”即可

正交实验法

减少测试工作量

基于逻辑覆盖

语句覆盖要求设计若干个测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次。

判定覆盖要求设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少执行一次，即判断的真假值均要被检测。

条件覆盖的基本思想是设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。

判定-条件覆盖是判定和条件覆盖设计方法的交集 条件覆盖是判定和条件覆盖设计方法的交集 ，即设计足够的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次。

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

修正条件/判定覆盖：

路径覆盖就是设计所有的测试用例，来覆盖程序中的所有可能的执行路径。

计算环形复杂度的三种方法:• 流图中的区域数等于环形复杂度。

• 流图G的环形复杂度V(G)＝E-N+2,其中E是流图中边的条数,N是流图中节点数。

• 流图G的环形复杂度V(G)＝P+1,其中P是流图中判定节点的数目。

所谓独立路径是指至少引入程序的一个新处理语句集合或一个新条件的路径,用流图术语描述,独立路径至少包含一条在定义该路径之前不曾用过的边。

环形复杂度 = 独立路径数量

第五章

5.4 单元测试

定义：单元测试是对软件基本的组成单元进行独立的测试：

时机：

单元测试和编码是同步进行，但在TDD中，强调测试在先，编码在后。单元测试一般由开发人员完成,QA人员辅助.

意义：尽早发现错误；检查代码是否符合设计和规范，有利于将来代码的维护

• 错误发现越早,成本越低.

• 发现问题比较容易

• 修正问题更容易

驱动/桩程序 ★ 运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块。

驱动模块（drive）:对底层或子层模块进行测试所编写的调用这些模块的程序。

桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程序。

5.7 系统集成 (概念

背景：模块相互调用时，接口出现多种问题：接口参数不匹配、传递错误数据、全局数据结构出现错误等

由有经验的测试人员+开发者共同完成

集成测试对单体架构：

分类：渐增式测试模式与非渐增式测试模式

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

渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。（自顶向下、自底向上、混合策略/三明治法）

大棒模式所有的模块一次集成，很难确定出错的真正位置、所在的模块、错误的原因。

自顶向下优点：不需要测试驱动程序，早期实现并验证系统主要功能；缺点：需要桩程序;底层关键模块错误发现较晚;早期不能充分展开人力

自底向上优点：不需要桩程序;底层关键模块错误发现较早;早期充分展开人力 缺点：需要测试驱动程序; 较晚实现并验证系统主要功能

三明治方法的优点：它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。采用这种方法的主要缺点是：在真正集成之前每一个独立的模块没有完全测试过。

对微服务架构：验证一个子系统或功能模块与外部组件之间的正常通信

第六章

6.1 功能测试

系统测试 = 功能性 + 非功能性

功能测试：根据产品设计规格说明书来检验被测试系统是否满足各方面的使用要求

面向界面UI、数据、操作、逻辑、接口等

要求举例：

功能逻辑清楚，符合使用者习惯 功能逻辑清楚，符合使用者习惯

系统的各种状态按照业务流程而变化，并保持稳定 系统的各种状态按照业务流程而变化，并保持稳定

每项功能符合实际要求 每项功能符合实际要求

系统的界面清晰、美观

菜单、按钮操作正常、灵活，能处理一些异常操作

能接受正确的数据输入，对异常输入的容错处理

 .2 回归测试

定义：在程序有修改的情况下保证原有功能正常的一种测试策略和方法

目的：

所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；不影响软件原有功能的正确性

策略：再测试全部用例

基于风险选择测试

基于操作剖面选择测试

再测试修改的部分

更智能的选择方法

回归测试对保证软件质量具有重要意义。要实现有效的回归测试，必须解决回归测试中的两个主要问题：

（1）测试用例的优化选择；

（2）覆盖率分析。

第七章

7.1性能测试

定义：为了发现系统性能问题或获取系统性能相关指标而进行的测试。

采用负载测试技术

性能指标：系统资源（CPU、内存等）+ 系统行为表现 （网络流量、响应时间、数据传输的吞吐量、数据处理效率等）

具体指标：数据传输的吞吐量 （Transactions）

•数据处理效率 （Transactions per second）

•数据请求的响应时间（ Response time）

•内存和CPU使用率

•连接时间 （Connect Time）、 发送时间 （Sent Time）

•处理时间 （Process Time）、 页面下载时间

•第一次缓冲时间

•每秒（SSL）连接数

•每秒事务总数、每秒下载页面数

•每秒点击次数、每秒HTTP 响应数

•每秒重试次数

性能问题

• 内部表现：资源耗尽或使用率过高；(资源耗尽/泄漏/瓶颈)

• 外部表现：响应很慢 （网页打开很慢 查询数据很长时间才显示列表 网络下载速度很低，如5k/s）

压力测试

概念：强度测试、负载测试。压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。

容量测试

容量：系统能正常工作的最大的并发用户数

.2 安全性测试

定义：全面检验软件在需求规格说明中规定的防止危险状态措施的有效性和在每一个危险状态下的反应，对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案进行针对性测试，并对安全性关键的软件单元和软件部件，单独进行加强的测试，以确认其满足安全性需求。

目的：检验系统权限设置有效性、防范非法入侵的能力、数据备份和恢复能力等，设法找出各种安全性漏洞

安全功能测试：数据机密性，完整性，可用性，不可否认性，身份谁，授权，访问控制，审计跟踪，委托，隐私保护，安全管理等。

安全漏洞测试：设计，实现，操作，管理上存在的可被利用的缺陷或弱点。

 .3兼容性测试

验证软件之间是否正确地交互和共享信息

硬件兼容

软件之间兼容

数据之间兼容

.4可靠性测试

可靠性（Reliability）是产品在规定的条件下和规定的时间内完成规定功能的能力。

成熟性度量可以通过错误发现率 DDP （Defect DetectionPercentage）来表现。在测试中查找出来的错误越多，实际应用中出错的机会就越小，软件也就越成熟。

DDP= 测试发现的错误数量/已知的全部错误数量