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

《测试架构师修炼之道》读书笔记

文章目录

1、在不同阶段的职责

1、需求解读阶段

理解价值；理解所测产品的商业目标、核心价值和用户的使用场景，也就是站在开发者的角度，需求能带来哪些价值，站在用户的角度，用户能获得哪些价值，来判断功能的实际效果是否满足预期效果
用户场景；产品对应的用户有哪几种，这些用户对应的业务流程是什么，用户的习惯是什么
需求的特性，明确需求是后台型需求还是用户型需求，是继承型需求还是全新开发的需求，是短期快速型需求还是长期战略型需求。我们需要根据产品的特点，去选择最合适的测试方式，以"刚刚好"满足发布的要求。
分析测试重点（产品的核心价值）与测试难点（测试验证难易程度），分析测试深度（测试方法）与广度（测试类型）

2、测试执行阶段

具备基本的版本迭代管理知识，能够识别那些变形的迭代研发模式，能和团队管理者一起逐步改善研发模式，使研发更加高效，在各种变化的情况下，依然能够保持良好的版本节奏

识别变形迭代研发模式的关键特征

需求与交付偏差

表现：需求文档与实际开发内容不一致，或交付成果未覆盖核心功能。
根源：需求分析阶段未明确测试目标与质量模型（如功能性、兼容性优先级）。

测试与研发脱节

表现：测试用例滞后于开发进度，或自动化测试覆盖率不足。
根源：缺乏持续测试机制（如流水线集成、自动化回归测试）。

低效的迭代节奏

表现：频繁返工、版本稳定性差，或发布时间频繁波动。
根源：未基于质量模型（如可靠性、性能）制定迭代计划。
选择合适的测试用例，考虑测试用例的最佳执行方式，如是自动化测试还是手工测试、是否需要增加探索式测试等
考虑测试执行的顺序，实时关注产品缺陷趋势，确定缺陷修复的优先级，对于非必现（非必然重现）的缺陷的管理规则
- 对于非必现缺陷，测试架构师要制定有效的处理机制
- 确定哪些缺陷是当前要解决的，优先保证测试执行不受阻塞
- 分析实际的缺陷趋势和预判的缺陷趋势的差异，以此来调整测试策略，使产品如期发布

3、测试质量评估阶段

使用产品质量评估模型来确认质量目标的达成情况，判断产品是否达到交付标准。

1、分析测试过程

我们在做质量评估的时候，要关注测试过程------尽管规范有序的测试过程并不代表最终会收获高质量的产品，但混乱的测试过程一定会给后端遗留更多的问题，以致影响最终的产品质量。

首次测试用例执行通过率：可以帮助我们评估新开发的产品功能的质量，如果有的模块首次执行通过率较低，根据"缺陷聚集性原理"可知，系统可能还隐藏着缺陷。
累积测试用例执行通过率：可以帮助我们评估当前产品整体的质量。测试执行通过率足够高也是版本发布的前提，即只有达到公司要求的测试执行通过率，才可以考虑发布。
非测试用例发现缺陷比：我们鼓励测试者在测试中可以基于测试用例做一些探索，所以我们希望"非测试用例发现缺陷比"可以在一个合理的范围内，如果非测试用例发现缺陷比过高，那么说明先前的测试设计可能存在问题，如测试设计投入不足、不够深入等；如果非测试用例缺陷发现比过低，那么说明测试团队可能比较沉闷且缺乏探索性精神，或者测试思路还不够开阔等。无论出现哪种情况，都需要测试架构师及时分析、总结、改进。

2、缺陷分析

（1）缺陷趋势分析：

定义：缺陷趋势是指随着测试时间的推进，测试人员发现缺陷的趋势和开发人员解决缺陷的趋势
目的：能够帮助我们判断：是否还能继续发现系统中的缺陷，当前测试过程是否存在问题以及是否可以发布产品
分析缺陷趋势图

理想的缺陷数量曲线如下图所示，测试刚开始的时候，团队需要快速且高效地发现当前的缺陷，因此曲线呈现上升的趋势（凹函数），测试接近尾声的时候，正常情况下测试团队继续按照当前的方式进行测试，不会那么容易发现新缺陷了，拐点随之出现，曲线开始呈现下降趋势（凸函数）

分析拐点出现的时机
- 当拐点出现得比预期早，如下图这样，早出现拐点，说明如果继续按照当前计划进行下去，测试团队无法有效发现产品的缺陷了

