测试架构师修炼之道：从测试工程师到测试架构师（第2版）

本书从测试工程师的行业现状出发、解答了测试工程师遇到的职业瓶颈，同时在做好测试工程师的基础上，向测试架构师迈进，掌握测试架构师的核心技能。 比较深刻的几个总结： 1、敏捷开发模式下测试的可行范围更广：迄今的开发模式有三种：瀑布、敏捷、DevOps, 在当前比较流行的敏捷模式下，测试可以直接参与产品规划；与用户交流，收集需求；可以像开发人员一样去编码；可以使用工具做自动化；可以使用流程做质量改进；产品的职责发生变化，从质量守护到产品赋能：场景测试、性能测试、探索式测试、更有效的测试策略等使 测试具有系统和全局视角。 2、职业规划上分为管理上和技术上：管理上--基层测试组长（负责安排小组工作、承担小组中最重要种负责的测试工作）、测试经理（对测试的全流程负责，需要和不同角色进行沟通协作完成产品目标，解决团队测试中遇到的困难、难题，不断提升团队测试能力）、测试总监（负责一条或多条产品线、不在需要从事测试工作，但要关注测试新技术）；技术上--测试架构师（对不同组织、产品、研发模式做出适合当前状况的选择）、测试技术专家（测试分析设计专家、测试流程专家等）、测试开发人员（自动化测试架构的测试开发工程师、效能工具链测试开发）。 3、测试架构师必备的6个关键能力：明确测试目标、测试重点的能力；明确测试目标、测试重点的能力；测试分析、设计和执行能力（包括工具和自动化）；有效沟通的能力；持续学习和探索的能力。 4、软件产品质量模型：8个属性（功能性、兼容性、安全性、可靠性、易用性、效率、可维护性和可移植性），如何运用8个属性进行具体的测试工作 5、如何制定测试策略：明确产品质量目标（完全商用、受限商用、受限试用、不能使用）、产品特性价值分类（无人问津的特性、核心特性、辅助特性、噱头特性、潜力特性）、风险分析（确定测试重点和优先级）、适配产品开发流程（开发过程中关键节点和运作方式）、测试分层（将有共同测试目标的测试活动放在一起）。常见分析模型--产品覆盖度分析、测试过程分析、缺陷分析等：需求覆盖度评估、代码覆盖度评估；质量评估分析、测试用例执行情况分析、测试方法分析；缺陷密度分析、缺陷修复情况分析、缺陷趋势分析、缺陷年龄分析、缺陷触发因素分析。 本书虽然是在说测试工程师，但是对我这个开发工程师，是一样适用的，在开发的路上遇到的迷茫都得到了解答，同时也对日常工作中对测试工程师的做法不认同的点有凭证能够反驳，后面几章更多的是理论上的介绍，要是能够有更多案例之城，我可能会理解的更透彻一些。总而言之，很庆幸能够看了这本书，虽然短断断续续的阅读，但是也终于是读完了，前进之步伐虽小，但只要走总能走到尽头，值得我反复去阅读、去理解。

本书理论很强，体系健全，逻辑自洽，覆盖广泛，长期从事测试工作的人才能深切体会书中描述的情形。不谋全局者，不足以谋一域。不谋万世者，不足以谋一时。测试工作不是为了找缺陷而找缺陷，是为了商业目的和产品价值，从全局角度系统层面进行统筹安排，按照特定时期的目标进行最大限度的软件质量保障。 从产品立项，明确需求，特性分析，风险评估，测试策略，测试设计，沟通协调，再到资源分配，人工和自动化组合测试方法，按时交付，均有详细阐述。 没有任何一位测试人员能穷尽所有的情况，掌握测试技术，拓展测试视野，做出最适当的测试选择，才是测试人员的核心能力所在。认清现实，不断探索，在有限的条件下追求效益最大化。测试架构师必备的6个关键能力： 1.明确测试目标、测试重点的能力； 2.敏锐的风险识别和有效的风险应对能力； 3.测试分析、设计和执行能力（包括工具和自动化）； 4.质量分析和评估能力； 5.有效沟通的能力； 6.持续学习和探索的能力。

