TestRail - 項目的單獨設置

介紹

在我參與的許多專案中，人們並沒有為自己客製化 TestRail，而是使用標準設定。 因此，在本文中我將嘗試描述一個可以幫助您提高工作效率的單獨設定的範例。 例如，我們以一個行動應用程式開發專案為例。

一個小小的免責聲明。 本文不包含 TestRail 基本功能的描述（有很多關於此的指南）和銷售表達式，生動地描述了為什麼您需要選擇這個特定的供應商來建立具有測試的儲存庫。

論證計劃（將實施什麼）

1. 一般要求

   1. 絕對任何人都應該能夠通過此案。

   2. 案例應盡可能長時間地保持相關性

   3. 案例應盡可能全面地涵蓋行動應用程式的功能，以免與前兩點相矛盾

2. 分為測試案例和測試場景

3. 快速生成各種類型的TestRun

   1. 抽煙

   2. 回歸

   3. 衝擊試驗等

4. 案例支援優化

   1. 放棄“死”硬編碼螢幕截圖，轉而使用“可移動資料”

資格

要編輯字段，您需要管理員存取權限

選擇項目類型

有三種項目類型可供選擇：

我們將選擇預設類型。 所有案例都將同時在其中提供。 我們將使用智慧過濾並一次動態管理所有案例。

新增欄位以查看測試案例列表

讓我們新增一個欄位來顯示優先權測試用例：

您也可以新增其他欄位。

設定測試用例欄位和標籤

開啟設定選單：

我們將需要以下欄位：

「摘要」欄位（測試案例標題）

這個領域已經存在，我們只是系統化它的使用。 我們將用例分為TestCase和TestScenario。 為了提高大量案例的可讀性，最好事先就撰寫摘要的規則達成一致。

測試場景：

範例：TestScenario - 使用行動應用程式的基本場景

測試用例：

範例：主畫面 - 授權部分 - 輸入登入名

總的來說，我們在案例的總結中看到了經典的理解：「什麼、哪裡、何時」。 我們還以最適合自動化的形式在視覺上分離高級測試腳本和低階測試案例。

「StartScreen」標籤（TestScenario 開始的畫面；此外，許多測試案例可以接觸相鄰的螢幕）

對於可能需要的內容：我們將從文字中刪除引導使用者進入目前測試案例畫面的典型步驟的文字。 （建立特定測試情況的典型步驟）所有測試案例的所有典型步驟將寫入一個檔案中。 我會單獨寫更詳細的內容。

建立一個新字段：

填寫新欄位的組成部分：

在本例中，我們從值清單中建立一個選擇欄位。 輸入該欄位的值：

請注意，id值不以XNUMX開頭且不連續。 為什麼要這樣做？ 關鍵是，如果我們有記錄了輸入的 id 的測試案例，

之後我們需要在兩個現有螢幕之間創建第三個螢幕，

那麼我們將不得不重寫 id，並且由於現有文字案例的標籤已經附加到它，因此它們將被簡單地刪除。 這將是非常不愉快的。

標籤“Screen”（影響測試案例的螢幕名稱）

您可能需要什麼：衝擊測試的錨點之一。 例如，開發人員製作了一項很酷的新功能。 我們需要對其進行測試，但為此我們需要了解此功能到底會影響什麼。 預設情況下，我們可以從以下範例開始：應用程式的不同螢幕（活動）具有不同的類，因此構成應用程式的不同元件。 當然，在這種情況下需要採取單獨的方法。

範例：home_screen、MapScreen、PayScreen 等。

「MovableData」欄位（連結到具有可變更測試資料的代理資料庫）

接下來，我們將嘗試解決測試案例中保持資料相關性的問題：

1. 連結到當前佈局（這比截取死截圖要好得多）

2. 進入測試狀況畫面的典型步驟

3. SQL查詢

4. 外部數據和其他數據的鏈接

我們不會在每個測試用例中寫入測試數據，而是建立一個外部文件，並在所有測試用例上連結到該文件。 更新此資料時，我們不必遍歷所有測試案例並更改它們，但可以僅在一處更改此資料。 如果有人毫無準備地打開一個測試用例，他會在測試用例的正文中看到一個文件的鏈接，並提示他需要訪問該文件以獲取測試數據。

我們將把所有這些資料打包到一個外部文件中，專案中的每個人都可以使用該文件。 例如，您可以使用 Google Sheet 或 Excel 並在文件中設定搜尋。 為什麼選擇這些特定的供應商？ 事實上，我們從這樣的範例開始：團隊中的任何人都應該能夠打開並通過測試案例，而無需先安裝任何工具。

為 Google表格 您可以使用 SQL 查詢。 例子：

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

為 Excel 您可以設定方便的即時搜尋巨集。 （過濾）範例 鏈接.

實際上，這個想法並不新鮮，在第一個測試人員的書“Testing dot com”中有所描述。 （作者 Savin Roman）我們只是將 Roman Savin 提出的方法整合到 TestRail 中。 為此，請建立一個包含指向所建立文件的連結的欄位：

填寫連結的預設值，以便每個新的測試案例已經有一個連結：

如果外部文件的位置發生變化（我們提供任何不可抗力的情況），那麼您可以輕鬆地在所有測試案例中一次更改一個或多個欄位：

欄位「描述」（測試案例的描述或想法，標準說明）

您可能需要什麼：在此文字欄位中，我們將放置測試案例和標準說明的簡短描述。

示例： 此測試案例中的所有測試資料（目前佈局、工具的使用和其他資料）均由連結 {...} 指示，並位於 MovableData 檔案中。 連結到頂部對應欄位中的 MovableData。

標籤“組件”（行動應用程式組件）

可能需要什麼：用於衝擊測試。 如果一個行動應用程式可以分為多個元件（彼此影響盡可能小），那麼一個元件中的變更就足以在同一元件內進行檢查（存在一些風險），並且執行的理由就會更少一切事物的普遍回歸。 如果有資訊表示一個組件可能影響另一個組件，則編制影響測試矩陣。

範例組件：GooglePay、訂單、使用者、地圖、授權等。

標籤“TAG”（用於過濾的其他標籤）

使用標籤標記測試案例以進行任意過濾。 

對於以下方面非常有用： 

1. 快速編譯各種典型任務的 TestRun：冒煙、回歸等。

2. 測試會自動化還是已經自動化？

3. 任何其他標籤

範例：Smoke、Automated、WhiteLabel、ForDelete 等。

設定測試案例中欄位的顯示順序

我們創建了很多新字段，是時候以方便的順序排列它們了：

建立測試運行

現在，我們將使用當前案例建立一個新的測試運行，只需單擊三下即可進行冒煙測試：

其他有用的提示

1. 如果 TestRail 有多個項目，那麼不要忘記僅為您的項目創建新字段，否則相鄰團隊的同事會對新的不尋常字段的出現感到非常驚訝。 可能會出現局部昏厥。

2. 具有大量欄位的案例從相似的群組類型中複製比創建新的更容易：

3、帳號可以共享。 例如：一名管理員，多名使用者。

結論

上述範例已在多個專案中實施並顯示其有效性。 我希望它們能幫助您提高對這個工具的理解，並幫助您創建有效且方便的「測試儲存」。 如果您在評論中描述您使用 TestRail 的經驗和有用的提示，我將非常感激。

引用：

TestRail 供應商網站

書： 「測試 .COM」（作者 Roman Savin）

非常感謝您的關注！

來源： www.habr.com