軟體測試 - 快速指南

---

---

軟體測試 - 概述

什麼是測試？

測試是評估系統或其元件的過程，目的是確定其是否滿足規定的要求。簡單來說，測試是為了識別系統中與實際需求相反的任何差距、錯誤或缺失的需求而執行系統。

根據 ANSI/IEEE 1059 標準，測試可以定義為 - 分析軟體專案以檢測現有條件和所需條件之間的差異（即缺陷/錯誤/bug）並評估軟體專案功能的過程。

誰來進行測試？

這取決於專案的過程和相關利益相關者。在 IT 行業，大型公司擁有一個團隊，負責在給定需求的背景下評估開發的軟體。此外，開發人員還會進行測試，這稱為**單元測試**。在大多數情況下，以下專業人員會根據各自的能力參與系統測試 -

• 軟體測試人員
• 軟體開發人員
• 專案主管/經理
• 終端使用者

不同的公司根據測試人員的經驗和知識，對測試軟體的人員有不同的職位名稱，例如軟體測試人員、軟體質量保證工程師、QA 分析師等。

並非在軟體週期的任何時間都可以測試軟體。接下來的兩節將說明在 SDLC 中何時開始測試以及何時結束測試。

何時開始測試？

儘早開始測試可以降低返工成本和時間，並生成交付給客戶的無錯誤軟體。然而，在軟體開發生命週期 (SDLC) 中，測試可以從需求收集階段開始，持續到軟體部署。

這也取決於正在使用的開發模型。例如，在瀑布模型中，正式測試是在測試階段進行的；但在增量模型中，測試是在每個增量/迭代結束時執行的，並在最後測試整個應用程式。

在 SDLC 的每個階段，測試都以不同的形式進行 -

• 在需求收集階段，對需求的分析和驗證也被視為測試。

• 在設計階段審查設計以改進設計也被視為測試。

• 開發人員在完成程式碼後執行的測試也被歸類為測試。

何時停止測試？

很難確定何時停止測試，因為測試是一個永無止境的過程，沒有人可以聲稱軟體已 100% 測試。需要考慮以下方面來停止測試過程 -

• 測試截止日期

• 測試用例執行完成

• 功能和程式碼覆蓋率達到一定程度

• 錯誤率降至一定水平，並且沒有發現高優先順序的錯誤

• 管理決策

驗證與確認

這兩個術語對大多數人來說都非常令人困惑，他們可以互換使用。下表突出顯示了驗證和確認之間的區別。

軟體測試 - 誤區

以下是一些關於軟體測試最常見的誤區。

誤區 1：測試成本過高

**現實** - 有句諺語，在軟體開發過程中為測試支付更少的費用，或者以後為維護或更正支付更多的費用。早期測試在許多方面都節省了時間和成本，但是減少測試的成本可能會導致軟體應用程式設計不當，從而使產品變得毫無用處。

誤區 2：測試耗時

**現實** - 在 SDLC 階段，測試絕不是一個耗時的過程。但是，診斷和修復在適當測試期間發現的錯誤是一個耗時但富有成效的活動。

誤區 3：只有完全開發的產品才進行測試

**現實** - 毫無疑問，測試依賴於原始碼，但審查需求和開發測試用例與開發的程式碼無關。但是，迭代或增量方法作為開發生命週期模型可以減少測試對完全開發的軟體的依賴性。

誤區 4：完整的測試是可能的

**現實** - 當客戶或測試人員認為完整的測試是可能的時候，就會出現問題。團隊可能已經測試了所有路徑，但完整的測試永遠不可能發生。在軟體開發生命週期中，測試團隊或客戶可能從未執行過某些場景，並且可能在專案部署後執行。

誤區 5：經過測試的軟體是無錯誤的

**現實** - 這是一個非常普遍的誤區，客戶、專案經理和管理團隊都相信這一點。即使擁有出色測試技能的測試人員測試了應用程式，也沒有人可以絕對肯定地聲稱軟體應用程式是 100% 無錯誤的。

誤區 6：錯過的缺陷是由於測試人員造成的

**現實** - 將應用程式中即使在執行完測試後仍然存在的錯誤歸咎於測試人員，這不是一種正確的方法。這種誤區與時間、成本和不斷變化的需求約束有關。但是，測試策略也可能導致測試團隊錯過了錯誤。

誤區 7：測試人員負責產品的質量

