是什麼殺死了軟體測試人員？

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

隨著萬聖節的臨近，那我們看看幾樣對軟體測試人員最具有殺傷性的武器。

加快釋出週期

為了應對現今“快魚吃慢魚”的緊張局勢，軟體交付程式變得越來越緊，考慮到軟體測試會阻礙軟體交付的時間，所以只靠加快質量程式就想達成預定目標是不現實的。

但是如果沒有足夠的時間用於測試的話，這可能就意味著你們的組織文化需要大肆整頓一番了，因為文化對構建和測試軟體起導向作用。毋庸置疑，我們都希望生產出高質量的軟體，但是組織文化能影響決策的偏頗，而這會導致軟體投放市場時產生的風險大小。

開發過程中寫出的劣質程式碼

軟體測試人員主要的工作就是執行測試，但是卻無法追究於一些原本完全可以在實施過程中發現的簡單錯誤。所以如果一個開發團隊能持續應用開發測試方法，例如單元測試、靜態分析和同行程式碼審查以確保程式碼在進入QA前剔除掉很多不必要的缺陷和問題，這將會大大減少QA用於發現、報告然後修復這些缺陷所需要的時間。這麼做不但能提高團隊的整體速度，還有助於測試人員將有限的時間全部用於執行那些艱鉅的測試任務。

真實的測試資料

真實的測試資料能顯著改善測試套件的有效性。良好的測試資料和測試資料管理方在提高覆蓋率的同時也會增加風險，所以開發並獲取測試資料可能在很長一段時間內都將是一個相當大的挑戰——因為我們需要投入大量的時間和精力等等。拷貝生產資料是有風險的（並且有可能違法），而要求資料庫管理員來提供必要資料的話通常又有諸多延誤，要是將這任務轉嫁到開發人員或者QA頭上，又很可能會延誤專案的其他方面，導致一些不準確或者不完整的結果。

有些團隊發現模擬技術，例如虛擬化服務，可以減少對測試資料管理的恐懼。

完整的測試環境

如果有多個相關係統，那麼要想建立一個完整又真實的測試環境幾乎是不可能的。開發人員、測試人員和效能工程師經常要面對下面這些難題：

• 系統過於複雜或者不切實際以至於不能採用測試實驗室的方法
• 區域劃分或者政治方面的界限限制了我們對資源的訪問
• 無法訪問第三方/合作伙伴的系統和服務
• 限制了測試的排程制約
• 有缺失/不穩定的元件
• 不斷變化的開發環境

通過構建一個階段性的測試環境或虛擬測試實驗室的方法來試圖解決測試環境的訪問限制，可謂是非常昂貴的。在很多情況下，構建這樣一個採用分級應用例項和虛擬測試實驗室的環境是不可能的——舉個例子，如果相關的應用程式是一個第三方應用程式，那麼往往會由其他部門或者超越“地緣政治”界限的執行測試團體來託管其複雜系統（如大型機）。即使是在構建一個“完整的”測試環境也是可行的情況下，配置並維護所有相關的應用程式依然需要持續性的高額運營成本。

但是不幸的是：測試人員無法完成測試。最新的研究表明，由於測試環境的訪問限制，64％的測試人員花費很少或者幾乎沒有時間來建立自動化的測試，並且只有50％的測試計劃按照預期完成。

如果你想逃脫上述追殺，那麼服務虛擬化或許可以為您提供一個安全避難所。