推荐作为测试手册参考，结合《Google软件测试之道》阅读。书中不仅讲测试的职业规划，也提到了国外测试专家、软件开发专家的测试理念和观点，包括自动化测试的观点，非常值得进一步阅读、体会和实践。可以从这几个方面阅读，重点推荐2和3：1. 测试的职业规划，测试架构师的关键能力和知识体系。*2. 测试理念、观点和方法*3. 自动化测试理念、观点和实践4. 产品质量的8个属性和测试方法5. 做产品的启发 书中要点，零散笔记：1. 测试的职业规划（1）测试可以在管理方向和技术方向相互转换 “测试架构师是测试技术方面的一个发展方向，是产品测试技术专家，其主要职责是对不同的组织、产品、研发模式做出最适合当前状况的选择，进行刚刚好的测试，为产品成功保驾护航，提供支撑。”（图2-8） “测试架构师的工作是保证测试的正确性，而测试管理者的工作是保证落地和交付。” （2）测试架构师的关键能力和知识体系。6个关键能力（图4-1）、测试策略的全局视角（图4-2）和测试技术知识体系（图5-1 ）。 2. 测试理念、观点和方法（1）"Test is Dead!" 真实的含义（by Savoia） “真正死去的，是那些传统模式下重复的、低效的、堆人的测试，取而代之的是那些更加专业的测试，这些测试不仅不会死，还会成为抢手资源。” 测试可以通过自动化固化产品的基本能力，测试人员是最贵的资源，他们应该聚集更有效的测试策略，实现场景测试、性能测试、更高效的探索式测试。 （2）探索式测试(Explortary Testing) 不是“发散测试找缺陷”，而是一种测试风格，强调并行、交互地开展学习、测试设计和执行。ET的定义可以查看Wikipedia介绍。 ET思维模型是CPIE（Collation，Prioritization，Investigation，Experimentation），包含整理、排序、调查和实验的4个阶段，并持续迭代。ET需要针对特性的价值，进行分区，并根据不同的分区，选择不同的ET方法。 “和探索式测试对应的是脚本式测试（ScriptTesting，ST），脚本式测试要求测试人员编写测试脚本去记录所有的测试用例（包括测试操作和预期），然后通过脚本来实施测试。” James Bach总结的探索式测试和脚本式测试的差别：“在脚本式测试中，测试人员先设计测试用例，再在一段时间后执行这些测试用例，或者测试用例被其他测试人员执行。而在探索式测试中，测试用例是在测试执行时被设计的，而且大部分测试用例不需要详细的记录。” 探索性测试在整个测试中，理想的占比是多少，参考图4-14。 （3）开展基于产品特性价值、以及高价值特性的风险的测试，是一种验收策略。 （4）价值流：价值流是精益模式中的一个基本概念。Karen Martin和Mike Osterling在Value Stream mapping中，把价值流定义为“一个组织基于用户需求所执行的一系列有序的交付活动”，包含了拿到用户需求后，为用户进行设计、生产和提供产品服务所需的所有活动。测试活动在VSM中，需要体现高价值。 （5） 启发式测试策略模型：测试专家James Bach提出的启发式测试策略模型（Heuristic Test Strategy Model，HTSM），由项目环境、产品元素、测试技术和质量标准4个维度组成，如图9-9所示。 （6）可测性：系统对输入，以某种方式提供反馈，以便评估系统行为（用户）或者实现（技术）是否正确的可能性即可测性；质量的8个属性，都要分析可测性； （7）测试设计：“好的测试设计得到的是整洁的测试用例”，参考《代码整洁之道》。实例化需求是强大的测试思想，在自动化方面的应用也是，参考《实例化需求-团队如何交付正确的软件》by Gojko Adzic。 3. 自动化测试理念、观点和实践 （1）“自动化测试其实是一种误称，因为无论如何尝试自动化测试，都需要引入大量测试人员。自动化测试可以理解为“工具支持的测试”，使用任何工具来帮助测试都属于自动化测试的一种类型。“（James Bach自动化敏捷测试，2003） （2）“自动化测试的意义首先在于固化能力，其次才是提升效率”，而不是反过来，强调效率，但不能做到有效的能力固化；不能固化能力的自动化用例，也可能成为类似nonDeterminism的用例，也无法达到为产品重构提供信心的好处； （3）“自动化测试最基本的要求其实就是两点：测试者能够充分信任自动化的结果；自动化脚本可稳定连续运行，可维护，可移植。”即自动化用例：a）不能是nonDeterminism的用例，否则它们无法被信任；（参考Martin Fowler关于nonDeterminism博文:https://martinfowler.com/articles/nonDeterminism.html）b）自动化脚本应该具有原子性，维护不应随着用例的增长而快速增长，甚至变得无法维护。c）自动化脚本应该能反复运行，即不依赖产品环境的数据，用例应该不关心系统初始状态，或者创造系统的初始状态，在自动化测试结束后，清除自动化测试过程创建的数据和痕迹； （4）自动化测试推荐金字塔模型，Martin Fowler 认为， 基于用户接口（如UI）的自动化测试运行慢、效率低、维护开销大。因此自动化测试应该投入更多的精力在单元（Unit）和接口（Service）层，这样不仅自动化测试效率更高，还可以更早发现质量问题，提升系统质量。（参考 https://martinfowler.com/bliki/TestPyramid.html） 自动化测试的其它模型，比如Trophy和Honeycomb的讨论：https://martinfowler.com/articles/2021-test-shapes.html 许多产品的测试是钉子模型，UI的手动测试占比非常高，接口和单元测试的比例低。规范的接口定义，合适的自动化理念、流程和框架，以及自动化测试的分层，是达到测试金字塔模型的前提。 举个简单的场景，如果产品开发涉及前后端的数据交互，后端接口返回的数据，不符合规范，比如数据的类型、结构以及资源等的描述或操作不符合规范，前端需要进一步封装或者业务逻辑处理，那么，接口(service)层的自动化可能无法做得很充分。因为，即使接口层的自动化用例全部通过，但数据可能不是前端直接就能用的，整体的自动化效果会打折。后续接口逐步规范的演进，也带来更多的维护工作。 （5）自动化测试工具需要考虑其提供的工程能力见“图4-113　自动化测试工具评估项”，而且自动化不仅仅是回归测试，而是需要发挥创造性思维，明确测试理念和思想，选择合适的测试框架、框架，做适合自己产品特点的自动化。（参见《自动化测试最佳实践》Dorothy Graham） （6）自动化成熟度可以评估参见图4-115，4-116的自动化成熟度模型和成熟度评估指标。 （7）DevOps/CICD的自动化CICD、DevOps流水线上的各层测试全部自动化，参考“图4-110　DevOps自动化效能平台架构”。可以通过《持续集成软件质量改进和风险降低之道》、《持续交付发布可靠软件的系统方法》进一步拓展理解。 4. 产品质量的8个属性主要可以作为手册参考的内容：（1）车轮图（2）各个属性详细测试内容（3）属性的评估 5. 产品启发（1）如何理解产品的商业目标和价值呢？可以参考商务知识和软件架构的交错关系的气泡图（by Dave Hendricksen），见图3-1。 （2）产品特性价值分类销售/核心、噱头、继承、辅助特性等，不同特性质量要求、测试方法都是不同的。"一个确定核心特性的取巧方法，即对那些比较成熟或正在持续演进的产品来说，用户反馈缺陷最聚焦的那几个特性，往往就是核心特性。" （3）"软件中约有2/3的特性很少或从未被使用过"，因此需要谨慎规划产品特性，以及售卖的商业模式。Standish Group的调研结果显示：“真正被用户使用的特性大概只有20%（7%一直使用，13%经常使用，16%有时使用，45%几乎不用）”。文章“A Quick Look At The 7 Wastes of Software Development”指出：很多权威统计数据都显示，现有软件中约有2/3的特性很少或从未被使用过。 （4）产品存在“痛点”“爽点”和“痒点”参见《产品思维30讲》（梁宁）

