完善的質量保證測試——用戶流程教程

隨著產品和服務的部署越來越快，質量保證 (QA) 必須適應不斷變化的環境，有時在更短的時間內達到相同的覆蓋水平。 我們如何避免數量超過質量的錯誤？ 我們如何覆蓋更多、提高效率並在工作中仍然有效？

我們都知道創建測試用例需要很長時間。 我們必須應用不同的技術、測試類型，並記錄前提條件、步驟和預期結果。 此外，我們必須制定一個測試計劃。

質量保證專家經常發現自己沒有時間，尤其是當他們試圖完成質量保證流程中的所有階段時。 最令人頭疼的是測試計劃和設計階段，圍繞測試用例創建和測試文檔展開。 完成所有工作可能需要幾個小時，有時甚至是幾天的努力，而且通常他們會選擇跳過某些可交付成果並進行總結，而忽略可能導致測試被遺忘的重要信息。 這也導致失去知識共享的好處。

傳統 QA 測試符合用戶流程

我是傳統測試用例和測試計劃的忠實粉絲。 它們不僅有助於識別大量的測試用例，而且還能很好地記錄產品。 你可以在訓練中使用它們，團隊中的任何人都理解它們。 您不必過分依賴經驗讓某人開始測試。 測試計劃包含更多信息，例如詳細說明範圍、測試項目、您正在測試的功能以及您不測試的功能。 測試計劃中還有一項風險分析。 這些只是其中的一部分好處，但是在許多情況下，所需的總時間太長了。

測試計劃的目的是項目利益相關者之間的一種溝通方式和協議。 它有助於詳細說明測試產品的目標、所需資源以及任何方法或策略。 該計劃有助於確保一切都在考慮之中，並使利益相關者對質量保證過程的戰略投資充滿信心。 沒有具體規定該計劃必須為 10 頁長。 我們可以重新定義它以適應快節奏的團隊。

另一種方法是簡化傳統的測試用例和測試計劃，以減少所需的時間投資，但提供對所有利益相關者有意義的相同（如果不是更多）覆蓋率和文檔。 這涉及一個單一的事實來源，一個扭曲的用戶流。 通過構建和維護用戶流程，您將已經為您完成了大部分測試用例設計。 這可以應用於任何產品或團隊，並且在細節和結構方面是通用的。

使用流程方法將幫助您縮短測試文檔的周轉時間。 這不僅適用於手動 QA，也適用於自動化。 該流程還可以對測試計劃的某些部分做出貢獻。

順其自然

事不宜遲，讓我們直接開始為一個簡單的消息傳遞網站構建用戶流程。

我們首先需要一個免費的思維導圖工具。 我個人使用 XMind。 隨意下載您喜歡的任何工具——我們將只使用基本功能，例如繪製流程圖、為某些主題添加“註釋”、為不同的條件著色和使用標籤。

我們的第一步是了解產品。 通常，您將參考模型圖像或線框。 如果這些都不可用，與開發人員進行快速跟進電話將準確產生預期的屏幕。 在我們繼續進行時，請隨意跟隨並練習。 該流程不僅限於用戶界面，還可用於繪製 API 到 API 調用、數據庫圖表、依賴結構等。 同樣的原則也適用。

條件、狀態、動作

我們只使用三個演員來限制我們的流程。 您將擁有一個Condition ，它就像具有特定角色的用戶、已清除的緩存或第一次登錄的用戶。 其次，我們有一個State/Page ，它是一個實際的 GUI 組件，例如主頁或登錄窗口。 接下來是Action ，它是一種導致狀態改變的物理用戶交互。 讓我們看看這一點。

分析需求

這是我們的主頁，也就是國家。 我們有兩種可能的操作：註冊和登錄。

然後，我們有另一個狀態的登錄窗口。 這裡的操作是返回和登錄。 請注意，我們不會將輸入字段分類為操作。 非常歡迎您這樣做。 根據我的經驗，我發現在處理運行十分之幾的複雜系統時，維護起來有點困難，但對於簡單的應用程序，它可能非常適合。

