一个漏测Bug能让你想到多少？｜ 得物技术

一、背景

二、原因分析

2.1  需求评审阶段，对业务需求细节理解不明确，设计存在不合理，未深入挖掘隐含拓展需求

• 问题分析

  
  

  在实际产品研发过程中，产品需求其实处于一个细化、优化、下钻过程中，在需求PRD文档交互文档输出进行评审时，未能把一些产品细节问题、隐含需求暴露出来，而测试用例的编写是基于PRD、交互文档以及自己对该需求经验理解所涉及测试用例。

  
  

• 改进措施

1. 需求评审前，我们应该先仔细阅读PRD及交互文档，先形成自己对产品的思考，通过脑图的方式列出对产品设计的疑问点,从用户或者从行业角度找出产品设计缺陷点。
   
   

2. 需求评审会议中，带着列出的疑问点向产品、开发沟通自己对产品的疑惑和质疑点，多提几个为什么？如何实现？数据获取来源？超出预期的数据怎么处理？缓存处理机制如何？数据保存何处？逻辑由前端处理还是后端服务？后端服务逻辑是否跟第三方关联？

   
   

3. 需求评审完成后，按照一定的功能，将需求拆分成若干大模块，大模块拆分成小功能点，然后考虑功能点的具体实现流程，通过思维导图细分模块功能、从页面、交互、边界处理、接口逻辑、环境配置等维度进行梳理需求，尽可能挖掘隐含可拓展需求点，然后进行一次测试组内需求评审和技术复盘，让协作成员一起补充隐含需求，使得产品设计缺陷尽早且最大化地暴露出来。

   
   

4. 在后期技术评审时，探讨逻辑交互以及上下游数据走向和消息发送流转，串联技术侧疑问点。

   
   

2.2  测试用例覆盖不全面，场景出现遗漏

• 问题分析

在测试用例设计过程中，容易出现思维受限或者需求盲区，我们不可能完全覆盖用户使用的所有场景，编写测试用例的时不可能把所有的场景都能想周全，把所有的场景下的情况都写成测试用例去模拟、去覆盖这也是不太现实的。

• 改进措施

• 用例设计开始之前，列思维导图

  
  

  通过思维导图列出业务流程，前、后端接口逻辑。然后按照PRD和交互文档，依照UI界面切分成大的功能块，然后在大功能块，然后在大功能块再切成小功能块，最后到功能点，每个功能点通过UI、基本功能、边界、内存、数据、交互、接口逻辑等维度开展用例设计导图，并列出需找产品、开发确认的疑点。

• 用例设计完成后组织用例评审

  a. 组织开发、产品进行测试用例评审，并抛出用例设计时的疑问，通过产品实现角度、数据存储、用户、产品体验角度对用例进行评审完善补充。

  b. 组织测试组内提前预审测试用例也是非常必须的，对于正式用例评审前会组内进行预审，在版本结束后组织全量用例集合入也会进行串讲用例，特别是一些经验老道或者业务熟悉的老司机们，可以在用例评审上快速的帮忙指出用例的遗漏点，有助于测试人员打开思路，尽可能多的覆盖用户场景，值得注意的是用例评审上遇到不确定的，应立即记录下来作为待办项，结束后及时找相关人员确认，避免猜测不确定。

• 总结用户反馈、完善测试用例流程 - 下钻测试用例构建以有备无患

  
  

  a. 产品测试发布上线后，对于用户反馈的缺陷，如果缺陷是因为场景设计不全引起的，我们先分析出现问题的场景是必现还是偶现，如果是必现，我们可以通过和技术同学沟通，确认该场景的一些具体复现步骤，确认引入原因，解决方案。

  b. 对于线上如果出现缺陷需要对测试用例完善：除了补充该场景case外，考虑一些和该场景相关联的场景，将多种场景下测试用例及时完善、评审，增加到用例库中去。

  c. 针对线上缺陷分析其具体原因做复盘总结，关注线上问题反馈群，及时发现问题、定位问题、分析原因，判断是否为老逻辑引入还是新功能引发问题，精准化补充对应的用例，针对特别场景补充接口自动化、防资损数据狗校验、全量用例集合BVT用例。

