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