最後，我們來到用戶成功登錄後將登陸的儀表板。在這裡，我們有三個操作——我們可以創建、編輯或刪除消息。

我們現在有足夠的信息來開始用戶流程。 讓我們總結一下我們所擁有的。 我們記下產品的狀態。 我們可以看到，有四個頁面：

1. 主頁
2. 登錄窗口
3. 註冊窗口
4. 儀表板

我們在每個可以與之“交互”的頁面/狀態上寫下我們的操作：

1. 主頁
   1. 登錄
   2. 登記
2. 登錄窗口
   1. 登入
   2. 取消
3. 註冊窗口
   1. 待定（取決於產品）
4. 儀表板
   1. 創建
   2. 編輯
   3. 刪除

我們從Product Name開始，它可以更改以適應您的環境，但這適合大多數團隊及其產品，也提供了一個很好的起點。 下面，我們會注意到Register旁邊有一個問號。

很多時候，您會遇到敏捷中的一個組件，該組件尚未在範圍內或計劃用於未來版本。 請注意它的存在，但在我們獲得更多信息之前將其保留為未知數。

繪製流程圖

我們在 XMind 中畫出上面的樣子：

你會注意到我只是用顏色編碼什麼是狀態和什麼是動作。 我還在主頁中添加了取消操作中的一行以準確表示該流程。 當用戶選擇“登錄”時，我們還會看到兩個條件。 儘管兩者都進入儀表板，但我們仍然想測試這兩種可能的情況。

XMind 的好處是，如果我們在一個大型、複雜的應用程序上工作，我們可以創建不同層次的圖表，所以如果你想將流程分解為多個流程但保持它們鏈接，鏈接很容易做到分開工作表的主題。 您可以選擇插入超鏈接，並從嚮導彈出窗口中選擇操作導致的“狀態”。 這意味著如果您在 XMind 上選擇“登錄”並且它超鏈接到“儀表板”，您的鼠標光標將跳轉到“儀表板”，即使它在不同的工作表上。 很酷。

我們的流程缺少的是標籤。 我們給產品一個標籤 0，因為這是流程的根。 然後，為每個狀態（藍色）添加一個 S# 標籤，為每個動作（綠色）添加一個 A# 標籤，最後，為每個條件（青色）添加一個 C# 標籤。 每個標籤必須是唯一的。 我們最終得到以下結果：

要跟踪您上次使用的數字——因為隨著產品的增長，試圖找到最高數字可能具有挑戰性——我將其存儲在流程的根主題中，如下所示：

我們現在來到創建測試用例的部分。 我們將重點關注預期結果，這可能是測試用例中最重要的信息，也是功能驗收標準的一部分。 我將為每個部分或測試添加一個標題，然後在其下列出預期的結果。 我將只對一個子集執行此操作以保持本文簡潔：

然後，登錄窗口：

然後，登錄操作：

它真的正在成形。 注意添加的邊界和安全測試。 您可以隨意命名，以最容易標記的為準。 我有時會用測試類型標記標題，例如安全 - JS 注入 - 電子郵件字段，然後在下面列出預期的結果。

在大多數團隊中，我們發現不斷變化的需求很難維護。 不再。 假設我們剛剛了解到，所有首次使用的用戶都必須看到 Ts 和 Cs 窗口，並且必須在繼續訪問他們的儀表板之前接受 - 沒問題。 我們可以相對容易地添加狀態和動作，如下所示：

我們現在看到了添加新狀態的影響。 請注意，編號一開始可能很奇怪，但只要我們記得，編號只是用來唯一標識每個參與者——很像數據庫中的主鍵。 不要忘記更新您的“上次使用”筆記以跟踪您使用的數字。

從流中創建測試用例

