軟件生命周期中，需求是整個項目的源頭。俗話說良好的開端是成功的一半，但是，不是每個項目都能遵從流程，花太多時間在
需求分析上，而把精力投入到代碼的編寫中。這可能導(dǎo)致什么問題呢？開發(fā)和
測試對需求理解都不充分，開發(fā)出來的功能與實(shí)際需求不符，測試要么憑自己的經(jīng)驗一步一步發(fā)掘潛藏的功能點(diǎn)，把項目往良性的軌道上引，要么就聽從開發(fā)的腳步，亦步亦趨。那么測試人員要如何在需求不明確或者文檔不全的情況下著手測試才能保證軟件的質(zhì)量呢？
一、參考同類型的網(wǎng)站：一般情況下，我們測的系統(tǒng)總會有原型可參考，比如我目前測的訂票系統(tǒng)，就可以參照攜程，主要功能基本一樣，細(xì)節(jié)可能有出入，攜程上操作一遍，然后再看看它提供的幫助，再有可以網(wǎng)上搜索資料，參考下行業(yè)的基礎(chǔ)知識，這都是收集需求的方法，這樣子下來也基本對訂票系統(tǒng)也就有個認(rèn)識了，然后與開發(fā)經(jīng)理確認(rèn)，再和開發(fā)一起把功能定下來，該改的改，該修的修，BUG一點(diǎn)不含糊。弱弱的吐槽下，這個項目的開發(fā)居然都不知道有需求說明書，雖然寫的基本沒太大的價值。
二、根據(jù)經(jīng)驗和常識判斷：做項目多了就知道，萬變不離其宗，系統(tǒng)不一樣，思路可以套用，所謂的學(xué)以致用，舉一反三。我上個項目做的銀行測試，我照樣可以測現(xiàn)在的訂票系統(tǒng)，就在一個字：活。有需求照需求測，沒有需求找參照，說個例子吧，訂票系統(tǒng)中有個功能是積分，需求上就一句話提到有積分功能，怎么測？難道看到有這個功能就算過了？我后來就參照了淘寶的積分抵扣，下單了積分就被臨時凍結(jié)了，取消訂單又釋放出來，但開發(fā)在做這個功能的時候也沒有跟他們的頭溝通，直接是要等支付完成后才扣除積分，這導(dǎo)致一個什么問題呢，可以重復(fù)使用積分，如果真上線使用了，說不定會造成不小的經(jīng)濟(jì)損失的。類似這樣的問題太多太多，你總可以從一些地方獲得參照，或者說是靈感，項目測的怎么樣，跟測試人員的素養(yǎng)有很大的關(guān)系，尤其是在沒有規(guī)范的流程下。
三、溝通：毋庸置疑，這太重要了，需求不一定在文檔中寫出來，但道理上開發(fā)肯定知道需求的，但一般不會主動和測試溝通，因此，我們作為測試就要主動和開發(fā)人員溝通，不僅可以對系統(tǒng)有更深的了解，還可以對項目進(jìn)度有把握。
四、多和同事討論