挑战
大多数现代软件系统都是基于面向服务的体系结构构建的。例如，常见的基于Web的服务的B/S结构的服务，和更传统的C/S结构的服务。API应用程序接口层封装了组织业务所需要的功能，服务于用户界面使用。用户界面和业务功能的分离，从根本上改变了用户如何进行测试，测试可以在生成API接口后就开始。
由于API测试需要测试者具备更多开发所具有的技术能力；测试脚本类资产的维护随着代码的变更，也成为一个问题；开发和测试两个部门间的协调，技术技能和业务知识之间的综合能力，都是需要面对处理的关键问题。对大多数组织来说，这项测试工作的自动化，仍然是一个挑战。
基于模块的测试自动化平台，打破了这一技术障碍，通过模块，用图形化的方法描述和被测对象的交互接口的技术信息，并将其表现为对任何测试人员或业务人员，更加直观，容易理解的模块，快速的创建API自动化测试，进而帮助组织不需要编写任何脚本，就可以将自动化测试，从用户界面，扩展到基于API接口的自动化测试，从而帮助测试团队更早的开展自动化测试，并实现跨Web界面、手机、SAP等多种技术平台的，端到端的集成系统测试场景。
好处
无需脚本测试API
完全支持包括SOAP和REST等流行的Web服务标准之内的多种协议接口API的测试。对于采用WSDL、WADL、Swagger、OData、RAML、XSD、JSON和SAP描述的文件或URI通一资源标志符，可以使用扫描程序，就可以自动生成基于图形界面的测试基础模块，使用基于模块的测试自动化框架。
易于维护API测试资产以应对变更
之前的API测试都是通过手动编写脚本完成的。这意味着开发和测试人员花了数小时编写测试用例脚本，然后每当API被更新时，又花费数小时维护脚本。API扫描功能不仅大大缩短了测试创建时间，而且几乎取消了维护时间，使应用程序开发更快，更新周期更短。
改进开发人员和测试人员的协作
开发人员对正在开发的API执行功能检查时，可以使用免费的API扫描工具与服务接口进行交互，同时，可以捕获服务请求和响应消息接口并保存成文件，为后期测试提供帮助。测试人员可以使用这一文件，自动转换为业务可读的基于模块的自动化测试框架。
这一方面，使得开发人员更容易参与到测试过程；同时，为非技术测试人员和业务分析人员提供直观的界面，帮助测试团队可以轻松地审查和扩展测试用例，而无需担心JSON、XML或xPath等太多技术概念。
轻松维护API端到端测试
基于模块的测试自动化平台帮助所有测试人员快速创建和维护API测试，这些测试可以作为Web界面、手机、SAP等端到端测试场景的构建块重用。
基于模块的测试自动化平台在所有类型自动化测试背后，使用相同的，简单的，无脚本的测试自动化解决方案，不需要复杂的API编程。
重用API测试实现服务虚拟化
API测试可以自动转换为服务虚拟化资产，以便对敏捷开发所需的关键服务虚拟化资产进行简单管理。
将SoapUI测试迁移到企业API测试
将您零碎的SoapUI项目转换为基于模块的自动化测试平台的API测试，以实现重用，极大地提高了维护、效率和协作。
基于模块的自动化测试平台，通过综合测试数据生成、风险覆盖优化、服务虚拟化和持续测试分析，来扩展API测试功能，优化API测试策略。
广泛的API技术支持
大多数API测试工具只支持REST和SOAP标准。对于拥有数百个集成系统的企业公司来说，这种有限的支持是不够的。基于模块的自动化测试平台支持整个API过程，从Web API，到真正的端到端测试的传统支持协议。
实现方法
基于模块，无需编码的API测试技术，不但支持REST和SOAP这些Web API，而且支持等多端到端系统测试所需的传统协议。我们在此仅以常见的基于REST 的Web 服务的API接口测试作为例子，来描述使用工具扫描实现自动化API测试的方式。
1. 扫描API接口描述
API接口扫描程序有两种启动方式。程序既可以作为一个无需授权的，单独的免费程序使用，也可以作为测试工具的一个菜单项启动。这主要是考虑到，有些组织可能可以建立测试开发和测试执行分立的机制。使用单独运行的API接口扫描程序，便于由开发人员使用扫描工具，将抽象的API，用一个简单的消息的的请求和响应对来描述，便于提供给测试人员理解，并将其保存为文件，交由更熟悉业务的测试人员，使用测试工具来导入这个文件，用业务需求，完成测试设计和执行验证工作。
下图通过对一个连锁咖啡店网上服务程序的扫描，得到相关消息接口，选择对咖啡店实现增删改查的消息，可以选择将原始的消息描述改为更用例理解的消息描述，每个消息都有Request请求和相应的Response响应。
2. 导入测试工具中生成API测试模块
将这个扫描结果保存到文件提供给模块测试工具使用，或直接导入测试工具中。
3. 为API测试模块添加属性。
例如为以下模型添加属性，相当于为响应的消息添加了接口参数。
1) 增加新的咖啡店
2) 获得咖啡店列表
3) 删除咖啡店
自动添加需要的参数。例如，我们为函数“增加新的咖啡店”添加参数。
选择技术视图Technical View需要添加到参数中的内容，点击Add按钮即可。
同样的，为了易于测试人员理解，可以重命名这些参数。同样的方式，为其他服务接口模块添加属性如下。
以上工作，可以由研发人员，或具有技术背景的测试设计人员完成。
而下面的测试用例设计工作，可以有熟悉业务测试需求的人员完成。
4. 生成测试用例
1) 在服务器中开设新的咖啡店，
2) 验证是否开设成功
3) 删除新开设的咖啡店
新建测试用例“新增咖啡店”。
将已有的测试步骤按照业务所需的顺序，拖动加入到测试用例中。
自动填充所选择的测试步骤的属性值，即接口的参数值。
检查和调整这些参数，实现预定的测试业务逻辑。
上图中，
“CP key”实现用测试配置变量key中获取值。实现类似脚本中，设置全局变量或宏的作用。
“B 服务器给于的店号”，实现了从一个缓存“服务器给于的店号”获取值。实现类似脚本中，设置局部变量的作用。
执行这个测试用例，验证预期的逻辑。
上面内容简述了如何在无需编写脚本的情况下，实现API接口测试自动化。