与我心有戚戚焉，读《测试之美》

好书值得熬夜

现在是2017年4月1日凌晨三点零三分。我刚刚完成《测试之美》的阅读，并着手整理零散的读书笔记。本来可以在读到一半的时候就可以写出一篇像样的书评或读后感的，但，因为是一本好书，值得我继续花费时间仔细读完。

是bug还是缺陷？

计算机科学历史上第一个被发现的缺陷，真的是一只虫子（蛾子）！而这只蛾子的一个不幸遗产，是使一个原本代表有点麻烦却『基本无害的』小生灵的单词（即bug）逐渐植根于计算机科学的语言中。

这个可爱的小词使得我们低估了软件缺陷可能造成的问题的规模和严重性，并几乎可以肯定，导致了软件公司在质量保证和缺陷管理方面没有足够的重视和投入。然而缺陷往往不是『基本无害的』 ...

所以，我特别认同本书第六章中的观点：使用“缺陷（defect）”这个词来代替"bug"，以帮助提醒我们：我们在处理的并不总是一个可爱的小生灵。

有指标才能更清晰制定目标

长久以来测试团队工作的衡量指标都是与发现的缺陷或缺陷率挂钩。然后科学的指标体系的制定，需要从各个利益相关群体角度出发，比如本书第二章、第六章提到的：

缺陷发现百分比（defect detectionpercentage,DDP）

测试中发现的缺陷的平均成本（Average cost of a test bug,ACTB）

正式产品中发现的缺陷的平均成本（Average cost of a production bug,ACPB)

测试的投资回报率（Test ROI）= (ACPB - ACTB) * 测试的缺陷 / 发现成本；

回归测试自动化的百分比（Regression test automation percentage,RTA）： 自动化回归测试/(自动化回归测试 + 手工回归测试)

回归风险覆盖率（Regression risk coverage,RRC）

回归测试加速比（Acceleration of regression testing,ART）

测试用例有效性（Test-CaseEffectiveness,TCE）

等等诸多衡量指标，有商业价值角度，也有内在效率角度，有指标才能更清晰制定目标。

全书概览

全书23个相对独立的文章，有多位作者编写，被化为三个部分。文章中观点不尽相同，甚至有相左的时候。个人认为，第二、第六、第八、第十五、第十八章值得细度。

第一部分：测试者之美

• 第一章 介绍了如何尊重和设置测试团队的位置，以及如何获得一个为你上刀山下火海的测试团队；
• 第二章 是一个教你如何为测试工作设定可以衡量的指标的干货文章，受益匪浅；
• 第三章 说的是一个开源社区的故事，更多的讲的是以测试为主导的开源社区如何运营的经验；
• 第四章 讲了几个有趣的关于性能测试的实际工作案例，通俗易懂却发人深省；

第二部分：过程之美

• 第五章 讲了微软Office设计改版的一些感受，除了教你强大的模糊测试方法，同时也会提升你的产品设计理念；
• 第六章 介绍了缺陷管理的必要性以及如何进行缺陷管理，并介绍了BugsAnyWhere、BugJuicer等工具的使用，同时也介绍了测试用例有效性指标TCE；
• 第七章 介绍了微软Swift的即时通讯相关测试方法、代码以及感受，对于基于XMPP的产品业务的测试工作有重要参考价值；
• 第八章 介绍了如何做到真正的大规模自动化的干货篇章，读完后泪流满面，与我心有戚戚然！
• 第九章 介绍了开源的Python解释器相关的测试套件，并阐述了Python简单的美学理念：美比丑好；
• 第十章 介绍了随机数发生器RNG测试的微妙之处，诠释了复杂性和统一性的完美结合，文章烧脑，读前慎重！
• 第十一章 讲了高效率测试方法相关的技术：以变化为中心的测试框架。通俗的解释是：哪的代码动了就测哪儿；
• 第十二章 这几乎算是一篇微型小说了，清晰的让读者感受到软件开发、软件测试的专业素养、社会责任，以及需要秉持的核心理念：以人为本，以用户为本；同时也介绍了几种常见的测试理念和方法，值得一读；
• 第十三章 同时是音乐人和程序员的作者介绍了音乐演奏、软件测试工作的相通之处，并对测试工作、理念、方法、协作都谈了一些看法，但干货很少，建议粗读或跳过；
• 第十四章 重点介绍了敏捷开发、测试驱动开发的理念以及实施方法，并对于整个需求到开发上线的流程做了完整的介绍，敏捷团队可最大化受益；
• 第十五章 诚如本章标题『完美测试是商业成功的基石』一样，作者身处敏捷开发、测试驱动团队中，介绍了测试团队在参与商业价值实现、测试驱动方面的一些方法和理念，文章中有不少干货；
• 第十六章 本章的主要观点是，测试没有最佳实践，测试是一种软件风险管理，是一种时间和资源的平衡投入，以寻找有可能惹怒用户的问题。不过作者的理论抽象能力以及讲故事的能力真心不太好；
• 第十七章 阐述了一个看起来很牛逼的SLIME的测试方法，目标是系统化提高测试的效率；

