【转】一个漏测Bug能让你想到多少？

• 题目分析
  
  在实际产品研发过程中，产品需求着实处于一个细化、优化、下钻过程中，在需求PRD文档交互文档输出进行评审时，未能把一些产品细节题目、隐含需求暴袒露来，而测试用例的编写是基于PRD、交互文档以及本身对该需求履历明确所涉及测试用例。
  
• 改进步调
  

• 需求评审前，我们应该先细致阅读PRD及交互文档，先形本钱身对产品的思考，通过脑图的方式列出对产品设计的疑问点,从用户大概从行业角度找生产品设计缺陷点。
  
• 需求评审集会会议中，带着列出的疑问点向产品、开辟沟通本身对产品的疑惑和质疑点，多提几个为什么？怎样实现？数据获取泉源？超出预期的数据怎么处理处罚？缓存处理处罚机制怎样？数据生存那边？逻辑由前端处理处罚照旧后端服务？后端服务逻辑是否跟第三方关联？
  
• 需求评审完成后，按照肯定的功能，将需求拆分成多少大模块，大模块拆分成小功能点，然后思量功能点的具体实现流程，通过头脑导图细分模块功能、从页面、交互、界限处理处罚、接口逻辑、情况设置等维度进行梳理需求，尽可能发掘隐含可拓展需求点，然后进行一次测试组内需求评审和技术复盘，让协作成员一起增补隐含需求，使得产品设计缺陷尽早且最大化地暴袒露来。
  
• 在后期技术评审时，探究逻辑交互以及上卑鄙数据走向和消息发送流转，串联技术侧疑问点。
  

• 题目分析
  
  在测试用例设计过程中，容易出现头脑受限大概需求盲区，我们不可能完全覆盖用户使用的全部场景，编写测试用例的时不可能把全部的场景都能想全面，把全部的场景下的情况都写成测试用例去模仿、去覆盖这也是不太实际的。
  
• 改进步调
  

• 用例设计开始之前，列头脑导图
  通过头脑导图列出业务流程，前、后端接口逻辑。然后按照PRD和交互文档，依照UI界面切分成大的功能块，然后在大功能块，然后在大功能块再切成小功能块，末了到功能点，每个功能点通过UI、根本功能、界限、内存、数据、交互、接口逻辑等维度开展用例设计导图，并列出需找产品、开辟确认的疑点。
  
• 用例设计完成后构造用例评审
  a. 构造开辟、产品进行测试用例评审，并抛出用例设计时的疑问，通过产品实现角度、数据存储、用户、产品体验角度对用例进行评审完满增补。
  b. 构造测试组内提前预审测试用例也优劣常必须的，对于正式用例评审前会组内进行预审，在版本竣事后构造全量用例聚集入也会进行串讲用例，特别是一些履历老道大概业务熟悉的老司机们，可以在用例评审上快速的帮助指出用例的遗漏点，有助于测试职员打开思绪，尽可能多的覆盖用户场景，值得注意的是用例评审上遇到不确定的，应立即记载下来作为待办项，竣事后实时找干系职员确认，制止推测不确定。
  
• 总结用户反馈、完满测试用例流程-下钻测试用例构建以防患未然
  a. 产品测试发布上线后，对于用户反馈的缺陷，如果缺陷是由于场景设计不全引起的，我们先分析出现题目的场景是必现照旧偶现，如果是必现，我们可以通过和技术同砚沟通，确认该场景的一些具体复现步骤，确认引入缘故原由，办理方案。
  b. 对于线上如果出现缺陷须要对测试用例完满：除了增补该场景case外，思量一些和该场景干系联的场景，将多种场景下测试用例实时完满、评审，增长到用例库中去。
  c. 针对线上缺陷分析其具体缘故原由做复盘总结，关注线上题目反馈群，实时发现题目、定位题目、分析缘故原由，判定是否为老逻辑引入照旧新功能引发题目，精准化增补对应的用例，针对特别场景增补接口主动化、防资损数据狗校验、全量用例聚集BVT用例。
  

• 题目分析
  
  按照测试用例实验测试，可以让我们尽可能的不出现遗漏一些测试点。不能由于某一个人大概对某一块业务熟悉简化其测试用例，不严格按照测试用例来实验测试，如许出现了一些遗漏Bug着实是不应该。
  
• 改进步调
  
  
  
  • 测试用例不肯定能包管全部的场景和功能点都能覆盖到，但是严格按照测试用例实验测试，能最大水平上包管产风致量，只管制止出现缺陷。
    
  • 养成测试记录风俗：对于测试壅闭用例、测试Fail用例，应该重点关注并记载，在回归测试阶段进行精准回归测试，确保修复Bug导致关联功能引入的新Bug也能被发现。
    
  
  

• 题目分析
  

• 改进步调
  

• 题目分析
  

• 改进步调
  

• 从代码管理层面：开辟修复一个Bug提交代码自测通过准备提测时，开辟团队提交代码进行代码review，引入新Bug的可能性概率就会较小，低落风险存在。
  

