8.1 API/接口测试的目的与意义
API（Application Programming Interface）自动化测试是软件测试中最基本的一种类型。API就像建造大楼的砖块，程序开发人员通过运用一定规则将"砖块"放在一起来构造程序，从本质上来说，API测试是用来验证组成软件的那些单个方法的正确性，而不是测试整个系统本身。
API测试又称为接口测试，接口测试是功能测试的一种。它主要借助于单元测试技术，通过模拟上层应用或者系统上层调用接口的应用场景，是对系统接口功能进行测试的一种手段。在进行接口测试的过程中，测试工程师并不需要了解被测试系统的所有代码，而主要通过分析接口定义以及模拟接口调用的业务应用场景来进行测试用例的设计，从而达到对被测试系统功能进行测试的目的。接口测试的重点是要检查数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
接口测试一般应用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要 测试这些系统对外部提供的接口，验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。
接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比。接口测试天生为高复杂性的平台带来高效的缺陷检测和质量监督能力。平台越复杂，系统越庞大，接口测试的效果越明显。
8.1.1 接口测试的目的
接口测试是测试接口，尤其是那些与系统相关联的外部接口。接口测试的核心战略在于：以保证系统的正确和稳定为核心，以持续集成为手段，提高测试效率，提升用户体验，降低产品研发成本。
■ 核心：保证系统的稳定
质量管理的 目标是保证系统的正确和稳定，接口测试作为软件质量管理的一部分也保证系统正确和稳定，更准确地说是保证系统服务端的正确和稳定。一个系统的服务端越接近 底层，对系统的影响就越大，甚至有可能牵一发而动全身，服务端的一个缺陷可能会引起客户端的几个甚至十几个缺陷，更可怕的是服务端的缺陷有可能引起系统的 崩溃，这对整个系统来说，损失将是不可估量的，因此服务端接口的质量将直接影响到系统的正确和稳定。
■ 目的：提高测试效率，提升用户体验，降低产品研发成本
接口测试要为代码的编写保驾护航，增强开发人员和测试人员的自信，让隐含的Bug提前暴露出来，让开发人员在第一时间修复Bug，让功能测试人员和性能测试人员在测试的时候更加顺手，最大限度得减少底层Bug的出现数量，让产品研发的流程更加顺畅，要缩短产品的研发周期，最后在产品上线以后，要让用户用得更加便捷，要让用户感觉产品服务零缺陷。
8.1.2 接口测试的意义
接口测试是单元测试的一个子集，但又不等同于单元测试。从测试的角度来看，接口测试的价值在于其测试投入比单元测试少，而且技术难度也比单元测试小。一 般来说，接口测试的粒度要比单元测试更粗，它主要是基于子系统或者子模块的接口层面的测试。因此，接口测试需要测试的接口或者函数的数量会远远小于单元测 试，与此同时，接口定义的稳定性会远远高于类级别的函数。所以，接口测试用例代码的改动量也远远小于单元测试，代码维护成本会比单元测试少很多，因而测试 的投入量会小很多。从另外一个层面来看，借助于接口测试，可以保证子系统或子模块在各种应用场景下接口调用的正确性，那么子系统或子模块的产品质量也可以 得到充分的保证。因此，接口测试是一种适度的白盒测试技术，准确说它是一种灰盒测试，投入产出是非常理想的。
总的来说，接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益的驱动作用下的最佳解决方案。主要体现在下面的三个方面：
首先，接口测试节省了测试成本，根据数据模型推算，底层的一个Bug能够引发上层8个左右Bug，而且底层的Bug很容易引起全网的死机。相反接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。
其次，接口测试不同于传统开发的单元测试，接口测试是站在用户的角度对系统接口进行全面高效持续的检测。
最后，接口测试是自动化并且持续集成的，这也是为什么接口测试能够低成本高收益的根源。
8.2 UFT中的API测试
UFT（Unified Functional Testing--自动化功能测试）中的 Service Test为API级别中的测试提供了一种直观简便的方法。HP Service Test工具箱窗格提供REST服务、Web服务、JMS和HTTP等功能测试领域的活动集合，通过导入WSDL文件或从资源库中使用服务就可以为"工具 箱"窗格中添加活动，还可以利用内置的活动向导创建新的自定义活动。HP Service Test对于那些非GUI应用程序，可以随时通过"工具箱"窗格中拖放到视图上创建一个测试，为快速获得测试结果提供了一种无需编写代码的方法，高级用户 可以利用事件处理程序自定义测试行为，并自定义代码模块。
8.2.1 SOA测试的重要性
接口开发的发展促成了SOA（Service-Oriented Architecture--面向服务的体系结构）的发展，SOA通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。SOA的出现，接口的可重用性给IT省略去了大量的工作。就开发体系结构方面而言，SOA是将来的一个发展趋势。
SOA虽然可以使业务更加灵活，但是如果没有正确实施，SOA也会造成业务中断。因此SOA自动化测试是一个充分利用产品和流程来减少应用程序升级或部 署新的服务的风险的测试方法。SOA自动化测试核心是为预部署系统申请工作负载，同时测试系统性能的一个过程。构建一个良好的性能测试必须满足以下条件：
■ 服务响应速度对目标用户是足够的；
■ 服务器响应是否正确；
■ 服务能处理异常和非法值；
■ 在预期和非预期的用户负载下，服务要稳定；
如果满足这些条件就可以设计出有效的测试。一个有效的自动化测试过程能够帮助您做出更明智的发布决策，减少系统停机时间，并且防止可用性问题。
HP Service Test是一种SOA测试解决方案，它能够简化和加速SOA服务的自动化功能测试，减少了SOA服务测试所需时间，有助于确保这些服务在部署之前满足您的业务需求。它使您的组织能够简化Web服务测试程序，并尽量减少对脚本的自动化能力的需要。
8.2.2 SOA概述
SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些 单元之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中 的服务可以以一种统一和通用的方式进行交互。这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两 点，一点是它的灵活性；另一点是当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不 同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
面 向服务的体系结构不是一个新鲜事物，它是传统的面向对象的模型的替代模型。虽然基于SOA的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设 计却是面向服务的。由于它考虑到了系统内的对象，所以虽然SOA是基于对象的，但是作为一个整体，它却不是面向对象的，不同之处在于接口本身。然而，现在 的SOA已经有所不同了，它是以可扩展标记语言（Extensible Markup Language，XML）为基础，通过使用基于XML的语言（Web服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中。
8.2.3 服务测试术语
在SOA自动化功能测试过程中，与SOA相关的Web服务的术语主要有：
HTTP（Hypertext Transport Protocol--超文本传输协议）：是一种通信协议，详细规定了浏览器和万维网服务器之间互相通信的规则，通过因特网传送万维网文档的数据传送协议。
JMS（Java Message Service--Java消息服务）：应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
REST（Representational State Transfer--表述性状态转移）：是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
SOAP（Simple Object Access Protocol--简单对象访问协议），或面向服务交换架构协议）：是一种轻量级的、简单的、基于XML 的协议，它被设计成在Web上交换结构化的和固化的信息。SOAP 可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP）、简单邮件传输协议（SMTP）、多用途网际邮件扩充协议（MIME）。它还 支持从消息系统到远程过程调用（RPC）等大量的应用程序。
TEST：测试中描述用户执行的步骤，它模拟了真实用户使用应用程序的行为。
UDDI（Universal Description Discovery and Integration--统一描述、发现和集成协议）：UDDI是一个用来发布和搜索WEB服务的协议，应用程序可借由此协议在设计或运行时找到目标WEB服务。
Web services：Web Service是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得Web Service能与其他兼容的组件进行互操作。Web Services 主要利用 HTTP 和 SOAP 协议使商业数据在 Web 上传输，SOAP通过 HTTP 调用商业对象执行远程功能调用，Web 用户能够使用 SOAP 和 HTTP通过 Web 调用的方法来调用远程对象。
XML：（Extensible Markup Language--可扩展标记语言）：用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进 行定义的源语言。XML是标准通用标记语言（SGML）的子集，非常适合Web传输。XML提供统一的方法来描述和交换独立于应用程序或供应商的结构化数 据。
XSD（XML Schema Definition）：XML Schema 是DTD的替代品。XML Schema语言也就是XML Schema Definition（XSD）。XML Schema描述了XML文档的结构。可以用一个指定的XML Schema来验证某个XML文档，以检查该XML文档是否符合其要求。文档设计者可以通过XML Schema指定一个XML文档所允许的结构和内容，并可据此检查一个XML文档是否是有效的。XML Schema本身是一个XML文档，它符合XML语法结构。可以用通用的XML解析器解析它。
WSDL（web service description language--web服务描述语言）：它是基于XML的用于描述 Web Services以及如何访问Web Services的语言。它是一个XML文档。用于说明一组SOAP消息以及如何交换这些消息。
8.3 API测试通用流程
HP UFT（Unified Functional Testing--自动化功能测试）工具中的服务测试为API级别中的测试提供了一种直观简便的方法。本节将介绍如何利用UFT的服务测试构建一个简单的 API测试，通过测试已知应用程序和服务执行的活动，观察响应，通过检查应答，确定您的系统是否按预期执行来熟悉API的测试流程。本节主要包含以下几个 部分内容：
■ 启动API服务；
■ 创建一个新的服务测试；
■ 服务测试窗口的介绍；
■ 构建测试流中的测试；
■ 数据驱动测试；
■ 测试步骤的连接；
■ 多个数据源的数据映射。
8.3.1 启动API服务
HP自带的HP航班服务，它可以作为Web服务和REST服务。HP航班服务与航班预订数据库共同作用就可以检索航班的目的地，创建客户的订单，更新保 留或删除它们。进行API测试之前必须启动API服务，启动API服务按照下面三个步骤进行，如果想获得服务测试方法和操作的详细信息，可以在示例应用程 序的命令窗口键入"help"。
（1）选择"开始"--"所有程序"--"HP Software"--"HP Unified Functional Testing"--"Sample Application"--"flights API"，命令窗口打开表明应用程序是可用。
（2）如果窗口发出一条消息是默认端口24240是不可用，那么在<installation_directory> SampleApplication HPFlights_Service.exe.config文件中的文本编辑器appSettings节点上更换24240端口为一个有效的端口。
（3）最小化"命令"窗口。
如果已经打开HP航班服务，就可以开始为无界面的机票应用程序创建测试。