1.后台泄漏测试BUG是指在测试过程中没有发现的产品逻辑缺陷（尤其是在测试环境中可以复现的缺陷），在上线后或上线后才被发现并反馈用户体验。可能导致上线失败或资产损失。在产品测试的过程中，难免会漏掉一些bug。因此，将对错误和漏测进行一些思考和总结。2、原因分析Bug其实是任何一个应用产品都会有的问题。不是所有的bug都能发现，包括高级测试，或多或少都会出现线上缺陷，也没有人能操作软件的所有功能，请慎重考虑应用场景。虽然不可能做到完全零缺陷，但我们每发布一个产品，都需要追求缺陷越来越少，产品质量越来越高，减少线上问题的反馈。缺陷缺失的主要原因如下：2.1在需求评审阶段，对业务需求细节理解不清晰，设计不合理，没有深入挖掘隐藏的扩展需求。在实际的产品开发过程中，产品需求实际上是在细化、优化、下钻的过程中，需要PRD文档的交互式文档输出进行审核时，一些产品细节和隐性需求没有暴露出来，而测试案例是基于PRD编写的，交互式文档和它自己对需求的经验理解涉及测试用例。在回顾改进措施需求前，认真阅读PRD和交互文档，形成自己对产品的思考，通过脑图列出产品设计的疑点，站在用户的角度找出产品设计缺陷还是来自行业。在需求评审会上，把你对产品的疑惑和疑惑连同列出的疑惑传达给产品和开发，多问why？如何实现？数据采集??源？如何处理超出预期的数据？缓存处理机制如何？数据存储在哪里？逻辑是由前端处理还是由后端提供服务？后端服务逻辑是否关联第三方？需求评审完成后，根据一定的功能，将需求划分为若干个大模块，大模块又划分为小的功能点，然后考虑功能点的具体实现过程，对模块功能进行分析通过思维导图细分，从页面到交互、边界处理、界面逻辑、环境配置等维度梳理需求，尽可能挖掘出隐藏的、可扩展的需求点，然后进行需求评审和测试组技术评审，让协作成员共同补充隐性需求，使产品设计缺陷尽早暴露并最大化。后期技术回顾，讨论逻辑交互、上下游数据趋势、消息发送流向，连接技术端疑惑。2.2测试用例覆盖不全和缺失场景分析在测试用例设计过程中，容易出现思维局限或需求盲区。我们不可能完全覆盖用户使用的所有场景，写测试用例也不可能包含所有场景。把所有场景下的所有情况都写成测试用例来模拟覆盖是不现实的。改进措施在用例设计开始前，列出思维导图，通过思维导图列出业务流程、前后端接口逻辑。然后根据PRD和交互文档，根据UI界面，分成大功能块，然后在大功能块中，再在大功能块中，再分成小功能块，最后到功能point，每个功能点通过UI，基本功能，边界，内存，数据，交互，界面逻辑等维度制定用例设计图，列出产品开发确认需要发现的疑点。用例设计完成后组织用例评审a．组织开发和产品测试用例评审，在用例设计中提出问题，从产品实现、数据存储、用户、产品体验等角度对用例进行评审和补充。b.预审测试组中的测试用例也是非常有必要的。在正式用例评审之前，会在组内进行预评审。版本结束后会整理全用例集，用例串口，特别适合有经验或熟悉业务的。老司机们，在用例评审中可以快速帮助指出用例的缺失点，有助于测试人员打开思路，覆盖尽可能多的用户场景。值得注意的是，如果在用例评审中遇到不确定的地方，应立即记录下来，作为待办事项，结束后及时找相关人员确认，避免猜测和不确定。总结用户反馈并改进测试用例流程——深入测试用例构建，为任何危险做好准备产品测试发布上线后，对于用户反映的缺陷，如果是场景设计不完善造成的缺陷，首先要分析问题出现的场景，偶尔还是会出现，如有需要可以与技术人员沟通同学确认了一些重现场景的具体步骤，确认了介绍的原因，以及解决方法。b.如果线路有缺陷，需要完善测试用例：除了补充场景用例，考虑一些与场景相关的场景，及时改进和审查各种场景下的测试用例，以及将它们添加到用例库中。C。在线缺陷分析具体原因进行回顾总结，关注在线问题反馈群，及时发现问题，定位问题，分析原因，判断问题是引入旧逻辑还是引入新逻辑功能，精准补充对应用例针对特殊场景，补充接口自动化、资产防丢数据狗验证、全用例集合BVT用例。2.3测试阶段没有严格按照测试用例进行问题分析。根据测试用例执行测试可以让我们尽可能避免遗漏一些测试点。不应该因为某个人或对某个业务的熟悉就简化测试用例，不严格按照测试用例进行测试，以免出现一些遗漏的bug。改进措施测试用例不一定能保证覆盖所有场景和功能点，但严格按照测试用例执行测试，可以最大程度保证产品质量，尽可能避免缺陷。养成测试记录的习惯：对于测试阻塞用例和测试失败用例，应重点关注并记录，并在回归测试阶段进行精准的回归测试，确保相关功能引入的新BUG时也能被发现错误已修复。虽然测试过程非常规范，但是软件质量还是不尽如人意。2.4测试环境和测试资源有限，导致分析缺失缺陷的问题。现阶段的测试环境极其复杂。业务系统不是孤立存在的，相关方环环相扣，相关系统往往会出现不一致的情况。在稳定的情况下，除了身份证、银行卡等稀缺资源的使用有限外，往往会在测试后丢弃一个有效数据，所以我们可以通过mock尽可能还原客户的实际环境问题。毕竟，现实不是真实的环境。由于环境的不同，可能会出现很多意想不到的问题，比如：配置问题、数据源问题、数据同步问题。它会暴露出来，在我们的测试环境中无法恢复。我们只能基于预发布环境或生产环境来验证问题，这可能会导致质量隐患。改进措施1）引入灰度发布测试测试组对预发布环境进行回归测试，基本可以模拟真实环境执行测试环境中无法测试的用例，不影响在线用户的正常使用。2）做好生产验证环节的案例筛选工作。一是梳理生产验证案例。生产验证用例除了筛选p0+p1级用例进行回归外，还应包含测试环境mock或baffle被屏蔽的测试用例，严格按照后端接口对前端Response用例执行在生产回归阶段有生产验证案例，覆盖真实的在线环境场景。3）加强对后端及相关方业务逻辑的理解。前端不仅需要了解前后端接口的交互业务逻辑，还需要了解后端接口与其他相关方的接口交互逻辑，检查判断是否它给出的接口数据是正确的，对测试环境中测试用例的覆盖率有一个整体的控制，以保证生产环境中测试用例的全面覆盖。2.5开发者引入的新bug分析。有的开发者只会解决你提交的bug中的问题描述步骤，不会检查问题可能涉及的所有点。看起来问题已经解决了。相反，引入了一个新问题。一个不熟悉功能模块的开发人员来修bug，是因为他对业务不熟悉，考虑不周导致无意中引入了新的bug。改进措施1）代码审查从代码管理层面：开发修复bug，提交代码自测，准备测试。当开发团队提交代码进行codereview时，引入新bug的可能性会更小，风险也会降低。2）从修养层面进行精准回归测试：开发测试后，了解代码变化点，准确分析变化点对关联功能点的影响，确认验证开发者修复的bug，链接关联函数尽量指向遍历回归测试。3）和开发者谈开发者是怎么修复这个功能的，和开发者聊实现。很容易从开发的设计中抓住测试的注意点，记录在用例中。比如A的开发，曾经把功能B做成某个方式，出现了某个bug。现在函数B同样实现了，那么之前的bug很可能会出现在函数C中。4）覆盖率的实践和应用，增加了开发冒烟执行的代码覆盖率。根据覆盖数据分析，还有那些冒烟的用例没有覆盖，是方法没有覆盖，类没有覆盖，还是异常逻辑没有验证。回到通过开发自测试和覆盖率来减少新错误的引入。2.6缺乏探索性测试环节的问题分析我们发现的很多bug并不是根据测试用例的执行而发现的，而是在测试过程中的随机测试中发现的，这些步骤并没有体现在测试用例中。我们的测试用例并不可能涵盖所有场景。改进措施1）入学考试通过后，进行ET考试。测试接入测试完成后，进入SIT测试阶段：一般来说，ET测试是最容易发现bug的，所以测试接入测试完成后，进入SIT测试阶段。一轮探索性测试暴露了测试初期的大部分bug，让bug累计数达到一定的峰值。如果尽早发现错误，质量会更高。2）UAT测试前，进行组内ET测试。SIT考试即将结束。在UAT测试之前，在组内组织一次ET测试，让组内不同的测试可以使用不同的测试方法、测试思维、测试经验、测试习惯进行探索性测试。发现一些遗漏的BUG，奇怪的BUG，或者由于思维方式的局限而导致的不合理的使用。3）精准测试精准测试的测试用例聚类分析功能，可以有效发现“测试错误”。例如，如果一个用例的执行步骤出现错误，其聚类结果将不可避免地发生变化。管理者可以通过系统分析的结果发现并纠正这类错误。以前可能需要返回站点反复确认。精准测试的核心技术点是测试用例和代码的溯源技术。简单的说，这项技术就是当函数执行时，会立即生成相应的整体代码执行，即当一个测试用例被点击时，会立即跟踪到相应的代码和模块。精准测试测试漏洞分析功能，适合敏捷测试。基于程序静态数据和动态运行数据，自动分析软件缺陷风险最高的位置，引导最先完成高风险模块的覆盖，并在有限的时间内完成风险最高模块的覆盖测试时间。3、从开发的角度思考3.1自测背景开发者做好自测是非常必要的，也是大势所趋。前期是开发自测，后期是用户体验测试。在成本和时间上，越晚发现bug，修复成本越高；从修改效率来说，越早处理bug越快。对于一个优秀的开发者来说，自测的bug会比测试发现的bug多，也就是轮到测试的时候，bug的数量是相当少的。3.2疑难问题思考时间和进度太紧，进度紧。对自己的代码太自信了，觉得健壮性强，不忍心修改。认为是测试的责任，严重依赖测试。不知道怎样才能有效做好自测，覆盖全面。冒烟测试的开发没有深入了解QA创建指定的用例，执行简单。3.3思维转变代码质量和项目质量都是我们的责任。测试不同于开发人员思考问题的方式。开发是做软件，测试是破解软件，试图找出问题所在。任何一个函数都有正常场景和异常场景，而且大多使用等价类和边界值来选择数据，覆盖面广。不要相信任何开发的代码都没有错误。跳出具体实现中使用的开发思路，从需求和用户的角度去测试是否通过。如果您是用户，请测试您的功能。3.4自测不慎造成的痛点和隐患遗漏需求：用户一旦发现这个问题，用户印象会大大降低，可能一开始就直接放弃使用，带来非常大的损失客户。功能事故：主要流程功能没有测试到位，或者异常场景没有测试到位，导致线上频繁报错，体验极差，直接认定为事故。延迟上线需求：如果自测不充分，测试会花费大量时间来沟通低级bug，甚至主流程无法进行。这无疑会给开发带来返工、重复测试、耗时、需求延迟、项目延迟等。一系列的问题。3.5制定自测报告规范功能模块介绍和后台介绍功能，后台介绍使用用户组介绍环境信息版本号Hosts，代码发布分支预发布或官方功能设计文档和UI设计图等数据库数据同步，环境配置,开关设置确定已经整理好的自测点。写代码时记录的业务点和测试点。正向、反向、异常场景测试点兼容性自测点。这个功能的开发会不会影响到其他的功能，一行代码会不会？串口流程环节低级bug数量，页面展示UI效果，开发冒烟自测阶段覆盖率，集成阶段覆盖率预期结果：符合测试SOP规定，准出口标准、烟雾自测和覆盖标准测试阶段的集成阶段。控制测试阶段的bug数量。发生后，我们需要深入分析遗漏的bug，思考哪些方面做得不够。是理解业务逻辑的错误吗？缺少用例评估？技术方案不合理？设计用例的思考方向是否有偏差？多问几个为什么，换个角度思考问题，合理设计评价。确保类似的BUG能够提前被发现和暴露，从而尽可能减少缺陷的发生，提高产品质量。做好不同阶段用例测试计划的实施，增加精细化测试和探索性测试环节，需要开拓新的测试思维，跳出惯常的常规测试思维。同时，也要站在开发端，考虑编写代码设计的思维逻辑，减少测试阶段出现bug和遗漏的可能性。开发方也需要严格执行自测和覆盖SOP要求。
