1.介面測試的背景

1.1    什麼是介面測試

介面測試是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過 程，以及系統間的相互邏輯依賴關係等。

1.2   為什麼要做介面測試

在淘寶網系統的歷史上，首先出現的是功能測試和效能測試，然後是自動化測試，但發展到今天，淘寶網的架構已經不再是傳統的 MVC 結構，系統不斷向著分散式、業務中心化 和高可用性的方向發展，如今的系統架構紛繁複雜，系統間的介面龐雜繁多，傳統的功能測 試、效能測試和自動化測試已經難以滿足系統發展的需求，迫切需要一種更加有效實用且可 以持續進行的測試方式來保證系統的質量。

介面測試在這種需求下應運而生。 首先，隨著系統複雜程度的上升，傳統的測試方法測試成本急劇增加，測試效率大幅下降（資料模型推算，底層的一個bug能夠引發上層的 8 個左右bug，而且底層的bug很容易引 起全網的宕機。相反介面測試能夠提供系統複雜度上升情況下的低成本高效率的解決方案。

其次介面測試不同於傳統開發的單元測試，介面測試是站在使用者的角度對系統介面進行 全面高效持續的檢測。

最後介面測試是自動化並且持續整合的，這也是為什麼介面測試能夠低成本高收益的根 源。

總之介面測試是保證高複雜性系統質量的內在要求和低成本的經濟利益的驅動作用下 的最佳解決方案，介面測試是一個完整的體系，也包括功能測試、效能測試。

下圖充分說明了系統間介面的複雜程度：

1.3  介面測試的適用範圍

介面測試一般應用於多系統間互動開發，或者擁有多個子系統的應用系統開發的測試。 介面測試適用於為其他系統提供服務的底層框架系統和中心服務系統，主要測試這些系統對 外部提供的介面，驗證其正確性和穩定性。介面測試同樣適用於一個上層系統中的服務層接 口，越往上層，其測試的難度越大。介面測試在淘寶的應用是一個自下而上的發展過程。

介面測試實施在多系統多平臺的構架下，有著極為高效的成本收益比。介面測試天生為 高複雜性的平臺帶來高效的缺陷檢測和質量監督能力。平臺越複雜，系統越龐大，介面測試 的效果越明顯。

2.介面測試的目的

2.1   戰略方針

介面測試的核心戰略在於：以保證系統的正確和穩定為核心，以持續整合為手段，提高 測試效率，提升使用者體驗，降低產品研發成本。

核心：保證系統的穩定 質量管理的目標是保證系統的正確和穩定，介面測試作為軟體質量管理的一部分也是保證系統的正確和穩定的，更準確的是保證系統服務端的正確和穩定，一個系統的服務端，越 接近底層，對系統的影響就越大，甚至有可能牽一髮而動全身，服務端的一個缺陷可能會引 起客戶端的幾個甚至十幾個缺陷，更可怕的是服務端的缺陷有可能引起系統的崩潰，這對整 個系統來說，損失將是不可估量的，因此服務端介面的質量將直接影響到系統的正確和穩定。

手段：持續整合 什麼是以持續整合為手段，關鍵在於“持續構建”、“業務”、“整合化”以及“文件體系”，我們需要讓被測程式碼進行持續構建整合，我們需要用業務化的思維去考慮介面定義的合理性， 我們需要從效能、安全的角度去思考程式碼的正確性，我們還需要從整合化的角度去甄別介面 間資料傳遞的正確性，我們更需要確定我們的測試範圍，也就是我們測什麼、不測什麼。

目的：提高測試效率，提升使用者體驗，降低產品研發成本 介面測試要為程式碼的編寫保駕護航，增強開發人員和測試人員的自信，讓隱含的 BUG提前暴露出來，要讓開發人員在第一時間修復 BUG，要讓功能測試人員和效能測試人員在 測試的時候更加順手，最大限度得減少底層 BUG 的出現數量，要讓產品研發的流程更加敏 捷，要縮短產品的研發週期，最後在產品上線以後，要讓使用者用得更加順暢，要讓使用者感覺 產品服務零缺陷。

