質量控制
大多數
測試人員認為測試工作是發現bug，雖然這是測試的主要任務，但其實測試最重要的任務是質量控制，而發現bug和驗證bug只是質量控制的一個重要環節而已。
我想很多測試人員都經歷過這樣的場景，就是測試環境全部都能測試通過，但正式上線之后就會有各種各樣的bug，到底是哪里出了問題呢？
在測試工作中，常見的問題原因分為以下幾類：
●不同版本的數據兼容
這是最常見的問題，一般新版本的迭代不僅僅是代碼層面的，還有
數據庫的改動，而對於線上原有的數據來說改動了數據庫有可能會受到影響。
舉個例子：
如果數據庫增加了一個字段，那么新數據肯定會通過新的程序給這個字段賦值，而原有的數據這個字段往往是空的，這時讀取該數據就會發生問題。
當然這只是一個最簡單的情況，這種情況在測試環境可以用歷史數據進行測試從而發現該問題。但往往還有更多復雜的情況，有時候是需要手動造數據庫的數據來模擬數據兼容的問題。這個就是測試比較容易忽視，也最容易發生問題的一個點。
●測試環境和正式環境的不同
測試環境和正式環境的不同也是一種經常發生的事情，
不同分2種情況：
硬件方面的，一般正式環境的服務器都比測試環境來的好，所以硬件上不太可能一致，雖然這個差異影響比較小，但也不排除會影響程序的運行。
軟件方面的，包括程序語言的版本，服務器系統的版本，甚至服務器的權限控制都會影響到程序的運行。
如果說不同版本的數據兼容問題可以在測試環境預判並測試，那這種情況可能只能做到提醒開發和運維人員了，硬件方面沒辦法，軟件方面盡量做到一致，以減少測試環境和正式環境的差異，讓正式環境上的程序跑的更加穩定。
●服務器的配置
這個不同於上面說的程序語言版本，而是在代碼層面的配置：
配置文件，包括代碼的相對路徑，某個功能的開關，又或者是服務器ip的配置等等。而這些都是相對於測試環境配置的，如果發布的時候將配置文件覆蓋也會導致正式環境出問題。
服務器上配置的crontab腳本，很多程序是需要通過crontab腳本定時執行，而crontab又是需要在服務器上配置的，自動配置不方便控制及維護。所以大多數還是需要人為去配置的，這個配置如果漏了或者配置錯也會導致出問題。
以上3點只是常見的，事實上可能會遇到更奇葩和不可思議的問題，
例如
●正式環境多台服務器有一台服務器代碼未更新，導致問題時隱時現。
●數據庫的主備數據不一致，當切換主備數據庫后會出問題。
之類的問題很多，所以在最開始就講要了解網絡的架構（點擊看原文），每一個中間的環節都有可能出問題，而不僅僅是代碼這一個環節。
所以好的測試不能只把目光放在代碼層面的測試，而是要從更高的視角去看整個項目在上線發布的時候存在的各種風險。有些可以通過測試而發現出來，而更多的還是要提醒開發和運維人員去規避這些上線的風險，我想這才是好的測試人員應該做到的事情。
看到這里是不是會發現，一部分原來認為是測試人員背的鍋，其實並沒有那么地委屈。因為寬以待人嚴於律己，作為優秀測試人員的你，可以做得更多更好！