半年沒有接觸.net了，最近公司又讓我參與半年前就已經啟動的一個.net web項目，這次我負責一部分編碼和所有的測試。為了快速的融入團隊的開發工作中，我就必須盡快熟悉整個項目的環境。

這個項目雖然提供了需求文檔，但是長篇大幅的，內容也比較多，看著也容易犯困。需求是必須要了解的，自己又是負責測試部分，那么我必須要對整個網站的整體和細節部分都要清楚。
我個人認為，在接觸需求的時候，不能夠死磕需求文檔，死磕需求僅僅是去做功能，這是比較機械的。我們需要站在用戶的角度去分析和理解需求，把自己放在普通用戶的位置去感受和想象，而不是開發人員的角度。

我把文檔看一遍，網站也瀏覽了一遍，但是對網站的功能和流程仍然比較模糊，心中也沒有一個具體的概念。我在瀏覽整個項目的UI草圖時，突然間得到了靈感：整個網站頁面元素比較多的頁面就二三十個，我何不把這些頁面做成截圖的形式，對照著需求文檔，在圖片上一一把需求給標注出來呢？

我以下面這張截圖里面的頁面為例。

大體一看，這個頁面按鈕也不少，而且很多按鈕元素比較隱秘，很難一眼看出來。如果對照需求去看，或許這次自己了解了，但是下次可能因疏忽而忘記某些頁面元素和功能，通過在圖上進行簡略的標注，能夠得到很直觀的需求，而且條目也非常清晰。

對照文檔中的需求在圖上標注需求得到的結果如下，在測試這些功能時我也不必對著word文檔去一一驗證，看圖就能了解需求部分了。

有些批注里面的文字比較長，我就截取部分關鍵的字，加重顯示，以后也不必每條都看完所有文字。了解需求后，我還得提供一個測試文檔，以測試這些功能。

功能	測試頁面	測試用例\用例步驟	Bug	測試結果
1.功能1	url	1. 用例一 ?? a) ?? b) ?? c) 2.用例二 ?? a) ?? b) ?? c)	1.bug1 2.bug2 3.bug3 (并提交到bug管理工具里面，顯示bug原因，級別，截圖)	1.失敗 原因： 2.成功
2.功能1	url	1. 用例一 ?? a) ?? b) ?? c) 2.用例二 ?? a) ?? b) ?? c)	1.bug1 2.bug2 3.bug3 (并提交到bug管理工具里面，顯示bug原因，級別，截圖)	1.失敗 原因： 2.成功
3.功能1	url	1. 用例一 ?? a) ?? b) ?? c) 2.用例二 ?? a) ?? b) ?? c)	1.bug1 2.bug2 3.bug3 (并提交到bug管理工具里面，顯示bug原因，級別，截圖)	1.失敗 原因： 2.成功
4.功能1	url	1. 用例一 ?? a) ?? b) ?? c) 2.用例二 ?? a) ?? b) ?? c)	1.bug1 2.bug2 3.bug3 (并提交到bug管理工具里面，顯示bug原因，級別，截圖)	1.失敗 原因： 2.成功

?

由于是第一次擔任測試工作，文檔也是隨心所欲，希望能有前輩提供一些建議，我能夠通過改進也運用到項目中（PS:公司沒有測試人員）

轉載于:https://www.cnblogs.com/psunny/archive/2010/03/04/1678611.html

總結

以上是生活随笔為你收集整理的我是如何去了解需求的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。