如何丰富测试手段，实现QA自身效率的提升
作者|李京京
项目中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从保姆型到辅助型的有效途径。