【经验分享】软件测试用例管理

Posted 2023-04-03

本文涉及到测试用例的编写规范，以及用例管理的分享，因此，无论是对于初级测试工程师，还是质量团队的管理者，都有一定的参考意义。文中涉及到的方法和工具并不是唯一解决方案，希望大家收获到的不仅仅是文字表面，而是文中分享的一些思路。

有人说：测试用例还不知道？不就是描述测试步骤吗？

这么回答确实没什么错，只是如果内心上也仅仅这么认为的话，只能说并未理解测试用例。

测试用例除了作为测试行为的描述，更多的是作为被测目标是否达到需求的验证，主要还是考验了一个测试工程师的组织归纳能力，其输入来源往往是承诺书、用例(Use Case) 以及自身对业务领域知识的经验，一个软件测试工程师的专业度往往体现在他设计的测试用例上。

专业的工程师设计出的测试用例集，不仅能够描述自己的行为，还能指导别人实施，不仅强调深度，还具有优秀的用户思维。

虽然从格式上来说，基本就定型了：

关于这部分，网络上的教程只多不少，就不赘述了。

只不过要强调的重点是， 格式只能保证测试用例明晰，并不能提升测试用例的设计能力 。因此，测试用例该怎么写？还是要从结构化设计开始。这里需要提到一个概念 HLTD [ High Level Test Design ]，可以简单粗暴的理解为测试大纲的设计。

就如同我们写文章一般，提笔正文之前，会先拟个草稿，列出中心思想及段落提纲，然后再攥写润色。

写测试用例也是类似的套路，先列出测试点作为大纲，并且具有结构化布局。通常以大的功能或模块进行分类，再细化二级甚至三级类别，最终列出具体的测试点。该阶段的设计，笔者倾向于利用思维导图（脑图），相较于传统的文档软件工具，思维导图的展现更直观。

由于最终会是一张大图，所以硬伤也随之体现，只适合用于思路梳理，不适合用于文档化管理。

把这些结构化好的测试点文档化，就是我们所说的测试用例了。

所以从这里我们可以看出，每一条测试用例的目的很明确，是验证一个或一类测试点，颗粒度需要根据公司实际情况权衡，太粗不利于对于测试点覆盖的总结，拆太细会消耗更多的精力。

测试用例其实是一个非常详尽的文档，必然会消耗测试工程师相当一部分的精力。在传统软件开发时代，甚至作为 KPI 的一项指标。

但随着敏捷时代的兴起，有一种声音开始冲击这种认知。

早期的敏捷实践者，对敏捷宣言的解读仅仅停留在了文字表面，认为“只需要软件，不需要文档”。这直接导致了这一时期，大量的团队缺失了详尽的文档，甚至连一些基本的文档都没有。

如今，越来越多的敏捷实践者认识到，敏捷宣言所宣扬的并不是“不用详尽的文档”，恰恰相反， 敏捷宣言认同了“详尽的文档很重要”这件事，并且提出了更高的要求 —— “工作的软件更重要”

对于测试用例文档化工具的选择，很多团队仍然停留在传统的办公软件，如 Word、Excel

但如今凡事比快的市场环境下，团队成员高效协作、团队信息实时共享的需求越来越高，测试用例平台化管理必然还是最终归属，除了文档化，还利用平台制定计划，展示进度和结果。

事实上，在传统时代，大一些的软件公司就已经使用平台来管理测试用例了，这再一次证明了敏捷时代并不意味着推翻过去的经验和成果，而是提出了更高的要求。

如今，相对知名的管理平台有基于 Jira 做插件的，如：Zephyr、Xray、synapseRT、TM4J，也有独立的开源平台: 如：TestLink，或收费的独立平台: 如：TestRail

我们主要从其生态、推行成本、可扩展、费用角度去综合考虑。

Zephyr 的名气一直都很大，但实际上并不太符合国人使用的习惯，使用起来诸多不便。用例直接使用 Jira issue，功能比较简单，用例管理主要在计划和循环的关联上。由于其是 Jira 插件，因此能很好的跟 Jira 上其他 issue (需求、任务、缺陷) 进行关联。但其用例管理的可视化不是很好，没有用例集的概念。迁移方面，数据导入支持类型有限。扩展方面，若要使用其 API，还需要另外装一个插件。其费用中等。

