相信很多人跟我一樣有過這樣的困惑，那就是在需求階段我們測試人員應(yīng)該做些什么？下面就將看過的一篇文章貼出來與大家一塊分享。
首先，測試用例和測試工作本身是不斷完善的，在開發(fā)過程的初期，可以認為是需求階段，或者沒有規(guī)范需求工作的設(shè)計階段。如果有一個比較明確的需求文檔，可以在這個階段檢查完了需求文檔以后開始設(shè)計測試用例。這里，對于需求文檔的檢查主要是兩個方面：
1.檢查需求文檔描述的正確性，愚以為測試人員要對于真實的系統(tǒng)所涉及的業(yè)務(wù)非常熟悉，比如一個簡單的財務(wù)軟件，那么測試人員本身就要對會計工作熟悉，財務(wù)制度熟悉，在檢查需求文檔的時候不要迷信所謂的“都是用戶真實的需求”，這里存在兩個問題，一是用戶是否真的能正確地描述自己的需求，二是需求人員是否真的能正確地理解需求。另外，還有一個用戶的噓氣是否符合行業(yè)規(guī)范的問題，如果不符合，那么是否要確認——這里存在一個隱患，用戶可能會在開發(fā)的后期突然要求他們自己要走行業(yè)規(guī)范，讓你的需求變動，所以要事先明確好。
2.檢查需求文檔描述的準確性。主要是考慮文檔中是否存在描述的模糊的地方，對于自己不清楚的問題一定要明確。這個時候是要保證需求的可測試性——我得意思是說保證需求是可以完全為測試工作服務(wù)的。
那么在檢查完了需求之后，就可以開始設(shè)計測試用例了，愚以為，在這個階段因為沒有開始設(shè)計工作，所以對于測試用例的考慮不能僅僅從界面出發(fā)——雖然RUP中對于用例的要求有這一項。因而測試用例的設(shè)計應(yīng)該從業(yè)務(wù)角度出發(fā)，從實際業(yè)務(wù)出發(fā)來設(shè)計測試用例。當然，在測試用例的描述時，要盡量考慮怎樣同應(yīng)用程序脫離開而仍然具有有效性。
當然，這個階段所實現(xiàn)的測試用例是不過完善的，只能涵蓋某些內(nèi)容，但是我認為這些用例不僅僅全部都是功能測試用例，而且在整個項目中都將有效。
不過，當缺少需求文檔時，那就要發(fā)揮測試人員自己的能動性了，要主動的工作，而不是被動的等待。要自己嘗試著去熟悉實際業(yè)務(wù)，要盡量通過自己所能想到的方法來開展工作。