軟體測試，黑盒測試能否發現需求的錯誤？

1樓：Arnold

可以，基本上在公司，你所經歷的第乙個階段就是需求評審。在需求評審的過程中，你就要盡力發現需求文件中的錯誤。之後你憑什麼需求之後下來肯定要寫測試計畫，或者說是有你的領導來編寫測試計畫。

然後按照測試計畫來編寫測試用例。編寫完測試用例之後，就執行這些測試用例去發現軟體的錯誤。那麼很顯然，首先按照敏捷模式來說，無論是測試工程師還是開發任工程師，都是基於這份需求去展開下來的工作。

所以開發完成之後，我們肯定要按照需求，然後編寫出來用例。編寫用例的過程中，有可能就會發現需求不通的一些地方。之後，如果這個期間沒有發現錯誤，那麼在執行的階段你也會發現一些。

有可能發現的需求錯誤。所以你在這問這個問題的時候，我覺得是你還是沒理解黑河功能和需求之間的關聯關係，他倆是強關聯關係。並且我們在提單的過程中發現bug型別裡邊兒有設計錯誤，其實就是需求相關的錯誤。

2樓：測試凱哥

題主，可以很負責任的告訴你：黑盒測試發現需求的錯誤是完全沒有問題的。

按照黑盒測試的定義：就是在程式的介面處，按照軟體的要求就行操作，輸入符合要求的資料，檢查是否能夠得到預期設計的結果。

在這個過程中，如果按照需求描述的進行操作，發現沒有獲得期望的結果。那其實就是需求不完善或者錯誤的表現，因為沒有將可能出現的情況全都考慮進去。

其次，在這裡面，有乙個非常重要的關於需求的認識。我們通常認為的需求是什麼呢？就是明文規定的，以文字的形式展現出來的要求，但是，有一點可能會被很多人給忽略掉，那就是：

隱性需求。這是相對於剛剛提到的那種需求來說的。

因為我們都知道，有一種缺陷是：需求規格說明書中沒有提及，但是應該實現，而軟體並沒有實現的功能。

所以總的來說，黑盒測試，如果做好了，可以很大程度發現需求中不足的地方，並且促進這些不足改進。

3樓：測試之心

先上答案，黑盒測試能發現需求的錯誤。

而且，這正是黑盒測試的強項。

先大膽解釋一下你這裡說的【需求】的錯誤，應該說的是諮詢人員或者產品經理從使用者那裡獲取到的需求。從眾多專案經驗看，很多時候，使用者自己都沒想明白自己想要什麼，更不要說我們獲取到的需求了，我們開發測試的東西經常都是經過若干輪調整，甚至推翻重做，最後才能符合使用者的業務場景。

黑盒測試常說的一句話，站在使用者的角度測試；黑盒測試人員要深刻的理解客戶的業務，業務場景，想象著自己是客戶的話，如何來使用我們的被測系統，這種時候往往能發現【需求】不合理之處，或者設計考慮不周之處，這正是黑盒測試的發光點。

其實測試人員不只能在測試階段發現需求或設計的錯誤，往往在需求評審階段，也能發現這種錯誤。這也是為什麼很多大廠都提倡測試盡早介入，就是希望測試人員能盡早的發現這類錯誤。因為如果在測試階段才發現這類錯誤，如果需要推翻重來的話，那麼前期開發的投入就都是浪費了。

推翻重來的代價傷不起啊~~~

4樓：阿遠

建議問問題加問題背景。否則會有很多歧義，不確定具體是問什麼。

首先只是從字面意思回答。

什麼叫需求的錯誤，是指設計的不合理?還是指有些異常場景沒有考慮到?

如果需求的錯誤指的是我上面的兩種定義。其實我很難理解為什麼要把黑盒測試和能不能發現需求的錯誤聯絡在一起。

應該說是在黑盒測試的第一階段，需求分析的過程中，是比較容易發覺「需求的錯誤」。

第二種情況，我猜你想問的是，作為乙個黑盒測試的測試人員有沒有權力對產品的需求提出需求的改進建議。

當然是有建議權的。一般會有個需求評審，就是為了給產品提建議的。測試的時候會提優化單，也是給產品提建議。

但是產品接不接受就是另外乙個問題了。