Xray 算中规中矩，也是使用 Jira 的 issue 来创建测试用例。但其新增的 issue 类型多达 5 类，显得极其复杂。关联能力与 Zephyr 相同，数据导入支持类型有限，本身有 API 可供使用。其费用中等。

synapseRT 是国人开发，汉化效果最好，功能强大。有用例集的概念，用例也是用的 Jira issue 来扩展。数据导入支持了 TestLink、Zephyr 这样的其他平台。关联能力同 Zephyr，数据导入支持类型依旧有限，其本身也有 API 可使用。而费用相对较低。

TM4J 使用独立页面管理测试用例，脱离复杂的 Jira issue 页面，上手难度低。数据导入功能强大，覆盖很多类型及一些知名平台。关联能力与上述插件一致，本身也有 API 可使用。但费用相对较高。

TestLink 作为独立的测试管理平台，功能全面，开源免费。可以关联 Jira 这样的知名平台，但由于不是 Atlassian 体系，所以生态体验不高。硬伤是界面丑陋，容易影响工程师的心情。笔者曾经使用其本身的 API 进行 UI 美化。

TestRail 是一个强大的商业平台，笔者接触不多，不乱作评论。

综合考虑，虽然 TestLink 作为免费开源用例管理平台中的 TOP，在用例管理上做得非常科学，一直值得学习，但笔者所在公司已经在使用 Jira，并在落地 DevOps，外加笔者常受 Atlassian 中国社区研究院副院长的支持，TM4J 成为最终选择：

出品方还是挺强的，除了 TM4J，Zephyr 其实也是其下产品，Swagger 也已经是目前认知度很高的产品了。

从官网介绍上可以看出，TM4J 还是比较现代化的：

首先我们看看利用 TM4J 如何来编写测试用例。

层级结构上，我们根据 HLTD 来创建目录以及子目录，以方便所有人理解和阅读，最后的测试点则实例化为一个测试用例，它拥有全局唯一的 Key。

点击 New 按钮创建新测试用例，默认在 Details 标签页，在这里定义用例名称、目的、前提条件，详情中可以设置状态、优先级、所属组件，并可以添加一些便于管理的标签。

切换到 Test Scripts 标签页，默认是 Step-by-Step 类型，按照 STEP - TEST DATA - EXPECTED RESULT 添加每一个测试步骤。

另外值得一提的是，在 Traceability 标签页，可以关联 Jira issue、Confluence page

通常我们针对每次产品发布交付，需要制定范围，因此计划管理是必不可少的。

计划管理推荐按照发布版本来制定顶层目录，然后针对测试类型创建二级目录，如回归、新功能、端到端、接口、性能等等。

测试计划的创建本身操作倒并不复杂，除了定义计划名称、目的、状态、责任人，外加一些标签。

还需要关联一下需求或者 Confluence 页面。测试周期在刚创建测试计划的时候可能并不存在，可以在之后创建测试周期的时候，会双向关联。

测试周期是一个承上启下的关键，往上关联测试计划，往下关联具体的测试用例。

通常一次发布交付会经历 3-5 次冲刺，每轮冲刺的范围不一定完全相同。

在新建完测试周期名称、描述以及详情之后。

进入 Test Cases 标签页，点击 + Add test cases 添加已经编写好的测试用例。

这一步操作使得测试用例具备了项目属性。

最后在测试周期的 Traceability 标签页点击 Test Plans 后面的放大镜。

通过查找来关联已经做好的测试计划。

创建完测试周期，就可以进入该周期浏览到分配到自己名下的测试用例了，这是所有测试执行者都需要用到的界面，还可以通过 Group by 根据不同规则进行归类，比如根据测试周期中制定的不同目录。

对于用例步骤的执行，TM4J 提供了一些快捷按钮，可以直接标记通过、失败、阻塞，并且可以点击齿轮按钮，快速创建、查找 Jira issue 进行关联，当然，除了对于步骤关联 issue，也可以针对该用例标记 issue，点击 Issues 后面的 + ▼ 可进行操作。统一平台的好处便是在此了。

虽然我们在查看测试周期列表的时候可以看到测试的进度，但更多数据展示可以通过测试报告来体现。

