0cm;text-align:justify;text-justify:inter-ideograph;line-height:170%;
mso-pagination:lines-together;page-break-after:avoid">第97貼【2004－9－8】：通過用例設計來測試需求
我們從V模型上可以知道，驗收測試是以系統需求為基礎的，系統測試是以功能測試為基礎。每個開發階段的活動都與相應的測試活動是并行進行的。在需求階段進行系統（驗收）測試計劃和設計，除了能指導最終的系統測試和驗收測試執行外，其本身也是對需求的一個驗證過程。
通過閱讀軟件需求規格說明書，通常很難想象在特定環境下的系統行為。以功能需求為基礎或者從使用實例派生出來的測試用例可以使項目參與者看清系統的行為。雖然沒有在運行系統上執行測試用例，但是設計測試用例的簡單動作可以解釋需求的許多問題。如果你在部分需求穩定時就開始開發測試用例，那么就可以及早發現問題并以較少的費用解決這些問題。
設計概念性測試用例可以發現需求的錯誤、二義性、不可測性、遺漏等方面問題，為了獲得最大的效果，要求測試人員能夠獨立的去對需求進行思維，從一個不同于開發的角度上進行分析，這可能會是一個逆向的思維過程，在這個過程中，測試人員可能會設計出不同于需求的測試用例，而這最終可能會有兩個解釋：
Ø1、需求不完整或者需求有錯；
Ø2、遺漏了測試用例或者測試用例本身有錯誤；
不管是哪種解釋，最終肯定會提高整個系統的質量。但這個質量的獲得是通過冗余的人員來完成的，即：開發人員在對系統需求進行進一步分析的時候，有一組獨立的測試人員也在對系統需求進行獨立的思維，并從中獲取測試用例。盡管這兩種思維可能會出現重復，但由于思維的方式不同，最終肯定會使得需求變得更清晰和更完善。
0cm;text-align:justify;text-justify:inter-ideograph;line-height:170%;
mso-pagination:lines-together;page-break-after:avoid">第98貼【2004－9－9】：需求建模測試
需求的建模包括把需求轉換成圖形模型或形式化語言模型。需求的圖形化分析模型包括數據流圖（Data Flow Diagram，DFD）、實體關系圖（Entity-Relationship Diagram，ERD）、狀態轉化圖（State-Transition