作者|赵力新、刘筱雨
问题的产生
随着公司业务的发展，组织架构的调整，业务归属不断的变更，业务测试用例的维护越来越困难。举个例子，A产品本来归属于A业务线，由于组织架构调整，A产品交给B业务线维护。如果本次迭代中A产品有一些需求改动，那么负责测试的QA同学C需要怎么设计回归测试用例呢？
现状
测试同学C可能会去找之前负责测试的QA同学D要一份测试用例，发现D同学这里随着业务迭代，有好多版本的用例，比如1.0版本的完整用例，优化版本1.1/1.2/1.3....的用例，还有一些小迭代，甚至没有落地到测试用例。想找一份现在运行版本的完整用例还真是不容易。
总结一下问题：
用例是否有统一的地方存放？
用例如何随业务迭代保持常用常新？
拓展一下，用例设计时，是否能方便复用基础组件用例？
解决问题
转转测试部工程效率组研发了功能用例平台，用来解决用例统一存放、用例随版本迭代更新、用例复用的问题。
1、用例类型
功能用例平台的用例主要包括三种：业务用例、业务模块用例、基础组件用例。大概介绍一下含义：
业务用例：业务迭代中某一个需求的用例；
业务模块：某一个业务线抽取出来的比较独立的模块，比如优品->自营->详情页模块；
基础组件：某业务或者公司通用的组件，比如转转下单地址修改组件、优品手机首页底部筛选组件。
其中业务用例会复用业务模块用例和基础组件用例。（有一个约束条件，复用的业务模块，放在当前用例的二级节点上。）当业务需求上线之后，我们会对二级节点业务模块发起合并，由业务模块负责人审批通过之后，更新业务模块的用例，以此来保证业务模块的实效性，使业务基础模块用例随着业务迭代保持常用常新。基础组件更新之后，会通知引用此基础组件的业务用例负责人，让他们查看是否需要同步最新基础组件的用例。具体关系如下图所示：
2、用例展现方式
为了符合大多数人的思维习惯，功能用例平台的测试用例是以脑图形式展示的。脑图的节点提供了常用的功能，包括标记用例类型（冒烟用例、核心用例、漏测用例）、标记用例执行状态（通过、失败）、分配用例执行人、快捷提bug（第二版再上线）。
3、技术方案设计
由于用例是以json格式编辑及保存的，后端采用了mongoDB存储数据。经过调研对比，我们对json树采用“物化路径“的方式存储，加上mongoDB索引使用非常方便，用例的查询、存储都非常高效。用例历史版本的维护，我们只需要记录用例根节点id，即可查询到完整版本的用例，这样回滚到任何一个版本都非常方便。
前端结合antd框架，gg-editor mind等插件，提供基础脑图的展示，编辑等功能，并且根据字段不同显示对应的标签，达到直观展示信息的目的。
后续规划
目前功能用例平台1.0版本提供了用例复制、编写、同步和审批合并的功能，接下来我们会完善平台的功能，主要有以下几个方面：
针对用例快捷提bug，自动生成bug复现步骤，无需打开tapd（转转项目管理平台）；
测试计划，会让开发同学根据自己的名字和需求搜索到待自己执行的用例；
用例统计，目前冒烟用例、总用例数据随着用例更新已经是自动统计了，接下来会把前端页面加上。
end