壹. 了解需求，什麽是系統的核心業務
二. 編寫測試用例：用例名稱，前置條件，測試數據，測試步驟，期望結果
三. 自動化代碼的初步構建：所有的元素定位、元素操作、測試用例都寫在壹個模塊中
問題：
1. 層次混亂，壹旦頁面元素調整，需要挨個尋找對應的測試模塊，測試類，測試用例函數，不便於後期維護
2. 不便於代碼的復用
四. 引入PO模式，進行分層設計：實現測試用例和頁面對象分離
好處：
1. 層次清晰，相互獨立，易維護
2. 頁面對象可以多次調用，提高了代碼的復用度
五. 引入單元測試框架unittest
六. 優化分層設計
將每個頁面公***的屬性和方法提取出來，封裝成壹個BasePage模塊下的BasePage類，後期各個頁面只需要繼承它，就可以獲得父類的所有屬性和方法，這樣不僅簡化了代碼，而且提高了復用度
七. 引入pytest：基於unittest，比unittest更"智能"
好處：
1. 可以通過打標記來運行特定的測試用例
2. 利用contest.py定義公***的fixture，多個測試類中都可以調用，不需要每個測試用例類都定義壹遍環境準備和環境清理，簡化了代碼
3. pytest可以按壹定規則自動發現測試用例，而unittest則需要向指定的測試套件中添加測試用例
4. 利用pytest-html庫，可以生成自帶的html報告和xml文件，而xml文件的好處是方便跟其它平臺的集成和展示，方便做二次開發
八. 註意點
1. 做自動化前，要有獨立的賬號，避免外界環境的幹擾
2. 頁面順序完全是由業務邏輯來決定，由測試用例來決定。因此在封裝頁面時不用考慮誰來調用它，不用考慮哪壹個頁面操作之後再來使用它(或者哪壹個功能操作之後再來使用它)，應該考慮的是無論前面做了什麽樣的操作，誰來用它，任何壹個步驟來調用它的時候，它都能正常的操作(這也是為什麽壹些頁面的元素需要滾動操作)
3. 在封裝功能時不要考慮在用例中是什麽意思，只需要考慮在本頁面是什麽功能(比如：標詳情頁面獲取余額功能的封裝，不需要把函數命名為get_user_left_money_before_invest，而是在只考慮它的功能的情況下命名為get_user_left_money)
4. 在選標的過程中，不要指定特定的標名，而是要隨機選擇，因為頁面上的標是會變的。因此測試數據的選取，用例的設計要遵循盡量不要依賴系統的原則，這樣也提高了代碼的穩定性
5. 投資操作的前置條件是：可用余額要大於投資金額，如何保證這個條件，有兩種方法：
1) 後臺充值足夠多的錢
2) 判斷當前用戶余額夠不夠，不夠就充值，可以調用查詢接口查詢用戶余額，調用充值接口進行充值——因為API操作是非常快的，這也提高了測試用例的效率
6. 保證用例的獨立性：每壹個測試用例都要重新打開瀏覽器