BUG漏测的原因总结,以及如何处理

简介: 一、漏测的概率    漏测,是指软件产品的缺陷没有在测试过程中被发现,而是在版本发布之后,用户在使用过程中发现存在的缺陷。

一、漏测的概率

    漏测,是指软件产品的缺陷没有在测试过程中被发现,而是在版本发布之后,用户在使用过程中发现存在的缺陷。

二、预防漏测的意义

        我们都知道,缺陷越早被发现,发现和解决缺陷所花的成本就越小,如果缺陷是在测试中发现的,那么所花的成本将小得多。测试

是保证软件质量的最重要手段之一,因此,进行漏测分析、预防漏测、促使缺陷尽可能在开发过程早期被发现,是非常有意义的,它有

利于降低软件产品成本、提高软件产品质量。

三、原因分析

        谁都不敢打包票说自己经手测试的东西没有问题,包括资深的测试工程师,或多或少的会出现让缺陷从自己的手中溜走,谁也不能

把软件所有的功能操作、运用场景想周全,但是像神一样的老鸟我就不知道了。


漏测原因
对应解决方法


1.需求规格不明确,导致测试用例编写过于粗犷。

      


1.先进行需求分析,找出需求规格说明书中不明确、或有疑虑的地方,与需求人员(产品)确认商讨,给出明确定义。

2.在测试过程中发现没有明确和有疑惑点的,也要与需求人员确认商讨,要求给出明确写定义,之后完成测试用例。

3.无法及时确定的,可先编写大概框架,之后再将测试用例细化,补充完善。

2.需求规格变更,测试用例未及时更新

    


需求规格变更,导致原来的测试用例与现在的规格不相符合。我们在执行测试用例过程中,如果碰到测试用例与规格不相符合的地方,我们需要记录下,并根据新规格补充完善测试用例,对存在有疑问的地方需要和产品或设计进行沟通和确认,可以要求需求规格进行明确定义,事后将新增的、修改的测试用例整理成文,发给组内同事组织评审,并将评审之后的用例更新到用例库中去。

3.测试用例覆盖不全面,场景出现遗漏


       因为测试用例场景设计导致缺陷遗漏是在所难免的,编写测试用例的同事不可能把所有的场景都能想周全,把所有的场景下的  情况都写成测试用例这也是不大现实的。对于外部反馈的缺陷,是因为场景设计不全引起的,我们先分析出现问题的场景是客户必须的场景还是偶然的场景,如果该场景是客户操作习惯,我们可以通过和技术接口人沟通,确认该场景的一些具体细节,在完善测试用例的过程中我们也要考虑一些和该场景相关联的场景,将多种场景下测试用例及时完善、评审,增加到用例库中


4.测试过程中未严格按照测试用例执行

       我们需要面对现实,测试用例并不能覆盖所有的使用场景,但是,测试用例是按需求根据规格编写的,经过了需求分析、开发、测试及其他相关人员的评审,最大程度的保证用例的准确性、全面性。测试用例不一定能保证所有的场景和功能点都能覆盖到,但是严格按照测试用例执行测试,能最大程度上保证我们的软件质量,尽量避免出现缺陷。就一句话,我们在测试过程中要严格按照测试用例执行,不要因为测试用例的繁琐而抛弃测试用例,进行随意的测试。如果是因为测试过程中随意的测试,导致出现遗漏问题,实在是不应该。
5.时间不充足,导致一些功能点在测试过程中被忽略

1,根据功能模块划分测试优先级,主要的功能模块优先级最高,安排有经验的人测试,安排新手测试一些不重要的功能模块或者很少使用的功能模块,在后续测试过程中,由有经验的同学将新手测试过的模块进行冒烟测试,确认是否有明显BUG;

2,尽量避免在一些和开发扯不清的情况下浪费自己的时间,如果因为开发人员排查问题占用的时间较长,可以告诉测试负责人,由测试负责人采取相应措施,通过协商来避免类似问题蔓延;

3,增加测试人手

4,加班

6.测试环境受限,导致缺陷漏测

