专栏首页软件测试那些事测试用例管理平台的一二三

测试用例管理平台的一二三

为什么要有测试管理平台?

对测试从业人员:提高效率,标准化交付过程

对于团队主管和高阶管理者,掌握进度,把控风险。沉淀组织资产,维持稳定性。

对其他职能:了解进度,透明交付过程

关于外包,有了平台,更加易于管理外包的交付工作。

一般的测试平台能干什么?测试平台有哪些类型?笔者简单梳理了一下,供大家参考。尤其是在DevOps平台建设时,关于测试管理是集成既有平台,还是自建其管理能力,又如何管理自动化测试用例?对待这些问题的看法和解决方式的不同,就会造就不同形态的测试管理平台。这是笔者之前关于测试用例管理讨论的续篇。测试人,你还在写用例吗?是什么在支撑着你写?

I型用例管理平台

测试管理,包括了测试用例管理、测试任务管理、测试结果管理,统计报表等最为基础的功能,以支持测试团队的工作开展。这是以TestLink为代表的测试用例管理平台的范围。

从这个界面上可以看出,TestLink以Project(产品/项目)作为最大的业务上下文,在此之下,涵盖了需求管理和测试用例管理以测试执行的管理。在实际的项目中,类似很多人把Junit当做单元测试框架一样,很多人也只是把TestLink当做一个用例管理工具,极少有用其来做需求管理的。包括TestLnk也没有缺陷管理的功能,因此,还需要通过API等方式与第三方的需求管理和缺陷管理平台进行集成,进而实现测试侧的研发过程管控。

II型用例管理平台

在这个基础之上,DevOps倡导推倒烟囱式的组织结构和交接式的交付过程。因此,在DevOps平台的建设中,也希望打破各个功能团队各管一段,各自建设自身的交付平台的情况。因此,也希望测试平台不是一个竖井,而是能成为整个研发过程管理平台的有机组成部分。这一部分,则是JIRA等一众商业软件的地盘了。

JIRA凭借着其完善的功能体验和强大的生态圈,已经成为盘踞产品开发管理类软件的主要玩家。寄生在JIRA上的XRAY、synapseRT等插件,则可以在完成测试用例和测试任务管理的同时,天然地连通需求、缺陷等内容,非常方便地实现需求-用例-缺陷的上下游追溯,并实时提供测试进度、需求覆盖强度等报告。正所谓“因为看见,所以相信”。如果某个组织已经在使用JIRA,那么通过JIRA的某个测试插件来实施测试管理,几乎是一件非常顺理成章的事情。

这是其官网上提供的案例。可以看到,依托于JIRA提供的强大工作流引擎,以及和JIRA中需求、缺陷的无缝衔接,让XRAY在测试管理上占到了一个独特的优势。以下是XRAY中的实体关系图,

在一个JIRA项目可以包括多个版本,每一个版本可以包括一个或多个需求,一个需求可能包括一或多个测试用例,甚至可以包括测试集合。测试计划包括那些需要被跟踪的测试用例。测试执行包括那些希望被执行的测试用例。一个测试用例可以被包括在多个测试集合中,可以被多个测试计划所使用,也可以被多个测试执行所执行。一个测试用例可以包括一或多个前置条件,一个前置条件也可以被多个测试用例所引用。每次一个测试用例在测试执行中被执行后,一个测试运行(Test Run)就会被创建。(来源:https://www.jianshu.com/p/50e0289a4656)

XRAY号称已经服务于70多个国家的5000多客户。作为一个小众市场的一款产品,其商业化无疑是非常成功的。类似的还有国产的SynapseRT, 感兴趣的读者可以尝试。

当然,在研发管理领域,国产的禅道、Ones等产品也具备不俗的能力。

从禅道这个产品首页截屏来看,禅道绝没有把自己局限在测试管理领域,而是希望打造一站式的研发过程管控平台。在国产替代的大背景下,以及JIRA转向云化战略的影响下,笔者预计可以私有化部署的这些竞争者们将对JIRA的国内份额将发起强有力的冲击。当然,用户们的使用习惯一旦养成,路径依赖的力量是十分强大的。并且既有的管理平台上积累沉淀的组织资产也是一条深厚的护城河。这条路既是机会多多,也是崎岖坎坷的。

III型用例管理平台

与之前I/II型测试平台形成较大差异的,则是III型测试平台,这种类型的平台更多地注重于自动化测试。

譬如历史上非常成功的HP QC,也就是现今的MicroFocus ALM产品,不仅仅具备用例管理的功能,也可以实现测试脚本托管和自动化测试执行的能力。这其实是用例管理平台的另一个方向,也就是近些年来越来越多团队在建设测试平台时首要考虑的功能。类似于早些年比较流行的开源测试平台Fitnesse,允许用户通过封装接口调用和断言,提供所谓的Slim fixtures,能够让普通使用者在网页的表格里通过关键字来组装用例,实现用例的管理和自动化执行和结果报告。当然,借助于不同的slim插件,Fitnesse还支持java/c++/.net等多种语言的驱动。

包括最近在Github上开源,社区搞得比较红火的MeterSphere,底层依托于Jemter实现了HTTP接口自动化测试用例的一站式管理。以下是其官方在B站放出的介绍视频中的一张片子,基本说明了其主要内容,当然核心还是实现接口测试用例的创建和执行。

当然,这个产品也还在快速迭代中,功能也在愈加的丰富。

自动化用例和用例管理平台

就平台类型来说, I/II型这两种基本上还是以实现测试管理或者研发过程管理电子化和信息化为主。用通俗的话来说,就是以测试任务管理和手工测试用例管理为主。采用了上述平台之后,需要考虑的另外一个问题就是,如何来管理自动化测试用例。

以下是源自XRAY官网的两个截图,

第一张是通常意义上的测试用例和自动化测试用例管理过程。

首先在测试管理平台上建立一个测试用例(逻辑上),然后通过编码实现该用例的自动化(物理上)。接下来的过程就是通过CI等途径执行自动化测试用例,并将结果标注到用例管理平台对应的测试用例上。

这其中有以下的一些关系需要解决

1)【手工】测试管理平台上的测试用例(逻辑上)需要进行创建

