8年測試只剩下著點心得體會了！
質量控制
大多數測試人員認為測試工作是發現bug，雖然這是測試的主要任務，但其實測試最重要的任務是質量控制，而發現bug和驗證bug只是質量控制的一個重要環節而已。
我想很多測試人員都經歷過這樣的場景，就是測試環境全部都能測試通過，但正式上線之後就會有各種各樣的bug，到底是哪裡出了問題呢？
在測試工作中，常見的問題原因分為以下幾類：
不同版本的資料相容
這是最常見的問題，一般新版本的迭代不僅僅是程式碼層面的，還有資料庫的改動，而對於線上原有的資料來說改動了資料庫有可能會受到影響。
舉個例子：
如果資料庫增加了一個欄位，那麼新資料肯定會通過新的程式給這個欄位賦值，而原有的資料這個欄位往往是空的，這時讀取該資料就會發生問題。
當然這只是一個最簡單的情況，這種情況在測試環境可以用歷史資料進行測試從而發現該問題。但往往還有更多複雜的情況，有時候是需要手動造資料庫的資料來模擬資料相容的問題。這個就是測試比較容易忽視，也最容易發生問題的一個點。
測試環境和正式環境的不同
測試環境和正式環境的不同也是一種經常發生的事情，
不同分2種情況：
硬體方面的，一般正式環境的伺服器都比測試環境來的好，所以硬體上不太可能一致，雖然這個差異影響比較小，但也不排除會影響程式的執行。
軟體方面的，包括程式語言的版本，伺服器系統的版本，甚至伺服器的許可權控制都會影響到程式的執行。
如果說不同版本的資料相容問題可以在測試環境預判並測試，那這種情況可能只能做到提醒開發和運維人員了，硬體方面沒辦法，軟體方面儘量做到一致，以減少測試環境和正式環境的差異，讓正式環境上的程式跑的更加穩定。
伺服器的配置
這個不同於上面說的程式語言版本，而是在程式碼層面的配置：
配置檔案，包括程式碼的相對路徑，某個功能的開關，又或者是伺服器ip的配置等等。而這些都是相對於測試環境配置的，如果釋出的時候將配置檔案覆蓋也會導致正式環境出問題。
伺服器上配置的crontab指令碼，很多程式是需要通過crontab指令碼定時執行，而crontab又是需要在伺服器上配置的，自動配置不方便控制及維護。所以大多數還是需要人為去配置的，這個配置如果漏了或者配置錯也會導致出問題。
以上3點只是常見的，事實上可能會遇到更奇葩和不可思議的問題，
例如
正式環境多臺伺服器有一臺伺服器程式碼未更新，導致問題時隱時現。
資料庫的主備資料不一致，當切換主備資料庫後會出問題。
之類的問題很多，所以在最開始就講要了解網路的架構，每一箇中間的環節都有可能出問題，而不僅僅是程式碼這一個環節。
所以好的測試不能只把目光放在程式碼層面的測試，而是要從更高的視角去看整個專案在上線釋出的時候存在的各種風險。有些可以通過測試而發現出來，而更多的還是要提醒開發和運維人員去規避這些上線的風險，我想這才是好的測試人員應該做到的事情。
看到這裡是不是會發現，一部分原來認為是測試人員背的鍋，其實並沒有那麼地委屈。因為寬以待人嚴於律己，作為優秀測試人員的你，可以做得更多更好！
最後跟大家推薦一個學習資料分享群：672899761，裡面大牛已經為我們整理好了許多的學習資料，有自動化，介面，效能等等的學習資料！
人生是一個逆水行舟的過程，不進則退，咱們一起加油吧！