我觉得这里面的测试设计思路真的蛮好的，蛮好的打测试功底的书，前提得静下心来看

什么是刚刚好的测试？如何做到刚刚好的测试，达成共赢的局面？作者从需求分析，测试分析，风险分析，风险分析和质量评估等维度进行端到端的分析，一环扣一环，缺一环可能都不容易完成。

在软件测试领域，我推荐新手可以阅读《软件测试的艺术》和《测试架构师的修炼之道》作为入门。 Myers《软件测试的艺术》这本书的部分观点虽然有点陈旧了，例如缺乏适应21世纪当代敏捷开发的内容。但作为测试领域的“圣经”，该书依然非常适合初学者了解测试——作为一个工程实践领域的发展史，以及深入领悟测试领域的科学哲学。更多关于敏捷开发的内容，可以通过刘老师《测试架构师的修炼之道》这本书补充。 找工作前通过该书补充领域知识，背面试“八股文”。工作几个月后重新阅读，确实也基于实践获得了更多深入的领悟。在有工作经验后，这本书也是常看常新的。 这本书的新版本时间早于AIGC时代，而在AIAgent辅助编程大行其道的2026年。测试以及软件开发行业也产生了新变化。例如汇编语言和高级语言的执行结果几乎没有不确定性，所以软件开发行业不需要考虑“容差”，但“容差”在其他工程学领域就非常重要。 而自然语言编程，每次输出的结果都具有不确定性，这将“容差”重新引入了软件行业。新一代工程师（例如我）很多已经不会“古法编程”了，如何把这些菜鸡组织起来协作（笑）？ 另一方面，对各类黑箱模型（例如LLM）的评测工作，也成了测试领域的新重点。例如各类Bench marking（基准测试）非常火爆。而对于发展程度落后于LLM的，物理模型/世界模型/VLA（视觉-语言-动作）模型，如何建立一个好的，以及能促进模型质量改进的Benchmaking，依然是一个重大的挑战。