2.3  测试阶段未严格按照测试用例执行

• 问题分析

  
  

  按照测试用例执行测试，可以让我们尽可能的不出现遗漏一些测试点。不能因为某一个人或者对某一块业务熟悉简化其测试用例，不严格按照测试用例来执行测试，这样出现了一些遗漏Bug实在是不应该。

  
  

• 改进措施

  
  

• 测试用例不一定能保证所有的场景和功能点都能覆盖到，但是严格按照测试用例执行测试，能最大程度上保证产品质量，尽量避免出现缺陷。

• 养成测试纪录习惯：对于测试阻塞用例、测试Fail用例，应该重点关注并记录，在回归测试阶段进行精准回归测试，确保修复Bug导致关联功能引入的新Bug也能被发现。

虽然测试流程很规范，但是软件质量还是不如意。

2.4  测试环境、测试资源受限，导致缺陷漏测

• 问题分析

  
  

  对于现阶段得物的测试环境问题是及其复杂的，业务系统不是孤立存在的，关联方环环相扣，而且关联系统常常出现不稳定的情况，另外涉及身份证、银行卡等稀缺资源的使用有限，往往测试完一个有效数据废弃一个有效数据，所以我们可以尽可能通过mock、还原客户的实际环境问题。

  
  

  现实毕竟不是真实的环境，由于环境的差异，可能出现很多意想不到的问题，例如：配置问题、数据源问题、以及数据同步问题，这些都是可能只在特性的环境、特定的操作步骤下才会暴露出来，在我们的测试环境还原不出来，只能基于预发环境或者生产环境来验证问题，导致质量可能出现风险隐患。

  
  

• 改进措施

• 测试组在预发布环境上进行回归测试，能基本模拟真实环境执行测试环境无法测试的用例，又不影响线上用户的正常使用。

• 首先进行生产验证case梳理，生产验证case除了筛选p0+p1级别case进行回归外，还应该包含测试环境mock or 挡板阻塞的测试case，以及后端接口对前端响应的case，在生产回归阶段严格按照生产验证case执行去覆盖真实线上环境场景。

• 前端不仅需要了解前端与后端接口的交互业务逻辑，还需了解后端接口与其它关联方的接口交互逻辑，校验判断其给的接口数据是否正确，对测试环境测试用例的覆盖程度有整体的把控度，以确保生产环境的测试用例覆盖做到全面性。

2.5  开发人员引入的新Bug

• 问题分析

  
  

  有一些开发人员只会针对你所提交的Bug中问题的描述步骤解决，并不会去排查该问题有可能涉及的所有点，有可能出现解决了这个问题，而引入了一个新的问题。一个不熟悉功能模块的开发人员来修复Bug，因为业务不熟悉，考虑不周全导致无意识的引入新的Bug。

• 改进措施

  
  

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

  
  

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

  
  

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

  
  

• 增加开发冒烟执行代码覆盖率，根据覆盖率数据分析有那些冒烟用例未覆盖到，是方法未覆盖到、还是类未覆盖到或者是异常逻辑的校验未回归到，用开发自测和覆盖率的方式降低其新Bug的引入。

2.6  探索性测试环节欠缺

• 问题分析

  
  

  我们发现的很多Bug都不是按测试用例执行发现出来的，都是在测试过程中随意测试发现的，而这些步骤在测试用例中并未体现，我们的测试用例不可能覆盖所有的场景。

  
  

• 改进措施

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

  
  

• SIT测试进入尾声，UAT测试之前组织一次组内ET测试，让组内不同的测试用不同的测试方式，测试思维，测试经验，测试习惯进行探索测试，能发现一些由于思维定势局限原因导致漏测的Bug、诡异的Bug或者使用不合理的地方。

  
  

