這是《落葉》文集里第 288?片落葉，希望你能喜歡，不為別的，只為這份堅持。
【背景】
這是一個好思考，好提問的同學(xué)，在學(xué)習(xí)《顛覆你的 Python 接口自動化測試》課程的過程中提出的一個疑惑。
【你問】
接口自動化測試需不需要覆蓋業(yè)務(wù)邏輯校驗？
【我答】
不管是在這門課程的設(shè)計上，還是我們的實際工作中，“接口測試”和“接口自動化測試”都需要剝離開去看待，前者是測試類別或者說測試工作，而后者是輔助前者的一種技術(shù)手段，切記，不要混在一起去看待。
就接口測試本身來說，只有當參數(shù)完整性驗證 + 接口返回碼驗證 + 業(yè)務(wù)邏輯正確性驗證都做完了，才能說這個接口的測試完成了，沒問題了。（注：這里暫不涉及接口的性能和安全性檢驗）
而接口自動化測試，簡單點說，就是通過某種商業(yè)的、開源的、自研的工具替代手工接口測試的部分工作。
為什么要說是部分工作呢？因為我們要清楚地認識到很重要的兩點：
第一、目前所有的自動化其實都是半自動化，不管是接口自動化、web?自動化，case 都是人工設(shè)計的，腳本也都是人工編寫的，只有部分執(zhí)行的工作才是機器做的，是這樣的吧？
第二、既然是替代部分人工操作的工具，那我們就不得不去考慮它的開發(fā)成本和維護成本了，也就是常說的，做這個東西，性價比高不高？而且，后者往往會容易被忽略掉，以為工具或腳本寫出來之后就一勞永逸了；
綜合上述兩點的考慮，我對接口自動化測試框架的產(chǎn)品需求有幾個要求：
第一優(yōu)先級：減少腳本開發(fā)中不必要的人工投入。
舉個例子：一個接口所包含的參數(shù)類型基本都是已知的、固定的，每類參數(shù)的入?yún)⒅?，基本都由一組入?yún)⒅禈?gòu)成，那我就要這個框架實現(xiàn)，我人工對于一個接口只要寫一條用例，為每個參數(shù)選擇好入?yún)⒅档念愋蜁r，會自動生成所有的接口測試腳本，而不用人工復(fù)制、粘貼、再修改參數(shù)的入?yún)⒅?，假如一個參數(shù)的入?yún)⒅涤?個，那就要重復(fù)7次，多累啊，而且完全沒有價值，還容易犯錯。
第二優(yōu)先級：執(zhí)行結(jié)果的發(fā)送和查看。
當我啟動了接口自動化的腳本之后，我不可能一直等著的，或者說我如果用于某種環(huán)境的定時巡檢時，我也不需要每次執(zhí)行結(jié)果都要查看，只有當執(zhí)行結(jié)果有錯誤時，才需要郵件將執(zhí)行結(jié)果發(fā)送給我，附上 Summary 和元數(shù)據(jù)報表即可。
第三優(yōu)先級，才可能是對于業(yè)務(wù)邏輯的正確性判斷，因為它可能需要檢查很多東西，而且有些東西，可能還需要從數(shù)據(jù)庫里取值來做比對，還有不同客戶端之間的等待、依賴關(guān)系等等，所以最后我才會考慮去做這一部分功能，為什呢，就是因為性價比最低。
接口自動化測試工具，在以下幾個方面相對比較實用：
第一、現(xiàn)網(wǎng)環(huán)境的巡檢，巡檢其實就是通過接口請求返回的 code，判斷接口服務(wù)器是否 work well，如果返回異常，就報警，發(fā)郵件給運維或開發(fā)人員；
第二、集成開發(fā)階段，就是當服務(wù)端接口開發(fā)完成時，可以用參數(shù)完整性校驗來檢驗接口是否按照接口文檔完成的，只有通過后，客戶端開發(fā)才開始聯(lián)調(diào)，這樣效率會高不少；
所以，好的接口自動化測試框架，除了讓 QA 使用起來，門檻低，人工干預(yù)少，重復(fù)性工作減少，還要是 web service、定時 Job 和分布式執(zhí)行腳本的，因為便于開發(fā)、運維人員使用，他們也不需要在自己本機安裝什么環(huán)境。
如果上述的框架開始運行，趨于穩(wěn)定的時候，再去考慮業(yè)務(wù)邏輯校驗功能都不遲，也就是多花點時間，設(shè)計一套升級維護成本小且準確率高的的方案而已。
《測試路上你問我答》里的?Q&A 80，如果是你要的，甚好！如果不是，你問，我答！
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
