最近随着测试服务端的工作达到一定的量，在工作完成一个阶段之后，细细回想，还是有一些经验可以分享给大家的。
工作的项目中经常会涉及到微服务的重构或者迁移，那么针对这种代码的重构之后，映射到业务层面，测试同学该如何开展工作呢？
示例场景：以前的直接购买走的是paypay的接口，后来加入了购物车的逻辑，可以多件共同购买，走的是placeOrder的接口，但是购物车一期的逻辑，没有针对直接购买的接口做改造，所以直接购买的入口造成了后面对一些相应的优惠券的处理和购物车中使用优惠券逻辑不通的情况；然后购物车二期马上就将直接购买的接口改为placeOrder接口，单个商品的直接购买也会生成一个购物车id，然后使用优惠券的逻辑与购物车中购买逻辑同步一致了；由于版本原因，所以购物车功能之前的端，直接购买走的还是老的paypay的接口。
后面由于stock-service库存微服务的加入，购买租赁的接口都开始调用库存服务，但是由于之前的paypay接口查询库存的方式没有进行改造，所以没有调用库存服务，还是直接查询的表。在测试成都仓关仓的需求中，就要额外执行一些测试场景，还没有购物车功能的低版本，库存的读取是否也正确。
服务端的测试想要测试覆盖全面，需要理解各种接口的归属于哪个微服务，当服务弃用或者重构一个新的服务，影响到的场景或者接口需要有整理的了解和认识，这样在项目中后期的测试中，对于服务频繁的迁移和重构，才能测试更全面；
有相当部分用户其实在使用app时经常不会主动更新到最新的版本，所以端内很多页面都会内嵌web、h5页面，这样有功能迭代的时候，页面的上线并不涉及到包的迭代，用户也不需要频繁更新包。同理，端内很多数据的来源都是来自服务端，基本上各种展示都是动态的，由服务端返回的。服务端的上线可以随时，并不会给用户带来界面更新的感知。
抓包工具是为了能够定位到哪个页面或者哪个操作用到了哪些接口，当需要定位问题时，需要在页面中拿到调用的接口以及请求的参数，如果开发者在端内通过一些便捷渠道能获取到是最好，例如接口文档或者端内的小工具。如果需要验证在生产环境调用的接口是否正确以及返回数据的校验的话，那么就必须抓包了。
来源：CSDN
作者：tiejian147
链接：https://blog.csdn.net/tiejian147/article/details/104009177