關(guān)于Web端-UI自動化測試
在手工測試階段，針對項目輸出了測試用例，如果這些測試用例需要在版本迭代的過程中，需要進行回歸測試，通過手工重復(fù)地執(zhí)行測試用例，將會耗費大量的人力。
為此應(yīng)運而生就有了自動化測試，通過使用自動化工具，將按照測試用例進行點點操作，校驗的工作，交給代碼程序來執(zhí)行，測試工作，就變得省心省力了。
- 重點：測試用例是自動化測試腳本的依據(jù)，一切不基于測試用例而寫的自動化腳本都是耍流氓。
關(guān)于UI自動化測試
UI 自動化的本質(zhì)：
- 定位元素
- 操作元素
- 模擬頁面動作
- 斷言結(jié)果
- 生成報告
基于以上5個本質(zhì)，自動化測試的整體流程是這樣的，這里百度登陸功能的測試用例為例：
- 對于這條測試用例，需要找到它的定位元素：用戶名輸入框，密碼輸入框，登陸按鈕
- 操作元素：對于這3個定位元素的操作有2種，分別是“輸入”與“點擊”
- 模擬頁面動作，也就是測試用例的步驟：
- 輸入用戶名
- 輸入密碼
- 點擊登陸按鈕
4. 判斷結(jié)果：將用例中的預(yù)期結(jié)果與實際結(jié)果進行比對，如果一致，代表成功，否則代表失敗。對于這條測試用例，登陸成功的標志是，頁面右上角出現(xiàn)了用戶的頭像與用戶名，那么，可以通過獲取網(wǎng)頁中用戶名的文本信息，與登錄賬戶的用戶名對比，一致的話，代表這條用例通過。
根據(jù)執(zhí)行結(jié)果，自動生成報告，常用的第三方模塊：HtmlTestRunner，Allure2 等
適合UI自動化測試的場景
當然，不是所有的測試場景都適合用自動化測試來實現(xiàn)。
對此，可以參考以下的標準輔助判斷：
- 項目的需求不會頻繁變動
- 頁面的 UI 已經(jīng)進入穩(wěn)定階段
- 項目周期足夠長
- 大量回歸的測試任務(wù)
其中，有一些項目是明顯不適合使用 UI 自動化測試的，例如視頻播放器（暴風影音，騰訊視頻，愛奇藝等），音樂播放器（例如網(wǎng)易云音樂，QQ 音樂等）等交動性強，并發(fā)依賴強的軟件。
原因是，這一類軟件，判斷視頻內(nèi)容對不對，判斷音樂聲音與歌詞對不對，難度極大。
另外，延伸一個話題：關(guān)于自動化測試的覆蓋率，面試會問到的一個點。
國內(nèi)大多數(shù)互聯(lián)網(wǎng)公司的項目迭代周期比較短，因此自動化覆蓋率一般都不高。
具體還是要根據(jù)項目迭代周期進行描述，參考標準是：
- 迭代周期是半年或者一年以上的項目，每次需求變動很少，自動化測試的覆蓋率一般是60%-70%，主要是覆蓋之前的舊功能以及核心場景
- 迭代周期為一個月的項目， 覆蓋率大概是25-30%，主要是覆蓋 P0（極重要）級別的絕大多數(shù)用例，與 P1（重要）級別中的部分用例
- 1~2周一個迭代的項目，覆蓋率大概是10%，主要是覆蓋 P0（極重要）級別，可能會對用戶造成嚴重影響的核心場景
其次，UI 自動化測試的時間切入點主要有2個：
- 冒煙測試階段
- 回歸測試階段
UI 自動化測試設(shè)計原則
- 一個測試用例完成一個功能點測試（常用）：一個手工用例對應(yīng)一個自動化測試用例
- 一個腳本是一個完整的場景
- 腳本之間獨立，不能有依賴（腳本間相互隔離）：例如與登陸狀態(tài)相關(guān)的用例：個人中心、訂單詳情、下單購物等，如果腳本之間不獨立，相互依賴，在登陸的測試腳本失敗的情況下，會導(dǎo)致個人中心、訂單詳情、下單購物的測試腳本全軍覆滅，后續(xù)修復(fù)與維護成本高
4. 設(shè)置合適的檢查點：通過斷言判斷用例的成功與否
5. 設(shè)計良好的框架：Python 常用的測試框架有 unittest 與 pytest，利用框架，及對共用的測試模塊進行封裝，減少自動化測試腳本維護的工作量
總結(jié)
