網(wǎng)上很多類似需求分析的帖，還有少許高人掛名，無非都是寫些抓住顯性需求，深挖隱性需求之類云云，再問的深入點(diǎn)的話回答多半就是結(jié)合實(shí)際項(xiàng)目分析等等。有時候大道理看多了會讓人有深陷泥濘的感覺，在面對實(shí)際項(xiàng)目時就有點(diǎn)找不到出路。現(xiàn)在我就說點(diǎn)實(shí)際的，談?wù)勎以陧?xiàng)目中所遇到的問題。
在實(shí)際項(xiàng)目中，需求一般經(jīng)歷三個活動，即：評審、基線和變更；相對應(yīng)的測試活動有：評審、用例和測試，具體時間點(diǎn)的對應(yīng)分別是需求評審中、需求基線后和需求變更前后，當(dāng)然在需求變更完成后也會穿插一些用例修改工作。
我們先來看看測試三項(xiàng)活動中，哪一個環(huán)節(jié)最重要。我之前寫過這么一句話，叫做：方法影響用例，用例指導(dǎo)執(zhí)行，執(zhí)行顯示結(jié)果。當(dāng)然，方法自在人心，由此可見用例很重要。用例一般在需求基線后進(jìn)行編寫，但實(shí)際項(xiàng)目中由于項(xiàng)目緊急，PM就希望在需求基本邏輯穩(wěn)定后先同步進(jìn)行編寫用例，之后再根據(jù)需求變動而修改相應(yīng)的測試用例。在這里我比較贊賞的是用例前置這么一個好的提議，但是我個人又不太認(rèn)可這么一個做法。
首先根據(jù)缺陷放大模型，我們肯定是希望能夠?qū)⑺锌赡苡|發(fā)的缺陷給扼殺在搖籃里，即在需求評審的時候就提出相應(yīng)的問題，我們都知道，編寫測試用例是發(fā)現(xiàn)需求問題的一個重要手段，那么如果我們在需求基線后再去寫測試用例，那么就一定會有更多的需求問題會在開發(fā)那里衍生成為系統(tǒng)缺陷，所以我贊賞用例前置這個提議。
但是這樣一來，另外一個問題就擺上臺面了。基線前編寫好的測試用例在需求基線之后的修改量是十分巨大的，而且在某些需求大改動的地方，我們只有選擇重新編寫用例，因?yàn)闅v史用例會禁錮我們的思想導(dǎo)致測試點(diǎn)缺失。這不僅僅是一個工作量的問題，它同樣會誘發(fā)消極怠工情緒，這也是為什么我并不大認(rèn)可需求基線前就編寫測試用例。
有時候人真是一個矛盾綜合體啊，下面談?wù)勎业淖龇?。首先我需要充足的評審時間，因?yàn)槲倚枨笤u審的時候會看的相當(dāng)仔細(xì)，不僅關(guān)注基本的邏輯問題、措辭嚴(yán)謹(jǐn)問題，還關(guān)注角色權(quán)限、功能入口、返回界面、默認(rèn)排序、字段長度、字符限制、流程的合理性已經(jīng)相應(yīng)UI原型布局、交互、菜單層級之類的問題，將寫測試用例時所想的在評審的時候發(fā)揮出來，以便理清需求、盡早的發(fā)現(xiàn)更多的問題，這時候用例不會寫出來，但是在腦海里應(yīng)該有個大概的輪廓。用記事本記錄所有問題，時刻關(guān)注需求文檔的修改，并實(shí)時將最新版本需求文檔與之前版本的需求文檔在SVN中進(jìn)行對比，確保自己關(guān)心的問題得到修改，并記錄他人提出的修改意見在需求中的修改情況，并根據(jù)相應(yīng)的修改情況重新整理腦海中用例的映射集，在需求基線后就可以用最快的方式寫出最完整的測試用例。
合理的需求分析還應(yīng)該結(jié)合一個合理的功能點(diǎn)劃分，一般情況下我們功能點(diǎn)的劃分直接按照工作量來劃分，其實(shí)還應(yīng)該結(jié)合功能點(diǎn)之間的關(guān)聯(lián)程度、相應(yīng)需求人員的分工以及相應(yīng)測試人員的能力進(jìn)行劃分。具體原因細(xì)節(jié)我不愿在這過多累述，雖然在實(shí)行上有些困難，但是我覺得這個大致方向是可取的。