1.什么是接口測試
接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
2.為什么做接口測試
首先，節省測試成本，數據模型推算，底層的一個bug能夠引發上層的8個左右bug，而且底層的bug很容易引起全網的宕機。相反接口測試能夠提供系統復雜度上升情況下的低成本高效率的解決方案。
其次接口測試不同於傳統開發的單元測試，接口測試是站在用戶的角度對系統接口進行全面高效持續的檢測。
最后接口測試是自動化並且持續集成的，這也是為什么接口測試能夠低成本高收益的根源。
總之接口測試是保證高復雜性系統質量的內在要求和低成本的經濟利益的驅動作用下的最佳解決方案，接口測試是一個完整的體系，也包括功能測試、性能測試。
3.接口測試的適用范圍
接口測試一般應用於多系統間交互開發，或者擁有多個子系統的應用系統開發的測試。接口測試適用於為其他系統提供服務的底層框架系統和中心服務系統，主要測試這些系統對外部提供的接口，驗證其正確性和穩定性。接口測試同樣適用於一個上層系統中的服務層接口，越往上層，其測試的難度越大。接口測試在淘寶的應用是一個自下而上的發展過程。
接口測試實施在多系統多平台的構架下，有着極為高效的成本收益比。接口測試天生為高復雜性的平台帶來高效的缺陷檢測和質量監督能力。平台越復雜，系統越龐大，接口測試的效果越明顯。
4.在接口測試中如何應對需求的頻繁變化
在現在這個互聯網軟件時代，需求的頻繁變動已經不是什么新鮮事。客戶的需求變更、市場需求的變更，項目本身的調整，以及新需求的出現等等都會導致需求的變化。這種需求的變化常會出現在項目開發階段，根據需求的變化開發人員會對項目進行調整，而作為在項目開發階段就接入進行測試的接口測試人員同樣也會被影響，這種影響有時是巨大的，影響着我們的工作效率，它會導致我們需要重復以前的部分測試工作，甚至會讓我們以前所做的測試工作白費。而且越是大型的、復雜的項目，這種影響越大，暴露出的問題也越多。
針對這段期間我在項目中的體驗，將需求變化對接口測試的影響和出現的問題羅列下：
1. 需求變化，接口測試人員不知道或過了很久才知道。由於某些原因，常常會導致新需求變動接口測試人員不知道，或是過了很久才知道。往往接口測試人員是通過用例回歸發現用例跑不通，然后會進行錯誤排查，最后發現問題后和開發確認后才知道是需求變化。這樣是很浪費時間，甚至會遺漏一些需要測試的新需求的功能點，導致測試不全，遺漏bug。
2.需求變化，對原有測試用例及其代碼的影響.這個也是最讓我頭痛的、最直接的影響。需求變動有時會打亂了原有的測試規划，甚至包括對測試特性的划分原則，相應的測試結果分析驗證、測試需求跟蹤等都不到位。並且我們接口測試會對一個項目寫上百個測試用例，為了盡可能的發現bug，測試用例里面有無數的驗證點。往往一個很小的需求的改變會影響到很多的測試用例代碼不通過，我們需要對很多測試用例進行調整，需要對測試數據以及測試代碼進行修改，有時甚至需要修改我們的測試框架。這對我們接口測試人員來說是一個不少的挑戰。
3. 新需求變化測試時間短，開展詳細的測試有難度。由於新需求的提出已在開發期間，其測試時期短，接口測試有時沒有人力和時間投入對新增修改需求的測試分析和設計上，基本上很難像對待老需求一樣，開展詳細的測試分析設計。
如何減少需求變更對接口測試的影響：
1. 良好的心態。從心態上，接口測試人員應該把需求變化當作是一種項目常態，平常心應對。但是，我們也要學會控制這種需求變化的趨勢，不能任其發展。
2. 及時溝通，最快知曉需求變更。和需求相關人員和開發人員做好即時溝通，第一時間知道需求的變更，及時做好測試策略更新。知道的越早對我們的影響越小，需要的測試成本也越低。
3. 良好的團隊合作。接口測試人員和開發人員的良好合作，分工明確，對新的改動及時通知對方，短時間內開展最有效的團隊協作。接口測試人員要主動關注開發代碼的修改，對測試用例和測試代碼及時調整，做到小粒度的修改。
4. 接口測試人員反應快，用例代碼靈活性高。接口測試人員反應快，提前做好新需求的測試規划，包括測試設計和測試執行規划，並且在設計中要考慮新需求對老需求的影響；並且我們原測試用例和代碼也要有一定的靈活，可以在一定程度上適應需求變化，將未來的新需求的影響盡量降到很小。這里就不詳細說了，下次就具體的MC的項目說說如何增強測試用例代碼的靈活性，減少新需求對測試代碼的影響。
5. 做到及時的需求跟蹤。通過測試用例代碼的不斷回歸，盡早的主動的發現需求的變更。
我們接口測試人員要成熟、快速、有序、靈活、有責任心的應對需求的變化，把我們的接口測試工作做得更好。
5.接口測試中測試與開發的配合
作為一名測試人員，工作中接觸最頻繁的應該要數開發人員了。在整個測試過程中，開發人員是與測試人員是走的最近的，因為從最初測試的需求到測試中發現的缺陷的處理以及最終測試的總結，都需要和開發人員緊密合作。
接口測試因其天生的代碼親密性，為了更好地提高產品質量，就要求測試人員更加地深入到開發的工作中去（從需求出發深入到代碼、頁面中去），甚至是與開發並行地工作。那么這就對測試人員和開發人員的合作與互動提出了更高的要求。
也許有人會認為開發和測試在項目中相互獨立會更加好，在此對這個問題不作討論，只想說說從始至終與開發保持聯系的好處。時刻保持聯系，可以使雙方對於項目的進展有一個明確的共同的理解，使項目的執行更加順利。減少一些缺乏溝通而可能造成的工作內容的沖突，例如對於需求理解的不一致、需求變更等。
2、測試需求不光來自於PRD和UC，還要傾聽來自開發的需求，這往往是他們擔心的內容
誠然PRD和UC是測試需求的主要來源也是測試工作的依據，然而從PRD和UC出發的測試需求往往是功能性的，會遺漏不少細節，特別是在接口測試工作中，這些細節又往往體現在開發的工作中，或者某些具體的實現中。因此傾聽開發的測試需求，同時提出測試對於開發的要求是十分必要的。開發的需求經常是體現了在開發中他們沒有把握的地方，這些光靠分析PRD和UC是很難得到的。
讓開發知道測試在做什么是怎么做的，當前測試的狀況是什么樣子的，測試也要了解開發的進度和工作內容。開發了解測試的方法和內容會有利於提高代碼的可測性以及代碼的品質。測試了解開發的工作方式和進度，就便於和開發進行合作加快缺陷的修復和驗證。不僅要了解，在了解的基礎上相互交換意見和看法，這往往能相互提高工作效率。
4、職責明確，測試應全面負責測試的工作環境、配置、代碼，開發不應當隨意改動。
講了很多互動的地方，但是有些內容卻不應是互動的。就接口測試來說，測試環境配置和測試代碼應當全部由測試工程師來維護，因為測試工程師主導整個測試的過程並對測試的結果負責。可以請開發協助配置環境這是必要的，但是出現任何測試方面的問題，開發都不應該在沒有和測試工程師溝通的情況下介入測試環境和測試代碼的變更。因為這樣往往會導致測試用例無法通過，測試環境被破壞，測試結果可信度下降。會給項目進度帶來不必要的影響。
相應的，由於接口測試的代碼往往和工作代碼在一個工程下，測試也不應該去改動開發的工作內容，這會帶來十分嚴重的后果。
5、測試應當高度關注測試持續集成的結果，第一時間分析問題，並初步定位后轉交開發。
在此我想強調下初步定位並轉交開發的問題，可能有些同學會覺得缺陷被發現后直接轉交開發就可以了，定位缺陷的事開發完成就可以了。我有一些不同的想法，能夠定位缺陷意味着對於項目有着較為深入的了解，將有助於提高缺陷修復的效率。例如，同樣是查詢結果異常的問題，原因可能各有不同，如果初步將問題進行定位，必定能提高這些相似但實質卻不同的缺陷的解決效率。