基于git的测试用例管理方案

点击上方蓝字关注我们！

| 导语使用YAML文件描述测试用例，自动化生成测试用例，并提供网页访问的能力；同时对测试用例数据进行多维度的统计，提供丰富的测试用例管理和查看视图，更好的保障客户端迭代质量。

背景

“开发负责质量”是研发效能提升的重要一环，有利于推动更合理的架构设计，形成研发上的闭环，让做自动化、做单元测试的成本足够低。

在研发效能提升的大背景下，开发也要开始着手编写测试用例。我们先来看下测试用例是什么：

测试用例是从测试角度对需求各个功能点的详细文字描述，包括执行步骤、预期结果等，用于指导需求的测试工作，以及单元测试和自动化测试的编写。

问题

一直以来，我们都是在TAPD上编写需求的测试用例，TAPD上可以比较方便的进行需求和测试用例的关联。但随着我们对测试用例的要求越来越高，在TAPD编写测试用例的缺点也逐渐暴露了出来：

不同的TAPD项目无法关联同一份测试用例 iOS和android客户端是两个独立的TAPD项目，虽然两端的测试用例基本是一致的，但还是要写两份。为了解决这个问题，大家不知不觉中就使出了杀手锏：copy一份。但是copy之后，后续的修改又无法同步，写起来费时费力。
TAPD基于目录来管理测试用例，测试用例不是“一等公民” 测试用例会关联很多信息，比如版本、模块、需求等等，但是在TAPD里，我们必须给测试用例安排一个目录。如果按版本建立目录，会导致历史测试用例难以维护，每次做新需求时，都是新写一份测试用例，即使之前版本可能有类似的测试用例。如果按模块建立目录，模块的粒度划分又是个很麻烦的事，尤其是遇到跨模块的测试用例的时候。而且在TAPD中按模块管理，很容易在维护和更新的过程中丢失版本等重要信息。
无法直接引用其他测试用例有一些测试用例属于基础测试用例，比如日夜间适配。只要做UI需求，就需要关注日夜间适配。大家没法直接引用这些基础测试用例，所以每个UI需求的测试用例中都要单独写一部分日夜间适配的测试用例，不仅做了重复工作，而且很容易遗漏一些重要的测试点。

TAPD测试用例举例：

这些问题暴露出来之后，我们就开始规划使用新的测试用例管理方案。因为测试用例的完备性会直接影响到迭代质量，如果测试用例写得不好，迭代质量就很难保证了。从实际经验看，我们每个版本总有因为测试用例缺失导致的bug。

目标

那么如何能够既保证测试用例的质量，同时能让大家写起来更轻松呢？我们定了如下几个目标：

两端共用一份测试用例。
测试用例支持互相Review，提前发现问题，保证测试用例的完备性。
方便查看、搜索历史测试用例，并不断进行维护和更新。
可以关联单元测试和自动化测试，为自动化验证打好基础。
好用，不额外增加大家的负担。

目标列完后，其实基本方案也就浮出水面了。既然测试用例交给开发管了，那我们就用开发的方式去管管。

方案

1. 使用git管理测试用例

为什么使用git？

两端在同一个git项目里写测试用例，自然就可以使用同一份测试用例。
按照代码的方式管理测试用例，提交到主干需要发起Merge Request，保证经过Review后才能使用

用git管理测试用例的好处很多，但是怎么去写测试用例呢？写个excel文件放上去？那还不如直接用TAPD。我们想做的是用git 管理测试用例，而不是简单的把测试用例托管到git上。

2. 使用YAML文件描述测试用例

为了尽可能地降低写测试用例的成本，我们希望大家在写测试用例时只需要填好必需的字段，其他的数据我们进行自动化的解析和完善，最终形成一个完整的测试用例。

YAML文件写起来方便，而且更好解析，非常适合用来编写测试用例。

我们定义了一系列测试用例的描述字段，用来表示一个测试用例。一个YAML文件，就对应了一条测试用例描述。 YAML文件中主要包含了以下字段：（以上面截图中的TAPD测试用例为例）

代码语言：javascript复制

#【必填】Desc: 测试用例详细描述Desc: 直播轻互动和互动热度#【可选】PreCondition 前置条件PreCondition: 使用6.0.80及以上版本#【必填】TestPlan：编写测试用例TestPlan:  #【必填】CheckPoint 表示“测试点”  - CheckPoint:      #【必填】desc：测试点描述      desc: 互动资源下发错误      cases:        #【必填】cases：放置具体测试用例        - case:            action: 没有下发动效资源btn_like_resource，或者下发的不合法            assert: 不展示飘心动画，不展示热度，也不去轮询拉取热度接口            iOSAutoTest: testInvalidResource            androidAutoTest: testInvalidResource  - CheckPoint:      desc: 互动资源下发正确      cases:        - case:            action: 展示动画            assert: UI符合预期        - case:            action: 拉取热度值            assert: 拉回来N条，按照每秒N/5去递增的展示        - case:            action: 查看热度值展示            assert: 位置：在心的上方，数字规则：按照通用的来，大于9999显示万        - case:            action: 点击心            assert: 本地假写，热度值 1，同时调用点赞计数增加的接口#【必填】版本变更记录，版本号 负责人，中间按空格分开，版本号必须是3段格式，包含4个数字，如6.0.90ChangeLog:  - 6.0.80 (authorname）#【可选】Story: 需求链接（多个需求使用数组格式）Story: http://tapd.oa.com/10045201/prong/stories/view/1010045201857627509#【可选】RelatedModule：额外关联模块，如果此用例同时影响其他模块，则在此处填写RelatedModule:  - Video/直播底层/普通直播#【可选】IncludeTestCase：引入测试用例，填写后会自动将关联的测试用例包含进来IncludeTestCase:  - 日夜间适配  - 网络适配

其中，测试用例描述、前置条件、测试点描述、执行步骤、预期、需求链接、等级等都是我们在TAPD中写测试用例必填的字段，这里通过YAML文件来写更加方便，不会增加大家编写测试用例的工作量。

除此之外，我们额外添加了几个重要字段，用来管理测试用例。

版本变更记录用于追踪版本变化和负责人变化，我们会自动生成版本维度的测试用例看板。
引入测试用例用于添加基础的测试用例，比如日夜间适配、网络适配等。这里只需要写个名字，我们会自动解析并将“日夜间切换”和“版本控制”对应的测试用例放到该测试用例中。省去了很多重复工作，而且保证大家使用同一份基础用例。
额外关联模块用于处理一个测试用例关联了其他模块的情况，我们会自动将该测试用例补充到模块维度的测试用例看板中。
每条测试用例的单元测试和自动化测试用于关联测试用例对应的单元测试和自动化测试，我们后续基于此字段做自动化验证，并进行多维度的统计。

整体看来，相比于在TAPD中填写，虽然增加了几个字段，但是填写起来都非常简单，并不会增加大家的工作量，反而规避了很多的重复工作。

YAML文件只是测试用例的描述，那最终的测试用例到底长什么样子呢？和写的YAML文件有什么不一样的呢？