周末下班前一个新员工的工作总结吸引了我的注意力，让我又想起前几天微博上看到的《2011我的项目经历二三事之测试 》，进而思考一问题：如何保障代码发布后不会导致故障？
故事：小王终于可以喘口气了，在过去的一周内小王加班加点把一个核心的功能点开发完毕，刚刚顺利在仿真环境测试通过，现在是下午5点30分，小王走到饮水机旁准备喝点水。“小王，明天上午8点正式上线”，朱总对小王说，“已经通知发布人员了”。小王合计了一下，6点半起床，7点上地铁，8点到公司，今天晚上还是早点睡觉吧。过年后，已经有两次上线故障了，虽然不是什么大的问题，但代码回滚会让开发人员备受打击，测试、发布人员也跟着受累，领导也都看在眼里。
问题：如何保障代码发布后不会导致故障？
答案：在仿真环境中发现可能导致线上故障的问题，这就是验收测试。通过代码发布前的验收测试，增强开发人员、测试人员和代码发布人员对即将上线的代码的信心。
回顾：我们现在是怎么做的？
对于仿真环境的测试，测试人员采用黑盒测试，会通过【curl】等工具对openapi的接口进行测试，并查看返回结果。重点测试修改的接口或新增的接口，对于没有变更的接口（由开发人员进行评估），通过代码打包时的回环测试【node.js】进行验证。同时，测试人员测试的过程中，开人员会盯着系统的日志，看有没有异常信息。
对于需要进行性能测试和评估的发布，也会专门安排对应的测试。
展望：更进一步
1、检查回环测试是否全面
检查回环测试的接口是否完全覆盖web.xml中开发的接口？从测试环境的tomcat获取web.xml文件，分析比较。
2、简化回环测试开发
对于openapi接口测试来说，比较简单：准备测试数据（测试账号），向服务器接口（url）发送请求（输入参数），等待服务器返回结果，判断输出结果与预期结果。通过openapi的业务分析，将业务闭环（增-删-改-查作为一个闭环）作为一个TestSuite，其由多个TestCase构成，每个TestCase的开发简化为：准备测试数据、配置接口地址url、输入参数、预期结果，其余的事情交给框架来做。
3、数据源验证
除了进行黑盒测试外，可以通过访问到对应的数据源查看期望的数据是否想入到期望的数据存储中（mc\redis\mysql）。
4、日志聚合分析
对应大型分布式系统来说，仅仅依靠测试或调试过程中开发人员“盯着”日志很容易遗漏系统的问题。将希望的日志按时间线排序，将多个系统中的日志按主题聚集，对于分析定位系统的问题很有帮助。Scribe已经被FB证实很有效。
补充：Node.js是一个很好的项目，用它来做openapi的验收测试很简单，但与传统的测试框架JMeter相比，采用Node还需要自己做一些事情，简化测试用例的开发和维护；如果需要对测试结果进行图形化展现的话，同样需要自己来做。
另外，Node是事件驱动的调用机制，需要仔细评估测试用例的执行顺序会不会影响测试结果，同时避免将所有的调用串行化。
故事的结局是这样的：上午9点半小王来到的公司，发布人员通知他上线顺利，小王开始接受更有挑战性的工作。
附：2011我的项目经历二三事之测试 http://jabcf.blog.163.com/blog/static/348312402012118761931/