基于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测试用例为例）

#【必填】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文件有什么不一样的呢？

3. 自动生成Markdown文件

我们对YAML文件进行解析和数据填充，就生成了最终的Markdown文件。为什么要再生成一份Markdown文件呢？

首先YAML文件里只是测试用例的基本描述信息，并不足以作为真实的测试用例描述。其次，相比于YAML文件，Markdown文件更方便阅读。

比如对于上面的YAML描述文件，我们会自动生成如下Markdown文件。

可以看到：

• YAML文件中的测试点描述会以表格的形式展示，非常直观。
• YAML文件中额外引入了日夜间适配 和 网络适配 测试用例，所以这两个测试用例会自动添加到该测试用例中。
• 可以看到测试用例对应的版本记录、需求链接、关联模块等信息，并支持跳转。

大家只需要在YAML文件中填好对应的描述字段，提交后就能自动生成这样的测试用例文件，全自动进行，非常优雅。

4. 自动生成文档网站，支持内网访问

现在我们可以自动生成测试用例文件了，但还不够好用。

• Markdown毕竟还得找个编辑器才能看。
• 直接把Markdown文件粘到需求单里当测试用例？有点low。
• 在git网页或者文件夹中浏览测试用例？不方便。

为了进一步提升体验，我们使用gitbook将Markdown文件以文档网页的形式进行发布，这样就可以在网页中浏览测试用例。

同时，基于腾讯内网静态网站服务，我们进行进一步的配置，支持在内网直接访问 来查看所有的测试用例。

在这个网页中，我们可以轻松的查看、搜索所有的测试用例！

• 查看每个测试用例的详细描述
• 查看全部的测试用例列表及基础测试用例列表
• 查看每个模块、子模块的测试用例及关联测试用例
• 查看并追踪测试用例的变化情况
• 进行各种页面跳转

同时，丰富的数据统计维度可以更好地推动大家写单元测试和自动化测试，提升整体代码质量。

所有的能力，都是通过解析YAML文件，并进行一系列的自动化操作获得。 开发同学只需要写YAML文件，提交后会自动触发蓝盾流水线的执行。在蓝盾流水线中，我们会进行格式校验、数据组装、文档发布等一些列操作。流水线执行完毕后，就可以直接通过网页查看测试用例。

5. 本地预览

我们写了一套命令行工具（qntc），提供本地预览能力，大家写好YAML文件之后，可以先在本地进行页面预览，预览没问题之后再进行提交。 除了本地预览测试用例页面之外，我们还提供了在本地查看测试用例、进行数据校验等能力。

整体流程

总结

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

测试用例描述作为核心数据，直接存储git仓库中，也非常方便后续的扩展，比如生成更丰富的统计视图，将数据导入其他平台等。

end

扫描二维码获

取更多精彩干货

注：图片均来源于网络，无法联系到版权持有者。如有侵权，请联系后台做删除处理。