另外在這個戰略過程中，我們需要幾類資源作為支撐，下面做簡單描述。 首先在這個戰略中最重要的一點是要強調團隊的重要性，特別是團隊中需要有合理的人力資源配置，在這個團隊中，需要全才，也需要專才，需要技術專家，也需要業務專家，既 需要高效的執行者，也需要有效的管理者，任何人在這個團隊中都可以發揮重要作用。

其次我們需要強大的測試技術以及測試框架去支撐我們的日常工作，包括基於 JAVA 以 及基於 C++的測試框架，甚至以後會擴充套件到其他各個語種的框架，計算機軟體的架構發展到 今天，特別是分散式軟體的發展，導致軟體體系結構日益複雜化，各個系統之間的依賴逐漸 加強，JAVA、C++以及多種技術的綜合使用，使傳統的單元測試已經無法滿足於針對介面編 程的架構方式，我們需要以一種更加乾淨的層面也就是從業務的層面對介面進行隔離測試， 同時為了模擬真實場景，也需要在真實的環境中對系統內根據業務流程對各個介面進行串聯 測試，最後以持續整合系統保證被測程式碼的穩定性。

再次要充分重視文件的重要性，包括需求文件，開發技術方案，測試技術方案，介面定 義 JAVADOC，測試用例文件等等，完善這些文件可以大大減少軟體工程週期中各個團隊配合 障礙，也可以降低後期軟體維護成本。

因此貫徹和落實介面測試的戰略可以最大程度地提高軟體質量的穩定性。

2.2  發展各階段和目標

將簡要講述一個介面測試團隊從建立初期到發展起來經歷了哪些階段，以及我們期 望將來做成什麼樣子。

摸索階段：

 一個全新的團隊成立之初一般都會經歷一個比較長期的摸索階段，在這個階段我們會嘗

試不同的技術、框架和流程規範。直到在這些方面都找到了比較適合團隊自身特點的方案， 那麼這個階段的目標就算是達到了。

穩定提高階段：

 摸索階段過後就應該會進入一個穩定提高期。經歷了摸索階段過後，團隊的技術、框架

和流程規範都應該有了一個基本的定型。這個時候團隊的目標就是通過不同的專案實踐來不 斷優化這些定型後的東西，最終總結出一套最佳實踐出來。它應該能夠成為其它專案測試活 動的參照，甚至是標準。這個時候，我們會發現所有的專案都在有序、統一、高效、可靠的 進行。

擴大影響，組織共贏階段 ：

那麼到達上面這個目標之後是不是就是介面測試團隊的終點呢？顯然不是，不要忘了，

到目前為止，無論你在介面測試的工作上做得再好，那也僅僅只侷限在介面測試本身上。我 們不應該滿足於此。通常來說介面測試團隊在整個質量保證團隊中佔據了眾多的核心技術人 員。他們擅長使用各種技術來解決問題，甚至比開發團隊做得還好。擁有如此多的技術資源， 如果我們不懂得合理利用，那真的是很大的浪費。在做好介面測試本身的基礎上，我們還應 該積極瞭解其它測試團隊面臨哪些問題，這些問題是不是可以利用技術手段來解決，如果可 以，我們是否可以為他們實現一些實用的工具來幫助他們解決問題或者提高工作效率；我們 自己的技術是否有需要分享給其它測試團隊，甚至是整個軟體團隊，以幫助他們更好地完成 工作。總之，我們應該思考如何更有效、更合理地利用介面測試團隊的資源，來提高整個組 織的業績，這不僅會擴大介面測試團隊本身的影響力，讓介面測試團隊成為整個組織的核心 競爭力，同時它還創造了一個共贏的局面。

另一方面，在工作的流程上，各個測試角色是可以互補的，介面測試的設計、用例可以 跟功能和效能測試共享，介面測試的報告可以作為功能測試的重要參考，讓其瞭解底層都經 歷了哪些測試，哪裡是 bug 的密集區，哪裡相對安全一些。在功能測試工程師找到 bug 之後， 介面測試工程師可以用程式碼直接覆蓋這個 bug 產生的程式碼，使這個 bug 永遠不會出現第二次。 介面測試人員還可以直接繞過頁面，對底層系統進行效能和壓力的測試，在測試中各個角色 的密切配合，也減少了測試的成本，提供系統全方位的質量保障。

