【软件评测】11软件测试理论

仅为学习记录~

软件测试基础

软件测试

软件测试

软件测试的定义

• 73年的第一个定义–程序能够按照预想的设计去运行而给出的信心（83年修订后为系统的特性和能力为目标的一种活动
• 79年给出了新的定义–为了发现错误而执行系统的目的，称为“证伪”
• 83年–使用人工或自动手段来运行和测试某个系统的过程，目的是是否满足了规定的需求，弄清预计结果和实际结果的差距，这个定义开始像质量方面靠拢
• 14年-发布了软件工程知识体系SWEBOK3.0，强调的是动态验证计算机程序对有限的测试用例集是否可产生期望的结果

软件测试的对象–程序、数据和文档

软件测试的目的–保证软件质量，保证软件和系统符合相关法律、技术标准、应用需求，降低软件产品的产品风险和应用风险

验证与确认

GB/T给出了验证与确认的描述，称为V&V
验证–对应的是需求，找相关的客观证据来证实规定的需求已经得到了满足
确认–通过提供客观证据来证明针对某一功能和特定应用需求得到了满足

软件缺陷

GB/T32422的定义，软件中出现了瑕疵或缺点，导致无法满足用户的需求或者规格说明书的要求，称为缺陷

软件缺陷主要产生在需求分析阶段和设计阶段，需求分析阶段40%，设计阶段30%，编码阶段30%

需求分析阶段（通过评审可以降低缺陷率）

• 客户描述不够清晰，造成需求不明确
• 需求频繁变更
• 用户和软件开发人员的沟通问题
• 获取需求查验的方式（调查问卷、当面沟通）有待提高

设计阶段–缺陷较隐蔽，通过评审可以降低缺陷率

编码阶段–缺陷较容易发现

缺陷越早发现，修复代价越低


优先级用于表达、评估、解决缺陷的优先程度

严重性指缺陷失效后最大的影响程度

测试质量与保证

软件质量

GB/T25000.1指在规定条件下软件产品满足明确或隐含要求的能力

质量保证

质量保证是以保证各项质量管理工作实际有效的进行和完成为目的的活动体系

质量保证是管理性活动

软件测试是技术性活动

软件测试是质量保证活动中的一个子项，是质量保证中一个很重要的技术手段

测试用例

测试用例–为某个特定目的而开发的输入、执行条件、预期结果的一个集合

要点

• 目的性强
• 需要有特定目的下的运行环境
• 要提供判定准则

作用

• 测试实施的依据
• 体现了测试的方案、方法、技术和策略
• 保证测试的规范性，提高测试效率
• 保证测试质量，避免随意性和盲目性
• 作为软件企业的一类资产
  

测试策略

测试策略是软件测试的原则、方法的集合

测试策略的方法

• 基于分析的策略
• 基于模型的策略
• 基于标准规范的策略
• 基于自动化的回归测试策略

软件策略的确定主要是测试的需求以及测试风险的评估结果来决定，基于测试需求、风险评估结果去定义测试的范围、要求，选择合适的测试方法，然后去制定测试启动、测试停止、测试完成的标准和条件

测试策略的输入

• 测试所需软硬件资源的详细说明
• 需要的人力资源的角色和职责
• 测试方法、测试标准和完成标准
• 目标系统的功能性和非功能性需求、技术指标

测试策略的输出

• 已批准或审核的测试策略文档、测试用例和测试计划
• 需要解决方案的测试项目

制定测试策略过程

1. 确定测试需求

测试需求必须是可观测、可测评的
软件需求与测试需求以及测试用例不是一对一关系
测试需求可能有许多来源

2. 评估风险并确定优先级
3. 确定测试策略

测试的原则

• 溯源性原则–追溯到原始需求，旧版本称为溯源
• 工程性原则–需尽早地不断地开展测试
• 独立性原则–避免开发人员自己测试自己的程序（在旧版本中，测试人员可以进行单元测试）
• 合理性原则–无法对软件进行穷举，无法进行彻底的测试，在质量的要求和测试强度之前找到合理的点，设置测测试的增值条件
• 不完全性原则–测试显示软件中缺陷的存在，但不能证明软件不存在缺陷。也就是说，软件测试可以降低软件中未发现的缺陷的可能性，但是即使没有发现缺陷，也不能证明其正确性
• 相关性原则–一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比，旧版称为群集性原则
• 可接受性原则–在利益相关方可接受的情况下，允许某些缺陷的存在
• 风险性原则–测试本身是有风险的

软件测试模型

V模型

V模型是对瀑布模型的优化，强调了测试的重要性，从本质上还是没有改变瀑布模型的特点
左边部分表示开发阶段，右边部分表示测试阶段

W模型

体现了测试工作应尽早和不断地开始的原则（工程性原则）
第一个V表示开发过程，第二个V表示测试过程
W模型仍然没有把软件测试独立出来，还是依赖于开发过程

H模型

H模型把测试流程从开发过程中独立了出来，不需依赖于开发过程
在软件开发过程中，任何一个时间点上，只要具备了测试的条件，就开展测试工作，兼顾了测试的效率和联合性，适用于各种规模的软件测试

敏捷测试模型

以应付需求为核心，进行持续、有意义的沟通和迭代，强调的是各方人员之间的相互协作
敏捷测试模型对测试人员要求较高，要求测试人员沟通高效、理解需求能力足够

软件测试分类

回归测试

软件有变动的情况需要进行回归测试

• 对缺陷修复–首先验证缺陷是否正确修复、然后测试缺陷修复可能影响到的功能是否正确
• 对新增功能–验证新功能的正确性、测试可能受到影响的其他功能
• 对删减功能–检测是否影响到保留的功能

按照关联代码划分

• 白盒测试–也称为结构测试、逻辑驱动测试、基于结构代码的测试。基于程序内部结构来设计测试用例
• 黑盒测试–把软件看成一个不透明的盒子，只关注软件的功能、规格说明书和特性，不关注内部结构

按实施主体划分

• 开发方测试–开发方在开发环境下测试，比如说α测试
• 用户测试–用户在用户的应用环境下测试，比如说β测试
• 第三方测试–以第三方为主体的测试（技术、财务、管理独立于开发方、用户方的组织）

按工程阶段划分

• 单元测试–单元为软件中最小的单位，可以表现为一个函数、一个过程、一个类，主要依据为模块的详细设计文档，测试价值为尽早地发现问题，降低成本，也称为模块测试。单元测试可由测试人员和开发人员共同完成。单元测试的测试内容包括模块接口、出错处理、局部数据、独立路径、模块、边界条件
• 集成测试–去发现单元、接口之间可能存在的问题，涉及的输入文档为概要设计说明书、详细设计说明书。一次性组装为big bang，还有增值组装

组装时需要考虑的问题
1.在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失
2.一个模块的功能是否回对另一个模块的功能产生不利的影响
3.各个子功能组合起来，能否达到预期要求的父功能
4.全局数据结构是否有问题
5.单个模块的误差累积起来，是否会放大，以致达到不能接受的程度

模块组装方式
一次性组装方式：节省人力，如果没有问题的话成立，在测试过程中发现问题时，很难定位问题出现在哪里，反而浪费工时
增量式组装方式：
1.自顶向下的增量方式
2.自底向上的增量方式
桩模块/驱动模块–是一个底层的驱动模块

• 系统测试–将软件整个结合在一起，以需求规格说明书的要求逐一地去验证系统的质量
• 确认测试–也叫做有效性测试，一般由开发方组织，去验证软件的有效性，以需求规格说明书来确认和验证的有效性，还需要做软件配置的复查工作
• 验收测试–以用户为主的测试，一般使用生产中的实际数据进行测试，决定是否接受或拒收系统

按执行代码划分

• 动态测试–黑盒测试、白盒测试、灰盒测试
• 静态测试–代码审查、代码走查

按质量特性划分

• 功能测试
• 性能效率测试
• 兼容性测试
• 易用性测试
• 可靠性测试
• 信息安全性测试
• 维护性测试
• 可移植性测试

按符合性情况划分

• 符合性测试–按照相关的标准、合同来进行符合性的检查

软件评测标准

标准化概述

标准–为了在一定范围内获得最佳秩序经协商一致，并由公认机构批准共同使用和重复使用的一种规范性文档，是标准化活动的核心产物

标准化–为了获得在一定范围内的最佳秩序，对现实的问题和潜在问题，制定共同使用和重复使用的条款的一种活动

软件测试标准化的作用

• 建立了软件测试最佳秩序的一个工具
• 促进了软件测试技术的创新和应用的途径
• 扩大推广了软件测试的技术

标准分类

• 国际标准–任何的国际组织公布的标准
• 国家标准–作用于国家行政管理范围内
• 行业标准–国家相关行业的行政主管编写和公布的
• 地方标准–各个区域的地方政府制定的
• 团体标准–相关团体自行制定的，自愿采用
• 企业标准–由企业指定的人员发布的，作用标准在企业内

软件测试相关的主要标准

• 软件质量标准–主要用于解决产品质量如何来进行评价、怎么评价的问题
• 软件测试文档和技术标准–支撑软件质量中各个质量特性，以及策动取值和评价，并给出了相关测试的过程、测试文档、测试技术
• 软件测试工作量及成本估算标准–控制成本和成本管理的决策的一种量化方法