TM4J 的 Reports 功能给我们提供了丰富的模板，方便一些经验不足的测试质量管理者。

最后，笔者想说， 测试工作不能作为一个独立的业务，应该更多的与其他角色协作 ，特别是在现在的敏捷时代，测试用例的执行可以要求开发工程师关注，测试的状况可以要求产品经理随时介入，因此，强烈建议我们软件测试工作者尽量选择一些跨职能协作平台。

参考技术A

国内外9大测试用例管理工具：1.PingCode；2.TestRail；3.Xray；4.Jira；5.PractiTest；6.PractiTest；7. Zephyr Enterprise；8.MeterSphere；9.Bugzilla。

一、采用测试用例管理工具的必要性

以前我们用 Excel 来维护测试用例，产品发布前把 Excel 里的用例过一遍，这样做似乎是可行的。但随着项目的迭代，项目复杂度的增加，用例的版本也越来越多，Excel 这类工具的缺点也逐渐显现。

比如通过 Excel、Xmind 等维护用例，我们经常面临：

缺乏用例该有的元素（计划、评审、优先级等)

多人协作，用例没有统一存放地点，管理也非常麻烦；

项目大，模块多，文件特别大；

项目迭代，用例无法保证常用常新；

Xmind 查找过滤麻烦，破解版稳定性差；

查看历史记录和历史版本对比麻烦；

用例无传承；

QA 工作难以度量；

等等

我相信国内大部分公司都和我们类似，要么拿着 Excel、Xmind 这种非专业的测试用例管理工具来管理的测试用例，要么拿着 TestLink 这种从界面到交互都感觉上古时代的平台来管理，而且一个不到百人的
QA Team，连一个用例管理都没做统一，上面三种同时存在，不同 Team 用不同的方式，甚至一个 Team
内都可能多种并存，而且更让我吃惊，他们都拿不出一份自己系统完整的测试用例，因为他们每个版本都用一份新的文件去管理用例，所有旧的用例都不会被传承下来。

除此以外，通常的测试管理方法还有两种，一是使用一些专业的测试用例管理工具，比如PingCode、TestRail等；另一种是使用Cucumber，RF，SVN和GIT等代码活文档、自动化测试框架和代码版本工具。下面我们将一一介绍。

二、大部分人都在用的9款测试用例管理软件

曾做过一次测试管理工具选型，调研了几种工具，整理了网上一些比较靠谱的软件测评文章资料，涵盖国内外厂商开源和商用版，下面一一列举各工具特性和优缺点。

1.PingCode

这可能算是国内近几年最好用的测试用例管理工具之一，具有成熟的功能，不错的操作体验，以及还是一站式的研发项目管理软件。能够帮助团队把控测试质量、管理测试过程、实现团队内外部的协同。

具体功能包括：测试用例库管理、编写用例、用例维护、测试规划与执行、关联用户故事与缺陷、测试报告与测试报表、关联自动化测试工具，掌握测试进度和执行结果情况等等能力。

最让我喜欢的是，PingCode 支持用例自定义，这对于对扩展有情结的人来说非常重要，因为业务是多变的，多给自己留点空间，同时用例导入这块支持脑图的导入、支持代码工具git、CI/CD工具jinkens等也是非常吸引我的。

除此以外，PingCode

还被广泛用于需求收集、需求管理、需求优先级、产品路线图、项目管理（敏捷/kanban/瀑布）、缺陷追踪、项目文档管理、效能度量等领域。并且集成了github、gitlab、jinkens、企微、飞书等主流工具，也就是说我们能在需求下面关联代码，关联集成信息，在飞书查看通知等。对比其他产品它具有简单易上手、开箱即用、成本低的特点。

软件优点：

产品开箱即用，简单易上手，不需要像Jira 那样经过好几月的培训，以及专门的系统管理专家配置系统才可使用；

为25人以下团队免费提供基础版本，收费版价格仅为国外产品Jira的30%-40%；

国产化，支持信创、麒麟等；

支持私有部署、定制化以及saas等购买方式；

口碑、服务支持好；

软件缺点：

暂未提供多语言版本；

PingCode官网

2.TestRail