3.介面測試的定位

3.1   人員能力定位

• 熟悉軟體測試流程,測試理論和測試方法。能夠根據測試需求，制定測試計劃和設 計測試用例。
• 瞭解軟體工程理論知識和開發流程，有一定的程式設計能力。能夠根據測試用例，準備 測試資料以及編寫和執行測試指令碼,並對軟體 bug 進行跟蹤分析和報告。
• 掌握 JUnit,Spring,Maven,CruiseControl,DBunit,Unitils,Ibatis 等技能，並且能夠運用這 些技能搭建介面測試框架。
• 思維活躍，善於發現問題，有較強的邏輯分析能力和學習能力。
• 具備良好的表達和溝通能力。
• 工作認真細緻，踏實肯幹，責任心強。

3.2  職責定義

我們的客戶是呼叫介面的人，不是開發介面的人 對業務的理解要達到開發人員的水平掌握軟體測試的理論知識要能夠獨立設計和開發測試，有定位問題的能力要能搭建系統的測試框架有權利在質量不達到要求的情況下阻止產品（專案）的釋出

3.3   工作內容定義

下圖是介面測試在各個發展階段的工作內容，在初期階段以編碼和持續整合為主，以後逐漸增加測試方案的設計和系統本身的分析、設計內容，最終為系統的整體質量負責。

4.介面測試的流程

4.1  專案工作流程

4.2  日常工作流程

規範而統一的工作流程是大家分工合作的基礎，只有每一個人都遵循統一的流程，專案才可能統一有序地進行。因而，規範的工作流程對提高團隊的合作能力以及工作效率都有至關重要的作用。

4.3   流程步驟詳解

根據以往的實踐經驗總結，介面測試可以分為以下幾個步驟：需求分析和設計評審，測試框架和技術選型，測試計劃制定，測試環境搭建，測試用例設計和評審，測試實現和執行， 持續整合。下面，將對每一個步驟作詳細說明。

4.3.1  需求分析和設計評審

幾乎所有軟體活動都是以需求分析開始的，介面測試也是如此。在本階段我們有兩個任 務：一是充分理解需求，並保證所有人對需求的理解一致；二是儘可能找出需求本身所存在 的問題。

需求分析之後，緊接著就應該進入系統設計階段了。系統設計不應該僅僅只是系統設計 師或者開發人員的事情，作為介面測試人員，應該可以從測試的角度為系統的設計提供一些 方案或者建議，優化設計的同時提高系統的可測性。

4.3.2   測試框架和技術選型

系統設計評審之後，系統實現所需要使用到的技術都應該已經選定。在這個階段，介面 測試人員就需要根據系統設計來選定自己的測試框架和要使用到的技術。當然，這並不是必 須的，如果你所測試的專案和之前已經測試過的專案技術架構都差不多的話，那麼你可以沿 用之前的測試框架和技術，或者在這個基礎上稍加調整。如果所測試的專案採用的是一種不 同的技術架構，那麼你就需要仔細考慮如何選定與之相適應的測試框架和技術。

介面測試框架和技術的選型有很多因素，原則就是選擇一個能滿足你的測試需要的最好 用的框架和技術，並且儘量是你的專案成員都比較熟悉的框架和技術。沒有必要單純為了提 高測試的技術含量而選用功能奇多但卻複雜難懂的工具來使用。

4.3.3   測試計劃制定

介面測試的測試計劃制定基本上和功能測試差不多。這個階段主要要明確有哪些測試資 源，測試資源如何分配，在整個測試過程中需要完成哪些事情，每個時間點應該完成哪些事 情，還有最重要的也是很容易被忽略掉的一點就是風險評估。雖然我們不可能識別出所有的 風險，但是我們可以根據經驗值來識別出大部分的潛在風險並加以管理。良好的風險管理是 一個軟體團隊成熟的體現。

4.3.4   測試環境搭建

