大家好~我是
米洛！
我正在從0到1打造一個開源的介面測試平臺, 也在編寫一套與之對應的完整教程，希望大家多多支援。
歡迎關注我的公眾號測試開發坑貨，獲取最新文章教程!
回顧
上一節我們粗略介紹了下怎麼設計前端頁面。時隔一日，博主已經把程式碼碼好了。
不得不說，前端程式碼還是非常非常難寫的，感覺同樣是crud，卻比後端複雜許多。這一節我們繼續補充這塊內容。
恭喜EDG獲取S11冠軍，EDG牛皮！蹭個熱度~
細節
細節部分大家可以參看具體的程式碼邏輯，我這邊稍微介紹下頁面的調整。
資料構造器（前置條件）
這塊採用了Antd pro Components，也就是專業級的Card元件。看起來確實比我自己寫的好上100個檔次:
前後對比:
- 改造前
配色也不知道怎麼配，我一直覺得前端很難，css是門學問。
- 改造後
來看看ProCard的程式碼:
- 安裝ProCard
npm install --save @ant-design/pro-card
- 使用
可以看到api比較簡單，avatar就是卡片的圖示，title是標題，description是描述。很習慣的antd風格。
用例列表部分
我們都知道測試計劃就是為了組裝測試用例的，所以我們這邊給出了一組資料，可以通過專案獲取到該專案下的測試用例樹。
選中以後，下方會出現一個可拖拽的case列表，如果對於順序有嚴格要求的，可以拖動列表，改變case的執行順序。
與之對應的，需要通過專案獲取到case資料:
也可以通過目錄來選擇case。
後端改動如下:
因為我們是有通過專案獲取case目錄的方法的，現在缺的就是是否要繼續獲取目錄下的case。
所以定義了一個case_node的引數（引數是一個方法，獲取子節點的方法）。
如果有該方法，則呼叫之獲取對應的節點。
由於select資料比較奇怪，我們的資料庫存的case_list又是id，所以我們想知道case名字並不是很容易。
於是這裡帶出專案樹的同事，帶出了case_id => case_name的對映關係: case_map。
這樣做肯定會有問題，特別是資料量多的情況下。但一個project下的case有這麼大規模的時候，也可以重構了。
最後，編寫該介面:
前端通知部分
通知部分很簡單，也是常規表單，給它們加上圖示會更友好:
通知具體的邏輯還沒有做，這涉及到人員的手機號，郵箱等。肯定是需要一個使用者管理頁面，使用者也需要更新資料的頁面。
APScheduler的坑
不得不說，這個庫還真的是有一些問題。雖然看起來是比較美好，但現實給人當頭一棒。
-
踩坑
當編輯測試計劃的時候，使用scheduler.modify_job，就算你改變了trigger，也不會使cron表示式更新。
最後來張穩定執行測試計劃的圖:
最新的程式碼，我已經部署了。
歡迎大家提各種建議和意見。