一篇文章讲清楚如何对软件缺陷进行管理(4)

模糊提交

测试环境

缺少必要的测试工具和设备。在一个比较大型的网站中，系统在正常负载情况下的性能非常重要，如果测试人员没有一种有效的测试工具或者必要的硬件设备，那么就很难去模拟、再现系统负载的环境。

缺少必要的系统配置。如果是Java开发的程序，我们可能会在多种操作系统上去验证它的正确性和稳定性。

缺少必要的测试用例。好的测试模型可以减少更多的BUG，也可以发现更多潜在的BUG。好的测试用例不仅仅是一系列测试方法的组合，它更大的用处在于和历史积累BUG记录的对比分析。

4、Bug的种类

需求阶段的BUG——来源：

模糊不清的需求

忽略的需求

冲突的需求

分析、设计阶段的BUG——来源：

忽略设计

混乱的设计 ：这样的情况发生在两种设计性质完全相反的情况中，如果在实际的系统中，某块地址规定不允许被多线程访问，而方案却被设计成以多线程方式进行，则会在此层面上产生BUG，严重的会造成整个系统的崩溃。

模糊的设计：模糊BUG产生的原因在于设计人员对需求没有清晰的认识，或者需求本身就是含糊不清的。

实现阶段的BUG——来源：

遗漏的功能

内存溢出：属于一种比较严重的软件BUG类型。例如，软件执行了某些强行向操作系统保护地址写入数据的指令，导致整个环境的彻底崩溃；再如：数值除零导致堆栈溢出

其他实现：表现为出现的错误难以定位其类型，比如在产品化阶段，测试人员或者最终用户提出的部分提高程序运行效率的建议，当然开发人员并不完全处理这些问题，但是这些建议将成为一种特殊的BUG类型，被保留在项目数据库中。

配置阶段的BUG

配置阶段的BUG是最危险的，往往体现在软件交付或者最后的系统测试中。

配置阶段的BUG出现的原因是复杂的，比较典型的是旧的代码覆盖了新的代码；或者测试服务器上的代码和实现人员本机最新代码版本不一致。这些情况造成了错误代码被修改后，经过一个时间段再次回归测试时又会出现同样的问题。

配置阶段的BUG解决方案也很简单，项目组可以指定专人（集成员）进行配置和集成管理，集成员保证正确集成整个系统，并将最新的代码发布到测试服务器或者客户服务器上。这个阶段由QA（质量保证）部门负责监管和控制，规定集成的时间间隔和最佳集成时间，统一维护一份项目组集成人员和集成时间列表。

原文转自：http://www.uml.org.cn/Test/201611161.asp