山东大学2022软件测试技术复习纲要

文章目录

第一章——引论
第二章——软件测试的基本概念
- 软件缺陷
- - 定义
  - 修复软件缺陷的代价
  - 测试分类
  - - 静态测试
    - 动态测试
    - 压力测试
    - 基于脚本测试和探索式测试
  - 测试结束标准
  - 软件测试的工作范畴
第三章——软件测试方法
- 概念
- - 白盒测试的概念
  - 黒盒测试的概念
- 测试用例
- - 什么是测试用例
  - 为什么要设计测试用例
第四章——软件测试流程与规范
- TMM
- TPI
- CTP
- STEP
第五章——单元测试
- 概念
- 测试任务
- 测试依据
- 测试目标
第六章——集成测试和系统测试
- 集成测试
- - 概念
  - 集成模式
  - 测试依据
  - 主要目标
- 系统测试
- - 概念
  - 测试依据
  - 确认测试
第七章——验收测试
- 概念
- α，β测试
第8章——软件本地化测试
- I18N——软件国际化
- L10N——软件本地化
- G11N
- 关系和区别
第9章——软件测试自动化
- 概念
- 手工测试vs自动化测试
- 实现原理
- - 代码分析
  - 对象识别
  - 脚本技术
  - 自动比较技术
  - 测试自动化系统的构成
  - - 自动化测试的引入和应用

第一章——引论

为什么要进行软件测试？

产品质量的保证。软件总存在缺陷，只有通过测试，才可以发现软件缺陷。也只有发现了缺陷，才可以将软件缺陷从软件产品或软件系统中清理出去。
控制成本的关键。软件中存在的缺陷给我们带来的损失是巨大的，这也说明了软件测试的必要性和重要性。
测试是所有工程学科的基本组成单元，自然也是软件开发的重要组成部分。
软件可靠性确认。
让企业具备国际竞争的实力。

什么是软件测试？

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

验证是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性
有效性确认是确认所开发的软件是否满足用户真正需求的活动

Bill Hetzel博士（正向思维的代表）：

软件测试就是为程序能够按预期设想那样运行而建立足够的信心

“软件测试是一系列活动以评价一个程序或系统的特性或能力并确定是否达到预期的结果”

测试是为了验证软件是否符合用户需求，即验证软件产品是否能正常工作

Glenford J. Myers （反向思维的代表）：

测试是为了证明程序有错，而不是证明程序无错误

一个好的测试用例是在于它能发现至今未发现的错误

一个成功的测试是发现了至今未发现的错误的测试

软件测试和软件开发的关系

在V模型中，软件测试活动和项目同时启动，软件测试的工作很早就开始了，避免了瀑布模型所带来的误区—软件测试是在代码完成之后进行。V模型相对准确地反映测试与开发之间的关系：

左边是软件定义和实现的过程（包括分析、设计和编程），右边是对左边所构造的东西进行验证的过程，测试与开发有一对一的关系。测试的工作（右边）是对开发工作（左边）成果的检验，以确认是否满足事先的定义和要求。

软件测试与SQA（软件质量保证）的关系

联系

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

区别

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

四种导向

1957～1978年，以功能验证为导向，测试是证明软件是正确的（正向思维）。
1978～1983年，以破坏性检测为导向，测试是为了找到软件中的错误（逆向思维）。
1983～1987年，以质量评估为导向，测试是提供产品的评估和质量度量。
1988年起，以缺陷预防为导向，测试是为了展示软件符合设计要求，发现缺陷、预防缺陷。

五大学派

分析学派：分析学派认为测试工作是技术性很强的工作，侧重使用类似UML工具进行分析和建模。
标准学派：标准学派把测试看作侧重劣质成本控制并具有可重复标准的、旨在衡量项目进度的一项工作，测试是对产品需求的确认，每个需求都需要得到验证。
质量学派：软件质量需要规范，测试就是过程的质量控制、揭示项目质量风险的活动，确定开发人员是否遵守规范，测试人员扮演产品质量的守门员角色。
上下文驱动学派：认为软件是人创造的，测试所发现的每一个缺陷都和相关利益者密切相关；认为测试是一种有技巧的心理活动；强调人的能动性和启发式测试思维。探索性测试就是其典型代表。
敏捷学派：认为软件就是持续不断的对话，而测试就是验证开发工作是否完成，强调自动化测试。TDD 是其典型代表。

第二章——软件测试的基本概念

软件缺陷

定义

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

修复软件缺陷的代价

在设计阶段就是它的3～6倍，在编程阶段是它的10倍，在内部测试阶段是它的20～40倍，在外部测试阶段是它的30～70倍，而到了产品发布出去时，这个数字就是40～100倍，修正错误的代价不是随时间线性增长，而几乎是呈指数增长的。

测试分类

静态测试

静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的审査以及静态分析等。并不需要对代码进行编译和仿真运行。

动态测试

动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统行为、变量实时结果、内存、堆栈、线程以及测试覆盖度等各方面的信息，来判断系统是否存在问题，或者通过有效的测试用例，对应的输人输出关系来分析被测程序的运行情况，来发现缺陷。

