你必须要会的测试用例基本功

 /摘要 /

随着软件系统规模的持续增大，业务复杂度的持续增加，软件测试的复杂度也随之越来越大。而软件测试工作复杂度的直接体现就是测试用例编写、维护、执行和管理，所以编写易读、易维护和易管理的测试用例可以有效的降低测试工作的复杂度。本文主要系统的介绍了测试用例的几种经典编写和管理方法，包括每种的特点，适用场景以及实例。帮助不同的项目和团队，根据自己的情况选择适合的测试用例编写和管理方法，从而降低测试工作的复杂度，提高测试工作的效率。

1

前言

在软件测试工作中，测试用例是其最为重要的基础。一个良好的测试用例可以帮助测试人员更容易阅读，理解，修改并管理它，从而提高测试工作的质量和效率。要编写一个好的测试用例，首先需要对业务需求和验收标准进行深入的分析，并确定业务需求和验收条件的正确性和合理性。然后对其进行测试分析，并完成整体测试用例的设计和编写，其中包括功能测试用例，端到端测试用例，异常测试用例等等。在分析和设计用例的过程中，可以通过启发式测试策略模型 （HTSM）这类方法来进行分析，并通过边界值，决策表，PairWise 等方法来设计测试用例。其中的难点如何让测试用例尽可能的覆盖到验收标准，从而完成验收功能的高覆盖测试率。并且还要尽可能找到业务需求，技术架构等系统相关的各种限制，通过分析限制可以得到更多的测试用例，包含异常测试用例。对于设计好的测试用例需要进行分类并管理，然后根据不同的分类进行分层测试。通常情况下可以将测试分为端到端测试，功能测试，集成测试，单元测试等。根据这个分类方法，可以方便进行测试分层管理，就是就是某些测试用例放在端到端测试类型里面，而有些测试用例则放到集成测试类型里面。而根据测试用途还可以将某些类型的测试分类成回归测试，验收测试，健全测试和冒烟测试等。由于一个测试用例可能既属于回归测试，又属于冒烟测试，所以这种情况下就需要一个良好的测试管理系统或者管理方法来对大量的分类后的测试用例进行管理。编写和管理测试用例是测试用例工作中工作量最大，最为繁琐的部分。其质量的高低直接影响到测试工作是不是能高效和顺利的进行并完成。所以结合产品的类型和团队的情况，选择适合自己团队的用例编写和管理方式，从而事半功倍。

2

测试用例分类

测试用例通常可以分为两大类，即验收测试用例和探索测试用例。

验收测试用例的核心就是验收条件，对于明确清晰并且细化到足够程度的验收条件，可以直接转换为或者作为测试用例来使用。但是往往很多情况下测试用例没有细化，甚至不够明确和清晰，存在歧义，从而导致很难设计出足够的用例来映射到所有验收条件，称之为 AC Mapping。其次对于整个软件系统来讲，由于很多验收条件都是一些分散的点，而如何通过分析业务需求和验收条件等来设计测试用例，保证测试用例对于系统功能或者端对端场景的全覆盖，即 Function/E2E Coverage，这个是第二个难点。最后一个难点是功能和系统限制，即 Function/System Limitation。它的核心是如何通过分析验收条件，业务流程，技术架构等信息，发现某个功能或者系统级别的限制，只要突破这个它们即开始在做探索性测试，它们也可以叫探索性测试用例。无论验收测试用例还是探索性测试用例，都可以使用各种基础的测试用例方法来分析和设计测试用例，比如等价类，因果图，错误推测法或者场景法等等。

对于测试用例本身，需要使用代码化的思维来进行编写，维护和管理，其目标就是易读，易维护，易执行和易管理。为了达到这个目标，还需要克服以下测试用例的难点：自然语言的多样性，数量大，且自动和手动难统一。大部分情况下的测试用例都会使用自然语言进行描述。而自然语言的多样性和歧义，可能会让用例设计和编写者以外的手动测试执行人员或者自动化测试开发人员产生误解，从而理解错测试用例，并得到错误的测试过程和结果。其次当测试用例的数量增大以后，比如几千上万的时候，维护和管理的问题也随之困难起来，其中还包括如何统一管理自动化测试和手动测试用例，从而减少对于重叠测试用例的维护和管理。为了解决这些问题，需要用多一些方法，其中包括使用代码式思维来编写测试用例，比如用 DSL 语言，测试步骤和测试数据分离等，其次还需要强大的测试用例管理系统等等。

