接口场景化建设
一、为什么开发场景化
Apollo框架介绍：适用于酷家乐业务体系，多功能接口测试框架。
随着公司业务的快速扩大，对业务质量的要求也越来越高，原先的框架无法支撑起复杂的业务自动化，需要重新进行升级改造。
二、期望改变什么
想要提高人效和接口收益率，为此我从以下两方面进行了设想：
1. 简单，人人能用。
2. 专注接口质量。
2.1 针对 “简单，人人能用”
Apollo介绍：
我们做了以下几点：
减少用例录入成本：用户之前使用的Apollo Repo可完全兼容，平顺迁移，之前的接口case继续使用。
减少用例编写成本：简化了编写成本，提供了用例模板demo，可一键复制，进行特定修改即可。
减少用例维护成本：支持“傻白甜式”编写接口用例，不需要写代码，并保存Apollo框架风格，只需要一些简单的输入即可完成维护。
2.2 针对“专注接口质量”
我们做了以下几点：
支持场景化：后期接口不再以单独出现，提倡场景化，即多个接口组合完成一个测试用例场景。
更多的校验手段：提供各种断言和diff功能，还提供了多接口组合校验。
专项支持：针对部分特殊的底层服务如mesh，dcsmesh做专项校验支持（mesh效果自动化回归探索）
三、平台的组成
平台主要是由三部分组成：环境管理、 类目管理、测试用例管理。
下面简单介绍下各模块。
3.1 环境管理
相信看到这，大家应该比较熟悉，类似于Apollo的apollo-config.properties 文件，在这里进行统一的管理。
3.2 类目管理
用于创建类目，放置测试用例，目前支持到二级类目，方便大家按照各自需求进行管理。
3.3 测试用例管理
平台重点，用例的编写，导入，运行 都在该页面。
当你了解完这三个页面后，就可以在平台上进行编写了。可能会有同学好奇，为什么没有支持自定义脚本？
这里涉及到一个效率问题，平台的初衷是将效率提升至极限，减少代码编写。最终能做到边测试，边补充场景用例。
并且也不方便规范化，统一管理，评估用例质量。
四、设计和实现
4.1 链路设计
目前与公司各平台打通，形成闭环
4.2代码开发
设置 “前置用例”以及“场景化” 处理，接口上下游打通
设置 “response处理引擎” 针对不同类型的返回结果做特殊处理
4.3功能支持
请求参数支持
部分参数展示，详情查看：介绍篇-接口用例参数
常规函数支持
根据公司业务特性以及用户的反馈，提供了6种函数支持用户
4.4 成果展示
自动化发现问题数
H2 自动化bug发现率 逐步提高
五、效能进阶-流量回放支持
5.1 产品设计
5.2 产品实现
根据应用名，进行接口筛查，提示哪些接口未覆盖，进行精准覆盖
录制的流量生成 接口case
六、规划和展望
目前平台已经接入定制和硬装的大部分接口，以及部分智能设计项目。最难的业务线已经支持完毕，剩下的业务线推广，只是时间问题。
平台的理念一直都是 “提高编写case效率，提高自动化发现率”。在我看来，这是一件既简单又困难的事情。
主要从以下两个方向分析，
提高编写case效率：
深入并充分调研各业务线同学的难点和需求，精准开发需求。目前这一点，平台已经做到，每个同学的repo都会分析，查看一遍，做到充分支持。
虽然进度会有所延缓，但能提高每个同学接入时的流畅性，我认为是必要的，也向用户传达开发者的认真和负责。
提高自动化发现率：
这件事其实是最难的，因为涉及到大家对接口case编写的理解，如何写才是高稳定，高效发现bug的case。以及如何保证做增量测试，少做存量测试。
我们可以提供高效的工具，但是如何发挥它，还是要靠人。所以后期还需要进行方法论的封装，对大家进行提倡，并确保有力落地， 这件事才有可能显著改善。
推荐阅读
公众号：酷家乐技术质量 知乎：酷家乐技术质量
TesterHome：kujiale-qa (酷家乐质量效能)