因爲近段時間,公司有個項目頻繁出現軟件發佈後發現有問題,須要回滾。問題的緣由不少,多是運維配置問題、測試環境差別問題、漏測問題、修改範圍評估不足致使舊功能有問題等等。所以,項目組提到了預發佈測試的想法。從而引起了我對預發佈測試的深刻思考(以前有思考過作,但因爲各類緣由沒落實執行)。數據庫
項目組提出的預發佈測試簡單來講就是測試人員模擬運維人員進行部署和配置的測試、而後進行版本規劃功能的測試和熱門功能的測試,確保軟件發佈生產環境後運行沒有問題。正如一千我的的眼裏就有一千個哈姆雷特,其實每一家公司的預發佈測試的實施目的和實施過程都不徹底同樣。本人就以自身公司爲例子進行思考。運維
當預發佈測試說將要推行時,一些基層的測試人員就有想法了:測試
一、關於部署和配置過程自己不屬於測試範圍,軟件運維的工做,有時候軟件運維各類配錯了致使問題出現,如今卻變成測試人員要來檢驗部署和配置的過程。資源
二、測試環境測試過了,爲何還要在預發佈環境測試一遍,測試工做量的重複投入了,測試人力資源成本大了。開發
三、熱門功能是以前上線功能,當前版本沒有改動,爲何還要測試一遍,測試工做量又增大。部署
四、自己項目的版本迭代週期就短,就快,並且測試時間長期一直被擠壓,如今又多加一個測試環節。甚至於,原本該項目測試就要加班加點,又弄一個測試環節出了,怎麼破。
產品
那麼,做爲測試的管理者,就須要對這個流程進行深刻思考,和判斷是否要作了同時也要作好下面的工做。軟件
首先,預發佈環境是一個什麼環境?預發佈環境其實生產環境,只不過是服務是另外獨立部署(爲了避免影響線上),若是涉及數據庫結構的改動會提早在測試環境作好測試和評估。預發佈測試是屬於測試的一個環節,在系統測試以後發佈上線前,也就是上線前的最後一次生產環境測試。配置
1)解決測試環境與生產環境的差別,提早發現問題,使得上線後儘量的避免出現問題硬件
2)驗證運維部署和配置的過程會不會存在問題,配置類的交付是否齊全,有助於運維工做的暢順
3)版本功能和舊功能的線上驗證,保障版本運行正確正常,提早發現開發對版本影響範圍評估不足而致使舊功能有問題
4)在生產環境驗證能夠彌補某些沒法在測試環境中執行的用例,提升測試執行覆蓋率
1)測試人力成本(主要成本)
2)運維人力成本(有些環境須要運維人員協助完成,如環境的部署等)
3)出差成本(主要由於有些項目公司內沒有環境,須要出差到現場進行測試)
4)延誤常規測試任務
5)多部門溝通協調成本(關於實施部署這塊,須要跟軟件運維、硬件運維,甚至產品部、市場部的去溝通協調,落實測試環境和測試數據問題)
既然項目組已經提出想法,首先要考慮這個環節作了能不能解決問題,有沒有收益。
首先,對於測試,工做量的增長了,但測試手段也增長了,一些在測試環境沒測試出來的問題提早發現了,進一步保障的軟件上線的質量。
再者,對於運維,測試人員在預發佈環節把部署、配置和功能都」演練「了一次,後續工做順暢了,同時運維自身的功能驗證或者也省了。
最後,對於近段時間頻繁爆發問題,預發佈測試手段確實能解決問題(如版本影響範圍評估不足、運維交付和配置檢驗、沒法執行的用例等),提升版本發佈的成功率。
每一個公司都會有自身的各方面考慮,究竟值不值得作在這裏不會妄下定論,最好結合目前項目組的實際狀況、資源狀況、市場狀況等來得出質量保障的最優解,綜合考慮。