这个测试执行完了发现bug也不能随便跟人说说就算了,要记录下来~
Getting Your Bugs Fixed - 让你发现的缺陷得到修复
不是我们找到什么bug,都会得到修复的,有些可能推迟,有些可能被忽略,有些可能作为下一版的feature。以下原因是为什么一个bug没有被修复
1.There's not enough time - 时间永远都是紧张的。
2.It's really not a bug - 业界有个名言“It's not a bug, it's a feature!”呵呵。
3.It's too risky to fix - 对于一些遗留系统,他们就好像定时炸弹,没人敢碰他们。
4.It's just not worth it - 不值得修复。这些决定都是商业决定或者基于风险的而得出的结论。
5.Ineffective bug reporting - 一份非高效的缺陷报告。测试员没有很好的对缺陷进行描述。
针对最后一条,也就是这章的重点,要记住以下一些报告缺陷的基本原则:
1.Report bugs as soon as possible - 尽早把缺陷报告上去。越早找到bug,能修复bug的时间就越多。
2.Effectively describe the bugs - 对缺陷的高效地描述。
a.Minimal - 简明扼要。只把必须的步骤挑出来,描述一下事实。报bug的时候并不是把test case复制粘贴过去就行了,如果这样的话请个人来测试有何意义,我们要发挥主观能动性,分析出最简单最核心的步骤。同时要对事不对人。
b.Singular - 报告单一的bug。每一个报告只能包含一个缺陷。不要把N个错误写到一个报告里面。因为在一个报告里面有许多bug的话,很容易会出现一种情况~修复了其中一个就忘记了另外的。
c.Obvious and general - 明显的和概括的。不要运行一个自动测试6个小时然后出现错误了,让修复bug的人也运行6个小时……
d.Reproducible - 可重现的。这个一定要注意,提交的bug一定要是能重现的,不能说有时候能出有时候不能出。
3.Be nonjudgmental in reporting bugs - 在缺陷报告里面,不要有任何带有感情色彩的用语。对事不对人。
4.Follow up on your bug reports - 跟进你所提交的测试报告。一个好的测试员能找到和记录下很多缺陷,并且在那些bug被修复的过程中继续监控他们。
Isolating and Reproducing Bugs - 隔离和重现缺陷。如果你发现了一个bug,它的步骤很多,而且不是每次都能重现,那么一下的一些方法可以作为参考:
1.不要对任何事情做任何假设,不能假设某些步骤肯定没有问题。我们需要记录下所做的每一个步骤的每一个细节。做这个的目的是要确信每个有可能引起bug的细节都能被记录下来用于以后的分析
2.注意那些竞争条件和并发的问题
3.利用白盒测试可以让边界条件,内存泄露和数据溢出自己暴露出来。
4.一些跟状态有关的bug只在某些状态下才能重现。
5.对于内存网络共享硬件等的问题也可能考虑进去,例如同时用一个打印机。
6.不要忽略硬件的问题,有可能这个是个配置问题。
Not All Bugs Are Created Equal - 不是所有bug都是平等的。对每个bug,都可以给它们定义出各自的严重程度还有优先等级。
Severity - 严重程度。指出这个bug有多严重,是对bug本身问题的一个描述。例如一个能让系统crash的bug可以定义为最严重的bug。
Priority - 优先级。指出需要对这个bug有多重视。
不是说越严重的bug优先级就越高。例如一个可以引起系统crash的bug,这是一个严重的bug,但是这个bug是在一些非常极端的情况下才能出现,那么就有可能不是一个优先级很高的bug。又好像是一个公司的LOGO错了,他对于用户的影响其实不大,所以这个bug的严重性可能只是很低,但是对公司的影响是很大的,所以优先级很高。
A Bug's Life Cycle - 缺陷的生命周期。
对于一个Bug来说,最简单的生命周期就是这张图所显示的。Open - Resolved - Closed。这个当然只是从测试人员的角度来看bug的声明周期了。这个是最本质的东西,每个公司都有自己不同bug生命周期,来适应本公司的一些工作吧。书中列了一个变种后的~就是下图:
1.发现bug,就要提交报告,这样一个bug报告就生成了,出于open状态
2.bug提交以后有人修复,然后就能转到resolved状态。
3.然后再经过测试员的验证,证实真的修复了,这个bug就可以open了
前3个是最最最简单的3种状态
4.通常提交一个bug以后会让一个bug委员会或者是开发经理来review,看这个到底是不是bug,还有分配给谁来修复,确认优先级等等
5.如果Review证实ok了是一个bug,那么就可以分配给工程师来修复,然后这个图其实是少了一个状态的。呵呵
6.如果Review完了以后觉得这个不是一个bug,可能是一个新的功能,或者这个bug在这个版本里面就不去修复了,就会去到Deferred状态那里。
7.如果证实这个根本不是一个bug,那么就可以直接closed。
8.对于在resolved状态,如果测试员检验的时候发现bug没有被修复,那么这个bug又回到了open状态。
9.如果一个bug在这一个版本修复了,但是在下一个版本里面又出现了,那么又能回到open状态了。
10.Deferred的bug有可能在下一版被处理。
|