【如何设计测试用例】(蓝桥课学习笔记)

如何设计测试用例

1、测试用例的概念和作用

从未有足够的时间做所有我们需要做的事情，这是在软件项目中，尤其是测试环节中的一个普遍的现象。当应用程序发布时，总会有些遗漏的缺陷没有被发现，这是无法避免的一件事情。对于测试人员而言，如何在有限的时间内，把测试工作做到最好是我们需要考虑的事情，设计测试用例就是为了让测试过程在一定程度上变得可控。

所谓的软件测试用例设计就是将执行软件测试的行为活动作一个科学化的组织归纳，通过对每个测试需求进行进一步实例化，来指导软件测试的实施过程。如果没有软件测试用例，软件测试的实施就只能按照测试人员的心情进行测试了，就如同演员没有剧本凭感觉演戏一样，即兴发挥，东拼西凑，效果可想而知。

当软件测试计划评审完成（此时，开发的设计文档也已经评审完成并进入了编码阶段），就可以开始测试用例的设计了。

那么到底什么是软件测试用例呢？首先我们要弄明白它的概念。

软件测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

简单的说，测试用例就是设计一种情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期执行结果，如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示该条测试用例已经检测出软件有缺陷，这时候就必须将缺陷标识出来，开发人员会在下一个测试版本内修复这个问题，软件测试工程师取得新的测试版本后，必须利用同一个测试用例来验证这个问题，确保该问题已修改完成。

从软件测试用例的概念可以看出，软件测试用例的最终形态也是一种文档，它是软件测试执行的基础，是软件测试的核心。好的测试用例能够大大提高测试效率、节约测试时间。本文从四个方面说明测试用例在软件测试中的作用，希望测试人员，特别是测试新人，能够对测试用例给予足够的重视。

避免盲目测试，提高测试效率
编写测试用例有利于测试的组织。在开始实施测试之前设计好测试用例，可以避免盲目测试，提高测试效率，特别是对于测试人员中的新手，好的测试用例可以帮助他们更好地完成复杂的测试任务，提高测试工作的效率。

确保功能需求不被遗漏
测试用例是根据功能需求细细推敲而来的并且通过了严格的评审，按照测试用例执行测试，可以使软件测试的实施重点突出、目的明确，确保功能不会被漏测。

便于回归测试
在项目执行测试期间会有多次回归测试，以保证老的缺陷被成功修复，同时没有引入新的缺陷。如果没有测试用例，凭脑子记住之前的操作步骤是不可能的，这样就无法复原原有的测试过程。

为测试的度量提供评估基准
测试完毕后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量软件测试质量都需要一些量化的结果。比如测试用例的执行率是多少、成功测试用例的执行率是多少、需要的测试合格率是多少，等等。测试用例可以为这些结果提供量化数据和评估的基准。

2、获取需求的测试点

上面谈到了测试用例的重要性，接下来谈一下测试用例的设计步骤。

设计测试用例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户使用场景以及程序/模块的结构都有比较透彻的理解。一般测试用例设计的时候，会考虑如下步骤：

获取需求的测试点

分析系统程序的工作流程，明确各个功能模块的需求，明确测试范围，提取所要测试的具体测试点，为编写测试用例提供依据和思路。

设计测试用例模板，设计测试步骤
确定一份符合规范的测试用例模板，结合软件需求文档，在掌握一定测试用例设计方法的基础上，设计出比较全面、合理的测试用例，并且生成规范的测试用例表。

确定测试数据

根据测试用例表的内容，复审测试用例，并确定支持这些测试用例的实际值，包括用作输入的测试数据、用作预期结果的数据值、用作支持测试用例所需的其他数据。如果是自动化测试的话，在这里需要写自动化测试脚本。

评审测试用例

软件测试用例在形成文档后还需要评审、更新之后才能算是有效的测试用例。评审会议一般至少会进行两轮。第一轮一般是测试负责人召集测试人员进行小组内部评审；第二轮是与项目有关的其他部门的人员进行的评审，比如项目经理、产品人员、开发人员等。一方面可以再次确认需求和预期结果，另一方面可以让各方再次就需求达成共识，减少出错的可能性。

获取需求的测试点

在进行软件测试计划的制定时需要对需求进行分析，那个阶段的需求分析主要是就宏观的功能模块进行分析，以及对需求规格说明书进行评审测试。而在设计测试用例时进行的需求分析的目的则是为了获取详细的测试点，然后根据测试点来编写测试用例，这个阶段的分析更加细化，更加具体。比如：

在功能测试中，通过分析需求描述中的输入、输出、处理、限制关系、约束等，给出对应的验证内容。