**現實** - 這是一個非常普遍的誤解，即只有測試人員或測試團隊應該對產品質量負責。測試人員的職責包括向利益相關者識別錯誤，然後由他們決定是否修復錯誤或釋出軟體。在此時釋出軟體會給測試人員帶來更大的壓力，因為他們將對任何錯誤負責。

誤區 8：應儘可能使用測試自動化來縮短時間

**現實** - 是的，測試自動化確實可以縮短測試時間，但在軟體開發的任何時間都無法啟動測試自動化。當軟體經過手動測試並在一定程度上穩定時，應開始測試自動化。此外，如果需求不斷變化，則永遠無法使用測試自動化。

誤區 9：任何人都可以測試軟體應用程式

**現實** - IT 行業以外的人認為甚至相信任何人都可以測試軟體，並且測試不是一項創造性的工作。但是測試人員非常清楚這是一個誤區。思考替代方案、試圖使軟體崩潰以探索潛在錯誤對於開發它的人來說是不可能的。

誤區 10：測試人員的唯一任務是查詢錯誤

**現實** - 在軟體中查詢錯誤是測試人員的任務，但同時，他們也是特定軟體的領域專家。開發人員只負責分配給他們的特定元件或區域，但測試人員瞭解軟體的整體工作原理、依賴關係以及一個模組對另一個模組的影響。

軟體測試 - QA、QC 和測試

測試、質量保證和質量控制

當涉及到確定質量保證、質量控制和測試之間的差異時，大多數人都會感到困惑。儘管它們是相互關聯的，並且在某種程度上，它們可以被視為相同的活動，但確實存在一些區別點將它們區分開來。下表列出了區分 QA、QC 和測試的要點。

稽核和檢查

審計 - 它是一個系統化的過程，用於確定組織或團隊內部實際測試過程是如何進行的。通常，它是對軟體測試過程中涉及的過程進行的獨立審查。根據 IEEE 的定義，它是對組織實施和遵循的已記錄流程的審查。審計型別包括法律合規性審計、內部審計和系統審計。

檢查 - 它是一種正式的技術，透過識別任何錯誤或差距，對任何工件進行正式或非正式的技術審查。根據 IEEE94，檢查是一種正式的評估技術，其中軟體需求、設計或程式碼由作者以外的人員或小組詳細檢查，以檢測故障、開發標準違規和其他問題。

正式檢查會議可能包括以下流程：計劃、概述準備、檢查會議、返工和後續。

測試和除錯

測試 - 它涉及識別軟體中的錯誤/缺陷，但不進行修正。通常，具有質量保證背景的專業人員參與錯誤識別。測試在測試階段執行。

除錯 - 它涉及識別、隔離和修復問題/錯誤。開發人員在程式碼中遇到錯誤時會進行除錯。除錯是白盒測試或單元測試的一部分。除錯可以在開發階段進行單元測試時，或在修復報告的錯誤的階段進行。

軟體測試 - ISO 標準

全球許多組織開發和實施不同的標準，以提高其軟體的質量需求。本章簡要介紹了一些廣泛使用的與質量保證和測試相關的標準。

ISO/IEC 9126

該標準處理以下方面，以確定軟體應用程式的質量 -

• 質量模型
• 外部度量
• 內部度量
• 使用中的質量度量

該標準提出了一些適用於任何軟體的質量屬性集，例如 -

• 功能性
• 可靠性
• 可用性
• 效率
• 可維護性
• 可移植性

上述質量屬性進一步細分為子因素，您可以在詳細研究該標準時進行學習。

ISO/IEC 9241-11

該標準的第 11 部分涉及產品在指定使用環境中，由指定使用者用來實現指定目標的有效性、效率和滿意度的程度。

該標準提出了一個框架，描述了可用性元件及其之間的關係。在本標準中，可用性從使用者效能和滿意度的角度考慮。根據 ISO 9241-11，可用性取決於使用環境，並且可用性水平會隨著環境的變化而變化。

ISO/IEC 25000:2005

ISO/IEC 25000:2005 通常被稱為提供軟體質量需求和評估 (SQuaRE) 指南的標準。該標準有助於組織和增強與軟體質量需求及其評估相關的流程。實際上，ISO-25000 替換了兩個舊的 ISO 標準，即 ISO-9126 和 ISO-14598。

SQuaRE 分為以下子部分 -

• ISO 2500n - 質量管理部分
• ISO 2501n - 質量模型部分
• ISO 2502n - 質量測量部分
• ISO 2503n - 質量需求部分
• ISO 2504n - 質量評估部分

SQuaRE 的主要內容包括 -

