【测试人生】《测试架构师修炼之道》阅读笔记

《测试架构师修炼之道》一书，笔者入行一年多的时候拜读过。虽然这本书主要偏向业务测试、质量管理的方向，而并非技术测试、测试开发的方向，但只要是测试行业从业者，笔者认为都值得一看。

从笔者本人角度，对于测试人员的职业发展，是极端推崇技术方向的。但工作最终总会落实到人，测试近年来被划分为偏向技术的岗位，那么技术本身就一定要搞起来，这样才能使得这类职业能够在工作框架体系里处于不屈之地。

但即便如此，测试本身也有很多技术/管理方法论的积淀，有很多old school的东西是值得尊重的。不论技术做成什么样，从测试工作的最终目标而言，都需要贴合传统测试遗留下来的的概念。《测试架构师修炼之道》一书，对传统测试，尤其质量管理方向相关的知识点、工作目标、工作方法都概括的非常明确，是测试行业不可多得的智慧积淀（嗯，测试行业确实缺乏沉淀！）。

技术方向的测试同学阅读这本书，能够更好地把握技术研发的方向；业务方向的测试同学阅读这本书，能够更全面地规划自己的发展。

在阅读的过程中，笔者也做了相关的读书笔记，提炼了其中的精要。本文也将把笔者的读书笔记全部分享出来：

第一章：软件测试工程师的“三年之痒”

第三年的瓶颈：基本的技术与业务都已掌握，但不知道该如何深入，工作缺乏挑战性与成就感

软件测试的能力：

对整个系统有整体把握
站在用户（玩家）角度理解需求
技术+产品技能

第二章：软件测试工程师的职业规划

职业规划路线

测试工程师的两条路：

管理（测试主管、PM）
技术（工具、平台、专项）

管理

初级（组长）：负责产品一个/多个特性（P6、P7）
中级（主管）：管理10~20人团队，制定、评估测试计划，评估产品质量（P7、P8）
高级（总监）：理解产品商业目标，团队人才管理，财务资源规划，改进产品测试效率与质量（P9+）

技术

产品测试专家
- 业务需求向测试转换过程的桥梁，负责测试架构设计
- 对测试重点与难点进行攻关，提供最优方法
- 协助测试经理指定测试计划与进度
- 战略规划、业务建模、数据分析、产品生命周期质量保证
- 测试技术的涉猎（为产品服务）
专项
- 性能、可靠性、安全测试
- 技术共性的研究：测试设计、缺陷分析、探索性&自动化（测试执行）、测试流程、安全性&兼容性（功能性）、性能、可靠性、可移植性（可安装性）、易用性、可维护性（稳定&可测试）

九段秘书&六段测试

四段——深入理解产品质量，了解产品性能、可靠性、易用性等非功能属性测试，能够运用测试缺陷分析技术评估产品质量。
五段——推动测试技术进步，不断追求最适合产品的技术。
六段——缺陷预防，测试方法标准化，固化为测试工具和流程。

质量与测试

质量关注大的产品流程
测试关注产品的小质量，除此之外，还有交付质量、经营质量等环节
软件测试在质量领域的发展
- 产品流程设计
- 质量管理者（策划、控制与改进）
- 客户满意度管理

第三章：软件测试架构师应该做和不该做的事情

产品测试是端到端的

需求分析

理解需求
- 理解商业目标
  - 客户/细分客户
  - 市场趋势
  - 竞争对手
  - 产品是否体现市场价值
  - 测试策略是否和营销目标一致
- 梳理用户使用场景
  - 产品有什么类型的用户
  - 用户的业务是什么
  - 竞争对手的解决方案/差异
  - 产品的规范要求、行业背景、用户习惯
  - 场景的输入与输出
测试策略
- 测试范围
- 测试重点：产品价值、质量目标、代码实现、历史测试情况
- 测试目标
- 测试深度：测试方法多样性（边界值、异常值等）
- 测试广度：业务覆盖度

测试分析和设计

阶段测试策略
- V模型（需求分析->编码，单元/集成/系统/验收测试）
- 出入口准则
- 分解总体测试策略
按照设计方案落实

测试执行

版本测试策略
- 测试范围与计划的偏差
- 测试目标、用例
- 测试重点关注内容与执行顺序
- 回归&自动化等测试方法
跟踪测试执行
- 跟踪用例执行情况
- 缺陷跟踪
- 调整测试策略
- 不仅仅是发现bug，而是记录与跟进
建立版本质量档案
- 质量目标：商用、demo等
- 目标分解：覆盖度/测试过程/缺陷情况
- 分类：老特性变化/新特性研发
- 优先级

