缺陷管理

缺陷管理分为三部分: 缺陷描述, 缺陷级别, 缺陷状态及状态转换

1. 缺陷描述

要素: (和测试用例里面的要素是一样的)

环境, 数据, 步骤, 版本, 预期结果, 实际结果, 附件, 级别, 优先级...

这里比测试用例的要素多"实际结果"这一要素, 目的是将实际结果和预期结果进行对比, 如果结果一致, 代表功能正确, 如果不一致, 就是缺陷. 是需要进行对比的.

对于"附件" 这一要素, 当语言描述不清时, 可以从服务器里面抓取相关日志存到文档里, 将它附在研发人员的缺陷里, 这时研发人员就可以从附件里查看缺陷, 分析原因然后进行处理.

2. 缺陷级别

缺陷是分级别的, 级别是缺陷的严重程度. 优先级是修改缺陷的优先级. 原则上缺陷的级别越高, 修改的优先级越高. 但也有个别缺陷级别高, 但是修改的优先级低.

缺陷级别分为4个: 崩溃, 严重, 一般, 次要, 建议

大部分公司会有个 建议性的bug, 表示功能是没有缺陷的, 比如可能为了页面更美观, 但并非bug, 所以叫做 建议性bug.

现在企业都会有5个缺陷级别. 对应着为 A, B, C, D, F(或者为1. 2. 3. 4. 5).

3. 缺陷状态及状态转换

缺陷的7个状态: NEW OPEN FIXED DELAY REJECTED CLOSED REOPEN

标准规范的缺陷状态转换图是以 "start"开始, 以 "end"结束.

以下, 是我画出的缺陷状态转换图:



NEW 状态是由测试人员发现这个缺陷之后, 把它提交到缺陷管理平台上后, 默认状态就是NEW. 因此, NEW状态由测试人员来操作

OPEN 状态表示测试人员将bug分配给bug对应模块的研发人员后, 状态就由变为OPEN. OPEN状态由测试人员来操作.

FIXED 状态表示研发人员验证是bug, FIXED状态由研发人员来操作, 因此研发人员对bug有 3 中处理方式:

第一种, 研发人员验证完认为这不是缺陷, 将状态置为 REJECTED(拒绝)
	
第二种, 研发人员验证完认为这是缺陷, 但是影响不大或自己目前任务较多, 没有时间修改,暂时不影响其他核心功能, 因此将它推迟到下个版本修改.将状态置为 DELAY
	
第三种, 研发人员验证完发现它是一个缺陷, 进行修改完之后, 将状态置为 FIXED
对于修改完的缺陷, 测试人员是不可以直接关闭的, 需要先进行验证.

验证通过, 测试人员就将状态置为CLOSED,
	
验证失败就需要研发人员重新修改bug, 测试人员将状态置为 REOPEN
状态置为 REOPEN的bug, 就不需要再次验证了, 因为已知它是bug了, 因此就直接发给研发人员, 让研发人员进行修改.

有两个无效的缺陷: (测试人员要避免少提无效的缺陷, 在工作中影响绩效考核.)

测试人员提交的缺陷, 研发人员无法验证和处理. NEW-OPEN-REJECTED-CLOSED
	
测试人员自己提交的缺陷, 自己无法复现出来. 说明这不是一个bug, 是测试人员这边出了问题 NEW-OPEN-CLOSED
REJECTED状态和DELAY状态, 需要进行评审(因为可能研发人员和测试人员对某些缺陷有争议, 所以进行这两个状态时需要进行评审; 但不是每一次这两个状态都需要评审.)

注意:

1.评审是测试人员和研发人员有争议的时候,

2.在每轮测试之前会组织一场会议, 将所有REJECTED和DELAY状态的缺陷统一进行评审, 并不是发现一个缺陷就进行评审

 

 

 

目录

一、缺陷管理

1、缺陷管理工具（禅道）

⒈安装

⒉使用禅道

⒊禅道功能

2、BUG的生命周期

