工商银行数据中心接口冒烟测试方法(2)

传统的接口测试方法主要采用手工编辑接口报文的方法，这种方法只要按照接口文档的描述构造测试报文就OK了，虽然简单，但是有失高效。于是这个方法有了升级版本，就是通过参数化报文中的关键字段，批量生成测试案例，这也是接口性能测试的主要方法之一。这个方法虽然解决了获取报文的效率问题，但是并不能很好解决覆盖率的问题，毕竟报文是人工构造出来的，并不能非常真实的体现实际的业务交易场景，实际测试结果也印证了这一观点。于是，我们想既然传统的接口测试是在正常的业务交易测试中覆盖了，那么我们干脆去直接捕获前段发起交易产生的接口消息报文。非常幸运，公司绝大部分的开发部门都是严格按照LOG4J格式记录应用交易日志的，因此我们只要按照一定的规则去分析应用的交易日志，就能够提取出我们所需要的内容。

2、消息是否能够覆盖所有的程序分支问题：

根据消息内容的不同，应用程序会选择不同的程序逻辑分支，如何能够覆盖所有的分支，传统方法只有通过白盒测试实现，但是验收测试更偏重于黑盒或灰盒测试，因此过去经常因为测试案例不全面，导致某一个未覆盖分支的程序问题流入生产环境。我们目前想到的方法，是通过在系统中导入存量的接口测试案例，并通过日志中捕获的测试案例，经过一段时间的积累，逐渐形成一个较为完整的接口测试案例库。如果能够旁路一台生产环境应用服务器日志，效果会更好，毕竟生产的交易种类和场景是最全面的，当然这里还要解决生产数据脱敏等问题，对于金融行业还要面对很多制度流程的问题。

3、如何判断消息返回结果的正确性问题：

每一个应用对于接口报文的设计都是遵照一定的规范和习惯，我们只需要梳理出标记交易成功状态的字段就可以了。某些交易不包含这个字段，我们就需要进行人工判断，并对成功的结果进行格式化（比如timestamp，流水号等），提取MD5特征值，作为判断接口后续测试结果正确性的依据。不过，状态字段是成功并不代表接口测试通过，毕竟返回结果中还包含了很多业务数据字段需要验证。如果这些字段值变化比较规律（比如一直不变、持续增加或减少），我们准备定义一些模型规则去判断它们。而那些上蹿下跳的数据，那就留给人去判断了。其实，对于冒烟测试而言，我们认为并不需要苛求去判断每一笔交易的正确性，只需要统计大量测试案例结果的成功率，并与前期成功率进行比较，以判断测试结果是否正常。

4、执行效率的问题

我们理解的冒烟测试是要在尽可能短的时间内，对新的版本或测试环境进行一个准入测试，以判断其是否具有开展后续是验收及适应性测试的条件，因此冒烟测试的效率至关重要。我们的策略是通过异步小批量作业的方式不间断的扫描日志处理报文，每日定时并发的方式去执行测试案例，执行时间取决于版本安装时间或测试任务的需要，目前2万笔测试案例，基本可以控制在10分钟之内。

原文转自：http://blog.tingyun.com/web/article/detail/1340