如何获得讲师PPT：
扫码关注公众号，后台回复「5131」即可获得讲师PPT哟～
还能一键订阅后续精彩活动内容～
Q&A环节答疑：
一、环境不同、基础数据不同，回放的数据是不是也会报错？比如我们要回放支付接口，但是没有对应的订单数据，这种如何处理？ 还有就是很多接口都需要用户登录，这个在录制回放的场景里面怎么处理？需要录制一个全量的流程吗？
在接口自动化测试当中，我们测的是单个应用的一个接口的测试。比如说这个接口它的对外调用是全都要录制下来的。比如说回放支付接口，比如说这个接口是一个支付操作，那我会调对外的一个支付接口，那这个接口其实会录制下来的。然后在测试环境回放的时候，我们是不会对这个支付接口真实调用的，我们是会从录制的数据当中取出它的返回值给它进行回放，是不依赖测试环境对应的订单数据的。通过录制回放解决的是这种没有下游数据的问题。
然后第二个是说很多接口需要用户登录，其实是可以把这个登录的操作录制下来的。像我们公司的话，它的登录其实是调用的，比如说用户中心提供的一个接口，判断这个用户是否登录，那这个对外调用本身就会录制下来。所以，它的登录校验其实是当时线上通过，那我们回放的时候它就是通过。当时线上录制的是登录不通过，那回放的时候也是登录不通过。
二、在全链路压测过程中，mock的返回值从录制的中心取数据这个会不会很耗性能？这些mock点只能做测试的同事自己来找吗？
mock 的返回值从数据中心取这个操作。首先在全链路压测场景中，需要 mock 的地方其实不是很多的。比如说需要 mock 的是重复订单校验，就是相当于在整个链路当中需要 mock 的地方只占很小一部分。然后取数据的时候，因为它是一个 HTTP 调用，我们最开始也是把这个数据放到 ES 里面，然后从 ES 里面选这个回放数据，从 ES 查询，这个操作就比较慢。确实当时回放的响应时间比线上真实的响应时间要长。那我们做了一个优化，把这些子调用的数据给它预热到 Redis 里面，然后最后我们从 Redis 里面去取这个数据，那它的响应时间就是很快了。整个调用链路下来，比如说升单操作，那它的响应时间基本上是没有什么影响的。
然后对 Mock 的点只能做测试的同事自己来找。首先我们会有一批公共的挡板，比如说调调支付，还有说是发短信，这些我们都会设成公共的挡板，就比较公共的操作我们是提前设置的，然后是对所有的业务线都是生效的。还有一部分我们的公共挡板就是会把外网的所有调用都设上公共挡板。那业务同事需要做的就是通过半自动化调试挡板那个流程来看每一个 case 它走不通的原因，然后只要对对应的地方设挡板就可以了，那整个链路其实要设置挡板的地方并不会特别的多。
三、订单号在不同的环境中，如何保障生成的是一致的？
对于订单号的话，我们是从线上录制的，公司的生成订单号也是提供一个公共的服务，有一个公共的服务来提供生成订单号这个操作。所有生成的订单号基本上都是一个对外的 double 调用，那这个 double 调用它就是天然的会被录制下来的。
所以在接口自动化测试场景当中，生成订单号的操作是会录制的。在回放的时候，这个订单号和线上的订单号是一样的。在压测中这个订单号是不会录制的，是让它真实地打下去，因为压测场景的录制和回放都是在线上环境，所以是不会有冲突或者是不一致的问题。
四、压测的时候是否支持回放历史数据？
压测的时候，目前一种是：比如说我一个小时之后要搞压测，那我可以在那提前 1 个小时去准备这份数据，如果他对数据的时效性要求比较高，那我可以提前 1 个小时去准备这个录制数据，那回放的历史数据就是一个小时内的。那如果他对这个历史数据要求不高的话，他是可以用历史数据的。比如说他这个场景对时间要求没有那么高，它就可以用历史的 case 来回放的。
五、对于流程式的场景如何获取上一步的业务数据？在录制的数据中要进行脱敏处理吗？这个数据会和真实的服务器会交互吗？
这个流程式的场景上一步，是问的是接口自动化测试还是全链路压测？
如果是接口自动化测试的话，它是不依赖上一个流程数据的，因为它所有对外调用，包括从 MySQL 里面取数据，这些操作都是被录制上的，所以它是不依赖上一步的业务数据的。然后如果它是一个全链路压测场景的话，我们是可以把上一步数据录制下来，比如说它取上一步业务数据的时候，这个操作我们可以把它设上挡板，然后把这个操作录制下来。
录制的数据要进行脱敏处理吗？首先我们的数据是有一些加解密的这个接口，我们是不录制的，就是加所有加解密的接口，我们都是让他真实地去调用的，所以他传的入参这些其实都是脱敏的已经脱敏的数据，然后我们不会做特殊的脱敏处理。
因为我们用的是录制回放技术，那真实和业务的机器交互的就只有是在入口的时候，比如说我发这个发起入口请求的时候，是真正打到业务的机器上去的，然后在回放的时候，它会走这个业务真实的单独这个业务的代码，然后对它的下游调用。比如说如果是设了挡板的话，那它的下游调用不会真实地走，但是这一个当前应用的所有的 Java 方法都是会走的。
六、话题互动
-
回放接口的入参模型变更后，测试环境如何与线上环境匹配？
比如说一个需求上线后，它的测试参数可能是变化了。比如说多增加了一个字段，那这个需求上线后，它线上的录制数据就已经是增加了这个字段的。因为线上是一直在执行录制的，那有了这一份新的录制数据之后，那 beta 环境自然就用新的 case 来去回放了，就保证了线上和测试环境的 case ，它的参数是一致的。
如果问的是，比如说线上的代码是旧的，然后本次是一个新的需求变更，然后这个需求变更增加了一个字段，那这种它就是属于正常的。比如说代码改动，那我们接口自动化测试主要解决的就是回归 case 的这种问题，如果它的接口结入参的结构已经变化了，但这个需求还没有上线，那现线录制的 case 是少参数的，这种的话我们目前是认为它是正常的业务变更，就不属于回归测试的范畴，所以即使说这个接口它是没有办法回归的，那么我们也不会拦截。它的上限就是它可以申请跳过，这是一个正常的代码变更，跳过去就好了。然后这种变更的话，它是需要 QA 人工的真实地去测试的。
-
回放接口的子调用发生了变更(子调用的接口路径/入参模型)，测试环境如何mock变更后的子调用？
比如说，如果接口路径发生变化了，那我的录制数据其实是没有的，那回放的时候它会走到这个请求。一种方式是：如果这个子调用可以真实地在测试环境，可以真实地调用下去的话，那就可以把这个子调用给它设置到黑名单里，就是我们不 mock 这个子调用，让它真实地往下调用，如果说它真实的调用是在测试环境通不了的，那目前是没有解决这种问题的，它这个子调用就会回放失败。
但我们也认为它是一个正常的业务变更，如果是子调用的入参模型变化的话，这个结果它对整体的业务流程没有很大影响的话，这个是可以做到模糊地去忽略的。比如说它某一个子调用，它的参数增加了一个，那我们会把两个测试环境，一个是基准环境部署的是 master 代码，然后一个是测试环境部署的分支代码，那我们在 DIFF 的时候会发现走到同一个子调用的时候，它的参数入参是有差异的。比如说基准环境是两个参数，测试环境是三个参数，这个时候我们会把这个差异 DIFF 出来，测试人员或者是开发人员他可以选择把第三个参数给忽略掉，这个时候我们再去DIFF， DIFF 的时候就认为是相同的了。这种方式它如果不影响后续的测试流程的话，是能够解决这个问题的。
-
测试环境比线上环境的子调用多了，该如何mock此类的场景？
这个子调用如果是调用得多了，得分两种情况：比如说是录制的里面已经有这个子调用了，它只是次数变多了，或者是它真实的就多了一个完全没有录制过的对外调用。
如果说是已经录制过只是次数变多的情况下，是可以把历史的数据，比如说线上录制了两次，然后回放的时候它要调用 3 次，那我们可以把前两次的数据作为第三次的那个数据给它返回去，就是相当于子调用的复用，这种情况可以解决。
如果是线上真的完全没有走到的一个子调用，然后测试环境新增了这部分子调用，它也属于一个正常的业务修改，那也其实不属于回归的范畴。这种的话就应该是 QA 或者是开发人员真实的要去走测试的，它属于一个正常的业务变更。这种的如果是说需要 mock 的话也可以做到，但我们只能说做到mock 固定值之类的，就是没有办法动态地给它进行到mock。
-
如果测试环境的中间件调用发生了变更又该如何mock，例如：测试环境新增缓存？
例如测试环境新增缓存这个中间件的含义我不太清楚，我猜测这个中间件是不是指公司的基础组件？还是说是 Redis 的调用之类的？如果是指公司的基础组件的话，比如说基础架构提供的一些公共的一些jar包，那这些jar包里面的调用对于业务同学来说的话，他其实是不太关心的，就是他写业务代码的时候，他不用关心基础组件做了什么事情，所以这些基础组件的代码流就是相关的。
调用的话我们是不设置 mock 的，就是让它真实地调用下去。如果是基础组件里面增加了某些调用，那其实是会真实地往下调的，不会影响它的业务流程。如果是业务里面，比如说调用Redis，它增加了一个调用或者是参数变化了，就是跟第二个问题是差不多的，跟第二个问题的解决方法是差不多的。
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫 
评论列表（1条）