3、BUG严重程度定义规则

4、产品和项目的概念

二、配置管理

1、概念

2、配置管理常用术语

⒈配置

⒉配置项

⒊基线

⒋版本

3、配置管理工具（SVN）

⒈安装

⒉服务器端配置

⒊SVN常见操作和功能介绍

4.SVN的基本构架

5.串行和并行工作模式

6.为什么要使用SVN对源代码进行管理？

7.SVN是如何进行配置管理的？

一、缺陷管理

1、缺陷管理工具（禅道）

下载地址：https://download.csdn.net/download/Arno_007/13121799

⒈安装

⑴ 点击安装程序，必须英文路径，然后在安装路径中找到xampp这个文件夹

⑵ 点击运行程序



⑶ 先点击NO再点击YES





⑷ 点击服务选项-配置端口，勾选“自动更改端口号”





⑸ 点击启动禅道，然后修改密码

⒉使用禅道

⑴ 先使用管理员账号密码登录系统（admin/123456）,登录后修改密码

⑵ 在【组织管理】配置公司的名称，部门以及用户信息

⑶ 建立产品信息

⑷ 建立产品的模块

⒊禅道功能


为了方面编写测试报告，禅道提供了“统计”和“导出”功能以满足测试报告编写。


2、BUG的生命周期

⑴ 已激活-已确认-已解决-关闭

⑵ 已激活-未确认


这种一般都是提交BUG后，开发人员要么忘了，要么不想理会！这种情况我们需要即时提醒！如果不改！找领导！


⑶ 已激活-已确认

    ① 设计如此


领导说要这样做的，测试想多了。


    ② 重复BUG


这个BUG有其他测试人员提过了，无须再提


    ③ 外部原因


这个可能是别人接口调用有问题导致的不通现象，与我们没关系。


    ④ 无法重现


这个我们开发人员重试了几遍都没有出现，但根据测试的截图来看确实出现了这个问题，只是无法立即重现，需要分析系统日志或待用户真实使用的时候，遇到了这种问题的时候，需要立即提供用户操作业务的账号、密码等关键信息提供给我们开发人员。


    ⑤ 延期处理


这种问题影响不是很大，但确实也算一个问题，领导说了，这种小问题留在后面统一优化。（当然这种问题也存在很多需求类的建议，也就是虽然没有说，但应该要实现要做的）！


    ⑥ 不予解决


Ⅰ 这个BUG需求文档没有说，测试人员提给我的话加大了我的工作量，我不想改，我不改！

Ⅱ 建议：建群-拉人-@需求-@开发 看到没！，可以拉甲方，但最好直接联系甲方，不要在群里说。


3、BUG严重程度定义规则

严重级别
			
具体表现
			
问题说明
			
说明
		
致命（1级）
			
1）数据库破坏。

			2）系统停机。

			3）扩展到其它系统的系统停机。
			
阻断性问题，导致我无法进行下一步操作
			
遇到1级BUG，赶紧提，开发不改？找领导！不然没法继续工作。
		
严重（2级）
			
界面：
UI界面无法打开/报错，无法正常完成测试工作的。

			非配置文件中的错误的页面链接，此类链接属于硬编码到代码中必须重新发布程序的错误链接。
程序（代码逻辑）：
核心功能实现问题（指程序核心模块的功能或优先级高的特殊功能）。
数据库：
数据表设计字段与用户需求不符（字段缺失、字段数据类型不符、字段冗余）。

			数据表字段保存不完全。
			
表单提交出问题，数据展示出问题，定义为此级别
			
 
		
一般（3级）
			
界面（GUI）:
界面提示不规范（提示信息错误，提示内容与实际原因不符，提示信息不友好等）

			界面布局不规范（同级别字体样式未统一、段落未对齐、页面框架不统一）

			文字错误（包括按钮文字，页面文字，选项框文字等）
程序（表单格式）：
普通功能操作和输入输出项与用户需求不符（包括输入输出项缺失、名称不符和必填项不符）。
			