压力测试

也称负载测试，用来检查系统在不同负载（如数据量、并发用户、连接数等）条件下的系统运行情况，特别是高负载、极限负载下的系统运行情况，以发现系统不稳定、系统性能瓶颈、内存泄漏、CPU使用率过高等问题。

基于脚本测试和探索式测试

基于脚本的测试执行（ST）	探索式测试（ET）
系统性强	自由灵活
容易管理、控制	适应性强，和ST是互补的
设计在先，执行在后	执行和设计（思考）并行
主要是验证自己的思路	不断和系统交互，带着问题测试
可预见性	学习的过程，强调个人能力

测试结束标准

用例全部测试
覆盖率达到标准
缺陷率达到标准
其他指标达到标准

软件测试的工作范畴

软件测试工作的组织与管理：制定测试策略、测试计划，确认所采用的测试方法与规范，控制测试进度，管理测试资源。
测试工作的实施：编制符合标准的测试文档，搭建测试环境，开发测试脚本、与开发组织协作实现各阶段的测试活动。

第三章——软件测试方法

概念

白盒测试的概念

按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。

黒盒测试的概念

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

测试用例

什么是测试用例

为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求，被称为有效地发现软件缺陷的最小测试执行单元。

为什么要设计测试用例

测试用例测试用例是软件测试的核心，构成了设计和制定测试过程的基础。

测试用例是测试人员在测试过程中的重要参考依据。
测试用例可以帮助实施有效的测试，所有被执行的测试都是有意义的，不要执行毫无意义的测试操作。
良好的测试用例不断地被重复使用，使得测试过程事半功倍。
测试用例是一个知识积累的过程。

第四章——软件测试流程与规范

TMM

TMMi呈现的是一个过程改进的阶段型架构。它包括阶段或级别，组织可以通过它们使测试过程从临时的和未管理的状态进化为已管理、已定义、已测量和优化的状态。在TMMi中有5个级别，规定了成熟度级别和测试过程改进的路径。每个级别都有一组过程域，组织需要实施这些过程域来达到对应的成熟度级别。

TMMi1级—初始

TMMi2级—已管理

TMMi3级—已定义

TMMi4级—已测量

TMMi5级—优化

过程能力描述了遵循一个软件测试过程可能达到的预期结果的范围。TMM的建立，得益于以下3点：

充分吸收CMM的精华
基于历史演化的测试过程
业界的最佳实践

TPI

TPI是基于连续性表示法的测试过程改进的参考模型，是在软件控制、测试知识以及过往经验的基础上开发出来的。

CTP

关键测试过程（Critical Test Process，CTP）评估模型主要是一个内容参考模型，一个上下文相关的方法，并能对模型进行裁剪。

使用 CTP 的过程改进，始于对现有测试过程的评估，通过评估以识别过程的强弱，并结合组织的需要提供改进的意见。

STEP

STEP（Systematic Test and Evaluation Process，系统化测试和评估过程）是一个内容参考模型，认定测试是一个生命周期活动，在明确需求后开始直到系统退役。

第五章——单元测试

概念

单元测试：单元测试是对软件基本组成单元（如函数、类的方法等）进行的测试

单元测试的测试人员：程序人员和开发人员

时机：一般在代码完成后由开发人员完成，QA（质量保证）人员辅助。

模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。

从逻辑的角度来拆分系统后，得到的单元就是模块

划分模块的主要目的是职责分离

从物理的角度来拆分系统后，得到的单元就是组件

划分组件的主要目的是单元复用。

测试任务

单元独立执行路径的测试：在单元中应对每一条独立执行路径进行测试，这不仅检验单元中每条语句（代码行）至少能够正确执行
单元局部数据结构的测试：检査局部数据结构是检査临时存储的数据在程序执行过程中是否正确、完整。
单元接口测试：检查模块接口是否正确。
单元边界条件的测试：检查临界数据处理的正确性。
单元容错性测试：预见、预设的各种出错处理是否正确有效。
内存分析

测试依据

软件需求规格说明书 软件详细设计说明书

测试目标

主要目标：检验各单元模块是否被正确地编码

需要验证以下内容：

信息能否正确地流入和流出单元。
在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。
在为限制数据加工而设置的边界处，能否正确工作。
单元的运行能否做到满足特定的逻辑覆盖。
单元中发生了错误，其中的出错处理措施是否有效。

第六章——集成测试和系统测试

集成测试

概念

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

顾名思义，集成测试是将软件集成起来后进行测试。集成测试又叫子系统测试、组装测试、部件测试等。

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

集成测试的测试人员：有经验的测试人员和开发者共同

集成模式

非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。
渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合进来进行测试，测试完后再把下一个应该测试的模块结合起来测试。渐增式测试又可以根据每次添加模块的路线分为自顶向下测试、自底向上测试和混合测试等方式。
1. 自顶向下：从主控模块开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。在集成过程中，可以使用深度优先的策略或宽度优先的策略。
2. 自底向上：从“原子”模块（即在软件结构最底层的模块）开始集成以进行测试。
3. 混合策略：在具体测试中，可采用混合策略，即结合上述的两种方法逐步实施集成测试。

