时间压力

　　● 时间是一种宝贵的资源。

　　● 所有软件项目时间都需要被精确估算。可是夹杂着预计、猜测这些不稳定的因素，当最终期限迫近和关键时刻到来之际，错误也就跟着出现了。

　　文档贫乏

　　● 贫乏或者差劲的文档使得代码维护和修改变得异常艰辛，其结果是带来许多错误。

　　● 区分职业实现人员的方法并不是看他有几年的编码经验，而在于其是否有良好的先文档后实现的习惯。

　　● 文档代表着一种特殊的记忆，没有它的存在对人对己都不利。

　　软件开发工具

　　● 总是希望通过更加先进的工具来避免BUG的出现，这就患上了典型的银弹综合症。

　　● 开发工具可能使我们摆脱某些问题的出现，并且提高工作效率。实际上，现代的开发工具对整个软件质量尤其是可靠性并没有什么重大的影响。

　　3、Bug如何穿透测试

　　代价太大

　　● 正规的软件公司会引入QA，对项目整个过程进行全方位的质量保证工作。但是执行QA需要调用很多的资源，比如要检查和复审需求阶段输出的标准工件，就需要高水平的分析员加入，但是通常他们时间很少很宝贵，并且不会有太多的精力顾及此事。

　　● 在设计和实现阶段，随着大量审查工作的介入，所有该阶段的参与人员都要付出更多的时间和精力来参与。

　　● 这些形式的检查、审查和测试延长了整个项目的开发过程，这些附加的工作时间都会直接变成附加费用，大大增加了整个项目的造价。

　　市场决策

　　● 即使测试人员发现了产品中的BUG，但是公司会觉得修复BUG将延长整个产品的发布时间，有可能错过销售的旺季（可能是每年的5-10月份），并且会打乱整个公司针对该产品的销售计划，在确认产品中的BUG不是非常严重的情况下，软件被销售了。但是，如果这是航天、医疗、股票交易的管控软件系统，如带有BUG，则发布后果是非常严重的，但是对于某些行业这样的做法是可行的。

　　时间紧迫

　　● 测试要花费大量的时间，至今尚未有一种自动化的测试工具能够全面和高效率地测试一套软件产品。

　　● 测试项目经理接到测试任务后表现得过于乐观，没有考虑任务的风险。

　　● 开发人员过高估计自己的能力，认为所有的BUG都是微不足道、便于修复的。他让测试工作和编码工作同时进行，这样根本没办法保证测试的正确性。并且在时间紧迫的时候，大多数测试员只是选择明显的几条程序路径测试或者输入不完整的测试数据，这些都造成了大量的BUG纰漏。

　　现场证据

　　● 有时会遇到这种问题，发现了BUG但是不知道怎么把它明显地表示出来。不能向开发人员提供足够的证据报告，是测试人员的耻辱，开发人员同样会根据这样的报告讥笑测试人员的所作所为。

　　● BUG的可重现性，与导致BUG出现的原因有着密切的联系。

　　● BUG的可重现性也体现了测试人员对软件系统的熟悉程度。

　　● BUG的可重现性，也体现在操作的顺序上。

　　过于自信

　　● 开发人员是非常不诚恳的测试人员，他们总是说“我做的肯定没问题”或者“不可能呀，它在我的机器上跑得好好的”。有的时候项目管理者也很自负，过于相信团队成员的表现，而不去理会测试人员或者客户的抱怨。

　　● Titanic灾难就充分体现了人类的自信，我们有足够的水密舱就算破了5个船也不会沉。

　　● 没有详细的测试计划，没有严谨的测试行为，不再关注每个细小的环节，这样BUG就从旁边悄悄溜走了。

　　模糊提交

　　测试环境

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

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

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