软件质量模型与评价标准

软件质量标准的发展

软件质量模型的发展

1. 第一阶段：ISO/IEC9126:1991《软件工程 产品质量》对软件产品提出了6个方面的质量特性（功能性、可靠性、易用性、效率、维护性、可移植性）
2. 第二阶段–ISO/IEC9126:2001《软件工程 产品质量第1部分：软件模型》和3个质量度量标准。将软件质量分为内部质量、外部质量和使用质量（有效性、生产率、安全性、满意度）
3. 第三阶段–ISO/IEC 25000系列标准，将软件内部和外部质量更改为软件产品质量，产品的特性由原来的8个改为8个（多了兼容性和信息安全性），使用质量更改为有效性、效率、满意度、抗风险、周境覆盖，增加了IT服务质量（适宜性、可用性、安全性、可靠性、有形性、响应性、适应性、可维护性）和数据质量（准确性、完备性、一致性、确实性、现时性、可访问性、依从性、保密性、效率、精度、可跟踪性、可理解性、可用性、可移植性、可恢复性）的模型

使用质量

使用质量–从用户角度来看待软件的质量
有效性–用户实现确定目标的准确性和完备性
效率–用户实现目标准确性和完备性过程中所消耗的资源的情况
满意度–产品在指定的使用周境中用户要求满足的程度
抗风险性–产品或系统在经济状况、人的生命健康、环境潜在的风险因素
周境覆盖–在指定的周境中，能够被使用的程度

产品质量：系统/软件产品质量

• 功能性–在指定的条件下使用，产品或系统提供满足用户明确或隐含功能的程度，功能的特性：完备性、正确性、适合性、依从性
  测试方法：等价类、边界值法、因果图法、判定表法、场景法

  用例：正常用例、异常用例

完备性–功能集对指定用户的覆盖程度，X=1-A/B
正确性–提供所需的精度,X=1-A/B
适合性–功能与指定任务之间的实现程度，X=1-A/B
依从性–对相关标准、约定的遵循程度

• 性能效率–在指定的使用条件下，使用资源量的有关情况，性能效率的特性：时间特性、资源利用率、容量、性能效率的依从性

时间特性–响应时间、处理时间、吞吐率是否满足需求
资源利用率–所使用的资源数量、资源类型满足需求的程度
容量–参数最大需求的程度，对象处理大量的数据，确定是否达到了将使软件发生故障的极限；给定时间内，能够持续处理的最大负载或工作量

测试类型：基准测试、并发测试、压力测试、负载测试、稳定性测试、极限测试、场景测试、吞吐量测试

• 兼容性–共享相同的硬件和软件环境的条件下，产品系统或组件能够与其他产品能够执行信息的交换以及执行所需功能的程度，兼容性的特性：共存性、互操作性、兼容性的依从性

共存性–在与其他产品共享通用的环境，或者共享资源的环境下，产品能够有效执行所需的功能，且不会对其他产品功能造成影响的程度
互操作性–各组件之间能够进行数据的交换

• 易用性–在特性的使用周境中，产品系统在有效性、效率、满意度等方面为了指定目标可为用户去使用的程度，易用性的特性：可辨识性、易学性、易操作性、用户差错防御性、用户界面舒适性、易访问性、易用性的依从性

可辨识性–用户能够辨识产品是否能够完成其目标的程度。描述的完整率、演示覆盖率、产品标识可辨识、入口点的自描述性
易学性–学习使用产品的程度。帮助系统和文档的完整性、自动填充默认输入字段、差错信息易理解性、用户界面的自解释性
易操作性–操作和控制的难易程度。操作一致性、消息的明确性、功能的易定制性
用户差错防御性–预防用户犯错的程度。抵御误操作、用户输入差错纠正
用户界面舒适性–让用户感到舒服的程度
易访问性–广泛特征为个体使用的程度。特殊群体的易访问性、支持的语种的充分性

• 可靠性–在指定环境下指定时间内完成指定功能的程度，可靠性的特性：成熟性、可用性、容错性、易恢复性、可靠性的依从性

成熟性–在正常运行下，满足可靠性要求的程度。故障密度、故障修复率、平均失效间隔时间（MTBF）、周期失效率
可用性–在需要使用时，能够进行数据操作。系统可用性、平均宕机时间
容错性–硬件发生错误时，软件是否能正常运行。避免失效率、组件的冗余度
易恢复性–软件失效时，是否能恢复受影响的数据，以及重建的程度。平均恢复时间、数据备份完整性、数据恢复能力

• 信息安全性–产品或者系统保护信息和数据的程度，使其他用户按照授予的权限访问软件系统，信息安全的特性：保密性、完整性、抗抵赖性、可核查性、真实性、信息安全的依从性

保密性–只有被授权的用户才可以访问。访问控制性、数据加密正确性
完整性–防止非授权的访问和篡改计算机的程度
抗抵赖性–活动发生后能够正视且不否认的程度
可核查性–实体活动可以进行追溯的程度。用户审计跟踪的完整性、系统日志存储
真实性–对身份、标识进行核实符合其声明的程度。鉴别机制的充分性、鉴别规则的符合性

• 可维护性–能够被预期的维护人员进行有效的修改和效率的程度，维护性的特性：模块化、可重用性、易分析性、易修改性、易测试性、维护性的依从性

模块化–组件发生变更后，对其他组件影响的程度
可重用性–资产能够被重复利用于多个系统或用于其他资产建设的程度。资产的可重用性、编码规则符合ing
易分析性–评估变更的难易程度。日志完整性、诊断功能有效性
易修改性–被有效修改而不会引入新的缺陷。扩充系统应用、软件版本更新方式、软件版本更新时的数据操作、系统参数配置、用户权限配置
易测试性–是否满足有效性和效率的程度

• 可移植性–系统和软件产品从一个环境下迁移到另一个环境的下的有效性和效率程度，可移植性的特性：适应性、易安装性、易替换性、可移植性的依从性

适应性–在软件环境变更下，能够有效率的去使用的程度
易安装性–安装卸载的有效性和效率
易替换性–产品能够替换另一个同样用途产品的程度

软件质量、模型、测度、测量函数之间的关系

• 确定评价需求–确定评价目的、评价的产品质量需求、标识待测产品相关的部件、待测产品规定的严格程度
• 规定评价–测量的测度、测度判断的准则、评价判断的准则
• 设计评价–策划评价相关的活动
• 执行评价–实时测量工作、应用选定的测试标准进行验证
• 结束评价–评审评价结果、编制评价报告、评审质量反馈

就绪可用产品（RUSP）

RUSP–直接就可以使用的产品

RUSP要求–产品说明要求、用户文档集要求、软件质量要求

测试文档集要求–规定了对产品进行测试时，需要整理编写的测试文档的集合

符合性评价细则–适用于产品的说明、交互的软件

软件测试标准

38534修改采用了国际标准29119，主要适用于企业和评测机构，去规范测试过程，建立自己的软件测试流程，提高测试人员的能力

测试过程标准

组织级测试过程

定义了开发和管理组织级测试规格说明书的过程，包括组织级测试方针、策略、规程、资产的维护

组织级测试过程的输入

• 主要利益相关方的观点
• 组织内当前测试实践和知识体系
• 组织使用宣言
• IT仿真，及IT项目管理方针
• 质量方针
• 组织级测试方针
• 组织级测试策略
• 对测试规格说明的反馈
• 组织机构的典型测试计划
• 产业和政府标准

活动和任务

• 家里组织级测试规格说明
• 监测和控制组织级测试规格说明的使用
• 更新组织级测试规格说明

结果

• 确定组织级测试规格说明的需求
• 制定组织级测试规格说明
• 利益相关方同意组织级测试规格说明
• 可以获取组织级测试规格说明
• 监督组织级测试规格说明的符合性
• 利用相关方同意组织级测试规格说明的更新
• 更新组织级测试规格说明

信息项

• 组织测试规格说明（组织级测试方针、组织级测试策略）

测试管理过程（按照教程模型，测试管理过程包含了动态测试过程）

定义了涵盖任何测试阶段、测试项目的管理过程，包括3个子过程，分别为测试策划过程、测试监测和控制过程、测试完成过程

测试策划过程

目的–用于制定测试计划

输入

• 组织级测试方针
• 组织级测试策略
• 监管标准
• 项目测试计划
• 事件报告
• 项目管理计划
• 适用的产品文档
• 软件开发计划
• 项目及产品风险
• 测试计划更新

活动和任务

• 理解上下文
• 组织测试计划开发
• 识别和分析风险
• 确定风险缓解方法
• 设计测试策略
• 确定人员配置和调度
• 编写测试计划
• 获得一致性测试计划
• 沟通并提供测试计划

结果

• 分析并理解测试的工作范围
• 确定并通知参与测试计划的相关利益方
• 按照规定的风险暴露水平，可以通过测试对风险进行识别、分析和分类
• 确定测试策略、测试环境、测试工具以及测试数据需求
• 确定人员配置和培训需求
• 安排每项活动
• 计算估计数，并记录证明估计数的证据
• 测试计划达成一致，并分发给利益相关方

信息项–测试计划

测试设计和实现过程

目的–设计测试用例、测试规程

输入

