测试人员测试用例设计编写规范

测试用例设计编写规范

一： 用例设计依据 ：

1 需求说明书

2 项目测试需求功能点

3 测试工程师本人的理解程度（个人经验）

二： 用例内容：

1 用例编号： 唯一标识，与需求编号对应，为多对一关系 

2 模块名称

3 子模块名称

4 用例标题： 对测试项简短的描述

5 用例级别： 确定用例执行的级别

6 前提条件： 执行用例时需要的预置条件 

7 操作步骤： 执行该动作需要完成的操作 

8 预期结果： 执行完该动作后程序的表现结果 

9 实际结果： 实际输出的结果

10 问题描述： 执行该用例出现后系统显示的错误 

11 验证结果： 该测试用例是否执行通过

12 用例转bug： 用例执行不通过的转为bug

13 测试执行者：按照该用例执行测试的人员 

三： 编写用例原则：

1 系统性。对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系 

2 连贯性。对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯 

3 全面性。应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备

4 正确性。输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合

5 符合正常业务规则。测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规

6 可操作性。测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果

四： 用例的维护 ：

1 修改的测试用例
随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并在备注栏中加以说明

2 删除冗余的测试用例
如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个

3 增添新的测试用例
对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明

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

• 1.正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
  2
  容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出；输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。

  2.容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出；输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。

  3.完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。

  4.接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。

  5.数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。

  6.边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），主要输入一些合法数据/非法数据，主要在边界值附近选取。

  7.压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行，进行测试。

  8.等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。

  9.错误推测：异常场景、异常操作等。

  10 效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。

  11 可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。

  12 可移植性：在不同操作系统及硬件配置情况下的运行性。

  13 回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题以提交至开发人员。

  14 比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较。

  15
  兼容性测试：操作系统的兼容性测试内容不仅包括软件的安装，还需对关键流程和功能点进行检查。而需要测试哪些操作系统的兼容性，首先取决于软件用户文档上对用户的承诺，其次就需要对一些常用操作系统兼容的检查

  16 历史版本兼容性测试：某些功能存在新版本和历史版本数据显示、页面展示不一致的问题。需要不同版本进行测试。

六：用例评审 ：

• 参与人员：产品经理、研发人员、UI/UE设计人员、测试人员；

  1 用例设计的结构安排是否清晰合理，是否高效的需求进行覆盖  用例的优先级别是否安排合理

  2 是否覆盖了测试需求的所有功能点，包括需求中的业务规则、所有用户可能使用的流程或场景等

  3 用例是否有很好的可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确