為什么又一篇自動(dòng)化測(cè)試的文章
如果搜索自動(dòng)化測(cè)試相關(guān)的文章，看到的集中在兩類：一是宏觀上的關(guān)于手工測(cè)試和自動(dòng)化測(cè)試的區(qū)別、自動(dòng)化測(cè)試的優(yōu)缺點(diǎn)、測(cè)試金字塔應(yīng)該的結(jié)構(gòu)（比如三角、倒三角、甜筒、梯形、洋蔥、地球儀模型等），等等。一是微觀上的關(guān)于測(cè)試工具的使用。對(duì)于讀者來講，在沒有一定的實(shí)踐基礎(chǔ)上，前者很容易陷入一種形而上的討論，讀時(shí)不明覺厲，掩卷不知從哪開始。后一種又很容易造成一種“自動(dòng)化測(cè)試=自動(dòng)化工具/自動(dòng)化執(zhí)行”的錯(cuò)覺，弄不好便會(huì)變成拿著錘子找釘子。
本篇文章的嘗試回答這樣的問題：如果QA沒有太多自動(dòng)化測(cè)試實(shí)踐，但又在測(cè)試效率上碰到瓶頸，冀望自動(dòng)化測(cè)試就能解決當(dāng)前困境時(shí)，應(yīng)該作出怎樣的一些思考？。（注：文章后半部分會(huì)涉及HTTP接口，希望讀者已經(jīng)了解HTTP協(xié)議的基本內(nèi)容）
從頭講起 - 測(cè)試的cycle time
測(cè)試的核心問題是：測(cè)什么（What），怎么測(cè)（How）。對(duì)QA來講，測(cè)試就變成要能夠想到、還要能夠測(cè)到（測(cè)試效率）。這兩個(gè)問題有時(shí)有本質(zhì)的困難，有些測(cè)試點(diǎn)就是再給出兩倍的時(shí)間也不一定能想到，同時(shí)有些測(cè)試能想到卻不一定能測(cè)到（比如全組合測(cè)試）。
在這種理解上，自動(dòng)化測(cè)試到底能幫助QA什么呢？要說清這個(gè)問題，還得先從基本的測(cè)試過程開始。一般一次完整的測(cè)試要經(jīng)歷以下步驟：
理解需求、測(cè)試分析、設(shè)計(jì)用例、準(zhǔn)備環(huán)境、準(zhǔn)備數(shù)據(jù)、執(zhí)行用例、判斷結(jié)果、（報(bào)Bug、重測(cè)）、Sign off
如果說測(cè)試是QA對(duì)質(zhì)量的反饋，并稱呼從“理解需求”到“Sign off”為一個(gè)完整的測(cè)試Cycle，那么可以說只有經(jīng)歷了一個(gè)完整Cycle的測(cè)試才更有意義。比如，設(shè)計(jì)很多用例而不執(zhí)行，團(tuán)隊(duì)并沒有從“設(shè)計(jì)用例”活動(dòng)中得到有效的質(zhì)量反饋（除了一些澄清）。同樣，有了Bug而不報(bào)告，也不能算有效的測(cè)試，因?yàn)檎鎸?shí)的質(zhì)量反饋并沒傳達(dá)到團(tuán)隊(duì)。
另外一方面，可以簡(jiǎn)單定義從“理解需求”到“Sign off”所經(jīng)歷的時(shí)間為測(cè)試Cycle Time，那么如果Cycle Time過長(zhǎng)，長(zhǎng)到團(tuán)隊(duì)得到第一次反饋時(shí)已經(jīng)是迭代Last Minute，這時(shí)也可以認(rèn)為測(cè)試效率很低。這也包括對(duì)Bug的重測(cè)過程。
自動(dòng)化測(cè)試的目標(biāo)應(yīng)該是測(cè)試Cycle Time的整體的縮短，加快測(cè)試反饋周期。
要理解這個(gè)，可以借助價(jià)值流圖的方式，給以上每個(gè)步驟記錄一個(gè)時(shí)間，我們能得到這樣一個(gè)結(jié)果：
假設(shè)單個(gè)階段活動(dòng)為5分鐘，且只有一個(gè)Bug并一次修復(fù)成功，則測(cè)試Cycle Time合計(jì)5*8 = 40分鐘。如上圖，QA要經(jīng)歷30分鐘（不含Bug時(shí)間）的測(cè)試活動(dòng)才能給團(tuán)隊(duì)第一次的測(cè)試結(jié)果，經(jīng)歷40分鐘的測(cè)試活動(dòng)才能將相關(guān)功能Sign off.
如果“自動(dòng)化測(cè)試=自動(dòng)化執(zhí)行”，哪怕把執(zhí)行時(shí)間縮短為秒級(jí)別，Cycle Time也只減少了5分鐘，節(jié)省5/40 = 12%的時(shí)間。
但是如果我們的自動(dòng)化節(jié)省了包括準(zhǔn)備環(huán)境、數(shù)據(jù)等的時(shí)間，比如用基于模型的方法自動(dòng)化了分析到準(zhǔn)備數(shù)據(jù)的全過程，使其整體時(shí)間縮短到5分鐘，則節(jié)省的時(shí)間則是20-5 = 15分鐘，節(jié)省15/40 = 37.5%的時(shí)間。
糟糕的自動(dòng)化是有了很快的執(zhí)行速度，卻給“喂”了無(wú)效甚至錯(cuò)誤的測(cè)試數(shù)據(jù)，這時(shí)的執(zhí)行快只是一種假象，無(wú)助于加快有效反饋的目的。還有一種自動(dòng)化測(cè)試是將手工測(cè)試用例翻譯成自動(dòng)化測(cè)試腳本，這通常只是片面追求執(zhí)行快而已，整體Cycle Time也許變得更長(zhǎng)，因?yàn)闀鴮懞途S護(hù)自動(dòng)化腳本也是要花時(shí)間的。
自動(dòng)化測(cè)試工具的出發(fā)點(diǎn)
當(dāng)我們執(zhí)行了數(shù)個(gè)測(cè)試用例，也就是經(jīng)歷了數(shù)個(gè)測(cè)試Cycle后，發(fā)現(xiàn)一些活動(dòng)可以抽象出來，如上圖所示，這也就是一大類工具產(chǎn)生的根源。也正因?yàn)槿绱耍蠖鄶?shù)工具都是為了某類特殊目的而產(chǎn)生，同時(shí)天生就有其局限性。據(jù)不完全統(tǒng)計(jì)，目前的測(cè)試工具數(shù)以百計(jì)，并且還在增加中。諸多工具中，很大部分都聚焦在用例執(zhí)行上。
測(cè)試工具作為基礎(chǔ)設(shè)施，輔助QA測(cè)試，但是在“測(cè)什么”這個(gè)問題上收效甚微，還得依靠QA自身的分析能力。QA需要明確自己的測(cè)試問題域，同時(shí)理解這些工具的設(shè)計(jì)出發(fā)點(diǎn)，合理地使用它們。從Cycle Time的描述可以看出，只著眼測(cè)試執(zhí)行的工具通常離Cycle Time整體縮短的目標(biāo)還有相當(dāng)大的距離。
所以當(dāng)你碰到瓶頸，以為是因?yàn)闆]有使用某個(gè)或某類自動(dòng)化工具時(shí)，請(qǐng)仔細(xì)想想你的測(cè)試問題域和已有的測(cè)試過程是否已經(jīng)優(yōu)化了。通常我們會(huì)發(fā)現(xiàn)，優(yōu)化現(xiàn)有的測(cè)試過程比單純?cè)黾右粋€(gè)測(cè)試工具的效果更突出。
注：考慮QA的日常，可以再細(xì)分一下，以便參考：
常規(guī)用例設(shè)計(jì)與執(zhí)行
探索用例設(shè)計(jì)與執(zhí)行
回歸用例設(shè)計(jì)與執(zhí)行
其它非功能性用例設(shè)計(jì)與執(zhí)行
以API自動(dòng)化測(cè)試為例
上面講的都還在概念層次，我們以API測(cè)試為例來具化一下這些概念，來看看測(cè)試、自動(dòng)化測(cè)試、測(cè)試工具的聯(lián)系，以及一個(gè)新測(cè)試工具的產(chǎn)生過程。
聚焦在API上，一方面很多系統(tǒng)的對(duì)外服務(wù)本身就以API為主。另一方面，隨著架構(gòu)的演進(jìn)，大多網(wǎng)站也采用了前后端分離的方式，也就是API對(duì)外可見，相當(dāng)于系統(tǒng)給用戶暴露了至少兩類訪問途徑。據(jù)說douban，facebook等網(wǎng)站的API直接訪問量是大于其Web訪問的。
API測(cè)不測(cè)？如果系統(tǒng)只提供API服務(wù)，答案是肯定的。但是如果系統(tǒng)是網(wǎng)站或者系統(tǒng)有前端界面，得到的答案卻有點(diǎn)“模糊”，一方面QA受本身技術(shù)的限制沒有意識(shí)到API的存在及其重要性，另一方面以前端界面為默認(rèn)或者承諾的交互方式為由而降低了它的優(yōu)先級(jí)。但是如果以用戶可能會(huì)通過什么樣的方式來影響系統(tǒng)的角度上講，只要API有訪問的可能，API測(cè)試覆蓋就不可或缺。
API測(cè)試場(chǎng)景 - 測(cè)試問題域
API作為專門測(cè)試，除非有專門工具的封裝，它沒有Web那樣直觀的界面，需要對(duì)相應(yīng)協(xié)議的理解。要想談API自動(dòng)化測(cè)試，就得先看看QA測(cè)試API時(shí)有哪些場(chǎng)景以及難點(diǎn)（先假設(shè)我們只討論功能和性能，不涉及安全、契約測(cè)試等）。
場(chǎng)景1：?jiǎn)蝹€(gè)API的單次執(zhí)行，只要會(huì)至少一種API調(diào)用方式即可，比如curl、Postman之于RESTful類API。（難點(diǎn)：無(wú)）
場(chǎng)景2：?jiǎn)蝹€(gè)API的多次執(zhí)行，這時(shí)需要對(duì)API的正常返回、異常返回以及API對(duì)多種數(shù)據(jù)組合進(jìn)行測(cè)試。（難點(diǎn)：大量數(shù)據(jù)的準(zhǔn)備和管理，測(cè)試執(zhí)行）
比如：對(duì)一個(gè)POST請(qǐng)求，Post body有6個(gè)字符串類型字段，如果一個(gè)字符串正向、負(fù)向數(shù)據(jù)合計(jì)為5，則全組合為5的6次方：15625
場(chǎng)景3：多個(gè)API的單次執(zhí)行，它們之間沒有依賴。（難點(diǎn)：管理每個(gè)API以及它們對(duì)應(yīng)的數(shù)據(jù)）
場(chǎng)景4：多個(gè)API的單次執(zhí)行，它們之間有執(zhí)行順序依賴，沒有數(shù)據(jù)依賴。（難點(diǎn)：管理API間的執(zhí)行順序）
場(chǎng)景5：多個(gè)API的單次執(zhí)行，它們之間有執(zhí)行順序依賴，也有數(shù)據(jù)依賴。（難點(diǎn)：管理API間的執(zhí)行順序，數(shù)據(jù)依賴）
場(chǎng)景6：多個(gè)API的多次執(zhí)行，它們之間有執(zhí)行順序依賴，也有數(shù)據(jù)依賴。（難點(diǎn)：管理API間的執(zhí)行順序，數(shù)據(jù)依賴，大量數(shù)據(jù)的準(zhǔn)備和管理，測(cè)試執(zhí)行）
通常，一個(gè)系統(tǒng)開發(fā)到中期時(shí)（比如4個(gè)迭代），系統(tǒng)可能會(huì)累計(jì)超過30個(gè)API，它們會(huì)包含GET、POST，數(shù)據(jù)依賴。同時(shí)QA需要時(shí)時(shí)對(duì)系統(tǒng)回歸，以及通過API對(duì)系統(tǒng)數(shù)據(jù)準(zhǔn)備等，并持續(xù)這些活動(dòng)到開發(fā)結(jié)束。大一點(diǎn)的系統(tǒng)超過100個(gè)API也不少見。
場(chǎng)景7：API的數(shù)據(jù)來源于第三方系統(tǒng)（難點(diǎn)：數(shù)據(jù)源不可控）
場(chǎng)景7的項(xiàng)目上下文依賴太多，暫時(shí)不予討論。其它6個(gè)場(chǎng)景卻可以很明確地識(shí)別其難點(diǎn)。從量級(jí)上講，假設(shè)系統(tǒng)有50個(gè)API，平均每個(gè)API需要準(zhǔn)備和執(zhí)行正向、負(fù)向數(shù)據(jù)組合為50，則我們有50*50 = 2500個(gè)用例。管理這個(gè)量級(jí)的數(shù)據(jù)和執(zhí)行并不是一件容易的事。
API自動(dòng)化測(cè)試的方向
從上面的分析可以看出，2500個(gè)測(cè)試用例的執(zhí)行和管理是一個(gè)很大的挑戰(zhàn)（國(guó)內(nèi)項(xiàng)目通常只有一個(gè)QA，而API測(cè)試只是QA在項(xiàng)目中眾多的測(cè)試活動(dòng)中的一種）。這就是QA面對(duì)的問題的特殊性，因?yàn)殚_發(fā)通常不會(huì)面對(duì)這種規(guī)模的用例管理與執(zhí)行。這時(shí)必然要通過某種途徑縮短Cycle Time，使完成每次測(cè)試周期的代價(jià)足夠小，我們要從分析到執(zhí)行到報(bào)告等各個(gè)環(huán)節(jié)上下功夫。
首先，API測(cè)試有天然的Data-Driven的特點(diǎn)，一條數(shù)據(jù)就是一個(gè)用例，并可以直接執(zhí)行（嗯，沒有中間環(huán)節(jié)賺點(diǎn)擊）。
同時(shí)，準(zhǔn)備這些數(shù)據(jù)已經(jīng)有很多方法論及其工具的支持，比如組合測(cè)試，等。
在CI/CD成為標(biāo)配的今天，測(cè)試環(huán)境一般不成為問題，除非有大量的第三方依賴。
但執(zhí)行效率有時(shí)卻成為關(guān)鍵，如果平均一個(gè)API執(zhí)行時(shí)間為1秒，串行執(zhí)行2500個(gè)用例則需要2500秒，約42分鐘。如果并行執(zhí)行，則需要考慮場(chǎng)景、優(yōu)先級(jí)及依賴。
考慮到對(duì)整個(gè)產(chǎn)品的所有API進(jìn)行管理和執(zhí)行，碰到的難點(diǎn)就包括但不限于：管理單個(gè)API的測(cè)試數(shù)據(jù)以及各類數(shù)據(jù)變種、執(zhí)行和報(bào)告，多個(gè)API的數(shù)據(jù)、執(zhí)行和報(bào)告，API的依賴，按場(chǎng)景執(zhí)行，按優(yōu)先級(jí)執(zhí)行，并行執(zhí)行，統(tǒng)計(jì)結(jié)果、性能數(shù)據(jù)。
通過測(cè)試流程改進(jìn)并不能解決上述的所有問題，這時(shí)引入自動(dòng)化就成為必然。市面上API測(cè)試工具很多，這些工具在協(xié)議層做到了盡善盡美，同時(shí)也提供比較方便的界面。但是面對(duì)QA碰到的上述特殊性要求卻總顯得力有不逮。以幾種工具或方式為例：
Postman：用戶界面友好，易上手，但API數(shù)量和測(cè)試數(shù)據(jù)變多后，管理就很不方便
SoapUI：老牌API測(cè)試工具，支持Groovy script對(duì)Test Case的定義和管理，對(duì)QA有代碼要求，與工具強(qiáng)綁定
Programing（比如Java Junit + httpclient，Python pytest，等）：對(duì)QA的代碼要求高，實(shí)施周期長(zhǎng)
我們還有什么選擇
既然已有的方案和工具不能解決問題，而QA碰到的問題又那么實(shí)實(shí)在在，也就只有嘗試自己梳理方案甚至寫新的工具了。這里有兩個(gè)方向：
一：只解決當(dāng)前項(xiàng)目的問題，方案與項(xiàng)目上下文強(qiáng)相關(guān)。好處是沒有多余工作，缺點(diǎn)是方案可移植性差。
二：抽象上面的問題，得到通用方案或者工具。好處是多個(gè)項(xiàng)目可重用，但是需要大量的基礎(chǔ)性工作，針對(duì)特定項(xiàng)目還要在通用方案或工具上輔以針對(duì)性的手段。
仔細(xì)梳理了上述問題域，根據(jù)方向二，經(jīng)過一段時(shí)間的努力，工具Go4Api已經(jīng)初見雛形：
— Go4Api定義了一種精簡(jiǎn)的Json格式，自我表達(dá)，它包含一個(gè)用例、用例間關(guān)系和HTTP Request/Response/Assertion等全部信息，同時(shí)本身還可以參數(shù)化，由另外的數(shù)據(jù)文件驅(qū)動(dòng)。
— 借助Go語(yǔ)言并發(fā)內(nèi)置的語(yǔ)言特性，Go4Api的調(diào)度機(jī)制能處理成千上萬(wàn)的用例以及管理它們的優(yōu)先級(jí)、先后依賴、數(shù)據(jù)依賴、并發(fā)執(zhí)行。
— 面對(duì)API測(cè)試?yán)锒喾N數(shù)據(jù)組合問題，Go4Api內(nèi)置了Mutation Test和Fuzz Test。其中Mutation Test功能能對(duì)現(xiàn)有的數(shù)據(jù)進(jìn)行多種Mutation（即正、反向變異）并執(zhí)行；Fuzz Test能根據(jù)API及其Fields的定義，通過規(guī)則生成數(shù)據(jù)，并實(shí)現(xiàn)了Go語(yǔ)言版的Pairwise算法，對(duì)用例數(shù)進(jìn)行有效降低并執(zhí)行。
— Go4Api還可以對(duì)HAR、Swagger API的格式文件進(jìn)行轉(zhuǎn)化，使之成為Go4Api能識(shí)別并處理Json格式。
更多詳情請(qǐng)見Github地址：https://github.com/zpsean/go4api
wiki: https://github.com/zpsean/go4api/wiki
go4api能做什么，不能做什么
Go4Api解決了之前所列場(chǎng)景1~場(chǎng)景6所識(shí)別出來的所有問題了嗎？還不徹底。比如以下兩點(diǎn)沒有完全支持：
— 如果一個(gè)API的數(shù)據(jù)來源于多個(gè)API的執(zhí)行結(jié)果，這種復(fù)雜的數(shù)據(jù)依賴部分支持。
— 一個(gè)POST API創(chuàng)建了新的數(shù)據(jù)，可以通過go4api Scenario功能為它加一個(gè)包含DELETE API的Child Case達(dá)到 tear down的目的，但是如果系統(tǒng)還沒有DELETE API呢？傳統(tǒng)的方法是SQL Delete等方式，Go4Api目前部分支持sql形式的teardown。
另外，Go4Api有圖形操作界面嗎？目前沒有看到有界面的必要。但是Go4Api提供了友好的可視化測(cè)試報(bào)告。
總結(jié)
測(cè)試是一個(gè)系統(tǒng)活動(dòng)，是否自動(dòng)化測(cè)試以及怎樣自動(dòng)化測(cè)試需要全面考慮測(cè)試的問題域本身。
自動(dòng)化執(zhí)行不等于自動(dòng)化測(cè)試，縮短測(cè)試Cycle Time，加快測(cè)試反饋周期應(yīng)該是考慮自動(dòng)化測(cè)試方向的重要因素。在有些場(chǎng)景下，自動(dòng)化測(cè)試數(shù)據(jù)準(zhǔn)備可能比自動(dòng)化執(zhí)行帶來更多好處。
測(cè)試工具不是天生的、也不是萬(wàn)能的，它通常是針對(duì)某類測(cè)試問題域的解決方案。如果使用不當(dāng)，誤把工具當(dāng)測(cè)試問題，只會(huì)練就屠龍術(shù)而已，無(wú)助于解決測(cè)試問題本身。
注：作為驗(yàn)證，Go4Api已經(jīng)在作者參與的項(xiàng)目實(shí)際使用。后續(xù)會(huì)有文章介紹Go4Api具體的應(yīng)用場(chǎng)景和實(shí)際使用經(jīng)驗(yàn)，敬請(qǐng)期待。
另外，為啥預(yù)覽顯示很好的小圖片發(fā)布后變那么大，width調(diào)整不生效。-_-!!
