軟件測試過程當中應注意的風險

在編寫測試計劃的時候要考慮可能發生的風險，並提出應對措施。那麼到底都有哪些風險要注意呢?如何解決呢?如下列出了一些方案：

　　設計方面：

　　風險：(1)沒有詳細設計說明書;

　　解決方案：測試人員要在開發階段對相關設計及需求文檔進行分析，對大致模塊功能進行分類，分析業務邏輯，在不清楚的地方及時與開發人員溝通。

　　風險：(2)沒有統一的界面設計規範。

　　解決方案：與項目負責人確認測試標準。

　　開發方面：

　　風險：(1)全部模塊開發沒有統一設計，開發人員有本身的設計方式;

　　解決方案：與項目負責人確認標準方式，與標準方式不一致的地方所有以BUG形式提交。

　　風險：(2)需求變動開發。

　　解決方案：建議將需求變動造成文檔，對沒有文檔的需求變動，在測試過程當中發現及時與開發負責人確認，並存檔相關變動文檔。

　　測試自己：

　　風險：(1)人力資源;

　　解決方案：保證穩定的人員安排。

　　風險：(2)硬件資源;

　　解決方案：事先分析測試所需硬件資源，及時申請，保證測試工做順利進行。

　　風險：(3)版本控制;

　　解決方案：嚴格控制版本，BUG以版本爲單位進行提交。在測試過程當中及BUG確認階段禁止任何代碼更新。

　　風險：(4)測試時間不足。

　　解決方案：動員測試人員完成測試任務，必要時，應給予相應物質獎勵。

　　測試風險是不可避免的、老是存在的，因此對測試風險的管理很是重要，必須盡力下降測試中所存在的風險，最大程度地保證質量和知足客戶的需求。在測試工做中，主要的風險有：

　　1、質量需求或產品的特性理解不許確，形成測試範圍分析的偏差，結果某些地方始終測試不到或驗證的標準不對;

　　2、測試用例沒有獲得百分之百的執行，若有些測試用例被有意或無心的遺漏;

　　3、需求的臨時/忽然變化，致使設計的修改和代碼的重寫，測試時間不夠;

　　4、質量標準不都是很清晰的，如適用性的測試，仁者見仁、智者見智;

　　5、測試用例設計不到位，忽視了一些邊界條件、深層次的邏輯、用戶場景等;

　　6、測試環境，通常不可能和實際運行環境徹底一致，形成測試結果的偏差;

　　7、有些缺陷出現頻率不是百分之百，不容易被發現;若是代碼質量差，軟件缺陷不少，被漏檢的缺陷可能性就大;

　　8、迴歸測試通常不運行所有測試用例，是有選擇性的執行，必然帶來風險。

　　前面三種風險是能夠避免的，而四至七的四種風險是不能避免的，能夠降到最低。最後一種迴歸測試風險是能夠避免，但出於時間或成本的考慮，通常也是存在的。

　　針對上述軟件測試的風險，有一些有效的測試風險控制方法，如：

　　測試環境不對能夠經過事先列出要檢查的全部條目，在測試環境設置好後，由其餘人員按已列出條目逐條檢查;

　 　有些測試風險可能帶來的後果很是嚴重，可否將它轉化爲其餘一些不會引發嚴重後果的低風險。如產品發佈前夕，在某個不是很重要的新功能上發現一個嚴重的缺陷，若是修正這個缺陷，頗有可能引發某個原有功能上的缺陷。這時處理這個缺陷所帶來的風險就很大，對策是去掉那個新功能，轉移這種風險;

　　有些風險不可避免，就設法下降風險，如「程序中未發現的缺陷」這種風險老是存在，咱們就要經過提升測試用例的覆蓋率(如達到99.9%)來下降這種風險;

　　爲了不、轉移或下降風險，事先要作好風險管理計劃和控制風險的策略，並對風險的處理還要制定一些應急的、有效的處理方案，如：

　　在作資源、時間、成本等估算時，要留有餘地，不要用到100%;

　　在項目開始前，把一些環節或邊界上的可能會有變化、難以控制的因素列入風險管理計劃中;

　　對每一個關鍵性技術人員培養後備人員，做好人員流動的準備，採起一些措施確保人員一旦離開公司，項目不會受到嚴重影響，仍能能夠繼續下去;

　　制定文檔標準，並創建一種機制，保證文檔及時產生;

　　對全部工做多進行互相審查，及時發現問題，包括對不一樣的測試人員在不一樣的測試模塊上相互調換;

　　對全部過程進行平常跟蹤，及時發現風險出現的徵兆，避免風險。

　 　要想真正迴避風險，就必須完全改變測試項目的管理方式;針對測試的各類風險，創建一種「防患於未然」或「以預防爲主」的管理意識。與傳統的軟件測試相比，全過程測試管理方式不只能夠有效下降產品的質量風險，並且還能夠提早對軟件產品缺陷進行規避、縮短對缺陷的反饋週期和整個項目的測試周期。