預備知識：深入理解介面測試

來自專欄強哥學堂17 人贊了文章

實驗簡介

隨著移動互聯網甚至物聯網的觸角深入到人們生活的每個場景，每個角落，伴隨而來的便是企業對其軟體系統介面定義和研發，以便於進行數據傳輸和交換。由此導致目前企業急需大量專職介面測試工程師，因為介面測試天然具備自動化測試的可行性。所以本章內容專門就介面測試的各種存在形式給大家統一一下思路。

實驗目的

（1）理解介面測試的含義與作用。

（2）理解代碼級介面測試與協議級介面測試。

實驗流程

1. 關於介面測試

介面測試是一個比較寬泛的概念，近幾年在國內也受到很多企業和測試從業者的追捧。但是很多人對介面測試的理解並不完整，事實上，我們無論通過何種方式運行一段程序，我們都必須依賴於調用該程序的介面才能實現。

比如，假設我們現在通過登錄界面輸入用戶名和密碼，點擊登錄按鈕，最終該操作會被組裝為一個HTTP請求進而發送給後台伺服器端，後台伺服器則會直接調用實現登錄的介面，通過該介面來運行登錄的實際代碼。

那麼在這個過程中，點擊「登錄」按鈕是一個前端界面，所以我們如果通過該方法來觀察其最終運行狀態的，我們稱之為界面級的黑盒測試。當然，我們也可以利用各種協議發送工具甚至用代碼發送協議數據包給後台伺服器進而觀察其運行狀態，此時，我們稱之為協議級的介面測試。當然，我們也可以從代碼層面直接調用該登錄介面，那麼此時我們稱之為代碼級的介面測試。最後，我們還可以直接深入到代碼實現層，對代碼的實現邏輯進行詳細的測試，我們又稱之為白盒測試或單元測試。

那麼問題來了，這整個過程唯一的區別僅在於我們調用該登錄代碼的方式不一樣，最終真正工作的，都是同樣的一段代碼，這個本質是絕對不會因為被調用的方式不同而發生一丁點的變化的。所以，任何一種調用的方式，都是在驅動程序運行而已，本質上來說，他們所做的事情沒有任何區別，那麼與其這樣，我們為什麼還要基於界面來測試登錄的功能呢？我們完全可以基於其介面來進行測試，也可以達到同樣的目的。比如我們可以通過發送HTTP請求的方式來測試登錄功能，也可以直接調用登錄代碼來測試登錄的功能。而且這樣的做法都是可以自動化的，也是可以重用的。這也是為什麼介面測試越來越受到重視的原因。

當然，也正是因為介面測試的所謂介面，是一個不太容易下定義的概念，所以我們千萬不能盲目地認為協議級的測試就是介面測試，或者代碼級的測試就是介面測試，這些理解都太過絕對。事實上，點擊「登錄」按鈕，也可以被稱之為一個介面，而與之對應的測試，我們則只能稱其為界面級的介面測試了。所以請大家不用糾結於概念本身，更多地專註於從不同角度來完成對一個功能的測試，進而達到更全面的測試覆蓋，儘早地找出Bug才是王道。

2. 關於白盒測試

本書在前一章便將自動化測試從另外一個角度為大家進行了歸類：代碼級，協議級和界面級。本書所講的白盒測試，統指代碼級的測試。白盒測試是相對於黑盒測試而言的一種測試方法而已。是指我們可以基於系統的代碼層邏輯來實現非常有針對性的測試，其參考文檔主要是系統的詳細設計文檔，甚至可以精確到演算法層實現，也可以向上提升到代碼介面層。

白盒測試的核心就是利用測試驅動程序來測試被測程序（如某個函數或方法），所以白盒測試默認情況下自帶自動化測試屬性。從介面測試的定義來看，白盒測試自然也是通過調用其函數或方法的介面才能完成測試的執行。所以，本書後續所介紹的白盒測試，均是指基於代碼級介面實現的測試。我們既關注介面規範，也關注代碼的邏輯實現。

白盒測試既然天然就是屬於自動化測試，我們當然應該重視白盒測試工作，將白盒測試，灰盒測試和黑盒測試有效地結合起來，各自完成不同的測試。比如我們可以重點利用白盒測試來完成對基本功能點的測試或部分性能測試，利用灰盒測試如協議級測試來完成可靠性，安全性，性能等測試工作，利用黑盒測試完成用戶體驗，兼容性方面的測試。通常情況下，這樣的組合，會讓我們的測試工作變得更加有效率。建議大家不妨在工作當中嘗試這樣的組合。

3. 代碼級介面測試實施價值

代碼級測試在預防軟體產品的Bug方面其實是非常有效的。如果我們將其發揮好，從組織和技術層面做好協調和規範，其價值不容小覷。簡單將其歸結為如下幾點：

（1）容易上手：只要對代碼有一定概念，都可以輕易完成針對代碼的專項測試。即使是一個沒有受過正統的程序設計培訓的人，也可以比較容易地按照標準流程和模板完成測試腳本的開發和測試數據的準備。

