如何丰富测试手段,实现QA自身效率的提升

发表于:2021-8-09 09:39

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:李京京    来源:博客园

  项目中QA同学需要针对不同项目特点,采用不同的测试手段,大家常用的测试手段包括:功能测试接口测试,接口Mock测试等,那如何将这些测试手段应用到自己的项目中,形成特定的测试方案呢。下面会结合具体项目来作详细阐述。
  一、接口自动化测试
  项目名称:盘古类目体系改造
  1、背景介绍
  通过新老类目体系的相互映射,保证新老类目体系并行一段时间,待各个业务方完成由旧类目体系到新类目体系迁移完成,下线旧类目体系,全部切到使用新类目体系。APP会作为盘古的第一个接入方。
  2、难点分析
  本项目的核心是偏下游的基础服务,调用场景较多,且7000多个分类的新老数据映射,需要测试的case量巨大,完全基于功能层面去测试成本高,耗时长,且无法保证全量覆盖,可行性低。不同业务线业务场景不同,且有一些特殊场景存在,单纯的接口测试是不能覆盖业务线的实际应用场景的,且交互逻辑是否正确,最终还是要通过功能层面去验收。
  3、测试方案
  全量自动化接口测试+业务场景功能测试
  4、效果
  全量接口自动化测试,大大提升了测试效率(详见表格),实现了case的全量覆盖,保证了测试质量;且沉淀下来的测试代码,项目后期维护阶段,可以复用进行回归测试。
  从用户功能角度做验收是必要的,发现业务特定场景下的细节问题,保障用户体验。
  二、提前产出测试工具
  项目名称:我发布的列表页改版
  1、任务展示逻辑及曝光策略测试
  (1)难点分析
  任务及曝光策略涉及到的条件都是结合Redis缓存的特定字段的时间戳或字段状态值来判断的,构造Redis里有代表性的时间戳和可能的状态值是可行的,但是构造的数据只有在隔天才会影响到Redis中特定值的变动,频繁的构造真实数据,进行客户端展现的测试,几乎是不可行的。
  可不可以让server从代码里把时间间隔改小呢?沟通结论是不可行的,因为如果修改了,模拟测试,测试的不是真实逻辑,意义不大。
  (2)测试方案 采用分层测试
  真实构造可能的测试场景,生成Redis中具有代表性的时间戳和可能的状态值,并校验这些字段值是正确的。
   编写操作Redis的工具类,针对性的对Redis中的时间戳和状态字段进行增删改查,对客户端展示进行测试。
  2、不同量级的曝光数在客户端的展示样式
  通过Mock接口字段的不同返回值,查看客户端的展示样式是否正常。
  综上,通过提升QA自身的技术能力和代码能力,有助于丰富自身的测试手段,深入理解技术实现方案,从而制定合理的测试方案。
  一个优秀的测试方案,除了它的有效性外,还需要做到可以对提测部分尽早介入测试,将问题尽早暴露出来,减少项目后期压力。
  结合QA内部推行的冒烟流程等有利条件,可以提前准备好RD自测所需的数据构造,测试工具,接口case等,是实现QA从保姆型到辅助型的有效途径。

     本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号