1、測試人員盡早介入

盡量在需求階段就開始介入，其好處不言而喻，盡早發(fā)現(xiàn)問題可以有效的降低項目風險和修復成本。讓質量保障的工作貫穿整個軟件開發(fā)的生命周期，有效的進行 缺陷預防。

2、驗證需求

為每個需求提供 質量度量標準，具體而言就是針對需求劃分2個分類：滿足需求分類和不滿足需求分類。要明確滿足需求和不滿足需要的具體度量標準，是模糊的需求明確化。對于不易明確化的需求，可以進行需求劃分，把大需求劃分為若干個可以明確的小需求。驗證需求時需要驗證的屬性：

• 正確性：根據(jù)用戶的需求進行驗證。是否正確的完成了用戶的真實需求。
• 完整性：用于保證需求中沒有遺漏任何必須的元素。避免遺漏原始需求。

除了功能性需求之外，非功能性需求也需要驗證，具體包括：性能、安全、可用性、兼容性、可訪問性等。非功能性需求可以分為系統(tǒng)級需求和功能級需求。非功能性需求檢查表如下：

• 一致性：是否有互相矛盾的情況。排除有歧義的地方。
• 可測性：需求是否可以測試并且有準確的預期輸入和結果。否則需要提醒相關風險。
• 可行性：保證需求可以在有效的資源內被完成。比如：預算、進度、技術等。
• 必要性：確認需求是否為必須，如果去除是否有任何問題。
• 優(yōu)先級：為每個需求確定其優(yōu)先級，便于后期在必要時對需求進行取舍。
• 明確性：需求的陳述需要精確且可測量。比如：性能指標不能以很快來描述。
• 可追溯性：明確需求被哪些功能模塊所調用。保證在需求變化的時候可以追溯影響的范圍。

3、需求就緒后立即設計測試過程

測試過程是對需求可測試性的再次確定，在有效的時間內為每個需求設計盡可能的測試過程，必要的情況下可以按照優(yōu)先級來順序完成，在需求得到精化后需要同步更新測試過程。測試過程應當包含：需求的輸入數(shù)據(jù)、需求的驗證步驟、已知的預期結果。

4、確保需求變化的傳達

如上3所述，需求在變化后需要盡快的通知到所有相關的涉眾。包括設計、編碼、測試。這樣才能保證需求能夠被完整的消化，否則可能會引發(fā)較多的無效缺陷。

5、注意在現(xiàn)存系統(tǒng)上進行開發(fā)和測試

基于現(xiàn)存的系統(tǒng)進行開發(fā)或者重構，往往會有很多問題。比如：新舊系統(tǒng)的一致性等。如果要避免2個版本的并行開發(fā)的問題，則需要按照如下流程來管理開發(fā)項目：

• 使用確定版本作為基準版本
• 把該版本程序進行文檔化【如果有則可省略】
• 基準版本有更新時也要文檔化
• 固化形成的有效開發(fā)過程

6、了解手頭的任務和相關的測試目標

判斷一個程序功能是否正確的要素：

• 合法輸入有正確的返回
• 非法輸入有對應的提示
• 不論何種輸入程序都不應掛起、崩潰或退出
• 可以在預定的時間內一直正常運行
• 實現(xiàn)了功能性、非功能性需求

了解測試目標的途徑如下：

• 理解系統(tǒng)。從更高的層次來理解需求，而非獨立的思考需求本身
• 盡早介入
• 理解企業(yè)文化和過程。為更好的適應和提出改進意見做準備
• 實現(xiàn)的范圍
• 測試期望。高層、客戶對測試的期望
• 吸取教訓
• 工作量大小
• 解決方案的類型。復雜的解決方案，還是簡單的解決方式
• 技術選擇。根據(jù)技術棧確定待測對象
• 預算。根據(jù)預算來確定投入的測試工作量
• 時間表。根據(jù)時間表來調整測試時間
• 版本提測方式。迭代提測還是大版本提測

在對系統(tǒng)有了全面的了解后，就可以知道系統(tǒng)的規(guī)模和相應的工作量、客戶的問題及潛在的風險。通過這些信息來了解當前的測試任務，并據(jù)此確定測試目標及對應的測試框架。最終形成測試計劃或者測試策略文檔。

7、考慮風險

?

總結

以上是生活随笔為你收集整理的有效软件测试 - 50条建议 - 需求阶段的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。