（2）容易實施：由於代碼級測試工作直接使用測試代碼來調用被測代碼（通過其開放出來的介面進行調用），所以實施過程非常容易。我們只需要通過簡單的判斷就可以確定該項測試是通過還是失敗。

（3）容易維護：通常情況下，在軟體研發的過程中，一旦代碼的介面確定，變動相對比較少，所以維護該測試腳本的工作量相對較低。測試腳本也相對比較穩定。

（4）容易見效：一旦我們將代碼級測試工作實施起來，效果是非常明顯的。馬上可以看到測試腳本所產生的效果。

（5）容易定位：由於測試腳本直接調用被測試代碼，所以一旦測試腳本無法運行通過，要定位該問題將會變得非常容易，同樣的，修復該問題的成本也會更小。

（6）增強質量意識：事實上，很多企業的代碼級測試工作會由測試團隊和程序員團隊共同負責，這將非常有助於程序員團隊在編寫代碼時增強其代碼的質量意識，為全員質量意識打下堅實的基礎。

4. 代碼級介面測試實施難題

那麼，代碼級測試既然這麼有價值，為什麼現在很多企業並沒有真正將其實施得很好呢？為什麼我們平時看到的絕大多數企業都只是在大談特談介面測試或界面級功能測試，或者是系統級性能測試，很少談及代碼級測試呢？當然，這當中有技術原因，但是更重要的，是人為的原因。筆者就這些年的經驗，為大家總結一下為什麼很難將代碼級測試實施起來的一些原因：

（1）程序員不習慣：程序員們都非常習慣了直接上手寫代碼，並沒有養成寫代碼之前或之後還要來寫測試代碼的習慣。每一個程序員，從開始寫代碼的第一天起，就從來沒有人給他們傳遞過，什麼叫質量意識，什麼叫代碼之美，什麼叫敬畏之心。

（2）測試人員編碼能力差：很多測試工程師在編碼方面的能力的確不敢恭維，而且國內普遍存在這樣一種奇怪的現象就是寫不好代碼的人才去做軟體測試，可以相像，這樣的軟體測試，又能測試得有多深入？

（3）程序介面無規範：代碼級測試能夠實施好，必須需要一個規範的設計文檔和介面說明，甚至清晰的演算法實現。但是在很多研發團隊中，能把客戶的需求分析清晰，形成文檔已經不易，根本沒有時間來設計介面規範等這麼細節的事情。所以程序編寫的過程就是一個打補丁的過程，導致代碼級測試工作很難實施。

（4）利用調試代替測試：程序員團隊都會將自己的代碼進行調試，進而儘早地發現程序中可能存在的Bug。這本身並沒有錯，錯的是誤認為這就是測試。事實上，調試是單次的，隨機的行為，不具備可重用性，比如程序員每一次調試輸入的數據可能都是隨機的，而且這個數據很有可能沒有很好地覆蓋代碼邏輯。而代碼級測試則是嚴謹的，可重複運行的。無論程序怎麼樣修改，只要能夠順利通過代碼級測試，則都是可以接受的，除非測試程序有Bug。

（5）項目時間緊迫：這應該是每一個團隊都會提到的一個問題。由於時間緊迫，我們沒有時間完整地測試；由於時間緊迫，我們沒有時間寫測試腳本；由於時間緊迫，我們只能全部時間都用來寫代碼？但是真的這樣就可以提高效率嗎？無數失敗的或延期交付的項目經驗告訴我們，如果沒有很好地規範和嚴謹的流程，以及全員質量意識，即使項目趕出來了，客戶也不一定認可。

（6）只關心用戶看得到的東西：什麼，代碼還需要專門測試？我們只做黑盒測試，將用戶的操作過程模擬好就行，這樣用戶就不會發現問題了。但是，很奇怪的是，往往用戶什麼問題都可以發現，我們千萬不能抱有僥倖心理。

（7）測試程序複雜度高：有時候我們為了能夠調用一個被測代碼，我們需要準備大量的測試環境和測試數據，這個是代碼級測試經常遇到的問題。就是測試驅動程序很難開發，導致代碼級測試的門檻較高。還不如最後由黑盒測試來完成來得簡單方便。事實上，這個問題我們需要辯證地來看待，針對測試環境非常複雜的情況，無論白盒，黑盒，可能測試起來都會比較複雜。問題始終都得解決，通常筆者會建議代碼級測試更多關注在代碼的演算法層或邏輯實現層（即層次更低的代碼）。而協議級或界面級的測試，更多關注於控制層代碼。

事實上，筆者並不想鼓吹代碼級測試多麼完美，多麼有價值，但是我們一定不能無視它的存在。如果在研發團隊中，我們把代碼級測試簡單實施起來，邁出第一步，或許，我們會更容易理解並接受，進而認可其價值。簡單來說，代碼級測試的工作多做一些，系統測試的工作我們就可以少做一些，而且根據缺陷放大模型，把問題扼殺在搖籃中，更能看到其價值。

思考練習

（1）請理解單元測試與白盒測試，代碼級介面測試與灰盒測試在作用上的區別。

注：希望學習更多技術，繼續在IT行業突破提升自己的各位朋友，歡迎加群594154674，不管你自我感覺牛不牛B。