第一階段：API自動化
之前的想法是：通過API建立資料，訪問資料，進行資料操作，儲存資料庫，通過模擬前端的操作來想象API的訪問流程。
然後，驗證資料庫是否儲存正確。後來發現該想法流程是錯誤的。
問題：
1、模擬前端的操作需要對每個前端操作後呼叫的API非常熟悉，這已經超過了測試的範圍，屬於開發的範疇。
2、每個API的整合測試應該是獨立的，有順序的對API的測試使得API之間存在相互依賴的關係。然而每個API的正確性並不能保證。
3、API本身是具有很強的獨立性，不應該通過前端模擬操作來對其進行相對的驗證，操作邏輯應該由前端負責。
總結：
1、使得API具有健壯性，對正常的資料傳輸和異常的資料傳輸，伺服器端都能正確的響應和返回正確的響應碼。
2、對於API的整合，務必使得每個API都獨立驗證，不能具有相互依賴性。
3、API的正確性為前端邏輯的自動化驗證提供了穩定的基礎。
4、工具可使用：unittest，pytest(推薦)
第二階段：自動建立測試資料
前端的一些UI驗證，需要一些組合資料，每次更新環境，版本迭代，自動化建立需要的資料。
此時需要依據測試用例(UI顯示部分)來保證每種情況，包括邊界，越界情況的顯示正常。此些資料在每次新環境都需要驗證的情況下，手動建立太過於浪費時間，通過Python讀取excel預先設計好的，通過API或者直接寫入資料庫的方式自動化建立批量的資料。寫入的方式通過具體的業務來選擇。
第三階段：前端操作自動化
第二階段和第三階段的順序不太重要，也可以先執行第三階段。
這裡的前端操作自動化，通俗的講是對前端控制元件響應的一些自動化驗證，屬於基礎的前端測試。如文字的輸入，按鈕點選響應，表單提交後的正常顯示等。
依據是需求文件，覆蓋需求文件的一些基本的點可以。不需要太多的複雜的流程和操作。
工具使用appium。
第四階段：使用者實操自動化
使用者實操依據是使用該軟體的過程中，使用者操作的真實場景，為後的收尾自動化測試。
如使用者可能在使用的過程中，停留在該頁面10分鐘，然後鎖屏，然後解鎖，檢視該APP是否還在生存中。
如使用者可能在使用的過程中，是程式退入後臺。這裡的具體操作需要了解不同的平臺對程式生命週期的定義階段不同。
前端自動化和介面自動化
之前一直在思考前端自動化和介面自動化分別側重點是什麼。
前端自動化側重點在於組建的響應，資料顯示(包括長度，小數正確取位等)，後端側重在於資料處理的正確性驗證。
之前主要通過Appium檢驗前端的各個按鈕響應是否都正確，某個元素是否顯示出來了，忽略了一個動作操作完後對其他介面資料顯示的影響檢測。效能測試工具其實前端和後端的自動化側重點不同，但是對於資料的檢測可以是雙重檢測。這樣測試完後的資料更有保障。
關於資料生成(準備)
資料生成(準備)與測試放在分開的模組中，混到一起，容易中斷測試程式碼。
先資料生成測試需要的資料然後再執行測試程式碼。
本作品採用《CC 協議》，轉載必須註明作者和本文連結