質量控制
大多數測試人員認為測試工作是發現bug,雖然這是測試的主要任務,但其實測試最重要的任務是質量控制,而發現bug和驗證bug只是質量控制的乙個重要環節而已。
我想很多測試人員都經歷過這樣的場景,就是測試環境全部都能測試通過,但正式上線之後就會有各種各樣的bug,到底是**出了問題呢?
在測試工作中,常見的問題原因分為以下幾類:
這是最常見的問題,一般新版本的迭代不僅僅是**層面的,還有資料庫的改動,而對於線上原有的資料來說改動了資料庫有可能會受到影響。
舉個例子:
如果資料庫增加了乙個字段,那麼新資料肯定會通過新的程式給這個字段賦值,而原有的資料這個字段往往是空的,這時讀取該資料就會發生問題。
當然這只是乙個最簡單的情況,這種情況在測試環境可以用歷史資料進行測試從而發現該問題。但往往還有更多複雜的情況,有時候是需要手動造資料庫的資料來模擬資料相容的問題。這個就是測試比較容易忽視,也最容易發生問題的乙個點。
測試環境和正式環境的不同也是一種經常發生的事情,
不同分2種情況:
硬體方面的,一般正式環境的伺服器都比測試環境來的好,所以硬體上不太可能一致,雖然這個差異影響比較小,但也不排除會影響程式的執行。
軟體方面的,包括程式語言的版本,伺服器系統的版本,甚至伺服器的許可權控制都會影響到程式的執行。
如果說不同版本的資料相容問題可以在測試環境預判並測試,那這種情況可能只能做到提醒開發和運維人員了,硬體方面沒辦法,軟體方面盡量做到一致,以減少測試環境和正式環境的差異,讓正式環境上的程式跑的更加穩定。
這個不同於上面說的程式語言版本,而是在**層面的配置:
以上3點只是常見的,事實上可能會遇到更奇葩和不可思議的問題,
例如所以好的測試不能只把目光放在**層面的測試,而是要從更高的視角去看整個專案在上線發布的時候存在的各種風險。有些可以通過測試而發現出來,而更多的還是要提醒開發和運維人員去規避這些上線的風險,我想這才是好的測試人員應該做到的事情。
效能測試通過標準
對於效能測試,在測試過程中需要通過觀察一些目標,根據這些目標的結果來判斷是否滿足要求,主要包含如下 業內對於效能測試有一些通用的通過標準,這裡給出乙個web專案效能測試通過標準,作為樣板 基本都遵循2 5 10,2s以內最佳 說明 另外需要強調的是,每個專案對於是否通過的標準不盡相同,實際執行中,優...
FFmpeg轉碼指令(測試通過)
1 rmvb提取音訊為 ffmpeg i rmvb 2 按時間範圍擷取 ffmpeg i rmvb ss 00 00 10 t 00 10 00 ss 擷取開始時間 t 擷取持續時間 ffmpeg i rmvb qscale 10 flv ffmpeg i rmvb s 640 480 flv 5 ...
本地測試通過,mvn打包報錯
異常原因 打包報錯,異常是 bigdecimal 轉 long 報錯 解決過程 mvn 打包報錯,從錯誤日誌中定位到 如下 classa a new classa 引用的外部包 a.settotalnum new bigdecimal 1111 mvn 打包出錯,日誌中定位的行數 a.setfile...