首页 > 软件测试/ 正文

从BUG的“一生”闲谈软件测试工程师面试

2012-09-18 23:20:19 ℃

　　好久没有写博客了，让大家失望了，最近实在是事情太多了，在最近的对学员的模拟面试过程中有一些体会和感受，希望这些感受对目前正在找工作的学员以及测试同仁能起一点抛砖引玉的作用。下面就从问题开始入手：

　　问题：谈谈你对缺陷的认识？

　　参考的思路：首先，这个问题是个非常发散的问题，为什么这么说呢？因为大家都知道BUG在软件的整个生命周期内一直是一条主线，从程序员的“错误”的行为导致“缺陷”，而“缺陷”被激发导致软件“故障”，“故障”没有人修复会导致软件某一功能“失效”。另外一点的是众所周知的缺陷放大模型，根据缺陷放大模型的要求提出了“尽早测试”的观点，同时也带出了静态测试的重要性。从目前很多企业通过“BUG”数来衡量测试执行人员甚至是测试人员的工作绩效，到IBM所提倡而且做得非常成功的对“缺陷”从100多个纬度来进行ODC分析。再到微软强调的“以BUG为中心”的工作模式，无不体现“缺陷”在整个软件测试甚至在整个软件开发活动中的重要性。那么对于缺陷而言，到底有哪些东西是需要我们测试人员能联想到和需要掌握的呢？以下是鄙人的一点点看法：

　　第一，一谈到缺陷，我们首先能够想到的肯定是缺陷怎么样管理，也就是缺陷跟踪怎么样去做？用什么样的缺陷跟踪工具？缺陷的一生到底是什么（也就是BUG有哪些状态）？为什么要进行缺陷跟踪？

　　参考的答案：

　　首先缺陷跟踪对于整个项目具有十分重要的意义，是后期进行缺陷的分析和统计的基础，是对整个软件质量进行度量的基础。而想到缺陷的分析，我们可以联系到Gompertz模型和ODC分析，通过对缺陷的Gompertz分析我们可以得出测试该如何结束？测试应该停止于理智而非情感，那就是我们对于测试该如何结束的决策需要基于事实数据，这里可以联想到ISO的八项质量管理原则的其中一点“基于事实的决策”。通过的缺陷的ODC分析，我们可以从多个纬度来分析导致缺陷发生的技术和非技术原因，从而可以改进我们的开发和测试技术以及我们的测试过程，举个例子，如果通过分析发现很多问题跟初始化相关，那可以说明单元测试的静态检查没有做好，那可以选择对单元比较熟悉的人，经验跟丰富的人来做代码检查。因为工作好象就是这样的，如果你不行就让别人来。好，不能太发散了，回到我们缺陷跟踪，常见的具备缺陷跟踪能力的工具有以下：

　　1、最简单的电子表格和WORD文档管理；

　　2、专业的测试管理工具如QC、CLEARQUEST、免费的BUGZILLA和JIRA等。然后再描述下，比如在QC中BUG有哪些状态？

　　第二，BUG单的内容？什么样的BUG单是比较好的BUG单？

　　参考的答案：

　　1、测试项目的名称，这一点好的BUG跟踪工具都已经把它给模板化了，在填写BUG单的时候只需要选择就可以了。

　　2、软件的版本号，包括主版本和从版本号。这一点同测试项目名称一样，都已经模板化了。

　　3、BUG问题发现人，这个目的很简单，为了方便问题的统计，了解某一测试执行工程师的工作成绩。

　　4、BUG发现的日期和时间，同上面一样方便统计。

　　5、问题发现的测试环境（软硬件软件，包括客户端和服务端的环境），目的是为了清晰地了解问题发现的条件。

　　6、缺陷的编号，每个缺陷都有唯一规范的编号，目的是为了方便检索和统计。

　　7、缺陷的标题，对缺陷的简明扼要的描述。

　　8、缺陷的类型，缺陷是功能性问题还是性能性问题，还是安全性问题，这样可以联想到软件质量模型。