我們最近回答了很多關於使用的問題Jira用於測試用例管理．從如何使用Jira進行測試到哪些解決方案最能補充Jira過程，Jira和測試似乎都是最近的話題。

在最近的一項Tricentis民意調查中，66%的受訪者表示在過去的幾個月或幾年裏使用過Jira，這種流行並不一定令人驚訝。

那麼，在使用Jira進行測試用例管理時，您究竟需要知道些什麼呢?這篇指南將帶你完成從湯到堅果的所有事情，包括:

1. 使用Jira進行測試的挑戰
2. 如何定製Jira測試
3. 嚴格使用Jira進行測試用例管理的利弊
4. 集成測試工具與Jira的選項
5. 找到適合你需要的最佳溶液組合的技巧

快速的;關於Jira的背景

對於那些不知道的人，Jira是來自Atlassian的問題和項目跟蹤軟件。目前，它是敏捷團隊使用的頭號軟件開發工具，隨著敏捷采用的持續增長，越來越多的組織引入了Jira。的最近首次公開募股以及大量的公司離開了遺留的ALM提供商隻是推動了Jira的廣泛采用。

盡管JIRA是為問題和項目跟蹤而設計的，但許多團隊都將其用於測試用例管理，以便開發和測試可以保持在一個係統中。但是JIRA是如何進行測試的呢?讓我們來看看。

使用Jira進行測試的挑戰

回到JIRA如何為測試設置的問題，簡單的答案是JIRA不是。實際情況要複雜得多，特別是考慮到今天有多少組織正在使用它進行測試。

當您開始研究如何在Jira中構建測試流程時，最常見的起點是問題類型。你會看到Jira有幾種不同類型的問題(Bug, Epic, Improvement)，但沒有專門用於測試的問題。這是因為Jira不是一個測試用例管理解決方案。它實際上是用於問題跟蹤的。

你可以以某種方式定製Jira，將其用於一些測試用例管理過程，但這些都是臨時定製，因此有局限性。例如，在Jira內部構建的每個工作流都有一個端點“done”。但是在測試中，即使你完成了一個測試，也並不意味著你真的完成了這個測試。

這種設置意味著，如果您為測試用例管理定製Jira或某些問題，您將總是發現自己移動到完成狀態，而一旦測試執行，您可能還沒有“完成”。您真正想要的是能夠將該測試用例用於多種類型的測試，不管它是為了什麼回歸測試或者在不同的參數和配置下運行相同的測試用例來驗證一個新特性。然而，由於Jira問題總是被推到“完成”，您在重用問題進行測試的靈活性方麵受到了限製。

Atlassian自己關於Jira的文檔說，它可以用於手動測試、驗收測試等，但它明確警告說，Jira中沒有簡單地內置特定於測試的功能。此外，如果您正在使用任何類型的自動化，則需要使用另一種解決方案。

即使使用手動測試和驗收測試，也有一些限製。讓我們假設Jira在運行手動測試用例方麵做得非常好。它可能在某一時刻起作用，或者用於一個全新的功能，但當你將其移至完成狀態時，接下來會發生什麼?如果您想要做回歸或基於會話的測試呢?您將如何跨項目重用這些對象，分配多個票據項並顯示覆蓋率?根據吉拉的設定，你不能。

如何定製Jira測試

盡管存在這些限製，許多團隊仍在使用JIRA進行測試用例管理，他們通常通過以下兩種方式中的一種來定製問題:添加“測試用例”問題類型，或者使用“用戶故事”。讓我們來仔細看看這些選項是如何工作的:

深入研究:添加“測試用例”問題類型

要通過添加“測試用例”問題類型來定製用於測試用例管理的Jira，您需要執行以下步驟:

1. 創建一個“測試用例”問題類型
2. 添加完成預期結果所需的步驟
3. 讓這個測試用例成為您需要做的測試的父問題
4. 創建子任務，並將該子任務標記為“Test Run”，以便執行測試
5. 在“test Run”子任務中輸入結果、受影響的版本、結果以及運行測試的受讓人

雖然這種方法在理論上可行，但在現實中它麵臨著幾個挑戰:

• 重新運行測試:如果您需要重新運行一個測試執行或者測試一個新版本，您需要添加更多的測試運行作為子任務，並且您必須在每次想要記錄該測試用例的曆史時添加一個子任務。
• 重用測試:使用測試用例管理，您經常需要重用測試運行，並查看這些測試運行的日誌，但是您不能重用JIRA中的子任務，因為它們被標記為“已完成”。
• 創建覆蓋率報告:因為所有的子任務都分配在一個父問題下，您不能將幾個測試運行分組到不同的配置並顯示覆蓋率報告。