2)【手工】如何建立平台上的测试用例和自动化用例之间的关联关系

3)【手工】由于用例执行也往往是用例管理平台上一个重要的概念,如何将某次执行结果和某个用例执行关联起来也是需要解决的问题。

4)在实现上述联关系的基础上,就可以通过接口调用等方式实现结果的自动化上报了。或者某些平台是通过【手工】上传Juni xml报告等形式来实现结果的上报。

而在实际项目中,往往希望能做到整个过程的无缝衔接。如Xray提供的以下案例,

在执行结果上报时,XRAY会自动创建测试用例的JIRA issue, 并接更新其执行结果。

对于自动化用例编写人员,希望能在代码提交并通过CI执行之后,用例和执行结果能够自动被上报给用例管理平台,也就是将上述手工操作能转变成自动化的步骤,这是整个方案能顺利运行的基础。

代码形式的自动化用例,无论是Junit还是pytest,亦或是其余商业、开源或者是自建的测试平台,通过API来向测试管理平台申报测试用例和执行结果。对接测试框架和平台之间,完成上述流程自动化衔接,是整个方案的核心,也是DevOps平台建设中需要周到考虑的细节之处。

你中意哪一型?

对于大型集中式测试团队以及大量采购测试外包的公司来说,III型测试平台几乎是团队的标配了,尤其是如果设置了专门的自动化或者研发效能小组的话,就更是如此了。此类平台的好处也是不言而喻的,通过统一交付界面,有利于快速横向扩展,让更多的内部或者外包业务测试人员能以较低的学习成本来贡献自动化测试用例,由此来快速提升整个组织的自动化测试实施效率,

当然业界对此也有不同的声音。例如业界大佬熊节老师,先生对于中心化、提供自定义DSL的测试平台一直抨击有加,认为这样做只是为极少数“老佛爷”提供了一个铁饭碗。他还撰写过一篇名为《如何做一个能害死人的自动化测试工具》

http://gigix.thoughtworkers.org/2010/5/29/how-to-create-a-test-tool-which-sucks

的文章,讲述了“不知道怎么的被放到一个叫做“测试工具开发”的边角部门里,干着一些不疼不痒不影响公司业绩的工作”的“一个边缘程序员”通过封装测试引擎,发明和“推广一套自己的测试脚本语法”,最终”成功晋升为公司的红人。”

一般来说中心化的平台可能是团队处于高级形态后的事情,笔者也认为平台建设要针对团队自身的实际情况。管理平台,作为组织级资产,其建设和维护其实是一件成本极高的事情,而且受到“康威定律”的影响,极易随着组织架构的调整而被调整。对测试组织形态感兴趣的读者可以移步《你看好哪家的测试组织模式?

对于团队规模较小、工程能力一般,自动化测试历史欠债较多的团队,当前最紧急的可能还是提升测试人员的个人编程能力(包括阅读研发人员代码的意识),发动研发组织全员实施质量内建活动和自动测试。这种情况下,去中心化的测试平台是不是更适合团队呢?也就是自动化测试工具+I/II型测试管理平台的方案,让代码的归代码,让平台的归平台。甚至来说,测试平台压根还没到要考虑的阶段。

你的意见呢?

欢迎关注:软件测试那些事

文章分享自微信公众号:
软件测试那些事

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