表单界面按这个定义，比如个人注册
			
 
		
建议（4级）
			
界面: 
是否改动都不影响发布和用户验收
程序:
可以更好改进的, 但是对测试质量不会构成影响的
			
所有界面
			
 
		
4、产品和项目的概念

⒈做产品的


这种叫作互联网公司，公司有独立的IT部门、有独立的产品部门，公司没有所谓的需求分析师，有也叫作“产品经理”。（比如：淘宝、腾讯、网易、百度）


⒉做项目的


这种一般都是外包公司接的项目，为了调研用户需求，会指派一个需求分析师与客户进行对接！


二、配置管理

1、概念


配置管理的概念:配置管理是通过对在软件生命周期的不同时间点上的软件配置进行标识，并对这些被标

                          识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可塑性的过程。


2、配置管理常用术语

配置
	
配置项
	
基线
	
版本
	
版本标示
⒈配置


配置的概念：“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了

                     即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持

                     数据，以及其他一切保证软件一致性的组成要素。


⒉配置项


配置项的概念：为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置

                        管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配

                        置项被作为一个单一的实体对待。一个系统包括的配置项的数目是一个与设计密切相关的

                        问题。 


⑴配置项的大类别

文档

一篇文档就是一个配置项


代码

推荐将整个项目组的所有代码当做一个配置项。如果项目组内不同模块之间的进度相差很大的时候，

将每一个模块的代码划分为一个配置项更加方便管理。


⑵配置项的分类方法

配置项
			
分类
		
合同类文档
			
建议书、用户意向书、用户需求、工作任务书、合同
		
计划类文档
			
包括各类项目相关计划，比如项目过程手册、项目计划，配置管理计划等
		
工程类文档
			
包括需求规格文档、测试计划（含测试用例）、设计文档、需求跟踪矩阵等
		
程序代码
			
所有开发的源代码、包括各类支持数据，二进制文件
		
第三方程序代码
			
有供应商提供的源代码，并接受供应商的维护
		
工具
			
支持软件开发、建立、维护的工具管理，比如语言开发工具，编译工具，测试工具，配置管理工具等
		
用户文档
			
包括用户手册，安装指南等
		
运行环境
			
包括系统运行环境的相关内容，比如系统运行的平台，环境设置要求等
		
 

 

 

 

 

 

 

 

 

 

 

 

⒊基线


基线的概念：在配置管理系统中，基线就是配置项在其生命周期的不同时间点上通过评审而进入正式受控

                     的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的基准。基线具有以下属性：

通过正式的评审过程建立
	
基线存在于配置库中，基线的变更由变更控制委员会控制
	
基线是进一步开发和修改的基准


⒋版本


版本的概念：版本表示一个配置具有一组定义的功能的一种标示。随着功能的增加，修改或删除，配置项的版本随之演变。

版本以版本号进行标识。


	常见版本：

	Base：基本版

	Alpha：内部测试

	Beta：外部测试

	Demo：演示

	RC：候选

	Release：最终



版本标识的概念：软件版本是以xx.yy.zz.pp的形式标识。


数字
			
发布类型
			
典型描述
		
xx
			
主版本号
			
增加了一个大的特性 - 可能导致与原先版本不兼容
		
yy
			
次版本号
			
增加了一个小的特性 - 保持与原先版本兼容
		
zz
			
维护版本号
			
可以包含一些更改，并且包含自上一次版本发布以后的所有的补丁。一般地，这个版本要根据保证和/或支持/维护协议主动提交给所有的用户
		
pp
			
补丁版本号
			
包含对客户或测试组发现和报告的一个或多个问题的解决。此版本只发布给报告问题的客户或测试组。解决一次问题发布一个补丁版本给报告问题的客户或测试组。补丁也可能只是一种优化
		
 

 

 

 

 

 

 

3、配置管理工具（SVN）



⒈安装

⑴ TortoiseSVN安装：傻瓜式安装即可

         用作项目参与人员的代码或文件配置管理

