​作者 | 赵悦

对于刚入职的测试同学来说，测试可能只是页面的点点点，但其实测试是一门很有意思的学问。工作 2 年后，我对测试产生了一些观念上的转变，并且会对不同类型的项目可以设计不同的测试方案，采用不同的测试手段对测试进行提效。那么现在就给大家分享一下我的成长经历！

一、校招新人心路历程

1、初入职场

刚来到公司加入了 B2C 团队，业务繁忙、需求量大，响应业务成了首要事情，重复着功能测试。对于刚入职的新手来说本身对业务就不是非常了解，测试时不仅需要对已有逻辑进行了解还要对新的功能进行测试，再加上自身对时间的分配还不能协调好，所以就少有时间进行测试方案设计以及项目复盘。

2、小白疑惑

因为所在业务涉及商品发布、质检、订单等链路，有较强的可复用性，所以组内产出了使测试效率大幅提升的数据构造，但是因为大家使用的语言是 Java，我之前未接触过，所以对开发数据构造有一定的抵触心理。后来刚开始推行的 http 接口测试，又要了解接口的实现、出参、入参，对结果进行断言，当时我觉得这些都可以用功能测试来验证，为什么要通过接口测试呢？

3、上手使用

后来到了 C2B 团队，虽然业务也比较忙，但是也有可以自我充电的时间。接着又推行了 scf 接口测试平台、mock 平台等各种测试工具，可以用来测试过程的提效，或者模拟一些不好出现的场景，组内也开始大力推广使用，所以我也开始在项目中开始进行接口测试。虽然在每个项目中也使用了接口测试，但是我在很机械的使用，没有感觉到有哪些提效，还处在使用阶段，并没有很好的运用。

二、入职两年后的成长

1、在整个需求的生命周期，测试关注点的转变

2、测试方法的转变

在测试前期，对需求进行分析，将大需求拆分成不同的测试点并整理出相应的测试方法是开展测试的第一步。那么如何针对于不同类型的项目制定不同的测试方案呢？

三、测试方案设计

1、深入了解需求

所谓 “知己知彼，百战不殆”，如果想要制定一个满足需求的测试方案，首先要知道系统要实现什么功能，业务流程是怎么样的，针对于产品需求整理出自己可以理解的一套流程。

2、整理测试点

先总体上整理出需要验证的功能点再扩展开写。

3、针对于不同类型的测试点采取不同的测试手段

日常我们最常接触到的主要是以下三类需求

• 全后端
• 偏前端
• 前端 + 后端

（1）智能分发—全后端需求
业务特点：在指定时间挑选出部分商品判断满足不同条件以特定价格分发到不同卖场。因为货的成色各不相同卖到不同的卖场利润也尽不相同，怎么能够达到利润最大化，是首要关注的事情。每天要上架几千台的货到不同的卖场，如果全靠人工来上架，成本太大，所以自动上架很好的解决了这个问题。那么验证上架卖场的准确性以及销售价是我们需要关注的点，那如何对纯后端需求进行测试是我们需要思考的。
解决思路：纯后端逻辑更改，这类的项目一般需要通过观察日志、查看数据库、或者看代码逻辑处理是否正确。

• 接口测试
  因为自动上架是基于定时任务触发的，没有手动上架入口，所以为了测试此类未与前端交互的需求可以采用 scf 接口测试。对判断上架卖场逻辑接口进行接口测试，传入不同的参数，看接口返回；
  

• 查看日志
  通过查看日志，检验判断策略的准确性；
  
  

• 远程 debug
  在设定销售价时需要获取 2 个系统，4 个场景的价格进行比对，但是在线下维护的机型数量较少，所以可能出现的第三方未返回价格，此类需要依赖第三方返回数据的测试点可以选择远程 debug 来修改第三方返回值，来命中价格范围；
  
  

为了模拟这种只返回一个值的场景，修改其中一个值未 null；

• scf mock 一些依赖第三方返回数据来进行内部逻辑处理的也可以采用 scf mock，写入你需要的返回值来达到目的。可能是一些异常场景正常流程无法触发，也可以为了测试第三方返回失败的情况下内部逻辑做的兜底处理等。并结合代码看自己走的场景是否覆盖全面；

（2）促销活动—偏前端需求
业务特点：用户报名参加运营活动，过一段时间进行秒杀，对不同资格的用户展示不同的页面，参与秒杀的用户和未参与秒杀的用户的页面展示做区分。
解决思路：后端改动相对较小，主要是前端页面的展示及动画效果。针对于此类的需求通过修改数据库、页面功能、不同机型的兼容性测试。

• 功能测试
  主要通过移动端模拟用户真实操作流程进行功能测试；

• 数据存储
  后端逻辑主要在记录用户的秒杀资格，所以用户每解锁一个状态，就要关注数据库表中的状态记录是否正确。优先保证后端逻辑的正确性，接着再主测前端界面样式；

• 修改数据
  为了测试不同状态下的用户展示不同的页面，每次修改用户的状态，来达到效果；

• http mock
  前端根据命中不同的条件展示不同的 tab，为了最小成本的测试到所有场景，通过 http mock 接口返回内容来测试前端展示的不同方案；
  
  

（3）门店回收进天路—前后端需求
业务特点：针对业务特性定制新的散货流程以满足回收散货需求。从回收到散货的流程较长，而且涉及到多方交互，还需要兼容在途订单。
解决思路：此类需求前后端改动均衡，验证的内容都比较多，流程还比较长，所以重点是先梳理出全流程链路，找到一个切入点作为主线，围绕着这个切入点展开测试方案设计。针对于此类的需求主要可以通过接口测试，数据构造提效，优先保证主流程，其次测试分支功能。

• 流程梳理
  因为从回收到散货涉及到回收单状态流转，以它作为主线再梳理各个状态下的页面展示、操作、交互，及不同端的功能；
  

• 接口测试
  因为这个流程涉及 app、后台、小程序，都和回收单状态密切相关，所以优先通过接口测试回收单状态流转，提高后端代码质量，使得联调和测试进度更通畅。

• 数据构造
  对于可以复用的流程，开发可以一键执行构造数据的工具，对于此种流程行节点较多的需求最适合做一个数据构造来在造数据的时候帮忙节省时间了。
  

• 代码分析
  需要比对前后价差的误差范围，边界值比较难构造，针对于此种测试场景，和开发共同进行代码分析，看判断条件是否正确；

  //沟通取店员回收价格百分之15
  if (employee.compareTo(inspector.add(employee.multiply(new BigDecimal(IMPUTATION_PRICE)))) < 0) {
  return true;
  }
  

• 功能测试
  最后再前后端结合进行系统的功能性测试，保证前后端的数据正常交互，同时测试前端界面展示及功能；

  四、总结

  1、从纯功能测试->接口 + 功能；
  2、从机械化使用->根据不同类型设计不同用例；
  可以根据不同类型的项目特点设计不同的测试方案，提高测试效率，这是作为测试需要重点关注的。在今后的测试过程中还需要不断去探索新的测试方法设计更合适的测试方案来助力提效。