一、缺陷管理
1.缺陷概述
1.1 缺陷的定义 *
- 产品实现不满足用户需求
- 测试执行时，实际结果和预期结果不一致
什么是Bug ？
- 狭义概念：是指软件程序的漏洞或缺陷
- 广义概念：除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节（增强性，建议性）、或与需求文档存在差异的功能实现等
- 软件的bug指的是软件中（包括程序和文档）不符合用户需求的问题。
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
缺陷的统计
- 严重程度
- 提交人
- 缺陷类型
- ......
Bug的生命周期：发现 --> 新建 --> 指派 --> 确认 --> 修复 --> 验证 --> 关闭
二、禅道使用
1.禅道简介
- 禅道是由青岛易软天创公司开发的一款项目管理软件。
- 特点是将软件研发中的产品管理，项目管理，质量管理三个核心流程融合在一套工具里面，是
- 一款软件生命周期管理工具。
- 轻量级实现，部署简单
- 开源，免费
禅道中的三权分立：
基本流程如下：
- 1. 产品经理创建产品
- 2. 产品经理创建需求
- 3. 项目经理创建项目
- 4. 项目经理确定项目要做的需求
- 5. 项目经理分解任务，指派到人
- 6. 开发人员实现需求
- 7. 测试人员测试，提交bug
2.禅道安装
网盘链接：https://pan.baidu.com/s/176ZGvOCyG51QmwyE3N40qg
提取码：4yjg
在
window
环境下，一键安装即可
安装包：ZenTaoPMS.9.8.3.win64.exe
(1).运行
Windows
一键安装包
- 双击解压ZenTaoPMS.9.8.3.win64.exe，压缩到某一个分区的根目录，比如F:(必须是根目录)
- 解压完成后会在f盘根目录自动生成一个 xampp 的文件夹
(2).进入xampp文件夹，点击 start.exe，打开禅道集成运行环境
- 如果电脑没有安装过VC运行环境时，会提示安装VC++环境
- Windows一键安装包的运行，需要安装VC++环境，点击yes即可安装。
注意：电脑中的vc++环境版本过低过高都会造成安装失败
注意：需要取消勾选 启用Apache用户访问验证
- 安装好后，点击启动禅道，会自动启动Apache和MySQL的服务，
- 如果服务启动失败，可能是端口被占用，解决方案：
- 点击服务-配置端口，勾选自动更改端口，也可以手动改端口
(3).修改数据库密码
- 首次打开，会提示数据库密码太弱，建议修改密码。
- 会默认显示一个密码，你也可以自己设置一个密码，点OK后数据库密码会自动修改。
- 也可以通过禅道控制面板中【密码】-【数据库密码】查看或者修改密码
(4).访问禅道
- 访问地址：http://ip地址:端口号/文件名
- 点击【访问禅道】，系统会自动会使用默认浏览器打开禅道访问页面
- 也可以自己打开浏览器输入网址访问
(5).登录禅道
- 超级管理员登录禅道后，一键安装包默认的账号密码是admin/123456。
- 系统会检测密码安全级别，提示修改弱口令密码，按照提示修改即可。
3.禅道的使用
禅道使用流程图
- 在禅道项目管理软件中，核心的角色有产品经理、项目经理、研发团队和测试团队四种角色。
3.1 超级管理员使用禅道
1.密码设置
(1).修改弱口令密码安全策略
- 修改之后，下次有新用户登录，就不再检查密码是否为弱口令密码
(2).修改密码
安全验证密码为当前密码（旧密码）
2.组织设置
(1).设置公司信息
(2).设置部门结构
添加部门：
添加子部门：
3.用户设置
(1).单个添加用户
(2).批量添加用户
3.2 产品经理使用禅道
产品经理登录：
1.添加产品
- 产品名称和产品代号是必填项。其中产品代号可以理解为团队内部约定俗称的一个称呼， 比如禅道的代号是zentao，可以是英文字母和数字的组合。
- 产品线：该产品属于那一个产品线。比如禅道这个产品线，下面包含禅道专业版，禅道开源版，禅道企业版 。
- 产品负责人：负责整理需求，对需求进行解释负责，制定发布计划，验收需求。
- 测试负责人：可以为某一个产品指定测试负责人，这样当创建bug，而不知道由谁进行处理的时候，该产品的测试负责人会成为默认的负责人。
- 发布负责人：由这个角色负责创建发布。
- 产品类型：默认是正常的类型， 还可以选择多分支（适用于客户定制场景）和 多平台（适用于跨平台应用开发，比如iOS，安卓，pc端等）的产品。
- 访问控制：可以设置产品的访问权限，其中默认设置只要有产品视图的访问权限就可以访问。 如果这个产品是私有产品，可以将其设置为私有项目，那么就只有项目团队成员才可以访问。 或者还可以设置白名单，指定某些分组里面的用户可以访问该产品。
2.添加产品模块
3.创建产品计划
4.创建产品需求
- 需求的标题和所属模块是必填项。
- 所属计划可以暂时保留为空。
- 需求审核那块，选择不需要审核，这样新创建的需求状态就是激活的。只有激活状态的需求才能关联到项目中，进行开发。
- 需求可以设置抄送给字段，这样需求的变化都可以通过email的形式抄送给相关人员。
- 可以设置关键词，这样可以比较方便的通过关键词进行检索。
5.需求评审
- 在创建需求的时候，有一个"不需要评审"的复选框，如果选中该复选框的话，需求的创建是【激活】中的； 但大部分情况下面，需求还是需要评审的；
- 即使产品完全由一个人负责，也可以将一些不成熟的想法存为草稿，后续再进行处理。新增需求的评审流程 如下：
- 如果创建需求时，未勾选不需要评审，那么创建的需求为【草稿】状态
- 评审是一个线下的活动（开会），只在禅道中更新评审结果；
- 评审结果有以下3种
- 确认通过
- 有待明确
- 拒绝
-
如果选择 “ 确认通过 ” ， 则需求的状态改为“ 激活 ” ，然后就可以关联到项目中进行开发了；
-
如果选择“ 有待明确 ” ，会保持需求的草稿状态，并将需求指派回需求的创建者头上，由其继续进行完善；
-
如果选择了“ 拒绝 ” ，则需要给出相应的拒绝原因，拒绝原因可以有：
-
- 由谁评审：是记录的参与评审的人员名单，可以输入用户名来自动筛选。 一般来讲需求评审可以是一个线下的评审会议，在禅道里面记录下参与需求评审的人员即可。 然后指定一个参与了评审的用户在线上修改需求的状态即可，如产品经理。
3.3 项目经理使用禅道
项目经理登录：
1.添加项目
- 注意事项
- 项目代号是一种隐喻，也就是团队内部可以互相了解和知晓；
- 团队名称，可以自己定义，比如叫做“禅道开发团队”等等；
- 在添加项目的时候，可以选择关联与之相关的产品，以便后续进行需求的关联；
- 项目可以控制它的访问权限，分为默认、私有和自定义白名单三种。
2.设置团队
3.关联需求
4.分解任务
单个分解：
- 需要将所有的任务都分解出来。这里面包括设计，开发，测试，美工，甚至包括购买机器，部署测试环境等等；
- 任务分解的粒度越小越好，比如几个小时就可以完成；
- 如果一个任务需要多个人负责，继续考虑将其拆分 事务型的任务可以批量指派，如要让团队的每一个人都写个项目总结，可以选择类型是事务，然后批量指派给所有人员；
- 任务的分配最好自由领取，调动大家积极性；
- 任务的分解最好由团队共同完成，不要由项目经理一人包办；
批量分解：
3.4 开发使用禅道
开发人员登录：
基本操作：指派、开始、工时、完成、关闭、编辑
1.领取任务
- 领取任务后，任务的状态为“进行中”
2.创建版本
3.提交测试
- 负责人为本次测试的负责人。
- 可以指定这次测试预计起止的时间。
- 任务描述里面，可以注明此次测试需要注意的地方。
3.5 测试使用禅道
1.BUG跟踪 *
- 测试提交缺陷
- 开发解决缺陷
- 测试回归验证
- 确认修复，关闭缺陷
- 并未修复，激活缺陷，重新指派给开发解决
- 关闭后的缺陷再次出现，测试激活该缺陷
(1).测试人员提BUG
测试人员登录：
(2).开发人员解决BUG
开发人员登录：
(3).测试人员回归测试
2.编写用例
在禅道工具中不常用该功能，因为很麻烦~
单个添加：
批量添加：
(1).导出模板
- 注意：编码格式选择 GBK（支持中文）
(2). 按照模板格式，编写用例
(3).导入数据
