哎呀，当时怎么没有想到
导读
在我们的测试工作中，是不是经常遇到这样的情形，发生了线上问题，产品、研发或者测试同学一拍脑袋：当时怎么没有想到，怎么给漏掉了呢？明明是一个非常简单的事情，用大拇指都能想到的验证场景，为何当时就漏测了呢？但实际情况是，逃逸到线上的缺陷，疑难杂症式的极端异常的问题很少，大部分都不复杂且可以在设计和开发中规避，或者在测试过程中被识别出来。针对此类问题，从测试覆盖度的角度，本文试图解释一下为何会发生这样的事情，以及如何有效规避。
导读
在我们的测试工作中，是不是经常遇到这样的情形，发生了线上问题，产品、研发或者测试同学一拍脑袋：当时怎么没有想到，怎么给漏掉了呢？明明是一个非常简单的事情，用大拇指都能想到的验证场景，为何当时就漏测了呢？但实际情况是，逃逸到线上的缺陷，疑难杂症式的极端异常的问题很少，大部分都不复杂且可以在设计和开发中规避，或者在测试过程中被识别出来。针对此类问题，从测试覆盖度的角度，本文试图解释一下为何会发生这样的事情，以及如何有效规避。
01 为什么经常会发生测试场景覆盖不全的问题
在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！
高质量的测试覆盖率是确保产品质量和用户体验的关键因素，但为何会经常发生测试场景覆盖不全的问题，这里面既有主观因素的缺失，也有客观因素的限制，具体包括：
1. 主观原因
粗心大意：认为需求非常简单，没有认真分析验证场景及异常流程、分支流程，没有识别隐藏的细节，或者对于存在的风险，存在侥幸心理，不去进一步求证或验证。
经验主义：思维固化，认为老办法同样可以解决新问题，没有进一步思考测试场景、测试数据、验证方式的不同之处。
需求理解不充分：测试用例只覆盖到了产品PRD里的显式功能，没有覆盖隐性需求，只进行了黑盒测试或者黑盒测试覆盖的场景不足。
业务知识不足：只看到了需求本身，没有看到背后隐藏的业务的真正诉求，知其然不知其所以然。
开发知识欠缺：无法熟读代码，无法通过参加代码评审识别出研发代码改动之处及可能影响的范围，望码兴叹，无法熟练进行白盒测试，或者自动化测试代码健壮性较差，无法起到自动化回归的作用。
信息互通不到位：与项目组其他成员沟通不到位，遗漏重要信息或没有对齐颗粒度，你以为的实际不是你以为，导致遗漏重要验证场景。
用例颗粒度太大：编写用例的过程也是自己梳理信息的过程，用例颗粒度大，自然梳理的过程就不会太精细，自然遗漏验证场景的几率就会更大（虽然探索式测试的理念是不要求编写详细的测试用例，而是在测试过程中不断调整、优化或细化，但很多需求不太适合探索式测试，这些需求要求快速上线，排期被严重挤压，很难有充足的时间进行探索式测试）。
测试专业技能薄弱：测试专业技能、经验不足，力所不及，自然无法保证测试的充分性及验证场景的全面性。
2. 客观原因
项目周期紧凑：目前很多需求都无法按照研发测试的正常排期进行交付，倒排期和赶工是常态，测试很难有充分的时间思考验证场景，新功能的测试往往只能覆盖主要路径，而忽略了一些边界情况和异常场景。
需求变更频繁：迭代快、变更快也是产品常态，往往一期还没有上线，二期三期就要评审了，没有经过线上真实环境、数据和客户的反馈，产品方案、技术方案存在的缺陷可能无法暴露或识别到。
投放渠道众多：尤其是针对C端用户的拉新和促活活动，投放渠道非常多，涉及在不同的承接环境，如App环境（iOS、安卓、鸿蒙）、H5环境、小程序环境，同时涉及到不同设备、不同环境、不同操作系统版本、不同浏览器的打开、回流、引导下载等操作，兼容性测试覆盖不足可能导致无法识别到特定设备下的功能或体验问题。
流量情况悬殊：各个投放渠道流量差异较大，若上线前没有对各渠道的流量有充分的预估，没有进行压测，在高并发、大数据量或复杂业务场景下，性能问题可能无法被及时发现，从而导致线上问题。
测试环境仿真度低：目前很多系统之间存在测试环境未打通、测试环境数据不全等问题，导致测试环境的仿真度较低，可能出现测试环境无法模拟真实环境，或测试环境无法覆盖全部验证场景的情况。
02
如何提升测试覆盖度
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。
为了尽量避免因测试场景覆盖不足所导致的线上问题，需要针对以上客观和主观原因进行分析，并制定行之有效的对策。总结来说，在测前、测中及测后，提升"内因"，把控“外因”，避免“三拍”。
测前：充分理解，不盲目拍胸脯保证。
测试工作不是始于测试执行之时，而应前置到需求阶段，测试同学应具备基本的业务Know-How，充分理解业务逻辑及研发逻辑，面对具体的业务需求，不仅停留在功能实现层面，更应理解此需求背后的业务诉求。在前置编写及评审测试用例的时候，与产品、研发充分沟通产品逻辑及技术实现方案是否与业务逻辑及真正的业务诉求保持一致，充分讨论业务风险和技术风险。总之，绝不能不求甚解、掉以轻心，应不懂就问，多沟通，多讨论风险，敢于发问，敢于质疑。 在测试专业能力方面，采用灵活的质量策略，如进行代码覆盖率分析，实施精准测试和探索式测试，维护贴近生产的测试环境和测试数据、更高覆盖率的的自动化测试，以及适合业务特点的测试工具等等。
测中：充分识别，不草率拍脑袋决策。按照我们前置测试用例的逻辑，大部分需求的测试用例在开发阶段或开发之前就已经编写并评审完毕，但随着交付进度的进行，各方对需求的理解不断加深，即使进入到测试阶段，仍可能会识别出新的范围、风险或问题，因此，应不断就验证范围、风险、异常场景等进行确认，并标注出核心验证点、测试过程中可能出现的问题和风险，及时调整和改进测试策略。还应共识双向的影响范围，即该需求是否影响了其他业务功能或技术模块，其他功能或技术模块是否影响该需求。 测后：充分总结，不惊慌拍大腿懊悔。测试完成及上线不是终点，除了配合业务进行线上验证及观察线上数据、进行线上巡检之外，还应花点时间回顾一下交付的过程，总结经验教训，主动分享。对于核心的用例，看能否沉淀为自动化的回归及巡检用例。万一出现了线上问题，先尽快恢复业务，再分析原因，进行复盘，总结教训和改进方案。
总结一下，针对如何提升测试覆盖度，“内因”是关键，基本可以解决上述“主观原因”导致的测试覆盖不足的问题，“外因”是基础，基本可以解决上述“客观原因”导致的测试场景覆盖不足的问题。
03 综述
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。 1.位图原理
总结来说，防止线上问题不能停留在口头上，或者简单粗暴地要求测试同学提升测试覆盖度，应该给与更加具体的要求、指导及评价的标准。其关键要素是流程机制确保基本的质量，专业能力进一步提升质量，主观能动性构建持续的高质量，只有不断提升“内因”并把控好“外因”，才能有效防范“漏测”问题的发生，持续交付稳定可靠的产品，并提供更好的用户体验。
求分享
求点赞
求在看