自動(dòng)化測(cè)試不是個(gè)簡(jiǎn)單的任務(wù)，而是個(gè)項(xiàng)目。作為項(xiàng)目就必須有他的流程與規(guī)范。
一、項(xiàng)目啟動(dòng)階段
1、可行性分析
評(píng)估項(xiàng)目當(dāng)前是否合適啟動(dòng)自動(dòng)化測(cè)試？如果項(xiàng)目不適合，需要找出不適合原因與上級(jí)領(lǐng)導(dǎo)溝通。
自動(dòng)化的啟動(dòng)時(shí)間的切入點(diǎn)很關(guān)鍵，切入點(diǎn)時(shí)間可以分散到模塊，先穩(wěn)定的模塊先開展自動(dòng)化。
2、抽樣分析
通過(guò)可行性分析后需要進(jìn)行抽樣分析，也就是寫幾個(gè)自動(dòng)化測(cè)試腳本，通過(guò)實(shí)際案列再次看看自動(dòng)化測(cè)試工作是否能順利開展，也可以在此過(guò)程中發(fā)現(xiàn)部分技術(shù)上的疑難或是否存在致命的問(wèn)題，在這過(guò)程中也可以發(fā)現(xiàn)有那些需要開發(fā)、測(cè)試、運(yùn)維、產(chǎn)品配合或改進(jìn)的地方。
有經(jīng)驗(yàn)的工程師通過(guò)抽樣分析，能對(duì)自動(dòng)化測(cè)試工作開展有個(gè)大體的輪廓，為后面的工作開展打下基礎(chǔ)。
抽樣分析方式推薦采用自動(dòng)化冒煙測(cè)試抽樣，也就是將實(shí)現(xiàn)冒煙測(cè)試用例作為抽樣的樣本，將系統(tǒng)的手工冒煙測(cè)試轉(zhuǎn)換為自動(dòng)化測(cè)試用例，自動(dòng)化測(cè)試的用例數(shù)量需控制在5個(gè)左右，這樣既有成果又貼合實(shí)際。
注意：抽樣分析時(shí)不要搭建完整的測(cè)試框架，可以只線性的實(shí)現(xiàn)自動(dòng)化測(cè)試用例，它的主要工作還是抽樣分析。
二、自動(dòng)化測(cè)試準(zhǔn)備階段
1、自動(dòng)化測(cè)試需求篩選與評(píng)審
測(cè)試需求篩選主要時(shí)明確自動(dòng)化測(cè)試的的目標(biāo)，整理出需要實(shí)現(xiàn)自動(dòng)化測(cè)試的業(yè)務(wù)需求，以及自動(dòng)化測(cè)試深度。需求分析完成后要對(duì)其內(nèi)容進(jìn)行評(píng)審，只有項(xiàng)目組評(píng)審?fù)ㄟ^(guò)后才能有效。
UI自動(dòng)化測(cè)試不可能做到100%覆蓋，所以我們主要從實(shí)際的業(yè)務(wù)場(chǎng)景方面考慮，首先需要貼合用戶使用的正向場(chǎng)景，然后再篩選出重要的逆向場(chǎng)景。
API自動(dòng)化測(cè)試，需要對(duì)整個(gè)系統(tǒng)的API進(jìn)行整理，根據(jù)API的重要程度和使用率來(lái)劃分等級(jí)，確定API自動(dòng)化測(cè)試的深度。對(duì)API自動(dòng)化測(cè)試的覆蓋率要求都會(huì)在70%以上，也有公司要求達(dá)到100%覆蓋率。
API 變更頻率比 UI 低，而且 API 測(cè)試腳本的執(zhí)行效率高，出錯(cuò)率低，可測(cè)試的覆蓋率也比 UI 高，它的維護(hù)成本也較低。所以現(xiàn)在很多公司將 API 作為自動(dòng)化測(cè)試的重點(diǎn)。
2. 制定自動(dòng)化測(cè)試計(jì)劃
由 PM 和自動(dòng)化測(cè)試負(fù)責(zé)人編寫計(jì)劃，與手工測(cè)試的測(cè)試計(jì)劃過(guò)程一致，在測(cè)試計(jì)劃中要明確做什么，什么時(shí)候做。自動(dòng)化測(cè)試計(jì)劃包含自動(dòng)測(cè)試的組織架構(gòu)、工作任務(wù)分配、工作量估計(jì)、人力物力資源的分配、進(jìn)度的安排、風(fēng)險(xiǎn)的估計(jì)和規(guī)避、各任務(wù)通過(guò)準(zhǔn)則等。
3、制定自動(dòng)化測(cè)試方案
測(cè)試方案編寫需要由有經(jīng)驗(yàn)的工程師編寫，測(cè)試方案要明確自動(dòng)化該怎么做。方案寫得越詳細(xì)，后面遇到的坑就越少。主要從以下方面考慮：
自動(dòng)化的目標(biāo)？
測(cè)試的范圍？
工具的設(shè)計(jì)和選擇？
開發(fā)語(yǔ)言的選擇？
自動(dòng)化測(cè)試框架的設(shè)計(jì)？
持續(xù)集成的規(guī)劃？
UI自動(dòng)化的場(chǎng)景與規(guī)劃？
API自動(dòng)化場(chǎng)景與規(guī)劃？
用例的設(shè)計(jì)原則？
測(cè)試腳本編寫的原則？
測(cè)試腳本的管理？
測(cè)試數(shù)據(jù)的管理？
自動(dòng)化測(cè)試環(huán)境的規(guī)劃？
腳本的執(zhí)行策略？
4、搭建自動(dòng)化測(cè)試框架
自動(dòng)化測(cè)試框架是由基礎(chǔ)模塊、用例管理模塊、報(bào)告統(tǒng)計(jì)模塊等組成的工具集合；它用于組織、管理和執(zhí)行自動(dòng)化測(cè)試用例，在測(cè)試完成后統(tǒng)計(jì)測(cè)試結(jié)果生成HTML測(cè)試報(bào)告。
自動(dòng)化測(cè)試框架需要保證測(cè)試腳本的分布執(zhí)行，用例的模塊化，測(cè)試數(shù)據(jù)的管理，清楚的日志分析與錯(cuò)誤截圖，通俗易懂的測(cè)試報(bào)告，基本的公共對(duì)象庫(kù)，基礎(chǔ)的操作方法封裝，可實(shí)現(xiàn)環(huán)境的配置，還要各種異常處理和場(chǎng)景恢復(fù)等。
在設(shè)計(jì)測(cè)試框架的時(shí)，要盡可能的將這些模塊功能有機(jī)的結(jié)合起來(lái)，要能將腳本有效的組織和連貫應(yīng)用，提高測(cè)試腳本的可維護(hù)性和可讀性。測(cè)試框架還要做到高內(nèi)聚低耦合。高內(nèi)聚，每個(gè)模塊盡可能獨(dú)立完成自己的功能，不依賴于模塊外部的代碼；低耦合，模塊與模塊之間接口的盡量簡(jiǎn)單。
對(duì)于中小型企業(yè)，不必自己編寫一套自動(dòng)化測(cè)試框架，現(xiàn)在開源的自動(dòng)化測(cè)試框架有很多如：Python + unittest+ selenium/Appium/requests(推薦)，Robot framework(推薦)，Serenity，Phoenix Framework，Tellurium，Gauge 等等。
記?。簺](méi)有萬(wàn)能的測(cè)試框架，適合自己項(xiàng)目的，能提高工作效率的就是好框架
5、測(cè)試用例標(biāo)準(zhǔn)化與制定編碼規(guī)范
測(cè)試用例標(biāo)準(zhǔn)化對(duì)提高代碼的重用性和復(fù)用率直接相關(guān)，它對(duì)測(cè)試腳本的可靠性和可維護(hù)性也有很大影響。
用例標(biāo)準(zhǔn)化需要有統(tǒng)一的設(shè)計(jì)模式，統(tǒng)一的編碼規(guī)范與約束，共有的模塊化函數(shù)與類庫(kù)，統(tǒng)一的命名規(guī)則。
三、自動(dòng)化測(cè)試腳本開發(fā)
1、測(cè)試用例設(shè)計(jì)
自動(dòng)化測(cè)試的用例設(shè)計(jì)重中之重，不要在沒(méi)設(shè)計(jì)自動(dòng)化測(cè)試用例之前就進(jìn)行編碼，自動(dòng)化測(cè)試用例他是對(duì)自動(dòng)化測(cè)試場(chǎng)景的整理與綜合。
很多自動(dòng)化測(cè)試腳本開發(fā)直接使用手工測(cè)試用例，然而手工用例之間的相關(guān)性高，到最后造成測(cè)試腳本繁重，用例維護(hù)難，遇到問(wèn)題難定位。
自動(dòng)化用例設(shè)計(jì)要保證測(cè)試對(duì)象的明確性；每個(gè)用例都是一個(gè)完整的場(chǎng)景；每個(gè)功能點(diǎn)一個(gè)測(cè)試用例；盡量降低用例的復(fù)雜度，每個(gè)腳本獨(dú)立，腳本之間不要產(chǎn)生關(guān)聯(lián)性。在寫用例過(guò)程中需要將共性功能或操作抽象出來(lái)模塊化，提高測(cè)試腳本的可維護(hù)性與代碼的重用性。
不管是UI自動(dòng)化還是API自動(dòng)化，編碼前必須設(shè)計(jì)測(cè)試用例。
具體內(nèi)容太多，后面開單獨(dú)章節(jié)講自動(dòng)化測(cè)試用例的設(shè)計(jì)。
2、公共腳本開發(fā)
在自動(dòng)化用例設(shè)計(jì)時(shí)已經(jīng)將共性的功能或操作抽象出來(lái)，在腳本編寫前需要將這些操作模塊化放入公共模塊。
3、測(cè)試腳本開發(fā)
根據(jù)自動(dòng)化測(cè)試用例實(shí)現(xiàn)測(cè)試腳本的開發(fā)，在開發(fā)測(cè)試腳本時(shí)要將腳本的可靠性和維護(hù)性放在首位，每寫一行都需要考慮它的可靠性和可維護(hù)性，代碼編寫必須嚴(yán)謹(jǐn)、規(guī)范。
腳本的執(zhí)行必須智能、高效、穩(wěn)定、可靠。
腳本開發(fā)完成后要在不同的環(huán)境運(yùn)行3次以上，確認(rèn)腳本沒(méi)有問(wèn)題才能提交代碼庫(kù)。提交代碼庫(kù)的代碼后，需要進(jìn)行代碼評(píng)審并在自動(dòng)化測(cè)試平臺(tái)運(yùn)行通過(guò)，然后才能合并到主分支。
四、自動(dòng)化測(cè)試的執(zhí)行與維護(hù)
1、自動(dòng)化測(cè)試執(zhí)行
自動(dòng)化測(cè)試的執(zhí)行策略有三種：定時(shí)執(zhí)行、自動(dòng)觸發(fā)、手工觸發(fā)
定時(shí)執(zhí)行，多用于監(jiān)控代碼版本的質(zhì)量。如，每天早晚二次固定時(shí)間執(zhí)行精選的中高級(jí)用例，實(shí)時(shí)監(jiān)控版本質(zhì)量。
自動(dòng)觸發(fā)，多用于冒煙測(cè)試。如，精選出冒煙用例(執(zhí)行時(shí)間控制在10分鐘內(nèi))，在開發(fā)提交代碼合并到主分支時(shí)自動(dòng)觸發(fā)冒煙測(cè)試，有問(wèn)題郵件通知對(duì)應(yīng)人員。
手工觸發(fā)，多用回歸測(cè)試。如，一周或一個(gè)sprint為周期觸發(fā)兩次左右的全量執(zhí)行，要結(jié)合實(shí)際情況手動(dòng)觸發(fā)。
2、自動(dòng)化測(cè)試結(jié)果分析
自動(dòng)化測(cè)試結(jié)果分析主要靠測(cè)試報(bào)告，測(cè)試報(bào)告要求通俗易懂，不能過(guò)于復(fù)雜。
每個(gè)sprint結(jié)束后需對(duì)自動(dòng)化測(cè)試結(jié)果進(jìn)行深入分析，以此來(lái)調(diào)整自動(dòng)化測(cè)試方案和優(yōu)化自動(dòng)化測(cè)試腳本。
3、 自動(dòng)化測(cè)試用例和腳本的維護(hù)
系統(tǒng)發(fā)生變更時(shí)需要及時(shí)更新自動(dòng)化測(cè)試用例和修改測(cè)試腳本。
測(cè)試用例和測(cè)試腳本的維護(hù)是個(gè)長(zhǎng)期過(guò)程，用例與需求掛鉤，測(cè)試腳本與用例掛鉤，必須先更新測(cè)試用例，然后才能修改測(cè)試腳本。用例和腳本的每次更新需留下維護(hù)的記錄，以便 review 和 問(wèn)題查找。
4、自動(dòng)化測(cè)試腳本的持續(xù)優(yōu)化
測(cè)試腳本需要每個(gè)大版本檢查一次，對(duì)腳本進(jìn)行優(yōu)化。測(cè)試腳本不是寫好了，需求沒(méi)有變更，運(yùn)行無(wú)報(bào)錯(cuò)就放在哪里。
每過(guò)段時(shí)間檢查腳本代碼，當(dāng)發(fā)現(xiàn)測(cè)試的方法可優(yōu)化的地方，就需要對(duì)代碼進(jìn)行修改。只有持續(xù)對(duì)測(cè)試腳本進(jìn)行優(yōu)化，才能讓腳本更智能、更高效、更穩(wěn)定、更可靠。
最后：
歡迎關(guān)注公眾號(hào)：程序員一凡，領(lǐng)取一份300頁(yè)pdf文檔的Python自動(dòng)化測(cè)試工程師核心知識(shí)點(diǎn)總結(jié)！
這些資料的內(nèi)容都是面試時(shí)面試官必問(wèn)的知識(shí)點(diǎn)，篇章包括了很多知識(shí)點(diǎn)，其中包括了有基礎(chǔ)知識(shí)、Linux必備、Shell、互聯(lián)網(wǎng)程序原理、Mysql數(shù)據(jù)庫(kù)、抓包工具專題、接口測(cè)試工具、測(cè)試進(jìn)階-Python編程、Web自動(dòng)化測(cè)試、APP自動(dòng)化測(cè)試、接口自動(dòng)化測(cè)試、測(cè)試高級(jí)持續(xù)集成、測(cè)試架構(gòu)開發(fā)測(cè)試框架、性能測(cè)試、安全測(cè)試等。
