測試設計規范是一個定義了與測試項目相關的測試條件、詳細的測試方法和高級測試用例的文檔。它確定了要運行哪些測試套件和測試用例，以及要跳過哪些。

使用測試設計規范，可以簡化對當前測試周期的理解。這個文檔回答了像“我們在做什么?”，“我們怎么做?”和“為什么要這樣做?”這樣的簡單問題。然而，要達到這個結果，必須正確地將許多事物融入到創建規范中，使其變得完美合理。

在軟件行業中，"規范"這個詞對任何人來說可能并不陌生。根據理論定義，規范是關于設計和制造某物所涉及的詳細描述和材料。規范已經采取了多種形式，并為不同部門提供了多種不同的服務。對于開發者來說，軟件需求規范(SRS)可能是首先記錄他的理解并傳達給客戶或其他團隊成員的文檔。對于測試人員來說，SRS文檔變成了測試設計規范(TDS)，它具有相同的目的，但專注于測試并且僅供測試人員使用。

什么是測試設計?規范的清晰度在很大程度上取決于我們對測試設計及其在測試領域中的作用的理解。

測試設計提供了關于在軟件應用程序上執行的測試的想法。重要的是要注意，測試設計預期在測試之前構建，而不是在測試過程中或之后。這樣，我們就知道應該采取哪些路徑并避免哪些路徑。

構建測試設計包括三個階段：

1.分析我們經歷的第一個階段是測試分析。在這個階段，我們分析應用程序和我們所擁有的其他所有東西。測試人員在分析階段收集的所有數據將成為以后測試用例的基礎。

2.計劃一旦我們分析了應用程序并收集了非結構化的原始數據，我們會計劃使用所有資源進行高效的測試。這在很大程度上取決于我們向用戶發布的軟件類型。游戲應用程序可能需要大量的UI、UX和硬件響應測試。在銀行應用程序中，擔心這些問題可能不那么重要。

3.創建測試用例我們有資源和結構可以在測試階段對軟件進行測試。因此，我們開始創建測試套件，記住我們是根據前一階段創建的計劃來工作的。測試套件的創建可能指示編程腳本或基于英語的定義。

在一些組織中，開發者可以通過測試套件來清楚地定義應用程序目標，從而確定系統的功能。例如，“檢查文件上傳”可以是一個包含與上傳框相關的測試用例的測試套件。之后，測試人員可能會在文件上傳中探索各個領域，如上傳具有允許擴展名的文件、上傳具有不正確擴展名的文件、在上傳過程中斷開網絡連接等。

另一方面，如果質量保證直接參與其中，他們甚至可以直接在此處以腳本形式設計測試套件。

完成了所有這些三個步驟后，我們的測試設計就完成了。但這主要側重于應用程序的測試部分。這將是我們需要創建的測試設計文檔的核心。將測試設計與完成文檔所需的其他元素相結合，形成了測試設計規范。

在進行測試時，重要的是考慮真實的用戶場景。為了使測試環境更加真實，應該在真實設備云上運行測試。

您可以使用LambdaTest——一個測試編排和執行平臺，提供跨3000多種真實瀏覽器、設備和操作系統對網站和應用程序進行手動和自動化測試。根據您的項目需求，您甚至可以在真實設備云和基于Android模擬器和iOS模擬器的移動應用程序上進行測試。

什么是測試設計規范?測試設計規范定義了我們的測試將如何構建。當我們深入研究這個概念時，我們就到達了測試設計規范或者說是一份比測試設計更豐富、更深入的文檔，供測試人員(有時也供開發人員)使用。

它不僅討論測試和場景，還回答了與測試相關的更深層次的問題。例如：

如何執行測試?我們需要多久執行一次測試?我們正在使用的方法是什么?為什么要使用這些方法?我們正在選擇哪些測試工具?為什么要選擇這些工具?具體解釋的測試場景是什么?根據測試人員或項目/組織的需求，還可以添加更多內容。

測試設計規范圍圍繞特征而不是測試用例展開，與測試設計相比。在討論時，我們考慮單個特征，并記錄在測試中將使用哪些測試用例或場景(從測試設計池中選取)。因此，我們為一個軟件創建多個測試設計規范。

測試設計規范的格式在測試設計規范中，我們可能會遇到來自不同人的不同觀點。即使消除了地理差異，你和我可能會產生完全不同的規范(或任何文檔)。這是因為我認為必要的東西對你來說可能并不重要，反之亦然。

為了解決這種情況，IEEE組織在軟件行業中處理、管理和規范每種類型的規范。IEEE包含一個龐大的數據庫，定義了軟件開發的每個階段的標準，甚至在編寫一行代碼之前就開始了。

對于那些針對SDLC中的特定領域的人來說，搜索特定規范可能變得耗時。為了處理這種情況，IEEE描述了一個數字，它指代一個區域內的標準文檔。對于我們的測試計劃、測試設計和測試用例規范，我們使用IEEE 829文檔。