第三部分 工具之美

• 第十八章 介绍了一种简单、优雅的方法来测试整个测试集的质量：植入人为的缺陷，看测试集是否可以发现。理论名称为：变异测试；嗯，对，就是对测试的测试，有点柏拉图悖论的意思；
• 第十九章 介绍了Mozilla的测试框架：参照测试（reference testin）的理念、方法；
• 第二十章 介绍了杀毒软件行业常用的一些开源测试工具、测试理念、测试方法；他们同微软一样，使用了模糊测试方法；
• 第二十一章 介绍了测试web应用程序的工具，Windmill，值得实际工作中了解和尝试；
• 第二十二章 讲述了Mozilla的爬虫工具演变成社区大容量测试框架的历史，并对测试工具整合、进化进行了探讨和分析；
• 第二十三章 介绍了开源平台eBox的测试工具ANSTE的开发历史和心得，对于自研测试工具来说有一定的参考价值。

好文节选

牛逼的测试团队是怎么炼成的

一旦测试人员学会阅读字里行间暗藏的玄机，观察显而易见之外的事物，询问一针见血的问题，以及眼界的扩展，你就成为了一名真正的测试强人，通过继续学习和掌握新的工具，你的力量将随着职业生涯不断增强。

测试人员就像其他职员一样，他们愿意为懂得认可和感谢他们作出额外付出的人不辞辛劳、竭尽全力。... 你会发现如果对测试人员报以对开发人员、数据库管理员等人同样的尊重，就会促进建立一个能吸引和留住顶尖人才的测试团队。

通过培训、认可和平等的奖励制度对测试团队表现出重视，你就会得到一个肯为你上刀山下火海的测试团队，他们还会把你的公司推荐给业界中和他们一样优秀的人才军团，并不需要有业界最高的薪酬待遇，你就可以吸引并留住精英中的精英。

质量成本

衡量一个故障成本的公认技术被称为“质量成本”：

• 发现成本： 就算我们没有发现缺陷，也会有测试成本。例如，进行质量风险分析，建立测试环境，并创建测试数据的这些活动都会产生测试成本。

• 内部故障成本： 因为发现缺陷而导致的测试和开发成本。例如，提交缺陷报告，解决缺陷，确认测试缺陷已解决和回归测试改动过的构建这些活动，都会产生内部故障成本。

• 外部故障成本： 因为无法提供100%无缺陷的完美产品而产生的支持、测试、开发和其他成本。例如，很多技术支持或客户服务的组织和系统维护的工程师团队的成本都是外部故障成本。

简易的设计是强大内功的体现

微软Office 2003的用户行为统计中，粘贴、保存、复制、撤销、加粗，这五个操作占据了所有命令使用次数中的32%。

考虑到微软Office套件有数百个功能，得知所有用户的操作几乎有三分之一被这么小和简单的集合覆盖，确实令人惊讶。或许更重要的是，这个统计强调了保证办公应用程序最基本功能可靠性的重要。它也说明，许多用户用屈指可数的功能就可完成数量可观的任务。

虽然传统的办公套件仍然流行，但这些替代者提醒我们，为用户提供最少烦恼和可靠功能是何等重要。用户用这样的功能可以写出范围很广的文档——从普通的到漂亮的，而无需很在意他们所选的工具。

后记

《测试之美》不是一本孤立的书，同系列的还有《数据之美》、《团队之美》、《项目管理之美》、《架构之美》、《安全之美》，全套6册。

嗯，要读完它们。