|
接口测试向来是测试行业招聘需求的重点，各位测试同学也在工作中或多或少接触过接口自动化的相关工作内容。我相信，不管从执行角度，设计角度，度量角度上考虑接口测试这件事，各位都会遇到一些难点，下面我就从几个点来理一下如何解决这些问题。 这个问题大家可能经常会存在一些疑问，也经常会发现一些问题。什么问题呢?明明我每个接口都测试到了但是一放到线上环境就出了问题，我们怎么去保证我测试接口的链路是全的呢？ 我们常规的设计思路是，我把待测的接口单独拎出来，然后构造对应的入参，用上了我们最最擅长的测试数据设计的一些方法，等价类边界值等等，只要每个入参情况覆盖到即可，通常我们会习惯性忽略各个入参的组合，因为参数过多的问题导致无法有效的去选择何种组合才算是一次有效用例。这里我们看一个例子： 这是一个接口A内部处理的示意图 我们发现该接口一共只有两种返回结果A和B，但是当入参存在0的情况下，虽然返回的结果也是A，但是它还走了一个存库的操作，如果我们在做接口测试的时候只验证了返回结果，这个肯定还不够，还需要进一步验证数据库情况。 因此，对于较复杂的内部逻辑情况的覆盖也显得比较重要了。 其实从我们上面的这张图来看，我们完全可以借鉴白盒覆盖法来去设计对应的测试用例，把接口处理的流程画出来再进行对应的用例数据设计。 常用覆盖法：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖 具体用法，小k老师会在今天下午2点腾讯课堂测试开发试听课上进行详细的讲解。 扫描下面二维码了解订阅课程： 我们做复杂接口测试的时候可能会遇到这类问题（特别是大数据测试下），某个计算型接口给到测试人员，入参什么的都不是问题，问题在于该接口会以某个入参作为索引，到多个业务表当中去找到对应的一些数据并进行计算，我们称这种依赖数据为接口前置数据。 但是回顾我们常规的接口测试，基本上postman打开，直接构造参数进行请求的发送了，并没有准备我们上面说的前置数据，这时候就比较麻烦了，可能需要先去跑一些数据出来才能够进行接口的验证，但是这样就无法做到自动化的去测试这个接口，必须人工介入构造前置数据。 方案： 在我们设计接口测试用例的时候（推荐采用平台管理），我们希望针对某些接口，我们在生成测试用例的同时能自动补全前置业务数据，并且此数据我们可控，那咋整呢？有办法！ 在我们接口自动化平台设计课中采用了数据工厂方案，大家可以借鉴 该工厂基于基础业务数据模板，在我们设计测试用例的时候，自动向业务表中插入定制化业务数据，并且可以通过配置的方式，让插入的数据可控、也可随机。并且该工厂除了能够补全业务数据外，还能够对压测数据进行生产回收，是一个比较好的数据治理方案。 想知道此部分的详细内容，今天下午2点课堂揭晓。 通过上述的方案，我们在工作中可以把接口测试做的更加深入，也能够通过平台化的管理方式大大提升工作的效率，降低后续接口自动化维护成本。  精益技术 赋能过程 |
|
|