• 测试依据
• 测试计划
• 测试策略
• 测试项
• 测试设计技术

活动和任务

• 识别特征集
• 导出测试条件
• 导出测试覆盖项
• 导出测试用例
• 形成测试集
• 导出测试规程

结果

• 分析每个测试项的测试依据
• 将待测特征组合成特征集
• 导出测试条件
• 导出测试覆盖项
• 导出测试用例
• 汇集测试集
• 导出测试规程

信息项

• 测试规格说明和相关可追溯信息
• 测试数据需求
• 测试环境需求

测试环境构建和维护过程

目的–建立和维护所需的测试环境，并获得相关状态告知利益相关方

输入

• 测试计划
• 测试环境需求
• 期望/运行环境
• 测试依据
• 测试规程
• 测试结果

活动和任务

• 创建测试环境
• 维护测试环境

结果

• 测试环境处于可测试的就绪状态
• 将测试环境的状态传达给所有利益相关方
• 维护测试环境

信息项

• 测试环境
• 测试数据
• 测试环境准备报告
• 测试数据准备报告
• 测试环境变更

测试执行过程

目的–在准备的测试环境中，运行测试设计和实现中的用例集、测试规程

输入

• 测试计划
• 测试规程
• 测试项
• 测试依据
• 测试环境准备报告
• 测试环境变更

活动和任务

• 执行测试规程
• 比较测试结果
• 记录测试执行

结果

• 执行测试规程
• 记录实测结果
• 比较实测和预测结果
• 确定测试结果

信息项

• 实测结果
• 测试结果
• 测试执行日志

测试事件报告过程

目的–向利益相关方报告执行结果，并另一步的操作后续

输入

• 测试结果
• 测试规程
• 测试用例
• 测试项
• 测试依据
• 测试执行日志

活动和任务

• 分析测试结果
• 创建/更新事件报告

结果

• 分析测试的结果
• 确认新的事件
• 创建新的事件报告细节
• 确定以前发生的事件的状态和细节
• 适当地更新以前提交的事件报告细节
• 像利益相关方传达新的或更新的事件报告

信息项–事件报告

测试监测和控制过程

目的–保证测试工作按照规格说明书进行的

输入

• 测试计划
• 适用的产品文档
• 组织级测试方针
• 组织级测试策略
• 控制指令
• 测度

活动和任务

• 准备
• 监测
• 控制
• 报告

结果

• 建立监测测试进度和风险变化的适当测度的收集方法
• 监测测试计划进度
• 识别、分析与测试相关的新风险和变更风险，并采取必要错误
• 确定必要的控制措施
• 向利益相关方传达必要的控制措施
• 批准停止测试的决定
• 向利益相关方报告测试进度和风险变化

信息项

• 测试状态报告
• 测试计划变更
• 控制指令
• 项目和产品风险信息

测试完成过程

目的–对测试项目进行总结

输入

• 项目测试计划
• 阶段测试计划
• 事件报告
• 项目测试状态报告
• 阶段/类型测试完成报告
• 组织级测试策略

活动和任务

• 存档测试资产
• 清理测试环境
• 识别经验教训
• 总结测试完成情况

结果

• 测试资产存档或直接传递给利益相关方
• 测试环境处于约定状态
• 满足并验证所有的测试要求
• 编写测试完成报告
• 批准测试完成报告
• 将测试完成报告发送给利益相关方

信息项–测试完成报告

动态测试过程

定义动态测试通用的过程，包括4个子过程，分别为测试设计和实现过程、测试环境构建和维护过程、测试执行过程、测试事件报告过程

静态测试过程

不运行程序代码的情况下，通过质量准则对测试项进行检查的测试

目的–通过人工的方式或相关的工具对代码进行走查、审计，去发现代码中的问题

输入

• 包含需求规格说明、软件设计说明在内的产品说明文档
• 包含用户使用手册、使用帮助在内的用户文档
• 软件源代码

活动和任务

• 计划
• 启动评审
• 个人评审
• 问题交流与分析
• 修正和报告

结果

• 确定工作产品中的缺陷或问题
• 工作产品评估的质量特征
• 评审结论
• 达成的一致意见
• 工作产品需要进行的更新

信息项

• 问题日志
• 事件报告
• 评审报告

测试文档标准

测试技术标准

基于规格说明的技术（下午题常考）

依据–软件规格说明书

特点–不考虑程序的内部结构和逻辑，只关注程序是否能按照规格说明书使用

可解决的问题

• 如何测试功能的有效性
• 何种类型的输入会产生好的测试用例
• 软件是否对特定的输入值敏感
• 如何分割数据类的边界
• 软件能够承受何种数据率和数据量
• 特定类型的数据组合会对软件产生何种影响

等价类划分

等价类划分–依据程序规格说明书，把程序的输入域分成若干个部分，从每个部分中选择少数的测试数据，代表该区域进行测试

价值–减少了工作量，提高了效率

等价类–某个输入域的子集，在该子集中，各个输入数据对应的程序产生的错误是等效的
有效等价类–在需求规格说明书，合理、有意义的输入数据构成的集合
无效等价类–在需求规格说明书，不合理、无意义的输入数据构成的集合

等价类划分步骤

1. 先从程序规格说明书中找出各个输入条件
2. 再为每个输入条件划分等价类，形成若干互不相交的子集
3. 列出等价表
   

等价类划分原则

• 在输入条件规定了取值范围或值的个数的情况下，可以确定一个有效等价类和两个无效等价类（原则1）
• 在输入条件规定了输入值的集合或规定了“必须如何”的条件的情况下，可以确定一个有效等价类和一个无效等价类（原则2）
• 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类（原则3）
• 在规定了输入数据的一组值（假定n个），并且程序每一个输入值分别处理的情况下，可确定n个有效等价类和一个无效等价类（原则4）
• 在规定了输入数据必须遵守的规则的情况下，可确定一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）（原则5）
• 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类（原则6）

测试用例的设计步骤

1. 为每个等价类规定一个唯一的编号
2. 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖
3. 设计一个新的测试用例，使其支付该一个无效等价类。重复这一步使所有无效等价类均被覆盖

分类树

分类树–等价类划分的另一种方式，将输入域划分为子集的方法，在ai中广泛应用

与等价类的区别–区域之间是否存在重叠的情况，等价类允许有重叠的现象，分类树完全不相交

设计测试用例的步骤

1. 识别出测试对象并分析输入域
2. 对测试对象的输入域进行分类
3. 画出分类树、组合成测试用例，组合测试用例需要注意逻辑兼容性，交集不能为空

边界值分析

边界值分析–在等价类的基础上，选择测试数据为边界

二值基本边界值分析–边界值要挑正边界以及边界外的最小单位值

三值基本边界值分析–边界、超过边界最小的变化单位，边界内的最小的变化单位

最坏情况边界分析–“多缺陷”假设

健壮性最坏情况测试–实际上是三值边界

语法测试

语法测试–针对于形式规格说明书的测试技术

语法测试测试用例的设计规则

• 每当语法强制选择时，就为该选择的每个备选方案导出一个“选项”
• 每当语法强制执行迭代时，为此迭代导出至少两个“选项”，一个包含了最小重复次数，另一个则大于最小重复次数
• 每当迭代被要求具有最大重复次数时，为此迭代导出至少两个“选项”，一个具有最大重复次数，另一个则超过最大重复次数
• 对于任何输入，可以对定义的语法改变以导出无效输入（“变异”）

组合测试设计技术

组合测试–运用于多选项的测试技术

组合测试输入数据要求

• 参数取值范围必须是可离散的（不能是连续的）
• 连续的参数或过多的取值需进行划分子集（可采用等价类、边界值、分类树等）

组合测试的实施步骤

1. 识别出所需测试的软件功能，以及影响被测软件功能的参数
2. 依据1的结果，识别每个参数的取值范围
3. 依据1的结构，识别出参数间的约束，依据约束的强度设定组合强度
4. 依据3中设定的组合强度，选择对应的组合测试方法，生成与组合测试强度相符的测试覆盖项
5. 依据4中的测试覆盖项生成测试用例，直到每个测试覆盖项都包含在至少一个测试用例中

组合强度

• 单一选择–单一选择只需要去考虑单一的条件，单一条件的取值都被测试用例覆盖，可能会出现多种组合方案
• 基本选择–选择第一个条件作为测试用例覆盖项的基础
• 成对组合–被测软件中的任意两个参数，他们的取值范围的任意一对取值范围，至少被一个测试用例所覆盖
• 全组合–被测软件中的所有参数值的任意有效值组合，都要被测试用例覆盖
• K强度组合–在组合要求为k的组合中，任意k个参数的取值范围内有效组合，至少被测试用例所覆盖

判定表测试

判定表–适用于条件存在制约的场景

判断表组成–条件桩、条件项、动作桩、动作项

判定表建立

• 确定规则个数（依据软件规格说明）
• 列出所有的条件桩和动作桩
• 填入条件项
• 填入动作项，制定初始判定表
• 简化，合并相似规则或者相同动作

适合使用判定表设计测试用例的条件

• 规格说明以判定表的形式给出，或很容易转换成判定表
• 条件的排列顺序不影响执行哪些操作
• 规则的排列顺序不影响执行哪些操作
• 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
• 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要

