互联网测试模型和API测试

本文主要依据极客时间茹炳晟的专栏，加上自己的SoapUI使用经验编写。

1、互联网测试的菱形模型   

         GUI应用测试、API测试、单元测试，三者组成应用系统测试的基本内容。在互联网应用中，特别是微服务架构大行其道的情况下，原来的金字塔模型（以单元测试覆盖率为基础，API其次，GUI测试在最后完成）不使用了，改成菱形模型。即，工作重心在API测试，重量级API测试，轻量级单元测试、GUI测试。简单说就是原来说的接口测试变成重点。

        其实，由于IDE、XP和CI/CD的发展，以及代码分析工具、IDE集成测试如xUnit等的发展，一般由比较良好意识的互联网应用软件工程师都会自觉地做单元覆盖测试。而GUI应用测试，一般更强调E2E的穿透性测试。主要系统业务复杂，E2E更能发现整体性的业务流程方面的问题，也是系统测试工程师的价值所在。微服务架构，使得每个微服务成为了类似原来中间件一样的基础组件了，充分测试的要求提高，搭建测试环境也相对简单，成为重心也很自然。

 

2、API测试接口工具

API测试一般3个步骤：  准备测试数据，通过API测试工具发起对被测API的request；验证返回结果的response（Assert）。       

茹炳晟的专栏重点介绍了cURL，Postman和newman，Postman有图形界面，Newman有利于CI/CD持续交付流水线。PostMan已经能够很好地应付单个API测试，对如何应对复杂场景的API测试节，其中提到：第一、被测业务操作由多个API调用协作完成，这个是微服务的核心，通过代码来传递上一个APi测试结果给下一个API测试；如何高效地获取单个前端操作所触发的API调用序列，通过分析抓包记录来快速获取。第二、API测试过程中的第三方依赖。接口测试时，最好使用MockServer来代替，就和敏捷测试中要求单元测试访问数据库的一般都用Mock替代一样道理。第三、异步API的测试，通常需要访问数据库或消息队列，这个一般是通过测试框架来解决，异步调用是否成功，业务逻辑是否正确。

     因此，对应的一些策略就是：使用基于代码的API测试框架，可以比较灵活可控地解决上述问题。目前已有的一些框架：基于JAVA的OKHTTP，基于Python的http.client等。还有大公司自行开发。其实就是    API接口解析+序列脚本库+断言库。能够比较好地解决与CI/CD工具集成、数据与脚本分离、自定义Assert和调用操作、序列操作的。但工作量会比较大，也无法重用原来成Postman已经做的工作。因此，现在流行的做法是自制工具，将Postman已有的collection和断言转化成代码。另外，能够实现Response结果发生变化时的自动识别。只把和以前不同的标识输出，简化Assert过程。

3、SoapUI使用

      我前面做测试较多使用SoapUI。SoapUI是很好的第三方工具，可模拟http、webservice等多种协议请求进行测试，SoapUI模拟请求方发送http、webservice的request请求。SoapUI模拟服务端作为测试桩进行http和webservice协议接口测试。可以方便地实现webservice接口的测试，包括用例生成、响应的结果验证、testcase编辑、testsuite组织。还可以实现基础的性能测试：通过短时间频繁调用，统计每次的响应时间等。在测试用例生成方面，可以自动发现注册协议，生成接口消息的基本结构，只需要填充具体数据即可。图形界面操作，很容易进行响应结果验证；上一个结果中数据的保存；测试套中序列的编辑。对照上面来看，应该是比较类似于Postman。