大家好，我是一菲，今天我們來談談做軟體測驗作業該規避哪些風險呢？
首先是開發方面：
風險：1.所有模塊開發沒有統一設計，開發人員有自己的設計方式;
解決方案：與專案負責人確認標準方式，與標準方式不一致的地方全部以BUG形式提交，
風險：2.需求變更開發，
解決方案：建議將需求變更形成檔案，對沒有檔案的需求變更，在測驗程序中發現及時與開發負責人確認，并存檔相關變更檔案，
接下來是測驗本身
風險：1.人力資源;
解決方案：保證穩定的人員安排，
風險：2.硬體資源;
解決方案：事先分析測驗所需硬體資源，及時申請，保證測驗作業順利進行，
風險：3.版本控制;
解決方案：嚴格控制版本，BUG以版本為單位進行提交，在測驗程序中及BUG確認階段禁止任何代碼更新，
風險：4.測驗時間不足，
解決方案：動員測驗人員完成測驗任務，必要時，應給予相應物質獎勵，
測驗風險是不可避免的、總是存在的，所以對測驗風險的管理非常重要，必須盡力降低測驗中所存在的風險，最大程度地保證質量和滿足客戶的需求，在測驗作業中，主要的風險有：
一、質量需求或產品的特性理解不準確，造成測驗范圍分析的誤差，結果某些地方始終測驗不到或驗證的標準不對;
二、測驗用例沒有得到百分之百的執行，如有些測驗用例被有意或無意的遺漏;
三、需求的臨時/突然變化，導致設計的修改和代碼的重寫，測驗時間不夠;
四、質量標準不都是很清晰的，如適用性的測驗，仁者見仁、智者見智;
五、測驗用例設計不到位，忽視了一些邊界條件、深層次的邏輯、用戶場景等;
六、測驗環境，一般不可能和實際運行環境完全一致，造成測驗結果的誤差;
七、有些缺陷出現頻率不是百分之百，不容易被發現;如果代碼質量差，軟體缺陷很多，被漏檢的缺陷可能性就大;
八、回歸測驗一般不運行全部測驗用例，是有選擇性的執行，必然帶來風險，
前面三種風險是可以避免的，而四至七的四種風險是不能避免的，可以降到最低，最后一種回歸測驗風險是可以避免，但出于時間或成本的考慮，一般也是存在的，
針對上述軟體測驗的風險，有一些有效的測驗風險控制方法，如：
測驗環境不對可以通過事先列出要檢查的所有條目，在測驗環境設定好后，由其他人員按已列出條目逐條檢查;
有些測驗風險可能帶來的后果非常嚴重，能否將它轉化為其他一些不會引起嚴重后果的低風險，如產品發布前夕，在某個不是很重要的新功能上發現一個嚴重的缺陷，如果修正這個缺陷，很有可能引起某個原有功能上的缺陷，這時處理這個缺陷所帶來的風險就很大，對策是去掉(Diasble)那個新功能，轉移這種風險;
有些風險不可避免，就設法降低風險，如“程式中未發現的缺陷”這種風險總是存在，我們就要通過提高測驗用例的覆寫率(如達到99.9%)來降低這種風險;
為了避免、轉移或降低風險，事先要做好風險管理計劃和控制風險的策略，并對風險的處理還要制定一些應急的、有效的處理方案，如：
在做資源、時間、成本等估算時，要留有余地，不要用到100%;
在專案開始前，把一些環節或邊界上的可能會有變化、難以控制的因素列入風險管理計劃中;
對每個關鍵性技術人員培養后備人員，作好人員流動的準備，采取一些措施確保人員一旦離開公司， 專案不會受到嚴重影響，仍能可以繼續下去;
制定檔案標準，并建立一種機制，保證檔案及時產生;
對所有作業多進行互相審查，及時發現問題，包括對不同的測驗人員在不同的測驗模塊上相互調換;
對所有程序進行日常跟蹤，及時發現風險出現的征兆，避免風險，
要想真正回避風險，就必須徹底改變測驗專案的管理方式;針對測驗的各種風險，建立一種“防患于未然”或“以預防為主”的管理意識，與傳統的軟體測驗相比，全程序測驗管理方式不僅可以有效降低產品的質量風險，而且還可以提前對軟體產品缺陷進行規避、縮短對缺陷的反饋周期和整個專案的測驗周期，
在這里推薦一個軟體測驗交流群，QQ：642830685，群中會不定期的軟體測驗資源，測驗面試題以及行業資訊們，大家可以在群中積極交流技術，還有大佬為你答疑解惑，大家也可以關注我的微信公眾號，程式媛一菲，有更多的好物和大家一起分享，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/252502.html
標籤：其他