在咱们的测试工作中，是不是常常遇到这样的情景，产生了线上问题，产品、研发或者测试同学一拍脑袋：过后怎么没有想到，怎么给漏掉了呢？明明是一个非常简单的事件，用大拇指都能想到的验证场景，为何过后就漏测了呢？但理论状况是，逃逸到线上的缺点，疑难杂症式的极其异样的问题很少，大部分都不简单且能够在设计和开发中躲避，或者在测试过程中被辨认进去。针对此类问题，从测试覆盖度的角度，本文试图解释一下为何会产生这样的事件，以及如何无效躲避。
一. 为什么常常会产生测试场景笼罩不全的问题
高质量的测试覆盖率是确保产品质量和用户体验的关键因素，但为何会常常产生测试场景笼罩不全的问题，这外面既有主观因素的缺失，也有客观因素的限度，具体包含：
1. 主观原因
• 粗枝大叶 ：认为需要非常简单，没有认真剖析验证场景及异样流程、分支流程，没有辨认暗藏的细节，或者对于存在的危险，存在侥幸心理，不去进一步求证或验证。
• 经验主义 ：思维固化，认为老办法同样能够解决新问题，没有进一步思考对测试场景、测试数据、验证形式的不同之处。
• 需要了解不充沛 ：测试用例只笼罩到了产品 PRD 里的显式性能，没有笼罩隐性需要，只进行了黑盒测试或者黑盒测试笼罩的场景有余。
• 业务知识有余 ：只看到了需要自身，没有看到背地暗藏的业务的真正诉求，知其然不知其所以然。
• 开发常识欠缺 ：无奈熟读代码，无奈通过加入代码评审辨认出研发代码改变之处及可能影响的范畴，望码兴叹，无奈纯熟进行白盒测试，或者自动化测试代码健壮性较差，无奈起到自动化回归的作用。
• 信息互通不到位 ：与项目组其余成员沟通不到位，脱漏重要信息或没有对齐颗粒度，你认为的理论不是你认为，导致脱漏重要验证场景。
• 用例颗粒度太大 ：编写用例的过程也是本人梳理信息的过程，用例颗粒度大，天然梳理的过程就不会太精密，天然脱漏验证场景的几率就会更大_（尽管摸索式测试的理念是不要求编写具体的测试用例，而是在测试过程中一直调整、优化或细化，但目前咱们目前的环境不太适宜摸索式测试，因为绝大部分需要都要求疾速上线，大部分需要都存在挤压排期的现场，在测试阶段很难有短缺的工夫进行摸索式测试）_。
• 测试专业技能单薄 ：测试专业技能、经验不足，鞭长莫及，天然无奈保障测试的充分性及验证场景的全面性。
2. 客观原因
• 我的项目周期紧凑 ：目前很多需要都无奈依照研发测试的失常排期进行交付，倒排期和赶工是常态，测试很难有充沛的工夫思考验证场景，新性能的测试往往只能笼罩次要门路，而疏忽了一些边界状况和异常情况。
• 需要变更频繁 ：迭代快、变更快也是产品常态，往往一期还没有上线，二期三期就要评审了，没有通过线上实在环境、数据和客户的反馈，产品计划、技术计划存在的缺点可能无奈辨认到。
• 投放渠道泛滥 ：尤其是针对 C 端用户的拉新和促活流动，投放渠道十分多，波及到不同在不同的环境运行，如 App 环境（iOS、安卓、鸿蒙）、H5 环境、小程序环境，同时波及到不同设施、不同环境、不同操作系统版本、不同浏览器的关上、回流、疏导下载等操作，兼容性测试笼罩有余可能导致在某些环境下呈现问题。
• 流量状况迥异 ：各个投放渠道流量差别较大，若上线前没有对各渠道的流量有充沛的预估，没有进行压测，在高并发、大数据量或简单业务场景下，性能问题可能无奈被及时发现，从而导致线上问题。
• 测试环境仿真度低 ：目前普遍存在零碎之间测试环境不联通、测试环境数据不全等问题，导致测试环境的仿真度较低，可能呈现测试环境无奈模仿实在环境，或测试环境无奈笼罩全副验证场景的状况。
二. 如何晋升测试覆盖度
为了解决测试场景未笼罩导致线上问题的状况，进一步晋升测试覆盖度，须要针对以上客观原因及主观原因进行剖析，造成有针对性的对策。总结来说，在测前、测中及测后，晋升 ” 内因 ”，把控“外因”，防止“三拍”。
1. 内因
晋升测试覆盖度，“内因”是要害，即能够通过踊跃的品质策略以及业余能力的晋升，大大减少测试覆盖度有余的状况。
• 测前： 充沛了解， 不自觉拍胸脯保障 。
◦测试工作不是始于测试执行之时，而应前置到需要阶段，测试同学应具备根本的业务 Know-How，充沛了解业务逻辑及研发逻辑，面对具体的业务需要，不仅停留在性能实现层面，更应了解此需要背地的业务诉求。在前置编写及评审测试用例的时候，与产品、研发充沛沟通产品逻辑及技术实现计划是否与业务逻辑及真正的业务诉求保持一致，充沛探讨业务危险和技术危险。总之，绝不能不求甚解、漫不经心，应不懂就问，多沟通，多探讨危险，敢于提问，敢于质疑。
◦在测试业余能力方面，采纳灵便的品质策略，如进行代码覆盖率剖析，实时精准测试和摸索式测试，贴近生产的测试环境和测试数据、更高覆盖率的的自动化测试，以及适宜业务特点的测试工具等等。
• 测中：充沛辨认， 不粗率拍脑袋决策 。在测试执行阶段，依照咱们前置测试用例的逻辑，此时应该大部分需要的测试用例曾经编写结束，但随着交付进度的进行，各方对需要的了解一直加深，可能会辨认出新的范畴、危险或问题，因而，在进行测试用例评审时，应再次就验证范畴、危险、异样场景等进行确认，并标注出外围验证点，注测试过程中的问题和危险，及时调整和改良测试策略。还应共识双向的影响范畴，即该需要是否影响了其余业务性能或技术模块，其余性能或技术模块是否影响该需要。
• 测后：充沛总结， 不惊恐拍大腿后悔 。测试实现及上线不是起点，除了配合业务进行线上验证及察看线上数据、进行线上巡检之外，还应花点工夫回顾一下交付的过程，总结经验教训，被动分享。对于外围的用例，看是否积淀为自动化的回归及巡检用例。万一呈现了线上问题，先尽快恢复业务，再剖析起因，进行复盘，总结教训和改良计划。
2. 外因
晋升测试覆盖度，“外因”是根底，即通过流程机制的束缚及全流程的品质把控，层层把关，相互补位，从机制上升高测试场景脱漏产生的概率。通过规范化的品质流动对需要交付的各个阶段进行品质准入和准出，步步为营，造成强制性的“七道关卡”，只有是严格遵守这套流程机制，上一道关卡脱漏下来的问题，可能会被下一道关卡辨认进去，因而，脱漏验证场景的从而导致缺点逃逸到线上的概率会被大大降低。
总结一下，针对如何晋升测试覆盖度，“内因”是要害，根本能够解决上述“主观原因”导致的测试笼罩有余的问题，“外因”是根底，根本能够解决上述“客观原因”导致的测试场景笼罩有余的问题。
三. 综述
总结来说，避免线上问题不能停留在口头上，或者简略粗犷地要求测试同学晋升测试覆盖度，应该给与更加具体的要求、领导及评估的规范。其要害因素是流程机制确保根本的品质，业余能力进一步增进品质，主观能动性构建继续的高质量，只有一直晋升“内因”并把控好“外因”，能力无效防备“漏测”问题的产生，继续交付稳固牢靠的产品，并提供更好的用户体验。
作者：京东科技 王先科
起源：京东云开发者社区 转载请注明起源