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

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

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

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

对其他职能：了解进度，透明交付过程

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

一般的测试平台能干什么？测试平台有哪些类型？笔者简单梳理了一下，供大家参考。尤其是在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型测试管理平台的方案，让代码的归代码，让平台的归平台。甚至来说，测试平台压根还没到要考虑的阶段。

你的意见呢？

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