前言
今天分享干货，软件测试用例的编写文档，看完我看还有谁不会写测试用例。需要完整文档笔记文末找我拿哦。
一 概述
1.1目的
统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。
1.2使用范围
适用于对产品的业务流程、功能测试用例的编写。
二 测试用例编写原则
2.1系统性
1、对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；
2、对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系；
2.2连贯性
1、对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确；
2、对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；
2.3全面性
1、应尽可能覆盖程序的各种路径
2、应尽可能覆盖系统的各个业务
3、应考虑存在跨年、跨月的数据
4、大量数据并发测试的准备
5、系统中各功能、业务的异常情况
三 测试用例设计方法
3.1 等价类划分法****：
将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
3.2 边界值分析法：
指对输入的边界条件进行分析，设计出针对边界值的测试用例。
3.3 因果图法：
就是利用图解法分析软件输入(原因)和输出条件(结果)之间的关系，以设计测试用例的方法。因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。
3.4功能图法
功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以看作是其状态不断发生变化的过程。测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。
3.5错误推测法
推测法主要依赖经验、直觉来作出简单的判断甚至是猜测，给出可能存在缺陷的条件、场景等，在找到缺陷后，设计出相应的测试用例。
四 测试用例编写规范
4.1测试用例命名规则
以功能模块和业务流程进行命名。
4.2测试用例编号规则
用例编号规则：以测试模块名称的第一个字母进行命名（大写），若测试模块名称比较长时，可进行简写。一般简拼不超过5个字母：如：
- 测试模块为“用户管理”，功能编号为“YHGL”；
- 测试模块为“行政单位管理”，功能编号为“DWGL”
- 功能编号规则直接以001、002、003…..
4.3测试用例文档书写内容
1、被测试对象的介绍
2、测试范围与目的
3、测试环境与测试辅助工具的描述
4、功能测试用例主要元素
- 前置/操作描述：
1、前置条件（可选）：系统权限配置或前、后台配置描述（所有进行操作的前提条件）。
2、操作：测试的操作步骤描述。
- 功能点： 功能点描述。
- 输入数据：前期数据准备。
- 预期结果：描述输入数据后程序应该输出的结果。
- 测试结果：描述本条用例的实际测试情况，并判断实际测试结果与预期结果的差别。
- **Bug编号/Bug简要描述:**需要进流程的对应事物流程的编号，及简要说明
- 备注：测试过程中遇到的问题等情况说明。
五 编写用例注意事项
5.1****功能检查
1 、功能是否齐全，例如：增加、删除、修改，查询条件是否合理，用户使用是否方便
2 、功能是否多余
3 、功能是否可以合并
4 、功能是否可以再细分
5 、软件流程与实际业务流程是否一致
6 、软件流程能否顺利完成
7 、各个操作之间的逻辑关系是否清晰
8 、各个流程数据传递是否正确
9 、模块功能是否与需求分析及概要设计相符
10、批量增加、批量修改，增加、修改等录入比较频繁的界面或录入数据量较多的界面，是否支持全键盘或全鼠标操作，并且使用通用的键实现数据字段的有序切换
**5.2 **面向用户的考虑
1 、操作方便性，如：按键次数是否最少，并不以开发实现技术限制为限制，而是以用户使用方便性和应用软件约定和通常的快捷键来实现提出合理建议
2 、易用性，面对用户的操作是否简单易学
3 、智能化考虑
4 、提示信息是否模糊不清或有误导作用。错误信息是否有用户语言风格的出错后续处理建议提示
5 、要求用户进行的操作是否多余，能否由系统替代。系统升级后，用户能否不做任何操作自动进行所有升级的数据、环境等准备工作，包括删除缓存等动作
6 、能否记忆操作的初始环境，无需用户每次都进行初始化设置
7 、是否不经确认就对系统或数据进行重大修改
总结
完整文档添加文章下方名片免费领取，还有各种简历面试及报告模板等你来拿。
 
版权归原作者 测试小婉 所有， 如有侵权，请联系我们删除。