因果图

因果图适用于输入和输出之间存在约束的情况

因果图导出测试用例的步骤

• 分析程序规格说明的描述中：原因和结果
• 分析程序规格说明描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”
• 标明约束条件
• 把因果图转换成判定表
• 为判定表中每一列表示的情况设计测试用例

状态转移测试

状态转移测试–软件若干个状态之间的转换条件或转换路径抽象出来，从覆盖所有的装填转移路径的角度去设计测试用例，关注状态转移是否正确

状态转移测试的步骤

• 画出状态转移图
• 根据转移图，列出状态——事件表
• 根据转移图，画出状态转换树
• 根据状态转换树，按照单步转移覆盖的要求，推导测试路径
• 根据测试路径逐一编写测试用例

场景测试

通过去描述所经过的路径，来确定工作的过程，遍历所有可能的场景，完成对系统的测试

场景法=基本流+备选流

随机测试

取一个随机值对系统进行测试

测试设计方法选择策略

• 首先采用分类树或等价类对函数的输入域进行划分
• 在任何情况下都必须使用边界值分析方法
• 对于参数配置类的软件，要用组合测试技术选择较少的组合方式达到最佳效果
• 如果程序的功能说明中含有输入条件的组合情况，则可选用因果图法绘制判定表，然后采用判定表法继续进行测试
• 对于业务流清晰的系统，可选择场景测试
• 对于明确存在不同状态转移的软件，可选择状态转移测试
• 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度
• 如测试用例自动生成和使用中可以结合被测软件时间，考虑选用分类树、状态转移测试、随机测试等多种方式
• 对于形式化方式定义的规格说明，可选择语法测试

测试用例的编写

• 分析被测软件的相关测试依据，将待测的特征组合成特征集，记录在测试设计规格说明中
• 根据测试计划中规定的测试完成准则，确定每个特征的测试条件，并记录在测试设计规格说明中
• 根据测试条件，导出测试覆盖项，记录在测试用例规格说明中
• 根据测试覆盖项，导出测试用例，并记录在测试用例规格说明中
• 根据执行的约束将测试用例汇集到一个或多个测试集中，记录在测试规程规格说明中
• 根据前置条件和后置条件，一级其他测试要求所描述的依赖性，对测试集中的各测试用例进行排序，导出测试规程，并将其记录在测试规程说明中

历年下午题典型考点

• 等价类划分法–常考
• 边界值分析法–常考
• 场景法–早期常考
• 因果图法–早期常考
• 黑盒测试的方法–简答题

基于结构的技术（下午题常考）

静态测试技术

静态测试技术是指在不运行程序代码的情况下，通过质量准则对软件系统进行检查的测试技术

常见技术为代码检查、编码规则检查、静态分析

代码检查

在编译和动态测试之前进行代码检查，能够快速找出软件的缺陷，而且看到的是缺陷的本质，有效去发现30%-70%的逻辑设计和编码的缺陷，但是测试效率较低，对测试人员的经验和知识有一定的要求

具体检查形式为代码审查、代码走查
代码审查–根据所使用的语言和编码的规范，确定审查所有的检查单，检查检查单中的设计是否符合软件规格说明书，主要目的检查代码逻辑、结构、可读性等方面

代码走查–由测试组的人员，集体去扮演计算机的角色，沿着程序的逻辑逐步去运行设计好的测试用例，来检查软件是否存在缺陷

代码检查的常见项目

• 检查变量的交叉引用表
• 检查标号的交叉引用表
• 检查子程序、宏、函数
• 等价性检查
• 常量检查
• 标准检查
• 风格检查
• 比较控制流
• 选择、激活路径
• 对照程序的规格说明，比较实际的代码和期望的代码，从差异中发现问题和错误
• 补充文档

静态分析

静态分析法是根据既定的外生变量值求得内生变量的分析方法，是对已发生的经济活动成果，进行综合性的对比分析的一种分析方法

控制流分析
数据流分析
接口分析
表达式分析

控制流分析

通过生成程序的有效控制流头来对代码进行分析，圆圈表示一个节点，一般对应一个语句或是一组语句，箭头表示控制流的方向

汇聚节点–在执行过程中，没有共同执行的语句，需要加一个空结点作为汇聚节点

圈复杂度

• V（g）=边的数量-节点数量+2
• V（g）=判断节点数+1
• V（g）=封闭区域数+1

圈度复杂性建议

• 通过圈复杂度，可以发现代码状况极复杂的模块或方法，这样的模块或方法也许可以进一步细化
• 尽可能使圈复杂度不超过10
• 圈复杂度高的模块及方法，其中的缺陷个数也多，测试时需重点测试。

独立路径条数= V（g）

函数调用关系图
扇入-函数被调用的数量，扇入越大，被重复利用性越高，通用性越强
扇出-完成其功能需要调用其他模块的数量，扇出不建议大于7

数据流分析

通过“定义-使用对”能发现缺陷

• 所使用的变量没有被定义（未定义），严重错误
• 变量被定义，但从来没有使用（未使用），可能是编程错误
• 变量在使用之前被定义了两次（重复定义），可能是编程错误
• 撤销变量之后再使用，严重错误（考虑变量撤销情况）
• 变量被定义随后又被撤销随后又被定义，可能是编程错误（考虑变量撤销情况）
• 所撤销的变量没有被定义，可能是编程错误（考虑变量撤销情况）
• 变量撤销后又再次被撤销，可能是编程错误（考虑变量撤销情况）

接口分析

主要是检查接口一致性

• 形参与实参类型、数量、维数、顺序、使用上的一致性
• 全局变量和公共数据区在使用上的一致性

表达式分析

表达式分析纠正的错误

• 在表达式中不正确地使用了括号造成错误
• 数组下标越界造成错误
• 除数为零造成错误
• 对负数开平方，或对Π求正切造成错误

基于结构的动态测试用例设计原则

• 保证一个模块中的所有独立路径至少被使用一次
• 对所有逻辑值均需测试true和false
• 在上下边界及可操作范围内运行所有循环
• 检查内部数据结构以确保其有效性

基于控制流设计用例

• 语句测试
• 分支测试
• 判定测试
• 分支条件测试
• 分支条件组合测试
• 修正条件判定覆盖测试
• 数据流测试

语句测试

覆盖要求：选择足够多的测试数据，每条语句都要遍历
语句测试覆盖度较低，对于逻辑或、与写错的逻辑语句中，可能会检测不出来

分支测试

对于逻辑或、与的逻辑语句中，可能会检测不出来，测试覆盖项为每一个分支

判定测试

分支测试与判定测试的区别

分支条件测试

每一个判定语句的取值，以及判定条件的取值，都要被覆盖
对于逻辑或、与写错的逻辑语句中，可能会检测不出来

分支条件组合测试

每一个判定中所有条件的取值的组合
覆盖强度最强，但是测试工作量较大

修正条件判定覆盖测试

1.MC/DC首先要求实现分支条件覆盖
2.再次基础上，对于每一个条件C，要求存在符合一下条件的两次计算：

• 条件C所在判定内的所有条件，除条件C外，其他条件的取值完全相同
• 条件C的取值相反
• 判定的计算结果相反

数据流测试

定义–使用
定义–给变量赋值的过程，一个变量可能会进行多次定义
使用–用到了变量但是没有赋值，分为计算使用、谓词使用
计算使用–一个变量定义其他变量，或者作为其他变量的输出
谓词使用–作为判定的条件

特征集–要测试的程序代码

测试条件–定义-使用对

测试覆盖项

• 全定义测试–从变量定义到使用的控制子路径，强调的是定义到使用
• 全计算使用测试–从变量的定义到计算使用的控制子路径
• 全谓词使用测试–从变量的定义到谓词使用的控制子路径
• 全使用测试–谓词使用和计算使用都要覆盖
• 全定义–使用路径测试—从定义到使用的所有子路径

基于结构的测试辅助技术

词法和语法分析

• 标号交叉引用表
• 变量交叉引用表（变量定义与引用表）
• 子程序、宏和函数表
• 等价表
• 常数表

程序插桩和驱动技术

• 程序插桩技术
• 程序驱动技术

ESTCA覆盖准则

• 对于A rel B（rel可以是<、>、=）型分支谓词，应适当地选择A与B的值，使得当测试执行到该分支语句时，A>B、A<B、A=B的情况分别出现一次
• 对于A rel C（rel可以是<、>；A是常量，C是常量）型分支谓词，当rel为<时，应适当选择A的值，使A=C-M；当rel为>时，应适当选择A的值，使A=C+M；M是最小单位的正数，若A和C均为整型，则M=1
• 为了检测程序语句中的错误，如该引用变量的却引用了常量，对于外部输入变量赋值，使其在每一测试用例中均有不同的值和符号，并与同一组测试用例中其他变量的值和符号不一致

层次LCSAJ覆盖准则

1. 语句覆盖
2. 分支覆盖
3. LCSAJ覆盖（即程序中的每一个LCSAJ都至少在测试中被经历过一次）
4. 是两两LCSAJ覆盖（即程序中的每两个首尾相连的LCSAJ组合起来都至少在测试中被经历过一次……知道第n+2层，每n个首尾相连的LCSAJ组合起来都至少在测试中被经历过一次）

最小用例数计算

