自動化測試腳本編寫小結

文章目錄

• • 1. 注釋
  • 2. 代碼抽取、封裝
  • 3. 業務相關
  • 4. 結果校驗
  • 5. 調試
  • 6. 送出代碼
  • 7. 及時總結
  • 8. 向同僚學習

1. 注釋

• 業務代碼必須要寫好注釋。變量的命名也需要考慮規範，盡量和業務名相關，這樣也算是一種注釋，讓人看得清楚。
• 純邏輯代碼注明該塊代碼的作用是什麼，入參、傳回值的注釋。一頭(入參)、一尾(傳回值)、一大概(功能)，讓他人拿到就能用，不用想怎麼實作的，應用為先。

2. 代碼抽取、封裝

• 使用兩次及以上的代碼塊，即可考慮封裝成函數，抽取複用的代碼，提出入參為變量。
• 涉及到對某個字段或者特定資料等進行多種操作時，考慮寫成類的形式。
• 某業務的操作涉及的資料和邏輯功能較多且複雜，考慮将業務操作和資料分離。

3. 業務相關

• 寫代碼前一定要考慮好業務需求，評估需要實作的業務；理清業務之間的關系，業務中也分輕重，并不是所有的業務都是需要立即去實作的。
• 使用思維導圖梳理業務，将業務走一遍，再思考每一步怎麼用代碼實作。
• 磨刀不誤砍柴工，明确需求、思路更重要，代碼隻是實作的手段。

4. 結果校驗

• 寫測試腳本，校驗是必不可少的一環，有的字段配置下發後，是否成功未知，測試未知，需要通過重新擷取來驗證，常常使用assert來判斷。
• 結果資料的展示，使用 f 文法來展示資料（比%s、.foramt()更清晰），在pytest+Allure 中使用allure.attach(資料，‘描述資訊’)

5. 調試

• 遇到bug，重複運作兩遍不如debug一遍，調試最能發現問題所在。
• 調試技巧需要不斷地提升，提高調試的能力。

6. 送出代碼

• 送出代碼前先自己檢查一遍，将調試的代碼删除，比如使用main函數調試的代碼，将沒用到的變量、導包、無用的注釋删除， 再使用 Ctrl+Alt+L 将代碼格式化後符合PEP8規範。
• 每次送出的資訊，都應該簡明扼要地描述目前送出的代碼。
• 每天記得更新項目代碼，避免在開發新的腳本過程中落後master太多，也便于送出代碼時合入、減少沖突。

7. 及時總結

• 每寫一項業務、一個腳本，及時記錄自己在其中遇到的問題，有哪些教訓可以總結哪些東西。
• 有的業務隻有在用自動化覆寫時才去了解，一旦了解後就記錄該塊的業務知識、注意點，業務這種東西一旦學習了，以後就隻要花很少時間就能拿起來。

8. 向同僚學習

• 同僚寫的代碼總有值得學習的地方，學他人之長，補己之短。
• 對于别人寫的不好的地方，思考是否有優化的空間。
• 剛開始可以學習模仿别人寫代碼，慢慢地試着優化代碼。