发布之后

发布之后，系统才开始在真实的数据、环境上运行，才开始经受真实用户的考验。发布，不意味着项目的结束，却是挑战的到来。如何在发布之后，快速修复 影响到 系统使用的bug；如何在发布之后，快速改进在真实环境中无法承受的性能问题；如何在发布之后，快速调整用户体验较差的界面设计或者功能实现。开发团队或 者维护团队，如果不能快速响应这些突然袭来的变化，就会给客户带来损失。

 

同时，从发布之后出现的问题，可以反思开发过程中某些方面的不足。以下会列出我们在发布之后遇到的一系列问题，以及对这些问题的思考。

 

难以 重现的问题

当发现bug的时候，立即想到的就是在测试环境或者UAT上重现问题，以便快速定位问题的根源。

场景

系 统发布一个小时之后，客户一封邮件过来，告诉我们有一个重要功能在产品环境上不工作：一个公司无法为她的包月套餐付费。于是，我们立即在测试环境上试图重 现问题，但失败了；UAT上也如是。这是一个重要的功能，经过详尽的测试，却在产品环境上突然出现问题，令人匪夷所思。于是，只好到产品环境上测试，果然 重现了bug。首先排除了环境的区别，那么肯定就是数据的区别。在仔细观察数据的时候，敏感地注意到一个特征：被测公司的所有员工都没有接受网站的条款。 马上在测试环境中建立同样特征的测试数据，果然重现了bug，并找到了问题的根源。

反思

有些bug会很难重现，而之所以难，根本原因在于忽略了出现bug的测试场景（包括数据、环境等因素）。导致这个bug出现的根源在于测试不够全 面。如果在测试中尽量覆盖边际情况，就可以避免多数类似问题的出现。

 

产品 环境中仅有的问题

产品环境和测试环境的差异在哪里？

场景1

这不是一个功能性bug：有一个页面在产品环境中出现了不应该有的滚动条，却十分影响页面的美观。对照测试环境和产品环境之后，发现是因为在产品环 境中一个链接的url过长导致信息框出现了滚动条。

场景2

页面上有个回退链接，会回退到之前访问的页面。有些时候却回退到了网站的首页，在测试环境中无论如何也不能重现这个bug。在产品环境下，发现出现 问题的页面都是从https跳转过来。查看代码，果然没有考虑这种情况。

场景3

在用某些关键词搜索的时候，会出现500错误。而在测试环境中却无法重现。非常幸运的是客户发来了产品环境的log，经过分析，发现问题在于产品环 境中集成的第三方工具提供的有些数据会导致程序错误。

反思

这 些都是典型的由于测试环境和产品环境数据或者环境不一致引发的问题。如果能在测试环境中尽量保持数据的拟真性、环境的真实性，则可以尽量避免这些问题在发 布之后才被发现。但从另一方面看，出现这些问题的根本原因在于代码不够完善。场景一中前端代码的包容性不够好；场景二中引起问题的代码有一些比如hard code的bad smell，却没有被及时修复；而场景三的代码是有漏洞的，它没有很优雅地处理数据获取失败时的情况。

 

无法 获知起因的问题

有些用户遇到了问题，但我们无法或者没有时间去一一获取这些用户的信息。

场景

新系统上线之后，所有老用户都得重新接受新的网站条款。但有些用户无法点击接受条款的按钮，严重阻碍了这些用户的回访。

反思

这 个问题可能只出现在千分之一的用户里面，试图去获取所有这些用户的客户端环境（浏览器版本）很困难，而客户又要求我们立即解决问题。所以，试图去重现问题 已经不可能了。不如凭着经验审查一下原有的代码是否有瑕疵，前端代码是否浏览器敏感。然后给出一个更通用、更完美的方案。这类问题是无法避免的，除非花费 大量时间对所有客户端环境都进行测试。但这类问题是可以解决的，比如上面那个bug我们就通过采用兼容性更好的代码解决了。

 

真实 用户体验的问题

真实用户才是真正的测试人员。

场景1