• 術語和定義
• 參考模型
• 通用指南
• 各個部分指南
• 與需求工程相關的標準（即規範、計劃、測量和評估過程）

ISO/IEC 12119

該標準處理交付給客戶的軟體包。它不關注或處理客戶的生產過程。主要內容與以下專案相關 -

• 軟體包的一組需求。
• 根據指定需求測試交付的軟體包的說明。

其他

下面列出了一些其他與 QA 和測試流程相關的標準 -

軟體測試 - 測試型別

本節描述了在 SDLC 期間可能用於測試軟體的不同型別的測試。

手動測試

手動測試包括手動測試軟體，即不使用任何自動化工具或指令碼。在這種型別中，測試人員承擔終端使用者的角色，並測試軟體以識別任何意外行為或錯誤。手動測試的不同階段包括單元測試、整合測試、系統測試和使用者驗收測試。

測試人員使用測試計劃、測試用例或測試場景來測試軟體，以確保測試的完整性。手動測試還包括探索性測試，測試人員探索軟體以識別其中的錯誤。

自動化測試

自動化測試，也稱為測試自動化，是指測試人員編寫指令碼並使用其他軟體來測試產品。此過程涉及手動流程的自動化。自動化測試用於快速、重複地重新執行手動執行的測試場景。

除了迴歸測試外，自動化測試還用於從負載、效能和壓力角度測試應用程式。與手動測試相比，它提高了測試覆蓋率，提高了準確性，並節省了時間和金錢。

自動化什麼？

不可能自動化軟體中的所有內容。使用者可以進行交易的區域（例如登入表單或登錄檔單）、大量使用者可以同時訪問軟體的任何區域都應該自動化。

此外，所有 GUI 專案、與資料庫的連線、欄位驗證等都可以透過自動化手動流程進行有效測試。

何時自動化？

應考慮軟體的以下方面來使用測試自動化 -

• 大型關鍵專案
• 需要頻繁測試相同區域的專案
• 需求不經常變化
• 使用許多虛擬使用者訪問應用程式以進行負載和效能測試
• 在手動測試方面穩定的軟體
• 可用時間

如何自動化？

自動化是透過使用支援性計算機語言（如 VB 指令碼）和自動化軟體應用程式來完成的。有許多可用於編寫自動化指令碼的工具。在提及工具之前，讓我們先確定可用於自動化測試流程的過程 -

• 識別軟體中需要自動化的區域
• 選擇合適的測試自動化工具
• 編寫測試指令碼
• 開發測試套件
• 執行指令碼
• 建立結果報告
• 識別任何潛在的錯誤或效能問題

軟體測試工具

以下工具可用於自動化測試 -

• HP Quick Test Professional
• Selenium
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• Testing Anywhere
• WinRunner
• LoadRunner
• Visual Studio Test Professional
• WATIR

軟體測試 - 方法

軟體測試有多種方法。本章簡要介紹了可用的方法。

黑盒測試

在不瞭解應用程式內部工作原理的情況下進行測試的技術稱為黑盒測試。測試人員不知道系統架構，也無法訪問原始碼。通常，在執行黑盒測試時，測試人員會透過提供輸入和檢查輸出與系統的使用者介面互動，而不知道輸入是如何以及在哪裡處理的。

下表列出了黑盒測試的優缺點。

白盒測試

白盒測試是對程式碼內部邏輯和結構的詳細調查。白盒測試也稱為玻璃盒測試或開盒測試。為了對應用程式執行白盒測試，測試人員需要了解程式碼的內部工作原理。

測試人員需要檢視原始碼內部，並找出哪個單元/程式碼塊的行為不正常。

下表列出了白盒測試的優缺點。

灰盒測試

灰盒測試是一種在對應用程式內部工作原理了解有限的情況下測試應用程式的技術。在軟體測試中，測試應用程式時“瞭解得越多，越好”這句話很有分量。

掌握系統領域知識總是能讓測試人員比那些領域知識有限的人更有優勢。與黑盒測試不同，黑盒測試中測試人員只測試應用程式的使用者介面；而在灰盒測試中，測試人員可以訪問設計文件和資料庫。擁有這些知識，測試人員可以在制定測試計劃時準備更好的測試資料和測試場景。

測試方法比較

下表列出了區分黑盒測試、灰盒測試和白盒測試的關鍵點。

軟體測試 - 層次

在測試過程中存在不同的級別。本章將簡要介紹這些級別。

測試級別包括在進行軟體測試時可以使用的方法。軟體測試的主要級別包括：

• 功能測試

• 非功能測試