1. 精准测试的测试用例聚类分析功能，可以有效地发现“测试的错误”。例如一个用例执行步骤错误，它的聚类结果必然会发生变化，管理者通过系统分析的结果就可以发现并纠正这一类的错误，而之前可能需要在现场回归反复的确认。

   
   

2. 精准测试的核心技术要点是测试用例与代码的追溯技术。这项技术简单来说就是当功能执行完成以后对应的整体代码执行情况就会立即产生，即当点击一个测试用例，就立即追踪到对应的代码和模块。

   
   

3. 精准测试测试漏洞分析功能，适用于敏捷测试。它可以基于程序静态数据和动态运行数据，自动分析软件缺陷最高风险的位置，引导首先对于高风险的模块完成覆盖，在有限时间内完成最具有风险的模块的覆盖测试。

   
   

三、对于开发角度侧思考

3.1  自测背景

3.2  疑难问题思考

1. 时间和进度太紧张，排期紧凑。

   
   

2. 对自己代码过于自信，自认为有很强的健壮性，不忍心去修改。
   
   
3. 认为这是测试的责任，多度依赖测试。
   
   
4. 不知如何有效的做好自测，覆盖全面。
   
   
5. 开发冒烟测试对于QA创建指定的用例理解不透彻，执行简约。
   

3.3  思维转变

1. 代码质量、项目质量均是我们的责任。

   
   

2. 测试和开发人员思考问题不同，开发是在制造软件，测试是在破坏软件，想办法去找出问题。
   
   
3. 任何功能都有正常场景和异常场景，多数使用等价类和边界值去选择数据，覆盖全面。
   
   

4. 不要相信任何开发的代码是无Bug。

   
   

5. 走出具体实现时用的开发思维，站在需求和用户的角度去自测是否通过，假如自己是用户去测试你的功能。
   

3.4  不仔细认真自测带来的痛处和隐患

1. 需求遗漏：一旦被用户发现此问题，用户印象会大打折扣，可能直接从开始使用即放弃使用，将带来非常大的客户流失。

   
   

2. 功能事故：主流程功能没有测试到位，或者异常场景没有测试到位，导致线上频繁报错，体验极度不好，直接认为就是事故。

   
   

3. 需求延期上线：如果自测不充分，测试花大量的时间去沟通低等级bug，甚至主流程走不下去，这样无疑会给开发带来返工、重复测试、耗时、需求延期、项目延期等一系列问题。
   

3.5  制定自测报告规范

• 功能模块介绍及背景介绍

  
  

1. 功能、背景介绍

   
   

2. 使用用户群体介绍
   

• 环境信息

  
  

1. 版本号

   
   

2. Hosts、代码发布分支

   
   

3. 预发or正式

   
   

4. 功能设计文档以及UI设计图等

   
   

5. 数据库数据同步、环境配置、开关设定等
   

• 梳理好的自测点

  
  

1. 编写代码时候记录的业务点和测试点

   
   

2. 需求变更的自测点

   
   

3. 正向、逆向、异常场景测试点

   
   

4. 兼容性

   
   

5. 开发此功能是否会对其他功能造成影响，一行代码是否会引发新的问题出现
   

• 自测实际结果：

  
  

1. 高等级Bug数量、影响冒烟核心流程

   
   

2. 中等级Bug数量、串联流程链路

   
   

3. 低等级Bug数量、页面展示UI效果

   
   

4. 开发冒烟自测阶段覆盖率

   
   

5. 一轮、集成阶段覆盖率
   

• 期望结果：

  
  

1. 符合测试SOP规定准出标准

   
   

2. 冒烟自测以及集成阶段覆盖率标准

   
   

3. 测试阶段Bug数量的控制

   
   

4. 上线后Bug数量的控制，质量月复盘满足数量控制标准
   

四、总结

活动推荐

主题：

得物无线技术沙龙（第三期）

时间：

12月4日 14:00 - 18:00

报名方式：

更多详情，请点击「沙龙详情」