一个页面有分页功能。用户来到了第n页，进行了一个操作之后，重定向到了第一页。而用户显然希望能继续回到第n页。

场景2

几个按钮应该排成一行，但当用户输入一个很长的名字之后，出现了换行。

反思

这类问题不算是bug，但却影响了用户的体验。测试人员虽然会站在用户的角度去测试功能，但最好的测试人员其实就是真实用户。如果有条件能在发布之 前，让一些真实用户参与测试，是发现这类问题的最好方法。

 

遗留 的疑难问题

既然是遗留的问题，肯定是难以解决的问题。

场景

系统中有几个暂时不影响发布系统使用的bug，它们被一直拖到了发布之后，因为之前“难以解决”。

反思

虽 然这些bug最终都被修复，但这是一种不正确的方式。疑难问题不应该留到发布之后：在发布之后能解决的问题，那么在发布之前也一样可以解决；如果在发布之 前确实无法解决，那么就应该选择其它方案。如果在发布之后花了很长时间也解决不了这些bug，就进退两难了。同时，维护团队一定要保证部分核心开发成员的 继续留任。如果在交付产品之后，开发团队立即全部撤离，而把系统的维护交给一群对业务和实现完全不熟悉的人，是一种很不负责任的态度。

 

不会 有问题的问题

这个功能不是已经经过验收了么？

场景

第一眼看到客户报的有些bug时，脑中飘过的第一个想法是：这个功能肯定经过详尽的测试，而且肯定经过了客户的验收，怎么可能有问题呢？但在测试环 境中确实重现了bug。

反思

之 所以在看到这些bug的时候比较难以置信，是因为我们以为这些功能已经被测试过，或者我们知道这些功能曾经被测试过。但事实是，有些功能可能根本就没有被 测过；而有些功能曾经被测过，但没有被自动化测试覆盖。同时，我发现后一类问题往往都是在last mile中被引入：在发布之前，为了解决性能问题，我们需要对设计或者实现进行一些大规模的改动；而到后期，测试人员因为功能性需求的结束而退出了团队。 当时非常担心大规模的改动会引起一些问题，在发布之后验证了这种担心。这类问题其实是可以尽量避免的：首先，更早开始性能测试和性能优化，以避免在 last mile进行大量改动；其次，last mile可能会出现赶工的情况，有大量功能的改动或者设计的变更，这时候是测试人员最不应该离开团队的时候。

不是问题的问题

客户坚持说，这里有问题。

场景1

客户说：在使用firefox浏览器的回退按钮时，能看到不实时的信息。

场景2

客户说：有一个bug... 过了一会儿，客户又说：bug好像没了。不过，总之问题出现过，你得去修复。

反思

这 些不是问题的问题，浪费了维护团队的大量时间。发布之后，维护团队需要及时地修复很多bug，应该尽量地排除不必要的干扰。在一个维护团队中，也需要维护 一个流程。我们的维护团队，由两个开发人员和一个测试人员构成。测试人员负责接纳并验证所有的bug，开发人员负责修复bug，再经测试人员测试，最后经 由客户验收。通过坚持这个流程，让团队的每个成员，都关心自己最应该关心的问题，而不应该被其它事情干扰。在发布之后，需要更加快速的反馈，而严格地执行 流程，能明显地提高团队的效率。

 

总结

系统在发布之后经历了一段时间的考验，bug不多，并且基本没有出现影响系统使用的bug；同时，维护团队保持了高效的反馈，及时地修复了大部分 bug。高质量的代码和快速地反馈得到了客户的认可。

现在回头看这些在发布之后出现的问题，我相信，没有一个系统能确保全部避免。不过从我的反思中可以看到，这类问题大多是开发过程中的“不完美”而遗 留下来的隐患，如果能做得更好，我们就可以尽早发现这些问题，以避免这些问题在发布之后才出现。

 

详情请见http://huzhenbo.name/blog/2009/09/06/after-release/

 

评论

1 楼 neusoft 2009-09-07  

深有同感 特别是做国内解决方案的更是如此