作者:风月同天测试人
原始发表时间:2021-06-18
如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • 滴滴开源敏捷测试用例管理平台!

    AgileTC是一套敏捷的测试用例管理平台,具备与xmind等脑图工具一致的操作体验。支持测试用例管理、执行计划管理、进度计算、多人实时协同等能力,方便测试人员...

    全栈程序员站长
  • 测试用例的管理

    随着软件系统规模的持续增大,业务复杂度的持续增加,软件测试的复杂度也随之越来越大。而软件测试工作复杂度的直接体现,就是测试用例编写、维护、执行和管理,所以编写易...

    ThoughtWorks
  • 滴滴开源AgileTC:敏捷测试用例管理平台

    桔妹导读:AgileTC是一套敏捷的测试用例管理平台,支持测试用例管理、执行计划管理、进度计算、多人实时协同等能力,方便测试人员对用例进行管理和沉淀。产品以脑图...

    测试开发社区
  • AgileTC --滴滴开源敏捷的测试用例管理平台环境搭建与试用

    滴滴开源了敏捷的测试用例管理平台,看了下大家部署遇到了各种各样的问题,那么正好呢,我也想体验下这个平台,正好有空,尝试着去搭建下。

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

    点击上方蓝字关注我们! | 导语 使用YAML文件描述测试用例,自动化生成测试用例,并提供网页访问的能力;同时对测试用例数据进行多维度的统计,提供丰富的测试用例...

    腾讯移动品质中心TMQ
  • 测开技能--接口测试平台增加测试用例一键转化Jmeter

    在之前的文章一文揭秘测试平台中是如何将测试用例一键转化Jmeter压测脚本,介绍了在spring boot搭建的接口测试平台,最近在维护开源的...

    雷子
  • 去中心化的测试用例平台之Maven插件

    从测试用例管理的角度来看,测试平台或者测试框架,首先需要解决业务域的问题 1)如何来表征一个测试用例、步骤以及用例集 2)如何来执行用例、用例集 3)如何来获取...

    Antony
  • 如何选择好的测试用例管理工具

    现在越来越多的公司参加到工具链的开发上来, 我总结了一下我们常用的测试管理工具的使用

    小老鼠
  • 一键转化将接口测试平台测试用例转化成Jmeter压测脚本思路

    之前开发的接口测试平台https://github.com/liwanlei/FXTest,今天的时候,想开发一个将测试用例转化成Jmeter压测脚本的...

    雷子
  • 从0到1开发测试平台(十五)性能测试用例管理页面的编写

    上一讲讲解了测试管理页面对应的后台接口,这一节我们主要讲解测试用例管理页面的编写,先上一张写完之后的效果图

    周辰晨
  • 使用Java JUnit框架里的@SuiteClasses注解管理测试用例

    Suppose I have four test cases in my project, the total methods to be tested: 7

    Jerry Wang
  • 如何开发有效的可复用测试用例,又如何使用和管理?

    在软件测试过程中,一个成熟的团队一般都有自己的公共测试用例库。公共测试用例库即可复用的测试用例库。今天我们就讨论一下如何开发有效的可复用测试用例,并学会如何使用...

    Tricy软件测试工程师
  • 面试题解答系列(一)之如何有效避免漏测?

    王豆豆
  • GTest(基于YApi)接口研发效能提升10倍 实战

    现在的互联网行业已经不是大鱼吃小鱼的时代了,而是快鱼吃慢鱼的时代,具体来讲就是从用户需求转化成企业服务的能力,其中研发效能的高低对用户需求转化速率起到了至关重要...

    咻咻ing
  • Allure整合JIRA XRAY实现自动化用例管理

    笔者之前写过一篇文章 测试用例管理平台的一二三 ,介绍了几种常见的测试用例管理平台。本文将介绍如何实现通过Allure提供的注解以及xray-maven-plu...

    Antony
  • 干货 | 去哪儿自动化测试框架Qunit中的零侵入切面技术应用及分布式运行平台

    作者简介 毛京超,任职去哪儿网酒店事业部,负责代理商对接业务线相关的测试工作,参与去哪儿Qunit自动化测试框架的开发。 蒋承君,去哪儿网金融事业部测试工程师,...

    携程技术
  • 技术分享 | Web测试方法与技术实战演练

    技术社区平台,主要为技术人员使用,技术人员作为普通用户可以在社区参与帖子的讨论,也可以发帖提出问题。社区具有分类、搜索、发帖、回帖等功能。

    霍格沃兹测试开发
  • 应用宝基于Robotium自动化测试(下)

    基于Robotium自动化测试(上)》一文中小编介绍了框架选择、测试环境搭建、用例编写、跨应用处理等等内容,本文将承接上文,继续介绍测试报告生成、持续集成等等相...

    腾讯移动品质中心TMQ

扫码关注腾讯云开发者

领取腾讯云代金券