深度挖掘:使用“用戶故事”

或者，您可以通過調整“用戶故事”來定製用於測試用例管理的Jira。以下是這種方法的工作原理:

• 創建一個用戶故事(這將作為測試用例，與第一個選項中的新父問題相同)
• 添加作為測試用例或引用回該用戶故事的測試運行的子任務
• 如果所有子任務都通過了，那麼用戶故事就可以投入生產了

這種方法再次提出了挑戰，因為子任務充當測試用例和測試運行。具體來說，它在以下方麵提出了挑戰:

• 重用測試:如果您想再次使用子任務，例如在回歸循環中或作為到另一個用戶故事的鏈接，它會變得複雜，因為用戶故事可能已經被標記為“完成”。
  • 注意:在Jira的工作流程中，所有標記為已完成的問題都會被關閉。如果您必須重新打開一個子任務，然後將其轉換為測試用例模板或測試用例類型，那麼您將以大量開銷維護而告終。
• 對齊測試用例:由於這種設置，如果您有多個連接到多個用戶描述的測試用例，對齊測試用例將變得極其困難。

嚴格使用Jira進行測試用例管理的利弊

正如上麵的例子所說明的，雖然Jira不是為測試而設計的，但是您可以定製它來滿足特定的測試用例管理需求。但是，你應該這樣做嗎?讓我們考慮嚴格使用Jira進行測試用例管理的利弊:

使用Jira進行測試用例管理的優點:

• 能夠創建自定義問題類型，例如測試用例
• QA、開發人員和測試操作的一個工作流
• 能夠使用現有的報表(Jira確實提供了出色的報表)
• 能夠使用已經購買和已知的工具(如果您已經安裝了Jira)
• 適合一次性手動執行

使用Jira進行測試用例管理的缺點:

• 不測試特定的功能(這是Atlassian自己調用的)
• 僅通過CI服務器與測試框架集成
• 無法創建覆蓋手動執行、自動化執行和基於會話的執行的測試用例覆蓋率報告
• 在問題和測試用例覆蓋之間沒有可跟蹤性報告
• 無法多次運行執行，這意味著大量的重複工作
• 測試周期和套件執行、測試步驟執行狀態、版本控製和環境配置方麵的限製

所有這些都意味著您通常使用測試用例和環境執行工具所做的事情，例如分組測試周期和測試執行，運行測試配置和處理版本控製，都不受支持。這讓你覺得:Jira真的是為測試而構建的嗎?還是你在強迫這個問題(沒有雙關語，因為在JIRA的一切都是一個問題)?在大多數情況下，你是在強迫問題，而且可能有更好的方法。

集成測試工具與Jira的選項

因為Jira不是為測試而設計的，所以在用於測試時，它會帶來許多限製。可以說，最大的限製是無法重用和集中測試工作。

所以，如果你已經過渡到Jira，你的開發人員喜歡它，你能做什麼?你的測試團隊有沒有辦法從Jira身上獲得價值?集成可以有所幫助。

因為Jira不是為測試而設計的，所以在用於測試時，它會帶來許多限製。可以說，最大的限製是無法重用和集中測試工作。

有兩種類型的集成可以用於向Jira添加測試功能:

1. 附加組件，它們是存在於Jira應用程序中的內部集成，並擴展了一些測試用例功能
2. 與專用測試用例管理工具的外部集成

讓我們仔細看看這些集成選項都需要什麼:

那麼Jira的應用程序和附加組件呢?

附加組件可通過Atlassian市場．一些常用的測試插件包括:

• 給吉拉照x光而且為吉拉獻西風用於手動測試執行(Xray也提供了一些BDD測試的功能)
• 表現的專業而且Tricentisqt的場景用於BDD、TDD和ATDD測試(這些最適合小型團隊或那些在JIRA中更多地采用敏捷2.0空間的團隊)

這些類型的附加組件擴展了Jira的功能，使其能夠更好地用於測試用例管理。例如，Xray自動將“測試”問題類型添加到問題列表，並允許您將測試用例步驟添加到測試問題類型。這種設置緩解了創建自定義問題類型的問題，該問題要求您添加包含已完成步驟和預期結果的批量部分(這反過來又給您留下了必須一次性完成的大量測試，並且無法逐行放入步驟失敗的位置、執行位置和實際執行情況)。