1.原因:环境的组合是无穷的,没有足够的时间、人力和其他资源成本在足够在足够多的环境中测试。

2.措施:保证主要的操作系统环境,网络环境

操作系统:针对当前使用比例来排序

网络环境:正常网速、低网速


7.开发人员引入的新BUG


8.对产品和应用流程的理解不到位

验证开发人员修复的BUG,并将相关联的功能点遍历到

方法:根据开发人员的水平,选择合适的回归测试策略。


四、目的

      不管是因为什么原因导致缺陷流到客户现场,问题发生了,我们首先要做的就是弥补缺陷带来的影响,项目组要评估由此带来的风险、损失,修正缺陷,提供完善的版本给客户使用。做完前面的这些工作之后,我们可以、甚至是需要自觉的进行思考总结,吸取经验教训,并将出问题的这些情况补充、完善到测试用例中去,对一些常见的情况还需要进行组内学习,避免在以后的工作中再次犯下同样的错误。


  如果能做的更好一步,我们可以学习并进行统计,对这些遗漏的BUG予以分类,缺陷的严重程度、所属功能模块、遗漏原因分类等等。我们在进行缺陷漏测分类活动时,可以由专人组织发起讨论,将需求、开发、测试、技术支持以及其他所有产品生命周期中相关部门的代表组织到一起对近期的漏测进行分析讨论,特别是技术支持人员能够提供很多非常详细的关于漏测缺陷的信息,这对漏测分类、累积经验、教训吸取非常有帮助。


  进行缺陷漏测分析的目的是为了促进软件质量和开发测试过程得到持续改进,使我们在测试过程中可以考虑得更加周全,弥补思维僵局。具体来讲,就是通过分析测试过程中漏测的缺陷,采取一些相应的预防措施以避免今后再发生类似的漏测。测试过程的持续改进将提高测试环境的效果和测试执行的效率、降低遗留到用户处的缺陷数和缺陷解决成本,从而提升软件的质量。


五、总结

缺陷漏测是不能杜绝的,缺陷漏测发生后,我们需要学会思考,吸取经验教训,尽可能的降低缺陷的漏测量。

来源:http://blog.51cto.com/11392572/2105018 

作者 七色洋



相关文章
|
6月前
bug长时间未修复该怎么办?
bug长时间未修复该怎么办?
bug长时间未修复该怎么办?
|
6月前
|
测试技术
无法复现的bug,如何处理?
无法复现的bug,如何处理?
459 0
|
6月前
|
测试技术 API
修改bug引入更多bug怎么办?
修改bug引入更多bug怎么办?
127 0
|
6月前
你真的会提交缺陷单吗?俗称报bug
你真的会提交缺陷单吗?俗称报bug
108 0
你真的会提交缺陷单吗?俗称报bug
|
5月前
|
前端开发 安全 JavaScript
如何区分是前端BUG还是后端BUG
1 基于经验 前端BUG特点: (1)界面排版、布局错误、兼容性问题 (2)网络不稳定导致JS或CSS未完全加载或请求超时(一般不需要提BUG),正常网络下加载超时 后端BUG特点: 业务逻辑、性能问题、数据问题、安全性问题 2 通过HTTP请求和响应信息 可以通过浏览器开发者工具(F12)、postman、fiddler(移动端可通过该工具抓包)、Charles、Proxyman、Wireshark、HttpCanary、tcpdump等工具。
85 1
|
5月前
|
JavaScript Java
做小程序时遇到的bug
做小程序时遇到的bug
|
6月前
|
测试技术
需求不明确的情况下,测试该如何处理?
需求不明确的情况下,测试该如何处理?
130 0
|
小程序 Android开发 iOS开发
小程序 | 小程序修复了一些bug
前段时间,有朋友反应小程序的今天吃个啥有bug,不能正常使用。
140 0
|
JavaScript 前端开发 Java
干货|各种语言是怎么处理时间的?以及常见的 bug
干货|各种语言是怎么处理时间的?以及常见的 bug
123 0
|
Java
以下代码找bug
以下代码找bug
120 0