TestRail提供了全面的、基于web的测试用例管理，以帮助团队组织测试工作，并获得对测试活动的实时了解。使用TestRail，您可以通过屏幕截图和预期结果轻松地捕获关于测试用例或场景的细节、跟踪各个测试的状态、使用信息丰富的仪表板和活动报告来度量进度，以及在多个测试运行、配置和里程碑之间比较结果。

工具优点：

具有三种测试用例管理方式：普通，基线（类似Git分支），多套件；根据创建的测试场景执行测试，例如可自定义浏览器、操作系统等；可集成众多缺陷追踪工具，如JIRA，GitHub，YouTrack等；提供Saas在线模式和独立部署版本；开放API。

工具缺点：

三种用例组织方式中使用较复杂（仅普通方式较好理解和使用）；交互设计较旧，10年前技术；SaaS版在国内访问速度很慢；价格较高

官网：https://www.gurock.com/testrail/

3.Xray

Xray是QA的第一大手动和自动测试管理应用程序。它是一个功能全面的工具，可以集成Jira。它的目的是帮助公司通过有效和高效的测试管理来提高他们的产品质量。

官网：https://xray.cool/

4.Jira

Jira 是全球知名的IT项目管理工具，它虽然自己不具备测试用例管理能力，但可以通过它丰富的插件完成，比如：

插件Zephyr：可以创建测试用例，测试套件，进行测试周期的管理，还可以有一个附加组件ZAPI用于自动化集成。

插件Go2Group SynapseRT：该工具具有测试用例管理功能，但主要关注基于需求的测试，可以用于跟踪某个需求对应的测试用例执行进度。

插件XRay：支持测试用例管理。Xray支持手工和自动化测试，包括Cucumber等BDD测试框架，以及JUnit、NUnit、Robot等自动化测试框架，覆盖了整个测试生命周期。

因为是基于插件提供的服务，所以永远都存在较高的下线风险，而且Jira本身价格加上插件的价格总价可能会远远超出你的预算，以及它在2020年以后在大陆停售本地版，所以你无法购买带本地部署等版本，只能上云。

工具优点：

作为Jira插件存在，也提供SaaS版独立运行；

测试中创建缺陷非常便利；

提供测试循环操作；

提供多种报表。

工具缺点：

不提供与其他第三方缺陷工具集成；

Jira的SaaS版本国内访问较慢（独立部署的Jira版比较吃服务器资源）。

官网：https://www.atlassian.com/zh/software/jira

5.PractiTest

PractiTest 是测试管理工具中一颗冉冉升起的新星，是一个端到端的测试管理系统，提供了测试用例管理，缺陷状态管理，具有可定制的仪表板，并附有详细报告。该工具提供了手动测试和自动化测试管理选项，还有探索式测试测试管理的功能。 

PractiTest与缺陷跟踪工具，如JIRA、Pivotal

Tracker、Bugzilla和Redmine，以及各种自动化工具，如Selenium、Jenkins等，无缝集成。PractiTest是唯一符合SOC2
Type2（安全方面的权威资质）和ISO 27001的测试管理工具，使其成为市场上最安全的QA系统。

官网地址：https://www.practitest.com/

6.Kualitee

无论您是在Excel中管理测试，还是已经在使用软件生命周期管理工具，Kualitee测试管理工具都可以为您的测试减轻麻烦，并使团队协作更加轻松。通过我们精心设计的仪表板，轻松地分配任务给团队，并始终保持在实时进展的顶部。

您可以与非常多的工具进行集成，并根据您的喜好进行定制，包括报告、筛选器、缺陷报告等等。价格也被特意保持在可承受和灵活的范围内，用以适合从单个测试人员到100多个团队组织的所有规模的团队。

7. Zephyr Enterprise

Zephyr最初是Jira中的一个插件，以增强Jira支持测试管理的能力。然而，对于规模较大的组织来说，由于测试活动的复杂性，采用这种方式进行测试用例管理是不够的，因此开发了企业版。Zephyr
Enterprise支持和Jira、以及CI/CD调度工具Jenkins、自动化测试工具Selenium等的集成。

官网：https://smartbear.com/test-management/zephyr-enterprise/

8.MeterSphere