在功能交互测试中，通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在功能交互的功能项给出对应的验证内容。

在其他的一些测试中（如界面测试、可靠性测试、易用性测试等），则需要考虑到需求的完整性，测试用例要充分覆盖需求的各种特征，包含隐性需求的验证，比如界面的验证、注册账号的唯一性验证等。

做好测试用例的关键就是，对需求和设计文档的理解，以及对系统的熟悉，所以测试用例的基础是软件需求。软件需求决定了测试点，但测试点却不完全来自于软件需求，测试点的来源有显性的和隐性的两种。需求文档是显性需求，而一些通过测试的原则、行业传统和常识推理出来的需求则属于隐性需求，它们无法从需求文档中直接导出。

软件测试用例必须建立在需求的基础上，检查系统的实际行为与需求指定的行为是否一致。显然一份可测试的、完整的和详细的需求说明书是对测试工作最大的帮助。但是在实际工作中，需求的定义通常是不完善的，有的项目甚至根本没有需求文档，虽然这从流程上来说绝对是不规范的，但是确实常常因为项目比较紧张存在不少这种缺胳膊少腿的现象。那作为软件测试人员，该如何在这种情况下突围呢？笔者经常被问到这个问题，尤其是测试新人对此处疑惑最多。

通常没有明确的需求文档的时候，软件测试人员可以像软件需求人员一样根据不同的项目类型去获取测试需求。除此以外，还要学会灵活应对，常用的方式有以下几种：

阅读遗留文档，收集整理已有的需求
如果没有可以用来导出测试用例的需求，测试人员可以通过阅读项目的原有文档来获取，例如：当前系统或者遗留系统的用户手册、有关遗留系统的测试工作的风险的讨论、遗留系统的缺陷列表以及软件测试总结报告等。什么是遗留系统呢？当系统由于某些局限如技术方面的局限，而无法满足新的业务需求，从而需要进行超出维护范畴的修改时，系统就变成了遗留系统，也可以理解为上一个版本的系统。如果存在遗留系统，那么可能会得到用于遗留系统开发过程的设计文档、设计标准、缺陷列表等。但是，新老系统之间肯定会有部分业务的变更，所以遗留系统的文档只能作为一个参考。

向相关人员咨询
可以和产品经理对需要测试的内容进行逐条确认。如果没有专门的产品经理（这种情况也不少见），也可以向项目负责人、设计人员、开发人员等当面进行咨询。或者让他们介绍一下产品的功能模块，并在自己使用后对产品进行模块划分，通过应用和分析来确定应用程序的测试点。

参考同类产品的需求说明
如果连遗留文档和开发文档也没有，也可以去网上查询一些同类产品的使用说明，幸运的话，还能找到一些类似产品的需求说明。这些文档虽然不是自己产品的需求说明，但是因为是同类产品，功能方面也总会有几分相似。研究同类产品，也可以增加对自己产品的把握。

采用探索性测试的解决方案
测试人员还可以通过探索性测试来获得更多的需求。我们可以把软件当产品说明书来对待，分步骤地逐项探索软件特性，记录软件执行的情况，详细描述功能。探索性测试与经过深思熟虑的、计划好的测试过程有所不同，它并不预先设计测试用例或者精确地按照一个计划来执行，它依靠的是测试员的知识水平和创造力。探索性测试可以运用在整个计划、编写用例和执行测试过程中。

运用探索性测试发现的问题将有助于我们确定工作的重点，例如：如果测试出系统的某个部分缺陷较多，而另一个部分却相对较少，那么我们就可以根据这些信息调整工作的重点。在这种情况下，无法像有些产品说明书那样完整测试软件，无法断定是否遗漏功能，但是可以系统地测试软件，肯定也可以找到缺陷。当然了，我们同时也要注意一点，探索性测试虽然在获取测试点的时候起到一定的作用，但它本身并不是非常强大的测试技术，它不能预先规划，不能确定和衡量测试的覆盖率，并且可能会遗漏重要的功能路径。

3、测试用例模板

编写测试用例应有文档模板，模板必须符合内部的规范要求。软件测试用例的基本要素应该包括用例编号、测试模块（测试对象）、测试标题（测试点）、用例级别、测试环境、测试输入、操作步骤、预期结果。

通常，我们用 Excel 表格或 Word 表格的形式来书写测试用例，如下表为测试用例 Excel 模板和测试用例的 Word 模板。也可以直接保存在用例管理系统中。以下，我们对测试用例的这几个基本要素做个说明：

测试用例Excel模板

测试用例Word模板