质量评估

能否进入下一阶段测试？
- 质量目标是否达到
- 未达到的一般性质量目标如何应对
- 遗留缺陷分析

测试经理、测试架构师与系统架构师

测试经理
- 制定测试计划（PM）
- 通过协调调度保证测试顺利进行
测试架构师
- 制定测试策略
- 验证产品是否展现应有的价值，满足用户需求
- 理解框架，使得测试设计与执行更加有效
系统架构师
- 如何创造产品，实现产品价值
- 如何实现以满足用户需求
- 需要与测试架构师一起整理user story

第四章：软件测试架构师的知识能力模型

软件产品质量模型

验证是否符合需求->非功能/隐性需求？

质量六属性：

功能性
可靠性
易用性
效率
可维护性
可移植性

功能性

指定条件下使用时，满足显性/隐性功能的能力

适合性：满足用户基本需求
准确性：结果与精度正确，表达内容无误
互操作性：多特性能够相互配合
安全性
功能顺从性：符合功能相关标准规范

可靠性

成熟性：避免因故障而失效
容错性：发生故障/违反接口约定（异常值）情况下，维持规定的性能级别的能力
可恢复性：软件失效情况下，重建规定性能级别并恢复受直接数据影响的能力
可靠性顺从性：符合可靠性规范

易用性

从用户习惯的角度

易理解性
易学性
易操作性
吸引性
易用性的依从性：遵循易用性相关标准与风格的程度

效率

产品性能

时间特性：提供适当响应和处理时间以及流量/吞吐量的能力
资源利用率：执行功能时，使用合适数量/类别的资源的能力
效率依从性：遵循相关性能指标的程度

可维护性

可被修改的能力

可分析性：诊断软件缺陷/失效原因/修改部分识别的能力
可修改性：软件产品能够被修改的能力
稳定性：软件产品不会因为修改而造成意外结果的能力（体现可修改的容易程度）
可测试性：软件产品已修改的部分能够被确认修复的能力
可维护性依从性：遵循相关标准/约定的能力

可移植性

从一种环境迁移到另外一种环境的能力

适应性：无需采用额外手段便可适应不同环境的能力（多OS兼容）
可安装性：在指定环境中被安装的能力（是否易安装？）
共存性：和环境中其它软件共存的能力（与效率/性能相关）
易替换性：在同样环境下替代另一个相同用途产品的能力
可移植性的依从性：遵循可移植的标准/约定的能力

测试类型

功能测试：产品能否满足用户特定功能要求并做出正确响应
安全性测试：产品是否有保护数据的能力，能在合适范围承受恶意攻击
兼容性测试：能够和其他相关产品/平台顺利对接（操作系统）
配置测试：是否能在推荐配置上流畅运行，是否会出现输入故障
可靠性测试：在长时间运行能否保证系统的性能水平，存在异常情况下系统是否依然可靠
易用性测试：产品是否易于理解、学习与操作
性能测试：时间/资源的使用
安装测试：产品是否能被安装与正确运行

测试方法

车轮图——围绕产品质量模型的相应测试方法

功能测试方法

单运行正常值输入法
- 测试用户发送email，收件人地址、发件人地址、邮件内容、标题、优先级等，都是输入。测试这些的正确性，即为单运行正常值输入。
- 输入有限（邮件优先级）：遍历
- 输入无限（邮件内容）：等价类
单运行边界值输入法
- 输入边界值、超越边界的值、不合法的值与输入正常值进行对比
多运行顺序执行法
- 考虑用户习惯性的操作
- 比如用户“收到一封邮件”与“发送一封邮件”两个事件组合中，只有“用户收到一封邮件，又发送该封邮件”才是测试点，具有顺序性。而“用户收到一封邮件后发送任意一封邮件”与“用户发送一封邮件后再收到一个邮件”并非测试点，可以分开来测。
多运行相互作用法
- 考虑两种运行有业务上或者内在资源上的关联
- “用户发邮件时，又收到一封邮件”就是相互作用的例子

单/多运行：测试人员的一次/多次操作或行为
从设计的角度划分功能，比如“用户和服务器建立了连接”这种叙述，并不算是运行
而“用户通过点击xxx” -> 输出结果为和服务器建立了连接，前者算是“运行”
针对一个用户执行操作（多个用户，考虑可靠性测试法）

可靠性测试方法

