质量体系建设之路---从接口测试开始基建

引言

中心内有大量的项目经过多年的迭代建设，无论是从体量、功能、复杂度都达到了一个无法完全依赖人工验证交付的点。
我们和很多质量团队一样，随着公司业务迅速的增长，前期质量环节主要依赖人工把控，在质量自动化工程建设上没太多积累，面对如今的业务交付无论是从效率、质量上都逐渐暴露出明显的短板。
开发及运维团队已在CI/CD上进行了提效建设，木桶效应逐渐明显，质量团队也希望尽快突破自己的交付瓶颈，并能逐渐建立自己的技术专业线，于是我们分析了目前比较集中的痛点，识别出2个关键词：回归提效、质量门禁。

回归提效怎么做

由于系统的体量较大，面对每次交付的需求，我们一方面希望精准分析出本次需求的影响范围，另一方面受限于交付周期及存在的变更风险压缩测试工期。
要本质上解决这两点，势必全量回归是保障质量最有效手段，集中验证本次交付需求是确保顺利交付的唯一途径。
一个维护多年的产品，很难有人能够针对每次改动分析全面涉及到的功能及业务场景，测试人员很希望能够释放资源将工作重点移至新功能验证。
那么接下来思路逐渐清晰了，为回归测试提效，减少人工参与。我们深入分析了目前团队现状及行业常规的自动化回归做法：UI层、API层。
接口测试路线成为我们首选，基于这个思路，我进一步走向平台化。

平台化势在必行

要完成接口自动化建设，我们是使用现成的工具：Jmeter、Robot Framework，还是基于开源框架搭建工程，还是平台化。基于三个方面考虑：
1、已完成相关技术人才储备
2、开发&运维团队已先行建设DevOps
3、质量工程化，工程效率化，构建TestOps
我们决定搭建属于福禄自己的质量平台，以接口自动化为“基建”.
平台化后，我们可以充分利用现有的开发平台，进一步完成从上至下的流程对接。

全员平台建设

一旦平台化后，有效的降低接口自动化用例编写的技术门槛，深入了与现有的发布流程“兼容”，测试过程数据的持续沉淀为今后质量度量化提供基础。
团队内部我们进行了人员分工，长期参与项目交付的同学承担起“产品经理”，有技术长处的同学承担起“全栈工程师”，善于沟通协调的同学承担起“项目经理，迅速的确定了功能流程。
考虑今后更便捷的与中心内部其他系统“打通”，我们基于福禄现有的前端框架进行打磨，后端选择开发效率更高的python。
前端技术栈：antd(react) + apache echarts
后端技术栈：python + flask + blueprint
数据持久化：MySQL

平台功能介绍

截止到目前，平台基本已完成：
项目环境信息->API搜集->用例编写->测试集创建->用例执行->测试报告

确保项目信息上下一致性

确保我们测试项目、应用、环境、api swagger信息从上至下是一致的，统一了数据源。
很多公司在接口测试都面临一个问题，到底我们接口覆盖做到什么程度，有没覆盖全，我怎么知道？
为了解决这一痛点，平台基于所有项目的api swagger进行解析，将api完整信息落库至平台，基于落库的api进行用例编写，避免了测试人员需要人工收集、手动填写、无法预知API量级......
将来想知道API覆盖率轻而易举，API的用例编写到底写到什么程度，每个API如何设计的用例，平台化的收益逐渐兑现。

既要高效写用例，也要满足复杂的实现

初期我们希望借助平台化极大降低编写接口用例的技术门槛提高效率，将常用的编写方式搬入了平台。但是随着深入的应用，很多复杂的场景涉及到：多接口上下文依赖、接口数据逻辑处理、数据库操作.....这类场景如果全部平台实现，显然对平台的设计提出了更高的要求及灵活度的实现，还会使得平台功能略显臃肿。于是我们设计出两套用例编写模式：用户模式、专家模式。

用户模式

大部分接口独立存在，这些接口用例量大、编写难度低、覆盖场景清晰，那么我们就在平台上一次性写好写全，边写还能边调试，这才是正确的写用例姿势。
调试过程中遇到接口异常，提供了自动生成