需求評審時,測試應該做什麼

2021-06-11 08:19:06 字數 2583 閱讀 3020

1樓:

1.需求評審前準備

完整性審查

應保證測試需求能充分覆蓋軟體需求的各種特徵重點關注功能要求、資料定義、介面定義、效能要求、安全性要求、可靠性要求、系統約束等方面,同時還應關注是否覆蓋開發人員遺漏的、系統隱含的需求。

準確性審查

應保證所描述的內容能夠得到相關各方的一致理解各項測試需求之間沒有矛盾和衝突,各項測試需求在詳盡程度上保持一致,每一項測試需求都可以作為測試用例設計的依據。

2.需求評審會議中

帶著列出的疑問點向產品、開發溝通自己對產品的疑惑和質疑點,多提幾個為什麼?比如:

1.如何實現?

2.資料獲取**?

3.超出預期的資料怎麼處理?

4.快取處理機制如何?

5.資料儲存何處?

6.邏輯由前端處理還是後端服務?

7.後端服務邏輯是否跟第三方關聯?

知道自己應該做什麼了嗎?如果知道了,那就去做吧!如果想提高,學習更多軟體測試知識,黑馬程式設計師就可以!

2樓:巴宛凝

對於一條軟體需求或著一個軟體需要實現的特徵,必須存在一個可以明確預知的結果,並且可以通過設計一個可以重複的過程來對這個明確的測試結果進行驗證。說得具體一點,就是要保證所有的需要實現的需求都可以用某種方法來明確的判斷是否符合需求文件的描述,如果對於某條需求或某個特徵無法通過一個明確的方法來經行驗證,或者無法預知的結果,那末就意味這這條需求存在缺陷。

作為一個軟體測試人員,需求評審應該做些什麼?

3樓:願為你瘋癲

需求評審

的參與人員:領導+產品經理+專案經理+開發人員+測試人員+運維人員等需求評審是一個對軟體需求進行確認和評估的一個活動,測試人員雖然不是主角,但要積極的參與。

評審前: 認真的閱讀需求說明,業務流程圖等資料;整理出測試點,一定要突出業務邏輯

評審過程中:對於需求是否合理,是否可以實現,咱們看著產品和開發人員討論即可。

咱們要關注的:

1. 主要關注需求是否具有可測試性,也就是需求是不是存在自相矛盾和二義性。

2. 還要分析目標使用者的操作習慣。

3. 對需求存在疑惑,或者理解不是很透徹,一定要問清楚4. 估算測試過程需要的時間和資源,這也最難把控的。(往往會變化)評審後,提交工作計劃,突出時間節點和產物。

以上內容均來自黑馬程式設計師社群

4樓:匿名使用者

需求評審對於軟體測試人員來說就像是最初的“產品測試”,在理解的基礎上發現產品設計上缺陷,其中包括邏輯錯誤,功能缺失,細節問題等等,這樣就會有效的在前期規避很多後期開發中產生的bug,減少了很多後期返工的成本。可偏偏需求評審往往是最不重視的一環,甚至可以說是沒有這個環節,追其原因無非因為專案時間緊迫或者覺得沒有必要,其實這是本末倒置和得不償失的。

產品需求作為程式的源頭,只有控制好最開始部分,才不會到最後去亡羊補牢。我有過很多血的教訓,所以才深深的體會到需求評審的重要性。

說了需求評審的重要性,接著就來談談如何進行需求評審,一般還是分為3步:

第一步就是要完全讀懂產品需求,這個過程只需要理解而不是去挑刺,因為要明白這個需求的目的是什麼,為什麼這樣做,怎麼做等等,只有在理解的基礎上才能去發現問題,而不是一知半解的去挑毛病,有些需求設計的是不合理,但也許有其特殊的用意,或者只是沒有更好的方案,不能為了挑毛病而去挑。

第二步就是分析和找問題;這就有點類似寫測試用例的時候設計測試方案了,把邏輯梳理出來,看看有沒有不對或者遺漏的點,整理出來反饋給產品經理。除了考慮有問題的地方,沒問題的地方也是需要分析的,比如有些設計非常合理,但會增加**的複雜度或者不利於後續的擴充套件和修改,同時也可能會給測試帶來成倍的工作量,這些也是需要指出的,因為測試要考慮的東西一定要比產品經理多,使用者使用習慣,程式複雜度,與線上系統的相容性等等,不然直接讓產品經理做測試不就好了嗎?

第三步就是細節問題的糾正,可以是介面,可以是文字,開發一般都是複製黏貼或者照著樣子畫葫蘆,這些小問題後期其實也可以測試出來的,但其鍋不在於開發,早點發現問題早點解決也是好事一件,至少不用提bug走一套bug處理流程了,也算給大家省點工作量,積少成多也是極好的。

當然需求評審能解決的問題也是有限的,一方面計劃往往趕不上變化,中間會有部分需求的改動,另外一方面有些深層次的問題只有在測試之後才會發現。但無論如何對於測試來說還是非常有必要的,如果能重視起來不僅僅對專案的效率提高不少,而且也能讓後期測試壓力減小,何樂而不為呢?

拿到一個新專案的時候,測試人員如何參加需求評審的工作?

5樓:

需求分析階段,測試人員需要做的工作:1、理解需求,參與稽核需求文件2、理解專案的目標、限制,瞭解使用者應用背景3、編寫測試計劃4、準備資源

6樓:year情乘雲姐

1. 首先我們會獲取到產品下發的需求說明和原型, 提前理解記錄一下問題(邏輯錯誤,暫未實現,需求不明)

2. 然後參加需求評審會議 -- 主要有產品負責講解 -- ui/前後端開發/測試 --專案經理都會參加

3. 作為測試人員主要是站在使用者角度,需求講解後提出問題, 共同討論, 明確需求,統一理解

4. 好處就是提前介入測試工作,已靜態評審的方式, 儘早發現產品問題,這也是我聽了黑馬程式設計師的公開課裡面講的

需求評審時測試人員需要關注哪些方面

1.完整性審查 應保證測試需求能充分覆蓋軟體需求的各種特徵,重點關注功能要求 資料定義 介面定義 效能要求 安全性要求 可靠性要求 系統約束等方面,同時還應關注是否覆蓋開發人員遺漏的 系統隱含的需求 2.準確性審查 應保證所描述的內容能夠得到相關各方的一致理解,各項測試需求之間沒有矛盾和衝突,各項測...

演講時要做什麼動作,演講時應該做什麼動作

肢體語言的作用通常被誇大了。在談論肢體語言時,首先關注的是避免不恰當的肢體語言!比如眼神飄渺 手足無措 身體搖晃 頻繁走動等。所謂正確的肢體語言無非是四個方面 眼神 看著觀眾,看不同的觀眾 包括表情自然站姿 直 穩 手勢 自然,同時避免抱胸 插兜 背後 移動 有必要時才適當移動,比如進入不同章節,或...

耳鳴應該做什麼檢查,耳鳴該做什麼檢查

耳鳴又可根據其特徵分為持續性耳鳴與節律性耳鳴持續性耳鳴可有單一頻率或多頻率聲調的混合,多為主觀性耳鳴。節律性耳鳴多與血管跳動一致偶爾與呼吸一致,耳鳴的頻率較低。耳鳴患者也要注意取捨。咖啡因和酒精可使耳鳴症狀加重。偏愛甜食者容易肥胖,患糖尿病機率高,容易產生和糖尿病有關的耳鳴。出現耳鳴需要做的檢查 1...