在软件的整个生命周期中，软件测试是一个重要环节，软件测试用例是软件测试的基础，也是测试工作的指导，所以做好软件测试用例管理尤为重要。我们软件测试中心专家从软件测试用例管理、用例设计、用例执行、用例任务管理、用例维护和人员以及权限管理等方面进行详细阐述，提升测试用例设计、使用、共享、追溯以及管理的效率，缩短测试周期，降低测试成本。
1 软件测试用例管理
软件测试用例管理包括目录创建、测试用例创建、引用、复制、导入、导出和统计等功能。
1.1 目录和测试用例创建
软件测试用例基于某个产品的某个功能进行设计。结合软件开发的流程，产品经过多次迭代版本的开发、测试才能进行发布，软件测试用例会在不同的迭代版本中重复执行。因此，测试用例按照表1 所示的层级进行管理。
第一级目录为产品名称，一个公司或者单位可能开发多个产品，因此可能存在多个一级目录。第二级目录为大版本，即对外发布版本。第三级目录为基线库和小版本，基线库目录下的用例为该大版本发布后最新的用例，该目录中的用例在测试过程中实时更新测试用例内容和测试结果；小版本中的测试用例为大版本迭代过程中的版本，测试执行也是基于小版本进行，测试过程中若发现测试用例存在问题可进行修改，修改的用例自动回合到基线库中。第四、五级目录为产品的功能以及子功能，对功能继续详细划分。第六级目录为测试用例。
其中，第一级到第四级，若单位有版本配置管理部分，可配置后在此处自动显示，保证数据源唯一；若没有版本配置管理部分，系统名称目录下支持创建目录或者用例，同一级目录名称不允许重复。
1.2 软件测试用例引用
支持不同产品和同一产品不同大版本、不同小版本、同一大版本基线库到小版本之间测试用例的引用，测试用例引用只引用用例内容，不引用用例的测试结果，引用后的用例编号不发生变化。
不同产品和同一产品不同大版本、不同小版本间引用的用例单独存储，也就是引用后用例变成一个单独的个体，与原用例不存在关联关系。同一大版本基线库到小版本之间测试用例的引用，小版本中的测试用例内容发生变化，基线库中用例随之变化，保证基线库中的用例为当前大版本下最新的测试用例。其他小版本可继续在基线库中引用最新的测试用例。
测试用例引用功能在测试执行过程中，方便测试管理人员管理测试用例，使不同版本间测试用例清晰，同时，保证各版本以及发布版本用例的可追溯性。
1.3 复制
支持对用例或者目录进行复制，复制后的用例编号根据一定的规则发生变化。该场景在用例设计过程中，用例内容大部分相同、少部分内容不同时，可进行用例的复制，复制后对用例不同之处进行修改即可，大大提升测试用例设计人员编写测试用例的效率。
1.4 导入
Excel清晰分级、快速填充序列和复制等功能在编写测试用例时，为测试用例设计人员提供极大的方便。为将Excel中测试用例存储在测试用例管理系统中，测试用例管理应支持按照Excel格式进行用例导入，以及全量、增量和修改导入。要求用例编号作为唯一的标识，已执行过的测试记录不能修改，当前执行结果可清空。导入的模板应该预置在测试用例管理中，与导出功能的文件格式和标题内容保持一致。
1.5 导出
软件测试用例支持导出Excel 和Word 两种格式，Excel 格式便于批量修改测试用例后进行导入，Word 格式便于试验大纲编制使用。Word 格式导出时可选择带执行结果和不带执行结果导出，不带执行结果导出时，测试结果列将为空。
1.6 统计
支持右键按照用例目录中的文件夹进行执行情况统计，同时支持表格显示统计结果，包括各子文件夹中以及总的用例个数、已执行个数、执行通过个数、执行不通过个数和阻塞个数等，方便测试管理人员进行任务跟踪和统计。
1.7 删除
支持用例单个或者批量删除，目录删除后，目录下的所有测试用例均被删除。
2 软件测试用例设计
软件测试用例至少应该包括以下元素，即用例编号、系统/ 功能名称、用例属性、用例级别、是否可自动化、用例描述、前置条件、测试步骤及系统响应、测试结果、设计者、执行者、执行时间和附图等，具体内容如下。
（1）用例编号。在某一产品中为唯一标识，按照一定规律进行编号，如产品名称、大版本名称、系统/ 功能名称、子功能名称、序号。用例编号用于测试用例的回合、修改、导入等功能，通过测试用例编号进行用例的唯一标识和操作。
（2）系统/ 功能名称。指该用例所属的系统或者功能名称，用于对用例进行分类，方便后续进行搜索、统计等管理，建议前期将系统/ 功能名称预置到测试用例系统中或者Excel 的下拉列表中，供测试用例设计人员进行选择。
（3）用例属性。指该测试用例属于具体类型的测试用例，如功能测试、性能测试、安全测试、接口测试、可靠性测试等，建议前期将用例属性预置到测试用例管理系统中或者Excel的下拉列表中，供测试用例设计人员进行选择。
（4）用例级别。至少包括3 个级别，分别代表测试用例待测试的重要和紧急程度，第一级别用例也可称为冒泡用例，代表交付版本的最基本功能。版本交付给测试人员后，首先，进行第一级别用例测试，若第一级别用例测试通过，版本可进行全面测试，否则，版本打回，待最基本功能修复正常后重新交付给测试人员。其次，第二级别用例是指除冒泡用例之外的基本功能用例，该级别用例在版本发布前，必须进行全量测试。最后，第三级别用例异常用例，也就是针对测试功能中的异常场景测试的用例，该级别用例正常情况下只测试一次即可。
（5）是否可自动化。用于标识测试用例是否可通过自动化进行验证，建议有两个选项，即“是”或者“否”，“是”表示该测试用例可通过自动化进行测试，“否”表示该测试用例只能通过手工进行测试。
（6）用例描述。描述用例主要测试的内容以及预期结果，要求简单明了，能一目了然地识别测试内容和期望结果。
（7）前置条件。测试前的准备条件或需要满足的条件。
（8）测试步骤及系统响应。测试步骤体是测试过程中需要执行的步骤或者操作，要求尽可能描述详细，保证测试人员可执行性；系统响应是指每一步操作系统应该如何响应，如应该显示一个怎样的画面。
（9）测试结果。测试结果表示测试用例的测试情况，包括通过、不通过和阻塞。测试的结果与系统响应一致时，测试结果为通过；测试的结果与系统响应不一致时，测试结果为不通过；还有一部分测试用例可能由于其他系统原因或者其他功能存在问题导致该用例无法测试，这部分测试用例的测试结果为阻塞。分析测试用例结论时，可通过测试用例的结果统计该版本不通过用例的数量，便于测试管理人员制定下一个版本测试策略或者做出关于版本是否可发布上网的结论。
（10）设计者。设计测试用例人员，如果是在系统中进行用例的设计，那么可直接使用登录账户自动填写。
（11）执行者。执行测试用例人员，标注测试用例结果时，可直接使用登录账户自动化填写。
（12）执行时间。本次测试用例执行时间，在标注执行结果时自动填写。
（13）附图。在系统响应中，有些预期结果无法准确描述，需要利用图示进行说明，故此测试用例管理系统需要支持上传图片。
3 软件测试用例执行
3.1 软件测试用例手工执行
软件测试用例执行包括单个执行和批量执行两种方式。
（1）单个执行。选择树型结构中的用例，右键可标注用例结果为通过、不通过和阻塞。
（2）批量执行。选择树型结构中的目录，右键可标注该目录下所有用例的结果。
3.2 软件测试用例自动化执行
支持使用不同插件进行测试用例自动化开发以及测试结果的自动标注。自动化标注的测试用例结果建议增加标识，表示该执行结果通过自动化执行。
3.3 执行日志记录
每个版本中，记录测试用例执行日志，包括测试时间（精确到秒）、执行方式（手动执行、自动化执行）、执行结果和执行人，有助于用例后续追溯使用或者统计使用。
最后软件测试用例执行数据都要体现到《软件测试报告》文档中，比如测试用例通过率、未通过用例、阻塞用例，软件测试用例的执行情况也是整个《软件测试报告》的精华所在。可参考：《如何正确解读和应用软件测试报告中的数据》
4 软件测试用例任务管理
任务管理需要支持任务创建、任务信息显示、用例执行以及执行结果统计。
（1）任务创建。支持右键基于试验版本信息测试任务的创建，输入任务名称，选择责任人，选择该版本下的用例，且同一用例不能重复分配。
（2）任务信息显示。树型结构中显示该任务下的用例信息，右侧显示任务详细信息或者用例详细信息。
（3）用例执行。支持可按照任务方式进行自动化用例执行和手工用例执行。
（4）执行结果统计。以任务为基准，统计结果内容包括各任务下的用例个数、已执行个数、执行通过个数、执行不通过个数、阻塞个数、未执行个数和执行进展（已执行个数/ 用例个数）。
5 软件测试用例维护
软件迭代过程中，测试用例需要不断刷新和维护。
针对小的变更，在版本交付过程中，应对测试用例进行维护修改；
针对需求变更或者新增，应及时增加和删除测试用例；
版本发布后，根据用户反馈的缺陷，应及时分析并补充测试用例。因此，测试用例维护是比较重要的过程，应及时删除过时、冗余的用例，刷新需变更的用例，及时补充新需求用例。
6 软件测试人员及权限管理
（1）测试人员管理。支持用户的登录、创建、修改和删除，默认有一个管理员账户；支持用户与权限的关联，用例只能按照指定操作的权限进行操作或者显示。
（2）权限管理。支持权限创建、修改和删除，各功能应具有自己的权限项，针对不同人员，通过分配相应的权限对用例的操作进行控制。
软件测试用例是测试人员最基本的操作依据，软件测试用例合理的管理，对软件测试的质量和测试人员的工作效率会有较大的提升。本文结合软件开发和测试的工作经验，详细分析了测试用例管理应具备的功能，将这些功能完全应用到软件测试过程中，使整个验证过程更清晰，管理效率更高，追溯性更强。