山东大学《软件测试技术》期末复习宝典

内部质量关注的是软件有没有正确地做事。(do things right) 即假设需求正确的情况下，开发团队内部的设计、编码、测试是否达到其应有的质量。内部质量对使用软件的人来说相对是不容易感知的，隐蔽的。例如，一段结构很差的代码如果运行结果是对的，可能用户就感觉不到它和结构更好的代码之间的差异。
外部质量关注的是软件有没有做正确的事。(do right things) 即开发团队交付出去的产品，多大程度地解决了客户的问题/满足了客户的需求。
使用质量关注的是真实的用户使用后感知的质量。它可能涵盖外部质量没有考虑的方面，或者在同一个方面质量要求实际更高。

2.2 软件缺陷定义及其原因

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

从产品内部看：软件缺陷是软件开发或维护过程中存在的错误、毛病等各种问题。
从外部看：软件缺陷是系统所要实现功能的失效或违背。

软件缺陷产生的原因：

技术问题：算法错误、接口错误。
团队工作：团队沟通不充分。
软件本身（整体）：用户使用场合、文档错误。

2.3 修复软件缺陷的代价

越到后期，修复软件缺陷付出的代价就越大。修正错误的代价不是随时间线性增长的，而是几乎呈指数增长的。

2.4 软件测试的分类

按照测试阶段或层次分：

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

按照目标/特性分：

功能测试
性能测试
强壮性测试
适用性测试
安全性测试
可靠性测试

按测试方法分：

白盒测试
黑盒测试

压力测试：也称负载测试，用来检测系统在不同负载条件下的运行情况，特别是高负载、极限负载的系统运行情况，已发现系统不稳定性、系统性能瓶颈、内存泄漏等问题。

回归测试：为保证软件中新的变化不会对原有功能的正常使用有影响而进行的测试。也就是测试原有功能还能使用。

静态测试和动态测试：

静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审。
动态测试是通过真正运行程序发现错误，通过观察代码运行过程来获取系统信息，对系统行为进行验证。

白盒测试和黑盒测试：

白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序。通过测试来检测产品内部动作是否按照设计规格说明书的规定进行，检验程序中的每条通路是否都按照预定要求正常工作。
黑盒测试也称为功能测试，它是通过测试来检验每个功能是否都能正常使用。在不能看到程序内部结构的情况下，在程序接口测试，它只检查程序功能是否按照规格说明书的规定正常使用。
黑盒测试不考虑程序内部逻辑结构，着眼于程序外部结构。

2.5 软件测试级别

单元测试：针对程序系统中的最小单元——模块或组件进行测试，一般和编码同步进行。主要采用白盒测试方法，从程序内部结构出发设计测试用例，检查模块或组件是否正确实现功能。通常要编写驱动模块和桩模块由编程人员和测试人员共同完成，而且以开发人员为主。
集成测试：也称为组装测试、联合测试，在单元测试的基础上，将模块按照设计要求组装起来进行测试。主要目标是发现与接口有关的模块之间问题，两种集成方式：一次性集成和渐增式集成。
系统测试：分为功能测试和非功能测试。
功能测试一般必须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否正常使用。
非功能测试则需要把软件放到整个计算机环境下，包括软硬件平台、数据等，在实际运行环境下进行一些测试包括：性能测试、安全测试、强度测试。
验收测试：目的是面向未来的用户表面系统能够按照预定的那样工作，包括：
α 测试：软件开发公司内部人员用新产品，在实际运行环境和真实应用过程中发现新缺陷；
β 测试：公司外部的典型用户试用，并要求用户报告异常情况、提出建议（体验服）。然后对Beta版本进行修正和完善（α 测试修正后的产品称为Beta版本）

2.6 什么是测试用例

为某个特殊目标而编制一组测试输入、执行条件和预期结果，以便测试程序是否满足某个特定需求。指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。

2.7 为什么要设计测试用例

