软件测试基础理论（入门篇三）---缺陷管理理论与工具（禅道）

目录

一、软件的缺陷

二、缺陷管理

2.1 提交缺陷注意事项

2.2 缺陷的跟踪流程 

三、项目管理工具之一---禅道

3.1 禅道介绍

3.1.1 基础了解

3.1.2 禅道使用流程

3.1.3测试人员使用禅道

3.2 禅道用户角色

3.2.1 超级管理员

3.2.2 产品经理

3.2.3 项目经理

3.2.4 开发

3.3 测试人员使用禅道 

3.3.1新建用例

3.3.2导入用例

3.3.3评审用例

3.3.4版本关联用例

3.3.5 执行用例

3.3.6 禅道中的bug跟踪

---

一、软件的缺陷

缺陷定义：软件在使用过程中出现的任何问题（如：错误、异常），都叫软件缺陷，即bug。

软件的缺陷会导致软件产品在某种程度上不能满足用户的需求。

软件缺陷的判定标准：

• 软件未实现需求（规格）说明书中明确的要求的功能
• 软件出现了需求（规格）说明书中指明不应该出现的错误
• 软件实现的功能超出需求（规格）指明范围
• 软件未实现需求（规格）说明书中虽然没有明确规定但是应该实现额度需求【一般指国家、行业、企业标准规范或者法律要求】
• 软件不易理解，难以使用，运行缓慢，用户体验不好

软件缺陷产生的原因：

• 需求阶段：需求描述不易理解、有歧义，错误等；
• 设计阶段：设计文档存在错误和缺陷；
• 编码阶段：代码出现错误；
• 运行系统：软硬件系统本身故障导致软件缺陷

软件缺陷的核心内容：

• 缺陷的标题--描述缺陷的核心问题【例如：后台会员管理输入正确的手机号添加会员失败，提示，手机号码有误】
• 缺陷的预置条件--缺陷产生的前提
• 缺陷的复现步骤--复现缺陷的过程
• 缺陷的预期结果--希望得到的结果【输入正确的手机号应该提示添加成功】
• 缺陷的实际结果--实际得到的结果【输入正确的手机号提示添加失败，手机号有误】
• 缺陷的必要附件--图片、日志等信息（证据）

构成缺陷的基本要素：

缺陷编号：缺陷的唯一标志

缺陷状态：表示缺陷当前处于哪个阶段

常见缺陷状态：

-new：新建，表示缺陷刚建立

-open：打开，表示已经指派或者开发认领了bug

-inprogress：进行中，表示开发正在修改中

-fixed：已修复，表示测试可以验证了

-closed：已关闭，表示测试验证通过

-rejected：已拒绝，表示开发拒绝了当前的bug

-postpone/delay:已延迟，表示开发延迟修复该bug

缺陷所属模块：缺陷属于哪个被测模块

缺陷严重程度：该缺陷的破坏程度或者影响程度

-critical

-major

-medium

-minor

-tiny 

缺陷的优先级：处理该缺陷的优先程度

-urgent priority

-veryhigh priority

-high priority

-medium priority

-low priority 

软件缺陷的类型：

• 功能错误
• 界面（UI）错误
• 兼容性错误
• 易用性
• 改进建议
• 其他

二、缺陷管理

2.1 提交缺陷注意事项

可复现：缺陷可以重新展现

唯一性：一个缺陷上报一个问题

规范性：符合公司或者项目要求

• 准确：描述的信息是正确的
• 具体：游戏界且是真实特定的
• 简洁易懂：描述简单，容易理解
• 次序清晰：描述缺陷过程有条件，有先后顺序

2.2 缺陷的跟踪流程 

三、项目管理工具之一---禅道

3.1 禅道介绍

3.1.1 基础了解

国产、免费、开源、简单、轻量级；

三管融合（产品管理、项目管理、质量管理）

禅道特点：

三权分立

• 产品部门--构想者
• 研发部门--执行者
• 测试部门--保证者

3.1.2 禅道使用流程

1）产品经理创建产品

2）产品经理创建需求

3）项目经理创建项目

4）项目经理确定项目要做的需求

5）项目经理分解任务，指派到人

6）开发人员实现需求

7）测试人员测试，提交bug

3.1.3测试人员使用禅道

管理用例

• 创建用例
• 评审用例

管理缺陷

• 缺陷的创建

3.2 禅道用户角色

3.2.1 超级管理员

• 1）设置密码强度
• 
•  2）完善组织构架
• 
• 3）添加用户
• 

3.2.2 产品经理

• 1）创建产品 
• 
• 2）产品的功能模块 
• 
• 3）创建测试计划
• 
• 4） 提需求
• 
• 5）需求评审

                 ---需要评审的需求处于草稿状态

                评审是一个线下的活动（开会），只在禅道中更新评审结果（通过、有待明确、拒绝）

• 
• 

3.2.3 项目经理

• 创建项目：【项目】--【添加项目】--编辑具体项目信息
• 
• 创建团队：【项目】--【团队】--【团队管理】
• 
• 关联需求：【项目】--【需求】--【关联需求】
• 
• 分解任务：【项目】--【需求】--【分解任务】/【批量分解】
• 
• 添加完毕保存后：
• 

3.2.4 开发

领取任务

• 方式1：【项目】--【任务】--选择开始
• 
• 方式2：【我的地盘】--【任务】--选择开始
• 

 提测

• 1）打版本：【项目】--【版本】--【创建版本】
• 
• 2）提交测试：【项目】--【版本】--【提交测试】
• 

3.3 测试人员使用禅道 

3.3.1新建用例

测试视图--->用例--->建用例  

用例的适用阶段，指在哪些测试阶段可以用上这个用例。可以进行多选。

用例步骤可以非常方便在之后插入，之前插入，或者删除当前的步骤。

不要把若干个测试用例作为步骤写到一个测试用例里面，因为这样不利于测试的管理和统计。

3.3.2导入用例

用例可以通过表格导入到禅道系统中

• 第一步：导出测试用例模板
• 第二步：按照模板编写测试用例
• 第三步：导入编写好的用例文件
• 

3.3.3评审用例

用例的评审功能，禅道里默认是关闭的。 可以由管理员到后台 -- 自定义 -- 用例 --评审流程里开启。 开启评审流程时，可以设置哪些用户提交的用例不需要评审。

 

用例的评审流程开启后，新建的用例状态为【待评审】   

用例评审是一个线下活动，线下开会评审用例后，由测试人员将评审通过后的用例导入禅道即可。

3.3.4版本关联用例

测试视图 ---> 测试单 ---> 关联用例

注：在某些版本的禅道中，【测试单】的名字叫【版本】，都显示被开发提测的版本。

关联用例

关联用例后在测试单中可以看到该测试版本关联的所有用例

3.3.5 执行用例

可以在用例列表，也可以在测试单--测试版本里执行用例 

3.3.6 禅道中的bug跟踪

测试提Bug

测试视图--->Bug--->提Bug  

开发解决bug 

测试回归验证

• 确认修复，关闭bug；
• 并未修复，激活缺陷，重新指派给开发；
• 关闭后的缺陷再次出现，测试激活该缺陷；
• 关闭后缺陷再次出现，测试激活该缺陷 
•