异常值输入法：采用系统不允许的输入值进行输入
- 故障植入法：把系统放在有问题的环境中进行测试，输入仍然为正常值
- 弱网/断线重连
- CPU、内存不足
- 软件冲突、驱动不正确
- 硬件问题
稳定性测试法：在一段时间里，长时间大容量运行某种业务的一套方法
- 低于性能测试的基准，考虑实际情况
- 增加操作数量
- 多个用户同时操作某功能
- 用户反复进行某操作
- 用户反复进行异常操作
压力测试法：在一段时间里，持续使用超过系统规格的负载进行测试的方法
- 在每个周期的某个小时段内，增大访问/操作量，持续一段时间
- 不允许业务失败
恢复测试法：在持续超过负载进行一长段时间的测试后，再恢复原先的负载规格执行测试的方法
- 持续进行超过规格的负载时，规格内的业务不是100%正确，可容忍宕机（考虑产品可靠性的要求）
- 当负载降到规格值之内后，业务必须100%正确

性能测试方法

系统能够正确处理新业务的最大能力
- 从分配资源到完成处理流程的速度
- 例子：每秒允许登录用户（开服PCU）、每秒能够主动发起多少次连接
- 考虑新业务的拆除（比如用户下线）
并发：系统能够同时正确处理的最大业务的能力
- 别的指标不能对并发指标造成影响

分析性能测试的影响因素：考虑用户发邮件，因变量为邮件大小（1bit～10MB）与邮件过滤策略（1～1000条），通过拟合曲线观察趋势。或者采用混合因变量的方法，模拟真实业务情况。

易用性测试法

一致性：风格布局统一，操作提示是否符合设计规范等。最好有个checklist。
可用性：用户视角——功能是否易用？最好需要熟悉用户又熟悉测试的人（提测）
- 完成某个业务场景配置需要的时间？
- 完成某个业务场景配置了多少步骤？
- 完成某个业务场景跳转了多少配置页面？
- 完成某个业务场景求助了几次？产品资料是否容易解决问题？

测试设计技术

测试点与测试用例

测试用例是测试点的加工，需要对测试点进行去重、合并、细化
需要保证用例的可执行性，是一份真正能够直到测试的说明书

四步测试设计法

建模
- 流程（流程图）
- 参数（输入输出表）
- 数据（等价类分析表）
- 组合（因子表）
设计基础测试用例：覆盖测试模型，确定测试条件
补充测试数据
扩展：针对容易发生缺陷的地方进一步增加用例

测试点的分类

流程类测试点：通过组合，形成一个完整的流程
参数类测试点：参数个数有限，可以遍历覆盖，系统会对不同参数有不同响应
数据类测试点：是一个范围，范围内的响应基本上是一样的
组合类测试点：流程、参数、数据的组合

流程类测试设计：路径分析法

绘制业务流程图进行建模
对覆盖流程的各个路径进行分析，覆盖方法有：
- 语句覆盖：所有判定和过程的最小路径集合
- 分支覆盖：覆盖系统中每个判定的所有分支所需的最小路径数
- 全覆盖：100%覆盖所有可能的路径
- 最小线性无关覆盖（常用）：每个路径片段至少被执行一次。
  - 线性无关路径（IP） = 边数 - 节点数 + 2 = 判定数 + 1 = 区域数 + 1
确定业务流程的所有子流程。对于每一个子流程，确定测试输入。

参数类测试设计：输入——输出表分析法

列出相关的参数输入与输出
正常的输入参数/异常与正常的组合
排列组合后，根据业务的约束条件与控制变量法去重，得到输入——输出表
覆盖输入输出表，完成用例

数据类测试设计：等价类和边界值分析法

等价类：输入值按照测试效果划分，相同效果为一类
边界值：参数输入边界的取值
等价类分析表：在某个条件下，有效与无效输入等价类的表
- 无效等价类一般针对单个因素
- 如果部分条件的等价类相似，可考虑合并这些条件。这样的话，某个条件下可测一部分有效/无效等价类，而另一个条件则测另一些有效/无效等价类。

组合类测试设计：正交分析法

采用因子表建模
- 有约束关系，考虑拆表
采用PICT工具生成测试用例（pairwise testing）
合并pairwise表，生成用例

控制用例粒度：测试点的组合与拆分

细粒度能够更加精确发现问题，但是用例数量会过多；粗粒度可以发现产品设计上、原型上的问题，但是可能测不到细节
不同阶段、不同业务功能，采取不同的粒度
策略覆盖：某些因子/数据类测试点在和其他测试点关系较弱的情况下，没有必要使用pairwise正交，可以考虑按比例在测试用例中进行分配
错误推断法：根据经验判断产品在哪些地方会出问题，针对这些问题设计测试用例