测试用例构成了设计和指定测试过程的基础。
测试的“深度”和测试用例的数量成正比。
测试工作量和测试用例的数量成正比。
测试设计和开发类型以及所需的资源主要受控于测试用例。
测试用例是软件测试的核心。

3. 第三章软件测试方法

3.1 测试方法分类

测试方法狭义说就是设计测试用例的方法。

白盒方法：

语句覆盖
条件覆盖
判定覆盖
判定条件覆盖
条件组合覆盖
基本路径覆盖

黑盒方法：

判定表方法
因果图方法
正交试验法
功能图法
等价类法
边界值分析法
错误推断法

3.2 等价类划分

流程：

确定软件测试项。
每个软件测试项都考虑长度、类型、规则三方向。
为每个【测试项+方向】去分配一个有效类和无效类。
根据有效类和无效类分别写出不同类的数据特征
将数据特征组合成数据用例（正向尽可能覆盖，负向一次只覆盖一个测试点）

最后组合出测试用例：有效数据两条；无效数据八条。

3.3 边界值分析法

流程：

确定边界情况
按照七点法确定测试点（可以简化为五点法）

五点法则是：

离点和上点两个只要选择一个即可
比如闭区间，则选择离点；开区间，则选择上点

3.4 判定表法

在前面的等价类划分中，我们可以看到一次我们只能验证一个测试点是否有效（账号或密码）。但是有时候我们需要验证的是测试点组合起来是否有效，也就是说所有测试点本身都有效，但是组合起来的结果并不一定满足要求，因此这个组合也是我们需要测试的，这个时候就需要使用判定表方法。

条件桩：问题的所有条件。
动作桩：针对问题所采取的动作。
条件项：所列条件的具体赋值。
动作项：条件组合情况下应采取的动作。

3.5 因果图法

因果图法主要是用来加强判定表方法表达能力较弱的问题。判定表法中条件的组合只能是“与”关系，但是当条件的组合变得复杂后，就需要另外两个关系“或”、“非”一起参与表达。同时因果图加入了条件本身的关系。

条件组合关系：与、或、非
条件本身关系：条件之间本身的关系

3.7 正交试验法

前面的四个方法：等价类、边界值、判定表和因果图都是从需求出发的测试方法。这些测试方法是否效果好完全看是否完全把握住软件的需求（分的类/条件是否全覆盖需求点）。正交试验法本质是穷举法，是在穷举法的基础上去减少测试的数量。

正交实验表都已经被人设计好了，我们需要做的仅仅是去查表。明确我们的测试对象需要用哪一张正交表去测试即可。

每一个正交表（普通正交表）如下：

$L_n(q^s)$

或者混合正交表如下：

$L_n(q_1^{s^1}\times q_2^{s^2})$

如果我们确认n、q、s也就确认了使用哪一张正交表。

因素s: 输入条件 (因素)的个数（例如上个例子中，有三个条件，分别是操作系统，浏览器，分辨率）
水平q: 每个实验因素的取值个数、即每个因素的实验点的个数（也就是取值个数）
实验总个数n：表示测试用例的总个数，也就是这个正交表生产的测试用例的数目

对于s和q很好确定，对于测试对象需要的测试用例总数确定公式如下：

$n=1+\sum_{1}^{S}(\mathrm{q}-1)$

如上面这个例子最后n为9=1+3+3+2。

3.8 Pairwise方法

思想：只要变量的两两组合通过测试，则代表测试用例整个通过测试，不需要再测了。

题目：假设有3个维度，每个维度有几个因子。如下：

浏览器：M，O，P
操作平台：W（windows），L（linux），i（ios）
语言：C（chinese），E（english）

求解：

使用pairwise算法，有多少个测试case？具体是什么case？我们沿用数学做题的格式。

解：

如果不用pairwise算法，我们需要 3*3*2=18个测试case。下面是具体的case：

