业务测试案例编写

概述

测试用例是有效进行测试工作的基础，也是提高测试效率，开发测试脚本的前提。

目的

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

测试用例原则

3.1 系统性

1) 对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；

2) 对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系。3.2 连贯性

1) 对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确；

2) 对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；

3.3 全面性

1) 应尽可能覆盖程序的各种路径；2) 应尽可能覆盖系统的各个业务；3) 应考虑存在跨年、跨月的数据；4) 大量数据并发测试的准备。3.4 正确性

1) 输入界面后的数据应与测试文档所记录的数据一致；2) 预期结果应与测试数据发生的业务吻合。3.5 符合正常业务惯例

1) 测试数据应符合用户实际工作业务流程；2) 兼顾各种业务变化的可能；

3) 要符合当前业务行业法律，法规。3.6 仿真性

人名、证件号码、地名、电话号码等应具有模拟功能，符合一般的命名惯例或规则。3.7 可操作性

测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果。

测试用例主要元素

测试用例包含主要元素如下：用例标题：用例的名称；

创建日期：测试用例创建时间；设计人员：测试用例设计人员；用例状态：测试用例状态；

前置条件：用例执行前需要预先做的配置和设置，以及需要具备的执行条件；

操作步骤：执行用例的详细操作步骤；

预期结果：按操作步骤执行后预期系统的执行结果。

测试用例编写规范

5.1测试用例命名规则

由于项目的实际需求和测试的工作需要，分以下几个等级来规范测试用例的命名：

1) 一级目录使用各项目的顶级菜单名称来命名，如维护、业务、查询三大类；

2) 二级目录使用顶级菜单下的二级菜单名称类命名，用户可根据名字判别该用例是测试哪个模块的；

3) 各用例根据各用例的功能来命名，尽量做到简洁明了。5.2测试用例编写方法

测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；

基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：

1) 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常；

2) 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理；

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

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

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

6) 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取；

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

8) 错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现

错误之处；

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

10) 界面友好性：理解和使用该系统的难易程度；

11) 兼容性：在不同操作系统及硬件配置情况下的运行性；

12) 性能测试：满足系统多用户并发运行时，系统压力、负载情况以及稳定性。

对于每个测试项目测试的测试用例不是一成不变的，随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时，可以不断的补充完善测试项目的测试用例。