需求測試

Question

我剛剛完成我的軟件系統的實施，現在我必須記錄它是否滿足其要求。我應該包括哪些信息，我應該如何佈置它？

我最初的功能性和非功能性需求是在一個兩列的表，看起來是這樣的：

• FN-01的系統應該允許用戶 私人信息發送到每個 等。
• NFN-03設置/配置 窗體應包含大多數字段的合理默認值 值。

Answer 1

一個接一個地列出需求編號和需求行，然後用文本和/或截圖來證明它是這樣做的。

用粗體左邊的要求編號，然後將要求文本標籤和斜體。將校樣文本/屏幕截圖與需求文本對齊，只留下需求編號的左欄。 EG：

REQ-1  italicized requirement text 

      text discussing how the software has 
      fulfilled the requirements, possibly 
      with a picture: 

      ----------------------- 
      |      | 
      |      | 
      |      | 
      |      | 
      |      | 
      ----------------------- 

REQ-2  italicized requirement text 

      etc... 

你應該組成章節或部分基於邏輯方案領域，並開始與一個對整個項目區如何滿足需求的Blurb的部分或章節（是普通

Answer 2

我會繼續它的簡單，並添加下列：

• 交付滿意的要求 - 一個下拉含是，否列表，打開
• 評論 - 關於交付任何評論，如「需要取消細郵件大小」，‘不能完全滿足該消息的佈局，而是由客戶端’等
• 完成日期接受 - 當改變交付
• 日期滿足 - 當變更被接受

隨着使用要求的ID中，我假設他們重新指向包含更詳細的信息，包括佈局，屏幕截圖的文檔等

Answer 3

我就已經在使用的要求編號方案到位，而不是創建一個新的。我會記錄每個要求的下列項目：

1. 的需求狀態：這可以在許多不同的方式來表述，但你tyring溝通，如果完成的要求，因爲上市，完成的經修飾的變什麼被列入名單或根本無法完成。
2. 要求註釋：描述先前列出的需求狀態。這就是「爲什麼」能解釋那些不能完全滿足要求的項目。
3. 完成日期：這主要用於未來的產品規劃，但也作爲歷史參考。

幾個其他點要記住：

1. 要求可以由客戶進行審查，特別是如果客戶是要求的來源。因此，這份文件需要儘可能準確和翔實。 （這也是另一個原因，除非必須，否則不要更改需求編號方案。）
2. 您的測試部門（假設您有測試部門）應該使用這些文檔進行測試計劃，並且他們需要知道需求是否滿足哪些不是最重要的哪些改變了，怎麼改變。

最後，除非您正在爲某人展示狗和小馬秀，否則您不需要截圖作爲需求文檔的一部分。你也不需要提供完成的「證明」。測試部門將爲您做到這一點。

Answer 4

我們通常會制定一個測試計劃，如果滿意，每個項目都可以打勾。該計劃將基於原始要求（功能性或非功能性），例如：

要求：用戶帳戶應在三次嘗試使用不正確的密碼登錄後鎖定。

測試：嘗試使用不正確的密碼登錄超過三次。用戶帳戶現在是否被鎖定？

我們會爲每個需求做這件事，並重新運行每個候選發佈者的計劃。一些測試是自動化的，但我們也有一個測試團隊來執行手動測試！

根據運行這些測試計劃和用戶驗收測試的結果，我們會將RC簽名爲正確並適合發佈。

請注意，即使測試計劃中的某些項目未通過，我們有時也會簽署發佈，這一切都取決於項目的性質！

Answer 5

驗證需求的正式方法是測試 - 通常是驗收測試。

這個想法是：對於每一個需求，應該有一個或多個測試來驗證需求。在正式的開發情況下，客戶在簽署要求的同時簽署驗收測試。

然後，當產品完成後，您會在接受最終產品之前提交驗收測試結果和客戶評審結果。

如果您有要求無法測試，那麼他們可能寫得不好。

例如不要說「加載文件應該很快」，比如說「一個大小爲X的文件應該在Z的硬件上加載不超過Y毫秒」或類似的東西。

Answer 6

有一些技術可以將您的需求轉換爲測試用例。 但這些取決於您的要求如何記錄。 如果您已經完成了基於場景的需求分析，那麼這將非常容易：只需爲您的場景的每個路徑創建一個序列圖，寫/做一個測試 - >完成。 除了這種方式創建的文檔也應該打動你的講師。

如果你沒有方案，你應該創建一些你的用例。

的這裏缺點是，它是非常密集的工作，應該只有在證明其使用的情況下使用（論文例如;））