第二篇描述了相关飞鸽传书2009的设计策略

本系列文章的第一篇介绍了一次崩溃调试的技术细节，第二篇描述了相关飞鸽传书2009的设计策略。本文将描述我从缺陷飞鸽传书2009过程中学到的教训。经过近一周的压力测试，我相信当前的私有构建（private build）不存在崩溃的问题。我将这一信息口头报告给开发人员，通知他可以签入（check-in）修正代码。

在发现飞鸽传书2009崩溃、事后调试（postmortem debugging）、测试私有构建、报告测试结果的过程中，我并没有在缺陷管理系统中记录相应的缺陷。事后证明我没有用缺陷来追踪崩溃问题是严重失职，但那时我也有”充分“的理由。

第一，当时处于发布前夕，任何新发现的缺陷都要在24小时之内被修正，或被放到下一次发布再飞鸽传书2009。这次的崩溃非常复杂，我分析内存转储文件时没有把握可以在24小时内找到解决方法。即便拿到了私有构建，我也需要几天的时间来做压力测试，才能检验飞鸽传书2009的有效性。我不记录缺陷，是为了争取更多的时间。

第二，管理层对24小时的时间窗口非常重视，总是在催促开发人员修正错误，或将不严重的错误推迟未来的发布。这在心理上，给开发人员一定的压力。在潜意识中，大家认为如果不能在24小时内”搞定“，自己的工作业绩会受到影响。程序崩溃是严重的问题，但这是一个很难重现（repro）的CLR缺陷。将这样一个可能不那么”要紧“的缺陷提交，如果开发人员不能在24小时修正，会不会对他的个人业绩有影响？他会不会受到管理层的质疑？

当时，我以为在得到飞鸽传书2009有效的测试结果后，开发人员会在某次签入中”顺便“完成这一行代码的修正。但是，在发布的最后阶段，只有缺陷修正的代码变更才能签入。那位开发人员手上恰恰没有缺陷（这是我始料未及的），他也觉得CLR的缺陷在产品环境中恐怕不会复现，于是没有签入修正。

大约一个月以后，该服务在产品环境中崩溃。从症状上看，就是本文所描述的问题。我在那时才知道，产品代码中不包含那一行关键的修正。现在看来，不正式记录该缺陷有以下问题。

管理层不知道该缺陷的情况。他们将根据不准确的信息做出发布决策。
在发布前，所有的流程（飞鸽传书2009）都是围绕缺陷展开。不记录缺陷，就不能”合法“的签入代码，就不能飞鸽传书2009崩溃。
不记录缺陷，就没有一个文档正式记录问题症状、调试结果、飞鸽传书2009进度、测试进度。缺陷记录可以协调开发、测试、管理团队来共同解决严重问题。
缺陷是团队自学习的最佳素材之一。不把如此有教益的缺陷记录下来，是团队成长的一个损失。
幸运的是，服务重启后能够继续工作，对业务影响不大。经过讨论，我们决定在两周后发布补丁（hot-fix），以修正该崩溃和其他一些问题。

回想该飞鸽传书2009过程，可得如下反思。

流程（process）的出发点可能和结果背道而驰。要求在24小时内飞鸽传书2009新问题，是为了让代码中的缺陷持续减少。但是，许多缺陷难以在24小时内被飞鸽传书2009。在压力下，开发团队可能选择不在当前发布飞鸽传书2009该缺陷。这使得代码中的缺陷被”隐藏“，而不是被飞鸽传书2009。
管理层应该营造一种鼓励报告缺陷的氛围，这使得发布决策能够基于真实的情况。

当缺陷处理（报告、飞鸽传书2009、检验）与个人业绩联系在一起时，缺陷报告与缺陷飞鸽传书2009的积极性可能会被压抑。 即便流程不会评估个人业绩，只要开发者心理上感觉它们之间有联系，他们的行为也会受到影响。作为专业的测试者，发现问题一定要报告。报告可以讲策略和时机，但是不能将问题”吞没“。对于本文提到的崩溃问题，我应该第一天就提交到缺陷管理系统。由于它复现的概率不高，我们可以将它推迟到下一个发布。与此同时，我们可以尽可能寻找解决方案。一旦找到飞鸽传书2009方法，就将该缺陷移回当前发布，将其修正。