软件测试中的bug是什么时候产生的？你知道吗？

我们在日常的测试工作中不可避免的会遇到各式各样的bug， 假如有人问到什么是bug以及bug的管理流程，我想你们一定都会倒背如流，通过我们之前的学习已经知道， bug主要是由以下几个方面产生：

使用软件应用程序或产品的人员没有足够的产品知识；

软件的错误使用方式；

开发的编码不正确， 使得设计中存在bug；

测试环境的设置不正确等等；

但是今天只说常见的bug是什么时候产生的， 其他的不谈。为了使讲的不那么枯燥，就直接就一个例子来说，如下图：

从上图中我们可以看到一共有4个需求：

需求 1：得到了正确的实施： 理解了客户的需求，设计了正确的架构去满足，并且正确的码了逻辑，因此我们提供了满足该需求的所有属性：在功能上，它做什么，它也有正确的非功能属性， 而且它足够快，易于理解，等等（理想的完美情况）；

需求 2：需求的分析和构建阶段一直很好， 直到编码的时候，犯了一些错误，引入了bug。如果我们测试在测试过程中发现了bug，并且开发及时的修正了，就会大幅降低bug的发生率，但是由于各种原因，测试并没有触发所有隐藏的bug，所以，当验收的时候， 我们就看到了产品是不符合其设计规范的（常见的情况）。

需求 3：在这个需求中引入的bug更难处理： 开发是完全按照他们被告知的架构建造的，但很不幸的是架构师犯了一些错误，所以在设计上存在缺陷。除非我们检查需求的原始定义， 否则在测试期间是不会发现这些bug的。而我们注意到它们时，它们将很难修复，因为需要更改整个程序的设计（极少情况）。

需求 4：这个产品的设计和制造是为了满足有缺陷的需求定义。 如果我们测试的产品符合其要求和设计，它将通过测试（毕竟我们都是以需求为准），但可能会被用户或客户拒绝。 修正客户在验收测试或现场使用中报告的bug会非常昂贵，有句话不是这么说的么：”越前期发现的bug修复它的成本越低“，不幸的是，需求和设计的缺陷在我们的实际项目中并不罕见，通常在需求和设计过程中引入的bug几乎占bug总数的一半。

了解软件中的bug在什么时候产生，会使你对整个项目有个整体的印象，从而对bug的定位起到一定的帮助作用，而且最重要的， 有可能会增加你撕逼获胜的筹码。

最后:【可能给予你帮助】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你

.
关注我的微信公众号【软件测试小dao】免费获取~

我的学习交流群：1033482984 群里有技术大牛一起交流分享~

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！