基于经验的技术

错误猜测法

基于测试人员对以往测试项目中的经验，去设计相关的测试用例，用于预测软件的缺陷和失效

软件错误类型

• 软件需求错误–软件需求不合理；软件需求不全面、不明确；需求中包含逻辑错误；需求分析的文档有误
• 功能和性能错误–需求规格说明中规定的功能实现不正确、存在未实现或冗余的情况；性能未满足规定的要求；为用户提供的信息不准确；异常情况处理有误
• 软件结构错误–程序控制流或控制顺序有误；处理过程有误
• 数据错误–数据定义或数据结构有误；数据存取或数据操作有误
• 软件实现和编码错误–编码错误或按键错误；违反编码要求和标准（语法错误、数据名错误、程序逻辑有误）
• 软件集成错误–软件的内部接口或外部接口有误；软件各相关部分在时间配合、数据吞吐量等方面不协调

估算错误数量的方法

探索性测试

基于现在的相关知识，去探索性测试

目的–帮助测试人员理解测试需求

分类

• 自由式探索性测试
• 基于场景的探索性测试
• 基于策略的探索性测试
• 基于反馈的探索性测试
• 基于会话的探索性测试

探索性测试风格

• 预感
• 模型
• 示例
• 不变性
• 干扰
• 错误处理
• 故障排除
• 小组洞察
• 规范

探索性测试的相关方法

• 5个部分：输入、状态、代码路径、用户数据、执行环境（局部探索性测试）
• 不能应用测试用例的整体设计（局部探索性测试）
• 决定了总体探索策略和产品特性的测试方法（全局探索性测试）
• 用于指导整体的测试过程，帮助测试人员设计整体的测试策略（全局探索性测试）

探索性测试的优点

• 在测试设计不充分的情况下，探索性测试可以基于之前类似的测试和结果进行测试
• 在早期需求模糊或系统不稳定时，探索性测试可以不受限制地在短时间内对产品质量进行反馈
• 当发现缺陷时，探索性测试可以快速向开发人员提供针对缺陷的严重程度、涉及范围和变化的反馈
• 探索性测试可以作为脚本测试的一个重要补充，以检测出脚本不能监测到的缺陷

探索性测试的局限

• 探索性测试无法对被测对象进行全面性测试，测试结果一般不易度量，不能确保发现最重要的软件缺陷
• 脚本测试可以在需求收集阶段编制测试用例，根据用例的执行来发现缺陷，而探索性测试缺少预防缺陷的能力
• 对于已经确定了测试类型和执行顺序的测试来说，直接编写测试脚本并执行比进行探索性测试更有意义
• 依赖测试人员的领域知识和测试技术，探索性测试不容易协调及调整，导致测试效率低下，缺乏条理

基于检查表的测试

通过设计对应的检查点，去检查软件对于检查点的情况是否符合需求

构建检查表–基于经验、对用户重要内容的了解、对软件错误的原因和方式的理解、检查项源于以往的经验总结且可测试量

支持测试类型–各种类型测试

基于代码检查表测试的主要检查点

• 格式规范性–嵌套的IF语句是否正确地缩进、注释是否准确并有意义、使用的标号是否有意义、代码与开始时的模块模式是否一致、整体上是否遵循全套的编程标准
• 入口和出口的连接–初始入口和最终出口是否正确；跨模块调用时，是否完整地传递所需的参数；是否正确地设置了被传送的参数值；是否对关键的被调用模块的意外情况进行处理
• 程序语言的使用–使用的动词是否合适、模块中是否使用完整定义的语言的有限子集、跳转语句是否适当
• 存储器使用–首次使用域之前是否经过正确的初始化、规定的域是否正确、每个域是否有正确的变量类型声明
• 判断和转移–正确的条件是否经判断、用于判断的是否是正确的变量、转移目标是否正确并能够被至少执行一次
• 性能–每个逻辑是否实现了最佳编码、是否提供正式的错误/例外子程序
• 可维护性–清单格式是否有助于提高可读性、标号和子程序是否符合代码的逻辑意义
• 逻辑性–全部设计是否都已实现、代码实现是否和设计一致、循环语句是否能够执行其设定的次数
• 可靠性–是否确认外部接口采集的数据、是否遵循可靠性编程要求
  基于文档检查表测试的主要检查点
• 可用性–是否提供纸质或电子介质的文档
• 内容–功能是否可以被测试或验证
• 标识和标示–文档的封面、页面/页脚或其他地方应具有唯一性标识；文档中应包含名称、版本及发布日期的软件产品标识；文档中应包含供方的名称和地址信息
• 完备性–文档是否包含使用软件必需的信息；文档是否清晰陈述软件产品所有功能及用户能调用的所有功能；文档是否对软件运行过程中的差错和缺陷进行说明；文档是否包括执行应用管理智能所有必要的信息
• 正确性–文档中包含的信息是否恰当且适合目标用户阅读使用；文档中包含的信息是否正确，没有歧义
• 一致性–文档中的表述不应自相矛盾
• 易理解性–文档中出现的术语可以被理解；文档是否包含清晰的组成文档清单或覆盖范围说明

软件测试工作量及成本估算

软件测试成本构成：直接成本（测试人工成本、测试环境成本、测试工具成本）、间接成本（办公成本、管理成本）

软件测试成本调整因子

• 软件复杂度–从软件规模、难度、结构等方面进行度量
• 软件完整性–与系统的风险等级有关，风险越高，完整性级别越高
• 测试风险度–测试过程中存在风险的程度
• 回归测试
• 加急测试
• 现场测试
• 评测机构资质

软件测试成本度量的实施步骤

自动化测试技术

自动化测试–把人为的手动测试行为转化为机器执行的过程

自动化测试

• 测试活动的自动化
• 测试过程管理的自动化
• 测试自动化不仅是技术、工具的问题，更是一个公司和组织的文化问题
• 自动化测试执行技术
• 自动化测试设计技术

自动化测试的目的：帮助测试寻找问题、协助问题的诊断、节省测试时间

自动化测试的分类

• 按自动化的流程环节分：自动化测试设计、自动化测试执行
• 按测试目的划分：功能自动化测试、非功能自动化测试（性能自动化测试、信息安全自动化测试）
• 按测试工具所访问和控制的接口划分：用户界面自动化测试工具、接口自动化测试工具
• 按测试工具所重点对应的测试阶段划分：单元自动化测试工具、集成自动化测试工具、系统自动化测试工具（系统级别自动化测试为用户界面自动化测试）
• 按测试对象所在操作系统平台划分：web应用测试、安卓移动应用测试、iOS移动应用测试、Linux桌面应用测试、windows桌面应用测试

自动化的优点

• 提高测试质量
• 提高测试效率，缩短测试工作时间
• 提高测试覆盖率
• 执行手工测试不易完成的测试任务
• 更好的重视软件缺陷的能力
• 更好地利用资源
• 增进测试人员与开发人员之间的合作伙伴关系
• 能执行测试步骤更长，综合性更强的测试用例
• 更快地反馈软件质量
• 提高系统的稳定性和可靠性

自动化的缺点

• 产生开发成本
• 需要测试技术团队
• 脚本维护成本高
• 无创造性
• 引入更多的复杂性
• 容易出现偏离原始的测试目标
• 可能引入额外的错误

自动化测试局限性领域

• 定制型项目
• 周期很短的项目
• 业务规则复杂的对象
• 人体观感与易用性测试
• 不稳定的软件
• 涉及物理交互

自动化测试不正确的期望

• 自动化测试可以完成一切测试工作
• 测试工具可适用于所有的测试
• 测试工具能时工作量大幅度降低
• 测试工具能实现100%的测试覆盖率
• 自动化测试工具容易使用
• 自动化测试能发现大量的新缺陷

自动化测试的通用架构

自动化测试时间策略

适合使用自动化测试工具的情形

• 被测试系统具备足够的易测试性
• 需求稳定，不会频繁变更
• 每日构建后的测试验证
• 研发和维护周期长，需要频繁执行回归测试
• 软件系统用户界面稳定，变动少
• 需要在多平台上运行的相同测试案例
• 项目进度压力不太大
• 测试人员具备较强的编程能力

开展自动化测试的必要条件

• 具备足够的易测试性
• 软件需求变动较少
• 项目周期较长
• 自动化测试脚本可重用

基于模型的自动化技术

优点

• 测试涉及的自动化能改善工作效率和减少人为错误
• 尽早建立测试模型能改善沟通，提前发现需求中的缺陷
• 使得不了解测试设计技术的业务分析人员也能实施测试设计
• 提高测试覆盖，从而改进软件产品的质量
• 缩短测试设计的周期，加速测试活动

缺点

• 从模型生成测试用例数量可能过多
• 建模需要一定的投入
• 模型也可能描述错误
• 模型的抽象可能带来理解上的困难

工具实现

• 微软的spec explorer
• Graphwalker
• stoat
• MBT On Cloud

基于搜索的测试技术

优点–把测试用例生成问题灵活转化为在特定软件对象的输入域中搜索更优的问题

局限性

• 变异操作可能产生大量输入事件序列无效的测试用例
• 移动应用软件是事件驱动的，其测试输入是一条事件顺序敏感的事件序列，而遗传算法的三种操作很可能破坏这种顺序关系，从而产生大量无效的测试用例，影响测试效率

