• 0
  • 0
分享
  • 我的5次测试遗漏解决方法及事后分析——软件测试圈
  • 曼倩诙谐 2023-04-21 11:50:33 字数 2007 阅读 701 收藏 0

  最近项目发补丁,笔者所负责的模块进行回归测试。提供的补丁版本在回归测试前已经进行过一些时日的测试,并且发现的故障也已经修复完成。但是情理之中意料之外的是,已经测试完成的功能陆陆续续又发现了几个故障,让笔者不得不检讨和怀疑自己。那么,这些故障为什么会测试遗漏呢?

  经过笔者对比和总结,复测发现的故障主要出现在以下情况:

  ·交互模块测试不充足,导致其他模块引用笔者测试模块时发现故障;

  ·测试样本数据量小,无法触发大数据量场景下的故障;

  ·非正常途径获取测试版本,导致故障未能及时发现;

  ·版本升级,兼容性测试不足;

  ·忽略一般类打印错误,导致数据残留;

  那么,所述的这几种测试遗漏场景,具体是什么样的情况呢?在测试中可以如何尽量避免呢?

  1.交互模块测试不充足,导致其他模块引用笔者测试模块时发现故障

  此类故障在笔者回归测试的时候出现过两次。笔者负责的测试模块功能是大数据转储和查询。出现的两次故障一次是上层模块引用查询功能时,后台报错不存在的查询字段;一次是模拟数据测试,查询模拟的数据时搜索不到结果。

  经过开发人员分析,两个故障属于代码异常故障。其一是代码异常拦截,导致字段查询失败;其二是存在相同字段时转储异常,导致模拟数据中部分字段未能正常存入。

  那么,从测试角度分析,为何会出现这两个故障呢?其一是笔者在测试时只关注自己模块功能、接口等是否正常,从已知的场景中分析、编写测试用例进行测试,未能与其他模块进行联调测试;其二是笔者不曾模拟过出现问题时的模拟数据,选用常见数据进行拓展模拟,忽略了测试样本多样性。

  那么,可以如何避免这类故障的出现或尽早发现这类故障呢?联合测试,我想是一个十分有效的办法。由于精力和时间以及经验和知识等局限性,测试人员特别是团队测试人员往往难以避免的只关注或重点关注自己模块的功能可用性和健全性,可能会忽略其他交互模块的调用方式和多样性数据传递。因此,加强联合测试可以多脑联合扩大测试场景,提升测试效果。

  2.测试样本数据量小,无法触发大数据量场景下的故障

  此类故障笔者在回归测试的时候出现过一次,主要出现在数据转储时。此前笔者为了能够快速地进行自动化回归测试,转储测试使用的数据量不是很大。因此,发现的转储功能故障基本处于代码合入时。但回归测试时,大数据量的冲击导致转储过慢、转储报错等问题频现。

  那么,可以如何避免这类故障的出现或今早发现这类故障呢?建立大数据量测试环境或性能测试环境。保持一个长期稳定的性能测试环境用于大数据量转储和查询测试。这样,可以让常规化测试通过的版本在版本发布前经过性能测试环境的过滤。

  3.非正常途径获取测试版本,导致故障未能及时发现

  此类故障笔者在回归测试的时候出现过一次。现象时将发布版本进行基本回归测试,发现竟然存在基本功能故障。经过思考和分析,发现问题出在笔者之前测试时环境上的版本不是笔者从流水线正常获取的,而是开发人员调试过的版本。也是由于笔者的偷懒,没有在之后拉取正规版本进行测试,导致这个基本功能故障在版本回归测试时才发现。

  那么,可以如何避免这类故障的出现或今早发现这类故障呢?一定要正规途径获取版本,不要试图偷懒。只有这样,我们才能保证我们发布版本与测试版本一致。

  4.版本升级,兼容性测试不足

  此类故障笔者在回归测试的时候出现过一次。由于基础环境升级,联合测试时笔者负责模块出现了接口功能故障。而之前测试时未能发现的原因是笔者使用的老版本基础环境测试,到这升级后出现接口不兼容。特别是参数调用和返回结构发生了改变。

  那么,可以如何避免这类故障的出现或今早发现这类故障呢?定时更新测试环境,尤其是基础环境,或者使用项目上提供的自动化测试环境进行测试。这样能够“紧跟潮流”,获取最新基础环境信息,及早发现故障。

  5.忽略一般类打印错误,导致数据残留

  此类故障笔者在回归测试的时候出现过一次。其现象是在进行版本卸载重装时发现数据残留。而此类故障并非笔者在回归测试时首次发现,其实在之前测试中隐隐约约也见过类似错误,但是笔者并未深究。直到回归测试时,笔者方式重视起这个问题,认真排查后发现时卸载时java环境变量未能成功获取导致数据残留。由于卸载时控制台输出错误未能明显标注(比如加粗、红色),所以笔者未能很快发现打印输出的错误。

  那么,可以如何避免这类故障的出现或今早发现这类故障呢?测试一定要小心谨慎,不能放过任何可疑行为。一旦我们在测试过程中发现某些可疑输出,即使是偶现,我们也一定要提高警惕,认真排查。

  说了这么多,不知道正在阅读的你有什么收获呢?本文只是笔者从自身角度将最近测试工作中的一些心得分享出来,希望浅薄之语能对你有所启发和帮助。