探索式测试

一边学习、一边设计、一边执行

CPIE

收集（Collection）：收集并理解关于测试对象的信息
划分优先级（Prioritization）：对所有需要测试的任务进行优先级划分
分析调研（Investigation)：对测试任务仔细分析，预测可能输出的结果
实验（Experimentation）：进行测试实验，确认测试结果和预期是否符合，分析是否有必要改变测试策略与方法。若有必要则重新回到收集阶段。

优点：更快测试，更快寻找到有效测试点，更高效发现缺陷
缺点：基本测试覆盖易不足，测试点不易复用

选择合适的探索式测试方法

产品特性分区。根据不同分区，选择不同的探索测试方法
- 历史区：老代码与特性
  - 恶邻测试法：缺陷多的代码段，需要多花时间
  - 博物馆测试法：老的遗留代码与很久没有执行过的用例需要和新代码有相同的重视程度
  - 上一版本测试法：检查新版本无法运行的测试用例，确保没有遗漏必须功能
- 商业区：销售特性
  - 指南针测试法：通过阅读用户手册、场景、需求以进行测试
  - 卖点测试法：对吸引用户的特性进行测试
  - 地标测试法：寻找测试点，明确测试项
  - 极限测试法：什么特性能使软件发挥极限？哪些输入会影响软件性能？
  - 快递测试法：专注于数据从输入到输出的执行流程
  - 深夜测试法：测试对象是否能自动完成任务？其中异常是否自动记录？
  - 遍历测试法：选定一个测试目标，用最短路径访问目标包含的所有对象
- 娱乐区：辅助特性
  - 配角测试法：专注于紧邻主要功能的辅助特性
  - 深巷测试法：把最流行与最不流行的模块放在一起测
  - 通宵测试法：测试软件长时间运行后，各模块是否正常
- 破旧区：问题高发的特性
  - 破坏测试法：专注缺陷较多的代码段
  - 反叛测试法：输入最不可能的数据
  - 强迫症测试法：强迫一遍又一遍接受同样的数据
- 旅馆区：平台或维护特性
  - 取消测试法：启动某些操作，然后停止，查看测试对象处理机制与反应
  - 懒汉测试法：让程序自行处理空字段/运行默认值
- 旅游区：噱头/一次性的特性——快速访问文件之类的各种功能
  - 收藏夹测试法：把软件可达的输出进行遍历与手机
  - 长路径测试法：访问离应用程序开始点尽量远的特性，在到达目的地前尽可能在应用程序内穿行
  - 超模测试法：关心表面的东西（UI显示）
  - 测一送一测试法：测试同一个程序多开的情况
- 其它区：代码变动、用户不关心但研发关心的内容
  - 内部测试法：收集这个功能哪些部分对确认测试结果、定位问题有用的测试输出，然后关心其效果
  - 变动区测试法：分析版本变化，只针对变化内容测试

开展探索式测试

确定任务——全局场景、特性漫游与局部功能点探索
根据任务设计探索地图
- 现在测试什么，接下来测试什么
- 直接使用测试点测试
- 根据测试结果调整测试点
- 设定完成时间
探索式测试总结
- 哪些方法能够有效发现产品问题
- 测试过程存在什么不足

自动化测试

自动化的不足

成本高（维护、人力与技术）
脚本不一定可靠
- 脚本难以捕获异常
- 失败的用例不一定是错误
不能单靠测试解决
- 需求、UI、命令行需要确定

评估自动化的收益

总成本 = 前期开发 + 后期维护成本

前期开发成本：人力、时间、金钱
后期维护成本：产品变更、定位/修复自动化运行环境可靠性与代码健壮性，以及其它杂项因素

自动化测试的收益 = 自动化测试的运行次数

实施成本计算方式：p = k * n / (c1 + c2)

p：成本
k：手工执行自动化用例所花费时间成本
n：自动化用例执行次数
c1：前期成本
c2：后期维护成本

第五章：软件测试架构师的软能力修炼

沟通和协商

基本沟通原则：尽早沟通，既要对事，也要对人——换位思考（了解项目各组成员的业务与立场）

写好测试用例

测试用例包含：

用例标题（完整的句子，用条件描述）
前置条件
测试数据
测试步骤
预期结果（一种步骤，对应一种结果）

第六章：如何才能制定好测试策略

测试策略

