1 目的

统一用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性、可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。

2 用途

适用于对各业务线测试人员对功能测试用例和接口测试用例的编写。

3 用例设计流程

测试分析：进行测试用例编写的前提。测试人员根据产品组提供的磨刀原型、teambition迭代需求、相关需求文档进行测试需求分析，找出明显的和隐含的需求。分析需求时应考虑前端-Web、前端-H5、后端、设备端需求是否完善。

测试设计：依据测试分析整理并编写出测试用例大纲，并将测试大纲细化为测试用例。测试用例大纲用脑图的形式进行管理，在时间受限的情况下，可本地草稿简单整理记录个编写大纲思路（这个过程可能经常会与产品、相关开发人员讨论确定需求）；最终根据整理后的大纲在metersphere上进行测试用例编写。

测试用例完善：测试用例在metersphere上编写完成之后，建立用例评审并指派给产品经理进行评审（时间允许的情况下，用例评审参加的人员应还包括测试人员、项目经理、开发人员），根据评审结果作相应完善；软件产品新增功能或更新需求后，测试用例必须定期修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；产品上线后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。

4 规范要求

4.1 测试用例整体要求

? 测试用例编写应严格根据磨刀原型、teambition迭代需求、相关需求文档分析点进行，要求覆盖全部需求功能点。（因测试人员有限，存在紧急发版需求或临时新增需求时，可根据实际情况确定是否优先编写测试用例，或者是等发版后补充）

? 测试用例编写应该制订统一的模板进行，并约定模板的使用方法，当前直接使用metersphere平台的用例模板。

? 测试用例中要写清楚测试的操作步骤和预期结果，能被不同测试人员理解和执行。

? 测试用例中要明确一级模块、二级模块和三级功能。

? 同一个功能点的测试用例，移动端和PC端需要单独编写，因为它们的界面和操作不同。

? 对于每个功能点，必须通过一组（一个或多个）用例满足其业务覆盖：对于某条记录的每个状态，对于能进行的每个操作，都生成一个用例（即对业务功能流程中的每个角色，每个功能操作，生成一个用例）。

? 界面显示、错误信息提示、用户界面友好性等界面相关检查暂不作为主要测试范围（觉得不合理的还是要提），由产品经理和前端（或UI）负责验收。

? 注重测试用例的可复用性，即在以后相似系统的测试过程中可以重复使用。

? 测试用例编写和评审都直接在metersphere上，可以实时反馈修改。

4.2 测试用例组成部分

一般的测试用例包括如下组成部分：用例名称、所属模块、状态、标签、责任人、用例等级、关联测试、关联需求、前置条件、步骤描述、预期结果、评审结果。

用例名称：能够清晰表达测试用例的测试目的和关键测试要素；
（如：验证XXX页面展示是否正常；验证XXX功能是否正常）

所属模块：标明用例所处的一级模块、二级模块或三级功能等，如果某个模块比较复杂，可能会有更多层级，每个层级会用斜杠分隔；
（如：/web端/设备管理）

状态：表明该用例状态（包括：未开始/进行中/已完成）；

标签：特别标注的用例分类点（可不填）；

责任人：测试用例的设计人员；

用例等级：区分测试用例的重要程度，确定用例执行的级别；
（功能测试用例等级可以都选P0）

关联测试：可关联相关的性能测试、场景测试、测试用例等（可不填）；

关联需求：可关联到相关的需求上，便于查找初始需求（可不填）；

前置条件：需要描述测试所需要处于的外部环境和测试前测试对象及辅助对象所需要处于的状态和配置。需要保证在完成预置条件中所描述的状态和配置以及外部环境后，测试执行的正确性、一致性；

步骤描述：为了达到测试用例的测试目的，所需要执行的操作；每个操作步骤对应一个预期结果；

预期结果：针对测试用例的测试目的，测试步骤中操作后对应的预期输出状态；

评审结果：展示该用例评审状态（包括：未评审/通过/未通过）。

4.3 测试用例实现规则

规则1：用例描述要求
每个用例必需要有至少一条操作步骤和预期结果；
操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；
操作步骤中不要包含结果的检查；
预期结果中只能包含结果，不能有步骤；
用例描述中不允许出现假设性词汇，比如：假如，或许，可能等；
用例描述中不允许出现二义性语句。

规则2：用例名称要求
用例名称以模块/页面/功能点去命名，命名格式：验证XXX是否正常；
用例名称不允许出现重复、包含关系，或者仅有数字编号差异；
用例名称简介易懂，不要包括具体操作步骤。

规则3：用例要素要求
用例名称、所属模块、状态、责任人、用例等级、前置条件、步骤描述、预期结果为必填内容，不能为空，其他字段为选填内容。

规则4：用例等级要求
由于User Story的优先级决定的是在一个版本中的开发优先级，用例的重要性参考的是模块对于系统功能的重要度，因此这里的重要性不以Use Story优先级为参考依据，这里当前所有功能测试用例等级默认都是P0。
P0：核心功能测试用例（冒烟测试），确定此版本是否可测，该用例执行失败会导致多个重要功能无法运行；
P1：高优先级测试用例，最常执行以保证整体功能稳定，包括基本功能测试以及重要的错误、边界测试（含UI部分、兼容性）；
P2：中优先级测试用例，更全面地验证功能的各个方面，包括异常测试、中断、断网等；
P3：低优先级测试用例，不常常被执行，比如性能、压力、兼容性等。）

规则5：前置条件要求
执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件；
前提条件包括测试执行入口、账号类型和权限、数据准备；
不可将其他用例作为前置条件，但可以将其它用例执行结果作为前置条件。

规则6：步骤描述要求
每一测试步骤对应一条预期结果；
每一条预期结果与其对应的测试步骤的编号要求保持一致；
一个结果有多个检查点时，确保检查点完整；
一个界面展示可做一个单独用例；
一个功能点可做一个单独用例；
（若同一个功能中预期结果相同时，可以考虑不同步骤合并在同一个步骤描述中；查询条件相关测试点，可考虑以每个输入框为一个步骤，此步骤描述包括多种情况）
不管以何种方式划分描述，用例及步骤必须覆盖所有的页面、功能点、以及业务场景。

规则7：预期结果要求
结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等；
结果涉及页面，需明确页面提示结果、数据变化；
结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化；
结果涉及消息：需明确关键查看内容；
结果对应不同输入数据有差别时需分别对应描述清晰；
结果要观察设备端响应是否正常。

规则8：测试数据要求
测试数据可在测试用例规定的范围内做一定变化；
需求涉及逻辑计算时，测试数据需要明确给出，编写形式为：[字段名：字段值]；
对于页面输入数据，需要区分必填项。

5 用例编写方法

测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面。

5.1 用例设计方法

1．正确性测试
输入用户实际数据以验证系统是满足需求相关文档的要求；测试用例中的测试点应首先保证要至少覆盖需求中的各项功能，并且正常。
2．容错性（健壮性）测试
程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
3．完整（安全）性测试
对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（或文件）的完整。
4．接口间测试
测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
5．数据库测试
依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
6．边界值分析法
确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
7．压力测试
输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行，进行测试。
8．等价划分
将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
9．错误推测
主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
10．效率
完成预定的功能，系统的运行时间（主要是针对数据库而言）。
11. 可理解（操作）性
理解和使用该系统的难易程度（界面友好性）。
12. 可移植性
在不同操作系统及硬件配置情况下的运行性。
13. 回归测试
按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员。
14. 比较测试
将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较。