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