第一階段：API自動化
      之前的想法是：通過API創(chuàng)建數(shù)據(jù)，訪問數(shù)據(jù)，進行數(shù)據(jù)操作，存儲數(shù)據(jù)庫，通過模擬前端的操作來想象API的訪問流程。
      然后，驗證數(shù)據(jù)庫是否存儲正確。后來發(fā)現(xiàn)該想法流程就是錯誤的。
      問題：
1、模擬前端的操作需要對每個前端操作后調(diào)用的API非常熟悉，這已經(jīng)超過了測試的范圍，屬于開發(fā)的范疇。
2、每個API的集成測試應(yīng)該是獨立的，有順序的對API的測試使得API之間存在相互依賴的關(guān)系。然而每個API的正確性并不能保證。
3、API本身是具有很強的獨立性，不應(yīng)該通過前端模擬操作來對其進行相對的驗證，操作邏輯應(yīng)該由前端負責(zé)。
      總結(jié)：
1、使得API具有健壯性，對正常的數(shù)據(jù)傳輸和異常的數(shù)據(jù)傳輸，服務(wù)器端都能正確的響應(yīng)和返回正確的響應(yīng)碼。
2、對于API的集成，務(wù)必使得每個API都獨立驗證，不能具有相互依賴性。
3、API的正確性為前端邏輯的自動化驗證提供了穩(wěn)定的基礎(chǔ)。
4、工具可使用：unittest，pytest(推薦)
第二階段：自動創(chuàng)建測試數(shù)據(jù)
       前端的一些UI驗證，需要一些組合數(shù)據(jù)，每次更新環(huán)境，版本迭代，自動化創(chuàng)建需要的數(shù)據(jù)。
       此時需要依據(jù)測試用例(UI顯示部分)來保證每種情況，包括邊界，越界情況的顯示正常。此些數(shù)據(jù)在每次新環(huán)境都需要驗證的情況下，手動創(chuàng)建太過于浪費時間，通過Python讀取excel預(yù)先設(shè)計好的，通過API或者直接寫入數(shù)據(jù)庫的方式自動化創(chuàng)建批量的數(shù)據(jù)。寫入的方式通過具體的業(yè)務(wù)來選擇。
第三階段：前端操作自動化
       第二階段和第三階段的順序不太重要，也可以先執(zhí)行第三階段。
       這里的前端操作自動化，通俗的講是對前端控件響應(yīng)的一些自動化驗證，屬于基礎(chǔ)的前端測試。如文本的輸入，按鈕點擊響應(yīng)，表單提交后的正常顯示等。
       依據(jù)就是需求文檔，覆蓋需求文檔的一些基本的點就可以。不需要太多的復(fù)雜的流程和操作。
       工具使用appium。
第四階段：用戶實操自動化
       用戶實操依據(jù)是使用該軟件的過程中，用戶操作的真實場景，為最后的收尾自動化測試。
       如用戶可能在使用的過程中，停留在該頁面10分鐘，然后鎖屏，然后解鎖，查看該APP是否還在生存中。
       如用戶可能在使用的過程中，是程序退入后臺。這里的具體操作需要了解不同的平臺對程序生命周期的定義階段不同。
前端自動化和接口自動化
       之前一直在思考前端自動化和接口自動化分別側(cè)重點是什么。
       前端自動化側(cè)重點在于組建的響應(yīng)，數(shù)據(jù)顯示(包括長度，小數(shù)正確取位等)，后端側(cè)重在于數(shù)據(jù)處理的正確性驗證。
       之前主要通過Appium檢驗前端的各個按鈕響應(yīng)是否都正確，某個元素是否顯示出來了，忽略了一個動作操作完后對其他界面數(shù)據(jù)顯示的影響檢測。其實前端和后端的自動化側(cè)重點不同，但是對于數(shù)據(jù)的檢測可以是雙重檢測。這樣測試完后的數(shù)據(jù)更有保障。
關(guān)于數(shù)據(jù)生成(準(zhǔn)備)
       數(shù)據(jù)生成(準(zhǔn)備)與測試放在分開的模塊中，混到一起，容易中斷測試代碼。
       先數(shù)據(jù)生成測試需要的數(shù)據(jù)然后再運行測試代碼。

本文來自（）

---

【年末回饋最后一波，全場六折起，豪禮升級，還送公開課入場券，趕緊搶！】

活動時間：12月1日-12月31日

標(biāo)簽：軟件測試技術(shù)軟件測試