第二章，平臺開發規劃

    從寫了第一章 測試平臺開發簡介，到如今開始寫第二章的內容，差很少有三個月了。中間遇上過春節，而後春節回來以後一邊要衝刺第一季度的績效，一邊忙着其餘的事情，幾乎沒有閒的時間。如今抽空繼續咱們的系列教程，不過提早說明，咱們的相關文檔不會介紹實現細節代碼，而是從更高的層次來進行分析，介紹。具體的代碼實現是比較初級的內容，若是你不能實現，仍是先去作自動化測試，不要入手平臺開發，結合自身狀況有計劃地來提高本身。

2.1 如何產生出平臺需求

       任何一個測試平臺，說小了就是完成一系列功能的綜合系統，說大了就是一個產品，和你一般在網上看到的如百度，騰訊等網站相似，是爲大衆服務的。而咱們可能客戶羣體會小一些，是普通的測試人員，或許只是大家部門的測試人員，而其與大型的平臺從原則上是一致的，麻雀雖小，五臟俱全嘛!

       一個好的測試平臺，是須要根據測試人員在平時的測試過程當中，遇到取繁瑣的問題，或是不太容易操做的地方，可是能借助工具來解決，爲了聚合各類資源，達到簡化操做，流程化工做等目的來產生出來的。不能爲了開發平臺而開發平臺，就算你開發的平臺功能再強大，不能解決實際問題，或是使用起來要求比較高，操做複雜的話，也是沒有任何意義的。

   藝術來源於生活而高於生活；平臺需求來源於測試工做，而簡於測試工做。

2.2 平臺需求規劃

       在咱們搞清楚了需求的來源後，就須要對需求進行全面的規劃。由於咱們要開發的是一個平臺，一個生態系統，不是解決特定問題的代碼集合；因此在考慮問題的時候，就須要有更高的視角和眼界。下面咱們從一個需求入後，介紹一下如何分析需求，以及如何產生出平臺。

 一，測試需求

目前不少產品都在轉向以app爲主，這就要求後端的服務或是接口質量比較可靠，即便出現了問題，也能及時發現。而測試採起的辦法是，編寫接口自動化測試，進行監控迴歸測試。可是不管以什麼語言編寫接口自動化，都有技術門檻，而不會技術的同窗沒有辦法參與進來，參與的同窗比較少，維護起來比較麻煩。如何下降技術門檻，提升可維護性，人員的傳承和培訓等問題比較明顯。

二，問題分析

       針對測試人員有上面這個需求，咱們測試開發的同窗就要分析問題，而後產生出解決具體問題的方法，進而產生出平臺需求。而這個需求的主要問題以下：

（1）技術門檻，不能使全部的同窗都參與進來。而若是隻有那麼一兩個同窗參與開發接口自動化測試的話，週期比較長，維護成本也比較高。

（2）運行成果不直觀。無論使用任何語言作接口自動化測試，最好的效果就是測試用例執行完成後，產生測試報告。而沒有對測試報告進行管理和統計的工做。

（3）測試用例管理不便。在執行測試用例的時候，通常是經過測試用例集來進行管理測試用例的，不能靈活地組合須要的測試用例。

（4）監控的時候須要藉助於jenkins, 或是服務器的定時任務，都不方便管理。

三，規劃需求

既然分析出上面的問題後，咱們就能夠詳細規劃需求了，也就是咱們要怎麼解決上面的這些問題。主要方法以下：

（1）下降使用成本，經過技術手段將編寫接口自動化測試進行可視化，不須要寫任何代碼，只須要填寫測試數據，便可生成接口自動化測試用例。

（2）管理測試用例，測試用例包含測試對象，測試數據，預期結果等，要進行合理的管理，以便減小維護成本。

（3）管理測試用例集，方面咱們自由組合測試用例，以適合不一樣的測試須要。

（4）測試用例集的運行方法控制，拋開第三方工具Jenkins，來進行合理的管理。

（5）統計測試報告，清晰的展現每次運行的結果，並能進行必要的統計功能。

（6）錯誤記錄功能，一旦測試用例出錯，須要記錄錯誤發現的現場環境，方便進行錯誤排查。

因此具體化成爲平臺開發的功能後，就應該是下面這樣的功能：

（1）接口文檔管理功能：管理接口信息，包括增，刪，改，查等。

（2）用例管理功能：新建，展現，查詢，刪除，運行測試用例。

（3）測試用例集管理：新增，修改，刪除，查找，運行測試用例集。

（4）任務管理：管理定時任務，或者其餘任務觸發機制。

(5)測試報告管理功能：展現，查找測試報告，對測試報告進行統計和分析。

（6）日誌管理功能：記錄錯誤日誌，對日誌進行過濾及分析。

（7）用戶管理功用：以便對測試用例，測試計劃，任務，報告和日誌的相關操做進行權限控制。

2.3 其餘更加細緻的規劃

經過測試人員的具體困難，分析產生困難的緣由或是問題，而後再根據問題提高出具體的需求。這是很是重要的一步，也是由問題到平臺的關鍵。可是有了具體的需求後，尚未辦法馬上去開發平臺，還有許多其餘的問題須要考慮。

一，    技術考慮

要完成咱們須要的功能，目前有哪些成熟的技術？Java和Python選哪一種語言比較好？數據庫用什麼？業界有沒有對應的開源框架，或是公司其餘人或部門有沒有這方面的嘗試？若是有現成的經驗可供參考，將減小咱們的開發成本，少走不少彎路。

二，    開發資源配置

若是咱們投入了相應的平臺的開發，人員如何配置：是你本身全面開發，仍是團隊開發？團隊的人員是什麼水平，他們能投入多少時間到平臺開發中？平臺開發時代碼如何管理？平臺能部署到哪裏？相應的軟硬件資源容易協調嗎？

三，    需求細化

若是上面的資源沒有問題，就須要細化咱們的需求了。每一項功能必須細化一下，出一個詳細的需求文檔。細化到顯示接口文檔的時候，應該顯示哪些信息？新增的時候須要填寫什麼字段等等。若是不如此細化出需求文檔，開發的時候就沒有依據。平時在咱們的正常工做中，是由產品來進行相關的工做的，但是若是咱們本身開發平臺的話，這就是咱們須要作的工做。

四，    代碼架構分析

細化完成需求後，就須要編寫代碼實現主要的功能。在寫代碼以前須要進行詳細的代碼架構設計，不能寫一段程序完成一個功能，而後都堆放在一塊兒，眉毛鬍子一把抓，後期維護成本至關大的。若是是團隊開發的話，沒有前期的代碼架構設計與分析，參與的人員越多，災難就會越大，合併代碼和維護會令人瘋掉的。

五，    實施維護和管理

在平臺開發初具規模的時候，就須要合理的維護和管理了。以便能使平臺更好地爲測試人員服務，此時的影響時間，問題排查，功能擴展等就會變成更加劇要了。無論你前期如何作需求調研，代碼如何規劃，功能如何強大，在投入使用後會出現各類問題。修改問題，優化代碼，新增功能將會持續很久的。

2.4 總結

   本章咱們從瞭解了測試平臺後，應該投入的下一個階段：平臺開發規劃，來簡單地介紹了相關須要規劃的內容，並以簡單的接口自動化平臺爲例進行了分析。固然若是測試平臺功能比較強大的話，須要考慮的內容更多，不過總體方向也是這幾個。但願經過這方面的介紹能給想作平臺開發的同窗帶來一些幫助，後面我會詳細介紹上面提到的各項規劃，請你們多多關注！