前言
換工作后膊毁，還是接手了接口自動化的項目胀莹，比之前用的更加深入，同時也學習到了很多新的知識婚温。對此想記錄下描焰，自己的思考。
接口自動化要做什么?
簡而言之就是栅螟，對接口做一些測試荆秦，把接口當做黑盒進行輸出、輸出力图。當然接口內(nèi)部的邏輯處理也需要考慮到步绸。整體還是以功能測試為主。
接口自動化的用例設計
之前我使用的是HttpRunner框架搪哪，作者對用例結構有很清晰的定義靡努。具體可以參考：HttpRunner 的測試用例分層機制 (適用于 2.X)
我目前的項目，接口是對外提供的晓折，耦合性較高惑朦，并且安全性有比較高的需求，對此接口測試用例漓概，我分為幾個模塊漾月。
單接口正常
對接口第一步調(diào)試并且正常，這樣的接口就屬于單接口正常了胃珍，如果是一個模塊并且具有以下接口梁肿，登入——》查詢——》修改——》刪除蜓陌，這么一個系列組合就可以封裝為一條測試用例，如果有幾個這樣的模塊吩蔑，那么可以把這些模塊封裝為一整個測試用例集钮热，作為基礎的冒煙測試，這樣的冒煙烛芬，也可以算是一個小場景了隧期。
通用斷言
在很多大型系統(tǒng)中，因為有鑒權相關功能赘娄，很多接口都不會直接到達業(yè)務層仆潮，會在collect層中在封裝一個通用鑒權模塊來進行處理。
任何請求都會經(jīng)過它的邏輯處理遣臼，只有它通過了才會下流到業(yè)務層性置，因此我們的接口也需要驗證這個功能點，由于所有的接口都要處理這樣的邏輯揍堰，索性對此進行封裝鹏浅，通過循環(huán)讀取csv中的數(shù)據(jù)，根據(jù)附帶的參數(shù)不一樣个榕，做不同的預期結果斷言篡石。例如sign芥喇，sign_time,appid等等西采，若接口無此參數(shù)，會直接跳過業(yè)務層继控，返回對應錯誤碼械馆。
單接口異常
接口異常場景比較多，對此進行細化武通，主要驗證霹崎，輸入和輸出，考量參數(shù)的限制冶忱，邊界尾菇，等價，默認囚枪，特殊派诬，敏感，對此又可以在細分是數(shù)組链沼，還是字符串
場景用例
場景的根本是依賴于用例的原子性默赂，小場景就是小用例，應該單獨可以存在并且運行括勺，多個用例可以組成測試用例集缆八，互補干擾曲掰，可以運行。
場景用例會有較多依賴情況奈辰，一般如果自動化做的好栏妖，建議通過接口來創(chuàng)造需要的數(shù)據(jù)，如果需要數(shù)據(jù)量特別大奖恰，通過接口創(chuàng)建不友好并且繁瑣底哥，也可以通過數(shù)據(jù)庫批量生成。
目前的疑惑
接口自動化用例的管理房官，隨著項目接口的增多趾徽，相關用例也同步增多，這就會讓我想到翰守，規(guī)模龐大RF用例的歷史孵奶，那基本上維護不了了。
還有就是蜡峰，接口用例了袁，需要寫多細，單接口異常情況的覆蓋度需要達到多少湿颅，很多接口可能在設計之初就不完善载绿，對輸入沒有定義好，或者說油航，當前框架流行崭庸，Spring的很多的注解，可能也會對參數(shù)做很多限制谊囚。而接口測試人員怕享，看不到代碼，設計了很多用例镰踏，其實是無用功函筋。所有，異常的考慮面在什么點奠伪。
場景接口測試用例跌帐，怎么編寫，期望是手工業(yè)務人員來進行編寫绊率，問題谨敛，手工業(yè)務人員，對接口是否了解即舌，是否有時間來完成佣盒。編寫完成后的維護工作怎么展開。如果又接口人員編寫顽聂，那么業(yè)務熟悉度肥惭，可能不夠盯仪。
我的想法
建議從大局觀，考慮蜜葱，不再區(qū)分全景，手工測試和接口測試人員，組成一個整體牵囤。
手工人員提供業(yè)務場景爸黄，接口測試人員，提供對應的接口測試用例揭鳞，共同維護炕贵。
若接口測試用例，可以提高手工業(yè)務人員效率野崇，那么手工業(yè)務人員會有興趣學習對自己有用的東西称开。進而提升用例的維護性。
同時接口測試人員乓梨，學習到了業(yè)務鳖轰，并且等到認可，會更有沖勁扶镀。方便設計更加完善的用例蕴侣，對整體的覆蓋度會有較大的提升。
異常場景的細分臭觉，根據(jù)真實項目情況而定昆雀，時間短就覆蓋關鍵點。有足夠時間胧谈，可以再細化忆肾。異常的用例荸频，要保證菱肖，編寫后，盡量不需要改動旭从∥惹浚可以持續(xù)穩(wěn)定的跑。目前只關注輸入/輸出就可以了和悦。