在測試框架和技術選型完成以後就可以開始進行測試環境的搭建了，在介面測試中典型 的環境搭建過程可能是這樣的：首先你會為介面測試建立一個基本的工程，併為這個工程設 計一個良好的結構，在這個工程中引入你所選定的測試框架和依賴，為這些框架和依賴編寫 好必要的配置檔案，將該工程和待測系統的工程以某種形式聯絡在一起（通常是專案依賴）， 在該環境下能執行通過一個最基本的測試。

介面測試的測試用例設計是以介面為單位來設計測試，在設計的過程中我們重點關注的是介面有哪些可能的輸入引數和預期的輸出結果是什麼。當然在需要的時候，也要考慮介面 的效能和所期望承受的壓力等。在這個過程中很重要的一點就是為不同的測試劃分優先順序， 這在測試資源不足的情況下將會指導你哪些測試應該優先完成，哪些測試可以延遲完成。即 便是在測試資源很充足的情況下，你也可以按照優先順序來完成測試，這樣一旦遇到某個風險 爆發，那麼基本上可以保證，優先順序高的工作已經完成了，而不至於驚慌失措。

測試用例設計出來以後應該經過評審，並將評審結果以某種形式記錄下來，作為測試實 施的最終方案。評審最好由以下這些人員共同參與：需求方、設計人員、開發人員、功能測 試人員、介面測試人員以及這些人員的直接主管。不同的角色會從不同角度對測試設計進行 考慮，因此在這個過程中會使測試設計得到極大的完善。

4.3.6  測試實現和執行

測試設計一旦產出並通過評審，那麼測試實現相對來說就是一件比較簡單的事情了。無 非是將一個個測試用例用程式語言實現出來並執行通過。

在測試實現的過程中可能會發現測試設計不夠完善，或者是因為需求的變更而導致需要 增加新的測試用例。不管是因為什麼原因，在實現測試的過程中，一旦發現有可以完善的地 方就應該立刻記錄下來，這樣可以更有效地保證測試的完備性。

在這個過程中我們還應該產出測試報告（包括日報和最終報告），讓整個團隊都及時掌 握專案的質量情況，以便不同角色正確安排工作。

4.3.7  持續整合

持續整合是介面測試實現全面自動化迴歸測試的重要技術手段。簡單來說，持續整合就 是把寫好的測試程式碼持續不斷地執行起來，並且利用版本控制技術，讓測試程式碼測試的始終 是最新版本的系統介面。

當介面測試進行到這個階段的時候，我們的目標就是要讓測試程式碼持續不斷的執行，並 且保證在執行不通過的時候及時定位並解決問題。在開發人員維護系統的時候，我們同時也 會根據持續整合的結果來維護我們的測試程式碼。

最後，需要注意的是，雖然以上提及的步驟是我們介面測試人員遵循的規範，但是不同 於功能測試等其他測試，介面測試需要與開發同步進行。如下圖所示，在專案啟動的時候我 們就要參與進去，在編碼結束時測試也基本完成，中間的每個步驟也與開發緊密相關。因此， 我們介面測試的工程師又叫測試開發工程師，我們既需要測試的知識，又必須具有一定的編 碼能力。

介面覆蓋率是否達到要求。

1) 所有供外部呼叫的介面必須有相對應的測試用例，覆蓋率要達到 95%以上。

2) 所有供內部呼叫並涉及到產品主要功能的介面測試用例覆蓋率要達到 90%以上。

3) 所有供內部呼叫並涉及到次要功能的介面，測試程式碼覆蓋率可以隨介面複雜度和重 要程度增高而增加。

測試用例中對介面業務規則的驗證是否完整。

1) 測試用例要覆蓋介面的主要業務規則。 介面的主要業務規則，就是該介面的主要功能，它影響著介面的業務實現和呼叫狀態。

如釋出一個寶貝，那麼釋出一個全新、二手、拍賣、閒置的寶貝等等就是主要功能。

2) 測試用例要覆蓋介面的常用業務規則。 還是釋出寶貝的例子，80%的賣家都會在“描述”中加入圖片，旺旺連結等。這個業務