MeterSphere 是一站式开源持续测试平台，涵盖测试管理、接口测试、性能测试、团队协作等功能，兼容 JMeter 等开源标准，有效助力开发和测试团队充分利用云弹性进行高度可扩展的自动化测试，加速高质量软件的交付。

官网：https://fit2cloud.com/metersphere/

9.Bugzilla

Bugzilla是一个开源的、基于Web界面的缺陷跟踪工具，可以管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期。Bugzilla在相当长的一段时间内被许多组织广泛使用。

官网：https://www.bugzilla.org/

一个项目经理的切身经验总结：测试用例可以被替代吗？

首先我们先明确测试用例是什么？个人觉得测试用例应该有：标题，测试目的，前提（预设条件），测试步骤，预期结果等。测试人员可以根据测试用例的这些要素，可以执行测试。那么它在软件测试流程中是必需的吗？
先分享下个人关于测试用例方面的经历：A公司和B公司。A公司有完备的大型软件开发流程，产品有自己完备的测试用例库和测试用例管理规范，在项目中也有测试用例的输出阶段：功能需求和概要设计出来以后，测试人员就根据这些输入开始着手准备测试用例。

接下来还会经历测试用例点的评审和测试用例的定稿阶段，测试人员根据完成的用例执行测试。在项目发布之后，还会预留时间对测试用例进行修改入库。这些入库的测试用例会作为回归测试的全集。公司A的某产品在项目中的测试用例相关活动如下图展示：
项目中测试用例相关活动图

B公司和A公司属于同一个行业，所在的产品也有软件开发流程，但是此流程被增删处理了，从测试活动角度而言，关于测试用例的相关活动已经完全删掉。只是在项目结束后会输出一个关于新功能的checklist，产品有一个checklist库。这里解释下checklist和测试用例的区别：checklist可以理解成等同于测试点，没有任何测试步骤和预期。不同的人拿到同样的一条checklist可能测试方法是不一样的；而对测试用例来说，不同的人拿到同样的测试用例测试方法是一样的。

A和B两家公司的产品质量应该说都还可以。关于测试用例是否是必备的呢？个人观点跟团队的架构和整个团队的测试经验有很大的关系，如下说明：

1、B公司的测试人员经验基本上在五年以上，并且是从相关行业跳槽过来的。可以说相关行业测试经验丰富，可以根据checklist进行测试；

2、B公司的测试人员模块分配固定，比如模块A分给测试人员小王，可能会一直分配给他。他对于这个模块的熟悉程度和测试方法的把握会得心应手，所以有没有测试用例没有影响到模块A的质量。

不过这样也遗留下了其他问题，如果存在测试人员离职，很可能这些测试方法就从此断档。

对于A公司这种完备的测试用例，有一次在项目总结会上，测试团队有人提出来，每次按照测试用例的步骤发现问题的概率不大，应该根据测试用例适度调整测试步骤和方法。当时这个提议是个人也是比较认可的。但是基于当时团队现状并没有公开尝试。主要原因是团队人员新生力量多，测试经验少，对产品的了解不透彻。

以上是2个公司关于测试用例情况的案例。测试用例是否必须的，不是一概而论的。以下是自己关于这方面的想法：

i)如果是一次性的项目，比如这个项目不会有延续性，做完就结束了，不需要维护了。这种情况个人觉得测试用例可以去掉或者简化测试用例，用checklist的代替应该就可以满足，毕竟是一次性工程。

ii)如果团队新生力量多，测试经验少（1-3年），可以在测试用例多下一些功夫，因为在测试用例产出前会有测试分析和测试设计的阶段，这两个阶段会很大的提升员工的测试能力和深化对被测对象的理解。

iii)如果团队测试经验丰富，对被测对象也熟悉。可以用其他的方式代替测试用例，比如checklist，避免人员流动带来的影响，可以采用文档的方式记录模块的功能逻辑和使用场景等。

整体来看对测试用例的把握可以很灵活，这些测试的输出并不是完全不变的。完全根据团队情况、项目情况等因素，合理把控，用其他方式代替也是可行的。关键在于一点，质量能保证即可。

最后:【可能给予你一定的帮助】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!
关注我的微信公众号【软件测试小dao】免费获取~

我的学习交流群：644956177 群里有技术大牛一起交流分享~

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！