我前15年做测试，属于国内第一批做这个的，后5年做了开发。说实话，我感觉，测试是一个缺少自我的职业，他的能力很少一部分体现在测试本身的技能，因为它本身也不需要啥技能，更大的技能需求体现在开发知识和业务理解。不懂业务，你不知道测试的标准，不知道啥是对的，啥是错的。不懂技术，你很难有足够的手段去测试底层功能。所以，当我做了开发，数据工程师，云工程师，基本上啥都干过了，才发现测试需要的是全才，而非专才

半个月读完了这本书，从测试角度来看讲的很有价值，很详细，但对于书中的一些方法也要根据自身工作环境去优化使用。 很多事情需要大量时间，需要良好团队，更需要跨部门合作和理解。测试不仅要做好自身也要让不懂测试的人理解你支持你，不然测试本身很难有超出让别人认可

本书体系全面，偏理论，轻实践，需要有一定测试经验的人去看。本人做为开发者，从此书全面了解了测试工程师这个职业，其中很多关于需求分析和测试策略与用例的设计，做为开发一样受益良多

以前很想把自己的工作经验总结成一本书，看了这本书之后，觉得真没必要了！ 测试策略方面，很多我想到的没想到的，本书都有介绍了 但是，请注意，所有事情都要理论联系实际，理论并不一定100%匹配你现在遇到的问题，但是绝对值得借鉴。