3

测试用例编写与管理

编写和管理测试用例一直是一件十分繁琐又很难降低成本的工作，为了尽可能降低其成本，测试用例需要具有以下特性：易阅读，易维护，易执行，易管理。而难点也比较突出，其中包括语言的歧义性和多样性导致的不易阅读和理解；手动测试和自动化测试用例很难统一管理和统一执行；当测试数量很大的时候，如果测试用例管理系统不易用，测试用例的复用性也不高，则会导致测试用例不易维护，从而会极大的增加了其管理成本。所以测试用例的编写需要用到代码思维，比如高内聚，低耦合，易复用，清晰的模块划分等。再加上自动和手动测试用例的统一管理系统，则可以使测试管理更加容易。

3.1

测试用例编写

测试用例的表现形式直接影响了它的可读性，可维护性。因为一套不易读，冗长繁琐且没有统一规范的测试用例会直接导致测试用例难以阅读和维护；其次还会直接影响到测试执行和结果的正确性。下面总结了三种经典的测试用例编写方法。但是由于不同的团队和不同的项目情况不同，所以没有一种最佳方法适合于所有团队。测试用例编写人员需要根据自己团队和项目的特点和情况，选择适合并且实用的测试用例编写方法，从而更好的维护和执行测试。

方法一 ：操作和执行步骤

这是一种常规的测试用例编写方法，通过描述操作和执行系统的步骤来描述测试用例。其优点是非常直观，而缺点是过于繁复。如果操作和执行步骤经常更改的情况下，其维护成本就非常高。所以它适合一些比较稳定，业务需求和执行步骤变更较少的项目。下面是两个实例，展示了两个申请新用户的用例。实例：

用例1: 申请一个新账号成功  Given <理查德>准备申请一个新的账号  When  打开“注册”页面并点击“下一步”  Then  “用户信息”页面成功打开  When  完成填写“用户信息”页面并点击“下一步”  Then  “审核”页面成功打开  When  用户信息审核完成并点击“下一步”  Then  “申请<成功>”页面成功打开
用例2: 申请一个新账号失败  Given <尼奥>准备申请一个新的账号  When  打开“注册”页面并点击“下一步”  Then  “用户信息”页面成功打开  When  完成填写“用户信息”页面并点击“下一步”\  Then  “审核”页面成功打开  When  用户信息审核完成并点击“下一步”  Then  “申请<失败>”页面成功打开

方法二：系统或者用户行为

在行为驱动开发（BDD）出现后，越来越多的测试用例通过系统行为来编写。其优点是相对于方法一，它非常简练。所以在修改和维护时成本较低。但是它有一个前提，就是测试执行人员必须了解功能细节的前提下，才能通过行为描述来进行测试。所以这种方法写出的测试用例多数用于自动化测试。下面是将方法一种的两个实例通过行为驱动开发重写后的实例。实例：

用例1: 申请一个新账号成功  Given <理查德> 准备申请一个新的账号  When  完成新账号申请流程  Then  新账号创建<成功>
用例2: 申请一个新账号失败  Given <尼奥> 准备申请一个新的账号  When  完成新账号申请流程  Then  新账号创建<失败>

方法三：用代码思维编写测试用例

方法一和方法二都存在不同程度的重复，不易复用。所以改善或者解决这两个问题，从而进一步增强测试用例的可维护性，降低新增用例和维护已有用例的成本，需要使用代码思维来进行测试用例编写。其核心是尽可能抽象出通用的操作步骤或者系统行为的领域特定语言（DSL），然后通过参数化的方式来进行测试数据传递，从而复用领域特定语言。下面是通过本方法重写方法一和方法二后的实例，它主要体现了众多代码思维中的其中一种，即逻辑与数据分离。

步骤实例：