用例编号
用例编号是标识该测试用例的唯一编号，用以区别其他测试用例。测试用例的编号有它的定义规则，可以写成“项目名称-测试阶段类型-编号”或者“项目名称-模块名-编号”。比如 LQ-ST-001（LQ 软件系统测试用例 001，此处假设“LQ”是一个项目的名称）或者 LQ-Login-001（LQ 软件登录模块测试用例 001）。定义编号的规则主要是便于检索。

测试对象
也可以叫做“测试模块”。指明要测试的项目、子项目或者软件的被测模块。如：xx 菜单、登录模块、购物车等。测试模块有时候还有子模块、子子模块，直接增加在表格中即可。

测试点
也可以叫做“测试标题”。测试点应该清楚地表达测试用例的用途，如“测试输入错误的密码进行登录时，软件的响应情况”。

测试环境
有时候也写作“前提条件”。是执行测试时所单独需要的特殊环境要求。或者执行测试用例之前所做的操作，如启动程序等。

操作步骤
操作步骤是执行本测试用例的每一步操作。需要注意的是每一步骤都要有一个编号，便于查看。描述要简洁、清楚、明确、完整、一致。

测试数据
描述测试用例所需的输入数据或条件。例如：测试计算器时，输入可以是 1+1，也可以是 1+2；除了数据之外，还可以是文件或具体操作（如单击鼠标、在键盘做按键处理等）。

用例级别
也叫测试用例的优先级，这部分涉及内容比较多，也是测试用例中比较重要的一个项，在本章下一个小节中单独详细介绍。

预期结果
描述输入数据后程序应该的输出结果。例如，输入 1+1，预期结果是 2；输入文件名，预期结果是可以正确打开文件，文件的内容和预期一致。通常，我们可以通过检查具体的屏幕、报告、文件等方式来确认实际结果与预期结果是否一致。

以下以登录界面（假设界面只有“用户名”输入框和“密码”输入框，以及“登录”按钮）为例，来写几条测试用例，供读者熟悉具体写法。

登录界面测试用例案例

4、测试用例的优先级

在实际软件测试项目中，经常无法在每一个应用程序的版本上执行全部的测试用例。所以在测试资源和时间都有限的情况下，你必须知道哪些测试用例应该被优先执行，哪些测试用例是在有富裕时间的时候可以被增加执行，这很大程度上是由测试用例的优先级来决定的。

总体来说，制定了测试用例的优先级，可以有以下好处：

可以优先执行优先级高的测试用例，即使测试时间不足，也能尽量保证测试工作达到了良好的效果；
可以根据优先级策略，高效分配测试资源，从而达到成本、质量的平衡；
可以为待定的自动化测试做一个好的起点。那些反复被执行最多次数的测试用例，可以使用自动化的解决方案。
因此测试用例优先级在一个测试项目中至关重要。

Ross Collard 在“Use Case Testing”一文中说“测试用例的前 10%到 15%可以发现 75%到 90%的重要缺陷。”而测试用例的优先级别划分就是帮助我们找出这前 10%到 15%的测试用例。

测试用例的优先级别划分在不同的公司会有所差异，以下推荐一种常见的测试用例优先级别的定义。如下图所示，我们将测试用例分成 4 类：BVTs，高，中和低。先对它们进行一个简单的说明。

测试用例优先级

测试用例的优先级

1-小版本确认测试（Build Verification Tests，BVTs）
也叫冒烟测试，这是一组需要优先执行以确认该软件版本是否可以继续测试的测试用例。BVTs 级别的测试用例如果测试失败会阻碍其他测试用例的验证，因为 BVTs 测试不能通过的时候，试图去执行其他部分的测试没有意义。比如登录功能中，如果连正确的用户名和正确的密码都无法成功登录的话，再去测试其他登录的情况就是毫无意义的。这种用例一般占总用例的 10%~15%。

2-高（High）
是指最常被执行的、保证功能稳定、目标的行为和能力正常工作的、能发现重要错误的测试用例的集合，这部分测试用例一般占总用例的 20%~30%。

3-中（Medium）
这部分用例更全面的验证功能的各个方面，主要指异常测试，如边界、断网、容错和配置测试的测试用例。这部分用例一般占总用例的 40%~60%。

4-低（Low）
这是一组最少被执行的测试用例。但这并不是说这些测试用例不重要，只是说他们在项目的生命周期里不是常常被执行，例如 GUI，错误信息，可用性，压力和性能测试。这部分用例一般占总用例的 10%~15%。

现在，测试用例的优先级别已经定义好了，那么如何把设计好的测试用例放到对应的级别中去，是另一件比较复杂的事情。分配测试用例的优先级并不容易，因为试图停止思考“所有的测试用例都是同等重要的”这个问题是一件非常困难的事情。遵循一定的步骤会让这件事变得稍微容易一些。

