测试杂感：测试只是反馈信息？

2010年第9期的《程序员》杂志刊登了荣浩先生的文章《关于测试的八个问答》（在线版本发布在JavaEye上）。这是一篇充满思辨的优质文章，有许多观点值得借鉴。但是，我对如下文字有不同意见。


    我说，那么，测试保证了质量？
    神说，你觉得三鹿没有测试吗？
    我说，….

    神说，测试只是提供信息。至于这些信息的定义、重要性以及所要采取的反应都取决于人，而人做出的决定都是感性的，利益驱动的。

    我叹口气，说，测试能够保证软件质量。

    神说，如果开发的产品本身就质量低劣，进行测试你不觉得是浪费大家的时间吗？一段时间发现的缺陷越多，并不意味着剩下的缺陷越少，而是意味着会出现更多的缺陷。

    我说，我明白了，测试只是反馈信息，除此之外，并不能做其他任何事情。正如我们去体检，体检报告只能反映当时我们的身体状态，至于健不健康，则取决于我们平时的生活习惯，这是两个分开的事情，体检并不保证我的健康。

    神说，是的。


荣浩先生认为“测试只是反馈信息，除此之外，并不能做其他任何事情”。但是得出这一结论的推理过程是不严密的。

荣浩先生先用三鹿的例子精彩地指出一个事实：有些企业的负责人不顾质检信息，出于私利，发布有重大缺陷的产品。在这样的企业里，测试活动不能影响产品生产和发布，不能保证质量。之后，荣浩先生提出，如果产品质量非常低劣，测试可以发现大量的缺陷，但是“边测边改”的混乱过程无助于提高质量。

以上两个观点都是令人信服的。但是，它们是对两个极端情况的分析，并不能得出普遍结论“测试只是反馈信息”。在大多数企业中，企业负责人不会草菅人命，他们被客服电话所折磨，也希望自己的产品能有个好质量。在大多数项目中，代码质量即便达不到卓越，但也能够满足基本要求。在这样的环境中，测试可以保证质量吗？

我的观点是：测试不能“保证”质量，但是测试有助于提高质量。

测试不能保证质量，是很容易理解的。按照现代质量理论，质量不是某个角色的职责，而是整个组织的职责；质量不取决于某项活动，它由所有活动共同构建。在软件生命周期中，战略规划、需求协作、架构设计、编码实现、测试检验、重构优化、推广营销，都对用户可体验的“质量”有重要影响。组织领导、项目经理、程序员、测试员都要对质量负责，他们的活动将共同决定产品质量。

虽然任何单一活动都不能保证质量，但是测试对于提高软件质量有着重要作用。而且，其作用已经远远超越单纯的“反馈软件缺陷信息”。


    * 对于开发人员，测试已经成为一项重要的设计与编程工具。
    * 对于敏捷团队，测试已经成为一项团队支持工具。
    * 对于测试者，测试负责且必须承担反馈信息的职责，但是他可以做得更多。


任何严肃对待软件的开发者都应该谨慎考虑Martin Fowler的话：


    The reason JUnit is important, and deserves the Churchillian knock-off, is that the presence of this tiny tool has been essential to a fundamental shift for many programmers. A shift were testing has moved to a front and central part of programming.

    JUnit之所以重要且受到丘吉尔式的赞誉，是因为这个小工具对于许多程序员的根本性转变至关重要。这个转变是测试移动到编程的前沿和中心位置。（摘录自《xUnit Test Patterns · 前言》）


以JUnit为代表的xUnit家族得以流行的根本原因是测试驱动开发（Test Driven Development）被普遍地认同和实施。Kent Beck将一种简单的实践发展为强大的编程工具，单元测试不仅是错误检查者，还是类型设计工具、可执行的规格说明和重构安全网。Jimmy Nilsson将测试驱动开发提升到架构级别，利用具体的测试用例来实施领域驱动设计（Domain Driven Development）。测试不但是单元（类或函数）设计的驱动力，也是体系结构设计的驱动力。

任何设计都要落实到代码且通过测试检验，才算完成。从抽象思考到代码实现的过程就是“编写测试，编写代码，通过测试、代码重构”的反复循环。在每一个小循环中，测试、编码、重构都对代码质量作出密不可分的贡献。单独强调某一项活动的贡献或忽略某一项活动的贡献，都是不恰当的。