規則不會影響介面的正常呼叫。但卻影響著使用者的使用習慣。所以測試用例中必須包含對“描 述”欄位中含有圖片連結，旺旺連結的驗證。

3) 引數驗證要覆蓋對邊界值和引數特有業務規則的驗證。 很多介面中都會對其引數有一定的限制，如一個欄位長度限制為<5，那麼就至少要存在

對該欄位的長度為 4，5 的測試用例。

 測試用例中是否覆蓋介面之間的關聯性測試。 如：一個新增介面的關聯性測試，就要以該新增介面的返回值為引數，來呼叫其他關聯

介面如修改和刪除介面，驗證其是否可呼叫並且呼叫成功。

遺留的 bug 對系統的影響程度。

1) 經常呼叫的介面，不可含有主要業務規則和常用業務規則相關的 bug，次要業務規 則的 bug 遺留率為 0.2%以下。

2) 不常呼叫的介面，不可含有主要業務規則的 bug，常用業務規則的 bug 遺漏率為 2%

以下，次要業務規則的 bug 遺漏率為 5%以下。

測試用例與測試程式碼是否一致。

測試用例是否可持續迴歸。

經過測試的介面是否達到了呼叫方的標準，呼叫方能否使用該介面來開發出產品設 計說明書所設計的應用。

5.介面測試的技術簡介

介面測試用到的框架和技術很多，我們本著不重複發明輪子但讓輪子協同工作的原則對 這些框架技術進行整合、擴充套件，不斷增強其功能和使用方便性。常用的技術簡介如下。

• Junit

JUnit 是 java 語言事實上的標準測試框架，是介面測試技術中最基本的利器，有以下 要特性：

批量執行

無論是利用 JUnit 命令列，還是 Eclipse，或者是當下很流行的整合測試框架，我們 都可以使用一個簡單的命令，按鈕或者操作來啟動我們成百上千或者更多的測試用 例，想象一下，如果讓我們用人力來做操作，那將是多麼一件耗時耗力的事。

斷言機制

通過斷言機制，讓我們的程式能夠自動的判斷測試結果是否正確，而無需我們人工的去分析和判斷。通過批量執行和斷言機制，使得我們的自動化測試變得可能。

測試報告

當測試執行完畢後，JUnit 可以產生很全面的測試結果，成功還是失敗一目瞭然， 對於失敗的用例會報告明確的錯誤資訊。這些都讓我們對整個測試的執行情況有很 好的掌控。

易於擴充套件

當下越來越多的工具都在基於 JUnit 的骨架上進行擴充套件，無論是 Unitils，Eclipse， 還是 Maven 都對 JUnit 提供了很好的支援。

• DbUnit

DbUnit是一個基於JUnit擴充套件的資料庫測試框架，目的是在測試執行前後使資料庫處 於可知狀態。它提供了大量的類對與資料庫相關的操作進行了抽象和封裝，運用DbUnit 的一般流程如下:

1) 根據業務準備測試用的資料，一般準備成 Excel 格式的資料集；

2) 在測試執行前，將資料集更新到資料庫；

3) 在測試執行後，將資料庫恢復到測試前的狀態。 在實際測試中直接運用DbUnit的情況很少，通常是跟其他技術（如Unitils）一起配

合使用。

• Spring TestContext Framework

Spring TestContext Framework 是 Spring 2.5 版本推出的測試框架，方便使用 Spring 容器 進行整合測試，而不依賴應用伺服器或其它部署環境，是測試 Spring 應用程式的首選良器。 主要提供以下功能：

u Spring 上下文管理和快取

提供對 Spring 上下文的持久化載入和快取機制，節省 Sprng 容器啟動時間，從而縮 短大型專案整合測試執行時間，有效提高測試效率。

• 測試 fixtures 依賴注入 通過依賴注入選擇配置測試類例項，方便使用已有的配置檔案搭建測試 fixtures， 實現 Spring 上下文在多個測試場景中的重用，從而能避免為單個的測試案例重複 進行測試 fixture 搭建。

事務管理

適用於測試中需要呼叫事務代理物件的情形，對每次測試建立並預設回滾事務，避 免因為改變資料庫的狀態而影響後面的測試。