在所有這些進展之後，我們現在進入更簡單的部分：測試用例創建。 讓我強調一些要點。 我們有每個演員的標籤，我們有每個測試的標題，我們有每個測試的預期結果，並將條件嵌入到我們的流程中。 這聽起來像是測試用例的秘訣，你不同意嗎？

我們現在所做的就是將流程中的內容複製粘貼到您希望的任何測試用例管理工具、Confluence 站點或 Excel 文檔中。 我仍然使用舊的可信賴的 Excel。 我將所有測試用例記錄在一個名為“基線”的文件中——非常原始。 完成複制粘貼後，我得到以下結果：

根據需要隨意添加測試類型、測試狀態和測試配置列。 條件最好放在“登錄”操作之前，但是，沒有正確或錯誤的方法，這取決於個人喜好和您如何組織自己。

有幾點需要強調。 一是我已經合併了共享相同信息的單元格——不需要重複複製粘貼，它浪費時間並且更難維護。 另一個項目是步驟。 您會注意到其中兩個測試包含包含狀態和操作編號的步驟。 當您將流作為團隊中 SDLC 的一部分時，可以使用此功能。 然後，所有利益相關者通過提供信息、模型、提高風險等來為流程做出貢獻。這意味著通過說明流程數字，團隊中的任何人都會知道該怎麼做，如果有新的團隊成員，這也很容易如“循序漸進，參考註釋”。

這也有助於自動化。 您可以為每個步驟或操作提供唯一的參考。 通過創建一個結構類似於您的流程的自動化包，您會發現您可以構建的自動化框架具有高度健壯、模塊化和跨應用程序兼容的潛力。 它將更大規模地使用分頁對象，這將減少維護時間並允許您將測試功能換成新功能。

流程可以是所有產品文檔的唯一真實來源，包括技術規範、功能規範、測試用例、狀態轉換、數據流等。

簡化的測試計劃方法

那麼測試計劃呢？你一定在想。 這很簡單。 測試計劃包含以下部分：

1. 簡介和範圍
2. 測試項目
3. 要測試的功能
4. 無需測試的功能
5. 假設
6. 進入標準
7. 退出標準
8. 工作分解結構
9. 風險
10. 環境要求

簡介和範圍將是 JIRA 故事或其他工具中的任何任務或故事。 測試項目只是當前部署在您的環境中的軟件版本或提交編號，您可以鏈接到 JIRA 票證或在 Confluence 或測試管理工具上運行的測試。

要測試的功能和不測試的功能實際上是您的測試用例。 為這個 JIRA 故事選擇執行的測試用例是“要測試的功能”，任何未列出的都是“不要測試的功能”。 很簡單，列出您將在故事票證上測試的狀態和動作。

假設、風險甚至環境要求可以編譯到文檔中或添加到 JIRA 的評論中，有時甚至可以放在 Confluence 上並鏈接到故事。

WBS 是您根據故事點或小時數分配給故事的估計值，具體取決於您的項目。 進入和退出標準已經成為故事的一部分。

如果你想接近“傳統”的測試計劃，你可以要求開發人員或其他利益相關者用是或否來評論這個故事，看看他們是否同意 QA 計劃。 這在技術上用作您的數字簽名。 所有這些都可以很容易地包含在您的 QA 流程中，並幫助您簡化 QA 文檔。

我們學到了什麼？

採用上述方法和簡化測試計劃以使用當今可用工具的用戶流程將幫助我們減少重複性工作並幫助 QA 在不犧牲質量的情況下實現更快的周轉時間。

這種方法有助於指導我保持井井有條，涵蓋每一個基礎，並構建整個團隊都能理解的文檔。 在敏捷中，這真的會派上用場，其中最好的部分是我們仍然遵守敏捷方法之一： “簡化文檔”。

我真的希望這些信息對您有所幫助。 這完全取決於你作為讀者。 這不是一套要遵循的具體規則，這些只是為您提供發展和提高效率的想法的指導方針。 沒有一種技術適合每個項目、團隊或產品，但它可能為另一個創新想法鋪平道路。