驱动程序
用于模拟被测模块的上级模块，能够调用被测模块，驱动模块接受测试数据，调用被测模块并把相关数据传送给被测模块。

桩程序
用于模拟被测模块工作过程中所调用的下层模块，一般很少进行数据处理，一般只检测被测模块传输数据的正确性。

测试依据

软件概要设计说明书 软件详细设计说明书

主要目标

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。

目标在于检验与软件设计相关的程序结构问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。

系统测试

概念

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

功能测试：根据产品规格说明书，来检验被测试的系统是否满足各方面功能的使用要求
非功能性测试包含：性能测试、压力测试、容量测试、安全性测试、可靠性测试、容错性测试
回归测试：在程序有修改的情况下保证原有功能正常

系统测试的测试人员：软件测试工程师

测试依据

软件需求规格说明书 软件概要设计说明书软件详细设计说明书

确认测试

确认测试又称有效性测试。有效性测试是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。

任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定，它包含的信息就是软件确认测试的基础。

第七章——验收测试

概念

验收测试：检查软件是否符合合同要求，包括需求规格说明、设计规格说明和用户手册等。

测试内容：
1. 易用性测试（用户界面和可用性测试）
2. 兼容性测试（软件兼容性测试、数据共享兼容性测试、硬件兼容性测试）
3. 安装测试和可恢复性测试（安装与卸载测试、可恢复性测试）
4. 文档测试（正确性、完备性、易理解性、一致性）
测试人员：用户和测试部门共同完成
测试依据：国家规范、行业标准、合同条款、用户确认的需求规格说明书

α，β测试

α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。

经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

第8章——软件本地化测试

I18N——软件国际化

I18N是借助功能设计和代码实现中软件系统有能力处理多种语言和不同文化，使创建不同语言版本时，不需要重新编写代码的软件工程方法。

支持Unicode字符集、双字节的字符
分离程序代码和显示内容
消除Hard code
使用Header files 去定义经常被调用的代码段
改善翻译文本尺寸，具有调整的灵活
支持各个国家的键盘设置
支持文字排序和大小写转换
支持各个国家的度量衡，时区，货币单位格式等的设置
国际化用户界面设计（自我定义）。

L10N——软件本地化

L10N是将一个软件产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。

翻译
地区文化、宗教
度量衡和时区等
软件用户界面（UI）
联机文档 (帮助文档和功能性的PDF文档)
热键设置

G11N

G11N = I18N + L10N

关系和区别

I18N是L10N的基础和前提，为L10N做准备
L10N是I18N向特定本地语言环境的转换
I18N 是软件产品源语言开发的一部分，属于Engineering
L10N 可以独立于Engineering，可由第三方完成

第9章——软件测试自动化

概念

自动化测试是相对手工测试而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。

手工测试vs自动化测试

手工测试	自动化测试
发现缺陷率高	难以发现缺陷
重复测试效率低	高效率、高复用性
不一致性、可靠性低	准确、可靠
依赖人力资源	不知疲劳，激励团队士气
覆盖率量化困难	覆盖率容易度量
创造性、灵活性	机械
容易实施	一次性投入大

在系统功能逻辑测试、验收测试、适用性测试、涉及物理交互性测试时，多采用手工测试方法
对那种不稳定软件的测试、开发周期很短的软件、一次性的软件等不适合测试自动化
单元测试、集成测试、系统负载或性能、稳定性、可靠性测试等比较适合采用自动化测试
功能测试时，工具更能发挥回归测试作用，可以保证对已经测试过部分进行测试的准确性和客观性

实现原理

代码分析

类似于高级编译系统，在工具中定义类/对象/函数/变量等定义规则、语法规则等，在分析时对代码进行语法扫描，找出不符合编码规范的地方。

对象识别

测试工具能够实现对用户界面的操作，要么就按照屏幕的实际像素坐标来定位，要么通过寻找UI上的对象（如窗口、按钮、滚动条等）来确定操作的目标.

Windows对象
Mac对象
Web DOM对象

脚本技术

脚本的技术围绕着脚本的结构设计，实现测试用例。

线性脚本
结构化脚本
数据驱动脚本
关键字驱动脚本

自动比较技术

自动执行测试脚本时，预期输出是事先定义的或插人脚本中，然后在测试过程中运行脚本，将捕获的结果和预先准备的输出进行比较，从而确定测试用例是否通过。

测试自动化系统的构成

在大规模的自动化测试过程中，需要调度、控制多台测试机器进行协助工作，还需要特定的服务器用于存储和管理测试任务、测试脚本和测试结果。

自动化测试的引入和应用

找准测试自动化的切入点
把测试开发纳入整个软件开发体系
测试自动化依赖测试流程和测试用例
软件测试自动化的投入较大
进行资源的合理调度