介面文件（概述）

作為介面自動化測試教程的最後一章，我們來講述一下影響介面自動化測試工作的乙個重要因素：介面文件。測試人員對指令碼語言的熟練程度，檢測點的設定技巧等相關的技能確實影響著介面自動化的實施，可以說介面自動化測試之本介面文件卻是重中之重。

介面文件，顧名思義就是對介面說明的文件。好的介面文件包含了對介面url，引數以及輸出內容的說明，我們參照介面文件就能編寫出乙個個的測試用例。而且介面文件詳細的話，測試用例編寫簡單，不會遺漏。

如果乙個介面文件沒有寫清楚，你從文件中分不出哪些兒引數是必需的，哪些兒是非必須的，而且沒有引數的取值說明，返回值的結構等資訊的話，測試人員是無法編寫相應的測試用例的。但是由於開發人員不願意寫文件，所以很多介面文件相對來說比較簡單，模糊不清，這對我們做介面自動化測試是很大的阻礙。

介面文件可以包含很多資訊，有的願意寫就可以多寫的，不太願意寫的話，就寫的資訊相對來說會少點兒。不過，下面幾項內容必須有，這是我們使用介面中和測試介面的依據：

（1）介面名稱。標識各個介面的簡單說明，如登入介面，獲取專案詳情介面等。

（2）介面url。介面的呼叫位址，在測試環境下前面的網域名稱可能不一樣，不過介面名是不會變的。

（3）呼叫方式。介面的呼叫方式：post/get方式，決定了如何呼叫介面及傳遞引數。

（4）引數格式。介面需要傳遞的引數，引數需要增加些兒說明：

（a）引數值型別說明：引數值要說明一下，只支援字母，資料，特殊字元或是字母資料混搭。

（b）引數長度說明：引數接收最大多少個的字串，或是最大是多少的數值等。

（c）引數取值範圍：像列舉型的引數，只接收什麼範圍內的資料，如1-5等。

（d）引數的配合說明：有些兒引數需要配合起作用的，如：offset和count引數。

（e）引數是必需的還是非必需的。

（5）返回報文。介面的返回值說明需要包含正確和錯誤的情況，正確的情況下有哪兒資料，錯誤的情況下會有什麼提示？

（6）功能說明。說明介面名稱的具體功能說明。

（7）其它說明。

上面的說明是通用的，還有其他的一些兒說明，如必須是登入狀態呼叫，或是版本號等說明，在某些兒情況下也需要說明一下。

嚴格要求的公司會要求介面開發人員標明上面相關的介面說明，此時我們做介面測試的時候，就可以參照文件來轉化我們的測試用例。但目前國內很多公司不太注重文件，介面資訊不全是常有的事情。

針對目前介面文件資訊不全或是沒有介面文件的情況下，如果上面的領導要求我們做介面自動化測試，這無異是乙個非常艱辛的任務。但是奉承著「兵來將當，水來土掩」的原則，我們要想著解決辦法。

（1）完全沒有介面文件。這個情況是最麻煩的，我們要找開發人員來商量，最好能補個介面文件，如果實在來不及那就給個呼叫介面的例項。例項中會有介面位址，引數等資訊，我們去測試環境中呼叫一下，就能看到返回結果的情況。

（2）介面文件資訊不全。資訊不全這個最常見，像引數說明缺少啊，沒有說明哪些兒是必需的引數，哪些兒是非必需的，或是沒有說明取值範圍等。此時我們能問開發就問開發，如果不太方便，就要做嘗試：一般非必需的引數不會做容錯的判斷，必需的引數檢測的方面比較全面。

（3）文件不是最新的。介面的後續的工作中被修改或是優化過，我們按介面文件上的說明去呼叫，返回和預期的不一樣。通知開發更新文件，然後用最新的文件再去修改測試用例。

這個介面文件需要和介面開發人員做好約定，開發新介面時要把介面資訊寫清楚，如果更新原來的介面，要及時更新介面文件。同時在寫介面自動化測試用例的時候，要多和開發人員溝通，只有通過大家的一起努力，才能把工作做的越來越好。

本章是介面自動化測試教程的最後一章，我們在本章講述了影響介面自動化測試的最根本的介面文件的相關知識。雖然我們不能要求開發完全按我們的要求寫介面文件，可是我們可以給領導建議應該寫成什麼樣子的，這樣有利於我們的工作。通過本教程的學習，相信大家能動手編寫自己的介面自動化測試用例，並投入到正式的工作中。

「臨淵羡魚，不如退而結網」，一定要動手去做，在不斷的實踐中才能積累豐富的經驗。不然就算看再多的教程也只是停留在理論上，遇到了實際問題時還是無從下手。最後，祝大家學習愉快！！