????終于又序更上了，原諒最近作者幾天事情不斷。

按照我們之前的計劃，需要迅速開啟很重要的核心多用例接口。

????首先，我們要確定，這個功能的大體設計。

就放在在我們的頁面 用例庫 中：

所以也就是我們很久之前就創建好的P_cases.html:

然后來想一下大體設計：

首先是大用例列表，每個大用例 包含很多接口， 可以單獨運行。

這個大用例列表?肯定有其 增刪改查功能，在數據庫一張大用例表中，有id name? 備注?等字段

然后就是數不清的小用例，這里每個小用例 就是一個接口，但是并不能直接用我們接口庫的數據表，因為不同的用例我們需要進行各種特殊設置接口，比如接口a在 用例A中 請求體中的參數是aaa，在用例B中，請求體參數是bbb。

所以，我們需要再創建一個獨立的表 來存放所有小用例，然后每個小用例的基本結構其實和接口的結構差不多，有url ,method,hedaer,body等等，而且還要有 所屬的大用例id， 這樣的效果是：我們打開一個大用例A,id=1

?然后后臺數據直接去 小用例表中 查找所有小用例的所屬大用例id == 1的，然后返回前端展示。

? ?????當然小用例表還要有一些其他的字段，比如執行順序，重試次數，斷言設置(包括正則，檢索存在，具體路徑)，提取返回值設置(正則，具體路徑)，是否跳過等等 我們之后隨著更新會不斷的有新字段添加的可能。

????后臺數據層的設想到此，然后就是頁面的設想了。

上面說了，一進入時映入眼簾的應該是 大用例表。看個概念圖：

可以看到每個大用例 有設置/運行/報告/復制/備注/刪除? 上面還有個新增按鈕。

然后當我們點擊設置按鈕時，屏幕要顯示它所包含的所有小用例，并且按照順序排列好。

如圖，屏幕左側滑出了這個小用例列表，上面有三個小用例。?

上面有添加新的小用例的按鈕，每個小用例左邊都有上下調整順序的按鈕。

當然這時我們點擊任意一個小用例，應該要看到這個小用例的具體設置。

如上圖，屏幕右側滑出來了這個?小用例的具體設置頁面。

可以看到，其實具體的設置和接口調試的那一套基本類似。不同的地方

主要有倆點：

1是?這里可以自己設置新接口，也可以直接套用接口庫中已存好的接口。

然后自己再稍微改改參數即可使用。

還有個主要不同的在于 提取返回值成?公共變量 和?斷言：

提取和斷言這倆個地方比較難，大家可能會有很多疑問到時候。不過別灰心，這么難的地方，挺過去，你就是王者。

當然，大家看到這里面復雜的 說明。其實這也是沒辦法的，畢竟這里我們相當于創造了幾套規則規范，必須按照這樣的規范去寫，我們后臺才能準確的翻譯和實現。當然想出這些規則然后用代碼實現翻譯?和 各種異常處理，非常困難，大家可能理解和學習起來困難，當初創造這些的時候則更困難。好在我已經給大家趟平了坑。

????可能后面我們看到那個mock功能，那個暫時我們這大章不講，因為優先級并不高。

然后最后是我們的測試報告結果：

當然 我對自己以前的審美設計一直比較難受，大家可以按照更好的設計實現。?報告中 需要對所有接口的返回值，斷言結果，提取結果 進行判斷和顯示。全部小用例都正確這條大用例才算正確。當然這些結果當我們運行完畢放在哪里呢？一開始我也想過緩存，但是后來覺得不行，因為這個用例的結果和時間是要做為日后的參考依據的，隨時點開看，不能每次要看都要重新運行。所以肯定要在數據庫中存放好每條小用例的運行結果，那么我們前面說到的小用例的數據層字段中，也要增加這幾個結果吧～

????好了，設計到此為止。下一章我們開始正式碼代碼。

可能有的同學會說 為什么展示的這么好看完善，直播做出來的那么丑呢？

其實這是因為完全體平臺中對于ui的打磨消耗了很大一部分比例的精力。而我們同學現在的當務之急是實現功能，過早的優化就是萬惡之源嘛～等全部功能差不多了。各位在公司的okr寫什么？還不是要寫寫優化么～

????還有很多同學說前段的js 什么的太復雜了，太難了。

難么？難就對了！簡單是留給點點點的。

累么？累就對了！舒服是留給領導的。

我們要悄悄的學習，然后驚艷所有同事。心中要有信念，沒有困難的工作，只有勇敢的測開。靠別人是公主～靠你幾哇是日本人～靠北啦是臺灣人～靠自己才是光榮的測開。

加油吧，測開，只要你足夠加油，測試一定會走向更美好的未來。

雄起吧，測開，只要測開雄起，明日太陽將會不復存在，而東方閃耀著的，是測開們努力的模樣，早安，測開們～

????最近有不少新同學關注了這個用愛發電的公眾號，歡迎大家給個好評～

再給互推一下小程序：

過節換頭像，藝術字，藏頭詩。