聊聊测试的左移和右看（合辑共13篇）

这是鼎叔的第一百零一篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。

第七个原创文章合辑“测试的左移和右看”OK了，没想到整理出来十三篇文章这么多，应该算业界相关领域内容最丰富的大白话原创合辑了。

测试左移的本质是，既然越早进行质量内建活动，得到的收益越多，为什么不把技术人员的一部分精力放在更早期的环节进行质量推动和把关，总的质量保障收益是更高的。

测试右看的本质是，既然验证发布效果是持续改进的动力，为什么不在系统测试结束后，持续投入一定的精力，观察用户对质量的期待是否与认知相符，从而在未来的研发周期采取果断改进行动。

这十三篇文章分为四部分：测试左移，代码的整洁，持续测试与DevOps，测试右看。

Part 1 测试左移

聊聊测试左移到需求阶段

测试左移是多年来测试行业的热门话题，在实际的践行中容易停留在“意识流”层面，仅仅是鼓励测试人员应该“主动做什么”，然而在业务压力大的常态下，被鼓励的尝试往往无疾而终。只有基于敏捷理念的理解，对研发生命周期各个环节进行质量内建实践，才能把测试左移落实成好习惯，形成好流程，最终内化为敏捷团队的本能。

而产品研发的源头，自然是需求产生及澄清阶段。精益需求的产生过程，就是测试左移最早可以发力的地方。

精益需求的相关管理和实践知识，请关注上一个专辑：聊聊精益需求管理（合辑共九篇）

聊聊测试左移到开发阶段

通常在开发阶段，开发人员做的事情是开发设计文档，编码，CR（代码评审）和开发自测等工作。与此同时，测试人员的常规活动是准备测试策略，测试用例设计，用例评审和自动化测试相关准备，等等。

本文提到的测试左移，是指测试人员除了要学习开发人员提供的设计技术文档（用作测试设计的参考）以外，还可以积极参与开发相关的重要活动，更早地暴露问题，减轻而非加重开发人员的负担。

测试人员的目的从发现缺陷变成了预防缺陷，这会导致与开发人员协作关系的重大变化。

聊聊什么是测试左移（翻译）

你越早发现代码中的问题，它们的影响就越小，处理这些问题的成本也更低。本文翻译自Arthur Hicken的博客，我们将探讨测试左移方法以及如何在你的组织中实现左移。

作者：Arthur Hicken

翻译：鼎叔

PART 2 代码整洁

聊聊代码的整洁（上）

《代码整洁之道》这本书最有影响力的一个观点，就是代码的好名字本身就解释了最重要的信息，如无必要，不要增加代码注释。这个观点和传统软件质量观点是不同的。

聊聊代码的整洁（下）

下篇继续聊《整洁代码之道》，我们分享注释、代码格式、类、系统如何做到整洁，以及代码坏味道的处理清单。

聊聊单元测试的整洁

敏捷及TDD鼓舞了很多程序员编写自动化的单元测试（参考 聊聊测试驱动开发），但是他们经常会遗漏编写好测试时很重要的细节。测试代码也需要遵守一定的质量标准，“脏测试”等同于（甚至还不如）“没测试”。

测试代码和生产代码一样重要。

PART 3 持续测试与DevOps

聊聊持续测试

如果在测试部门只能推行一个技术建设项目，那鼎叔就会选择“持续测试”。

持续测试（Continuous Test，CT），也有公司称为每日测试（Daily Test），就是每天都有新版本生成并完成相应的测试活动。尽可能在当天就发现是否有基本功能被新代码破坏掉，缩短解决问题的闭环，并让大团队对新代码提交保持信心，这样的实践契合“频繁测试”、“集体对质量负责”的敏捷原则。

聊聊持续测试的进阶

这篇继续聊聊持续测试建设的ROI分析，思考未来的成熟度进阶，以及其他要注意的。

第一阶段，跑起来，形成纪律。

第二阶段，成熟的流水线部署，能够应对大团队的持续测试需求，并做好精细化管理。

第三阶段，流水线的智能化+精准化，以及不稳定测试集的隔离。

聊聊如何测试你的测试（翻译自Meta）

鼎叔第一篇自行翻译的硅谷公司技术文章，来自facebook(Meta),关于flaky test的量化度量与应用，这也是国内很多大学教授喜欢的研究课题。Flaky test，有些人翻译成不可靠测试，形容有时通过，有时不通过，没有明确的失效重现概率。

原文：How do you test your tests?

翻译：鼎叔

聊聊《阿里巴巴DevOps实践指南2021》

认真读完阿里巴巴的DevOps实践指南（2021版）电子书，推荐给大家，说说个人的想法。

本来写了3500字的流水账读书笔记，太长了，改用思维导图重新画了一遍，方便看看。

PART 4 测试右看

聊聊测试的右移

完成端到端测试（也可以称为系统测试）阶段后，进入灰度发布或正式发布阶段，测试人员除了采集和分析缺陷外，也需要抽出一定精力，持续进行高价值的质量保障活动。

与其全身而退（立刻投入下个新版本的测试准备），不如花一些精力对当前发布版本多做一些高价值的质量活动，获得宝贵技能，再通过问题反思不足，验证测试策略的有效性，以便在下一个发布周期做得更好。

聊聊混沌工程

混沌工程是一门新兴学科，它不仅仅只是个技术活动，还包含如何设计能够持续协作的混沌实验。它由Neflix首先在实践中发现了混沌工程的商业价值，通过构建更有韧性的系统来抵御海量组件系统的意外失效。本文还会聊聊混沌工程的概念澄清，原则，投资回报和成熟度模型。

聊聊混沌工程的企业实践

知名公司的混沌工程实践有：谷歌的DiRT计划（灾难恢复测试，已经进行了数千次），Slack的灾难剧场，微软云平台混沌工程等。很多公司把混沌工程实验做成“Game Day”，用游戏比赛的有趣竞争状态来进行混沌实验，而不是制造如临大敌的气氛。

混沌工程的系统方法、原则和步骤，不止应用于分布式大型软件，也应用于软硬件一体的互联系统，如汽车自动驾驶系统。混沌工程也应用到了网络安全领域。

本文详细介绍各大企业实践混沌工程的优秀流程，经验教训，人为阻力，人和组织的能力提升，我们能从中学习到一些宝贵的洞见。

专辑的最后总结

本专辑分别介绍了在需求、开发、发布阶段中，测试人员可以做哪些“左移后看”的具体敏捷实践。

需求阶段，测试人员要理解需求背景和目标价值，研究用户画像，梳理用户故事场景。如果能够在需求评审时给出验收测试点，并完善需求质量评审检查清单，就能够让开发人员在写代码前就清楚“考点”，提高自测质量。

开发阶段，测试人员可以参与开发设计评审、TTD、代码评审、桌面检查和持续测试构建，落实代码规范纪律，同时也尽可能通过开发合作获得软件内部的知识，及早揭示可疑之处。

在部署和发布阶段，测试人员并不是早早转向下一个迭代工作，而是细心观察产品的可用性，监控关键服务质量和负面舆情，关注发布质量目标是否达成，及时干预品质口碑的风险，甚至可以根据用户行为数据对冗余用例集做优化。