測試經過！爲什麼線上還有不少BUG？實踐中的質量控制

質量控制

　　大多數 測試人員認爲測試工做是發現bug，雖然這是測試的主要任務，但其實測試最重要的任務是質量控制，而發現bug和驗證bug只是質量控制的一個重要環節而已。

　　我想不少測試人員都經歷過這樣的場景，就是測試環境所有都能測試經過，但正式上線以後就會有各類各樣的bug，究竟是哪裏出了問題呢？

 

　　在測試工做中，常見的問題緣由分爲如下幾類：

　 　●不一樣版本的數據兼容

　　這是最多見的問題，通常新版本的迭代不只僅是代碼層面的，還有 數據庫的改動，而對於線上原有的數據來講改動了數據庫有可能會受到影響。

　　舉個例子：

　　若是數據庫增長了一個字段，那麼新數據確定會經過新的程序給這個字段賦值，而原有的數據這個字段每每是空的，這時讀取該數據就會發生問題。

　　固然這只是一個最簡單的狀況，這種狀況在測試環境能夠用歷史數據進行測試從而發現該問題。但每每還有更多複雜的狀況，有時候是須要手動造數據庫的數據來模擬數據兼容的問題。這個就是測試比較容易忽視，也最容易發生問題的一個點。

　 　●測試環境和正式環境的不一樣

　　測試環境和正式環境的不一樣也是一種常常發生的事情，

　　不一樣分2種狀況：

　　硬件方面的，通常正式環境的服務器都比測試環境來的好，因此硬件上不太可能一致，雖然這個差別影響比較小，但也不排除會影響程序的運行。

　　軟件方面的，包括程序語言的版本，服務器系統的版本，甚至服務器的權限控制都會影響到程序的運行。

　　若是說不一樣版本的數據兼容問題能夠在測試環境預判並測試，那這種狀況可能只能作到提醒開發和運維人員了，硬件方面沒辦法，軟件方面儘可能作到一致，以減小測試環境和正式環境的差別，讓正式環境上的程序跑的更加穩定。

　 　●服務器的配置

　　這個不一樣於上面說的程序語言版本，而是在代碼層面的配置：

　　配置文件，包括代碼的相對路徑，某個功能的開關，又或者是服務器ip的配置等等。而這些都是相對於測試環境配置的，若是發佈的時候將配置文件覆蓋也會致使正式環境出問題。

　　服務器上配置的crontab腳本，不少程序是須要經過crontab腳本定時執行，而crontab又是須要在服務器上配置的，自動配置不方便控制及維護。因此大多數仍是須要人爲去配置的，這個配置若是漏了或者配置錯也會致使出問題。

　　以上3點只是常見的，事實上可能會遇到更奇葩和難以想象的問題，

　　 例如

　　●正式環境多臺服務器有一臺服務器代碼未更新，致使問題時隱時現。

　　●數據庫的主備數據不一致，當切換主備數據庫後會出問題。

　　之類的問題不少，因此在最開始就講要了解網絡的架構（點擊看原文），每個中間的環節都有可能出問題，而不只僅是代碼這一個環節。

　　因此好的測試不能只把目光放在代碼層面的測試，而是要從更高的視角去看整個項目在上線發佈的時候存在的各類風險。有些能夠經過測試而發現出來，而更多的仍是要提醒開發和運維人員去規避這些上線的風險，我想這纔是好的測試人員應該作到的事情。

　　看到這裏是否是會發現，一部分原來認爲是測試人員背的鍋，其實並無那麼地委屈。由於寬以待人嚴於律己，做爲優秀測試人員的你，能夠作得更多更好！