在敏捷团队中，测试专家Lisa和Janet认为测试承担两种职责：支持团队（Supporting Team）和挑战产品（Critique Product）。从支持团队的角度，测试可以视作一种开发活动。一些敏捷团队使用用户故事（User Story）来组织开发。在编写产品代码之前，程序员或测试员会和用户协作，一起定义该故事的用户验收测试（User Acceptance Test）。他们通过编写测试来实现“用户协作”：挖掘需求，确定细节，建立共识。在故事开发过程中，持续集成会频繁的运行各种测试用例集，来检查最新的签入（check-in）没有破坏对产品的约定。对于任何故事，只有所有的单元测试、功能测试和用户验收测试全部通过，它的开发才算完结，才能被标记为完成（Done）。由此可见，测试至少在如下方面渗入到软件开发的全过程。


   1. 与用户协作编写用户验收测试。它们作为可执行的规格说明，精确地描述了对产品的期望。
   2. 开发者编写单元测试完以成单元设计，开发者编写功能测试以完成代码集成。
   3. 持续集成的测试通过率提供了开发状态的重要信息。
   4. 用户验收测试的通过率提供了开发进度的重要信息。


测试仍旧是“反馈信息”。但是对于一个有进取心的团队，它所提供的信息也是推动产品研发、监控开发流程、优化开发过程（优质的开发过程会缓慢但长远地提高产品质量）的动力之一。

对于大多数测试者，测试的主体仍旧是“挑战产品”并汇报在该过程中收集的信息。不过，测试专家们鼓励我们用全新的视角考察测试。Chris
McMahon在《测试之美》中提出了一个崭新的、极富启发性的隐喻：软件是依赖于人的艺术品，测试者是“审稿人”。


    Good software testers supply critical information about value to people who care about that value, in a role similar to that of a book reviewer or a movie critic.

    好的软件测试人员会向重视软件价值的人提供有关于价值的关键信息，他的职责类似于书籍审稿人或电影评论家。

    Great software testers make aesthetic judgments about the suitability of entire approaches to software development itself.

    伟大的软件测试人员对于全体软件开发方法的适当性做出美学的判断。


“审稿人”隐喻带给软件测试全新的视角：不仅发现错误，而且驱动软件向更好的方向发展。审稿人也是“反馈信息”，她不会代替作者去写作，但是她会对文章主题、篇章结构、论述逻辑、研究方法、实验结果、引用文献等提出深刻的、富有洞察力的问题。要回答或解决这些问题，作者必须通盘考虑整篇文章，从架构到细节都作出深思熟虑的改进或重组。一个好的审稿人能够推动作品向更高层面发展。

作为曾经的学术论文审稿人，我在不同的会议审稿中三次读到同一篇论文。这意味着该论文至少被拒稿过两次。第一次投稿时，该稿件的质量已经不错，但是被拒绝了。后来，作者作出了重大修改，再次投稿，无奈再次被拒稿。于是，他再次大幅度修改。第三稿可谓脱胎换骨，质量远胜第一稿。我不禁感叹：如果在第一稿的时候就让它通过，那么就错失了一篇更佳的稿件，作者就丧失了反复锻炼并提升自我的机会，审稿人的把关和反馈何其重要！

软件开发自然有其独特的规律，不能反复地大幅度修改，但是将测试推向更高层面，全面且深刻的洞察软件产品和开发过程，无疑是测试的发展方向之一。

此外，测试还有一个不容忽视的使命：帮助测试者和团队成长。测试专家James A. Whittaker提出了一种测试实施方法：Bugs → Patterns → Test Automation。


   1. Bugs：找到软件缺陷（Bug）。
   2. Patterns：分析出缺陷的根本原因（Root Cause），编写出一个模式（Pattern），用它捕获相似的缺陷。一个模式是一个结构化的攻击手段，它包含如下内容。

          * 何时实施该攻击？
          * 该攻击会捕获何种错误（Fault）？
          * 利用该攻击如何识别软件失败（Failures）？
          * 如何指导攻击？
          * 样例和分析。

   3. Test Automation：识别出攻击过程中重复的、费力的（Laborious）部分，编写一个工具去自动化模式的使用。这里的测试自动化，不是常见的自动化执行测试用例，而是提供计算机辅助（Computer
      Assisted）工具，让测试者可以充分地利用他的头脑（Mind）。


按照James的方法实施软件测试，测试者和测试团队可以积累一批有效的软件测试方法和测试辅助工具。这可以帮助他们更有效、更高效地测试现在和未来的项目。也就是说，有积累的测试能够帮助测试者成长。如果他将经验和工具分享给测试团队，整个团队可以得到提高。如果他秉持“不二过”的精神，将所获得的典型错误总结之后分享给开发团队（这里有一个技术案例），那么可以提高开发团队的水平，让他们在编程时就避免一些典型的错误。

可见，不断反思与积累的测试过程有助于培养好的测试者和开发者，有助于打造一支更好的开发与测试团队。而更好的团队将有更大的可能去创造更佳的产品。

最后，我希望有更多的人去仔细阅读和思考荣浩先生的《关于测试的八个问答》，那确实是一篇值得反复体会的佳作。在阅读过程中，不妨大胆地与作者展开“讨论”。这世界上并不存在“神”，在软件实践中也不存在刻在石板上的“箴言”。大师们尚在不停地反思、不停地否定过去的自己，我辈更应该努力求索。