7.8 用例编写要求

测试用例是为实施测试而向被测试系统提供的输入数据、操作、各种环境设置以及预期结果的集合。在实际测试中，文档化的测试用例是执行测试过程中必备的工作内容。

测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要严格按用例项目和测试步骤逐一执行，并将测试结果记录在测试用例管理软件中，以便自动生成测试结果文档。

每个测试用例的测试等级，集成测试、系统测试和回归测试该测试哪些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

编写的测试用例，要具有代表性，测试结果要具有可判定性和可再现性。步骤要完整清晰无二义性，最通俗的判定标准是：让一个不熟悉功能需求的人，按照测试用例执行，仍然能够顺畅的实现测试，那就是测试用例编写得通俗易懂，是合格的。

7.8.1 格式

测试用例通常用Excel表格的形式书写存放。各个公司可能对于格式都有自己的要求和增删。

举例：

• 编号：是由字母和数字组合成的字符串，用例编号应具有唯一性、易识别性。
  规则：产品编号-测试阶段（ST，IT，UT）-测试项名-测试子项名-XXX。

• 测试项：指明要测试的内容，如所属测试大类、被测需求、被测模块、被测单元等。
  规则：

  系统测试阶段：软件需求项。  
  集成测试阶段：集成后的模块名或接口名。  
  单元测试阶段：被测试的函数名。
  

• 标题：测试用例的简单描述，需要用概括的语言描述该用例的出发点和关注点，原则上每个用例的标题不能重复。

  出发点不同：

  关注点不同：

  条件不同：

• 重要级别：根据需求确定的此用例重要程度。一般情况下，重要级别为高的测试用例，一个测试子项里有且仅有一个，大多数都是重要级别为中的测试用例。因为在测试开始前，会进行冒烟测试，如果重要级别为高的太多，就失去了冒烟测试的实际意义。
  规则：
  高：保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例。
  中：重要程度介于高和低之间的测试用例。
  低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。

• 预置条件：执行当前测试用例需要的前提条件，如果这些前提条件不满足，则后面的测试步骤无法进行或者无法得到预期结果。

• 操作步骤：执行当前测试用例需要经过的操作步骤，需要明确的给出每一个步骤的描述，测试用例执行人员可以根据该操作步骤完成测试用例执行。

• 输入数据：描述测试用例所需的测试数据或输入条件，根据软件测试用例的具体情况，有手工输入、文件、数据库记录等。

• 预期结果：描述输入数据后程序应该输出的结果。包括返回值的内容、界面的响应结果、输出结果的规则符合度以及数据库中的记录等，用来与实际结果比较，如果相同则该测试用例通过，否则该测试用例失败。

对于一些项目，可能在用例执行时，直接把测试结果写在之后，所以在执行时，还可以有下面的一些项：

• 实际结果：用例执行时实际执行的结果。如果与预期结果相同，写OK即可；如果不相同，写实际执行的结果。
• 测试人：执行此次测试的人员。
• 测试日期：执行此次测试的时间。
• 备注：测试结果的其他附加信息。

7.8.2 用例更新与维护

用例编写完成后，并不是就一成不变了。根据需求的变动，完善以及其他原因，可能会增加用例，删除用例或者修改用例。测试用例要经过正式、有效的评审，并利用工具来维护。做好用例的维护，在监控和总结阶段，用例相关的数据也是重要的过程体现数据。

7.8.3 用例评审检查规则

• 测试用例标识是否按照测试方案的规则来编写。

• 是否每个测试用例的预置条件都被描述清楚。

• 每个测试用例的测试步骤和输入数据中是否列出了所有必要的步骤和数据。

• 测试用例的预期结果是否完整而且清晰。

• 是否明确说明了每个测试用例或测试用例集的重要级别。

• 是否明确说明了测试用例的执行顺序。

7.8.4 练习

1.OA用户注册、登录功能测试用例编写，并评审。

2.车辆管理各模块功能测试用例编写，并评审。

3.其他用例编写方法的测试用例编写，并评审。