前面也说过我最近在做C++相关的重构，这是一个相对新的项目，因此软件工程中的各个方面都需要完善。软件测试是我能想到最直接的一个方面。

因为当前这个项目对程序的健壮性有较高的要求，软件测试想必是对这个要求的最佳保障，为了能够在构建测试以及规划测试时考虑得更周到，特意借来了这本经典书籍，Ron Patton著作的《软件测试》。我同时还借了一本《软件工程》，也是希望能补充了解一下测试之外的领域，不过才刚刚开始看，暂且不表。

这本书由浅入深，层层递进。从说服读者测试是必要的开始，到测试的定义，然后介绍各种类型的测试，再是一些延伸话题，最后还有相关职业发展的内容，结构十分清晰，确实是一本入门的好书。也许是国外作者都更倾向于把问题上升到哲学层面，这本书具体技巧较少，概念和相关的故事较多。其实这也有好处，就像方法和方法论的区别。这本书教你方法论，让你能考虑到很多问题，遇到现实中具体问题的复杂组合，可自行根据书中原则思考探索具体方法，并不必要书中主动提出；如若书中只提出一堆方法，反而令人眼花缭乱，容易混淆，不知道什么情况下该用什么了。而且，方法可能有局限性，可能会过时，不总能适用；方法论则往往通用。授人以鱼不如授人以渔，授人以渔不如授人以学渔之道，以免换一条河就钓不上来鱼了。

关于软件测试的重要性，其实怎么强调都不为过，但怎么强调都会有人不以为然。恐怕只能指望这些人亲身在拥有良好测试的项目中体验过后，才能心甘情愿地说，测试“真香”！所以，也就不必多说了，懂的自然懂，不懂的保持敬畏之心，勇于尝试就好了。

本书提出测试的目的，就是发现Bug，尽早发现Bug，尽可能让Bug被修复。

Bug发现得越早，修复的成本越低。这个很好理解。比如产品开发之前，测试人员对需求、功能定义中存在的问题进行纠正，可以避免开发过程中频繁变更功能设计；如果开发已经如火如荼地进行起来，再发现功能设计有致命的缺陷，痛苦的返工就是不可避免的了。还有，产品发布前，用户尚未接触到产品，开发人员修复Bug要轻松很多；产品发布以后，我们就不得不考虑如何为庞大的用户群体分发修复补丁了，而且Bug造成的影响也可能已经扩大了。

测试也不仅仅是发现Bug，还要让Bug尽可能被修复。这就要求测试人员对Bug进行记录和追踪，同时进行团队间的沟通协作。毕竟，测试人员只发现Bug而不去做后续工作的话，大概没有几个开发者会主动修复Bug。

本书令人耳目一新的是对测试的分类总结。本书对测试从两个维度进行分类：静态与动态、黑盒与白盒。

静态与动态区分是否真正把产品运行起来，黑盒与白盒则区分产品的实现是否对测试人员可见。

• 静态黑盒测试，即检查产品的规格说明书。有很多错误源自对需求、功能的定义不清淅，甚至有误，因此不可小觑这一测试的作用。
• 动态黑盒测试，即通过使用最终的产品来进行测试。这是最能模拟用户使用产品的测试方式。
• 静态白盒测试，即代码审查。关于代码审查，除了我们熟知的由作者之外的几个人进行Code Review这种方式之外，作者还介绍了几种方式：代码作者汇报解释他自己的代码，或者由其他人阅读他的代码来做汇报等。
• 动态白盒测试，即对程序代码的测试，基本上就是类似单元测试、集成测试的过程。

看完这本书，印象最深的一个词，就是Equivalence Partition（等价划分）。可以说，每每遇到需要具体分析的问题，涉及具体方法的问题，作者都会说，没有标准答案，请使用等价划分的方法论！

可以说这个概念是测试领域的“万金油”。这里并无贬义，毕竟现实就是复杂多变的，谁也没有办法做到测试完全。通过等价划分，尽可能让测试涵盖不同的场景，不同的分支情况等，从而实现更好的测试效果。书中有提到一些关于如何进行等价划分的建议。当然这是测试的核心问题，网上也可以搜到很多相关方法。

最后，书中还有一个说法令我印象深刻。不要指望仅仅通过引入测试来减少Bug。减少Bug并不是测试的功能或目的。测试仅仅相当于一种对Bug的“观测”，真正修复Bug的是开发人员。作者有个形象的比喻，没有医生会通过使用更多的体温计来帮助发烧的患者退烧降温。

作者在这里想表达的是，当发现Bug很多时，应当反思优化开发流程，而不是一味地投入测试。

如果开发流程是随心所欲的，比如测试永远只在产品开发结束后介入，没有人对产品需求和功能定义把关，甚至压根就没有这类具体的定义，那么无论再怎么投入测试也仅仅是不断地发现Bug而已，甚至就算修复了，又会源源不断地引入无数新的Bug。

作者提到了ISO9000系列标准，这是一系列质量管理体系标准。换句话说，它是对团队流程的评估。它通过对质量保证相关流程的观测，来反映团队产品可能达到的质量。毕竟，一个产品的质量是难以客观地进行评估的，但一个团队开发产品的流程是可以被严谨客观地观测的。

这不禁让我想到，当前开源项目质量良莠不齐，当我们在做一些产品想要采纳一类开源项目时，往往要考量很多方面做出选择。开源项目的健壮性是很重要的一点，但这一点又很难去判断，往往只能通过查看其活跃度、测试覆盖率、持续集成、文档丰富性、社区互动等情况来做出判断。每一个项目都去做一系列调研其实是很花功夫的。

如果将来有一个开源项目质量管理体系标准，开源项目都能去做一下认证，或者由诸如GitHub这种开源社区来做自动化的认证，是否可以大大提升开源社区的透明度，让优秀的开源项目获得更高的曝光度，也避免不成熟的开源项目被误用呢？

不知道这是不是一个幼稚的畅想，我倒觉得还挺有意义，尤其是如果真的可以自动化地做出一些指标统计的话。

总而言之，这本书很全面，不管是通常大家理解的程序上的测试，还是一些不常见的测试（例如对国际化、残障人士辅助功能、硬件兼容性、产品文档等的测试），都有涉及。当然，这本书比较老了，像当下较为流行的自动化测试，书中介绍的篇幅就比较少，也比较过时。但这不影响方法论的通用性。就算测试工程师不是你的职业梦想，长长见识也是值得的。

最后，我真的感觉，相比很多工程领域（像盖房子造大桥了……），软件工程真的很宽容，以至于市面上的软件产品质量参差不齐。

另外，我还真是挺纳闷，为啥现在好多公司都不要独立的测试岗位了呢？似乎说是把用户当测试就够了……

我倒是怀疑这是一个阴谋，也许大老板是想让公司各个团队的小领导自行决定是否要加强测试——那些不愿测试的团队大概迟早会失败，真是替公司领导做裁员的选择省去了麻烦呢！