我们在日常的测试工作中不可避免的会遇到各式各样的bug，假如有人问到什么是bug以及bug的管理流程，我想你们一定都会倒背如流，通过我们之前的学习已经知道，bug主要是由以下几个方面产生：
使用软件应用程序或产品的人员没有足够的产品知识；
软件的错误使用方式；
开发的编码不正确，使得设计中存在bug；
测试环境的设置不正确等等；
但是今天只说常见的bug是什么时候产生的，其他的不谈。为了使讲的不那么枯燥，就直接就一个例子来说，如下图：
从上图中我们可以看到一共有4个需求：
需求 1：得到了正确的实施：理解了客户的需求，设计了正确的架构去满足，并且正确的码了逻辑，因此我们提供了满足该需求的所有属性：在功能上，它做什么，它也有正确的非功能属性，而且它足够快，易于理解，等等（理想的完美情况）；
需求 2：需求的分析和构建阶段一直很好，直到编码的时候，犯了一些错误，引入了bug。如果我们测试在测试过程中发现了bug，并且开发及时的修正了，就会大幅降低bug的发生率，但是由于各种原因，测试并没有触发所有隐藏的bug，所以，当验收的时候，我们就看到了产品是不符合其设计规范的（常见的情况）。
需求 3：在这个需求中引入的bug更难处理：开发是完全按照他们被告知的架构建造的，但很不幸的是架构师犯了一些错误，所以在设计上存在缺陷。除非我们检查需求的原始定义，否则在测试期间是不会发现这些bug的。而我们注意到它们时，它们将很难修复，因为需要更改整个程序的设计（极少情况）。
需求 4：这个产品的设计和制造是为了满足有缺陷的需求定义。如果我们测试的产品符合其要求和设计，它将通过测试（毕竟我们都是以需求为准），但可能会被用户或客户拒绝。修正客户在验收测试或现场使用中报告的bug会非常昂贵，有句话不是这么说的么：”越前期发现的bug修复它的成本越低“，不幸的是，需求和设计的缺陷在我们的实际项目中并不罕见，通常在需求和设计过程中引入的bug几乎占bug总数的一半。
了解软件中的bug在什么时候产生，会使你对整个项目有个整体的印象，从而对bug的定位起到一定的帮助作用，而且最重要的，有可能会增加你撕逼获胜的筹码。
网友评论