工具实现–Sapienz

测试执行的自动化技术

测试工具的选择

• UFT
• Robot Framework
• Selenium
• Appium

自动化测试语言的选择

• python
• java
• go

测试输入的设计与实现

• 制定测试计划
• 分析测试需求
• 设计测试用例
• 搭建自动化测试框架
• 编写测试脚本
• 执行测试

测试输出结果的收集与分析

• 测试结果
• 跟踪测试缺陷
• 持续集成和自动化测试

基于风险的测试技术

基于风险测试概述

制定测试计划阶段

• 要测试什么，不要测试什么

内容、目标
要达到的质量要求尽量明确
让利益相关方都能理解并达成共识

• 如何测试

设计测试
确定目标、选取合适的测试设计技术
执行测试
明确测试工具、确定测试环境、确定测试轮次

• 测试实施资源安排

各种资源
说服项目利益相关方进行足够的测试投入

基于风险的测试计划制定

• 风险更容易被各方理解和接受
• 发现和缓解风险能更好地完成测试任务
• 减少风险符合相关方的自身利益

风险测试的相关概念
风险–在软件测试项目中，带来的不确定性和可能发生危险的情况，危险一旦发生会对项目产生影响
风险识别–识别可能对测试项目产生影响的风险，并形成一个文档
风险分析–对识别出来的风险进行优先级排列（定性分析），给出量化指标（定量分析）
风险控制–风险管理计划、风险降低、风险化解

测试计划内容

一般应用于商业产品、非安全攸关的产品或服务

风险分析和缓解措施设计

风险识别是基于风险测试的起点，主要方法为专家访谈、头脑风暴、采用风险框架、检查表
风险识别-其他获取风险的来源

• 各种规格说明
• 实现的细节
• 销售、市场资料
• 竞争对手的研究
• 独立评估机构
• 过去历史项目
• 个人的历史经验
  
  
  
  风险的影响和发生概率评估
• 风险的影响
• 风险发生概率和影响分析的基本框架
• 实际上基于风险的测试计划中的风险分析
• 区分能通过软件测试活动来缓解的风险

风险的影响和概率评估

实际上基于风险的测试计划中的风险分析

• 区分能通过软件测试活动来缓解的风险
• 从业务出发，估计风险的影响
• 从业务出发，估计在最终产品中允许的残留风险发生的概率
• 从产品开发测试出发，了解当前产品中风险发生的概率

上市后产品中允许的残留风险发生概率估计–设置质量目标

• 企业组织的质量政策中有相关的规定
• 对于没有相关规定的组织或项目

与利益相关方沟通，参考竞品来获取对产品质量的总体期望
对于全新的产品或无法从利益相关方处获取信息的，则从测试经理的经验/测试团队的头脑风暴/产品的使用场景的列举，推算使用场景中出现失效的受容忍的程度

对产品开发测试中遇到风险发生概率的处理原则

• 当功能还未开发时（或完成度很低时），其发生概率100%
• 当开始测试活动时，测试结果的通过率可以近似地作为开发测试中遇到风险的概率

风险的缓解措施

风险的优先级：
R=P×I
R=(C-P)×I

风险与缓解措施：测试策略

• 测试级别的划分，能对应解决软件开发的复杂性问题
• 测试类型的设计和安排，将测试类型安排在最适合对应的测试级别中来识别和缓解产品风险
• 测试设计方法，在每个测试级别和类型中，都需要进行测试设计和执行的工作
• 测试执行方法，对每个测试级别和测试类型都是具体地设计安排对应测测试执行手段
  

一般性的缓解措施指南（系统复杂性非常高）

• 对测试级别进行定义和划分（主测试计划）
• 定义各个测试级别所应达成的质量目标（主测试计划）
• 可以对各个级别的测试活动所应采取的测试类型、测试技术、工具和环境做出初步的指导性说明，并对测试活动所需要的预算进行一个框架性定义（主测试计划）
• 系统的复杂性风险是大型软件系统的核心风险之一（主测试计划）
• 各团队指定的测试负责人来分别制定各自测试级别的测试计划（分级别的测试计划）

测试风险缓解措施的基本步骤

• 安排测试级别来对应软件系统的复杂度风险
• 根据各个测试级别的特点和资源情况安排，通过特定的测试类型在本级别内对应特定的质量特性风险
• 在安排测试类型后，考虑采用哪些测试设计方法设计测试用例
• 根据与被测对象的交互方式、可能的测试环境、测试工具的情况来设计测试执行的方法

测试级别与测试实施

各测试设计技术对应的测试条件描述

• 等价类划分
• 边界值
• 分类树
• 语法测试
• 组合测试
• 判定表测试
• 因果图测试
• 状态转移测试
• 场景测试
• 随机测试
• 各种基于规格说明的测试设计方法

测试执行方法的设计和指导的内容

• 测试执行的环境设计
• 测试执行的方法定义
• 测试执行的周期和回归策略

单元测试设计与实施

• 对单元的明确功能选择基于规格说明的测试设计技术
• 对于单元输入的各项参数可以采用等价类划分、边界值、组合测试技术
• 对于有着明确的状态和转移定义的模块，应采用状态转移测试进行覆盖
• 对于有着明确逻辑判定的规格要求的，应采用判定表技术
• 通过代码覆盖度量工具可对执行以上测试用例时达到基于结构的测试设计技术覆盖进行度量；未能达到覆盖目标的部分代码，通过基于结构的测试设计技术来补充测试用例进行覆盖
• 一般对生命攸关系统中关键模块、核心算法模块，有法规或行业标准要求必须达成某种代码覆盖

集成测试设计与实施

• 以场景测试为主要测试设计技术
• 为了在场景中找出异常或极端的情况，可对通信消息的内容参数或调用的接口参数及返回值，应用等价类和边界值方法
• 对于通过异步通信来进行的模块间交互协调，还应考虑异步通信带来的固有风险
• 对于有状态转移的模块间交互协调，可采用状态转移测试，测试多个状态机间同步的情况
• 语句测试，设计测试用例覆盖序列图、活动图、流程图的每个交互和处理
• 分支测试、判定测试等可用于设计测试用例来覆盖序列图、活动图、流程图里的条件判定

集成测试工具应具备的功能

• 获取模块间调用的信息
• 根据测试要求匹配模块间调用（响应）
• 根据测试要求修改模块间调用（响应），包括修改调用的方法和参数内容
• 根据测试要求重复模块间调用（响应）
• 根据测试要求丢弃模块间调用（响应）
• 根据测试要求延迟发生模块间调用（响应）

验收测试设计与实施

• 从系统测试用例中随机抽取一些基本使用场景
• 从用户实际的使用环境中，能够正常使用功能，没有基本功能的异常
• 通常以手工测试为主

测试估算与平衡决策

分层架构软件测试（下午题常考）

分层架构是一种软件架构的范式，将软件分为若干个层次，每一层有各自的职责，层和层之间通过接口来交互和传递信息

分层架构的优点

• 复用性强
• 利于合作开发
• 分层独立
• 维护方便

分层架构的缺点

• 性能下降
• 成本增加

表示层（用户界面层）

表示层负责业务和视图的展开

表示层质量特性

常规测试项

• 内容显示和必输项检查–名称是否显示正确、是否是必输项、初始值及状态检查、元素关联性检查、信息内容正确性检查、控件类型是否显示正确（输入、输出、可视）
• 按钮/链接正确性检查–按钮/链接点击后在没有得到返回钱按钮需不可用、点击按钮/链接后可正常跳转到相应界面或窗口或执行
• 通用检查–风格一致（与同类界面视觉风格、字体、图标一致）、标题显示（界面标题和任务栏显示的标题正确）、元素位置（元素水平、垂直对齐）、元素尺寸（元素尺寸合理，行列间距一致）、窗口特性（切换、移动、改变大小、刷新时界面正常）

基于web端的表示层测试

• 浏览器可移植性测试–浏览器矩阵
• 页面性能测试–响应时间的可接受度
• web端涉及的质量特性–可移植性、易用性、性能效率

基于pc端的表示层测试

• 安装/卸载测试
• 在线升级测试
• 网络切换测试
• 可移植性测试
• pc端涉及的质量特性–可移植性、易用性、功能性

基于移动端的表示层测试

• 安装/卸载测试
• 切换测试（网络切换、前后台切换）
• 在线升级测试
• 安全测试（软件权限、应用安全）
• 性能测试（启动耗时、CPU、内存、耗电量、流量、功耗、流畅度）
• 可移植性测试
• 移动端涉及的质量特性–可移植性、易用性、性能效率、功能性、安全性

表示层测试策略

表示层测试设计和实施的原则

• 从软件需求分析和用户界面设计阶段，测试人员职责是参入同行评审，了解软件需求和用户界面要求，以及使用场景和用户特点，根据经验，从测试角度提出建议
• 测试人员在用户界面设计阶段结束后，可以提出对易用性问题的主观看法
• 在测试设计阶段，测试人员职责是根据软件需求规格说明书、用户界面设计以及软件人机交互友好性、易用性的测试准则设计测试用例
• 在测试实施阶段，测试人员职责是执行测试用例
• 由于版本的更新，需求的更动，可能涉及用户界面的回归测试
• 在上线之前，用户界面测试与功能测试同步确认一次，保证与最终版本的一致性
• 一般情况下表示层测试不作为专项测试内容，可与其他质量特性的测试混合进行