IEEE 829描述了在文檔中需要描述的以下基本要素：

測試設計規范標識符。需進行測試的功能。方法細化。測試用例標識。功能通過/失敗的標準。讓我們逐個分析它們。

標識符在創建設計規范時的第一個基本要素是標識符。它記錄在文檔的頂部，并且每個測試設計規范都有一個唯一的標識符。在文檔中需要這個要素的原因是，一個軟件可能包含與單個功能或一組功能相關的多個規范。

為了對這些文檔描述一個獨特的標識符，我們可以在不打開它們的情況下識別每個文檔的摘要。這種安排有助于更快地找到所需的信息，最終有助于快速完成測試階段。

在創建測試設計規范標識符時，請記住以下幾點：

名稱應該簡短且唯一。指定版本日期號。規范的作者及其聯系方式，例如電子郵件地址。明確定義修訂歷史(如果有)。

需進行測試的功能根據IEEE 829，測試設計規范的第二要素定義了需要測試的功能列表。通常，這對應于由高級管理層或客戶確定的從需求池(包含所有需求)中提取的需求。這些需求滿足應用程序的功能，因此將其稱為“需進行測試的功能”。

測試人員應仔細組合所有的測試用例規范，以滿足所有需求。沒有這些規范，我們的應用程序有可能存在錯誤和漏洞。

根據IEEE的規定，設計規范需要涵蓋以下內容：

功能：屬性和特征。功能：如果存在分組。如果測試計劃涉及多個層次的測試，請確定特定功能涵蓋的層次。與包含需求池的文檔的關聯。方法細化測試設計規范的第三部分涉及特征細化和我們的方法。 "細化" 部分有一些指定的部分必須包含，但測試人員可以在其上添加一些自己的內容。

作為一個測試人員，您可以考慮這一段是一個測試人員為其他測試人員記錄的最深層次的知識。對于那些不參與項目的測試人員來說，他們尤其需要用文檔回答有關測試技術的每個問題。

根據IEEE的規定，這種技術水平被分為以下幾個部分：

測試技術的具體細節：這部分將包括有關每個功能中使用的測試技術的較少細節。為什么使用某種測試技術：詳細說明為什么使用特定的測試技術以及它帶來的優勢。結果分析方法：突出顯示如何分析測試階段的結果。這一部分的主要目的是定義結果分析中使用的方法和所提到的工具。測試人員還可以說明為什么使用某個工具以及其目的。例如，JMeter 被用于分析負載測試結果。特征級別關系：此部分定義了特征或測試項與測試級別之間的關系。標準信息：測試人員認為對多個功能/測試用例有共同意義的任何信息應在此部分共享。這可能包括測試環境信息、設置信息、恢復信息和依賴項。

IEEE按照上述順序描述了這些部分。并不一定要遵循如此嚴格的步驟，只需要確保測試設計規范中的信息是完整的。

測試標識設計規范的這一部分用英文描述測試用例，以便讀者在深入了解具體細節之前能對測試用例有一個大致的了解。

此部分分為兩個部分：

測試用例標識介紹每個測試用例的簡要知識。測試過程標識介紹每個測試過程的簡要知識。

功能通過/失敗的標準最后但同樣重要的是，在測試設計規范中必須包含功能通過/失敗的標準。我們的目標是為每個測試確定通過或失敗的標準，并分析結果。

例如，如果一個測試用例涉及 "在網站上注冊"，通過的標準可能是 "用戶在數據庫中被創建"。如果使用失敗的標準，那么 "用戶沒有在數據庫中創建" 就意味著測試未通過。

這些標準幫助我們評估所有測試用例的最終結果，并闡明當我們說測試通過或失敗時的含義。

結論當一個測試人員加入團隊時，自然而然地，團隊將面臨各種不同類型的問題。除了定義方法和標準程序外，項目相關的問題可能會占用您大部分時間。

通過電話澄清所有疑問，并為每個測試用例提供解釋，包括 "我們為什么這樣做"，這是不可行的，而且老實說，新成員不太可能很快記住這些內容。因此，我們采用文檔的方式來解決這個問題。

在每個領域中，文檔提供了團隊成員和參與項目的人(無論是技術人員還是非技術人員)的參考材料。由于這些時候人們從世界各地聚集在一起共同開發一款優秀的軟件，因此需要一種標準的文檔來確保每個人在參考測試設計相關內容時都處于相同的頁面。

IEEE是負責此類事務的組織，他們提供了一個標準的分段文檔，稱為測試設計規范，用于測試設計領域，并記錄團隊所做的選擇以及與測試流程有關的一切。

本文介紹了這個文檔，并將復雜的部分分解為簡單易懂的概念。希望這個指南能為您在下一個項目中建立一個強大的測試設計規范提供快速參考。