.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
測試軟件的性能可能非常耗時。不斷檢查和修復失敗的測試或錯誤會花費大量時間，並且需要質量保證(QA) 團隊付出大量努力，尤其是當他們手動進行時。
為了節省時間並仍然提供高質量的結果，許多項目旨在自動化他們的測試工作。我們謹慎地開發自動化測試策略並使用TestRail 來管理自動化測試結果。
本文將通過分享我們在使用此工具時的策略，幫助您了解如何借助TestRail 提高QA 流程的效率。
為什麼要管理自動化測試結果？為確保有效的自動化測試，您需要製定測試管理策略並為您的項目選擇合適的技術和測試覆蓋率。這將為您提供自動測試結果的透明度、對這些結果的有效分析和管理，以及處理脆弱測試的策略，這些測試在大多數時間都有效。
實施測試自動化時最常見的問題之一是缺乏對自動測試結果管理的關注。管理自動化測試的結果是構建高效測試策略不可或缺的一部分。從長遠來看，它可以幫助您顯著縮短重複的手動測試過程並優化您的QA 費用。
最壞的情況是當您在自動質量保證(AQA) 環境中本地運行測試並且它們沒有集成到持續集成和持續部署(CI/CD) 管道中時。在這種情況下，您無法控制自動測試的定期運行或其結果。隨著時間的推移，或者在更改AQA 環境之後，自動測試可能永遠不會再次運行，並且它們之前的結果可能會丟失。因此，專門用於編寫和運行這些測試的資金和其他資源可能被證明是白費了。
在更成熟的流程中，QA 工程師和開發人員將自動測試集成到CI/CD 管道中。 QA 專家定期在測試環境中運行測試，並將結果匯總在一份報告中。通常，自動化測試團隊獨立於手動測試團隊工作。因此，手動測試及其結果與自動測試分開監控。這有一些負面影響：
您需要在多個地方努力管理測試結果
存在不及時響應失敗的自動測試的風險
有時，人工和自動化QA 專家對監控自動測試結果的職責模糊不清，這可能導致測試結果未被處理甚至丟失。此外，手動和自動QA 專家的職責不明確使計算自動測試覆蓋率的過程變得複雜，而自動測試覆蓋率是管理測試自動化的最重要指標之一。
現在，讓我們看看可以將測試自動化工具集成到測試過程中的不同情況。
您可以使用測試自動化工具實現什麼？通過將自動測試管理工具集成到QA 部門的工作中，您可以監督很多事情。
您可以使用自動測試自動化工具做什麼
自動化測試場景。自動測試管理工具為您提供了一種存儲自動測試場景以供將來使用的便捷方式。例如，如果您使用行為驅動開發或基於關鍵字的測試自動化方法，您可以為每次測試運行從存儲中檢索自動化測試場景。
測試執行過程。在測試用例的執行過程中，自動測試管理工具提供了許多組合測試的選項：順序執行、優先級排序、並行執行等。根據測試項目的要求、資源和目標，您可以選擇最佳選項並將其集成到您的自動測試管理工具中。
測試執行結果。許多測試管理工具允許您在測試運行後生成報告。這些報告有很多可視化組件，包括執行結果、失敗的測試和失敗的原因，以及總執行時間。
測試執行歷史。您所有的測試運行結果都已存儲並可以隨時檢索。您還可以根據所選工具的功能使用不同參數生成所有執行的統計信息。
為了優化自動測試結果的監控和管理，Apriorit 團隊採用了一種綜合方法，結合了手動和自動測試活動。作為這種方法的一部分，我們：
確保負責手動和自動測試工作的QA 專家作為單個團隊的一部分不斷聯繫
使用單一工具管理手動測試和自動測試
有幾種流行的自動測試結果管理工具，包括TestRail、Zephyr、QMetry 和Testmo。根據我們的經驗，我們更喜歡使用TestRail，因為它具有以下優勢：
TestRail的優勢
Jira 測試集成。我們使用Jira 作為我們的主要進度跟踪軟件，因此將TestRail 與Jira 一起用於測試自動化對我們團隊來說非常方便。
能夠管理手動和自動測試。這提高了我們QA 團隊的工作效率，使他們能夠及時響應失敗的測試。
測試用例統一。這使我們能夠以一種適合我們的單一格式使用測試用例，並以相同的格式自動從TestRail 導出測試用例。在我們導入現有的測試用例或創建新的測試用例後，TestRail 會將選定的模板應用於所有可用的測試用例。
用戶友好的用戶界面。 TestRail 不僅在視覺上很吸引人，而且使用起來也很直觀。
現在讓我們來看看我們在TestRail 中管理自動化測試結果的策略。
如何在TestRail中處理自動化測試結果我們基於左移方法開發了自己有效的QA 策略。
該策略的好處包括：
質量保證活動的時間和成本節省
更快的上市時間
改善用戶體驗
令人滿意的產品性能
作為我們有效的自動化策略的一部分，我們在策略實施之前的早期測試階段建立了自動測試覆蓋率。完成測試設計階段後，我們分析哪些設計的測試用例應該被自動測試覆蓋。所選測試在TestRail 中的類型字段中標記為自動。
指定測試用例類型可以讓我們在TestRail自動化測試時，所有的自動測試都有對應的測試用例。通過這種方法，運行自動測試和監控其結果的過程變得可控和透明。由於我們為每個自動測試都有一個相應的測試用例，並且我們知道如何在TestRail 中自動創建測試運行，因此我們可以按如下方式最終確定我們的自動測試結果管理策略：
Apriorit 自動測試結果管理策略
首先，我們為每個構建運行自動測試作為CI/CD 管道的一部分。
成功構建後，我們將新的自動測試版本發送到單獨的測試台以運行自動測試。
每次運行時，我們都會在TestRail 中形成一個新的測試運行，添加所有自動化類型的測試。
形成一個新的試運行後，我們按照一個模板來命名，這樣我們就可以很方便的了解試運行的版本和時間。例如，我們使用以下模板：Acceptance_Automation_Run_
完成自動測試後，每個測試的狀態都會在測試運行中自動輸入- 通過、失敗或未測試。
我們完成所有測試運行。之後，我們會收到一條通知，其中包含指向新測試運行的鏈接。
最後，我們審查通過測試的結果並分析狀態為“失敗”或“未測試”的測試。
在處理狀態為“失敗”或“未測試”的測試時，我們還使用定義的工作流程：
我們為回溯系統中所有失敗的測試創建錯誤票。我們的團隊總是重新檢查失敗的測試，並在錯誤報告中包含有關手動檢查結果的信息。
我們始終將修復錯誤或失敗的測試放在首位，即使它無法手動重現。我們這樣做是因為對我們來說，不正確的工作或失敗的測試與成品中的錯誤具有相同的優先級。
我們還為狀態為Untested 的測試創建錯誤票。一旦我們在測試運行中包含了自動類型的測試，它們就必須被覆蓋並且應該定期執行。如果有測試但我們團隊還沒有執行，這也是與產品bug同等優先級的問題。
因此，我們創建了一個透明的系統來監視和控制自動測試啟動的規律性和自動測試的結果。整個團隊，從AQA 和手動QA 專家一直到開發人員和管理人員，都可以收到有關測試啟動的通知並輕鬆查看測試運行的結果。
AQA 和手動QA 專家都可以查看測試結果和在失敗測試中註冊的錯誤。一切都是完全透明的，測試過程的所有參與者都可以訪問。現在我們已經解釋了我們在TestRail 中處理自動化測試結果的策略，是時候將TestRail 自動化集成到您的QA 流程中了。
如何將自動測試結果與TestRail 集成（實例）如果您想將自動測試結果與TestRail 集成，您可以使用與您在編寫自動測試時使用的技術相對應的現成插件。我們在下面的示例中展示的方法適用於Python 測試和Cypress 測試。
我們建議在每次運行自動測試時創建一個新的測試運行，因為它比運行單個測試更方便。這樣，您就不會丟失任何重要信息，例如測試執行日期和失敗測試統計信息。為了在每次運行自動測試時創建一個新的測試運行，我們在TestRailAPI 上實現了一個包裝器。
讓我們仔細看看每個使用的插件。
集成Python 測試您可以使用pytest-testrail插件將TestRail 和自動化測試集成到您的QA 流程中。
當您運行Python 自動測試時，您需要指定報告者和測試運行ID。
例如：
python-mpytest--testrail--tr-run-id=111自動測試標記為@pytestrail.case(*testrail_case_id*)。執行測試後，相應的測試狀態將添加到測試運行中。
在測試運行執行期間，我們使用來自testrail.cfg 文件的數據，其中包含以下參數：URL、憑據、project_id、suite_id 等。
以下是Python 測試的配置文件的樣子：
Python
[API]
url=https://yoururl.testrail.net/
email=user@email.com
password=
[TESTRUN]
assignedto_id=1
project_id=2
suite_id=3
plan_id=4
description='Thisisanexampledescription'
[TESTCASE]
custom_comment='Thisisacustomcomment'現在讓我們看一下將Cypress 測試集成到TestRail 中。
您可以使用TestRail Reporter for Cypress將Cypress 測試集成到TestRail 中。
您需要在TestRail Cypress 測試中包含測試用例的ID。在執行Cypress 測試時，您可以自動從cypress.json 文件中獲取數據。此數據包括以下參數：reporter、testrail URL、credentials、project_id、suite_id、run_id 等。
例如：
JavaScript
.
'reporter':'cypress-testrail-milestone-reporter',
'reporterOptions':{
'domain':'yourdomain.testrail.com',
'username':'username',
'password':'password',
'projectId':'projectIdNumber',
'milestoneId':'milestoneIdNumber',
'suiteId':'suiteIdNumber',
'createTestRun':'createTestRunFlag',
'runName':'testRunName',
'runId':'testRunIdNumber',
}為方便起見，您可以在每次測試運行結束時自行生成包含關鍵指標的報告。接下來，我們關注這些指標及其含義。
如何理解TestRail 中的重要指標將TestRail 用於您的QA 流程，除了提供自動測試的透明度和可控性之外，還可以輕鬆收集重要指標並跟踪其動態。執行測試運行後，您可以隨時在TestRail 中查看有關測試的結果和重要信息。
我們建議在報告中關注兩個重要指標：
主要的TestRail 指標
1. 自動化覆蓋率是自動測試覆蓋的測試用例的百分比。當您使用TestRail 管理自動化測試用例時，它們都有一個單獨的類型。您可以輕鬆計算驗收測試覆蓋率百分比以及整體自動化覆蓋率。
要了解自動測試的數量和百分比，請轉到“報告”選項卡。選擇名稱並為您的報告添加描述。之後，選擇Report Options中的Grouping選項卡並按Type對測試用例進行分組。
截圖1. Property Distribution 報告
最好定期生成Property Distribution 報告以監控指標動態，這將使您的團隊能夠控制自動測試覆蓋範圍的增加或縮小。
2. 每個測試的成功率是特定測試的通過/失敗狀態的百分比。在TestRail 報告的幫助下，您可以跟踪特定測試失敗的次數，並關注最常失敗的測試。
要在TestRail 中分析失敗的測試，首先轉到Reports選項卡。輸入名稱並為您的報告添加描述。之後，在Report Options 中選擇Failed狀態。
屏幕截圖2. Status Tops 報告
完成這些操作後，您將看到最常失敗的測試。
在分析失敗的測試時，您可以將它們分為兩類：
片狀測試（不可靠、脆弱的測試）——不穩定且經常失敗的測試，沒有明顯原因給出誤報結果，而不是發現實際錯誤。我們將在下一節中詳細描述使用此類測試的策略。
不穩定的測試或用例——損壞或有問題的測試或用例。這些測試表明您的模塊中有脆弱的代碼，您的QA 團隊可能需要重構它。
您需要立即解決並嘗試修復任何無緣無故失敗的測試，以免它拖延開發過程並在未來佔用您的QA 專家的時間。讓我們仔細看看如何處理這些不穩定的測試。
如何管理不穩定的測試不穩定的測試需要QA 專家的特別關注，他們處理自動測試、分析每個測試運行的結果，並為每個失敗的測試發布錯誤報告。不穩定的測試可能需要QA 專家付出大量努力，包括每次測試運行所花費的時間和資源、失敗測試的手動分析以及修復測試所花費的時間。
為了減少花在不可靠測試上的時間，您需要在自動測試管理策略中明確描述使用此類測試的策略。在Apriorit，我們有一個處理不穩定測試的清晰策略：
如何管理片狀測試
步驟1.首先，我們在這種特殊情況下定義了一個不穩定的測試。在我們的實踐中，如果某項測試連續三次出現誤報，我們就會認為該測試不穩定或不可靠。
第2 步。我們嘗試通過修復它來穩定flaky 測試。
第3 步。如果在嘗試修復它後，測試仍然失敗並給出誤報結果，我們可能需要刪除自動測試並更改TestRail 中的測試用例類型。
如果測試不可靠並且您無法穩定它，它就會成為您的QA 團隊的負擔。當測試不可靠並且您不能相信其結果時，最好盡快修復它或將其刪除。這樣，您就不必花時間支持和監控易碎測試的結果並手動檢查它們。
現在您有了處理不可靠測試的明確計劃。因此，您可以確信您的QA 團隊不會在此類測試上浪費太多時間和精力。
結論您可以將我們的示例作為QA 流程的基礎，並根據您的需要進行調整。使用TestRail 進行自動化測試結果管理可讓您顯著改善質量保證工作。在TestRail 的幫助下，您的QA 團隊可以減少在測試運行上花費的時間和資源。您還可以在TestRail 中跟踪您的結果，從而更有效地管理您的測試運行並處理失敗的測試和錯誤。