? ? 互聯(lián)網(wǎng)測試工作，無非兩大塊，質(zhì)量和效率，說起效率呢，往往很多人就會(huì)想到一個(gè)詞----自動(dòng)化。測試自動(dòng)化在網(wǎng)上一搜，無數(shù)相關(guān)文章會(huì)告訴你接口自動(dòng)化啊，UI自動(dòng)化啊，XX自動(dòng)化啊，筆者甚至見過測試要自動(dòng)化一切啊。。。每當(dāng)看到這些，筆者就知道，寫文章的人都是沒有真正思考過人，人云亦云，毫無主見，自動(dòng)化真那么厲害軟件測試這個(gè)工種早就淘汰了。

? ? 說下我對(duì)自動(dòng)化的理解，自動(dòng)化是一種概念，而不是僅僅是方案，它是解決測試效率的一種思路。那怎么才能借助這種思路解決問題呢，而不是爭論在使什么自動(dòng)化框架好啊，什么好積累啊，什么門檻低啊。。。。

? ? 其實(shí)有了自動(dòng)化思路還是空談，必須要結(jié)合業(yè)務(wù)場景，團(tuán)隊(duì)人員能力等諸多方面綜合考慮，下面筆者將在我司實(shí)踐自動(dòng)化的思路分享給大家：

????我司用戶產(chǎn)品做自動(dòng)化思路有三個(gè)大維度，包括線下測試，上線過程，線上測試。

? ? 先說說線下測試，我們把業(yè)務(wù)場景和團(tuán)隊(duì)分成三個(gè)階段，初創(chuàng)階段，穩(wěn)定階段，突破階段。這三個(gè)階段基本能夠覆蓋一款互聯(lián)網(wǎng)產(chǎn)品的三個(gè)主要階段了，我們一一說來。

【初創(chuàng)階段】

特點(diǎn)：（產(chǎn)品）方向不穩(wěn)定，功能和ui變化大。（人員）技術(shù)能力弱，全靠測試case補(bǔ)。

解決方案：這個(gè)階段啥自動(dòng)化方案都白扯，你根本沒時(shí)間做技術(shù)工作，就算有也白做，后續(xù)肯定要大改，投入產(chǎn)出比太虧。那怎么辦，我們除了加人沒有更好的方案了嗎？非也，對(duì)于土豪公司來講，加人當(dāng)然不在乎，但是一般初創(chuàng)公司很難在沒看清產(chǎn)品發(fā)展的情況下貿(mào)然擴(kuò)大測試團(tuán)隊(duì)。筆者是這樣做的，讓所有測試工程師接不同項(xiàng)目的測試工作，也就是讓每個(gè)人都做全能選手，然后大家一起分析，哪些項(xiàng)目或業(yè)務(wù)重復(fù)性大，然后固話這塊業(yè)務(wù)的測試case及人力安排，固話的好處是這些case除了測試也可以讓產(chǎn)品和研發(fā)一起測試，這樣團(tuán)隊(duì)每個(gè)人都是qa，而qa就可以專門去做變化較快的業(yè)務(wù)。你看看這塊我們用到任何一種自動(dòng)化框架和理論，但是效率是不是也提升了呢，再次強(qiáng)調(diào)，自動(dòng)化是思路，不是方法。

【穩(wěn)定階段】

特點(diǎn)：產(chǎn)品大方向及功能已經(jīng)明確，雖然迭代頻繁，但是不會(huì)大改。

解決方案：將已經(jīng)穩(wěn)定的業(yè)務(wù)自動(dòng)化掉，具體選用什么框架，根據(jù)各自技術(shù)棧來決定，筆者寫過php，java的（順便提一句，自動(dòng)化框架總有一天要自己寫，后續(xù)我會(huì)說到）。將穩(wěn)定的業(yè)務(wù)先把接口自動(dòng)化搞定，在提測階段和上線階段使用，保證研發(fā)提測質(zhì)量和上線質(zhì)量，qa只關(guān)注新功能就好。當(dāng)穩(wěn)定階段業(yè)務(wù)發(fā)展一段時(shí)間后，你就會(huì)發(fā)現(xiàn)新功能/接口的測試量也越來越多，使用自動(dòng)化框架添加case已經(jīng)非常耗時(shí)了，而且case的編寫完全取決于工程師自己的能力（良心），因?yàn)橥粋€(gè)case不同人寫的力度粗細(xì)就會(huì)差距很大，有的時(shí)候大到case能不能起到作用。所以這時(shí)候就需要自動(dòng)化case的標(biāo)準(zhǔn)化規(guī)范，那這個(gè)規(guī)范怎么寫呢？我們寫個(gè)wiki放上去，跟工程師說，都按這個(gè)寫，寫錯(cuò)打屁股？這無論從執(zhí)行層面和管理方面都不可行，這時(shí)候筆者主導(dǎo)開發(fā)了一個(gè)自動(dòng)化case編寫平臺(tái)，接口的入?yún)?，接口名填上去就好，針?duì)返回值的校驗(yàn)把主流的case檢查方法（也就是assert這些）做成選擇項(xiàng)，添加case的工程師只要選擇對(duì)于某一個(gè)自動(dòng)的檢查方法就好，方法比較多，比如：value的類型判斷，是int，還是string，還是其他，key和value是否存在，value值是否大于/小于/等于等的判斷。這個(gè)平臺(tái)開發(fā)后把工程師添加case的時(shí)間基本可以忽略不計(jì)了。

【突破階段】

? ? 一般能到此階段的公司，無論公司業(yè)務(wù)還是團(tuán)隊(duì)，基本已經(jīng)成型了。筆者看到走到這步的創(chuàng)業(yè)公司并不多。這個(gè)階段測試的質(zhì)量保證怎么做，自動(dòng)化用什么樣的思路做呢？這時(shí)候需要的是整體性的思維考慮了，這塊筆者展開說就比較多了，我先貼張圖，說下現(xiàn)在筆者所在公司做的事情，后續(xù)詳細(xì)再講。

簡單說下這幾個(gè)平臺(tái)作用：

解耦平臺(tái)：這個(gè)是筆者公司針對(duì)測試環(huán)境經(jīng)常出問題做的，主要解決下游測試環(huán)境有問題的情況，也能在上游進(jìn)行順暢的測試。

自動(dòng)化添加平臺(tái)：上邊有介紹，目的是減少自動(dòng)化添加的成本。

接口diff平臺(tái)：線上第一臺(tái)和線上服務(wù)的接口diff，目的是在保證數(shù)據(jù)相同的情況下，新代碼和線上老代碼相同接口返回?cái)?shù)據(jù)是否一致，驗(yàn)證即將上線的代碼不會(huì)影響老業(yè)務(wù)接口。

上線確認(rèn)平臺(tái)：這是從管理角度出發(fā)做的，讓研發(fā)和qa對(duì)上線有變更的文件意義確認(rèn)，確保研發(fā)和測試?yán)斫庖恢?，解決研發(fā)和測試因?yàn)闇贤ú蝗娴膯栴}。

線上服務(wù)接口監(jiān)控：線上第一時(shí)間發(fā)現(xiàn)接口問題的利器

問題定位平臺(tái)：當(dāng)監(jiān)控發(fā)現(xiàn)一個(gè)接口報(bào)警之后，qa往往會(huì)跟研發(fā)說，xxx有問題了，研發(fā)還要一頓查，是機(jī)器問題，還是服務(wù)問題，還是線上代碼bug。問題定位平臺(tái)能夠模擬研發(fā)查問題的思路，在報(bào)警的同時(shí)直接告訴研發(fā)問題出在哪，這樣很快就能修復(fù)上線了。