與此同時，如果您試圖進行BDD測試，則很難單獨在JIRA中遵循Gherkin“給定，何時，然後”語法，但像Tricentis qTest Scenario這樣的附加組件使其成為可能。Tricentis qTest Scenario允許您將點特性文件與您的場景一起作為問題類型導入，以便您不再需要創建標準問題類型。相反，您可以在場景片段中添加Gherkin風格測試腳本語言，然後您可以在其中創建一個點特性文件。您還可以創建附加到JIRA中的這些點特性文件的場景文件，這允許您將它們添加到用戶故事中。

使用附加組件的優點

通常，測試外接程序嚐試將Jira中發生的測試組組合在一起，以便您可以將所有測試用例拉入周期或套件中。它們還允許您查看每個分組的測試用例的最新執行結果，這創建了對測試執行分組的可見性。

使用附加組件來改進Jira的測試功能的其他優點包括:

• 保持與Jira相似的外觀和感覺
• 開始使用Jira內部的儀表盤
• 通過Atlassian Marketplace在線處理簡化購買
• 獲得測試特定功能的權限
• 獲得將測試對象鏈接到其他問題的能力

使用附加組件的缺點

雖然這些附加組件確實有很大的幫助，但在文本執行中可以做什麼和不能做什麼方麵，您仍然受到限製，因為基於Jira基礎設施所允許的附加組件功能是有限的。

例如，與您使用專用的測試用例管理解決方案相比，附加組件創建了更多的手動過程。此外，在外接程序中所做的一切僅限於手頭的特定項目，這意味著您不能將相同的問題放在多個項目中。

當您創建測試用例時，附加組件也會呈現一些版本限製。通常，如果您創建了一個問題並運行該問題，那麼運行隻是測試用例的複製。假設您在一個要運行的循環中的測試用例中有五個步驟，並且您添加了另一個步驟。Jira會自動將數據推入每個測試用例的運行中，這意味著您不能保留不同的版本。使用Tricentis qTest和其他一些工具，您實際上可以跟蹤測試用例的不同版本，並在執行時運行過去的版本，但是為了做到這一點，您需要有測試用例執行的一對一的版本曆史。

最後，當您使用附加組件時，測試用例等於Jira問題。它可能看起來不是這樣，但所有的附加組件都是這樣，而且這種設置會帶來限製。

其他使用附加組件來改進Jira的測試功能的缺點包括:

• 重用測試周期的可用性為零或有限(您可能能夠克隆一個測試周期，或者您可能不得不將測試用例移動到一個不附加到發布的特別測試周期中)
• 沒有邏輯文件夾結構
• 測試用例版本的未知更改曆史和對測試執行曆史的有限可見性
• 無法在Jira項目之間共享測試用例對象，這使得擴展變得困難，並創建了大量重複的工作，因為您不能使用不同的變量運行相同的測試
• 存儲大量測試結果數據的有限可伸縮性，當團隊過渡到自動化測試時，這經常成為一個問題

深入研究:專門的測試用例管理解決方案

大多數測試團隊都在努力提高效率。這通常是因為他們沒有使用正確的工具。專用的測試用例管理工具可以幫助提高效率，現在有許多工具提供了與JIRA的某種級別的外部集成，以便在允許您使用JIRA的同時為您的測試過程帶來更多特定於測試的功能。

大多數測試團隊都在努力提高效率。這通常是因為他們沒有使用正確的工具。

測試管理工具做什麼?

測試管理工具:

• 合並所有自動和手動執行:許多附加組件隻關注手動執行、BDD或TDD，但如果您正在進行Selenium自動化或自定義框架，您將希望以一種與JIRA通信的方式合並所有執行。一個專用的測試用例管理工具可以幫助您實現這個目標。
• 提供增強的執行設置和重用執行的能力:外接程序可以將測試用例分組到周期中，但它們不能將測試周期放在其他周期中，也不能有一個測試套件執行的周期。另一方麵，專用的測試用例管理工具可以做到這一點。這些工具還允許可伸縮性，這樣您就不必回到源記錄，複製和更改測試用例。
• 顯示Jira內部執行的整個曆史:通過顯示Jira內部執行的整個曆史，一個專用的測試用例管理工具可以幫助您確定測試用例在測試階段中的執行情況。這個視圖幫助您輕鬆地看到一些事情，比如為什麼一個測試用例失敗了。
• 允許您與多個項目共享測試用例:專用的測試用例管理工具還可以通過與多個項目輕鬆共享測試用例來消除測試用例的隔離。例如，用Tricentisqt，您可以有相同測試用例的多個測試運行，並且每個測試運行可以有不同的配置、環境設置、結果、受讓人等等，但是它們都可以綁定到相同的測試用例。這種設置允許您使用測試用例作為模板，而不必一遍又一遍地複製它。
• 提供企業可伸縮性:與Jira應用程序和附加組件不同，Tricentis qTest不依賴於Jira數據庫或數據結構來存儲數據。要了解更多關於Jira的存儲限製，閱讀我們的實驗結果與Jira服務器和一個常見的測試管理應用程序．