服务层（应用层）

服务层为表示层提供各种服务的支持

服务层质量特性

• 功能性测试–业务功能性测试（场景、异常场景）、边界测试（基于输入输出的边界测试）、单接口的不同参数组合测试、多接口的不同业务组合（业务流）测试
• 信息安全性–敏感信息是否加密、身份认证、注入、信息泄漏等
• 性能测试–响应时间、吞吐量、并发数、服务器资源（CPU、IO、内存、网络）

服务接口层测试设计和实施的原则

• 越早越好，越早发现bug，修复成本越低
• 检查接口的功能、性能
• 对于前后端架构分离的系统，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求，需要后端从接口层进行验证；前后端传输数据等信息是否加密传输需要验证
• 接口测试比较容易实现自动化测试

接口测试质量评估的原则

• 业务功能覆盖是否完整
• 业务规则覆盖是否完整
• 参数验证是否达到要求（边界、业务规则）
• 接口异常场景覆盖是否完整
• 性能指标是否满足要求
• 安全指标是否满足要求

业务逻辑层

业务逻辑层负责业务的规则、逻辑的实现

业务逻辑层质量特性

• 功能性–针对功能点、针对业务流
• 信息安全性–通过源代码审计的测试方法进行检测、常见的代码错误（编码错误、编码规范、重复、复杂度、注释解释）

针对功能点的功能性质量特性

• 对功能模块中所有存在输入条件的功能进行测试
• 对功能模块中所有存在输入结果的功能进行验证测试
• 对功能模块中所有存在业务规则的功能进行测试
• 对功能模块中存在异常情况或错误数据处理的功能进行测试
• 验证是否满足需求要求的所有功能，强调业务功能的完整性
• 验证功能实现是否满足用户需求和系统设计的隐藏需求，强调业务功能的适合性

针对业务流的功能性质量特性

• 对流程中调用的对外接口进行测试
• 对流程中的入口条件进行测试，验证其处理逻辑、错误控制等
• 对主要的流程进行逻辑正确性验证，再覆盖多个流程分支的全流程测试

业务逻辑层测试策略

• 业务功能测试策略–测试需求分析、测试用例设计、用例评审、测试实施执行
• 代码审计测试策略

数据层

数据层提供数据管理服务

数据层质量特性

• 数据库可靠性
• 数据库性能效率
• 数据库安全性
• 数据正确性与完整性
• 数据库功能性
• 数据可移植性

数据库安全性策略–一般用基于规格说明的测试技术，以人工功能检查为主要形式，检查内容为用户及口令管理、授权和审计管理、数据加密

性能效率策略–采用TPC的性能测试标准和规范

数据的可靠性策略–联机备份、故障恢复

数据的正确性与完整性策略–采用基于规格说明的测试方法，以手工测试为主，测试内容为数据库存储数据的方式、数据类型和长度、数据日期和时间字段、国际化、字符集编码

数据库功能性策略–安装与配置、数据库存储管理、模式对象管理、非模式对象管理、交互查询工具、性能检测与调优、数据迁移工具、作业管理

数据迁移策略–数据迁移测试的原则、数据迁移涉及的用例、数据迁移的测试方法
数据迁移的原则

• 完整性原则
• 正确性原则
• 适用性原则
• 有效性原则
• 安全性原则

数据迁移涉及的用例

• 老到新的记录条数对比
• 老到新的字段的映射关系确认
• 老到新的字段计算方法对比
• 老到新的字段长度与精度是否一致
• 老到新的字符串转移容易产生脏数据
• 老到新的空值与null处理
• 老到新的日期格式变化
• 老到新的废弃字段
• 老到新的新增字段默认值问题
• 老到新的清洗与规范处理，where条件
• 老到新的系统中，雷同字段的差异
• 数据对比
• 从业务上来判断，在应用程序中做一个流程，验证数据是否正常

数据迁移的测试方法

• 技术核验
• 静态对比
• 动态对比
• 业务连续性验证测试

事件驱动架构软件测试

事件驱动架构软件测试是指通过事件进行通信的一种软件架构，关注事件的产生、识别、处理、响应的状态变化

事件驱动架构的优点

• 天然为事件的发生和处理建立了模型
• 事件与事件处理逻辑、事件处理逻辑之间都得到了充分的解耦
• 交互式的响应性能较好

事件驱动架构的缺点

• 要考虑异步通信中的常见问题
• 开发相对复杂，与事件处理相关的点也非常常见
• 同时在实践中，此类缺陷导致的失效往往比较难以复现和定位

事件驱动结构支持的功能

• 事件通知的编码解码（可选）
• 事件通知的发送与接收
• 事件队列的管理与维护
• 事件的注册/注销
• 事件的优先级（可选）
• 事件与注册记录的匹配和过滤
• 事件的广播/转发
• 事件通道的创建、管理与维护（可选）
• 事件处理机制的调用方法
• 事件处理后的返回和后续处理（可选）

事件驱动架构的质量特性

功能性

• 与特定的业务领域密切相关，与架构实现关系比较小
• 功能完备性–基本与架构无关，事件驱动架构能简化复杂交互响应的实现
• 功能正确性–基本与架构无关，由具体的业务逻辑实现决定
• 功能适合性–与架构无关

可靠性

• 事件通知的编码解码
• 事件通知的发送与接受
• 事件队列的管理与维护
• 事件的注册与注销
• 事件的优先级（可选）
• 事件与注册记录的匹配和过滤
• 事件的广播和转发
• 事件处理后的返回/后续处理（可选）

性能效率

• 事件通知的编码解码
• 事件通知的发送与接收
• 事件队列的管理与维护
• 事件的注册与注销
• 事件的优先级（可选）
• 事件与注册记录的匹配和过滤
• 事件的广播和转发
• 事件通道的创建、管理与维护（可选）
• 事件处理机制的调用方法
• 事件处理后的返回/后续处理（可选）

易用性

• 事件通知的编码解码
• 事件通知的发送与接收
• 事件的注册与注销

信息安全性

• 事件通知的发送与接收
• 事件的注册与注销（跨越不同地域、网段的子系统）

兼容性

• 事件通知的编码解码
• 事件通知的发送与接收
• 事件的注册与注销
• 事件的优先级（可选）
• 事件的广播和转发

维护性

• 在事件驱动架构下，一般很少出现维护性问题
• 可测试性–事件收发机制、事件队列和分发器组件、事件的注册/注销、事件处理机制的调用

可移植性–在事件驱动架构下，一般很少出现移植性问题

事件驱动架构的测试策略

通常采用分层测试策略

单元测试

• 各个组件
• 事件收发模块/函数
• 编解码模块/函数
• 事件队列的管理模块/函数
• 通过功能和代码进行覆盖

集成测试–围绕核心功能来设计

系统测试–一般不安排

对事件驱动架构实现的业务逻辑

单元测试–集中在事件处理逻辑中

集成测试

• 优先级机制
• 集成测试可以跳过
• 业务逻辑依赖的事件驱动架构组件未经测试，必须完成集成测试

系统测试

• 基于规格说明书的测试技术
• 通过用于界面或系统接口来实现测试执行

微内核结构软件测试

内核只是最小的功能称为微内核结构

微内核架构概述

核心系统–能运行的最小模块

插件模块

• 专业处理，额外特性的独立组件
• 增加/扩展核心系统的业务逻辑能力
• 连接方式–OSGI、消息机制、WEB服务、直接点对点绑定

插件注册表–每个模块的基本信息（名称、数据规约、远程访问协议）

微内核模式的核心

• 基本服务封装到微内核
• 插件模块负责整合某个特定领域的抽象
• 微内核负责通用的功能抽象
• 应用程序、服务器通过基于“事件”的微内核通信，用来沟通各个不同的模块

微内核架构设计的关键点–插件管理（插件注册表）、插件连接（通信方式连接规范）、插件通信（通信机制）

微内核架构的优点

• 整体灵活高，能够快速响应不断变化的环境
• 易于部署，因为功能之间是隔离的，插件可以独立的加载和卸载
• 可定制性高，适应不同的开发需求
• 可测试性高，插件模块可以单独测
• 性能高

微内核架构的缺点

• 通信效率低，插件通过内核实现间接通信，需要更多开销
• 开发难度较高，微内核架构需要设计，因此实现起来比较复杂
• 通信规约，丰富的插件通信连接方式
• 版本控制复杂

微内核架构的质量特性

功能性

• 加载与移除插件
• 插件的使用测试
• 黑盒测试方法
• 插件管理功能：手工测试

信息安全性

• 插件的安全性进行评估–是否含有病毒、上传用户数据、窃取用于隐私
• 漏洞进行扫描分析

可靠性–应用的稳定性，包括崩溃、闪退、兼容性降低、效率变低

易用性

• 体现为：易操作、易理解
• 方便用户对已加载的插件进行管理或配置插件

微内核架构的测试策略

由需求文档确定本次需求的目标

单元测试–各模块测试，确认功能正常

集成测试

• 内核与插件之间是否存在问题
• 插件与插件之间是否存在问题

系统测试