测试的对象和范围
测试的目标
测试的重点和难点
测试的深度和广度
如何安排各种测试活动
如何评价测试的效果

与其它名词的不同：

测试方针：产品测试通用要求、原则与底线
测试计划：测试策略的拆解与时间资源的分配
测试方案：解决在测试设计和执行方面的问题（上面6个）

四步测试策略制定法

明确产品质量目标
- 测试目标为满足质量目标
- 围绕目标进行刚刚好的测试
- 将目标——行为——评估形成闭环
风险分析
- 提前识别阻塞测试的风险，基于风险调整测试策略
- 基于风险加强和降低测试投入
适配产品研发流程
- 按照研发流程设计测试策略结构
  - 概念阶段（三方）制定总体测试策略
  - 计划阶段制定阶段性测试策略
- 根据研发流程安排测试活动
测试分层
- 将大的测试目标，分到不同层次中分阶段完成

产品质量评估模型

多维度：覆盖质量评估各个维度
定量+定性：指标与分析结合
过程+结果：除了结果还要评估测试过程

评估维度：

测试覆盖度
- 需求覆盖度评估
  - 已经验证测试的产品需求数：产品需求规格总数
  - 目标为100%
  - 建立需求表/用例与需求的映射关系
- 路径覆盖度分析
  - 已经测试的语句数量：程序中可执行语句的总数
  - 语句、分支、全、最小线性无关覆盖
  - 确定覆盖策略，用路径分析法设计用例并跟踪执行
测试过程
- 测试用例分析
  - 测试用例执行率
    - 已经执行的测试用例数目：测试用例总数
    - 测试阻塞/未执行的测试用例，影响执行率
  - 测试用例执行通过率
    - 测试用例通过：已经执行测试用例数目
  - 测试用例和非测试用例发现缺陷比
    - 非测试用例为发散性的测试，这个比值不能过低，否则用例设计有问题
- 测试方法分析
  - 分析测试设计和测试方法是否符合
  - 分析测试方法和测试策略是否符合
  - 通过缺陷分析，反推测试方法的可行性
- 测试投入分析
  - 测试人员安排与投入工作量
缺陷
- 缺陷密度分析
  - 每千行代码发现的bug数
  - 预测产品的缺陷数，评估当前发现的缺陷是否足够多
- 缺陷修复情况分析
  - 缺陷修复率：已经修复缺陷：已经发现缺陷
  - 在每个测试分层都要确定缺陷修复率目标
  - 在每个分层结束判断是否能够进入下一阶段测试
  - 如果最终缺陷修复率不能达到预期，理论上不能发布产品
- 缺陷趋势分析
  - 判断当前系统是否能够很容易地发布缺陷
  - 观察凹凸性和拐点，分析原因
  - 发现缺陷与解决曲线趋势收敛：当前测试方法已经无法有效发信啊问题
- 缺陷年龄分析
  - 定义：系统产生/引入缺陷的时间
    - 继承/历史遗留：属于历史版本、继承版本或移植代码出现的问题
    - 需求阶段：需求不清、需求错误、系统整体设计的问题
    - 设计阶段：功能接口/交互、边界值/流程/算法设计的问题
    - 编码阶段：流程逻辑、算法、编程规范，接口规范的问题
    - 新需求/变更：新需求或功能实现变更引发
    - 缺陷修改：修改缺陷，引入了新的问题
  - 分析方法
    - 确定缺陷年龄（bugzilla）
    - 统计各类缺陷年龄的数量，绘制缺陷年龄分析图
    - 进行分析。理想情况如下：
      - 在缺陷的引入阶段就能及时发现该类缺陷，不会逃逸到下个阶段
      - 在特定的分层发现该分层的问题
      - 没有继承/历史遗留/新需求/缺陷修改引入的缺陷
- 缺陷触发因素分析
  - 缺陷触发因素越全面，说明测试方法越多，测试也会越深入
  - 确定缺陷的确实方法和类型，统计缺陷数目，绘制缺陷触发因素柱状图分析

风险分析技术

分析对象：测试策略
分析目标：识别可能阻塞测试策略顺利进行的问题

风险识别

分析测试设计关注哪些内容，比如针对某个特性进行测试需要通过路径分析法覆盖，然后需要进行功能交互、压力测试、性能测试等测试手段
分析上述内容保证顺利进行，需要哪些条件，比如文档/沟通顺利、测试人员对场景有深厚理解、能够掌握测试方法等因素
根据缺失的因素，识别风险

风险评估

风险优先级正交表（风险影响程度 X 风险发生频率）
需求类风险
- 需求质量不高，不足以支撑后续开发测试
- 开发测试都未能理解需求
设计类风险
- 设计正确性与全面性
- 测试容易发现缺陷吗？开发修复成本大吗？测试回归成本大吗？对用户影响大吗？
风险应对
- 回避、转移、减轻、改变
老功能分析
- 差异分析
- 历史测试情况分析
  - 老功能在新版本质量要求是否提升
  - 老功能缺陷与测试方法分析

分层测试技术

V模型

单元测试：产品实现函数单元
集成测试：产品模块与功能
系统测试：从系统角度验证功能是否正确
验收测试：从用户角度确认产品是否满足业务需求

通信公司的分层：

详细设计级
- 模块级系统测试（MST）
- 联调（BBIT）
概要设计级
- 系统设计确认（SDV）
- 系统集成测试（SIT）
- 系统验证测试（SVT）

敏捷环境下的分层：

单元测试
功能测试
非功能测试
探索测试

第七章：测试策略实战攻略

开始

制定测试策略之前，需要进行信息收集，比如：

项目的范围
人力投入
历史情况

然后采用四步测试策略制定法：

明确产品质量目标
进行风险分析
适配产品开发流程
进行测试分层

产品分为4个等级：

完全商用：完全满足用户需求，少量或者没有遗留问题，用户使用无限制
受限商用：特性无法满足用户特定场景，有普通以上的遗留问题，但有规避措施
测试、演示或者小范围试用：特性只满足用户部分需求，有严重以上遗留问题，无规避措施（Beta）
不能使用：特性无法满足用户需求，存在严重以上的遗留问题

对产品每个特性，也根据四个质量等级来划分。将特性的质量目标确定后，就可以进行风险分析
风险分析后就能够确定测试策略的结构，可以采用总分式

总体测试策略（概念与计划阶段）
阶段测试策略（计划与开发阶段）
测试执行（开发、验证、发布）

总体测试策略

对质量目标进行分解，比如：

测试覆盖度
- 需求覆盖度
- 路径覆盖度
测试过程
- 用例执行率
- 测试用例与非测试用例发现缺陷比
缺陷
- 密度
- 修复率

并为每一个测试分层确定目标，采用老功能分析法对特性进行分类。

哪些特性是新开发的
哪些是从老版本继承的
哪些特性的改动比较大
从老版本继承特性的历史情况

新特性进行全面测试，老特性对变化的部分进行全面测试，没有变化的可以适量回归+探索

测试深度和广度

测试深度：测试过程中需要使用的测试方法
测试广度：测试的范围

通过产品质量评估模型与老功能分析，可以初步确定测试深度：

功能测试（demo只用功能测试即可）
性能测试
可靠性、易用性测试

老功能分析可以用来确认测试广度：

测试覆盖度、测试过程、缺陷，是否全面测试

之后根据质量目标与分类，确定测试优先级与总体框架：

策略层：总体、阶段、测试执行策略
活动层：测试分析、设计，单元、集成、系统、验收测试
保证层：需求、开发设计、测试设计review

阶段测试策略

采用测试分析设计表保证测试设计符合策略

测试分析准备表
- 被测对象配置在测试设计中需要考虑哪些测试方法以及功能交互
- 测试点的考虑：功能、安全、一致性、性能、易用性等
- 功能交互：安全特性、VLAN
测试类型分析表
- 对待分析的每一条需求，逐一分析各测试类型下是否有测试点
功能交互分析表
- 需要进行交互分析的功能与对应测试点的关系

之后可以对测试用例进行分级

集成测试

集成测试位于开发阶段，相当于联调。集成测试是黑盒性质的测试，包括以下几项：

新合入功能是否正确
验证功能集成后系统功能的正确性
确认原来的系统功能没有被新合入的功能破坏

集成测试的条件（入口准则）：

计划的功能开发完成，完成了单元测试
功能集成完成，可测，提供用户的输入输出接口
测试团队做好准备
- 测试用例已经输出，并通过评审
- 测试资源已经到位
- 测试环境已经准备好

集成测试结束条件（出口准则）：

系统需要继承的功能已经全部开放，集成完成
计划执行的测试用例已经完成
缺陷分析的结果符合预期
达到了集成测试阶段的产品质量目标

系统测试

系统测试主要是针对全局，而非像集成测试一样针对单个功能

从系统角度验证测试功能的正确性
从系统角度来验证各种非功能的质量的正确性

入口准则：

集成测试的出口准则
测试团队已经做好准备