使用專用的測試用例管理工具的優點

通過提供上麵描述的功能，集成一個專用的測試用例管理工具可以大大改善Jira中的測試。這種方法的優點包括:

• 訪問企業測試功能，如配置管理器、與Jenkins和Bamboo的CI集成以及自動化測試支持
• 能夠使用基於模板定製的測試用例存儲庫
• 能夠在不同的項目中重用測試用例和共享對象
• 支持多種測試策略

使用專用的測試用例管理工具的缺點

盡管將專用的測試用例管理工具與JIRA集成可以提供所有的價值，但它仍然有其局限性。這種方法的缺點包括:

• 在工具和Jira之間處理固定的數據庫同步(後麵會詳細介紹)
• 管理工件映射的權限
• 解決瀏覽器限製(例如惠普要求Internet Explorer)
• 沒有和Jira完全融合
• 在專用的測試用例管理工具中圍繞不同程度的開源友好性工作

考慮到這些缺點，有幾個要點需要考慮，以幫助確定與專用測試用例管理工具的外部集成是否利大於弊:

• 您的團隊是否擁有廣泛的測試方法?如果您是一個隻做手動測試的小團隊，並且沒有推動自動化，那麼一個附加組件或Jira本身可能就可以工作。然而，如果您有廣泛的測試方法，您可能需要一個專用的測試用例管理工具。
• 您的測試策略是否保證使用企業級測試工具?如果這是您需要的東西，那麼外部集成就是正確的方法。如果它隻是一個很好的擁有，一個附加或Jira單獨可能工作。

兩全其美

雖然專用的測試用例管理工具為Jira內部的測試提供了最佳體驗，但它通常仍然存在一些缺點。然而，在企業測試用例管理工具和Jira之間獲得兩者的最佳效果是可能的。

實現這種平衡的關鍵是理解並非所有集成都是平等的，並確定為您的需求提供最佳集成體驗的解決方案類型。例如，大多數測試解決方案使用計劃同步,但Tricentis qTest Manager有一個實時集成，使用webhook。

通過計劃同步，您必須將整個測試用例管理工具模式映射到JIRA模式，這意味著您必須不斷地提取數據並使用資源來保持係統的最新狀態。計劃同步也容易出現延遲，由於api不斷試圖找出更新了什麼，如果發生任何計劃衝突，則會導致數據損壞，因此性能較差。所有這些都需要大量的資源來管理集成。同時，通過實時同步，您可以獲得項目(及其問題，無論它們是用戶故事、史詩、子任務等等)和JIRA之間的直接映射，然後您可以顯示針對這些問題的測試用例覆蓋率。這種實時同步為缺陷、瀏覽器自動化和嵌入式報告提供了直接提交到JIRA的機會，此外，由於JIRA始終是用戶故事和缺陷的源記錄，因此它確保了數據的準確性。的real-time sync option keeps both developers and testers happy because it allows everyone to keep doing all of their updates inside of Jira and only requires you to pull the issues that you care about into the test case management tool, where you can then create test cases and test runs and map those to the requirements from Jira. Once you’ve executed those runs, you can simply push the defect back out to Jira to interact with it and start working on a resolution. This allows everyone to keep doing all of their updates inside of JIRA and only requires you to pull the issues that you care about.With this type of integration in place, your developers can stay inside of Jira (rather than going to another tool to see everything) and your testers gain access to the enterprise features that are missing from a lot of the add-ons that are available — all without a complicated, time-consuming integration to manage. In other words, you get the best of both worlds.

哪種選擇對您的組織是正確的?

最終，哪種解決方案組合——隻有Jira, Jira加上一個插件，還是Jira加上一個外部集成——適合您的團隊，這在很大程度上取決於您的團隊規模和您所做測試的類型。

為了幫助您確定最適合您需求的解決方案組合，我們在下麵的圖表中列出了我們的建議: