测试用例是怎么管理的

测试用例的管理方法：1、使用如Excel，Word，Mindmap等文件管理；2、使用itest，TestLink等系统管理；3、使用Cucumber，RF，SVN和GIT等代码活文档、自动化测试框架和代码版本工具。使用如Excel，Word，Mindmap等文件管理是指使用这些软件进行测试用例管理。

一、测试用例的管理方法

1、使用如Excel，Word，Mindmap等文件管理

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

2、使用itest，TestLink等系统管理

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

3、使用Cucumber，RF，SVN和GIT等代码活文档、自动化测试框架和代码版本工具

本方法适合于有足够软件技术工程实践的团队和个人，因为它需要使用到代码版本管理工具，集成开发环境（IDE），自动化测试框架，持续流水线等实践才能高效的编写，维护，执行，管理测试用例，测试日志和测试结果。

本方法的优势是可以同时管理自动化测试用例和手动测试用例，并且更容易跟踪测试用例和测试数据的更改。而劣势是需要测试工程师有足够的工程技术能力来实现。下面是用Cucumber写的一个Demo的截图，左边是集成开发环境中测试用例的管理文件，每个Feature文件就是一套测试用例。而右图是通过Jenkins生成的测试用例活文档（Test Case Living Document），通过它可以统一的展示出手动测试用例和自动化测试用例的测试结果。

4、使用系统活文档

本方法是将代码活文档和系统管理结合，通过测试管理系统编写和管理测试用例，然后会自动生成代码模式的测试用例。也可以只编写代码模式的测试用例，然后自动同步到测试管理文档中。自动化测试在持续集成流水线执行，通过流水线进行展示并同步到测试管理系统中。

手动测试人员执行了手动测试后，将测试结果通过测试管理系统或者在测试代码中进行记录，并最终汇总到测试管理系统的进行统一展示，从而实现了让不同人员可以一起协作分析，设计，管理，和执行测试用例的工作。下面是本方法的架构设计图。

二、测试用例简介

测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

测试用例主要包含四个内容：用例标题，前置条件，测试步骤和预期结果。用例标题主要描述测试某项功能；前置条件是指用例标题需要满足该条件；测试步骤主要描述用例的操作步骤；预期结果指的是符合预期（开发规格书、需求文档、用户需求等）需求。很多人都以为测试用例包含实际结果，其实是错误的想法。测试用例不包含实际结果，测试用例产生于测试之前，只有测试时，才会有实际结果，所以实际结果是不可能与测试用例同步产生。实际结果存在于BUG文档，BUG文档是根据测试用例测试完后生成的报告文档。

三、测试用例编写要求

1、用例名称

• 常用的结构“主、谓、宾”。
• 名称简洁易懂，不要包括具体操作步骤。

2、前置条件

• 执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件。
• 不可将其他用例作为前置条件，前置条件需要语言描述。
• 完整清楚，包括入口、帐号类型、账号权限、数据准备等。

3、操作步骤

• 操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚。
• 操作和结果是一一对应的，但操作中不要包含结果的检查。
• 用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）。
• 用例描述中不允许出现假设性词汇，比如：假如，或许，可能。
• 用例描述中不允许出现二义性语句。

4、预期结果

• 原则上每个用例必需要有预期结果，结果不能为空。
• 结果中只能包含结果，不能有步骤。
• 一个结果有多个检查点时，确保检查点完整：

5、测试用例编号规则

• 目的：好的测试用例编号，可以更好的去了解此项用例所针对的模块，也有助于记忆和新用例的增加。
• 规则：测试用例编号采用“版本+细类+编号”的形式。
• 备注：其中“版本”为设计此测试用例的软件版本。
• “细类”为小模块中的汉字头一个字母，以非常多5个字母为标准。
• “编号”为BUG用例的编号，以4位为标准，依次递增。
• 例如：引导系统V2.01版本中，候车点设置，用例编号可以书写为：2.01_HCDSZ_0001。

延伸阅读

测试用例的设计原则

测试用例设计一般遵循以下原则：

• 正确性：输入用户实际数据以验证系统是否满足需求规格说明书的要求;测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
• 全面性：覆盖所有的需求功能项;设计的用例除对测试点本身的测试外，还需考虑用户实际使用的情况、与其他部分关联使用的情况、非正常情况(不合理、非法、越界以及极限输入数据)操作和环境设置等。
• 连贯性：用例组织有条理、主次分明，尤其体现 在业务测试用例上;用例执行粒度尽量保持每个用例都有测点，不能同时覆盖很多功能点，否则执行起来牵连太大，所以每个用例间保持连贯性很重要。
• 可判定性：测试执行结果的正确性是可判定的，每一个测试用例都有相应的期望结果。