人人都谈用例管理与持续集成
作者|张硕
天下武功，唯快不破 – 把握住效率等于把握住了市场竞争力
在当今的互联网大潮里，“快”决定了产品在市场中的竞争力，所以高节奏，高压力成为了项目最重要的特点，快速迭代也成了现在互联网领域中项目管理的主流趋势。而作为qa，如何在工作中适配这种高节奏，如何在快速迭代中保证项目质量，这又是一个一直以来都存在的问题。
从流程上分析，我们遵循着：
不难看出，保证每一个环节的质量就是保证了最终产品的质量，而提升每一个环节的效率也就是提升了项目整体的效率。
今天单独拿接口测试为例，Beetle平台已经极大的提升了部署和上线流程的效率，但在测试节点上，各个业务线都有自己的接口测试方案，并没有统一，这样就不利于做通用的自动化测试，也很难在部署和上线节点中间做持续集成，更无法从整体去把控各方的测试情况和测试数据。
百花争艳，兼爱非攻 – 拥抱变化，让各方自由发展
对于这种现状，从传统经验上，我们采取的方式是提出规范，让各方遵守，按照既定的约定去实践。但是这种方案明显不适合我们当前的场景，业务方特点鲜明难以统一，技术时刻更新，所以约定的规范经常面临要迭代更新的风险。
我的思路是，去兼容各方的特点，抓住共同的核心，进行统一管理。选择的方式是：
将各方的特点以配置的形式存储
接口测试按类型区分，每种类型有唯一的执行方式
执行过程闭环，不依赖其他环节
按照这个思路，下面介绍一下用例管理平台
一、命名规则配置
前面提到我们的思路是兼容各方的特点，以配置的形式存储。所以依据目前接入平台的各方业务特点，配置如下：
工程名称 – 接口测试工程的名称，与git或svn地址的工程名一致
配置名称 – 同一测试工程可能有多种规范（比如搜索推荐只有一个测试工程，但是工程的包会按搜索和推荐分为两种规则），用于区分同一工程的不同命名规范。
工程类型 – 当前只支持testNG，后续补充
包，类，方法名命名规则 – 用于生成可视化节点树，节点树后面会介绍
工程存储方式和地址 – 支持svn或git
config路径 – 当前支持scfconfig路径，后续补充host配置及其他
listener – 支持自定义listener，如果没有可为空
二、节点树
所谓节点树，即测试工程里测试方法的展示树，树是按照配置中的命名规则来自动生成，同时只会展示带有@Test注解的方法（针对testNG而言）
比如交易测试工程节点树的例子，当前树为3级节点：包，类，方法，支持全选，单选，多选，反选等操作。而节点选择到底用来做什么，请继续往下看。
三、测试套件
这是testNG类测试的执行核心，即测试套件，每一次测试执行都是按照测试套件来进行。
比如搜索测试工程新增套件，可以自己选择节点，取一个合适的名字，选择套件类型即可，节点可单选，多选，全选。所以我们被测服务或者被测场景与我们测试工程之间的关联完全取决于用户自己，用户可以依据实际的使用场景自由创造。而具体被测服务所在的机器ip也是可以在每次执行前自由配置。有了测试套件，我们就可以进行测试的真正执行了。
四、执行
测试执行的入口就在套件列表，这里也支持每次测试前手动更改被测服务ip。
前面也提到了我们的设计思路要做到测试闭环，所以整个接口测试过程中，我们涉及了在平台里进行拉取测试工程、部署测试工程、编译打包、修改配置文件、执行testNG测试、收集日志、产出报告、清理过程等，而最终产出的报告入口会在任务管理模块展示。
到这里一次测试执行就告一段落，那么细心的读者可能发现，这样做只是解决了各方测试没有统一管理的问题，但是其实并没有提高测试效率，因为在平台执行和自己在本地执行只是换了个地方而已。
所以下面介绍一下，用例管理平台接入beetle，向持续集成迈出的一大步。
我看的并不远，只是站在了巨人的肩膀上
在与Beetle方沟通后，我们采取了如下方案
Beetle增加集群CI配置中的用例配置，用来配置集群所需的测试套件
在每次分支部署时，会触发执行操作，也就是部署后自动执行所配置套件的测试用例
执行后，beetle上展示报告入口，可以跳转到报告页面
因为用例平台侧基本功能都有，所以只需要给beetle提供一份接口即可，这样执行既可在平台侧触发，也可以在beetle侧触发。
具体配置如下：
这里的用例套件就是在平台侧用户自己创建的套件，配置成功后，每次分支部署就会自动触发套件的测试用例，产出报告（当前建议先配置一些用例不多的冒烟类case用作回归使用），这样可以真实的反映出项目的冒烟测试情况和测试用例执行详情。
所以一开始提到的项目流程就变成了：
这样，也为后续的持续集成打开了大门，创造了有利条件。
用例管理平台初期的内容基本就介绍到这里了，后续还会有更多待优化更新的功能，比如用例文件（执行测试的参数文件）管理，链路测试执行，服务返回结果监控，其他监控管理等等。
在最后笔者也想说一句，平台只是工具，只是确保了项目流程可以顺利打通，确定了持续集成实现的可能，但是平台不能保证测试的质量和测试的正确性，这些都依赖于用户或者使用方自己。
完善用例，让用例真正具有健壮性可回归性，
完善自身，回归到测试本质才是重中之重~