可能的原因有：测试执行受阻，无法有效开展测试活动，或者测试投入变少，此时需要调整测试策略，提高团队测试产出

当拐点如下图那样一直未出现时，说明目前测试团队依然可以大量发现产品的问题

可能的原因有：产品质量太差，缺陷数量高于预期，团队中有经验的同事加入测试，或者团队可能使用了更多、更复杂的方法来发现产品缺陷。如果是最后一种的话，测试架构师做好分析和引导，保证测试者围绕产品质量目标和核心价值特性进行测试，不要为了发现缺陷而测试。

如何根据缺陷趋势图，判断产品可以上线

我们在判断缺陷数量是否收敛时，需要考虑如下两个条件。

1、累积发现缺陷的曲线呈现凸函数特性。

缺陷数量收敛是判断是否结束测试的必要条件------如果缺陷数量一直不收敛，那么即便计划的测试结束时间已经到了，也不应该结束测试，更不能发布产品。

2、累积发现缺陷的曲线和累积解决缺陷的曲线逐渐靠近，逐渐趋于一点。

临近发布时，要控制代码的改动，理想的整个测试过程对代码变动量的控制要像漏斗一样。

临近发布必须对代码进行改动时，应注意如下3点。

1、严格控制代码改动量，非必要不改动。

2、做好代码的静态检查。

3、做好和修改相关的回归，避免因为缺陷修改而引入新的问题。

（2）缺陷修复率分析

定义：缺陷修复率是指已经修复的缺陷总数和已经发现的缺陷总数的比值
用处：缺陷修复率能够帮助我们确定当前发现的产品缺陷是否被有效修复，如果最终的缺陷修复率不能达到预期，原则上不应该结束测试。
分析：

从缺陷对用户的影响角度，对缺陷严重程度进行划分

- 致命： 系统崩溃：应用或系统完全无法运行，例如启动失败、频繁崩溃。

数据丢失：用户数据无法保存、恢复或被错误删除。

安全漏洞：存在安全风险，可能导致用户数据泄露或被恶意利用。

核心功能失效：关键功能无法使用。

- 严重： 主要功能受限：主要功能无法按预期工作，但系统仍可运行。

性能问题：系统性能极差，例如加载时间过长、频繁卡顿。

数据错误：数据处理或显示不正确，但不会导致数据丢失。

- 一般： 功能异常：次要功能无法正常工作，但不影响主要功能。

界面问题：界面显示不正确，例如布局错乱、文字显示不全。

交互问题：用户交互体验不佳，例如按钮响应不灵敏。

- 较轻： 界面细节：轻微的界面问题，例如图标显示不正确、文字排版问题。

拼写错误：文本内容中的拼写或语法错误。

提示信息：提示信息不准确或不友好。

根据缺陷修复率确定产品是否达到上线标准

（3）缺陷年龄分析：缺陷存在的时间，通过缺陷年龄分析，可以识别出长期未解决的缺陷，及时跟进和解决。

（4）缺陷触发因素分析：测试者发现缺陷的方法，通过分析缺陷触发因素，可以了解哪些测试方法更有效，优化测试策略。

2、测试能力标准

1、概况-测试九段

测试一段：能执行。能按照测试用例执行测试，会使用基本的测试工具，能发现产品的缺陷，能清晰、准确地记录缺陷，并能和开发者进行有效沟通。也就是按照测试用例完成测试任务

测试二段：能设计。理解用户需求和产品实现，能够分析、设计测试用例，发现bug后能够有效定位，有自动化测试的能力。具备设计测试用例，缺陷定位，自动化测试的能力

测试三段：能深入。深入理解用户需求和产品实现，注重测试设计、执行的有效性，掌握各种专项测试技能，能对自动化架构进行优化。有意识不断优化自己的用例，以及注重测试效率，学习其他专项测试技能，有自动化架构优化的能力

测试四段：能带队。能带领一个小团队完成测试任务，能有效评估产品质量，给出建议。

测试五段：能固化。能将测试方法标准化，并固化为测试工具和流程，关注测试过程改进，有能力管理中/大型团队。能关注团队的流程问题，并提出改进建议，有管理中/大型团队的能力

测试六段：能引领。有眼界和影响力，在某些领域是行业的标杆。

2、测试架构师必备的6个关键能力

