一、測試人員及早介入：
在梳理需求的可測試性過程中，不僅幫助預防和修正了部分潛在缺陷，而且加強了大家對需求的業務邏輯的認識，讓需求的藍圖和邊界更具象的傳達給專案成員，減少越往後越難以推到重來的風險。
測試人員需要做的：更詳細的了解需求設計思路，需求允許的邊界，明確出需求的可測試性，比如：設計出乙個過程執行所測試的功能，且輸出結果可以預知，可通過程式設計或者人工的方式加以驗證，代表這個需求是可測的。
二、驗證需求
1.給需求定義質量測度標準：大而化小。
2.需求質量檢驗標準：
【正確性】需求符合使用者需要，可以參考使用者或者一線的體驗意見
【完整性】沒有必要的需求元素遺漏，通過檢查需求文件並提出問題幫助發現遺漏點
【一致性】需求與產品內部其他部分不產生矛盾，沒有有歧義的描述
【可測試性】保證測試一條需求的可能性，測試的結果是預先知道的，可以通過程式設計或者人工進行驗證；如果不能，則需要註明需求的風險，盡可能讓需求可以測試
【可行性】在給定期限、資源、技術等條件下可實現
【必要性】必要性，需求與系統或者產品的相關性、必要性
【優先順序】需要讓需求涉眾了解需求對於產品的價值，並確定需求的優先順序，方便開發測試人員在成本與風險之間尋求平衡
【明確性】需求的描述，採取了精確和可度量的方法，在涉眾中對於功能或非功能口徑能達成一致意見
【可追溯性】能夠找到所有引用該需求的系統部分，對於需求的任何變化，能確定系統中受這種變化影響的所有部分。
軟體開發流程之需求階段
一 需求階段 1.功能性需求 2.外部介面需求 a.使用者介面b.硬體介面c.軟體介面d.通訊介面 3.非功能性需求 a.效能需求 b.防護性需求 c.安全性需求 d.軟體質量屬性 附 需求開發的支援工具 1.資料流圖 a.概念 系統的邏輯模型，用來描繪資料流在系統中的流動和處理情況，資料流圖具有對...
測試基礎系列之需求分析
一 前言 半年前，就準備開始寫部落格來分享我在測試中的點點滴滴，也是記錄下我自己的足跡。但由於工作太忙，一直沒有開始。萬事開頭難 現在終於開始寫了，所有的觀點均是個人理解，有什麼不對地方，希望大家能指出。測試基礎系列是基於我理解的測試流程來寫的，軟體測試流程在我的另一篇文章 聊聊測試管理 管事篇 中...
測試流程之需求評審
測試流程是整個測試過程中的命脈，也同時是指導整個測試團隊的核心工作，所以在面試過程中也面試官們必問之題，但是每個公司的測試流程都不盡相同，比如有公司有完整的需求文件，有些公司需求卻是零零散散，在測試過程中需求不斷向產品，向開發求證。很多公司雖然有需求分析，但是並沒有需求評審，今天我先給大家講一講測試...