系统测试会对功能、可靠性、性能、易用性等各方面进行测试，不考虑测试执行顺序容易阻塞，需要考虑以下情况：

先进行稳定测试，再进行压力测试，最后进行恢复测试
先进行复杂的、难的测试用例，再进行简单的
将功能测试的测试用例和满规格的测试用例放在一起进行

出口准则：

计划执行的测试用例都已经完成
缺陷分析的结果符合预期
达到了系统测试阶段产品质量目标

验收测试

产品发布前的测试，是对用户需求的确认

Alpha测试
- 由测试人员模拟用户进行的测试，应该是不太了解产品细节，但对用户非常了解的人。Alpha测试需要关注以下的内容：
  - 用户会如何学习产品？产品提供的帮助是否切实？
  - 用户将产品安装在怎样的环境中？升级对用户的影响是否在容忍范围内？
  - 用户环境中哪些业务时需要关注的？不需要关注的业务怎么处理？
  - etc
Beta测试
- 由用户参加的测试，常见有如下两种：
  - 产品正式发布前将产品提前发给用户，收集反馈
  - 产品开发完成后，交由用户对产品进行验收

验收测试的入口准则：

系统测试的出口准则
Alpha测试人员、方案已经选好
Beta测试的用户已经确定

出口准则：

达到产品质量目标

第八章：版本测试策略和产品质量评估

版本测试时，应当有一份版本计划与一份测试计划，分别由开发人员和测试人员输出

版本计划
- 几个build，每个build合成什么功能
测试计划
- 集成测试、系统测试与验收测试需要测试多少个版本
- 每个版本的主要测试目标

版本测试主要工作是指定版本测试策略，然后跟进测试执行并进行评估。

第一个版本测试策略

第一个版本策略的制定方式，也可以按照目标——风险——流程——顺序的思路来制定
当某一个build的提交并不完整的时候，可以根据对测试人员是否可测为基准，进行测试
对于测试目标，比较好的描述方式是：对某个功能（测试对象），进行哪些测试（测试方法），发现产品哪些方面的缺陷（测试结果）

每个版本测试策略中，需要注明哪些是重点关注的内容。首先要对提交功能进行分析，提出测试团队重点关注内容，其次要确定版本测试功能优先级表。实际开发过程中，不同功能可能分为不同的提交，因此测试功能的优先级需要实时定制更新，而后在版本策略中向测试团队说明。同时可以对测试用例进行分级，从而更加容易选择测试用例。

在测试执行顺序方面，可以遵循如下的原则：

质量情况越好，就可以考虑将更多的测试方法组合起来执行
对刚提交的功能，在质量情况不明的情况下，不建议用组合测试法进行测试
先执行高优先级特性的测试用例，先进性复杂的、难的测试用例

测试的时候会遇到一些全局因素，比如浏览器、测试工具、操作系统等运行环境，需要策略性地进行试探测试。也可在不同配置下，对相同功能进行测试。
“接收测试”指开发人员将版本转移给测试人员是，测试人员对这个版本进行一次测试，确认没有阻塞问题能够按照测试策略完成测试。有两种结果——通过和不通过，判断标准是是否有阻塞问题。如果不通过，但有规避阻塞地方法，可以继续进行测试。接收测试适合level1的测试用例。

跟踪测试执行

跟踪测试执行的目的有3个：

确保测试团队按照测试策略来进行测试
实时关注缺陷，通过缺陷分析来确认测试策略是否合适，是否需要调整
关注项目中的实时风险，基于风险调整测试策略

要保证测试团队按照测试策略来执行测试，需要保证以下三点：

测试内容和测试策略中确定的范围、深度和广度一致
- 测试用例和测试策略一致
测试执行的顺序和测试策略一致
- 测试团队是否按照特性优先级顺序执行测试用例
- 测试团队是否按照测试策略中的测试方法、测试顺序来执行测试用例
计划测试的内容能够顺利执行
- 原因：人力不足，时间不够，测试环境不具备，具有其它缺陷
- 缺陷跟踪
  - 缺陷趋势是否正常
    - 拐点预测：测试方法不同或测试方法不变测试对象不同，不应该出现拐点
    - 判断拐点出现是否过早或者过晚
  - 是否存在因修改引入的缺陷
  - 本版本中必须解决哪一些缺陷：会不会对后续测试造成阻塞，需要保证测试完整性
  - 本版本中需要解决哪一些缺陷：阻塞的、改动大的、涉及需求方案设计的、致命和严重的