用例集1: 申请一个新账号  Given <用户>准备申请一个新的账号  When  打开“注册”页面并点击“下一步”   Then  “用户信息”页面成功打开  When  完成填写“用户信息”页面并点击“下一步”  Then  “审核”页面成功打开  When  用户信息审核完成并点击“下一步”  Then  “申请<结果>”页面成功打开数据集:  | 用户   | 结果  | 描述         |  | 理查德 | 成功  | 他是一名管理员 |  | 尼奥   | 失败  | 他是一名黑客  |

行为实例：

用例集2: 申请一个新账号  Given <用户> 准备申请一个新的账号  When  完成新账号申请流程  Then  新账号创建<结果>数据集:  | 用户    | 结果  | 描述         |  | 理查德  | 成功  | 他是一名管理员 |  | 尼奥    | 失败  | 他是一名黑客  |

3.2

测试用例管理

测试用例管理是一项繁琐的工作，现在业界存在四种经典方法，分别是文件管理，系统管理，代码活文档和系统活文档。与编写用例一样，没有一种用例管理方法是银弹，适合所有不同的团队和不同的项目。所以了解它们的特点，再根据自己团队和项目的实际情况，选择适合的才是最佳实践。

方法一 ：文件管理，如 Excel，MindMap 等

本方法是中小型项目中比较常见的测试用例管理方法。其优势是简单易用，而劣势是需要自己对测试用例模版进行定制，并且当测试用例过多的时候管理成本会急剧增加。其次对于本地文件模式，则很难让多人进行协作编写，但是 Google Sheets 这种在线文档没有这个问题。下面是一个 Excel 实例。

Excel 管理实例图：

方法二：系统管理，比如 TestLink，Zephyr 等

本方法一般是中大型项目中最为常用的管理方法。它的优势是管理系统提供了强大的管理和协作功能，比如协作编写用例，协作执行用例，测试步骤管理，截图管理，测试迭代管理以及丰富的测试用例和测试结果报表等。所以它有一定的学习曲线，并且基本上都是界面操作，相对比较繁琐，有些修改很难跟踪，比如测试步骤和测试数据的更改等。其次这种系统一般需要一个独立服务器来部署和运行，如 TestLink；或者需要花钱购买 License，如 Zephyr。所以相对成本比较高。下面两张图是 Zephyr 最为典型的支持执行管理和用例管理的界面。

Zephyr 执行管理实例图 1：

Zephyr 用例管理实例图 2：

方法三：代码活文档，自动化测试框架和代码版本工具，比如 Cucumber，RF，SVN 和 GIT 等

本方法适合于有足够软件技术工程实践的团队和个人，因为它需要使用到代码版本管理工具，集成开发环境（IDE），自动化测试框架，持续流水线等实践才能高效的编写，维护，执行，管理测试用例，测试日志和测试结果。本方法的优势是可以同时管理自动化测试用例和手动测试用例，并且更容易跟踪测试用例和测试数据的更改。而劣势是需要测试工程师有足够的工程技术能力来实现。下面是用 Cucumber 写的一个 Demo 的截图，左边是集成开发环境中测试用例的管理文件，每个 Feature 文件就是一套测试用例。而右图是通过 Jenkins 生成的测试用例活文档（Test Scenario Living Documentation），通过它可以统一的展示出手动测试用例和自动化测试用例的测试结果。

Cucumber 测试用例管理和活文档示例图:

Cucumber 活文档示例图:

方法四：系统活文档，方法二结合方法三

本方法是将代码活文档和系统管理结合，通过测试管理系统编写和管理测试用例，然后会自动生成代码模式的测试用例。也可以只编写代码模式的测试用例，然后自动同步到测试管理文档中。自动化测试在持续集成流水线执行，通过流水线进行展示并同步到测试管理系统中。手动测试人员执行了手动测试后，将测试结果通过测试管理系统或者在测试代码中进行记录，并最终汇总到测试管理系统的进行统一展示，从而实现了让不同人员可以一起协作分析，设计，管理，和执行测试用例的工作。下面是本方法的架构设计图。

系统活文档架构图 1:

系统活文档架构图 2:

4

总结

测试用例是测试工作的根本，不管是手动测试还是自动化测试的成功，都十分依赖于测试用例的质量。但是只有充分的做好测试分析，设计，编写和管理才能产出一套合格甚至优秀的测试用例套件。从保证测试工作可以高效正确的进行，为产出高质量软件保驾护航。