需求不明確的情況下如何做測試
軟件生命周期中，需求是整個周期的源頭。良好的開端，是成功的一半。需求的重要性自然不言而喻。但是，在很多企業中，並沒有對需求引起足夠的重視。原因並不是PM們不知道需求的重要性，而是商業競爭中不得不裁剪某些看似不能獲得很大利益的步驟。
什么是需求？很多PM和開發人員都未必真正考慮過這個問題。IEEE對需求有以下兩種定義的方式。
1. 解決用戶問題或達到用戶目標需要具備的條件或能力
2. 遵守合同、協議、規范或其他要求
然后用規范的文檔描述出來，就成了我們熟悉的SRS。
我們常說的需求，其實並不是我們認為的SRS。SRS應該叫做需求規格說明書。那需求是什么呢？與需求規格有什么區別？
需求：對要實現的功能的粗略描
需求規格：對需求的精確定義
我們知道，在軟件開發過程中，只有得知了需求的精確定義，才能開展工作。比如功能方面，編輯框能支持多少位字符。性能方面，時間和容量規定等。當然還包含其他非功能，性能方面的定義。
除了以上所說的需求，對於測試人員，還必須有測試需求。這個環節，很少有企業會重視。測試需求分為2方面：
需要測試哪些方面
軟件是否可測，需要增加哪些開發需求
其中第一條，很多企業都列到了測試計划中，這也可以，沒有規定一定要放到哪個文檔里。但是對於第二條，可以說幾乎沒有多少企業去做。
接下來，在沒有明確需求，需求規格，測試需求的情況下，我們怎么去做測試呢？現在很多企業，其實就是在這種情況下做項目的。
當測試人員接手一個項目后，第一件事情一定是想了解這個系統的功能，背景，架構。於是，馬上就會想得到需求文檔。但結果往往是失望的，根本沒有文檔，或者文檔根本不具備參考價值。此時不必太失望，因為這種情況實在是太常見啦。這時，請試着從以下幾個步驟着手。
查閱文檔：文檔是最具權威的，也是記憶最長久的。有時，我們的項目可能是在原有產品的基礎上，進行版本升級。這時，先去找找，有沒有原有版本留下的需求，或者是用戶手冊等文檔。從這些文檔中，了解項目的背景，系統的基本功能。這對了解新項目是有很大好處的。並且，在產品升級的項目中，驗證老版本的功能在新版本中是否正常，也是一個必要的工作。可以先參考老版本的相關文檔，設計新版本中的用例。
也有時，我們的項目是一個行業項目，比如金融項目。我們可以參
考一些行業知識的書籍，文檔。這對理解系統也有很大的好處。
實在沒有文檔，那只好暫時跳過這一步驟了。
在進入下一步驟之前，你可能得到了一些相關文檔，也可能什么也沒得到。無論如何，你可能對系統已經有了一些了解。這時，請記錄下來，寫成文檔。無論是對自己，還是對別人，在以后都可能極有參考價值。試想一下，如果前人已經給你留下了這些文檔，你是否可以輕松很多？還要注意及時更新你的文檔。因為你對系統的理解，隨時都在變化着，一定要保證你的文檔和當前你對系統的理解是一致的。
試着使用系統，根據經驗和常識猜測：既然沒有需求，那可以推測，該項目的管理一定是很糟糕的，對測試也不會投入很大的成本。因此，測試人員一般都是在編碼完成后才進入項目。這時，應該已經可以看到成型的系統了。在沒有需求的情況下，試着先“玩”一下系統吧。在這過程中，你應該對系統有可更深入的認識，在上一階段中，你可能留下很多疑惑或是猜測，這時應該能排除一部分了。
使用系統的同時，你應該具備行業知識。系統可能是針對某個專業領域設計的。例如一個期貨交易系統。你沒有基本的期貨知識，比如什么是持倉，什么是平倉。那么你如何能真正理解這個系統呢？當你有了業務知識以后，你會進行更深入的思考，來全面測試系統。
你還需要具備良好的軟件知識。比如某些控件的特性。單選框只能單選，不能多選。日歷控件是否可以手工輸入非法格式等。這些都是應具備的意識。
最后加上你的主觀判斷，你對系統的整體感覺怎么樣？是否越用越厭煩，為什么厭煩。系統的反應速度是否可以容忍，細節處理是否圓滑，等等。
在你認識系統的時候，可以使用一些方法，來幫助你更有效率地學習。比如可以畫一些流程圖。一圖勝萬語。同時，你也留下寶貴的文檔。當然，這個步驟中，你也要隨時注意保留和更新文檔，以備后用。
溝通：需求規格不一定非要以文檔的形式表現出來。軟件既然能做出來，那肯定是有需求的。而最清除需求的，一定是軟件的直接制造者，開發人員。開發人員自己知道需求，但一般不會主動和測試人員溝通。因此，測試一定要主動和開發人員溝通。可以安排會議，讓開發人員給測試人員介紹系統，並演示系統。讓測試人員對系統有一個整體了解。然后測試人員能進行更細致的測試。在進行細致測試的時候，一定會有更多不明確的地方。這時就需要利用自己的行業知識，計算機知識等，猜測一
部分。不需要每個細節都去詢問開發人員。因為開發人員也有自己的工作，他們不希望花太多時間來給你解釋。
有些項目中，客戶會直接參與到項目組來。這時，測試人員在權限允許的情況下，可以和客戶進行溝通。客戶那得來的需求，是最原始的需求。但是，客戶未必有良好的表達能力來描述希望的功能，也未必有計算機知識，因此不能描述出一些隱式的需求。在被允許的情況下，測試人員可以和客戶進行交流，不僅可以幫助客戶正確描述出真實需求，測試人員也能詳細了解需求。但是項目是要考慮成本的，客戶的期望是無限制的。在客戶提出需求以后，測試人員要先和PM或其他相關負責人協商后，才能將與客戶交流得來的需求，作為測試的依據。同事，第一時間告知相關開發人員最新的信息，也記錄成文檔。這時，你就將非文檔形式的需求，轉換為文檔形式了。至於文檔的格式，不一定要按照標准SRS的格式。因為它本身就不是個規范的SRS。以任何容易理解的方式，組織你的文檔。
有時候，會根本找不到可以溝通的人。不要奇怪，確實就是有這種時候。比如：
1. 測試一個開源軟件
2. 接到一個測試外包，但又沒有得到相關文檔，為了追求利益，還是接下了
3. 軟件項目組的部分人員已經聯系不上等等
這時候，一方面需要PM協調獲取相關資料，聯絡相關人員。另一方面，測試人員也可組織頭腦風暴，利用集體的智慧，共同探討和猜測軟件中的各個環節。也可以安排Bug Bash，讓盡可能多的人員參與隨機測試。一定會有人提出具有創造性的意見的。
在進行以上步驟的時候，利用良好的工具，能讓你事半功倍。我經常在使用的一個工具，就是Mindjet MindManager。這是一個很好的，幫助擴展思維的工具。它以分支的形式，來表現你的思維層次。你可以先列出個最基本的系統整體結構，然后逐步細化，增加分支。不要急於一次就將真個系統分析透徹，這是不可能的。你在進行以上步驟的時候，隨時會細化這個結構。當項目結束后，看看這個結構圖，簡直可以當作SRS來參考。