軟件質量挑戰和實踐建議(2)

　　圖 1 簡短描述了基于會議的測試。對于軟件中的任何新更改，計劃不同的測試會議，每個會議都有一個指定的目標和任務。測試會議期間，測試人員使用測試案例和/或執行探索性測試。測試會議結束時，會報告在會議期間找到的缺陷。

　　圖 1. 基于會議的測試工作流

　　基于風險的測試

　　因為在開發流程中進行了一些更改(主要的或次要的更改)，開發團隊通常擁有同一個軟件的許多常用版本。一種重要的 QA 實踐是在每個主要版本之后徹底測試軟件。另一方面，在每個版本中都對整個軟件運行全面的回歸測試既耗時又很難實現。但是，僅測試更改的功能或笨拙地刪減測試案例套件是不安全的。一段代碼可能解決了一個缺陷，但也可能破壞了代碼中的其他內容。

　　基于風險的測試方法采用了折中方式。它的基本理念是按降序對軟件功能和失敗模式排序，從最重要或風險最高到值得擁有的功能和簡單的風險(一個類似工具是 FMEA：失敗模式和影響分析)。如果測試人員在嚴格的時間限制下測試某個新版本時手頭有這個列表，他就可以集中精力確保新引入的更改不會破壞其他任何內容。然后就可以輕松地確保更改不會破壞軟件中的任何最重要的功能，因而不會發生任何最嚴重的風險。

　　回頁首結束語

　　每家公司都希望在充滿競爭的 IT 市場中飛得更高，而且在努力創造人們喜歡的優秀軟件。不幸的是，有時來自客戶或不耐煩的管理層的壓力可能導致團隊繞開軟件質量實踐，最終實現一個低于預期的產品。糟糕的軟件質量只有在它發生故障時才會被注意到。

　　本文中討論的實踐和方法貫穿整個開發生命周期。它們涵蓋需求分析、設計和開發，以及測試階段。而且它們表明缺陷預防比在項目結束時再解決問題要簡單得多，在項目結束時，更改帶來的技術人情債和成本將會很高。

　　本文突出了軟件質量角色和重要性，以確證忽略軟件質量可能嚴重影響公司實現其業務目標。另外，本文還為讀者介紹了一些更簡單、更高效的實踐，它們不但為團隊節省了時間、金錢和精力，還提升了產品的質量。

原文轉自：http://www.ibm.com/developerworks/cn/rational/software-quality-challenges-practice-recommendations/index.html