用例状态分为成功、失败、处理中、超时四种状态,分别通过配置相应SQL查询条件去映射,成功和失败是终态,处理中则是需要定时任务继续查询,超时,是我们内部设定的一个状态,目前是超过一个小时未返回终态设为超时,此API用例失效并报警,需要人工参与查看。所有这些规则都是在用例建立和编辑的时候添加的,如下图,一条用例包括了响应校验(值校验、key校验)和数据库校验,通过这种比较灵活的设计,基本能够满足复杂API测试场景。需要指出一点是,很多应用不允许外部测试平台直接访问数据库,我们的解决办法是写一个数据查询服务部署在系统环境中,只提供查询功能,并且有加密验证保证通讯双方(测试平台和数据查询服务之间)可信。
通常来说,测试平台或框架可以从某种层面上理解为工具链的串联,开发此平台的过程中,我们使用的技术栈有springmvc+herbinate做逻辑控制、amazingUI做用例管理、echart做结果展示,还使用Jenkins做任务调度等,用户就是各业务线测试人员,他们不需要了解具体代码的实现,但是需要对系统结构以及用例规则有很好的理解,这样才能设计出符合测试场景的用例。
任何测试平台的设计还是要基于业务的,后续我们对API平台的推进策略是,继续增加场景化功能以支持更多业务类型的测试,比如清结算系统中日终、日间的跑批任务,对账文件的数据检验等,增加大并发能力并和性能测试工具相结合。
原文转自:https://juejin.im/post/5c2c2f576fb9a049d05dd6e6