整合測試支援類

提供若干抽象類簡化整合測試編碼，方便測試類直接訪問 ApplicationContext 來 進行顯 式 bean 查 找或整 體測試 上下文 狀態 ，訪問 JdbcTemplate 或 SimpleJdbcTemplate 來驗證資料庫狀態改變。

監聽器機制 通過監聽器實現依賴注入、事務管理等功能的靈活配置而無需繼承任何 Base 類， 提供了良好的擴充套件點方便實現自定義監聽器實現特定功能。

• Unitils

Unitils 是輔助單元測試的一個開源類庫，其目的是使單元測試更為簡單和便於維護。 同時也對一些現有的類庫（如dbunit）進行更好的擴充套件，並且可以和JUnit以及TestNG測 試框架進行整合。

Unitils提供通用的斷言工具，支援資料庫測試，支援使用Mock進行測試，並提供對 Spring以及Hibernate的整合。

Unitils提供以下功能：

常用的測試工具。 通過反射來實現等值斷言，並提供忽略Java預設值以及空值以及集合內順序等選項。

Mock 物件的支援

1) 通過簡單的語法實現動態定義控制代碼/存根（stub）的行為以及對 Mock 呼叫的驗 證；

2)    良好的反饋，包括一個簡單並且可擴充套件的呼叫場景報告以及建議式的斷言宣告；

3) 通過使用引數匹配器來解耦方法引數間的約束，並可混合實際物件一起使用， 當某些引數不對測試產生影響時可以使用空值；

4)   當存根（stub）資料物件並不需要提供具體行為相應時，可使用虛假物件。

持久層測試的支援

1)   通過一些增長的，可重複的，或後期處理指令碼來自動管理資料庫；

2) 提供自動地使資料庫約束失效，將序列（sequences）設為最小值等功能，支 持 Oracle, Hsqldb, MySql, DB2, Postgresql, MsSql and Derby；

3)   簡化測試資料庫連線的建立；

4)   通過 DBUnit 簡化測試資料的插入；

5)   提供 Hibernate SessionFactory 的建立以及 session 的管理；

6)   提供 Hibernate 之類的 ORM 類庫的資料庫對映的自動測試。

對整合 EasyMock 的支援

1)   簡化 EasyMock mock 物件的支援；

2)   簡化 mock 物件的注入；

3)   使用反射機制匹配 EasyMock 引數。

Spring 整合

1)   通過上下文配置，使得 Spring 管理的 bean 可以簡單的注入到單元測試中；

2)   支援在單元測試中使用由 Spring 配置的 Hibernate SessionFactory。

• TestNG

TestNG 是為了解決 Junit 過於簡單的問題而產生的，它與 Junit 是同一類的框架，兩者不 能同時使用，這與對 junit 的擴充套件框架如 dbunit,unitils 等有非常大的區別。

TestNG 相比 Junit 增強功能如下：

定義測試組的能力，每個測試方法都可以與一個或多個組相關聯，但可以選擇只運 行某個測試組。

重新執行失敗的測試，對於每天都進行編譯來說非常有幫助。

提供了依賴檢查機制，並可以嚴格控制執行順序。

可以簡單的直接進行多執行緒測試了。

提供 xml 方式的引數化測試。

• CruiseControl

CruiseControl 是一種持續整合過程的框架，包括了旺旺訊息通知、郵件通知，Ant、Maven 和各種原始碼控制工具（SVN、CVS）的外掛，並提供了 web 介面，用於檢視當前和以前的構 建的結果。

通過運用 CruiseControl 持續整合實現自動化構建指令碼和測試完全自動化，其自動構建機 制工作流程流程如下圖示。

• Clover

Clover 是 Atlassian 組織的一款優秀統計測試覆蓋率外掛，可以免費用於非商業途徑， 可以為 Maven2 構建的專案生成報告。Clover 通過以下常用指標衡量測試覆蓋率。

• Statement coverage，也稱作 Line coverage，用於評價測試的程式碼語句覆蓋率。

