跟著師傅做了幾個日常，參加了幾次需求的討論，漸漸感覺到做需求還是需要花費不少精力的。如果說對原來的業(yè)務非常熟悉，相對來說做起來就輕松一些，而要是從來都沒接觸過這塊內容，就會感覺有點像丈二和尚摸不著頭腦：知道用戶想要什么，但是卻不知道如何跟現(xiàn)有的系統(tǒng)更好的結合起來，我們到底能夠提供什么？用戶的需求是否合理？做需求分析，不能跟著用戶的感覺走，因為這樣的話，只能是用戶說一你做一，而如果用戶不能很好的提煉需求的時候，我們就會進入一個死循環(huán)了。在和用戶討論的時候，我們首先要知道用戶為什么會提出這個需求？能夠幫助他解決什么樣的問題？希望達到什么樣的效果？并不是所有的用戶都能正確的表達自己所想要的東東的。
一個比較典型的例子：最近跟一個營銷平臺的PD在聊用戶一般會怎么樣來提需求的時候，談到曾經做過的一個營銷活動的推廣需求，運營人員為了推廣某一項活動，往往會比較糾結在頁面上這個按鈕應該如何放置，需要新增加幾個顯示字段才能達到這次活動的效果，那這是用戶最根本的需求嗎？不是，實際上他真正需要的是應該給他提供幾個維護活動的界面：類似什么樣的活動時應該出現(xiàn)下拉的選擇框進行維護，什么樣的活動應該給他提供幾個選項項。他們習慣上只會關注到現(xiàn)在他需要什么樣的功能，在下次需要新的功能的時候，又會來提新的需求，所以對于類似這樣的問題，PD的作用就顯現(xiàn)出來了：透過現(xiàn)象看本質，要善于抓住用戶描述問題的過程，引導他拋出隱含在這個需求背后的衍生內容，復述一下用戶所說的目前存在的問題，了解一下用戶可能會用的方式有哪些？并說明對流程的理解，再結合流程中的不明確點設計要詢問的問題，并將客戶的反饋記錄下來，然后與客戶確認一下是否有遺漏的內容，增加這些屬性是否就都已經覆蓋了他所想要的所有功能了？
我想這其實也就是需求分析的價值所在吧。這步工作如果沒有做好，往往就會導致考慮得不夠充分而引起新的需求變更，甚至關系到開發(fā)出來的軟件產品能否得到用戶的認可，客戶能否真正運用我們的產品幫助他們解決業(yè)務或管理上的問題。當然要做到這一點，也不是一兩天就能搞定的，需要一個逐漸積累的過程，學會如何巧妙的向客戶提問也是一門非常值得我們去思考的學問。業(yè)務方在需求的提出方面起著主導作用，但PD必須要能夠對客戶的需求進行過濾，要在非常了解原有系統(tǒng)功能，架構設計的基礎上來給出建議，這樣才有可能在需求階段規(guī)避掉一些具有比較大業(yè)務風險、技術風險的需求。
我們與運營方討論的過程中會收集到一些新的需求，回來后一般需要對用戶繁雜的業(yè)務進行流程的提取，把那些分布在各個部門的同一種業(yè)務提取出來進行初步的整理和分析， 把大致的功能點整理一下，遇到不明確的、有疑問的再咨詢師傅，必要的時候還要跟開發(fā)進行討論實現(xiàn)上是否可行。整體的思路是這樣的：業(yè)務的目標是什么？用戶需要怎么做才能完成業(yè)務目標？系統(tǒng)要能為用戶提供哪些支持？系統(tǒng)必須符合哪些規(guī)則？展現(xiàn)的形式可以包括：用例的分析，業(yè)務流程和活動輸入輸出的分析，業(yè)務操作規(guī)則的整理，通過確定用戶的任務，每項用戶任務的步驟，定義對業(yè)務具有重要意義的數(shù)據(jù)并確定已有的邏輯關系。在確保業(yè)務描述基本沒什么問題的前提下，邀請開發(fā)和業(yè)務方進行評審，并對業(yè)務流程上不對的地方進行修改。經過幾次來回的交流，最終才能取得較全面的需求。需求分析關注的目標應該是“做什么”，而不是“怎么做”，所以在描述需求的時候，表述的方式應該是“實現(xiàn)什么”，而不是“如何實現(xiàn)”。
做需求分析的過程，其實跟我們的測試分析工作有非常相似之處：我們在測試活動中，也都是從理解業(yè)務的需求開始的，首先需要明確測試需求（What），才能決定怎么測（How），通過了解這個項目具體是做什么的，完成一個什么樣的業(yè)務，哪些功能是最常用的？哪些功能是重點？還有就是用戶在處理實際業(yè)務時都要作些什么，多個業(yè)務之間的先后順序是怎樣的，用戶在處理業(yè)務時對于哪些地方有特別的要求，等等。這部分規(guī)則，就是我們的測試需求中最基本的一部分。測試需求不明確，只會造成獲取的信息不正確，無法對所測項目有一個清晰全面的認識，活在自己世界里的人是可悲的。
測試需求并不等同于軟件需求，它是以測試的觀點根據(jù)項目需求整理出一個checklist，作為測試該項目的主要工作內容。根據(jù)所測的功能點進行分析、分解，從而得出著重于某一方面的測試，如界面、業(yè)務流、接口、數(shù)據(jù)等等。理解項目需求，需要從整體到局部，從局部到細節(jié)。測試人員不要總只了解自己模塊的內容，要先從整個項目的業(yè)務流程入手，然后再到自己的功能模塊，這樣的好處是，測試人員了解上下游的交易功能，更加的能夠了解業(yè)務的實現(xiàn)方法。經過一番狂轟亂炸式的深入理解之后，再將自己負責的模塊有條有理的整理出來，然后講解給項目組成員，這樣也有利于模塊之間的整合理解，再由他們提出各種各樣的問題，若能很輕松的回答出各種各樣的問題，說明你對項目的理解已經很到位了，而如果在提問的過程中有很多的問題，都是你之前沒有考慮到的，那說明測試的需求分析做的還不夠到位，這時你就需要好好總結一下，是因為自己經驗方面的問題，還是由于其他方面的原因。總結起來測試需求的內容大致如下：
1、理解系統(tǒng)的流程：整理出業(yè)務的常規(guī)邏輯，一項一項列出各種可能的測試場景，同時借助于需求文檔資料，來確定該場景應該導致的結果
2、進行功能的分解：系統(tǒng)包含哪些主要的功能，每個功能的期望值是什么；各個模塊處理哪些業(yè)務，各子系統(tǒng)模塊之間的數(shù)據(jù)接口關系，基礎數(shù)據(jù)從哪里進入，通過哪些處理生成哪些結果等等。在做完以上步驟之后，將業(yè)務流中涉及的各種結果以及中間流程分支回顧一遍，確定是否還有其他場景可能導致這些結果，以及各中間流程之間的交互可能產生的新的流程，從而進一步補充與完善測試需求。
以上只是個人對如何進行需求的捕獲以及怎么樣做好需求理解的一些看法，同時也是對我自己前段時間的工作做的一點梳理，希望大家能多多交流，共同進步，把我們的測試工作做的更好。