今日目标
能够说出缺陷的判定标准
能够说出描述缺陷的6大核心内容
能够描述缺陷状态、严重程度、优先级的作用
能够按照提供的缺陷模版完成一个缺陷的提交
能够说出缺陷的跟踪流程
能够在禅道中提交测试用例
能够在禅道中提交缺陷
1. 缺陷
1.1 缺陷的定义（重点）
产品实现不满足用户需求
测试执行时，实际结果和预期结果不一致
1.2 缺陷的判定标准（重点）
未达到需求说明书指明的功能
出现了需求说明书指明不应该出现的错误
实现了需求说明书之外的功能
未达到需求说明书虽未明确提及但是应该实现的目标（如：性能要求等）
用户角度发现的各种问题与错误
1.3 缺陷产生的原因及根本原因
缺陷产生的原因
需求文档存在错误
需求变更
设计存在错误
代码错误
缺陷产生的根本原因
需求变更
沟通不畅、信息不同步
软件复杂
进度压力
1.4 软件缺陷的核心内容（重点）
标题：描述缺陷的基本信息，如（输入密码长度为5时，注册成功。）
前置条件：描述缺陷出现依赖的相关基础条件，如（未注册手机号）
复现步骤：测试用例里面的执行步骤
实际结果：执行被测试软件过程中，系统给出的结果
预期结果：参照需求说明书，在测试用例中设计的预期结果
附件：方便开发定位bug的关键信息，包含图片、日志log等
1.5 缺陷基本要素（重点）
ID编号：唯一
模块：根据产品进行具体的划分，如登录、注册
缺陷状态：表明缺陷处理进度
严重程度：从技术维度来衡量，bug的破坏力
优先级：从业务的角度，决定bug修改的先后顺序
缺陷类别：用于分类整理缺陷
1.6 缺陷的状态（重点）
new：新建
open：打开
fix：已修复
close：关闭
reopen：重新打开
reject：已拒绝
postpone：延期
1.7 缺陷严重程度（重点）
5-致命的
4-非常高
3-高
2-中
1-低
1.8 缺陷优先级（重点）
5-紧急的
4-非常高
3-高
2-中
1-低
### 思考题：优先级和严重程度的区别（了解）
+ Priority is Business【优先级是从公司运营角度(人力配置，资金投入等）】
+ Severity is Technical【严重级别是从技术角度】
- 优先级还要考虑团队的工作进度，阻塞工作的缺陷，要优先解决
- 考虑解决缺陷的能力，难度，风险
+ 最终优先级
+ 确定权：产品经理、项目经理等
+ 建议权：测试1.9 缺陷类别（了解）
功能错误
UI界面错误
兼容性
易用性
改进建议
其他
2. 缺陷管理
2.1 缺陷信息（重点）
核心要素
标题：描述缺陷的基本信息，如（输入密码长度为5时，注册成功。）
前置条件：描述缺陷出现依赖的相关基础条件，如（未注册手机号）
复现步骤：测试用例里面的执行步骤
实际结果：执行被测试软件过程中，系统给出的结果
预期结果：参照需求说明书，在测试用例中设计的预期结果
附件：方便开发定位bug的关键信息，包含图片、日志log等
基本要素
ID编号：唯一
模块：根据产品进行具体的划分，如登录、注册
缺陷状态：表明缺陷处理进度
严重程度：从技术维度来衡量，bug的破坏力
优先级：从业务的角度，决定bug修改的先后顺序
缺陷类别：用于分类整理缺陷
2.2 缺陷报告的重要性（了解）
体现测试的一个专业性
多站在开发的角度去思考问题（换位思考）
2.3 编写缺陷报告注意事项（理解）
可复现
唯一性
一个问题只提交一个bug记录
2.4 缺陷书写规范（理解）
标题：应保持简短、准确，提供缺陷的本质信息
复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤
实际结果：是执行复现步骤后软件的现象和产生的行为
预期结果：通常需要列出期望的结果是什么
附件：对缺陷描述的补充说明
2.5 缺陷跟踪流程(重点)
场景1：确认BUG解决
测试【new】==》开发【open】==》开发【fix】==》测试【close】
场景2：验证未通过，缺陷仍存在
测试【new】==》开发【open】==》开发【fix】==》测试【reopen】
场景3：开发延期处理
测试【new】==》开发【open】==》开发【postpone】
场景4：拒绝处理
测试【new】==》开发【open】==》开发【reject】
2.6 缺陷的统计（了解）
严重程度
提交人
缺陷类型
......
3. 禅道（重点）
3.1 禅道使用流程
1.产品经理创建产品
2.产品经理创建需求
3.项目经理创建项目
4.项目经理确定项目要做的需求
5.项目经理分解任务，指派到人
6.开发人员实现需求
7.测试人员测试，提交bug
3.2 禅道用户角色（了解）
超级管理员
产品经理
项目经理
开发
测试
...
3.3 超级管理员使用禅道（扩展）
取消弱口令：【系统】--【安全】
密码安全：不检查
修改弱口令密码：不强制
修改密码
修改公司信息：【组织】--【公司】--【编辑】--【公司名称】
添加部门：【组织】--【部门】
添加用户：【组织】--【用户】--【添加用户】/【批量添加】
注意：
用户名是数字，字母，下划线，大于3位
注意：用户的职位和分组，决定了用户的相应权限
添加用户
批量添加
3.4 产品经理使用禅道（扩展）
创建产品:【产品】--【添加产品】--编辑产品信息
维护模块:【产品】--【模块】--按层级编辑模块信息
维护计划:【产品】--【计划】
产品经理提需求:【产品】--【需求】--【提需求】
默认不开启评审，需求是激活状态
需求评审
需要评审的需求处于‘草稿’状态
评审是一个线下的活动（开会），只在禅道中更新评审结果
评审的结果
确认通过
有待明确
拒绝
需求变更
需要评审的变更需求处于‘变更中’状态
评审结果
确认通过
有待明确
撤销
3.5 项目经理使用禅道（扩展）
创建项目：【项目】--【添加项目】--编辑具体项目信息
创建团队：【项目】--【团队】--【团队管理】
关联需求：【项目】--【需求】--【关联需求】
分解任务：【项目】--【需求】--【分解任务】/【批量分解】
3.6 开发使用禅道（扩展）
领取任务：
方式1：【项目】--【任务】--选择开始
方式2：【我的地盘】--【任务】--选择开始
提测
1.打版本：【项目】--【版本】--【创建版本】
2.提交测试：【项目】--【版本】--【提交测试】
3.7 测试使用禅道（重点）
3.7.1 创建用例
【测试账号】登录
【测试】--【用例】--【建用例】
【测试】---【用例】-- 点击右上角“建用例”的下拉菜单，选择【批量添加】
3.7.2 导入用例
第一步：导出测试用例模板
进入【测试】---【用例】，右上角按钮【导出】--【导出模板】，选择【GBK】字符，点击保存
第二步：按照模板编写测试用例
第三步：导入编写好的用例文件
进入【测试】--【用例】，右上角【导入】--【导入CSV】，选择测试用例文件，选择“GBK”，点击保存
3.7.3 评审用例
【admin】登录，进入【后台】--【自定义】--【用例】---【评审流程】，【开启评审】的功能
测试人员登录，进入【测试】--【用例】，新建一个需要评审的用例（不勾选“不需要评审”）
在【测试】--【用例】，对需要评审的用例，点击操作栏“评审”按钮，进行评审。
“确认通过”：用例从【待评审】状态改为【正常】状态
“继续完善”：用例保持【待评审】状态
3.7.4 版本关联用例
测试人员登录系统，进入【测试】---【版本】，查看提交测试的版本
点击操作栏中的“关联用例”按钮，勾选用例（正常状态），点击保存。
3.7.5 执行用例
测试登录系统，进入【测试】---【版本】---【用例】，点击操作栏中的执行按钮
用例执行的结果：【通过】，【失败】，【阻塞】，【忽略】
失败的用例，可以点击“转BUG”，填写BUG信息，点击保存。
可以直接提BUG：进入测试--BUG，点击“提BUG”，填写信息，点击保存
3.7.6 禅道中BUG跟踪过程
测试提交缺陷
开发解决缺陷
测试回归验证
确认修复，关闭缺陷
并未修复，激活缺陷，重新指派给开发解决
关闭后的缺陷再次出现，测试激活该缺陷
今日目标
能够说出缺陷的判定标准
能够说出描述缺陷的6大核心内容
能够描述缺陷状态、严重程度、优先级的作用
能够按照提供的缺陷模版完成一个缺陷的提交
能够说出缺陷的跟踪流程
能够在禅道中提交测试用例
能够在禅道中提交缺陷
作业
作业：
1.梳理今日知识点，结合课上知识讲解补充完善今日总结内容，以xmind形式输出
2.TPShop商城前台【注册】功能测试用例设计、执行、并将发现的bug记录在缺陷报告和禅道
3.TPShop商城后台【添加会员】功能测试用例设计、执行、并将发现的bug记录在缺陷报告和禅道
说明：
后台访问地址：http://localhost/Admin/Admin/login
用户名：admin
密码：123456
测试功能：【系统】==》【会员】==》【会员列表】==》点击【添加会员】按钮
要求：
1.作业需要上交，命名格式：
姓名_作业_【XXX】测试用例设计，例如：张飞_作业_注册测试用例设计