- 调整测试策略
  - 被阻塞的功能较多的话，需要考虑是否提前结束测试
  - 存在阻塞的功能，原计划不在本版本的用例，考虑是否可以调整到本版本中测试
  - 没有阻塞的功能，原计划不在本版本的用例，考虑是否调整到本版本测试
  - 拐点出现太早，说明当前测试方法不能有效发现缺陷，分析是否因测试阻塞造成
  - 一直未出现拐点，说明当前测试方法能够有效发现缺陷，可以在下一阶段开始的1~2个版本中，增加一些和上一阶段测试相关的探索性测试

版本质量评估

在进行下个版本测试之前，需要进行版本质量评估
质量评估的方法：

记录需求和实现的偏差
- 需求理解方的错误导致实现上的错误（开发与产品理解分歧）
- 需求没有提交完
- 记录相关的bug列表，三方讨论
进行测试过程评估
- 测试方法：总结哪些测试方法比较有效
- 测试投入
- 测试用例：是否执行完，通过率是多少（先评估质量指标是否有效），多个版本中执行结果情况如何
  - 某功能通过率不高，说明该功能质量可能不高，需要调整测试策略
  - 项目初期关注首次通过率，其后关注累计通过率
  - 测试用例在多版本执行结果出现反复，有可能因为新功能合入对旧功能造成影响，或者因为缺陷修改引入了新的结果
缺陷分析
- 功能特性的缺陷密度是否正常
- 缺陷年龄分析是否正常
  - 缺陷引入阶段实时发现，不能遗留到下个阶段
  - 在特定测试分层发现该层问题
  - 没有继承/历史遗留/新需求变更/缺陷修改引入的缺陷
- 缺陷触发因素分析是否正常
调整测试策略：如果产生影响最终发布质量的问题，就需要采取措施
建立特性版本质量档案
- 对当前测试覆盖度方面的记录，包括需求与实现的偏差
- 测试过程分析记录
- 缺陷分析

后面版本测试策略

回归测试
- 缺陷回归：验证缺陷是否被开发人员修复
  - 功能性缺陷：对缺陷本身与该功能相关交互验证
  - 非功能性缺陷：对缺陷验证，分析缺陷修改是否对功能有影响
  - 底层/中间层缺陷：控制这类缺陷在设计修改和编码上的质量
- 功能回归：确认老功能不会因新合入功能而失效
  - 新开发功能合入版本后的回归
  - 老功能回归：自动化测试
- 阶段回归：确认产品当前质量达到该阶段的质量目标
  - 集成测试阶段：验证功能集成后正确性，满足出口条件（level 1级测试用例）
  - 系统测试阶段：对重点功能进行测试
  - 验收测试：对典型场景进行测试
探索式测试
- 集成阶段中后期逐渐进行探索式测试，对新合入功能进行探索
- 系统测试阶段，对整个系统重点特性与辅助特性进行深入测试
自动化测试
- 先对需要多次执行的测试用例进行自动化，优先自动化简单的、可靠的功能

阶段质量评估

在每个阶段完成时对整体质量进行评估，判断是否能够达到出口标准，进入下一阶段评估
质量评估可以按照质量评估模型进行评估，需要持续跟踪测试执行、评估版本与阶段质量。具体工作如下：

确认总体策略中的质量目标是否完成
- 对总体质量目标进行分解，为每个测试分层确定质量目标
- 如果质量红线（重要目标）没有达成，就不能进入下一阶段测试或发布
- 如果一般性目标没有达成，且没有应对措施，也不能进入下一阶段测试或发布
重要的质量目标（质量红线）
- 需求覆盖度、测试用例执行率、测试用例累计执行通过率、缺陷修复率
对未达到的一般性质量目标制定应对措施
- 非测试用例发现缺陷：寻找测试设计中的问题，改进设计，进行探索式测试
  - 产品实现/功能交互/边界值异常分支未考虑/测试场景未考虑
- 组合缺陷分析：将缺陷分析方法进行组合
  - 缺陷密度过高，可以分析缺陷触发因素。是否采用了更多的测试方法？是否有遗留较多的缺陷？如果缺陷趋势收敛，修复率达标，可以进入下一阶段的测试。
- 遗留缺陷：制定规避措施
  - 在版本计划发布前几个版本就开始进行，需要评估缺陷对用户影响程度、发生概率
  - 致命缺陷/没有规避措施严重缺陷，不应该遗留
  - 非必然重现bug，需要提单做问题记录，跟踪周期可以延长，可以适当降低问题优先级。