软件测试 第2版 §19 报告发现的问题

报告发现的问题

       软件测试的主要任务：测试计划、实际测试、报告发现的问题。报告所发现的问题，实际上是也许是软件测试人员要完成最重要的，有时也是最困难的任务！

本章重点:

·         为什么所有软件缺陷不一定都能修复

·         如何使找出的软件缺陷尽量得以修复

·         可以用哪些技术分离和再现软件缺陷

·         软件缺陷的生命从出现到消失像什么

·         如何手工或者使用数据库跟踪软件缺陷

§19.1           设法修复软件缺陷

       不修复软件缺陷的原因：

       没有足够的时间

       不算真正的软件缺陷，”。

       修复的风险很大

       不值得修复

 

并非所有的软件缺陷被发现就能修复：

1.没有足够的时间；

2.不算是真正的缺陷，比如“这不算软件缺陷，而是一项功能。也许很多人说发现了能不算吗，但是原因很多诸如理解错误，测试错误或是产品说明书的变更等情况；

3. 修改这个缺陷的风险很大;

4. 不值得修复，也许听起来很气人，有些Bug不经常出现或是这个功能不常用，出现问题的机率很小，但是如果有这样的情况

也就要相应的担当商业风险；

5. 无效的软件缺陷修复报告。其它如软件缺陷报告的不是很有效；

 

注意：由于软件开发的模式不同和小组的不固定，所以具体软件缺陷修复在某个小组是不可能的，更多的则是集中在管理者身上，还有一些是在程序员身上，还有一些是在会议桌上！

 

报告软件缺陷的基本原则：

尽快报告软件缺陷

有效描述软件缺陷。短小和单一。明显并通用，可再现。

在报告软件缺陷时不要做评价

对软件缺陷报告跟踪到底。

 

1. 尽早报告软件缺陷

2. 有效的描述软件缺陷

2.1 短小:

2.2 单一

2.3 明显并通用

2.4 可再现

3. 报告缺陷时不参加评论

4. 对软件缺陷报告跟踪到底

 

§19.2           分离和再现软件缺陷

再现的方法：

       不要想当然接受任何假设。       查找时间依赖和竞争条件的问题。

       边界条件软件缺陷

       状态缺陷仅在特定软件状态中显露出来

       考虑资源依赖性和内存，网络，硬件共享的相互作用。

       不要忽视硬件。

 

分离和再现软件缺陷

1. 不要想当然接受任何假设。记下所作的每一件事－每一个步骤，每一次停顿，每一件工作。

2. 查找时间依赖和竞争性的问题

3. 边界条件软件缺陷、内存泄漏和数据溢出等白盒问题可能会慢慢自己显露出来。也许要利用动态白盒技术。

4. 状态缺陷仅在某个特定状态才出现。注意事件发生的次序。

5. 考虑资源依赖性和内存、网络和资源共享的相互作用、

6. 不要忽视硬件。比如硬件降级、不按预定方式工作。板卡松动、内存条损坏、CPU过热。

 

 

§19.3           并非所有软件缺陷生来就是平等的

通常我们用严重性和优先级表示对软件缺陷的划分，当然这个要结合具体的公司规定。

 

严重性： 软件缺陷的恶劣程度；用户碰到该缺陷时可能性和影响程度。

优先级：修复缺陷的重要程度和紧迫程度。

       不是说越严重的bug优先级就越高。例如一个可以引起系统crash的bug，这是一个严重的bug，但是这个bug是在一些非常极端的情况下才能出现，那 么就有可能不是一个优先级很高的bug。又好像是一个公司的LOGO错了，他对于用户的影响其实不大，所以这个bug的严重性可能只是很低，但是对公司的 影响是很大的，所以优先级很高。

 

比如：

       严重性：

1.    System crash, data loss, data corruption, security breach

2.    Operational error, wrong result, loss of functionality

3.    Minor problem, misspelling, UI layout, rare occurrence

4.    Suggestion

优先级：

1.    Immediate fix, blocks further testing, very visible

2.    Must fix before the product is released

3.    Should fix when time permits

4.    Would like to fix but the product can be released as is

 

§19.4           软件缺陷的生命周期

最简单的状态转换：

       open state－resolved state－closed state

比较合适的状态见教材图19-4

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有可能在下一版被处理。

 

§19.5           软件缺陷跟踪系统

 

标准为测试事件报告，它的目的：记录在需要调查的测试过程起发生的任何事件。它包含标识符，总结，事件描述和影响。详见教材。

事件描述包含日期和时间，测试缘的姓名，使用的软硬件配置，输入，过程步骤，预期结果，实际结果，试图再现以及尝试描述，有助于程序员定为软件缺陷的其他现象或者信息。

影响包含严重性和优先级，以及测试计划，测试说明、测试程序和测试用例的影响指示。