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航班服務，就可以開始為無界面的機票應用程序創建測試。