使用系統的同時，你應該具備行業知識。系統可能是針對某個專業領域設計的。例如一個期貨交易系統。你沒有基本的期貨知識，比如什么是持倉，什么是平倉。那么你如何能真正理解這個系統呢?當你有了業務知識以后，你會進行更深入的思考，來全面測試系統。
你還需要具備良好的軟件知識。比如某些控件的特性。單選框只能單選，不能多選。日歷控件是否可以手工輸入非法格式等。這些都是應具備的意識。
最后加上你的主觀判斷，你對系統的整體感覺怎么樣?是否越用越厭煩，為什么厭煩。系統的反應速度是否可以容忍，細節處理是否圓滑，等等。
在你認識系統的時候，可以使用一些方法，來幫助你更有效率地學習。比如可以畫一些流程圖。一圖勝萬語。同時，你也留下寶貴的文檔。當然，這個步驟中，你也要隨時注意保留和更新文檔，以備后用。
溝通：需求規格不一定非要以文檔的形式表現出來。軟件既然能做出來，那肯定是有需求的。而最清除需求的，一定是軟件的直接制造者，開發人員。開發人員自己知道需求，但一般不會主動和測試人員溝通。因此，測試一定要主動和開發人員溝通�？梢园才艜h，讓開發人員給測試人員介紹系統，并演示系統。讓測試人員對系統有一個整體了解。然后測試人員能進行更細致的測試。在進行細致測試的時候，一定會有更多不明確的地方。這時就需要利用自己的行業知識，計算機知識等，猜測一部分。不需要每個細節都去詢問開發人員。因為開發人員也有自己的工作，他們不希望花太多時間來給你解釋。
有些項目中，客戶會直接參與到項目組來。這時，測試人員在權限允許的情況下，可以和客戶進行溝通�？蛻裟堑脕淼男枨�，是最原始的需求。但是，客戶未必有良好的表達能力來描述希望的功能，也未必有計算機知識，因此不能描述出一些隱式的需求。在被允許的情況下，測試人員可以和客戶進行交流，不僅可以幫助客戶正確描述出真實需求，測試人員也能詳細了解需求。但是項目是要考慮成本的，客戶的期望是無限制的。在客戶提出需求以后，測試人員要先和PM或其他相關負責人協商后，才能將與客戶交流得來的需求，作為測試的依據。同事，第一時間告知相關開發人員最新的信息，也記錄成文檔。這時，你就將非文檔形式的需求，轉換為文檔形式了。至于文檔的格式，不一定要按照標準SRS的格式。因為它本身就不是個規范的SRS。以任何容易理解的方式，組織你的文檔。
有時候，會根本找不到可以溝通的人。不要奇怪，確實就是有這種時候。比如：
1. 測試一個開源軟件
2. 接到一個測試外包，但又沒有得到相關文檔，為了追求利益，還是接下了
3. 軟件項目組的部分人員已經聯系不上等等
這時候，一方面需要PM協調獲取相關資料，聯絡相關人員。另一方面，測試人員也可組織頭腦風暴，利用集體的智慧，共同探討和猜測軟件中的各個環節。也可以安排Bug Bash，讓盡可能多的人員參與隨機測試。一定會有人提出具有創造性的意見的。
在進行以上步驟的時候，利用良好的工具，能讓你事半功倍。我經常在使用的一個工具，就是Mindjet MindManager。這是一個很好的，幫助擴展思維的工具。它以分支的形式，來表現你的思維層次。你可以先列出個最基本的系統整體結構，然后逐步細化，增加分支。不要急于一次就將真個系統分析透徹，這是不可能的。你在進行以上步驟的時候，隨時會細化這個結構。當項目結束后，看看這個結構圖，簡直可以當作SRS來參考了!
文章來源于領測軟件測試網 http://www.kjueaiud.com/
