移动APP测试之怎么避免Bug漏测？
一、漏测的概率
漏测，是指软件产品的缺陷没有在测试过程中被发现，而是在版本发布之后，用户在使用过程中发现存在的缺陷。
二、预防漏测的意义
我们都知道，缺陷越早被发现，发现和解决缺陷所花的成本就越小，如果缺陷是在测试中发现的，那么所花的成本将小得多。测试
是保证软件质量的最重要手段之一，因此，进行漏测分析、预防漏测、促使缺陷尽可能在开发过程早期被发现，是非常有意义的，它有
利于降低软件产品成本、提高软件产品质量。
三、原因分析
谁都不敢打包票说自己经手测试的东西没有问题，包括资深的测试工程师，或多或少的会出现让缺陷从自己的手中溜走，谁也不能
把软件所有的功能操作、运用场景想周全，但是像神一样的老鸟我就不知道了。
| 漏测原因 | 对应解决方法 |
|
1.需求规格不明确，导致测试用例编写过于粗犷。
|
1.先进行需求分析，找出需求规格说明书中不明确、或有疑虑的地方，与需求人员（产品）确认商讨，给出明确定义。 2.在测试过程中发现没有明确和有疑惑点的，也要与需求人员确认商讨，要求给出明确写定义，之后完成测试用例。 3.无法及时确定的，可先编写大概框架，之后再将测试用例细化，补充完善。 |
|
2.需求规格变更，测试用例未及时更新
|
需求规格变更，导致原来的测试用例与现在的规格不相符合。我们在执行测试用例过程中，如果碰到测试用例与规格不相符合的地方，我们需要记录下，并根据新规格补充完善测试用例，对存在有疑问的地方需要和产品或设计进行沟通和确认，可以要求需求规格进行明确定义，事后将新增的、修改的测试用例整理成文，发给组内同事组织评审，并将评审之后的用例更新到用例库中去。 |
| 3.测试用例覆盖不全面，场景出现遗漏 |
因为测试用例场景设计导致缺陷遗漏是在所难免的，编写测试用例的同事不可能把所有的场景都能想周全，把所有的场景下的 情况都写成测试用例这也是不大现实的。对于外部反馈的缺陷，是因为场景设计不全引起的，我们先分析出现问题的场景是客户必须的场景还是偶然的场景，如果该场景是客户操作习惯，我们可以通过和技术接口人沟通，确认该场景的一些具体细节，在完善测试用例的过程中我们也要考虑一些和该场景相关联的场景，将多种场景下测试用例及时完善、评审，增加到用例库中 |
|
4.测试过程中未严格按照测试用例执行 |
我们需要面对现实，测试用例并不能覆盖所有的使用场景，但是，测试用例是按需求根据规格编写的，经过了需求分析、开发、测试及其他相关人员的评审，最大程度的保证用例的准确性、全面性。测试用例不一定能保证所有的场景和功能点都能覆盖到，但是严格按照测试用例执行测试，能最大程度上保证我们的软件质量，尽量避免出现缺陷。就一句话，我们在测试过程中要严格按照测试用例执行，不要因为测试用例的繁琐而抛弃测试用例，进行随意的测试。如果是因为测试过程中随意的测试，导致出现遗漏问题，实在是不应该。 |
| 5.时间不充足，导致一些功能点在测试过程中被忽略 |
1，根据功能模块划分测试优先级，主要的功能模块优先级最高，安排有经验的人测试，安排新手测试一些不重要的功能模块或者很少使用的功能模块，在后续测试过程中，由有经验的同学将新手测试过的模块进行冒烟测试，确认是否有明显BUG； 2，尽量避免在一些和开发扯不清的情况下浪费自己的时间，如果因为开发人员排查问题占用的时间较长，可以告诉测试负责人，由测试负责人采取相应措施，通过协商来避免类似问题蔓延； 3，增加测试人手 4，加班 |
| 6.测试环境受限，导致缺陷漏测 |
1.原因：环境的组合是无穷的，没有足够的时间、人力和其他资源成本在足够在足够多的环境中测试。 2.措施：保证主要的操作系统环境，网络环境 操作系统：针对当前使用比例来排序 网络环境：正常网速、低网速 |
|
7.开发人员引入的新BUG
8.对产品和应用流程的理解不到位 |
验证开发人员修复的BUG，并将相关联的功能点遍历到 方法：根据开发人员的水平，选择合适的回归测试策略。
|
四、目的
不管是因为什么原因导致缺陷流到客户现场，问题发生了，我们首先要做的就是弥补缺陷带来的影响，项目组要评估由此带来的风险、损失，修正缺陷，提供完善的版本给客户使用。做完前面的这些工作之后，我们可以、甚至是需要自觉的进行思考总结，吸取经验教训，并将出问题的这些情况补充、完善到测试用例中去，对一些常见的情况还需要进行组内学习，避免在以后的工作中再次犯下同样的错误。
如果能做的更好一步，我们可以学习并进行统计，对这些遗漏的BUG予以分类，缺陷的严重程度、所属功能模块、遗漏原因分类等等。我们在进行缺陷漏测分类活动时，可以由专人组织发起讨论，将需求、开发、测试、技术支持以及其他所有产品生命周期中相关部门的代表组织到一起对近期的漏测进行分析讨论，特别是技术支持人员能够提供很多非常详细的关于漏测缺陷的信息，这对漏测分类、累积经验、教训吸取非常有帮助。
进行缺陷漏测分析的目的是为了促进软件质量和开发测试过程得到持续改进，使我们在测试过程中可以考虑得更加周全，弥补思维僵局。具体来讲，就是通过分析测试过程中漏测的缺陷，采取一些相应的预防措施以避免今后再发生类似的漏测。测试过程的持续改进将提高测试环境的效果和测试执行的效率、降低遗留到用户处的缺陷数和缺陷解决成本，从而提升软件的质量。
五、总结
缺陷漏测是不能杜绝的，缺陷漏测发生后，我们需要学会思考，吸取经验教训，尽可能的降低缺陷的漏测量。
一、对需求评审阶段，对业务需求细节理解不明确，未深入挖掘隐含拓展需求
改进措施
需求评审前，我们应该先仔细阅读prd及交互文档，先形成自己对产品的思考，通过脑图的方式列出对产品设计的疑问点,从用户或者从行业角度找出产品设计缺陷点；
需求评审会议中，带着列出的疑问点向产品、开发沟通自己对产品的疑惑和质疑点，多提几个为什么？如何实现？数据获取来源？超出预期的数据怎么处理？缓存处理机制如何？数据保存何处？逻辑由前端处理还是后端服务？后端服务逻辑是否跟第三方关联？
需求评审完成后，按照一定的功能，将需求拆分成若干大模块，大模块拆分成小功能点，然后考虑功能点的具体实现流程。
二、对测试用例覆盖不全面，场景出现遗漏
改进措施
用例设计完成后组织用例评审
（1）组织开发、产品进行测试用例评审，并抛出用例设计时的疑问，通过产品实现角度、数据存储、产品体验角度对用例进行评审完善。
（2）如时间充裕，组织测试组内用例评审也是非常必须的，特别是一些经验老道或者业务熟悉的老司机们，可以在用例评审上快速的帮忙指出用例的遗漏点，有助于测试人员打开思路，尽可能多的覆盖用户场景，值得注意的是用例评审上遇到不确定的，应立即记录下来，结束后及时找相关人员确认，避免猜测。
根据线上用户反馈缺陷完善用例
产品测试发布上线后，对于用户反馈的缺陷，如果缺陷是因为场景设计不全引起的，我们先分析出现问题的场景是必现还是偶现，如果是必现，我们可以通过和技术接口人沟通，确认该场景的一些具体复现步骤，确认引入原因，解决方案。然后进行测试用例完善：除了补充该场景case外，考虑一些和该场景相关联的场景，将多种场景下测试用例及时完善、评审，增加到用例库中去。
三、对测试阶段未严格按照测试用例执行
改进措施
测试用例不一定能保证所有的场景和功能点都能覆盖到，但是严格按照测试用例执行测试，能最大程度上保证产品质量，尽量避免出现缺陷。
另外养成测试纪录习惯：对于测试阻塞用例、测试fail用例，应该重点关注并记录，在回归测试阶段进行精准回归测试，确保修复bug导致关联功能引入的新bug也能被发现。
四、对测试环境、测试资源受限，导致缺陷漏测
改进措施
引入灰度发布测试
测试组在预发布环境上进行回归测试，能基本模拟真实环境执行测试环境无法测试的用例，又不影响线上用户的正常使用。
五、对开发人员引入的新BUG
改进措施
（1）代码review
从代码管理层面：开发修复一个bug提交代码自测通过准备提测时，开发团队提交代码进行代码review，引入新BUG的可能性较小。
（2）精准回归测试
从测试自我修养层面：在开发提测后，通过diff代码的方式，了解代码改动点，精准分析改动点对相关联的功能点的影响，将开发人员修复的BUG确认验证，并将相关联的功能点尽可能在app测试阶段通过遍历回归测试到。
首先，分析一下为什么面试官要提出这个面试题。
漏测是软件测试人员的大忌，也是无比大的锅悬在测试人员的头上，让人不行不紧张。
一旦软件上线出现问题，基本上都会认定是软件测试人员漏测了。但这种现象又是完全避免不了的，故漏测是软件测试人员最为关注的，特别是测试领导。
如何有效避免漏测？
这类问题王豆豆在面试过程没有遇到十回至少也遇到过九回了，可见这个问题在面试过程中出现的频率之高。
那在面试过程中遇到我们应该如何回答呢？
答：首先，漏测这种情况不能百分之百地杜绝，所以我们需要使用测试手段或者测试方法来尽量减少漏测现象的出现。
01
在测试之前：
首先，我们会对需求进行分析，然后再进行需求评审，评审时将产品经理、开发、测试集合在一起开一个评审会议，一起对本次迭代的需求进行讲解，通过评审会议之后测试人员一定要将需求吃透，只有需求完全理解到位，测试工作才能顺利进行。
理解清楚需求之后，测试人员通过各种用例设计方法编写测试用例，用例编写完全后测试小组可以先内部交叉评审后，再联合产品经理、开发人员进行评审会议，这此评审会议主要是检查测试用例是否对需求进行了完全覆盖，此次的评审会议非常重要，这也是避免漏测时最重要的一步。
执行测试之前，测试人员主要要做的就是对需求进行澄清、评审等各种手段来理解需求，掌握需求。
02
在测试之中：
首先，我们会根据事先已经准备好的测试用例（交叉测试）对软件进行测试，特别是对测试用例中优先级别高的用例着重进行测试。
注：测试过程中，测试人员不测试自己编写的测试用例，而测试其他测试人员的用例，达到再次检验。
同时在测试过程中，我们会根据测试情况一边测试一边修改测试用例，以保证测试用例对软件的高匹配。
首轮测试后期，我们会进行内部功能模块交叉测试。
最后我们会进行回归测试，回归测试时测试人员也是交叉回归bug，本轮测试除了回归bug还需要对上轮测试过程中出现bug频率高的功能模块着重测试。
03
在测试结束后：
测试人员召开总结会议，对出现的bug进行分析和总结。
在面试过程中，可以从这三个方面多维度来回答，并且在回答过程中，最好能结合实际的工作经验，比如有进行需求评审和未进行需求评审，最终的测试结果对比，这样就更有说服力。
如果面试官这时还说任务紧没有时间做这些，那又应该怎么办？
答：如果任务紧前期的需求分析和评审就更不能省略，如果产品和开发不能集合到一起进行评审，那也要进行测试内部评审。
需求是软件测试人员最重要的东西，如果需求理解不对，用例设计就不对，那最终的执行结果就会天差地别。
每个测试人员的思维都不一样，考虑的重点也有所差别，评审和头脑风暴是最快捷的解决办法。
如果任务紧，时间不充足，测试用例可以不用写得很详细，以前我们针对这种情况就是采用XMIND进行需求点编写，这样会省时和省力，编写完成后测试人员内部评审。
以上都是从技术的实现角度进行分析的，同时这类面试题不能避免面试官还想考察应聘者的抗压能力，任务紧加班现象基本无法避免。
昨天一个同事说得非常好：
跳出技术层面考虑，有时候面试官其实只是为了考察求职者在面试时的抗压能力，思考问题的逻辑条理是否清晰。
他要的不一定是技术能力上的实操性答案，而是求职者的工作上的软素质，看你的临场应变能力是不是能说服他，至于具体到工作上能不能解决问题，是另外一件事。
所以在回答面试题都需要逻辑条理比较强，王豆豆在面试过程中就喜欢列一二三点去回，这样说有个好处，可以留时间思考，同时给面试官的感觉是条理很清楚，有时就算说第一点时，第二点还没想好，等说完第一点时，第二点就自动到嘴边了。
不管是在面试中喜欢这样，在实际工作中王豆豆也喜欢这样分析问题和解决问题。
这也是经常所说的解决问题的思路，在这里举个简单的例子，如果连接服务器电脑连接不上，应该怎么解决？
也是通过一二三来解决的：
第一步：先检查自己的电脑的网络状况
第二步：检查自己电脑的IP和服务器IP是否在同一个网段下
第三步：ping服务器的IP，结果有二，ping得通或者ping不通，一般情况下只要ping得通，连接都没问题
第四步：ping不通，检查自己的电脑防火墙是否开启，如果开启的，关闭了再ping
第五步…………
这样依次逐步排出故障，这就是解决问题的思路。
上面提到的“如何有效避免漏测？”的解决办法在实际工作中也可以使用，这并不只是理论，这完全是来自于实践，只是在工作中会根据实际项目的情况而调整优先级或者增加新的解决方法。
-
需求评审
参加需求评审会，理解需求文档，在编码前找出需求的bug，与客户以及研发在需求的理解上达成一致的观念。但是也可能存在以下的问题：
1.没有需求文档？客户对需要的产品目标不明确，研发人员也不明确，这个时候，只能使用敏捷开发，把产品开发出来之后，先给用户使用，然后再根据用户提示的问题进行修改，这样的bug都比较难确定；
2.需求总是不能固定？不固定需求就会引出问题，然后引出一系列的bug；
3.需求已经定义，是否吻合客户实际应用？ 那么，这就需要我们在理解完需求之后，找用户进行确认，并通知项目的参与人员，进行一个有效的需求评审会议。是大家对需求都达到一致的认识。
-
梳理需求，尽早与开发人员、需求人员进行需求确认，统一不同角色对需求的认识
开发测试人员都可能存在对需求的认识不一致。越早进行，越能够避免出现因为对需求的认识不同而导致出现的问题（最可怕的是因此产生的隐性bug），这样也能减少后期很多不必要的资源浪费。
-
用例设计与评审
1.前期的模块支持数据量的调研和要求
2.用例编写考虑面要广，包括:使用不同的测试方法，不同的测试数据类型，正常流与异常流等来覆盖所有的需求。
3.如果缺少评审，自己抽时间找研发同事沟通用例的覆盖度，查漏补缺
-
测试执行
在固定的时间内，尽可能全面地执行测试用例。
1.在测试过程中不断的添加遗漏的用例，一定要在发现时及时补充，有些用例是无意间操作发现的；
2.详细标识每一个被执行过的用例。
-
bug回归
测试过程中，遇到过一个小小的参数变动可能引起一个比较远的功能点的大bug，开发不知道，测试不清晰，势必引发遗漏。在修改bug的这种情况下，有可能是牵一发而动全身的，是非常危险的。如果研发考虑的不周全，只修改了此bug，并没有考虑到与它接口的功能，那将会引发更多的bug。
-
发布前的功能回归
1.首先保证所有fixed的bug验证通过，并且没有引起别的bug；
2.在测试的过程中，最好自己编写checklist表，这样到最后一轮的时候，就不用再执行测试用例，只要执行一下checklist表就可以了。（checklist表记录的就是在测试中容易出bug而且比较重要的模块的简易测试用例）
3.如果时间和技术允许的话，可以使用QTP进行自动化脚本，方便回归。
4.细心细心再细心。只要一步步走下来，那么就可以把遗漏的bug数量减到最低。一句话，减少漏测的方法就是相关的文档全面化，标准化，统一化。
-
