本系列文章的第一篇介绍了一次崩溃调试的技术细节,第二篇描述了相关飞鸽传书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方法,就将该缺陷移回当前发布,将其修正。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/37314.html