@font-face {
font-family: "Times New Roman";
}@font-face {
font-family: "宋体";
}@font-face {
font-family: "Calibri";
}@font-face {
font-family: "微软雅黑";
}@font-face {
font-family: "Tahoma";
}@font-face {
font-family: "Cambria";
}p.MsoNormal { margin-bottom: 10pt; font-family: Tahoma; font-size: 11pt; }h1 { margin-top: 17pt; margin-bottom: 16.5pt; page-break-after: avoid; font-family: Tahoma; font-weight: bold; font-size: 22pt; }h2 { margin-top: 13pt; margin-bottom: 13pt; page-break-after: avoid; line-height: 173%; font-family: Cambria; font-weight: bold; font-size: 16pt; }span.msoIns { text-decoration: underline; color: blue; }span.msoDel { text-decoration: line-through; color: red; }div.Section0 { }Bug处理的流程
Bug的常用状态:新建、确认、修正、拒绝、关闭、延期处理、重新打开、无法重现
新建:测试人员执行测试,如果发现测试问题,在系统中记录问题,此状态为“新建”
确认:开发人员确认测试提交的问题存在,如果存在,则已经分配给开发人员
修正:开发人员已经修改完成,记录问题产生的原因,将状态修改为“修正”,等待测试人员的验证
拒绝:开发认为测试提交的问题不存在或是描述不清晰拒绝修改这个bug
延期处理: 开发认为测试提交的问题,不在当前版本处理该bug,下一个版本修改
关闭:测试人员对开发已经修复的问题进行验证,如果测试通过,则修改此状态为“关闭”
重新打开:测试人员对开发已经修复的问题进行验证,如果测试不通过,则修改此状态为“重新打开”
无法重现:开发人员确认测试提交的问题存在,如果不存在,则说明原因,并将状态 “无法重现”
Bug优先级
Bug的优先级定义:
1.极度重要:“停下其他事,马上修复此问题!!!!”
2.重要:“需要尽快解决。”
3.一般:“快点修复,但如果不能马上解决也可以。”
4.不重要:“如果有必要,这个问题可以推后处理。”
5.极不重要:“这个想法或建议应该暂缓执行,以后再说。”
Bug的严重程度
严重错误:由于程序所引起的死机,非法退出,死循环导致数据库发生死锁,等等
较严重错误:功能不符,功能缺失、数据不能保存等等
一般性错误:删除操作未给提示,界面错误等等
较小错误:建议类,用户体验类的问题等等
Bug的判定原则
软件未达到软件产品规格说明书
软件出现软件产品规格说明书不一致功能
软件规格说明书中未提到的隐含需求
最终认为体验不好,软件易用性差
用户反馈的问题
Bug的书写原则
Bug的提交的信息必须完整,具体如下:
a) 头信息包括:测试软件名称、版本号、严重程度、优先程度、测试平台、
缺陷或错误范围。要求填写真实、完整、准确。
b) 简述是对缺陷或错误特征的简单描述,可以使用短语或短句,要求简练、
准确,并描述清楚正确的应该是怎么样的,现在有什么错误,以及出现几率。
c) 操作步骤是描述该缺陷或错误出现的操作顺序,要求真实、完整、简洁、准确。
每一个步骤尽量只记录一个操作,结束时写上出现频率。
d) 预期结果与实际结果,要求真实、完整、简洁、准确。
e) 注释一般是对缺陷或错误的附加描述。比如:问题的特征,问题的解决方案等等
f) 对于描述不清楚的问题,可以抓张图片说明,对于非必现的问题,需要
添加log附件。
Bug的管理原则
Bug是可是再现的错误
Bug的验证必须由提交测试人验证
开发人员修复bug的过程,需要填写修改的原因,以及需要在那个版本上验证
对于有争议的bug,需要找第三方需求或是产品来进行确认
如果测试人员发现bug短期内无法修复,需要先与相关的人员沟通问题,以及需要汇报给领导,请领导一同商议解决策略
测试人员不能处理的bug,需要汇报给领导,请领导决策
对于无法重现的问题,需要单独记录文件表,进行后续跟踪
对于偶现的问题,需要在bug的结尾加上复现率
测试经理加强对bug的关注,对长时间没有处理的问题,应该进行关注以及跟踪