M W C
MW E
M L C
M L E
M I C
M I E
O W C
O W E
O L C
O L E
O I C
O I E
P W C
P W E
P L C
P L E
P I C
P I E

一共有18个，很繁琐。但是这是100%的测试覆盖率，缺陷率也是100%。现在我们使用pairwise，看看结果如何？首先咱们从最下方一个18号开始，它是 P I E，两两组合是 PI ，PE ，IE。看这3个组合在以上的相同位置出现过没有，PI在17号，PE在16号，IE在12号出现过。所以18这个case就可以舍去。最终剩下的如下：

共计9个测试case，节省了50%的测试case。现在我们从上面开始重新做一次。1号是MWC，两两组合是MW MC WC 都出现过，去掉。最终剩下的是：

这样也是剩下9个测试case，但是具体的case内容不一样。经过L. L. Thurstone证明，pairwise算法最终剩下的测试case个数肯定相同，但是可以有不同的case组合。

3.9 另一个视角看测试

前面将不同的测试方法按照黑盒和白盒的逻辑进行分类，但是分类的标准肯定不只一个。因此现在我们用逻辑和需求的角度来进行重新分类。

逻辑覆盖：对应于白盒测试。该类的测试方法要求设计的测试用例能够在逻辑上覆盖程序的某些结构（例如：所有路径、所有判断等等）
需求分析：对应于黑盒测试。该类测试方法设计用例的时候并不知道程序内部的结构，仅仅想要通过测试用例看程序是否满足需求的功能。

3.10 语句覆盖

语句覆盖测试：思想是设计测试用例，使得运行被测程序时，程序中的每一个可执行语句至少被执行一次。

3.11 判定覆盖

判定覆盖测试：思想是设计测试用例使得运行时，程序中的每一个判断真分支和假分支都至少经理一次，即每个判定分支都被满足过。

3.12 条件覆盖

条件覆盖：设计测试用例，使得程序运行后，每个判断中的每个条件都至少被满足一次。

3.13 判定条件覆盖

判定条件覆盖：是判定和条件覆盖设计方法的交集，思想是设计测试用例让程序执行中所有条件都至少执行一次，判定的分支也都至少走一次。

3.14 条件组合覆盖

条件组合覆盖：思想是设计足够的测试用例，让程序判断中的条件的所有组合都至少出现一次（不仅仅是条件出现过，要条件的组合也出现过）。

3.15 基本路径覆盖

前面讲的条件、判定、判定条件、条件组合都是从判断这个角度出发的，但是不一定对程序路径起到完全覆盖，比如：

因此，我们想到最直接的路径覆盖方法。但是路径覆盖测试量太大，于是就提出基本路径覆盖。

基本路径覆盖：思想是设计测试用例，运行程序能够覆盖程序主要的路径。

因此问题就转化为怎么找到主要路径：

画出程序流程图：
由流程图转为控制流图：
计算程序圈复杂度（计算有几个圈）：
圈复杂度越高则代表程序出错概率越大，因此可以认为 圈数=被测代码路径数量。
确定基本路径：根据上面得到的被测代码路径数量来确定基本路径

3.16 形式化方法，与形式化验证

形式化方法：基于数学的方法来描述软件系统属性的一项技术。
形式化方法就是把程序用数学方法来描述（公式、画图什么的），然后形式化验证就是通过验证（测试）这个描述来完成对程序的测试。

3.17 有限状态机（FSM）

有限状态机就是形式化验证的一个手段。
是软件测试的方法之一。
其验证（测试）的是状态图这个描述方式。

FSM的组成：

输入符号
输出符号
状态集
状态转移函数
输出函数

具体可以看下面这篇文章：(11 封私信) 基于有限状态机的测试（一）：基本定义、测试目标 - 知乎

举个例子（通过有限状态机方法得到一个程序状态图）：

状态图的输入符号、输出符号、状态集、转换函数、输出函数用状态表记录：

状态图能够转化为状态树来描述：

4. 第四章软件测试流程和规范

