關於自動化測試平臺搭建的初步構想

一.前言
測試平臺能夠理解爲一個測試管理平臺，主要用WEB來進行實現，方便其餘人統一工做，方便公司統一管理，能夠提升公司效率。該平臺主要是爲測試服務，但不只爲測試提供服務。一切的出發點都是爲了提升工做效率，減小公司成本，爲公司提供一個更加愉快的工做環境。
二.爲何須要測試平臺
目前，不少小公司或者較大一點的公司，測試徹底是基於功能測試，若是隻是進行功能測試則能夠直接使用開源的項目質量管理軟件(例如:禪道)便可。若是進行接口、UI自動化測試、性能方面的測試，則可有考慮本身搭建測試平臺。下面就以接口測試爲例，接口測試通常抓包後須要進行消息體的構造，有人喜歡用postman工具直接保存接口，有人喜歡直接使用fiddler等其餘的工具，這樣不一樣的測試人員各自工具不統1、各自用例也不統一。前者新人來了接手工做可能須要學習新的工具，雖然時間短但也是成本的消耗，後者若是本地機器出現了問題可能全部用例都沒有了。既消耗了公司的成本又致使部門管理不規範。
若是搭建一個統一的平臺就能夠解決上述問題，例如直接在WEB界面上直接將消息體複製進來便可完成接口測試並添加額外的數據校驗功能，各個接口各個場景測試經過後直接將內容保存到數據庫中。這樣，1是代碼集中統一管理了；2是要求低,對操做人員低，任何人只須要按照格式進行消息體的構造就能夠進行接口測試；3是全部人只要有相應的權限便可共享用例，方面測試人員相互交流學習，也可發現問題並完善用例；4是提升了工做效率；5是相比較已有的開源工具，能夠隨意擴展。
文章以接口測試爲例簡述搭建測試平臺的思路。咱們知道，接口是程序的最重要的一部分，而接口測試相對於性能和功能來講可能也是比較簡單的。咱們只須要理解接口協議，看懂接口文檔，熟悉用戶使用場景，理解用戶的表面需求和隱性需求，咱們就能夠設計出各類各樣的接口測試用例，並能夠與開發工做同時進行。
三.怎麼作
既然是本身搭建平臺進行接口測試，我的認爲WEB是最好的選擇，咱們只須要部署好服務端，客戶端能夠直接訪問不用像其餘應用程序同樣須要在每臺客戶端安裝其餘軟件。
使用HTML/CSS鋪一個界面，保證能夠輸入URL、RequestBody及對應的請求方式便可，這樣後臺接受前端傳來的數據進行解析並拼接(後臺的處理主要看前端傳參的形式，最好是事先定義好規範)。後端將處理好的參數發送到相應的服務器，並接收響應的返回值返回給前面並在界面上顯示便可。這樣一個最簡單的接口測試流程就完成了。如圖所示:

四.如何完善
前面只是一個簡單的接口測試的過程，只能說能夠完成接口測試功能，可是和其餘測試工具相比並不能體現出平臺的優點，如何保證平臺的優點呢？
接口返回後，必須須要自動進行相關參數的校驗，1是返回狀態或返回值的校驗；2是相關數據庫數據的校驗；這些工做都可以在頁面完成，若是是返回狀態或返回值的校驗能夠直接用一個json格式來指定須要校驗的字段及對應的值(值能夠是變量)。若是是須要校驗數據庫則能夠經過表單的形式來完成，表單內須要校驗的值能夠是任意的，例如:能夠是入參的值;能夠入參處理後的值；可使用正則來校驗數據庫值的類型(有些要求有值便可，有些要求是字母、數字；有些要求包含某些指定的值；能夠指定查詢條件(where或in等等)……
這樣，只須要定義好格式就能夠完成從請求到返回結果校驗的全過程了。
五. 如何擴展
若是隻包含接口測試就稱之爲測試平臺，則有些大題小作了。我的認爲，測試平臺既能經過WEB頁面完成相關的測試還應該能定時自動運行指定的用例(當人多，機器天然不足時，能夠指定用例在半夜來自動跑用例)；能夠在代碼發佈以前進行檢測代碼的質量，只有當代碼只能知足指標時才容許發佈；能夠將各個項目的公用測試工具(例如mock消息)均可以包含進平臺中，這樣全部人均可以直接使用…

只有想不到的，沒有作不到的。前提是成本低、效率高,不能只是爲了平臺化而刻意平臺。
六.歡迎關注做者公衆號