前言
至今為止也做了快一整年的接口自動化了，在融合線上項目中，學習到了很多。抽空記錄下這個項目得心路歷程。
做這個項目的緣由
早早就聽說過測試自動化的頂頂大名，上家公司準備采用RF這樣得關(guān)鍵字框架來做一些UI自動化，由于自身緣由，沒有參與太多，第一次聽聞自動化就是在哪里。自己內(nèi)心深處也特別想去看看到底測試自動化是什么樣子的。是不是就可以擺脫點點點了。感謝當前的公司給與了我一個這樣的機會。大boss傾向做出一個測試自動化，我直屬leader當然就是做咯，所以就招了我來完成這個項目。
就有了我之前的幾偏文章
之前的文章也可以是我心路歷程的階段性體現(xiàn)，從不懂，到學習。去挖掘，去對比，去執(zhí)行。去傳播。
隨著了解的越多，發(fā)現(xiàn)自己還有著更多的不懂。需要去學習和實踐。
接口的理解
這個是理解接口自動化的核心要素，需要知道什么是接口？接口是怎么來的？接口有什么作用？不同的接口有什么區(qū)別？接口的必須條件是什么？什么樣的接口可以進行自動化測試？
我嘗試從自身角度說說我的理解，如果說錯了或者不足可以和我交流下，我會修改的。
什么是接口？
其實在百度百科已經(jīng)說的很清楚了，我以軟件為維度來解釋，如果是JAVA語言，接口你們可能更多理解為一個類所具有的方法的特征集合，是一種邏輯上的抽象。這個是JAVA語言的定義。如果在一個項目中，前端同學需要你提供接口時，可不能這樣回哦。因為在廣義的定義中，前端同學要的接口是你controller層中定義的參數(shù)和協(xié)議。前端同學根據(jù)你提供的協(xié)議和參數(shù)來進行調(diào)用傳參數(shù)。這樣的‘接口’在其他編程語言中和路由是非常類似的。又有著不同，路由只有路徑?jīng)]有協(xié)議。這樣定義的‘接口’，從字面上來看確實更加貼合本意。恰好業(yè)界也認可，達成默認共識了。
接口是怎么樣來的？
很顯然接口是人為更加業(yè)務(wù)情況定義出來的，不同語言實現(xiàn)方法可能會不同，但是大同小異。我以JAVA為例，定義一個接口你需要確認這個接口采用什么樣的協(xié)議，是http還是socket。不同的協(xié)議調(diào)用的基本庫不同。假如是http協(xié)議，還需要確認請求方式是什么，是get還是post或者其他的方式。如果帶有參數(shù)，那么參數(shù)的定義是怎么樣的，數(shù)據(jù)持久層和數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計等等就都慢慢出來了。當這一切都定義好了，那么一個接口也就誕生了。
接口有什么用？
在之前的網(wǎng)頁技術(shù)當中，因為項目比較小完全可以自己內(nèi)部循環(huán)，不需要這樣的‘接口’出現(xiàn)，當后來隨著技術(shù)的發(fā)展，項目體機越來越臃腫，采用了更加合理的層次結(jié)構(gòu)，采用‘接口’來對業(yè)務(wù)邏輯進行解耦。包括當前較為流行的微服務(wù)也是做解耦的，通過接口的定義來實現(xiàn)。
不同接口有什么區(qū)別？
接口最大的不同點或者核心點就是在于它實現(xiàn)的協(xié)議，當前使用的有tcp/udp，后面衍生了http1.0，http1.1，http2.0，https，還有socket，soup，rpc等等，不同的協(xié)議都是針對不同業(yè)務(wù)的解決方案。
接口的必須條件是什么？
協(xié)議，請求方式，參數(shù)，這三者應(yīng)該說是一個接口的組成條件。
什么樣的接口可以進行自動化測試？
符合定義規(guī)范，例如http中的reastful API。邏輯清晰，有著良好的輸入/輸出文檔。
接口自動化測試的2條支路
支路一
當前很多公司做得接口測試是：根據(jù)接口文檔或接口服務(wù)對當個接口進行設(shè)計測試用例，有正向和異常，邊界值測試。
好處：對接口覆蓋比較全面。
缺點：沒有綜合考慮性價比，因為單個接口來說，前端和后端都會做很多校驗，從測試角度，我們確實需要是驗證這些校驗是否正確執(zhí)行，當時投入下去得成本，可能不能獲得類似得產(chǎn)出。并且因為完全沒有考慮或者說沒有條件去考慮到該接口的實現(xiàn)情景上下文的關(guān)聯(lián)關(guān)系,也就是說不能從 前端界面-->接口服務(wù)處理--->數(shù)據(jù)庫表字段 ,來綜合以一個場景化的思維來綜合測試接口，這樣就基本上很難發(fā)現(xiàn)問題。
支路二
走接口串聯(lián)的路子，按照實際業(yè)務(wù)需求來設(shè)計，準確來說是把手工執(zhí)行的用例轉(zhuǎn)換為調(diào)用接口來執(zhí)行，這樣就可以考慮情景上下文的關(guān)聯(lián)關(guān)系。使用接口來完成業(yè)務(wù)的邏輯測試。
好處：可以相當一部分代替人工回歸測試，執(zhí)行速度快，有一定的質(zhì)量保證，性價比高。
缺點：缺少單個接口的測試覆蓋度，可以會有一定的漏測。接口組合情況多種，測試用例的亂序組合調(diào)度需要進行解決。分層結(jié)構(gòu)，結(jié)果產(chǎn)出，問題定位都是需要面對的問題。
我的看法
在我實踐的項目中，我采用的是支路二，因為投入的成本有限，而且需要快速看到收益。最好好的辦法就是，制定自動化的原則，搭建好分層結(jié)構(gòu)，定義好產(chǎn)出。重復發(fā)揮手工測試人員的力量。優(yōu)先把冒煙測試的用例給轉(zhuǎn)換為自動化測試用例。感受到效果再進一步實施。
如果后期項目可以穩(wěn)定執(zhí)行下去可以充分在支路二的技術(shù)上加入支路一的測試方法，擴充測試覆蓋度，是非常不錯的。
工欲善其事必先利其器
咱們做軟件的，沒個利器來干活，估計效率也不高，IDE就不說了，個人喜好即可。關(guān)于接口自動化測試，那么需要根據(jù)你業(yè)務(wù)的自身情況和你團隊基礎(chǔ)來決定。工具選對了可以少走很多彎路的。基于大部分項目都應(yīng)該是http協(xié)議，那么市面上就有很多工具可以選擇了，整體可以分為JAVA系，Python系。
講講我在當前項目中，工具都使用了那些功能吧，供大家參考。
1、支持命令行CLI運行的方式。-----因為后續(xù)接入Jenkins需要。
2、整體框架能夠有分層結(jié)構(gòu)，方便調(diào)用。-------類似JAVA的分包，也可以調(diào)用。能夠?qū)τ美K更好的管理。
3、能夠有精確的測試報告輸出，日志記錄和輸出。------測試報告是最后的產(chǎn)出，也是定位問題的根本依據(jù)。
4、整體工具穩(wěn)定，可維護。-----正式上線的項目，第一考慮要素是穩(wěn)定可靠。所以工具最好是在持續(xù)維護的，有一定的成功案例和客戶群體。
5、工具可擴展，開源協(xié)議。------工具沒有完美，不同業(yè)務(wù)可以做少量的二次開發(fā)也是可以接受的。
6、可以提供hook之類的調(diào)用方式，響應(yīng)結(jié)果支持多種斷言。 -----實際業(yè)務(wù)中，請求和響應(yīng)有可能需要加密和解密，對斷言也有所不同。
基本上就是使用上訴功能了，在實際業(yè)務(wù)需求中，去嘗試，根據(jù)接口文檔或者抓包情況，來模擬請求，斷言結(jié)果，根據(jù)報告和日志定位問題，串聯(lián)接口組裝成測試用例即可。
感悟
關(guān)于接口自動化，算起來已經(jīng)在業(yè)界流行了很多年了。有著非常多的工具和方法來實施，但是真實在項目中的運行情況，在業(yè)界好像沒有太多消息?，F(xiàn)在突然又出現(xiàn)了一波web化的勢頭，更多的我認為應(yīng)該回歸本源，把基礎(chǔ)的接口自動化做好了，做大了，做完善了。再考慮web化的事情吧，沒有什么工具是完美的，QTP也涼涼了。只有跟著業(yè)務(wù)一起走，融合到業(yè)務(wù)中，才是核心。選擇適合自身實際情況的框架，落地實施，才是重點，行動起來，才能有所突破和改變。