⑵ VisualSVN安装:

         作为后台可视化管理项目库和人员权限







⒉服务器端配置

⑴ 建库











⑵ 建用户 + 组



⑶ 权限配置





 

⒊SVN常见操作和功能介绍



常用操作
⑴ import


作用：创建完SVN数据仓库后，把测试框架文件夹迁入SVN服务器中。




⑵ checkout


作用：签出服务器上的源测试框架到组员的本地机上开始测试




⑶ Add/Delete/Commit


Add：把需要提交的文件加入到提交列表中
	
Delete：将文件或文件夹的状态置为删除
	
Commit：向SVN服务器正式提交文件。提交时，注意填写提交日志和勾选待提交的文件






 



⑷ update


作用：取得SVN服务器上的最新版本


版本控制操作
⑴ Tag/Branch


作用：制作分支




⑵ Revision Graph


查看当前项目或文件的修订历史图示
	
如果项目比较大型的话，一般会建多个分支，和多个里程碑
	
可以看到项目的全貌


⑶ Diff with precious version


作用：比较该文档和上一个版本中的差异部分


⑷ Show log


显示当前文件（夹）的所有修改历史
	
SVN支持文件以及文件夹独立的版本追溯


⑸Revert to this revision


作用：版本回溯


4.SVN的基本构架



5.串行和并行工作模式


VSS的悲观锁

	  ① 锁定——编辑——解锁

	  ② 一个文件单次只能一个人编辑，提交后才能供其他人编辑

	  ③ 属于串行工作模式
	
SVN的乐观锁

	  ①修改——冲突（Merge）——合并

	  ②同一文件同时可供多人编辑，提交时若发生冲突，手工合并

	  ③属于并行工作模式


6.为什么要使用SVN对源代码进行管理？


SVN = 版本控制 + 备份服务器
	
各开发者之间的数据同步
	
SVN只会备份几个版本之间不同的地方，很省硬盘空间


7.SVN是如何进行配置管理的？


创建版本库，并定期备份
	
确定存储目录结构，并定期检查
	
分配和维护用户权限
	
对基线进行管理（通过在tags文件夹做标记实现）
	
对发布进行管理（通过在tags文件夹做标记实现）

	 


 

 

什么是bug？

编码错误的结果
什么是缺陷Defect？

对原始业务需求的变更或偏离
缺陷在不同的组织中有不同的名称？

issue、problem、bug、incidents
Bug Report包含什么信息？

缺陷id
缺陷描述
应用程序版本
步骤
提出日期
参考文件
bug创建者
缺陷状态
修复人
缺陷关闭时间
严重程度
优先级

缺陷管理过程？

Discovery 发现
Categorization 分类：优先级
Resolution 解决方案
Verification 核实
Closure 关闭
Reporting 报告

如何衡量和评估测试执行的质量？

Defect reject ratio 缺陷拒绝率：发现缺陷100个，其中20个为无效bug，20/100 = 20%
Defect leakage ratio 缺陷泄漏率：一共有100个缺陷，但只测试出80个，20 /100 = 20%

文章目录
缺陷管理工具
目的
jira使用
1.创建项目
创建问题
选择报告人和经办人
问题分配
问题关闭
缺陷报告
缺陷处理流程

缺陷管理工具
QC（HP） • BugZilla

• JIRA

• 禅道

• 其他在线项目管理系统

JIRA

• http://jira.qyguo.cn/secure/Dashboard.jspa

• 管理员 账号/密码 admin/admin@xbsd123hh

禅道

• http://zentao.qyguo.cn/

• https://www.zentao.net/book/zentaopmshelp/244.h

tml

• 管理员 账号/密码 admin/admin@xbsdhh
目的

掌握一种缺陷管理工具的使用

• 团队分配角色模拟系统测试流程

jira使用
1.创建项目






创建问题

选择报告人和经办人






问题分配







问题关闭




缺陷报告

缺陷处理流程