（1）明确测试目标、测试重点的能力。不仅从测试或者开发设计实现本身来明确测试目标，还要能够从产品价值、质量目标的角度来明确测试目标，圈定测试重点，保证通过有限的资源可以完成"刚刚好"的测试。

（2）敏锐的风险识别和有效的风险应对能力。能够对产品当前的风险进行多维度的分析，找到有效应对风险的方法，实现基于风险的测试。

（3）测试分析、设计和执行能力（包括工具和自动化）。知道好的测试是怎样的，能够对被测对象系统、深入地进行分析，精于测试用例设计，能用简洁无歧义的语言描述测试用例、缺陷，能不断总结优化测试方法，能把烦琐的工作用自动化的方式完成，能使用、开发测试工具来提高测试效率。

（4）质量分析和评估能力。能够通过过程分析、缺陷分析来评估当前产品/特性的质量，对下一步计划进行调整。**过程分析：**实时跟踪测试进度，对比实际执行与计划的差异；若某模块缺陷率显著高于预期，需增加测试深度或扩大覆盖范围，调整测试范围和优先级。

（5）有效沟通的能力。能够通过沟通获取和交换有用信息，并在不同角色之间达成一致。

（6）持续学习和探索的能力。包括总结、持续探索、持续改进、引入新技术或新方法以不断提升测试效能的能力

3、测试能力之测试分析、设计和执行能力

1、如何评估产品质量

产品质量是指"在特定的使用条件下，产品满足明示的和隐含的需求的固有特性"，简言之，质量就是满足需求。

下图是软件产品质量模型，包含8个属性

2、测试类型和质量属性的对应关系

3、确定测试深度和测试广度

测试类型代表的是测试的广度，测试者对测试类型掌握得越多，测试就越全面；而测试方法代表的是测试的深度，即测试者能够对系统进行测试验证，包括去除缺陷的手段的丰富程度。

产品测试车轮图

下面的图，车轮由测试类型组成，展示了测试的广度，每个车轮由测试方法组成，展示了测试的深度

4、如何编写出优美的测试用例

（1）测试用例的编写要求

1、测试用例描述精准，让人一看就明白测试的目标、输入和预期

2、被良好地组织、维护和传承

3、使用恰到好处的测试设计方法，使得测试用例拥有良好的覆盖度且规模适中

（2）三步测试设计法

1、对测试点进行分类

流程类测试点

流程类测试点要关注两个点，顺序性 ：关注操作步骤的顺序和逻辑，每一步都能得到正确的响应。完整性：确保整个流程从开始到结束都能正常完成，关注流程的完整性。

参数类测试点

参数类测试点偏向于性能方面，关注确保系统在不同配置和运行条件下正常工作

数据类测试点（要测完整的增删改查）

数据类测试点关注的是数据，包含输入数据，也就是用户提供给系统的数据；处理数据，也就是系统对用户的输入数据进行的各种操作，确保处理后的结果的正确性；输出数据，也就是系统向用户提供的数据，确保结果的正确性与完整性；存储数据，也就是数据库中的用户数据，这些数据需要确保其完整性和一致性。

组合类测试点

组合类测试点结合了流程类、参数类和数据类的特点。它们通常涉及多个输入的组合，用于测试系统在复杂条件下的表现。组合类测试点需要考虑多个因素的交互作用，以确保系统在各种情况下的稳定性和可靠性。

2、确定测试条件和测试数据

测试条件：测试条件是指在测试过程中需要满足的具体场景或情况，这些条件帮助我们确定在什么情况下进行测试。

测试数据：测试时能够覆盖测试模型（或部分）的输入数据，如某个输入参数的取值。

提前确定好测试数据，在测试时就能直接使用，提高测试效率

3、根据经验扩展、补充测试用例

（3）统一测试用例编写风格

实际测试项目中，测试用例最常见的问题是：

- 测试用例只有作者才能看懂，其他人会恨不得把测试用例拿来自己重写一遍。
- 测试用例由不同的人来执行，结果差别很大。
- 有的测试用例读起来很笼统，有的测试用例又写得特别细。

只有团队统一测试用例的编写风格，整个团队的测试用例库中所有测试用例都具有一致的样式时，测试用例才更容易被理解和使用，才有可能被组织和传承，才能不断提升和改进

（4）测试用例编写风格指导