• Basic block coverage， 是 Statement coverage 的一個變種，它把沒有一個分支的代 碼區域作為一個計量單位，而不是簡單的程式碼行，用於一個 if-else 分支程式碼行數遠 遠大於另一個的情況，在這種情況下，statement coverage 指標並不適用。

• Decision coverage（也稱作 Branch coverage），用於評價程式碼分支地測試覆蓋率。

• Path coverage，和 Decision coverage 相似，用於評價程式碼從開始到結束所有路徑的 測試覆蓋率。

• Function coverage，用於評價程式碼方法的測試覆蓋率。

6.介面測試的方向

在經歷了介面測試的發起、穩定、成型以後，我們有必要探討一下介面測試的未來。然 而，這卻是一個十分困難的命題，因為，未來永遠是一個謎。任何形式的預測，最終結果常 常成為笑料，IT 業界尤其如此。鑑於此，我們需要把更多的目光關注到介面測試的發展方向 上，而不是介面測試發展的最終結果的預測上。

介面測試之框架改進 目前，我們已經形成了完整的介面測試框架。但在不同的專案中，差別仍然很大，沒有

形成統一的基礎架構，從而導致構建介面測試框架的過程比較繁瑣，因此，我們可以在以下 幾個方面進行改進與優化：

1、測試資料管理框架構建與統一；

2、介面測試專案構建基礎框架； 3、mock 框架化； 4、高比例程式碼自動生成框架；

5、介面測試工具集與三方庫的本地化應用。

介面測試之持續整合 對於介面測試的技術而言，核心內容是持續整合，即自動化。其實，這個內容和其他的

測試也是一致的，從本質上來說，自動化代表了未來測試發展的主流方向。目前，我們已經 實現了介面測試的持續整合，而更高程度的自動化、更加廣泛的自動化是我們未來的發展方 向。

更高程度的自動化包含：1、持續整合框架的柔性改進，包括更加豐富的測試結果、更 加人性化的結果展現，測試結果旺旺/郵件推送，而不僅僅是專案構建失敗的提醒；2、持續 整合中介面測試專案自動構建與部署。

更加廣泛的自動化包含：1、各開發語言介面測試持續整合，HUDSON 的研究與應用；2、 將介面測試應用到更加廣泛的專案當中；3、持續整合框架與測試框架（用例、缺陷）的整 合。

介面測試之測試驅動 介面測試是白盒測試的一部分。作為介面測試而言，我們不僅需要保證程式碼的質量、系統的效能，我們還需要保證系統開發過程的正確性與高效性。測試驅動開發是介面測試的一 個重要思想。

在介面測試的過程中，我們要力求做到覆蓋到更多的程式碼行，覆蓋到更多的邏輯過程， 驅動開發更加準確、高效的實現自己的程式碼。同時，我們需要對程式碼進行分析與評審，驅動 開發提高程式碼的質量。

介面定義在系統級架構的過程中，是非常重要的一個環節。介面定義是否合理，需要從 更高層面，譬如系統的互動性、系統的易用性、系統的可擴充套件等方面來考慮。介面測試的職 責，需要從這些方面來約束和規範系統的介面定義過程，驅動開發完善設計，避免介面定義 的隨意性以及介面改動的頻繁性。介面的改動對系統的傷害是不言而喻的。因此，從一開始 就驅動開發完善介面定義是介面測試的一個重要發展方向。

介面測試之未來遐思

我們生活在資訊膨脹的時代，IT 行業的發展越來越快，也對測試提出了更高的要求。提 出成本更低，效率更高的測試技術、測試框架、測試方法、測試理論是我們未來能適應高速 發展的 IT 行業的基本要求。因此，我們提出如下的設想：

測試虛擬化：提供介面測試虛擬機器，構建測試虛擬化層。將被測系統執行在虛擬機器中， 與外部系統剝離，進行內部程式碼檢測、記憶體檢測、資料校驗與邏輯檢測。

測試智慧化：智慧分析系統程式碼，智慧生成測試程式碼，智慧 mock 外部系統，智慧執行 測試程式碼，智慧分析測試結果，智慧定位缺陷，智慧修復缺陷。