作者:刘晓佳Rachel    

来源:http://www.51testing.com/html/08/n-7795708.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   前言  性能测试用例主要分为预期目标用户测试、用户并发测试、疲劳强度与大数据量测试、网络性能测试、服务器性能测试五大部分。  具体编写用例时要根据实际情况去进行,遵守低成本、策略为中心,裁减、完善模型,具体化等原则。  Web性能测试模型提出的主要依据是:一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试,这些类型的性能测试的实施是有着相似之处的。  预期指标的性能测试  系统在需求分析和设计阶段都会提出一些性能指标,完成这些指标的相关的测试是性能测试的首要工作之一,这些指标主要诸于:系统可以支持并发用户200个,系统响应时间不得超过20秒等。  对这种预先承诺的性能要求,需...
            0 0 728
            分享
          • 1.monkey的简单介绍Monkey测试是Android app自动化测试的一种手段,Monkey测试本身非常简单,就是模拟用户的按键输入,触摸屏输入等,看设备是否出异常。当Monkey程序在模拟器或设备运行的时候,如果用户出发了比如点击,触摸,手势或一些系统级别的事件的时候,它就会产生随机事件,所以可以用Monkey用随机重复的方法去测试app。一般情况下单个app monkey 模拟测试10万次足矣。2.以下是app monkey测试的详细步骤先进入cmd界面,输入adb devices,查看是否正常连接;输入adb logcat | findstr START 监控app,打开你要测试...
            13 13 964
            分享
          • 一、Java集合框架概述集合可以看作是一种容器,用来存储对象信息。所有集合类都位于java.util包下,但支持多线程的集合类位于java.util.concurrent包下。Java集合类主要由两个根接口Collection和Map派生出来的,Collection派生出了三个子接口:List、Set、Queue,因此Java集合大致也可分成List、Set、Queue、Map四种接口体系,(注意:Map不是Collection的子接口)。其中List代表了有序可重复集合,可直接根据元素的索引来访问;Set代表无序不可重复集合,只能根据元素本身来访问;Queue是队列集合;Map代表的是存储k...
            0 0 969
            分享
          • 本文的作者是阿里的技术Leader——云狄,他将从管理的角度分享技术 TL 的核心职责,主要分为如下几个方面与大家共同探讨、交流:团队建设团队管理团队文化沟通与辅导招聘与解雇互联网公司的技术团队管理通常分为两个方向:技术管理和团队管理,互联网公司的技术 TL 与传统软件公司的 PM 还是有很大的区别。传统软件公司的 PM 更多注重于对项目的管理,包括项目任务拆解、项目进度以及风险等。对于多数互联网公司而言,技术 TL 更多的职责不再局限于项目角度,而是对业务与技术都要有深入的了解,就像黑夜里的灯塔,能够引导和修正团队成员前进的航向。综合技术和业务角度去深度思考问题,具备一定的前瞻性,并在技术领...
            1 3 3907
            分享
          •   你是不是还在为描述缺陷复现步骤而苦恼?你是不是还在为寻找一款合适的视屏录制软件而挣扎?那么,你应该好好看看这篇小文章。  作为测试人员,撰写测试用例、提交测试缺陷是基本工作。但往往我们会遇到:开发人员无法根据我们描述的缺陷步骤,复现缺陷现象。且不说是不是因为测试人员描述的步骤不够精准或不够详细,一旦出现开发无法复现缺陷现象时就会出现频繁地沟通,导致出现缺陷处理时间延长的潜在风险。不仅如此,即使是测试人员一对一、当面为开发人员演示了缺陷的复现步骤,也可能出现缺陷处理人的转移而重复缺陷复现过程,由此会出现许多反复无效的沟通环节。  那么,你是怎么复现缺陷步骤呢?可能大家都有比较好的方法。但是笔...
            0 0 504
            分享
      • 51testing软件测试圈微信