• 实际运行环境
• 功能测试完成后再考虑兼容性、性能测试

分布式架构软件测试

分布式架构概述

分布式架构是若干独立计算机的特点

特点：内部由多个独立计算机组成，外部呈现是单个系统

分布式架构的组件

• 分布式业务框架
• 分布式缓存和管理组件
• 分布式消息组件
• 分布式数据库
• 分布式文件系统
• 分布式治理组件
  
  优点
• 支持大量并发用户
• 容错和灾备能力
• 可灵活扩展

代价

• 额外的复杂性
• 接口数量的爆炸增加
• 容易出现强耦合导致维护性差
• 信息安全的风险

缺点

• 高维护成本
• 数据/事物处理上的一致性难题
• 逻辑耦合性强，定位问题困难

分布式架构质量特性

功能性

• 功能完备性–与架构实现有一定的关系
• 功能正确性–与架构无关，由具体的业务逻辑实现决定
• 功能适合性–与架构无关，由功能的交互设计和场景决定
• 架构与功能完全分开考虑的缺陷–在不同系统负载和容量情况下，系统所能提供的功能；非法、意外事件；部署、运维和监控功能缺失

数据一致性相关

• 数据一致的牺牲导致业务功能相关的缺陷（影响）
• 错误实现的数据一致性逻辑造成功能性和可靠性的缺陷（影响）
• 数据一致与高可用性的平衡设计不足，影响可靠性（影响）
• 对数据一致性的要求影响系统性能和容量（影响）
• 尽早开始测试和参与软件设计的评审（应对策略）
• 通过场景法设计容错和并发场景（应对策略）
• 进行专门的数据测试来覆盖数据一致性问题（应对策略）

事物处理相关

• 嵌套式事物能较好地保证系统的可靠性但容易导致性能问题（影响）
• 分布式事务在提供较好的性能和扩展性时导致稳定性差（影响）
• 对由嵌套事务模式实现的业务逻辑针对性地设计性能测试和压力测试（应对策略）
• 对由分布式事务模式实现的业务逻辑进行容错性测试（应对策略）

并发、互斥相关

• 出现在业务直接相关区域的错误读写影响业务功能的功能性（影响）
• 出现在服务软件逻辑区域的错误读写影响服务的可靠性（影响）
• 为确保不出现错误的数据读写，过度扩大临界区范围设计导致并发性能下降（影响）
• 分层的测试策略（应对策略）
• 尽早地开展测试活动，参与设计的评审（应对策略）
• 结合软件设计实现并发与互斥的逻辑，通过场景法、边界值、状态迁移法，针对弱点进行覆盖（应对策略）
• 单元测试中，对具体算法/业务/代码逻辑等进行逻辑覆盖和功能覆盖（应对策略）

远程调用和通信相关

• 涉及转换和通信过程，导致通信开销和通信延迟（影响）
• 跨地区/因特网时，导致信息安全风险（影响）
• 远程计算机出现错误时，本地模块崩溃（影响）
• 强调集成测试（应对策略）
• 在各个集成层面上进行性能测试（应对策略）
• 容错的场景涉及覆盖和灾备演练可以在各个集成粒度上进行（应对策略）
• 对于跨因特网或区域的远程调用和通信，组织专门的信息安全测试（应对策略）

运维相关

• 易用性
• 信息安全
• 维护性和可移植性
• 兼容性（共存性）

常见质量目标

• 容量
• 容错
• 响应速度
• 弹性

分布式架构测试策略

总体思想–分而治之，然后再进行综合

单元测试

• 分布式的软件系统：模块/子系统
• 功能测试、代码覆盖、再结合场景测试

接口测试

• 系统内的模块接口
• 应覆盖功能、性能、稳定性、信息安全

集成测试

• 子系统要完成的功能
• 等价类、边界值、场景法、状态迁移
• 性能、并发、容错
• 多个子系统集成

系统测试

• 系统对外的接口
• 基于规格说明的测试技术

移动应用软件测试

移动终端平台和应用软件概述

移动终端平台–Android、iOS

移动应用软件特点

• 多样的交互方式
• 多样的移动设备
• 快速的软件版本迭代

移动应用软件测试

测试方法–人工测试、脚本编程测试

脚本编程测试

• 利用测试脚本编程框架和接口编写测试脚本，然后交由测试框架实施自动测试执行和功能检查
• 利用录制回放工具自动化记录和执行测试脚本

移动应用软件测试的挑战–脚本编程测试的局限性、网络基础设施与架构的多样性、移动设备多样性的挑战

功能测试

• 目标–验证移动应用的功能是否符合预期
• 测试方法–手工测试方法、自动化脚本测试方法

性能测试

• 目标–设备性能、服务器/API性能、网络性能
• 测试方法–一般性能测试需要人工参与观察和统计

易用性测试

• 目标–在开发周期的早期识别出系统中的易用性错误，并可以避免产品出现故障
• 测试主要关注点–软件的有效性、软件的使用效率、软件内容的准确性、用户界面的友好性
• 测试方法–实验室环境的易用性测试、远程易用性测试
• 代表性的测试框架工具–在企业中通过招募部分软件用户实地完成、第三方服务完成

信息安全测试

• 目标–是防止针对移动应用软件的欺诈攻击、病毒或恶意软件感染、尽早发现可能的安全漏洞、非必要的权限许可等
• 测试方法–设计审查、白盒代码安全性检查、黑盒安全审计

可移植性测试

• 目标–是确保移动应用软件在不同的主流移动设备上能够正确安装、启动和卸载，以及能够正确、平稳地运行
• 测试方法–人工测试和众包测试、第三方自动化云测试服务

网络测试

• 目标–模拟不同的网络环境和质量，检测应用软件的健壮性、易用性和稳定性
• 测试方法–通过将移动设备连接到PC上进行网路测试；在专有服务器上构建网络WiFi，移动设备连接该WiFi进行网络测试

物联网软件系统测试

物联网能够让所有被独立运行的物理对象联系在一起

物联网的三个典型特征

• 普适服务智能化
• 自治终端互联化
• 普通对象设备化

物联网应用的三项关键技术–感知层、网络传输层、应用层

安全架构

• 设备层
• 通信层
• 云平台
• 全生存周期管理层

物联网安全架构的设备层

• 定义–设备层是指部署物联网的解决方案时所使用到的硬件，即“物”的实体
• 保护措施–物理安全、芯片安全、安全引导
• 原则–处理复杂度、安全性要求高的任务的前提条件是设备智能化；边缘处理应具有安全优势

物联网安全架构的通信层

• 定义–通信层是指安全发送/接收数据的媒介，即物联网解决方案中的连接网络
• 保护措施–数据加密、访问控制
• 原则–启动与云端的连接安全保障；信息的安全保障

物联网安全架构的云平台层

• 定义–云平台层是指物联网解决方案的后端，主要用于对接收到的数据进行分析和处理
• 保护措施–数字证书、完整性校验
• 原则–设备需要具备识别、认证和加密的功能

物联网安全架构的全生存周期管理层

• 定义–全生命周期管理层是指保证从设备制造、安装到物品处置的整个过程中都有足够高的安全级别，是一个整体性的层级
• 环节–设计、策略执行、定期审核、供应商控制
• 原则–远程控制和更新的安全保障

物联网测试中面临的挑战

• 软硬件协同网络挑战
• 模块交互强连接挑战
• 实时数据测试挑战
• 网络可用性测试挑战

物联网测试类型

• 可用性测试
• 物联网安全测试
• 性能测试
• 兼容性测试
• 监管测试

物联网渗透测试技术

• 威胁建模
• 漏洞利用
• 攻击技术

渗透测试流程

• 信息收集
• 进行分析
• 针对性开发
• 生成报告

大数据系统测试

大数据是指无法在一定时间内用常规的软件工具进行捕捉、管理和数量的数据

大数据的特点

• 数据类型多样
• 数据体量大
• 处理速度高速
• 价值密度低

大数据测试面临的挑战

• 数据的多样性和不完整性
• 高度扩展性
• 测试数据管理

大数据质量检测的测试策略

• 功能测试
• 性能测试
• 数据提取测试
• 数据处理测试
• 数据存储测试
• 数据迁移测试

大数据测试流程

• 用户使用
• 数据收集
• 大数据分析
• 缺陷挖掘

人工智能时代下的软件测试技术发展

人工智能是一种思维与响应的方式，是与人的方式相似思维的计算机技术

人工智能新的特性

• 当前对人工智能系统得到的测试结论，很难保证对演化后的系统也能够成立
• 人工智能系统的输出正确性判别具有一定的不确定性

人工智能对软件测试技术发展的影响

• 测试工作前移
• 自动化程度提高
• 测试项目管理
• 测试需求分析与测试设计
• 测试执行
• 测试更可靠

人工智能是否会取代软件测试人员

• 会取代很大一部分传统岗位（流程性体力工作、数据处理、数据采集）
• 减少技能要求低的岗位，增加高技能的需求
• 不可能完全被取代

人工智能技术在自动化软件测试方面

• 基于约束的技术
• 启发式搜索算法–遗传算法、蚂蚁算法、模拟退火算法

机器学习在软件测试中的应用

• 软件测试设计推荐
• 使用模式识别
• 软件脆弱性测试