功能測試

這是一種黑盒測試型別，基於要測試的軟體的規範。透過提供輸入來測試應用程式，然後檢查結果是否符合其預期功能。軟體的功能測試是在完整的整合系統上進行的，以評估系統是否符合其指定的的規範。

在測試應用程式的功能時，涉及五個步驟。

有效的測試實踐將看到上述步驟應用於每個組織的測試策略，因此它將確保組織在軟體質量方面保持最嚴格的標準。

單元測試

這種型別的測試由開發人員在將設定移交給測試團隊正式執行測試用例之前執行。單元測試由各自的開發人員在其分配的原始碼的各個單元上執行。開發人員使用的測試資料與質量保證團隊的測試資料不同。

單元測試的目標是隔離程式的每個部分，並證明各個部分在需求和功能方面是正確的。

單元測試的侷限性

測試無法捕獲應用程式中的每個錯誤。評估每個軟體應用程式中的每個執行路徑是不可能的。單元測試也是如此。

開發人員可以使用來驗證原始碼的場景和測試資料的數量是有限的。在用盡所有選項後，別無選擇，只能停止單元測試並將程式碼段與其他單元合併。

整合測試

整合測試定義為測試應用程式的組合部分以確定它們是否能夠正常執行。整合測試可以透過兩種方式進行：自底向上整合測試和自頂向下整合測試。

在一個全面的軟體開發環境中，通常首先進行自底向上測試，然後進行自頂向下測試。該過程以對完整應用程式進行多次測試結束，最好是在旨在模擬實際情況的場景中。

系統測試

系統測試將系統作為一個整體進行測試。一旦所有元件都整合在一起，就會對整個應用程式進行嚴格的測試，以確保它滿足指定的質量標準。這種型別的測試由專門的測試團隊執行。

系統測試之所以重要，原因如下：

• 系統測試是軟體開發生命週期中的第一步，其中應用程式作為整體進行測試。

• 對應用程式進行徹底測試，以驗證它是否滿足功能和技術規範。

• 在非常接近應用程式將部署到的生產環境的環境中測試應用程式。

• 系統測試使我們能夠測試、驗證和確認業務需求以及應用程式架構。

迴歸測試

每當對軟體應用程式進行更改時，應用程式內的其他區域都可能受到此更改的影響。執行迴歸測試以驗證已修復的錯誤是否導致其他功能或業務規則違規。迴歸測試的目的是確保更改（例如錯誤修復）不會導致在應用程式中發現其他故障。

迴歸測試之所以重要，原因如下：

• 在必須測試已進行更改的應用程式時，最大程度地減少測試中的差距。

• 測試新更改以驗證所做的更改是否影響了應用程式的任何其他區域。

• 在對應用程式執行迴歸測試時降低風險。

• 在不影響時間表的情況下提高測試覆蓋率。

• 加快產品上市速度。

驗收測試

這可以說是最重要的測試型別，因為它是由質量保證團隊進行的，他們將評估應用程式是否滿足預期的規範並滿足客戶的要求。質量保證團隊將有一組預先編寫的場景和測試用例，用於測試應用程式。

將共享更多關於應用程式的想法，並可以對其進行更多測試以評估其準確性以及啟動該專案的原因。驗收測試不僅旨在指出簡單的拼寫錯誤、外觀錯誤或介面差距，還旨在指出應用程式中可能導致系統崩潰或重大錯誤的任何錯誤。

透過對應用程式執行驗收測試，測試團隊將減少應用程式在生產環境中的表現。系統驗收也存在法律和合同要求。

Alpha 測試

此測試是測試的第一階段，將在團隊（開發團隊和質量保證團隊）之間執行。單元測試、整合測試和系統測試組合在一起稱為 Alpha 測試。在此階段，將在應用程式中測試以下方面：

• 拼寫錯誤

• 斷開的連結

• 模糊的說明

• 將在具有最低規格的機器上測試應用程式，以測試載入時間和任何延遲問題。

Beta 測試

此測試在成功執行 Alpha 測試後執行。在 Beta 測試中，目標受眾的樣本會測試應用程式。Beta 測試也稱為**預釋出測試**。軟體的 Beta 測試版本理想情況下會分發給 Web 上的廣泛受眾，部分是為了讓程式進行“真實世界”測試，部分是為了提供下一個版本的預覽。在此階段，受眾將測試以下內容：

• 使用者將安裝、執行應用程式並將反饋傳送給專案團隊。

• 印刷錯誤、應用程式流程混亂，甚至崩潰。