软件测试流程主要思考的是软件测试和软件开发之间的一个流程编排关系。在传统的软件测试流程中是先进行软件开发，然后进行软件测试：

但是这个流程编排显然是不合理的，软件测试应该贯穿软件开发的全过程。因此，我们考虑重新设计开发和测试的流程关系，将测试融入到开发过程中。

4.1 W模型

由两个V字型模型组成，分别代表测试与开发过程，测试和开发并行。测试伴随整个软件开发周期，并且测试的对象不仅仅是程序还可能包括需求定义文档、设计文档等。

4.2 TMap方法

是一种结构化的、基于风险策略的测试方法体系。目的是更早地发现缺陷，以最小的成本、有效且彻底地完成测试任务。TMap所定义地测试生命周期由计划和控制、准备、说明、执行、完成等阶段组成。

TMap有三大基石：

与软件开发生命周期一致的测试活动生命周期（L）
坚实的组织融合（O）
正确的基础设施和工具（I）
可用的技术（T）

4.3 软件测试的五大学派

分析学派：认为软件是逻辑性的，将测试看作计算机科学和数学的一部分，把测试看作是技术性很强的工作。
标准学派：把测试看作侧重成本控制并具有可重复标准的、旨在衡量项目进度的工作。
质量学派：测试是过程的质量控制、揭示项目质量风险的活动，测试人员扮演产品质量的守门员角色。
上下文驱动学派：强调人，测试所发现的每一个缺陷和相关利益者密切相关。
敏捷学派：测试就是验证开发是否完成，强调自动化测试。

分析学派：认为测试有很强技术性。

标准学派：认为测试具有可重复标准。

质量学派：认为测试是质量控制，测试人员是产品质量的守门员。

上下文驱动学派：强调人

敏捷学派：强调自动化测试

5. 第五章单元测试与集成测试

5.1 单元测试中的基本概念

单元测试：对软件基本的组成单元的测试。
时机：一般在代码完成后由开发人员完成，QA人员辅助。
概念：模块、组件、单元。
单元测试的测试人员：开发人员和测试人员共同完成，主要是开发人员。

5.2 为什么要单元测试

尽早发现错误，成本越低。
单元质量是系统质量的基石，单元测试可以比系统测试更加彻底。
软件bug不可以避免。

5.3 单元测试的目标

单元模块内部逻辑被正确实现。
信息能够正确地流入和流出单元。
内部数据能够保持完整性，包括变量定义引用、内存及时释放等。
代码行、分支覆盖等达到要求。

5.4 单元测试的任务

单元独立执行路径的测试：检查每一条独立执行路径的测试，保证每条语句都被执行过。
单元局部数据结构测试：检查局部数据结果完整性。
模块接口测试：检查模块接口是否正确。
单元边界条件测试：检查临界数据处理的正确性。
单元容错测试：预设的各种出错处理是否正确有效

内部执行路径、外部接口、数据结构、边界条件、单元容错

5.5 静态测试技术

静态测试技术：不运行被测试程序，通过对代码的检查阅读进行测试。

具体包括：

互查：通常是同一团队中的开发者之间互相审阅代码或文档。
走查：一种更加正式的程序审查技术，在面对关键任务或复杂功能时尤为重要。由项目经理发起开发人员甚至客户参与，采用讲解、讨论和模拟运行的方式来查找错误的活动。
评审

5.6 动态测试

不同于静态测试仅仅查阅代码、文档，动态测试需要真正将程序运行起来，需要设计系列的测试用例保证测试的完整性和有效性。

5.7 单元测试的测试依据

单元测试的依据是：详细设计和概要设计

单元测试是对软件基本组成单元进行的测试，其依据是：软件详细说明书。
单元测试不仅仅测试代码，同时有：接口测试、局部数据结构测试、边界条件测试、独立路径测试（基本路径测试）、错误处理测试等等。

5.8 编码的标准和规范

