對于測試時間和測試資源有限的軟件產(chǎn)品測試而言，基于風險的測試是一個比較好的選擇，可以幫助測試人員更好地提高測試效率并提升對測試對象的信心。這種測試作為一種有效的軟件測試方法，它自身又會面臨各種挑戰(zhàn)，它的風險又在哪里呢？本文將闡述基于風險的測試過程中經(jīng)常面臨的一些問題并根據(jù)實際情況給出的一些建議。

　。1）測試風險分析自身的風險

　　基于風險的測試需要分析和評估測試中存在的風險，并根據(jù)得到的結果將測試對象按照不同優(yōu)先級排列，首先測試重要和優(yōu)先級高的部分。但是測試風險評估本身也可能存在偏差，導致測試人員和測試資源分配的不合理。更嚴重的情況可能是高優(yōu)先級的測試對象被分析和評估為低優(yōu)先級，甚至由于時間和成本的原因而沒有測試。為了避免這種情況的出現(xiàn)，需要在測試風險分析和評估中采用如下一些方法。

　　● 盡量召集各個方面的項目參與人員共同識別和分析測試風險，如項目經(jīng)理、系統(tǒng)人員、開發(fā)人員、測試人員、實驗室管理員和配置管理員等，以求測試風險的全面和準確。

　　● 測試人員積極參與項目的各種評審，從項目管理、業(yè)務管理和用戶角度深入分析和研究項目中可能存在的各個方面的風險。

　　● 分析測試過程中發(fā)現(xiàn)的缺陷的來源。如果發(fā)現(xiàn)很多缺陷來自低優(yōu)先級的測試對象，或者在這種對象中發(fā)現(xiàn)了嚴重的問題，那么需要重新分析和評估這部分測試對象的風險。

　　● 對低風險的測試對象執(zhí)行一些探索性測試，以判斷風險分析和評估的正確性。

　。2）完成測試之后的風險

　　基于風險的測試可以加速提升對軟件產(chǎn)品質量的信心。因此當時間、成本和資源等有限且在測試完成率為“可以發(fā)布”時，可能結束測試，而不是達到的測試完成率，測試完成率沒有達到意味著低風險或優(yōu)先級比較低的測試對象可能沒有測試或完成測試。實際上這種情況也是存在風險的，需要進一步采取一些措施來減輕這方面的風險。

　　● 在軟件發(fā)布以后，測試團隊在時間和資源允許的條件下，應該繼續(xù)后續(xù)的測試。直到測試計劃中的測試全部執(zhí)行完畢，達到的測試完成率。

　　● 將測試的軟件產(chǎn)品和測試環(huán)境移交給軟件產(chǎn)品的維護組，使其能夠快速地定位和解決市場和用戶反饋的問題和缺陷。

　。3）基于風險的測試是管理人員的事情

　　在討論基于風險的測試時，經(jīng)？梢月牭竭@樣的言論：“這是管理人員的事情”，如根據(jù)產(chǎn)品風險對相關測試活動分配測試資源。實際上基于風險的測試不僅僅是管理人員的事情，測試分析、設計和執(zhí)行人員在其中都有各自的職責。無論是風險識別和評估，還是制訂和實施具體的風險應對措施都需要各方面人員的積極參與。

　　（4）風險列表不清晰

　　識別和分析風險可以有多種方法，測試過程中經(jīng)常采用的是頭腦風暴法，即測試經(jīng)理召集測試團隊成員和其他利益相關者開展風險識別活動。通過頭腦風暴法，測試團隊很快可以得到一個很長的風險列表。面對這樣的一個風險列表，如何管理這些風險將是一個問題。例如，有的風險描述含糊不清，有些風險則冗余重復，因此較好的方法是將頭腦風暴法和其他風險識別方法相結合；陲L險模板和基于質量特性的頭腦風暴法可以為風險提供系統(tǒng)性的保障并避免風險的重復。