首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >基于git的测试用例管理方案

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

作者头像
腾讯移动品质中心TMQ
发布2020-08-10 10:10:05
4K1
发布2020-08-10 10:10:05
举报

点击上方蓝字关注我们!

| 导语 使用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

扫描二维码获

取更多精彩干货

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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-08-07,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯效能 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 背景
  •  问题
  •  目标
  • 方案
  • 1. 使用git管理测试用例
  • 为什么使用git?
  • 2. 使用YAML文件描述测试用例
  • 3. 自动生成Markdown文件
  • 整体流程
  • 总结
相关产品与服务
TAPD 敏捷项目管理
TAPD(Tencent Agile Product Development)是源自于腾讯的敏捷研发协作平台,提供贯穿敏捷研发生命周期的一站式服务。覆盖从产品概念形成、产品规划、需求分析、项目规划和跟踪、质量测试到构建发布、用户反馈跟踪的产品研发全生命周期,提供了灵活的可定制化应用和强大的集成能力,帮助研发团队有效地管理需求、资源、进度和质量,规范和改进产品研发过程,提高研发效率和产品质量。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档