關於預發布測試的思考

由於近段時間，公司有個專案頻繁出現軟體發布後發現有問題，需要回滾。問題的原因很多，可能是運維配置問題、測試環境差異問題、漏測問題、修改範圍評估不足導致舊功能有問題等等。因此，專案組提到了預發布測試的想法。從而引發了我對預發布測試的深入思考（之前有思考過做，但由於各種原因沒落實執行）。

專案組提出的預發布測試簡單來說就是測試人員模擬運維人員進行部署和配置的測試、然後進行版本規劃功能的測試和熱門功能的測試，確保軟體發布生產環境後執行沒有問題。正如一千個人的眼裡就有一千個哈姆雷特，其實每一家公司的預發布測試的實施目的和實施過程都不完全一樣。本人就以自身公司為例子進行思考。

當預發布測試說將要推行時，一些基層的測試人員就有想法了：

1、關於部署和配置過程本身不屬於測試範圍，軟體運維的工作，有時候軟體運維各種配錯了導致問題出現，現在卻變成測試人員要來檢驗部署和配置的過程。

2、測試環境測試過了，為什麼還要在預發布環境測試一遍，測試工作量的重複投入了，測試人力資源成本大了。

3、熱門功能是之前上線功能，當前版本沒有改動，為什麼還要測試一遍，測試工作量又增大。

4、本身專案的版本迭代週期就短，就快，而且測試時間長期一直被擠壓，現在又多加乙個測試環節。甚至於，本來該專案測試就要加班加點，又弄乙個測試環節出了，怎麼破。

那麼，作為測試的管理者，就需要對這個流程進行深入思考，和判斷是否要做了同時也要做好下面的工作。

首先，預發布環境是乙個什麼環境？預發布環境其實生產環境，只不過是服務是另外獨立部署（為了不影響線上），如果涉及資料庫結構的改動會提前在測試環境做好測試和評估。預發布測試是屬於測試的乙個環節，在系統測試之後發布上線前，也就是上線前的最後一次生產環境測試。

1）解決測試環境與生產環境的差異，提前發現問題，使得上線後盡可能的避免出現問題

2）驗證運維部署和配置的過程會不會存在問題，配置類的交付是否齊全，有助於運維工作的暢順

3）版本功能和舊功能的線上驗證，保障版本執行正確正常，提前發現開發對版本影響範圍評估不足而導致舊功能有問題

4）在生產環境驗證可以彌補某些無法在測試環境中執行的用例，提高測試執行覆蓋率

1）測試人力成本（主要成本）

2）運維人力成本（有些環境需要運維人員協助完成，如環境的部署等）

3）出差成本（主要因為有些專案公司內沒有環境，需要出差到現場進行測試）

4）延誤常規測試任務

5）多部門溝通協調成本（關於實施部署這塊，需要跟軟體運維、硬體運維，甚至產品部、市場部的去溝通協調，落實測試環境和測試資料問題）

既然專案組已經提出想法，首先要考慮這個環節做了能不能解決問題，有沒有收益。

首先，對於測試，工作量的增加了，但測試手段也增加了，一些在測試環境沒測試出來的問題提前發現了，進一步保障的軟體上線的質量。

再者，對於運維，測試人員在預發布環節把部署、配置和功能都」演練「了一次，後續工作順暢了，同時運維自身的功能驗證或者也省了。

最後，對於近段時間頻繁爆發問題，預發布測試手段確實能解決問題（如版本影響範圍評估不足、運維交付和配置檢驗、無法執行的用例等），提高版本發布的成功率。

每個公司都會有自身的各方面考慮，究竟值不值得做在這裡不會妄下定論，最好結合目前專案組的實際情況、資源情況、市場情況等來得出質量保障的最優解，綜合考慮。