测试用例规范讲解.ppt

测试执行阶段 输入：测试用例 测试执行优先级，测试重点 测试用例质量分析 用例无覆盖缺陷分析 测试用例问题进行修改 根据实际情况记录测试用例执行结果 模块用例质量分析 用例高压线：执行后的用例无错误，发现错误需记录，并通知相关人员修改；不能出现执行漏测； 结项总结阶段 模块测试用例基线 测试用例质量整体分析 缺陷根因分析 网上问题分析 低级问题严重问题回溯测试过程，测试方法 问题追溯：模块责任制，有效期为2年 经验、方法总结 并行相关工作变更 包括需求变更，设计变更，代码回滚等 评估变更带来的影响，是否需变更 更新相关资料，用例，需求，代码 重点关注 并行相关工作评审 评审前的通知和准备 组内交叉、版本测试经理、测试经理、测试中心、开发评审 评审之后的完善和修改 对完善过后的进行检查、审核 分析评审结果与追溯 二、测试用例流程 项目测试流程：在项目中如何运用 测试用例标准：整体测试用例相关标准 测试用例资格考核流程：测试用例编写认证 测试用例设计学习素材：测试用例设计经验 三、功能用例框架 1、各模块框架必须按此模板；从公共库复制即可保证 2、有则写，没则为空目录。 3、文件夹以01-xx、02-xx标注。 非独立模块，可不按此模板来写，如专项测试、系统测试项等，但需评审。 大模块下可在细分模块，然后再按此模板编写。文件夹以01-xx、02-xx标注。 1、导致测试项的遗漏； 2、导致测试点的遗漏； 3、整体框架没有条理； 没有模板 模板不全 对比 1、结构清晰、思路清晰，重点体现在目录框架中 2、各框架下各文件夹必须有编号：01-、02-、03-，每个文件夹下不能超过10个测试用例 3、需要在“02-功能测试”的描述中，说明功能框架设计的思路 4、每个测试用例一个测试点 需要在“02-功能测试”的描述中，说明功能框架设计的思路 对比 对比 1、标题精简，需要体现测试目的，让人一看就知道测试什么 2、命名建议使用“测试……、验证……、……的测试、与……的关联测试、……异常测试、……兼容性测试”来进行描述，命名不宜过长 3、测试用例不写“编号”，方便后续维护 Case ID：用例编号 测试环境：测试环境1、测试环境2….. 测试方法：手工测试，接口测试，单元测试，自动化测试 兼容性问题：是否需兼容性覆盖 已自动化？：是否已自动化 更新(优化人)：测试用例更新人员 优先级： 用例优化级 用例属性关系到测试策略、测试质量、测试效率等环境。 用例优先级： (比例为参考数值，优先级定义关系到测试策略) Level 1(30%)： 用户最常用到的功能点；最基本的功能点（包括如加速产品的效果测试）；用户场景和解决方案（此部分测试级别虽高，但可以放在转测后进行评审和测试）；能预计当有问题时，开发改起来特别困难的 Level 2(30%): 功能验证的细化测试；常见的部署方式测试；关联测试 Level 3(20%)： 重要的容错和边界值测试；重要的兼容性测试；非常见的部署方式测试 Level 4(15%)： UI易用性、美观及其布局 Level 5(5%)： 信息提示、错误提示；极少用到的边界值和容错测试；非主流兼容性测试 该用例定义为1级 通过查看，此用例和功能密切度不高，且不需要后续执行，所以用例级别应该降低为3级。 1、UI中公共部分分析 如多个页面公用一个模板，则针对模板设计测试用例即可，这个叫素材 而各个输入框之间存在差异，则需要针对不同点进行设计 2、UI测试点主要页面处理，页面检查、页面交付，这几个角度分析，重点关注页面 3、防止出现UI测试与功能用例冗余问题，如功能用例能够覆盖UI测试，UI测试可省略 1、功能测试点包含 功能基本流程逻辑覆盖 业务流程多样性覆盖 用户操作习惯的多样性 模块配置的多样性 数据流的多样性覆盖 2、用例目录结构划分 平级分类相对独立 上下级分类有关联 下级从上级细化而来 1、关联测试：模块和模块之间、模块与系统之间、模块与硬件之间； 而模块内部的功能点和功能点之间的关联应该在功能用例中。 2、2者之间的关联，要注意关注度； 如模块A与模块B：模块A关联模块B，重点关注度是A；模块B关联模块A，重点关注度是B。 容错测试包含：容错测试、可靠性测试、安全性测试。 1、容错测试 测试系统在非正常的数据流输入、非正常的操作、非正常的外部环境下（这些不是通过程序本身提供的接口输入），验证系统是