编码标准：必须遵守的规则。
编码规范：建议的最佳做法。

实施编码规范的原因：

可靠性
可读性
可维护性
可移植性

5.9 驱动模块和桩模块

驱动模块：对底层或子层模块进行测试所编写的调用这些模块的程序。
桩模块：对顶层或上层模块进行测试时所编写的替代下层模块的程序。

5.10 单元测试常用工具

JUnit
CppUnit
NUnit

5.11 单元测试工具种类

代码规则/风格检查工具
内存资源泄漏检查工具
代码覆盖率检查工具
代码性能检查工具

5.12 集成测试

集成测试：集成测试是将软件集成起来，对模块之间的接口进行测试

模块内的集成，主要是测试模块内各个接口之间的交互集成关系。
子系统内的集成，测试子系统内各个模块间的交互关系。
系统内的集成，测试系统内各个子系统和模块间的集成关系

分为三个层次去集成：模块内、子系统内、系统内

5.13 集成测试的模式

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

渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完后再把下一个应该测试的模块结合起来测试。

渐增式需要编写的软件较多，工作量较大。
渐增式发现模块接口错误的时间较早。
非渐增式发现错误，难以诊断；渐增式发现错误很好定位。
渐增式比非渐增式更彻底。
非渐增式可以并行，渐增式不行。

5.14 集成方向

自顶向下集成法：从主控模块开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合。

自底向下集成法：从“原子模块”开始集成进行测试。

6. 第六章系统测试

6.1 系统测试的基本概念

系统测试：检验系统所有元素之间协作是否合适，整个系统的性能和功能是否达到要求。其测试内容包括：功能测试、非功能测试和回归测试。
系统测试的人员：软件测试工程师。
系统测试内容：功能测试、非功能测试、回归测试

6.2 功能、非功能与回归测试

功能测试：测试系统是否满足需求所要求的功能。
非功能测试：性能测试、压力测试、安全性测试、容量测试、可靠性测试等等。
回归测试：在系统添加新的功能后，程序发生修改后测试原有功能是否仍然可用。

6.3 软件修改的正确性

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

6.4 回归测试的策略及其方法

再测试全部用例
再测试修改部分
基于风险选择测试
基于操作剖面选择测试

6.5 性能测试及其目标

性能测试：为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在真实环境、特定负载条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最终对测试结果进行分析来确定系统的性能状况。

性能测试目标：

获得系统性能某些指标数据。
为了验证系统是否达到用户提出的性能指标。
发现系统中存在的性能瓶颈，优化系统的性能。

6.6 性能测试的基本过程

确定性能测试需求
根据测试需求，选择测试工具和开发相应的测试脚本
建立性能测试负载模型
执行性能测试
提交性能测试报告

7. 第七章验收测试

7.1 验收测试的基本概念

验收测试：在软件产品完成了系统的功能测试、非功能测试之后。在产品发布之前，需要进行一次验收测试，检查软件是否符合合同要求，包括需求规格说明、设计规格说明和用户手册等。

验收测试的内容：

易用性测试：用户界面和可用性测试。
兼容性测试：软件兼容性测试、硬件兼容性测试等
安装测试和可恢复性测试、文档测试
总结：正确性、完备性、易理解性和一致性。

验收测试的测试人员：用户和测试部门共同完成。

验收测试的测试依据：国家规范、行业标准、合同条款、用户确认的需求规格说明书。

7.2 验收测试完成标准

完全执行了验收测试计划中的每个测试用例。
若在验收测试中发现错误，则修改并通过了测试。或者经过评估留待下一个版本中修改。
完成软件验收测试报告。

7.3 α测试和 β测试

α测试：是软件开发公司组织内部人员模拟各类用户将对软件执行的操作，试图发现错误并修正。
β测试：是指软件开发公司组织各方面的典型用户在日常工作中使用beta版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对beta版本进行改错和完善。
经过α测试后调整的软件产品称为beta版本。