测试用例规范
2022-07-13 15:03:26 8 举报AI智能生成
![[Model] 测试用例模板](https://www.processon.com/chart_image/template/thumb/60d93bd30e3e742d29d4c06a.png?tid=60d93bd30e3e742d29d4c069)
测试用例基础规范
作者其他创作
大纲/内容
本想继续总结写完，奈何精力实在有限。各位可在日常工作中自行总结
废弃
数据库测试用例
建模 - 输出业务/系统流程（分析：业务流程 - 系统流程）
设计 - 测试场景
细分 - 测试用例/数据（设计：测试用例）
扩展 - 多类型测试（性能、安全、异常等等） ：基于业务经验
分析与设计过程
第一步：根据业务的目标（价值）、类别、技术等输入，确定业务场景分析的范围
基本流程
场景拆分
正常数据、异常数据
破坏性数据
并发性数据
场景正向逆向分析
备选流程
事件流程
第二步：业务流程梳理（业务场景）
在有限的条件下，尽可能梳理多的场景流程，涵盖
梳理场景、流程
结合实际的需求场景、客户场景
整合场景、流程
回归场景、流程
第三步：场景串联
测试场景分析实施
多：针对测试用例进行大数据量覆盖测试
并：针对测试用例进行大数据量同时执行，验证并发下的测试结果
复：重复的参数对同一用例进行执行测试。验证幂等结果是否符合预期
异：用非正常输入值进行用例测试。验证结果的正确性
非功能性设计扩展
测试分析与设计
保证接口功能是正常的
流程通过性验证
场景
数据类型
参数长度
空参数、参数值为空
封装数据必填判断
参数组合*
入参
数据加密
绕过验证或者身份授权
安全
根据业务逻辑设计
模块
接口名称
这接口是用来干嘛的
用例标题
请求方式
请求url
请求参数
有依赖的时候
前置条件
结果验证预期结果
请求报文
返回报文
用例设计模板
接口测试用例
此项更多是与业务结合 产出的流程性用例
业务流程的复杂化 此项的维护成本会很高 故可做节点拆分
流程测试用例
指导测试工作有序进行，使测试的数据有据可依
确保所实现的功能与产品预期的需求相符合
跟踪测试进度，确定测试重点
评估测试结果的度量标准
分析缺陷的标准
用例的用途
等价类划分法
边界值分析法
错误推测法
判定表驱动法
正交试验设计法
场景图法
黑盒测试用例
代码检查法
静态结构分析法
静态质量度量法
逻辑覆盖法
基本路径覆盖测试法
域测试
符号测试
白盒测试用例
用例设计方法
1. 应尽可能覆盖程序的各种路径
2. 应考虑存在跨年、跨月的数据
3. 大量数据并发测试的准备
全面性
1. 输入界面后的数据应与测试文档所记录的数据一致
2. 预期结果应与测试数据发生的业务吻合
正确性
1. 测试数据应符合用户实际工作业务流程
2. 兼顾各种业务变化的可能
符合正常业务惯例
1. 对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系
2. 对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系
系统性
1. 对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确
2. 对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯
连贯性
从项目需求分析文档/概要设计/详细设计/原型图中，了解出项目的需求
人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例
仿真性
测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果
可操作性
测试用例设计的原则
通过测试人员自己的分析、 理解，整理成为测试需求，使测试人员能清楚被测项目包含的功能点。
测试需求分析
分析了解被测试项目所属的行业及其业务知识
对被测项目的业务流程要全部梳理出来（可画出项目的流程图，也可用头脑风暴）
项目的流程：主线流程、分支流程、数据流转，流转过程中关键点的判断条件以及完成操作的一些非必要条件
业务流程分析
主要包括功能测试、界面测试、兼容性测试、易用性测试、异常测试、性能测试、压力测试等
字段名重复
空格
非法数据格式
非法字符
SQL注入
特殊格式录入
其他异常情况
在设计用例时要尽量考虑录入正常、边界、异常值等系统的处理情况
测试用例设计
由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、 开发人员、产品及其他相关的测试人员
测试用例评审
测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后， 测试用例必须配套修改更新
在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善
在软件交付使用后客户反馈的软件缺陷（BUG），而缺陷（BUG）又是因测试用例存在漏洞造成，也需要对测试用例进行完善
测试用例完善
用例设计步骤
常用的结构“主、谓、宾”
名称简洁易懂，不要包括具体操作步骤
用例名称
执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件
不可将其他用例作为前置条件，前置条件需要语言描述
入口：覆盖所有功能入口，包含URL直接访问
账号类型和权限：覆盖全部会员类型，注意业务权限控制，比如子账号权限
数据准备：数据准备完整正确，覆盖到线上环境的所有情况；标识出业务流程处于的条件；对于复杂的数据准备，描述对应的场景用例
完整清楚，包括入口、帐号类型、账号权限、数据准备等
操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚
操作和结果是一一对应的，但操作中不要包含结果的检查
用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）
用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等
用例描述中不允许出现二义性语句
操作步骤
原则上每个用例必需要有预期结果，结果不能为空
结果中只能包含结果，不能有步骤
结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等
结果涉及页面，需明确页面提示结果、数据变化
结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化
结果涉及消息：需明确关键查看内容
结果对应不同输入数据有差别时需分别对应描述清晰
一个结果有多个检查点时，确保检查点完整
预期结果
测试用例分项要求
以需求文档为准，不能以口头需求变更为准
需求变更，应及时对测试用例进行修改
优化、重构等迭代需适当调整用例
维护期项目，可根据项目组情况周期对用例进行维护
测试分析法，补充、还原测试场景
所有发现的bug和故障，基于测试用例无法发现，需转化为测试用例
测试用例编写完成后，应对测试用例进行持续的维护
删除/废弃过时的测试用例
随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。
改进不受控制的测试用例
如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用例是冗余的。
删除冗余的测试用例
增添新的测试用例
维护方法
用例维护规范
测试用例规范
0 条评论
回复 删除
下一页
