我是如何去了解需求的

2022-01-31 04:48:00 字數 1823 閱讀 6961

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

這個專案雖然提供了需求文件,但是長篇大幅的,內容也比較多,看著也容易犯睏。需求是必須要了解的,自己又是負責測試部分,那麼我必須要對整個**的整體和細節部分都要清楚。

我個人認為,在接觸需求的時候,不能夠死磕需求文件,死磕需求僅僅是去做功能,這是比較機械的。我們需要站在使用者的角度去分析和理解需求,把自己放在普通使用者的位置去感受和想象,而不是開發人員的角度。

我把文件看一遍,**也瀏覽了一遍,但是對**的功能和流程仍然比較模糊,心中也沒有乙個具體的概念。我在瀏覽整個專案的ui草圖時,突然間得到了靈感:整個**頁面元素比較多的頁面就二三十個,我何不把這些頁面做成截圖的形式,對照著需求文件,在上一一把需求給標註出來呢?

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

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

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

有些批註裡面的文字比較長,我就擷取部分關鍵的字,加重顯示,以後也不必每條都看完所有文字。了解需求後,我還得提供乙個測試文件,以測試這些功能。

功能

測試頁面

測試用例\用例步驟

bug

測試結果

1.功能1

url1. 用例一

a)b)

c)2.用例二

a)b)

c)1.bug1

2.bug2

3.bug3

(並提交到bug管理工具裡面,顯示bug原因,級別,截圖)

1.失敗

原因:2.成功

2.功能1

url1. 用例一

a)b)

c)2.用例二

a)b)

c)1.bug1

2.bug2

3.bug3

(並提交到bug管理工具裡面,顯示bug原因,級別,截圖)

1.失敗

原因:2.成功

3.功能1

url1. 用例一

a)b)

c)2.用例二

a)b)

c)1.bug1

2.bug2

3.bug3

(並提交到bug管理工具裡面,顯示bug原因,級別,截圖)

1.失敗

原因:2.成功

4.功能1

url1. 用例一

a)b)

c)2.用例二

a)b)

c)1.bug1

2.bug2

3.bug3

(並提交到bug管理工具裡面,顯示bug原因,級別,截圖)

1.失敗

原因:2.成功

由於是第一次擔任測試工作,文件也是隨心所欲,希望能有前輩提供一些建議,我能夠通過改進也運用到專案中(ps:公司沒有測試人員)

我是如何去了解需求的

半年沒有接觸.net了,最近公司又讓我參與半年前就已經啟動的乙個.net web專案,這次我負責一部分編碼和所有的測試。為了快速的融入團隊的開發工作中,我就必須盡快熟悉整個專案的環境。這個專案雖然提供了需求文件,但是長篇大幅的,內容也比較多,看著也容易犯睏。需求是必須要了解的,自己又是負責測試部分,...

如何了解需求?

大家都知道,做好乙個軟體專案的關鍵,在於需求的把握。那麼我們怎麼把握好需求了,我想每乙個設計師都可能有一套自己的理論和方法。我也不例外,這裡我就說說說我自己的方法吧。首先,大家都知道,了解需求的手段主要是通過面對面的交流。當然,也可以可以用郵件 甚至簡訊的方式來交流。但是我們都知道,這些手段都只是在...

產品經理如何了解使用者的需求?

今天特別想跟大家聊聊需求這件 小事 人人都是產品經理這句話說得不無道理,無論你從事哪個行業,都會提到 使用者需求 這個詞 尤其是對網際網路產品經理來說,需求是一切之始,先有了需求,才有了產品經理的一切職責的發揮空間,如果沒有需求,一切都無從談起,產品經理這個職位也就沒有了存在的價值。作為產品經理的你...