BUG其实是任何产品都无法避免的一个问题,不是所有的bug都能被发现,包括资深测试,或多或少的会出现线上缺陷,谁也不能把软件所有的功能操作、运用场景想周全。虽说不能做到完全零缺陷,但是每次发布的产品,我们需要追求缺陷越来越少,产品投诉越来越少。
为什么会出现缺陷漏测,主要有以下几点:
需求评审阶段,对业务需求细节理解不明确,未深入挖掘隐含拓展需求。在实际产品研发过程中,产品需求其实处于一个细化过程中,在需求prd文档交互文档输出进行评审时,未能把一些产品细节问题、隐含需求暴漏出来,而测试用例的编写是基于prd交互文档。
测试用例覆盖不全面,场景出现遗漏。在测试用例设计过程中,容易出现思维受限或者需求盲区,我们不可能完全覆盖用户使用的所有场景,编写测试用例的同事不可能把所有的场景都能想周全,把所有的场景下的情况都写成测试用例这也是不大现实的。
测试阶段未严格按照测试用例执行。按照测试用例执行测试,可以让我们尽可能的不出现遗漏一些测试点。但是我们一些同学,不严格按照测试用例来执行测试,这样出现了一些遗漏BUG实在是不应该。
测试环境、测试资源受限,导致缺陷漏测。互联网金融类产品的环境是及其复杂的,业务系统不是孤立存在的,关联方环环相扣,而且关联系统常常出现不稳定的情况,另外涉及身份证、银行卡等稀缺资源的使用有限,往往测试完一个有效数据废弃一个有效数据,所以我们可以尽可能通过mock、还原客户的实际环境(比如联网核查mock,银行卡鉴权mock),但是毕竟不是真实的环境,由于环境的差异,可能出现很多意想不到的问题,这些问题可能只在特性的环境、特定的操作步骤下才会暴露出来,在我们的测试环境还原不出来,只能基于生产环境来验证问题。
开发人员引入的新BUG。有一些开发人员只会针对你所提交的BUG中问题的描叙步骤解决,并不会去排查该问题有可能涉及的所有点,有可能出现解决了这个问题,而引入了一个新的问题。另外,一个不熟悉功能模块的开发人员来修复BUG,因为业务不熟悉,考虑不周全导致无意识的引入新的BUG。
探索性app测试环节欠缺。我们发现的很多BUG都不是按测试用例执行发现出来的,都是在测试过程中随意测试发现的,而这些步骤在测试用例中并未体现,我们的测试用例不可能覆盖所有的场景
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。