- 测试用例标题：测试用例标题应为一个完整的句子，并能完整表达测试用例的意图，常用格式是：谁在怎样的条件下，做了什么事，得到了怎样的结果
- 测试步骤：要做到，一条测试用例只包含一个预期结果，不能一条用例中包含多个测试组合，防止执行时遗漏某个条件，也不利于测试计划的安排，还会为后期测试用例的修改、维护和移植带来麻烦。
- 测试数据：测试数据可以和测试步骤分开描述，以避免在测试步骤中包含很多测试数据，如果一个测试用例中包含有多个参数，测试数据应是每个参数取值的组合，每个组合对应一种预期结果

（5）测试用例维护

- 缺陷分析：有一些缺陷可能是一时灵感突发发现的，或是运气好碰到的，并不是通过测试设计发现的。这些被称为测试设计遗漏。我们可以将这部分内容更新到测试用例中。
- 用户反馈：我们也需要对用户反馈的缺陷进行根本原因分析，将测试设计遗漏部分更新到测试用例基线库中。

4、如何制定测试策略

1、什么是测试策略

测试策略就是对以下6个问题的系统思考，最后决定测试团队该如何开展测试活动。

测试的目标是什么？
被测对象和范围是什么？
测试的重点和难点是什么？
测试的深度和广度如何确定？
如何安排各种测试活动（先测试什么，再测试什么）？
如何评价产品的质量？

测试策略是一种"选择"，是一种在复杂情况下该如何进行测试的选择，是测试价值观的体现。我们希望的是，测试架构师能够对不同的组织、产品、研发模式做出最适合当前状况的选择，进行刚刚好的测试。

2、相关名词介绍

1、测试方针：测试方针可以是公司层面制定的针对测试的统一要求，可通用于公司的所有产品，并且在较长的一段时间内都是适用的，可以理解为"公司目前的测试真理"。

2、测试计划：测试计划主要安排的是测试人员在什么时候做什么，执行主体是人

3、测试方案：测试策略是高层次的指导文件，它定义了整个测试活动的目标、范围、方法和资源分配，为整个测试活动提供了方向和框架。测试方案是具体的测试分析和设计活动的记录，它详细描述了如何实现测试策略中定义的目标，测试策略的层级比测试方案高，测试分析和测试设计活动需要接受测试策略的指导。

3、基于产品特性价值的测试策略

产品特性价值高的是测试重点，测试投入大，相关需求测得深，基于产品特性价值的测试策略就是从产品价值入手，把测试视野扩展到商业和产品，提供和商业目标更加吻合的测试策略。

4、基于产品质量的测试策略

产品质量要求高的是测试重点，测试投入大，测得深，反之浅。基于产品质量目标，使产品在发布的时候能够达到事先约定的质量目标

5、四步测试策略制定法

第一步：理解测试目标和范围

明确测试目标

- 确定测试的主要目的，例如验证功能正确性、性能是否达标、安全性是否符合要求等。
- 了解项目需求，包括功能需求、非功能需求（如性能、可用性、兼容性等）。
- 与项目团队（如开发人员、产品经理、业务分析师等）沟通，确保对测试目标达成一致理解。

确定测试范围

- 明确哪些功能或模块需要测试，哪些可以暂时不测试（例如某些尚未开发完成的功能）。
- 确定测试的边界，例如是否包括第三方集成部分、是否涉及不同操作系统或浏览器的兼容性测试等。
- 根据项目的时间和资源限制，合理划分测试范围，确保测试活动的可执行性。

第二步：分析测试对象

研究被测系统

- 了解系统的架构，包括技术栈（如编程语言、数据库类型、中间件等）、系统组件之间的交互方式等。
- 分析系统的业务流程和用户场景，例如用户如何使用系统完成特定任务，系统在不同场景下的行为等。
- 查看系统的设计文档、需求文档、用户手册等资料，获取对系统全面的了解。

识别关键功能和风险点

- 确定系统的核心功能，这些功能通常是用户最关注的，也是系统正常运行的关键部分。例如，对于一个电商平台，商品搜索、下单、支付等功能就是关键功能。
- 识别可能存在的风险点，例如技术风险（如新技术的使用可能导致的兼容性问题）、业务风险（如某些业务规则的变更可能影响用户体验）等。
- 根据风险的严重性和发生概率，对风险点进行优先级排序，以便在测试策略中重点考虑高风险部分。