• 獲取反饋後，專案團隊可以在將軟體釋出給實際使用者之前解決問題。

• 您修復的解決實際使用者問題的問題越多，應用程式的質量就越高。

• 當您將更高質量的應用程式釋出給公眾時，將提高客戶滿意度。

非功能測試

本節基於從其非功能屬性測試應用程式。非功能測試涉及從本質上是非功能性的但很重要的需求（例如效能、安全性、使用者介面等）來測試軟體。

下面將討論一些重要且常用的非功能測試型別。

效能測試

它主要用於識別任何瓶頸或效能問題，而不是查詢軟體中的錯誤。降低軟體效能的原因有很多：

• 網路延遲

• 客戶端處理

• 資料庫事務處理

• 伺服器之間的負載平衡

• 資料渲染

在以下方面，效能測試被認為是一種重要且強制性的測試型別：

• 速度（即響應時間、資料渲染和訪問）

• 容量

• 穩定性

• 可擴充套件性

效能測試可以是定性的，也可以是定量的，並且可以分為不同的子型別，例如**負載測試**和**壓力測試**。

負載測試

它是一個透過應用最大負載（以軟體訪問和處理大量輸入資料的方式）來測試軟體行為的過程。它可以在正常和峰值負載條件下進行。這種型別的測試可以識別軟體的最大容量及其在峰值時間的行為。

大多數情況下，負載測試是在自動化工具（例如Load Runner、AppLoader、IBM Rational Performance Tester、Apache JMeter、Silk Performer、Visual Studio Load Test等）的幫助下執行的。

在自動化測試工具中定義虛擬使用者（VUser），並執行指令碼以驗證軟體的負載測試。可以根據需要同時或逐步增加或減少使用者數量。

壓力測試

壓力測試包括在異常條件下測試軟體的行為。例如，它可能包括移除某些資源或應用超出實際負載限制的負載。

壓力測試的目的是透過向系統施加負載並接管軟體使用的資源來測試軟體，以識別其斷點。可以透過測試以下不同的場景來執行此測試：

• 隨機關閉或重新啟動網路埠

• 開啟或關閉資料庫

• 執行消耗資源（如CPU、記憶體、伺服器等）的不同程序。

可用性測試

可用性測試是一種黑盒技術，用於透過觀察使用者的使用和操作來識別軟體中的任何錯誤和改進。

根據尼爾森的說法，可用性可以用五個因素來定義，即易用性、可學習性、可記憶性、錯誤/安全性以及滿意度。在他看來，如果一個產品具備上述因素，那麼它的可用性就很好，系統就是可用的。

奈傑爾·比文和麥克萊奧德認為，可用性是可以衡量為與計算機系統互動結果的質量要求。如果透過使用適當的資源有效地實現了預期目標，則可以滿足此要求，終端使用者將感到滿意。

莫利奇在2000年指出，一個使用者友好的系統應該實現以下五個目標，即易於學習、易於記憶、使用效率高、使用滿意度高以及易於理解。

除了可用性的不同定義之外，還有一些標準和質量模型以及方法以屬性和子屬性的形式定義可用性，例如ISO-9126、ISO-9241-11、ISO-13407和IEEE std.610.12等。

UI 與可用性測試

UI測試涉及測試軟體的圖形使用者介面。UI測試確保GUI根據要求執行，並根據顏色、對齊方式、大小和其他屬性進行測試。

另一方面，可用性測試確保一個良好且使用者友好的GUI，可以輕鬆操作。UI測試可以被認為是可用性測試的一部分。

安全測試

安全測試涉及測試軟體，以從安全性和漏洞的角度識別任何缺陷和漏洞。以下是安全測試應確保的主要方面：

• 機密性

• 完整性

• 身份驗證

• 可用性

• 授權

• 不可否認性

• 軟體可以抵禦已知和未知的漏洞。

• 軟體資料是安全的。

• 軟體符合所有安全法規。

• 輸入檢查和驗證

• SQL注入攻擊

• 注入漏洞

• 會話管理問題

• 跨站點指令碼攻擊

• 緩衝區溢位漏洞

• 目錄遍歷攻擊

可移植性測試

可移植性測試包括測試軟體，以確保其可重用性，以及它可以從另一個軟體中移動。以下是可以用於可移植性測試的策略：

• 將已安裝的軟體從一臺計算機傳輸到另一臺計算機。

• 構建可執行檔案（.exe）以在不同的平臺上執行軟體。

