軟件測試工程師如何做好需求分析(3)

　　再對日志文件這個元素進行分析，先看看日志文件有那些屬性，首先日志文件具有文件名，還有存放位置，文件格式，文件內容、文件創建時間、文件大小、文件權限等屬性。

　　需求描述中提到了每天要生成一個日志文件，從文件創建時間屬性來看，每天有24小時，到底從什么時候開始創建文件，從0點開始還是從幾點開始，沒有描述出來。

　　---從文件名屬性來看，如何命名日志文件，需求中也沒有提及。從存放位置屬性來看，日志文件存放在什么地方也沒有說明。是不是所有的日志文件都存放在應用程序同一子目錄下?

　　---從文件格式屬性來看，首先日志文件是以文本方式存儲還是以二進制格式存儲?再者，文件的內容是以何種格式記錄，每條訪問記錄間如何分隔，是以回車換行作為分隔還是以其他字符作為分隔?都沒有描述。

　　---從文件內容屬性來分析，除了存放上述描述的內容外，是否還可以保存其他內容，如果不能保存其他內容的話，需求描述中應該加上一句”日志文件中只能存儲訪問記錄信息，不得儲存其他記錄信息“。

　　---從文件大小屬性來分析，日志文件的大小有沒有限制?如果某天處于訪問高峰期，訪問特別多，是否需要將日志文件分拆成多個是一個需要考慮的問題。

　　---從文件權限屬性來分析，日志文件是否機器上的所有用戶都可以訪問還是只有特定的用戶可以訪問?文件是否需要設置權限是一個需要考慮的問題。

　　所以在對上述需求描述進行分析后，你會發現需求描述中有很多的問題沒有描述清楚。也許有人會有疑問，如果將所有上面說到的問題都描述出來的話會 不會工作量太大了?僅從需求分析的角度來講，需求規格描述得較細的話確實會增大很多工作量，但從整個開發過程來看，需求描述完整的話，后續階段的開發產生 歧義和遺漏的可能性就很小，實際上后續階段節約的時間會大大超過需求所多花的時間。

　　測試人員在需求階段應做哪些工作

　　1)首先，測試用例和測試工作本身是不斷完善的，在開發過程的初期，可以認為是需求階段，或者沒有規范需求工作的設計階段。如果有一個比較明確的需求文檔，可以在這個階段檢查完了需求文檔以后開始設計測試用例。這里，對于需求文檔的檢查主要是兩個方面：

　　---檢查需求文檔描述的正確性，測試人員要對于真實的系統所涉及的業務非常熟悉，比如一個簡單的財務軟件，那么測試人員本身就要對會計工作熟 悉，財務制度熟悉，在檢查需求文檔的時候不要迷信所謂的”都是用戶真實的需求“，這里存在兩個問題，一是用戶是否真的能正確地描述自己的需求，二是需求人 員是否真的能正確地理解需求。另外，還有一個用戶的需求是否符合行業規范的問題，如果不符合，那么是否要確認--這里存在一個隱患，用戶可能會在開發的后 期突然要求他們自己要走行業規范，讓你的需求變動，所以要事先明確好。

　　---檢查需求文檔描述的準確性。主要是考慮文檔中是否存在描述的模糊的地方，對于自己不清楚的問題一定要明確。這個時候是要保證需求的可測試性--我的意思是說保證需求是可以完全為測試工作服務的。

　　2)那么在檢查完了需求之后，就可以開始設計測試用例了，在這個階段因為沒有開始設計工作，所以對于測試用例的考慮不能僅僅從界面出發，而應該從業務角度出發，從實際業務出發來設計測試用例。

　　當然，這個階段所設計的測試用例是不夠完善的，只能涵蓋某些內容，但是我認為這些用例不僅僅全部都是功能測試用例，而且在整個項目中都將有效。 。

　　3)不過，當缺少需求文檔時，那就要發揮測試人員自己的能動性了，要主動的工作，而不是被動的等待。要自己嘗試著去熟悉實際業務，要盡量通過自己所能想到的方法來開展工作。

原文轉自：http://www.blogjava.net/qileilove/archive/2013/05/20/399492.html