测试用例编写、测试用例评审及bug处理

测试用例模板

测试问题定义

1、错误：研发在编写代码时产生的错误
2、缺陷：错误的表现；分为过错缺陷和遗漏缺陷
3、失效：当缺陷执行时会发生失效
4、测试：处理错误、缺陷、失效及事故；测试是采用测试用例执行软件活动；测试目标–找出失效或者正确执行
引入问题三个阶段
开发过程中：“引入程序错误”、“找出程序错误”、“解决程序错误”

测试用例（testcase）

软件测试本质是要对测试内容确定一组测试数据
测试用例包含信息：
输入数据：前提和某种测试方法包含信息
预期输出：后果和实际输出
测试用例包含内容：
典型测试用例包含内容有：
测试用例编号
目的
前提
输入
预期输出
结果
时间

以本公司测试用例模板测试用例为例，包含内容有：
用例编号
需求名称：一级菜单、二级菜单
功能点
用例描述
前置条件
操作步骤
预期结果
实际结果
实例模板：

测试用例评审内容

根据评审范围确认评审内容，一般分为项目评审、测试内部评审；评审定义不同，评审的内容维度也不同。
1、测试内部评审
着重点
1） 测试用例本身的描述是否清晰，是否存在二义性
2）是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下
3）是否针对需求跟踪矩阵，覆盖了所有的软件需求，
4）是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待
2、评审内容大致有以下几方面
　　1) 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
　　2) 优先极安排是否合理。
　　3) 是否覆盖测试需求上的所有功能点。
　　4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
　　5) 是否已经删除了冗余的用例。
　　6) 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
　　7) 是否从用户层面来设计用户使用场景和使用流程的测试用例。
　　8) 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
3、评审方式
1）召开测试组进行内部评审，与会者参考评审内容，提出建议和意见
2）安排专人进行会议记录并在会后抄送所有人

bug优先级分类

缺陷分类划分：
1、出现相应的错误的开发阶段划分
2、相应失效后的结果划分
3、解决难度划分
4、不解决会产生的风险划分
一般在开发迭代周期会按照缺陷结果划分：
1、轻微 词语拼写错误或者优化小需求
2、中等 误导或重复信息
3、用户不友好 页面提示及使用感
4、影响使用 一些操作无响应
5、严重 影响流程操作
6、非常严重 系统宕机

一般提在pms中或者其他管理bug工具，优先级分为4个等级
1级：非常严重需要即刻处理 例如：服务器宕机
2级 ：功能完全无法实现
3级：普通bug，影响流程但并不影响流程
4级：优化bug及页面显示问题

bug生命周期
BUGStart–> BUG初始状态 -->BUG分配状态–>BUG重新分配状态 --> BUG修复状态 -->BUG验证状态 --> BUG关闭状态