• 从测试自我修养层面：在开辟提测后，相识代码改动点，精准分析改动点对干系联的功能点的影响，将开辟职员修复的Bug确认验证，并将干系联的功能点尽可能的遍历回归测试到
  

• 跟开辟聊实现很容易从开辟的设计中你可以把握到测试的注意点，并记载体如今用例中。比方Ａ开辟曾经用某种方式做了B功能，出现了某个Bug，如今B功能用了同样方式实现，那么极有可能之前的Bug还会出如今C功能。
  

• 增长开辟冒烟实验代码覆盖率，根据覆盖率数据分析有那些冒烟用例未覆盖到，是方法未覆盖到、照旧类未覆盖到大概是非常逻辑的校验未回归到，用开辟自测和覆盖率的方式低落其新Bug的引入。
  

• 题目分析
  

• 改进步调
  

• 在测试准入测试完成进入SIT测试阶段：一样寻常来说，ET测试是最容易发现Bug的，以是在测试准入测试完成进入SIT测试阶段，先辈行一轮探索性测试，使的大部分的Bug先在测试前期暴袒露来，让Bug累计数目到达肯定的峰值，尽早发现Bug，质量越高。
  

• SIT测试进入尾声，UAT测试之前构造一次组内ET测试，让组内不同的测试用不同的测试方式，测试头脑，测试履历，测试风俗进行探索测试，能发现一些由于头脑定势范围缘故原由导致漏测的Bug、诡异的Bug大概使用不公道的地方。
  

• 精准测试的测试用例聚类分析功能，可以有用地发现“测试的错误”。比方一个用例实验步骤错误，它的聚类结果肯定会发生厘革，管理者通过体系分析的结果就可以发现并改正这一类的错误，而之前可能须要在现场回归反复的确认。
  
• 精准测试的焦点技术要点是测试用例与代码的追溯技术。这项技术简朴来说就是当功能实验完成以后对应的团体代码实验情况就会立即产生，即当点击一个测试用例，就立即追踪到对应的代码和模块。
  
• 精准测试测试毛病分析功能，实用于敏捷测试。它可以基于步伐静态数据和动态运行数据，主动分析软件缺陷最高风险的位置，引导起首对于高风险的模块完成覆盖，在有限时间内完成最具有风险的模块的覆盖测试。
  

• 时间和进度太告急，排期紧凑。
  
• 对本身代码过于自大，自以为有很强的坚固性，不忍心去修改。
  
• 以为这是测试的责任，多度依赖测试。
  
• 不知怎样有用的做好自测，覆盖全面。
  
• 开辟冒烟测试对于QA创建指定的用例明确不透彻，实验简约。
  

• 代码质量、项目质量均是我们的责任。
  
• 测试和开辟职员思考题目不同，开辟是在制造软件，测试是在粉碎软件，想办法去找出题目。
  
• 任何功能都有正常场景和非常场景，多数使用等价类和界限值去选择数据，覆盖全面。
  
• 不要信赖托何开辟的代码是无Bug。
  
• 走出具体实现时用的开辟头脑，站在需求和用户的角度去自测是否通过，如果本身是用户去测试你的功能。
  

• 需求遗漏：一旦被用户发现此题目，用户印象会大打折扣，可能直接从开始使用即放弃使用，将带来非常大的客户流失。
  
• 功能变乱：主流程功能没有测试到位，大概非常场景没有测试到位，导致线上频仍报错，体验极度欠好，直接以为就是变乱。
  
• 需求延期上线：如果自测不充实，测试花大量的时间去沟通低等级bug，甚至主流程走不下去，如许无疑会给开辟带来返工、重复测试、耗时、需求延期、项目延期等一系列题目。
  

• 功能模块先容及背景先容
  

• 功能、背景先容
  
• 使用用户群体先容
  

• 情况信息
  

• 版本号
  
• Hosts、代码发布分支
  
• 预发or正式
  
• 功能设计文档以及UI设计图等
  
• 数据库数据同步、情况设置、开关设定等
  

• 梳理好的自测点
  

• 编写代码时间记载的业务点和测试点
  
• 需求变动的自测点
  
• 正向、逆向、非常场景测试点
  
• 兼容性
  
• 开辟此功能是否会对其他功能造成影响，一行代码是否会引发新的题目出现
  

• 自测实际结果：
  

• 高等级Bug数目、影响冒烟焦点流程
  
• 中等级Bug数目、串联流程链路
  
• 低等级Bug数目、页面展示UI结果
  
• 开辟冒烟自测阶段覆盖率
  
• 一轮、集成阶段覆盖率
  

• 盼望结果：
  

• 符合测试SOP规定准出尺度
  
• 冒烟自测以及集成阶段覆盖率尺度
  
• 测试阶段Bug数目标控制
  
• 上线后Bug数目标控制，质量月复盘满足数目控制尺度
  

原文：https://segmentfault.com/a/1190000042883339