可移植性測試可以被認為是系統測試的一部分，因為此測試型別包括針對不同環境下的使用對軟體進行全面測試。計算機硬體、作業系統和瀏覽器是可移植性測試的主要關注點。可移植性測試的一些先決條件如下：

• 軟體的設計和編碼應考慮到可移植性要求。

• 已對相關元件進行了單元測試。

• 已進行整合測試。

• 已建立測試環境。

軟體測試 - 文件

測試文件涉及在軟體測試之前或期間應開發的工件的文件。

軟體測試文件有助於估算所需的測試工作量、測試覆蓋率、需求跟蹤/追溯等。本節描述了一些與軟體測試相關的常用文件工件，例如：

• 測試計劃
• 測試場景
• 測試用例
• 可追溯性矩陣

測試計劃

測試計劃概述了將用於測試應用程式的策略、將使用的資源、執行測試的測試環境以及測試的限制和測試活動的計劃。通常，質量保證團隊負責人將負責編寫測試計劃。

測試計劃包括以下內容：

• 測試計劃文件的介紹
• 測試應用程式時的假設
• 測試應用程式中包含的測試用例列表
• 要測試的功能列表
• 測試軟體時使用哪種方法
• 需要測試的交付成果列表
• 分配給測試應用程式的資源
• 測試過程中涉及的任何風險
• 要實現的任務和里程碑的計劃

測試場景

這是一個單行語句，通知將測試應用程式的哪個區域。測試場景用於確保從頭到尾測試所有流程。應用程式的特定區域可以只有很少的測試場景，也可以有多達幾百個場景，具體取決於應用程式的規模和複雜性。

術語“測試場景”和“測試用例”可以互換使用，但是測試場景有多個步驟，而測試用例只有一個步驟。從這個角度來看，測試場景是測試用例，但它們包含多個測試用例及其應執行的順序。除此之外，每個測試都依賴於前一個測試的輸出。

測試用例

測試用例涉及一組可以在執行測試任務時使用的步驟、條件和輸入。此活動的主要目的是確保軟體在功能和其他方面是否透過或失敗。測試用例有很多型別，例如功能性測試用例、負面測試用例、錯誤測試用例、邏輯測試用例、物理測試用例、UI測試用例等。

此外，編寫測試用例是為了跟蹤軟體的測試覆蓋率。通常，在編寫測試用例時沒有正式的模板可以使用。但是，以下元件始終可用幷包含在每個測試用例中：

• 測試用例ID
• 產品模組
• 產品版本
• 修訂歷史
• 目的
• 假設
• 先決條件
• 步驟
• 預期結果
• 實際結果
• 後置條件

可以從單個測試場景中得出許多測試用例。此外，有時會為單個軟體編寫多個測試用例，這些測試用例統稱為測試套件。

可追溯性矩陣

可追溯性矩陣（也稱為需求可追溯性矩陣 - RTM）是一個用於在軟體開發生命週期中跟蹤需求的表格。它可以用於前向跟蹤（即從需求到設計或編碼）或後向跟蹤（即從編碼到需求）。RTM有很多使用者定義的模板。

RTM文件中的每個需求都與其關聯的測試用例連結，以便可以根據提到的需求進行測試。此外，Bug ID 也包含在內並與其關聯的需求和測試用例連結。此矩陣的主要目標是：

• 確保軟體根據提到的需求開發。
• 有助於查詢任何錯誤的根本原因。
• 有助於在 SDLC 的不同階段跟蹤已開發的文件。

軟體測試 - 估算技術

估算測試所需的精力是 SDLC 中一項主要且重要的任務。正確的估算有助於以最大覆蓋率測試軟體。本節描述了一些可用於估算測試所需精力的技術。

功能點分析

此方法基於對軟體的功能使用者需求的分析，包括以下類別：

• 輸出
• 查詢
• 輸入
• 內部檔案
• 外部檔案

測試點分析

此估算過程用於黑盒或驗收測試的功能點分析。此方法的主要要素是：規模、生產力、策略、介面、複雜性和統一性。

Mark-II 方法

這是一種用於根據終端使用者的功能檢視分析和衡量估算的估算方法。Mark-II 方法的過程如下：

• 確定觀點
• 目的和計數型別
• 定義計數邊界
• 識別邏輯事務
• 識別和分類資料實體型別
• 計算輸入資料元素型別
• 計算功能規模

其他

您可以使用其他流行的估算技術，例如：

• 德爾菲技術
• 基於類比的估算
• 基於測試用例列舉的估算
• 基於任務（活動）的估算
• IFPUG 方法