第三步：选择测试方法和工具

确定测试类型

- 根据测试目标和测试对象的特点，选择合适的测试类型。常见的测试类型包括：
  - 功能测试：验证系统是否实现了需求文档中描述的功能。
  - 性能测试：评估系统的响应时间、吞吐量、资源利用率等性能指标。
  - 安全测试：检查系统是否存在安全漏洞，如SQL注入、跨站脚本攻击等。
  - 兼容性测试：验证系统在不同环境（如操作系统、浏览器、设备等）下的运行情况。
  - 自动化测试：通过自动化工具执行测试脚本，提高测试效率和重复性。
  - 手工测试：由测试人员手动操作，发现自动化测试无法覆盖的问题。

选择测试工具

- 根据测试类型和测试对象的特点，选择合适的测试工具。例如：
  - 功能测试工具：Selenium（用于Web自动化测试）、Appium（用于移动应用测试）等。
  - 性能测试工具：JMeter、LoadRunner等。
  - 安全测试工具：OWASP ZAP、Burp Suite等。
- 考虑工具的易用性、功能完整性、与现有开发环境的兼容性以及成本等因素。

第四步：制定测试计划和资源分配

制定测试计划

- 确定测试活动的时间表，包括各个测试阶段（如测试准备、测试执行、缺陷修复、回归测试等）的开始和结束时间。
- 规划测试活动的具体任务，例如测试用例设计、测试环境搭建、测试执行等，并分配责任人。
- 制定测试标准和验收准则，明确何时可以认为测试通过，何时需要进行额外的测试。

分配资源

- 根据测试任务的复杂性和工作量，合理分配测试人员、测试环境、测试工具等资源。
- 考虑测试人员的技能和经验，将合适的人员分配到合适的任务上。
- 确保测试环境的可用性和稳定性，包括硬件设备、软件配置等。

5、如何提高测试效率

5.1 如何处理实际交付的内容和计划的偏差

常见的偏差是开发人员实际交付的内容和计划交付的内容存在差异，如和计划交付的内容相比，实际提交的功能缺失或不全。

处理办法：

提测标准：确保开发团队和测试团队对提测标准有清晰一致的理解，确保提测标准既合理又可达成。
问题记录：详细记录开发交付未达到提测标准的具体问题，便于后续的讨论和处理。
- 提供技术支持：协助分析日志，找出复现规律，定位问题的根源
- 讨论办法：与开发团队共同讨论问题的解决方案和改进计划，以及是否可以通过加班来补救，确认完整交付需要的时间
时间延长
- 延期提测：可否增加一个迭代，将原计划的迭代拆为两次提交，使得这个特性可以完整提交。
- 需求延后：可否调整迭代计划，把这个特性放到晚一些的迭代版本中提交。
总结教训：共同分析开发交付未达到提测标准的原因，是需求未充分理解，还是遇到技术难题，或者未充分自测

5.2 如何提高测试效率

1、调整测试执行顺序

我们要有目的的调整测试用例的执行顺序，要达到的目的是，能快速发现影响大的问题，并且能快速覆盖测试用例

方法：

优先测试影响核心功能的用例，根据测试用例对系统的影响程度，将测试用例分为高、中、低三个风险等级
优先测试那些过去频繁出现问题的区域，找出哪些测试用例在过去发现过问题，基于历史数据的测试用例优先级排序
简单测试用例优先：先执行简单的测试用例，快速覆盖基本功能，简单测试用例可以快速提供反馈，帮助快速发现问题

2、确定缺陷修复的优先级

在测试执行过程中，我们希望开发人员修复缺陷的先后顺序是：

尽早解决那些会造成阻塞的缺陷。
尽早解决那些代码改动较大的缺陷。
尽早解决那些涉及需求、方案、设计的缺陷。

操作层面上，测试架构师可以从"是否阻塞测试""缺陷修改影响"和"缺陷严重程度"三个维度对缺陷进行分析并设置分值，再通过分值来确定缺陷修复优先级

3、非必现缺陷的处理原则

原则1：测试人员发现的任何非必现缺陷，都需要提交。

原则2：测试人员负责对非必现缺陷进行复现，但不等于复现非必现缺陷只是测试人员的工作，开发人员也需要从代码层面进行分析，给出复现建议。

原则3：不能复现的缺陷不应该随便关闭或降低严重等级