一、概述

1.1编写目的

1. 统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。
2. 测试用例不仅仅用于组内QA阅读和执行，它们也可能会被Dev、PM等阅读审查或执行，更可能被其他测试人员或者新员工作为业务学习、测试执行的参照。

1.2使用范围

1. 适用于对产品的业务流程、功能测试用例的编写。

1.3约定

1. 测试用例采用思维导图方式进行展示，产出结果为XMind文件。
2. 思维导图首级子节点为各个需求点，末级子节点为简要归纳的测试点。
3. 修改测试用例内容后需及时通知本业务线人员及其他利益相关方。

二、测试用例编写原则

2.1系统性

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

2.2连贯性

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

2.3全面性

1. 应尽可能覆盖程序的各种路径
2. 应尽可能覆盖系统的各个业务
3. 应考虑存在跨年、跨月的数据
4. 大量数据并发测试的准备
5. 系统中各功能、业务的异常情况

2.4正确性

1. 输入用户实际数据以验证系统是否满足需求说明书的需求。
2. 测试用例中的测试点应保证至少覆盖需求规格说明书中的各项功能。

2.5符合正常业务惯例

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

2.6健壮性

1. 程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。

三、测试用例编写规范

3.1.功能检查

• 功能是否齐全，例如：增加、删除、修改，查询条件是否合理，用户使用是否方便
• 软件流程与实际业务流程是否一致
• 软件流程能否顺利完成
• 各个操作之间的逻辑关系是否清晰
• 各个流程数据传递是否正确
• 模块功能是否与需求分析及概要设计相符

例1：“场景添加广告单元”功能中，需要考虑针对于广告单元的增、删、改、查操作时软件的业务处理流程

image

例2：“新增认证中心”功能中，需要规划梳理可能会涉及到的软件流程及预期结果，用于与实际业务做比对

image

---

3.2.数据处理

3.2.1 输入数据

• 边界值
• 大于边界值
• 小于边界值
• 最大个数
• 最大个数加 1
• 最小个数
• 最小个数减 1
• 空值、空表
• 极限值
• 0 值
• 负数
• 非法字符
• 日期、时间控制
• 跨年度数据
• 数据格式
• 数据之间的关联性、逻辑性，数据范围、格式限制是否合乎日常情理，如年龄不应为负数，身份证位数必须为15或18位且与性别严格相关联，与生日可以有区别（考虑到阴历阳历的问题）但不相同时给予提示，私人电话号码的长度且国内电话只能有数字及短横线标识区号等

例3：对输入框形式的组件，需要考虑其数据长度、有效性等。

image

---

3.2.2 数据处理

• 处理速度
• 处理能力
• 数据处理正确率
• 计算方式及计算结果准确性，数字精度的取舍问题，汇总数据与分项数据累加的误差问题

例4：“客户管理”需求中，对上传文件操作考虑服务器性能问题，对文件大小做限制

image

3.2.3 输出结果

• 正确率
• 输出格式
• 预期结果
• 实际结果，金额数字的可能要验证小写大写的一致性，大写可能要测试多种金额的大写，包括没有整数的情况下，没有小数的情况下，带整数和小数的情况下

例5：“WAP页小额支付”功能中，需要做充值额度、秀点记录、订单记录等一系列相关数据的正确性校验

image

3.2.4 软件流程测试

• 反流程操作
• 重复操作
• 违反流程的打乱流程的不按操作手册的乱操作

例6：“提现改版”需求中，需要对不同用户、不同认证状态、不同操作顺序等全部状态综合考虑其业务场景，保障功能的健壮性。

image

3.3其他

1. （推荐）测试文档中标明本期工作相关内容，包括优先级、任务进度、任务排期等

   
   image

2. Sprint结束后可在测试文档中记录本期遗留的重大问题