資料結構
網路
關係資料庫管理系統
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法律研究什麼是需求追溯矩陣？
需求追溯矩陣簡介
追溯矩陣是一個表格樣式的文件，用於跟蹤軟體應用程式開發中的需求。它可以用於向後追溯（從編碼到需求）以及向前追溯（從需求到設計或編碼）。需求追溯矩陣 (RTM) 或交叉引用矩陣是它的其他名稱 (CRM)。
它是在測試執行過程之前生成的，以確保所有需求都以測試用例的形式得到解決，確保不會遺漏任何測試。我們在 RTM 文件中將所有需求與其關聯的測試用例連線起來，以保證我們為每個條件編寫了所有測試用例。
RTM 將由測試工程師為其分配的模組準備，並轉發給測試主管。測試主管將轉到儲存庫以檢視測試用例是否存在，然後整合並準備單個 RTM 文件。
本檔案的目的是確保每個需求都有一個測試用例，並且測試用例是根據客戶的業務需求準備的。如果缺少任何需求，則將使用測試用例執行，這意味著沒有為該特定需求設計測試用例，並且該特定需求將不會被測試，因為它可能包含錯誤。追溯的編寫方式確保了所有需求都得到滿足。
這類似於帶有表格的工作表文件，但追溯矩陣還具有許多使用者定義的模板。追溯矩陣中的每個需求都與其相應的測試用例相關聯，允許按照需求指定的順序執行測試。
重要 -
我們在批准後和執行前進行 RTM，以確保沒有遺漏任何需求的測試用例。
我們不會在編寫測試時編寫 RTM，因為它可能未完成，並且我們也不會在編寫測試用例後進行此操作，因為它可能會被拒絕。
RTM 文件確保每個需求至少有一個測試用例，但它不討論該特定需求的所有可能的測試用例。
RTM 模板示例
RTM 的意義是什麼？
每個測試人員的主要目標都應該是理解客戶的需求並確保最終產品沒有缺陷。為此，每個 QA 都應該正確理解需求並設計正面和負面的測試用例。
這意味著客戶的軟體需求必須進一步細分為場景和測試用例。必須分別處理每個案例。
**這裡有一個問題** - 您如何確保在所有潛在場景/案例中都測試了需求？您如何確保在整個測試過程中沒有遺漏任何需求？
跟蹤需求及其相關的測試場景和測試用例是一種簡單的方法。這通常稱為“需求追溯矩陣”。
追溯矩陣通常是一個工作表，它提供需求以及所有可能的測試場景和案例，以及它們當前的狀態，例如它們是否已透過或失敗。這將有助於測試團隊確定產品測試操作的範圍。
追溯矩陣的目標
它有助於跟蹤在 SDLC 的各個階段建立的文件。
它確保程式完全滿足客戶的需求。
它有助於檢測任何錯誤的根本原因。
追溯測試矩陣型別
以下是三種不同的追溯矩陣型別 -
前向追溯
後向或反向追溯
雙向追溯
前向追溯
前向追溯測試矩陣用於確保每個業務的需求或要求在應用程式中得到正確實現和全面測試。主要目標是確保產品開發沿著正確的路徑進行。然後，需求以正向方式對映到測試用例。
後向或反向追溯
反向或後向追溯用於確保我們不會透過改進設計元素、程式碼或測試不包含在業務需求中的其他專案來擴充套件產品的空間。並且其主要目標是使當前專案沿著正確的路徑前進。在這種方法中，需求被反向對映到測試用例。
雙向追溯
它是一種前向和後向追溯矩陣的組合，用於確保所有業務需求都包含在測試用例中。它還評估由於程式中的缺陷而導致的任何需求變化。
需求追溯矩陣中包含的引數
在需求追溯矩陣中，應包含哪些引數？
需求 ID
需求 ID 的型別和描述
測試用例的狀態
| 需求編號 | 需求描述 | 測試用例 ID | 狀態 |
|---|---|---|---|
| 123 | 登入應用程式 | TC01、TC02、TC03 | TC01-透過 TC02-透過 |
| 345 | 工單建立 | TC04、TC05、TC06、TC07、TC08、TC09、TC010 | TC04-透過 TC05-透過 TC06-透過 TC06-失敗 TC07-未執行 |
| 456 | 搜尋工單 | TC011、TC012、TC013、TC014 | TC011-透過 TC012-失敗 TC013-透過 TC014-未執行 |
上面顯示了一個需求追溯矩陣示例。
然而，在典型的軟體測試專案中，追溯矩陣將包含比這些標準更多的內容。
需求追溯矩陣可以 -
顯示覆蓋所有需求所需的測試用例數量。
對於單個測試用例，存在設計狀態和執行狀態。
如果需要使用者執行使用者驗收測試，則可以在同一矩陣中記錄 UAT 狀態。
在同一矩陣中，可以提及相關的缺陷及其當前狀態。
這種型別的矩陣將成為所有測試需求的一站式服務。
除了保留一個單獨的 excel 檔案之外。測試團隊還可以使用各種測試管理工具之一來跟蹤需求。
需求追溯可以為您做什麼
需求在哪裡實現
例如，
**需求** - 在電子郵件應用程式中實現“撰寫郵件”功能
**實現** - “撰寫郵件”按鈕應位於主頁面上的哪個位置以及如何訪問？
是否需要有需求？
例如，
**需求** - 僅允許指定使用者在郵件應用程式中使用“撰寫郵件”功能。
**實現** - 如果使用者將電子郵件收件箱設定為“只讀”，則“撰寫郵件”按鈕將不需要。
理解需求的最佳方法是什麼？
例如，
**需求** - 在郵件程式中使用字型和附件功能“撰寫郵件”。
**實現** - 按下“撰寫郵件”按鈕時應提供哪些功能？
撰寫電子郵件的正文並以多種字型樣式編輯它們，以及粗體、斜體和下劃線。
多種型別的附件（影像、文件、其他電子郵件等）
附件的尺寸（允許的最大尺寸）
因此，需求被細分為子需求。
哪些設計決策會影響需求的實現
例如，
**需求** - 所有功能，如“收件箱”、“已傳送郵件”、“草稿”、“垃圾郵件”、“垃圾箱”等都應該清晰可見。
**實現** - 可見專案應以“樹”或“選項卡”格式顯示。
所有需求是否都已分配
例如，
**需求** - 有一個“垃圾箱”郵件選項。
**實現** - 如果“垃圾箱”郵件選項可用，則必須首先實現並測試“刪除”郵件選項（需求），以確保其正常工作。如果“刪除”郵件選項工作正常，則只有已刪除的郵件將被收集到“垃圾箱”中，並且採用“垃圾箱”郵件選項（需求）將是合理的（將是有用的）。
1K+ 次檢視
