第一篇請參考：https://www.cnblogs.com/VVsky/p/9361139.html

當我完成jmx腳本編寫之後，將jmx嵌入ScriptManagement平臺，使之可以單模塊運行及批量運行之後。

主心骨部分算是完成了。

接下來的難點就是，怎麽使環境在執行之前一直是幹凈的。

幹凈的環境

接口設計考量的時候，我有說過，對響應值過於復雜的系統，是需要進行分段設計的。

本次的產品系統響應值比較復雜。所以我考慮了三種情況：

1.每個case執行之前準備數據，這個對於表結構等要求比較深入-----廢棄

2.直接備份整個庫：

　　→經過驗證，我發現單獨備份還比較快，就算慢也沒有關系，使用次數只有在初始化的時候使用一次。

　　→BUT！還原的時候，我計算了時間，超過1H.效率太慢了

3.備份對應的表：

　　→通過篩選，去除了一半的表，這時根據數據庫的特性，我們(我申請了兩個人力來幫忙寫代碼)使用了copy來進行表備份。

　　→BUT！其中有個表的數據量已經超過億級了，這導致整個的備份還原時間還是超過了30MIN+。

4.換方案備份，針對特性數據庫

　　→根據每個數據庫的特性使用系統自帶的方式進行備份，比如：mysql的備份和postgresql的備份肯定有不一樣的方案特性。

　　→最後，我們將時間縮短到了10分鐘以內，主要的時間耗損在壓縮與解壓縮。這個方案是目前最優的了。

根據以上：我們寫了幾個shell腳本文件，嵌入的本平臺內，使用python進行遠程操作執行。

所以：我們有了以下的界面操作

如上圖：

1.可以對服務器進行變更

2.可以對數據庫進行備份

3.可以進行還原操作

由於，是為本公司產品開發了，所以目前沒有增加數據庫選項，所寫的shell腳本也僅針對一種數據庫。

除以上用戶進行手動恢復環境，我還設置了一個開關，用於執行腳本後，平臺自帶進行環境恢復。

後續：

我們將進行版本管理開發

我們將對jmeter的腳本編輯遷移到此平臺

接口自動化之協同辦公自動化平臺二（ScriptManagement）