按照一定的逻辑把软件测试用例先随意进行分级

把所有功能性验证的测试用例标记为“高”优先级；
把所有错误和边界值的测试用例标记为“中”优先级；
把所有非功能性的测试用例（如性能和可用性）标记为“低”优先级。
并非所有的功能性测试用例都一样的重要。那么对于已经分配好优先级别的测试用例可进行提级或降级。

把功能性验证的测试用例分成两组：重要的和不十分重要的。把“不十分重要的”测试用例降级为“中”优先级；
把所有错误和边界值的测试用例分成两组：重要的和不十分重要的。然后把“重要的”升级为“高”优先级；
把非功能性测试用例分为两组：重要的和不十分重要的。把“重要的”升级为“中”优先级。
识别 BVTs 测试用例

将“高”优先级别的测试用例分成两组：严重和重要的。然后把“严重的”测试用例升级为 BVTs 优先级。

这些步骤和原则是对分配测试用例到不同优先级别的一个简化过程，但是在快速迭代的实际工作中，它可以给你很多帮助。另外需要记住，在一个项目中，这些优先级别不一定是静止的，可以根据实际情况进行调整。比如有的公司可能把测试用例的优先级分为“高”、“中”、“低”三个级别，或者“p1”和“P2”两个级别。只要分别对他们进行定义，并取得项目小组的一致认可即可。

5、测试用例的设计原则

测试用例除了应该符合基本的测试用例编写规范，还要遵守以下几条基本设计原则：

测试用例的描述要明确
测试用例的描述必须是明确的，比如“用户正确操作，系统正常运行”或者“用户非法操作，系统不能正常运行”这样的描述就是不明确的，什么是正确操作？什么是正常运行？这就必然导致测试人员对测试用例的理解不确定，从而引发测试中的错误发生。

除了操作步骤的描述要明确，预期结果的描述也必须是明确唯一的。

测试用例的描述要简洁
虽然我们要求测试用例的操作步骤要足够详细、准确和清晰，但同时也要保证测试用例的简洁性。冗长和复杂的测试用例可读性太差、不利于测试人员理解和操作，甚至有时候自己设计的测试用例，自己都不想执行。但过于简洁也会容易使人产生误解，所以要做到恰到好处，好好锻炼自己语言组织的基本功吧。

测试用例对需求的覆盖采用最小化原则
比如说，有一个系统功能模块，有 3 个子功能，那么我们是用一个测试用例覆盖三个子功能呢？还是用三个单独的测试用例分别覆盖三个子功能呢？对于稍微有点规模的项目，推荐后者。因为一旦发现了缺陷，指向性更强，便于调试。

测试用例编写要有条理、逻辑性强
测试用例可以按照功能点分类、操作顺序等逻辑顺序编写，而不要一会测试这里，一会测试那里，会让人无所适从。

功能覆盖全面、深入，能够发现软件中更多的缺陷
除了通过测试外，可以多想一些异常的操作流程进行失败测试，试图破坏软件，查看软件的响应情况。

6、测试用例的维护

在测试过程中，测试用例并不是一成不变的，它需要不断的更新和维护，这是一个不断修改完善的过程。无论事先把测试用例设计的如何好，开始执行测试后，肯定又会考虑编写新的测试用例。原因有三：

在实际项目中，所有需求和设计文档都存在而且包含所有功能路径和场景说明的情况非常罕见，导致编写测试用例时也会有遗留；
有时候系统架构和设计阶段错过的细节，直到执行测试阶段才浮出水面，这时候就需要补充测试用例；
软件自身的新增功能以及软件版本的更新，导致测试用例也必须同时更新。
在执行测试时，测试人员常常会由于学到了关于系统的更多知识，能够设计出新的测试用例。但这种时候，一般都处于最繁忙的测试阶段，除非发现了缺陷，测试人员往往都只执行测试而不做记录。而其实这种测试用例常常是测试过程中产生的最有用的部分，我们应该及时把它们更新到测试用例库中，或者先记录下来，等测试的执行告一段落之后再录入测试用例库中。

通过以上学习，可以发现，在软件测试项目中，编写测试用例是必要的，有很多好处。但也有其局限性，编写测试用例是个费时费力的工作，通常编写测试用例的时间比实际执行测试的时间还要长，后期维护量也非常大。而且如果是自动化测试的话，自动化测试脚本的维护量也不亚于开发代码的维护量。尽管如此，编写测试用例依然是测试工作中不可缺少的一部分。