1. 簡介
Telerik Test Studio （以下稱Test Studio）是一個易于使用的自動化測試工具，可用于Web、WPF應用的界面功能測試，也可以用于API測試，以及負載和性能測試。
Test Studio支持無代碼的方式創建測試，也可以基于代碼創建，或者兩者混合，無論哪種方式，都將始終確保最佳的應用質量并提供出色的結果。
Test Studio 為整個團隊提供測試自動化解決方案，使從初級測試人員到高級開發人員、產品經理和 QA 主管的每個人能夠在敏捷的軟件交付環境中實現最高的工作效率。
2. 特色
2.1 適應不同需求
Test Studio 旨在適應您的整個團隊。
Test Studio 的可視化測試記錄儀是經驗不足的 QA 的理想工具，這些 QA 旨在從手動測試切換到自動測試。他們可以在幾天內開始創建自動化測試，而無需編寫代碼。
Test Studio 的嵌入式 C# 或 VB 代碼編輯器允許更有經驗的測試工程師進入測試代碼并創建高級代碼內操作。
另一方面，團隊中的軟件工程師可以利用內置的Visual Studio擴展，使他們能夠訪問Visual Studio中的相同測試項目并與QA協作。
2.2 專有技術支持
Test Studio不是基于Selenium或其他開源框架，而是基于專有技術 - Telerik Testing Framework。它是一個由 Progress 支持的基于 .NET 的框架，它不斷進行更新，以支持新的 Test Studio 功能的開發。借助底層測試框架，Test Studio內部支持編寫基于 C# 或 VB 的自動測試。
2.3 支持測試全面
Test Studio 支持各種功能性 UI 測試，涵蓋任何 Web 技術 — 整個 Web .NET 堆棧，包括傳統和現代技術（如 Blazor、WPF 桌面）以及基于 JAVA 腳本的前端技術（如 Angular、React 和 jQuery）。使用 Test Studio 自動執行頻繁和重復的測試不僅支持高效且經濟高效的回歸測試，而且還使您能夠為需要測試的所有環境設置測試。
Test Studio 還支持負載和性能測試，允許您將功能轉換為負載測試，或者從頭開始輕松構建負載測試，無需代碼即可基于 Fiddler Everywhere 日志。通過 Test Studio 中的 API 測試功能，您可以針對所有常見的 RESTful API 請求創建驗證，并可以將 API 測試用作自動化 UI 測試中的步驟。
2.4 滿足CI/CD需要
由于Test Studio的集成功能，測試可以安排為作為任何CI / CD設置的一部分運行，在使用Microsoft托管代理的Azure管道中運行，甚至在Docker容器中運行。
3. 版本及許可證
3.1 Test Studio
Test Studio 是一個獨立的應用程序，根據購買的許可證，以兩種不同的格式提供：
Test Studio Web & Desktop 許可證包括 Web 和 WPF 測試記錄和執行、內置計劃解決方案、基于 Web 的集中式結果儀表板。此許可證提供Test Studio的主要功能。
Test Studio Ultimate 許可證在主要功能之上添加了負載測試和 Rest API 測試模塊。
3.2 Test Studio VS 插件
Test Studio Web & Desktop 和 Ultimate 安裝都包含 Visual Studio 的 Test Studio 插件。
3.3 Test Studio 運行時加載項
Test Studio 運行時加載項包括該工具的運行時組件。它旨在僅執行已開發的測試，建議用于在 Test Studio 內置計劃解決方案中配置的 CI/CD 生成服務器和執行計算機。
Test Studio運行時加載項許可證將針對將要安裝的每臺計算機單獨購買。
3.4 Test Studio Dev Edition
Test Studio Dev Edition 是 Visual Studio 的 Test Studio 插件，作為 DevCraft Ultimate 產品捆綁包的一部分進行分發。它提供了開箱即用的功能，以促進更輕松，更快速的測試自動化，特別是Telerik DevCraft構建的應用程序。無論復雜性或交互性如何，都可以輕松測試 .NET 應用，并跨 Web 和桌面無縫設置穩定的質量級別。
3.5 Test Framework
Test Framework 是一個免費產品，允許您編寫僅代碼測試并執行測試平臺的全部功能。此框架處理抽象瀏覽器、DOM 和 XAML 的所有繁重工作。使用該框架，你可以自動執行用戶操作、查找元素、等待元素以及使用 html 和 XAML 控件。
4. 功能
以下是 Test Studio 中一些最重要的功能：
- 記錄器允許您輕松地將操作和驗證添加到測試中。
- 元素資源管理器顯示項目中的所有元素，并允許您編輯其查找邏輯和篩選器。
- 不同的測試類型可以是同一項目的一部分。
- 數據驅動測試使用外部數據源，并針對每個值重復執行測試。
- 對話框處理功能涵蓋所有警報、確認、登錄、提示、文件上傳和下載對話框。
- 測試列表是測試的集合，可以作為計劃作業在本地和遠程計算機上執行。
- 在遠程執行服務器上計劃測試運行。
- “結果”選項卡提供已執行測試列表的概述。您可以向下鉆取并調查各個測試步驟。
- Test Studio 支持不同的持續集成和部署 （CD/CI） 工具，并允許您在構建完成時執行測試。
- 步驟生成器中的自定義步驟用于手動將特定步驟或條件添加到測試中。
- 項目設置具有許多可配置的選項來優化項目性能。
- 邏輯步驟，如如果...否則，循環和同時...循環允許您自動執行復雜的方案。
- 源代碼管理與 Git 和 TFS 的集成。
- 編碼步驟允許您在 C# 或 Visual Basic 中使用自定義代碼。
- 將嵌套的 API 測試作為步驟來啟用 Web 測試。
- 移動測試是Test Studio中的另一種項目類型，您可以在其中自動執行不同的Android和IOS應用程序。
4.1 跨瀏覽器的直觀錄制
憑借其直觀的點擊和記錄功能，記錄步驟從未如此簡單。Test Studio 主動支持主要的瀏覽器，包括Chrome、Edge、Firefox，以及用于無外設測試執行的無頭Chrome。
4.2 智能混合元素檢測
通過創建同時使用 Web 定位器和圖像的自動化元素，片狀和易碎的測試已成為過去。
4.3 元素存儲庫
在測試記錄期間，元素被添加到集中式元素存儲庫中，這使您可以更輕松地管理這些元素，并在測試和項目中重用它們，從而消除冗余并使您更輕松。
4.4 遠程計劃和并發運行
使用開箱即用的計劃功能，允許執行常見任務，例如在多臺遠程計算機上運行并發測試。
4.5 執行儀表板
使用易于使用的 Web 功能監控自動化結果和報告。團隊中的每個人都可以在 Web 中訪問它，而無需擁有專用的 Test Studio 許可證。
4.6 數據驅動測試
將數據源綁定到測試命令，而無需編寫和維護代碼。
4.7 步驟失敗詳細信息
使用失敗報告和智能建議輕松識別和修復失敗測試。
4.8 驗證 PDF
通常，在處理導出為PDF文件的數據時，您需要生成特定內容并下載PDF文件，然后打開它并驗證生成的文件中是否列出了所需的信息。Test Studio 作為 PDF 自動化工具之一，提供了開箱即用且完全無代碼的 PDF 驗證自動化功能，在測試錄制期間或自動化過程中可隨時添加 PDF 驗證步驟。
5. 安裝
5.1 軟硬件需求
要安裝 Test Studio 的計算機滿足系統要求中描述的硬件和軟件要求。
5.1.1 系統要求
|
|
磁盤空間 |
CPU |
內存 |
|
最小要求 |
500MB |
1.8GHz |
2GB |
|
推薦要求 |
2GB+ |
2.2GHz+ |
4GB+ |
|
顯示器分辨率 |
|
|
|
|
最低要求 |
1280 x 720 |
|
|
|
推薦 |
1920 x 1080 |
|
|
|
支持的操作系統 |
|
|
|
|
windows 11, Windows 10, Windows 8.1, Windows Server 2019, Windows Server 2016, Windows Server 2012 |
|
|
|
|
支持的瀏覽器 |
|
|
|
|
Internet Explorer 11; Latest Edge Chromium, Latest Chrome, Latest Firefox |
|
|
|
|
WPF支持 |
|
|
WPF for .NET 4.5+, .NET Core 3.1, .Net 5, .Net 6 and higher versions |
|
5.1.2 管理員權限
以下情況需要管理員權限：
- Test Studio安裝過程，包括初始安裝、修改現有安裝、卸載
- 測試 Studio 服務安裝和配置，包括啟用遠程測試執行的計劃設置
5.1.3 用戶帳戶控制
用戶帳戶控制（UAC）需設置為“從不通知”。
5.1.4 Visual Studio 插件支持
IDE（僅限 Visual Studio 插件）：Visual Studio Professional 或 Enterprise 2015、2017、2019 和 2022。
您必須以管理員身份運行 Visual Studio。
Visual Studio 項目應面向 .Net 4.5.2 到 Net 4.8 之間的版本。
Visual Studio 2017 在其默認安裝之上需要其他單獨的組件。
5.1.5 .Net Framework
.NET 4.5.2 - .Net 4.8 之間的任何版本
5.1.6 調度配置所需的數據庫
MongoDB 4.0 或 MongoDB 5
MongoDB 在安裝存儲服務的計算機上至少需要 2 GB 的額外磁盤空間。
5.1.7 數據綁定
如果使用 Excel 進行數據驅動測試，則需要：
Microsoft office 安裝或 32 位版本的 Microsoft Access Database Engine 2010。
5.1.8 源代碼管理
基于 Git 的存儲庫。
Azure DevOps TFVC 和基于 Git 的存儲庫。
5.1.9 構建服務器/持續集成
集成 CLI 運行程序測試執行需要至少安裝 Test Studio 運行時版本。
5.1.10 測試版軟件
不支持處于測試階段的操作系統和 Web 瀏覽器。
5.2 其它要求
您的用戶帳戶具有安裝、更改、修復或卸載 Test Studio 的管理員權限。您必須以管理員身份登錄或屬于計算機上的管理員組。
如果您計劃在 Visual Studio 2017 中使用 Test Studio 插件，請在 Visual Studio 安裝中添加測試工具核心功能組件。
如果計劃在 Windows Server OS 上運行 Test Studio 測試自動化并使用 IE，請關閉 Windows 組件 Internet Explorer Enhanced Security Configuration。
5.3 自定義安裝
在安裝過程中，可以自定義要安裝的組件，并更改默認安裝位置。
如果選擇以下某些組件，則需要考慮一些重要注意事項：
如果您在計算機上安裝了Visual Studio Professional或更高版本，則會自動選擇Visual Studio的Test Studio插件進行安裝。
若要在 Test Studio 計劃設置中將此計算機用作存儲或計劃服務器，必須選擇相應的組件，以便在初始安裝期間或更改現有組件時安裝 Test Studio 服務。
也可以在安裝完成后再添加存儲、計劃和執行儀表板功能，使用更改安裝即可。
存儲服務使用MongoDB作為存儲數據庫，如果計算機上不可用，則會自動安裝。MongoDB需要至少4Gb的可用硬盤空間才能正常運行。
如有必要，可以修改或修復已完成的 Test Studio 安裝。通過更改安裝，您可以添加或刪除一些Test Studio組件，例如Test Studio Services，Visual Studio插件等。
5.4 Test Studio 運行時的安裝
Test Studio 運行時版本是專用于測試執行的組件，旨在安裝在生成服務器（對于 CI/CD 配置）或調度和執行服務器（對于 Test Studio 計劃配置）上。
Test Studio 的運行時版本是一個單獨的產品，購買后可以從您的 Telerik 帳戶下載。
運行時版本的默認安裝包括Test Studio服務 - 計劃、存儲和執行儀表板。這些需要安裝在專用于計劃設置的其中一臺計算機上，該計算機將充當集中式計劃服務器，并將控制配置中所有計算機之間的通信。如果這是特定計算機，請按“安裝”按鈕繼續?；蛘?，如果當前計算機將僅用作執行服務器，則可以修改運行時版本的安裝，并通過按“自定義”按鈕從安裝向導中禁用 Test Studio 服務。
運行時沒有用于檢查更新的內置功能，需要手動執行安裝較新版本。
6. 配置
6.1 瀏覽器校準
需要一組特定的設置才能使每個受支持的瀏覽器能夠使用 Test Studio 進行測試錄制和執行，這稱為瀏覽器校準。某些瀏覽器還需要安裝擴展。
為了便于您應用這些設置，Test Studio 提供了一個內置機制來應用所有必要的設置并校準支持的瀏覽器。
6.1.1 啟用 Chrome 以實現自動化
在 Test Studio 版本 2022 R1 （v.2022.1.xx） 中，您可以選擇如何使用 Chrome 瀏覽器錄制和執行測試。在此版本中，可以使用或不使用 Progress Test Studio 擴展來啟用它以進行自動化。Chrome 的使用方式是在項目級別設置的，這意味著您可以同時使用這兩個選項，具體取決于您參與的項目。
默認情況下，每個 Test Studio 項目都設置為將 Chrome 與擴展程序配合使用。因此，如果這是您要使用的選項，則需要從Chrome網上應用店安裝最新的Progress Telerik Test Studio擴展程序。
如果您選擇使用 Chrome 進行錄制和執行，而無需其他擴展，則需要更改 Test Studio 項目中的設置。項目設置列在“瀏覽器”選項卡下，名為“使用瀏覽器擴展”（默認情況下處于啟用狀態）。取消選中該復選框，Test Studio 將啟動此項目的 Chrome 瀏覽器，而無需使用擴展程序，即使安裝了擴展程序也是如此。
6.1.2 瀏覽器校準
為了確保完美無瑕且一致的自動化過程，我們需要應用一些瀏覽器設置。我們稱之為瀏覽器校準，并實現了一項功能，可以開箱即用地自動校準瀏覽器。無需手動交互。
如果您的 Chrome 瀏覽器具有活動的 google Apps 會話（例如，您已登錄 GMail），則自動校準將無法按預期工作。要使用自動配置，請先注銷您的 Google 帳號。
7. 快速上手
7.1 創建項目
成功安裝并激活 Test Studio 并針對測試自動化校準瀏覽器后，即可創建第一個項目并熟悉 Test Studio 布局。
一個 Test Studio 項目允許您包含不同類型的測試：
- Web測試 - 一種測試，您可以在其中記錄對任何受支持的瀏覽器（Chrome，Firefox，Edge，IE）啟動的網頁的操作。
- Web 響應測試 - 一種測試，您可以在其中記錄針對在模擬設備模式（Chrome 和 Edge）中呈現的網頁的操作。
- 桌面測試 - 一種測試，您可以在其中記錄桌面應用程序（不限于特定技術）的操作。
- WPF 測試 - 可以在其中記錄針對 WPF 應用程序的操作的測試。
- 負載測試 - 一種測試，您可以在其中使用 Web 請求添加不同的方案以加載 Web 應用程序服務器。
- 手動測試 - 一種測試，您可以在其中添加步驟以針對任何應用程序手動執行。如果自動執行網頁，則可以將其轉換為 Web 測試。
- 性能測試 - 性能測試始終與有效的 Web 測試相關，并在此之上執行。
7.2 創建測試
在 Test Studio 中成功創建項目后，可以先針對所測試的應用程序記錄自動化測試。
Test Studio中的單擊并記錄功能旨在記錄用戶在 Web 和 WPF 應用中的操作，并在自動測試中將這些操作表示為步驟。
7.2.1 緊湊型錄制工具欄
啟動錄制會話會將 Test Studio 緊湊型錄制工具欄附加到為測試錄制選擇的瀏覽器。
緊湊型錄制工具欄是一個功能強大的工具，它支持其他有用的功能來增強錄制體驗。您可以暫?；蚶^續記錄操作，啟用或禁用元素突出顯示以使用“快速步驟”菜單，打開“高級錄制工具”以更詳細地瀏覽DOM等。
- 突出顯示元素 - 啟用或禁用“元素突出顯示”和“快速步驟”菜單。
- 錄制狀態 - 有一個“暫停”按鈕，用于需要對應用程序執行任何操作，但不需要記錄這些操作。暫停錄制時，按鈕將切換到“恢復”模式以再次觸發錄制。
- 高級錄制工具 - 打開“高級錄制工具”窗口以瀏覽應用程序的DOM樹，添加特定于元素的步驟或在錄制的步驟之間包括瀏覽器特定的操作或常見步驟。
- 旋轉緊湊型錄制工具欄 - 在垂直和水平之間更改緊湊型錄制工具欄的方向?？梢詫⑵湟苿拥綖g覽器/WPF 應用程序中的任意位置。
- 鏈接到文檔 - 點擊鏈接到我們詳細描述錄制過程的文檔。
7.1 執行測試
記錄第一個測試后，您需要執行它并檢查這是否需要其他調整。
測試執行完成后，將有一個摘要，即執行了多少步以及運行的總體結果。每個步驟都指示為“通過”或“失敗”，前面有一個綠色或紅色圓圈。測試結果將自動生成，并且可以通過單擊“查看日志”來查看詳細信息。
8. 其它功能
8.1 測試列表
Test Studio中的測試列表是要按順序執行的一組測試。您可以將自治測試組合在動態生成的列表中，每個測試都將在新的瀏覽器實例中執行?；蛘撸梢源虬鼫y試以按預定義的順序運行 - 自力更生或依賴于列表中以前的測試。
Test Studio為測試列表提供了兩個選項 - 靜態型，其中包含固定的，預先確定的測試列表；和 動態型，其中包含根據項目中的測試設置的屬性在執行時動態生成的測試列表。
8.2 靜態測試列表
在靜態測試列表中，可以添加 Web、響應式 Web、WPF、負載測試或這些測試的組合、手動測試和性能測試。有三種類型的測試列表可以涵蓋不同類型的測試 - 自動，手動和性能。測試列表的類型是在創建測試列表時定義的。
“自動”測試列表類型是執行一個或多個 Web、響應式 Web、負載或 WPF 測試的標準。創建此類列表時，只能選擇要包括的列出的測試類型（手動測試顯示為灰色）。
“性能測試”列表類型允許您為一個或多個 Web 測試執行性能運行。這種類型的列表只能包含 Web 測試（其余測試顯示為灰色）。在列表中添加的每個測試旁邊，您都有一個“配置...”按鈕，用于應用性能運行的設置。
“手動”列表類型允許您僅添加手動測試并一起執行它們（其余測試顯示為灰色）。按順序運行手動測試，或使用底部的“上一個”和“下一個”按鈕在它們之間來回切換。
8.3 動態測試列表
動態測試列表只能是自動類型，因此，它可以執行一個或多個 Web、響應式 Web、負載或 WPF 測試，或者這些測試的組合。創建動態測試列表時，有一堆測試屬性，您可以使用這些屬性作為從項目中篩選測試的條件 - 測試名稱，測試路徑以及所謂的用戶定義屬性 - 所有者，優先級，自定義屬性1，2，3。
每次觸發動態列表執行時，Test Studio 都會查詢項目并執行符合規則條件的測試。因此，如果在創建測試列表后添加了新測試，并且這些測試符合規則的條件，則它們將在執行時包含在測試列表中。
8.4 日志、調試
8.4.1 快速運行執行日志
快速測試運行后，將在測試視圖中生成快速執行日志。它包含有關當前測試的上次運行的詳細信息，您可以通過單擊“查看日志”按鈕將其打開。
從快速執行運行生成的結果將顯示在測試窗格中 - 成功執行的步驟用綠色圓圈標記，失敗的步驟在其前面用紅色圓圈標記。
每個失敗的步驟都會提供失敗的其他詳細信息（如果將鼠標懸停在失敗步驟前面的紅色圓圈上）。通過單擊該紅色叉線圓圈，可以打開“步驟失敗詳細信息”對話框。您可以看到故障的詳細消息，故障時預期圖像和圖像的屏幕截圖，故障時的DOM樹以及如何解決錯誤的建議。
8.4.2 可視化調試器
可視化調試器具有不同的選項，用于在快速測試運行期間調試測試。當測試的行為不符合預期時，尤其是在不清楚問題發生的操作時，通常使用它。
默認的快速運行將觸發顯示器右下角的可視調試器。它指示當前步驟，包括播放和暫停功能，如果將調試器選項設置為在出現錯誤時暫停，則顯示其他調試選項。
8.4.3 部分測試執行
檢查失敗測試的一種有用方法是將其部分執行到失敗測試之前的一個步驟（或幾個步驟）。
8.4.4 帶注釋的測試運行
在某些情況下，測試報告已通過，但預期要執行的操作實際上并未發生。在這種情況下，在快速測試運行期間啟用注釋會很有幫助。單擊“切換批注”按鈕，讓瀏覽器使用簡短的消息并突出顯示該步驟的目標元素來批注每個步驟。
這還將在每個步驟之間以配置的量（以毫秒為單位）減慢測試運行的速度。您可以從菜單中或通過輸入自定義值來設置它。
8.4.5 應用程序日志
應用程序日志是 Test Studio 在整個工具使用過程中記錄的消息列表，并帶來有關 Test Studio 中已執行操作的信息。如果項目中存在意外錯誤、崩潰或無法成功完成的建議配置，則通常使用它。
8.4.6 分析測試列表結果
“結果”選項卡顯示所有本地和遠程執行的測試列表的結果。在那里，您可以分析執行，向下鉆取到各個測試步驟，然后返回到每個執行的主測試列表級別。
8.5 在Test Studio中計劃配置
Test Studio 計劃設置允許您配置一組連接在一起的計算機，以便在無人參與的情況下執行自動測試。從計劃的測試運行生成的結果以允許團隊中的任何人查看這些結果的方式存儲。
Test Studio測試列表可以從網絡中任何計算機（包括虛擬機）上的本地項目執行，這些計算機是在Test Studio計劃設置中配置的。測試列表運行可以完全配置 - 何時執行，在哪些計算機上，如果有多個可用，是否生成自動電子郵件報告等。如果必須運行多個測試，則可以在不同計算機之間分配工作負載并減少總執行時間。所有結果都將存儲在一個集中位置，供您以后檢查。
8.5.1 計劃設置組件
Test Studio 計劃設置由默認產品安裝之上的幾個服務組成，需要正確配置這些服務以允許它們之間的通信。
需要添加的Test Studio服務如下所示：
調度服務
計劃服務是整個設置的核心組件 - 它位于所有操作的中間，可以認為它控制在任何遠程計算機上運行測試列表的過程。所有執行客戶端、存儲服務和從中執行測試的項目都連接到同一個計劃服務。
倉儲服務
存儲服務（用于保存項目文件和結果）是計劃服務的幫助工具。存儲服務維護一個數據庫來存儲文件和數據庫提供程序，Test Studio使用的是 MongoDb。
執行儀表板服務
執行儀表板是一個工具，它為所有團隊成員（包括未安裝 Test Studio 的團隊成員）提供對從計劃的測試列表運行生成的所有結果的訪問權限。執行儀表板服務在計算機上安裝了本地主機頁面，其中安裝了該服務。本地網頁可視化存儲在存儲數據庫中的結果。
8.5.2 需要多少機器
調度配置可以在一臺計算機上啟用，并且支持多臺執行計算機。充當執行服務器的每臺計算機都需要最少的 Test Studio 運行時安裝。
8.5.2.1 單機調度配置
調度配置可以在一臺計算機上啟用，并且支持多臺執行計算機。
計劃配置可以在一臺計算機上安裝Test Studio Ultimate或Test Studio Web&Desktop（修改以包含服務）完全啟用。
8.5.2.2 多機調度配置
至少一臺安裝了Test Studio Ultimate或Test Studio Web&Desktop的計算機（可以使用默認安裝） - 它將用于為自動化測試項目創建測試;
一臺計算機，它托管 Test Studio 服務 - 這可以是安裝程序中的任何計算機，因此它可以使用完整的產品安裝或運行時版本實例;
和至少一臺計算機來執行測試列表 - 這臺計算機需要最少的運行時安裝。
8.5.3 遠程計劃執行（單機設置）
使用 Test Studio，您可以在一臺計算機上計劃測試列表，但要使用 Test Studio 服務和模擬遠程測試列表執行。計劃服務設置允許您將生成的結果保存在存儲數據庫中。
在安裝 Test Studio 時，確保在“自定義安裝”對話框中包含 Test Studio 計劃服務和存儲服務組件。當然，也可以通過更改已安裝的產品來添加測試工作室服務。
確保測試運行程序指向同一本地計算機上已配置的計劃服務。
8.5.4 遠程計劃執行（多機配置）
8.5.4.1 跨計算機安裝Test Studio
Test Studio 中的計劃設置是一組服務，它允許在不同計算機上的 Test Studio 組件之間進行通信。根據其在配置中的角色，計算機可以運行產品的不同版本，并且可以以各種組合進行設置。
Test Studio 計劃組件是 Test Studio 服務，這些組件需要在其中一臺計算機上安裝和配置，這些組件將在設置中用作計劃和存儲服務器。根據決定哪臺計算機將托管哪個組件，您可以：
通過更改默認的獨立安裝來添加Test Studio服務。（默認情況下，這些服務不包括在Test Studio獨立安裝中）。
安裝默認的Test Studio運行時版本。（這些服務包含在默認運行時安裝中。如有必要，可以修改安裝以不包括這些內容。
執行服務器可以是任何物理機或虛擬機，并且Test Studio運行時版本安裝最少?？梢詫⒍鄠€執行服務器連接到單個計劃服務器，以允許您同時執行多個測試列表。允許在計劃程序和執行服務器上運行的計算機之間在操作系統和瀏覽器上存在差異。
若要將執行服務器注冊到計劃服務，需要將其執行客戶端配置為指向安裝程序中正在運行的計劃服務。執行客戶端是每個 Test Studio 安裝的一部分 - 獨立安裝或運行時。每個執行服務器都必須運行與計劃服務器相同版本的 Test Studio。
選擇執行服務器計算機時需要考慮的幾點：
確保執行服務器計算機具有足夠的磁盤空間來存儲從中計劃測試列表的項目的副本。
需要活動且未鎖定的用戶會話才能成功執行 UI 測試。有一些可能的配置和解決方法可以幫助設置執行計算機以保持活動會話。
上一個要求的一個例外是在Chrome無外設模式下執行測試 - 它只需要執行計算機上的登錄用戶。
8.5.4.2 配置調度服務
Test Studio 計劃服務協同工作，以確保項目與執行測試的計算機之間的無縫通信。它們的配置是相關的，因此在單個配置向導中執行。
Test Studio 存儲服務和 MongoDB 需要安裝在同一臺計算機上。
8.5.4.3 配置執行服務器
Test Studio Execution Server 可以是任何安裝了 Test Studio 的計算機（運行時版本是最低要求）。將計算機的執行客戶端配置為指向正在運行的計劃服務，并將其注冊為此計劃程序的執行服務器。
Test Studio 執行客戶端是Test Studio的運行時組件。它與 Test Studio Standalone 和 Run-time 版本一起安裝。若要啟動執行客戶端（也稱為測試運行程序），請在 Windows 的“開始”菜單中鍵入>“啟動執行服務器”。
8.6 無外設測試執行
無外設測試可提高測試過程的有效性和效率。Test Studio 支持在 Chrome 和 Edge Chromium 瀏覽器的無外設模式下執行所有現有的 Web 測試。
在無外設瀏覽器模式下運行 Web 測試使用 Web 瀏覽器來運行腳本，但跳過加載瀏覽器的 UI。這意味著在運行期間，所測試的 HTML 頁面不會呈現，因此整體執行速度要快得多。另一個優點是測試繞過與頁面的交互，以更直接地操作瀏覽器，從而減少了由于與 UI 相關的交互而導致的故障。
Test Studio 目前支持 Chrome 和 Edge Chromium 瀏覽器的無外設模式。通過選擇自動化項目中的瀏覽器類型，可以在無外設模式下執行該測試中的任何現有測試。
由于在無外設測試執行期間沒有加載UI，因此它比使用活動瀏覽器的常規測試運行快得多。因此，我們建議查看現有的 Web 測試，并確定這些測試是否包含足夠的等待和/或驗證步驟，以確保在無外設瀏覽器執行期間行為穩定且一致。
等待和驗證步驟是Test Studio中的機制，用于使測試執行速度與應用程序響應速度保持一致。這種類型的步驟始終與頁面上的元素相關，并且會減慢執行速度，具體取決于應用程序處理測試中操作的速度 - 因此，這些步驟實際上并不影響測試運行所需的總時間量。
添加一個短延遲作為等待或驗證步驟的基本概念是在發送下一個操作之前，確保所測試應用程序的狀態符合您的預期。直接的示例是確保在重新加載頁面后，元素在頁面上可見或存在。但是，不要低估頁面上的動態內容，而無需重新加載它。
8.7 響應式 Web 測試
為了幫助你滿足移動用戶的需求，Test Studio 提供了全面的功能來支持響應式 Web UI 測試。
使用Chrome和Edge Chromium瀏覽器的設備模式，您可以模擬不同的移動設備，并檢查網頁在這些設備上的行為。憑借其響應式 Web 測試，Test Studio 提供了針對此類模擬設備模式記錄和執行測試的功能。
Test Studio 中的響應式 Web 測試是一種獨立類型的測試，需要一些額外的設置才能在 Chrome 或 Edge Chromium 的設備模式下正確模擬移動設備。
為了方便起見，我們準備了一個預定義設備列表，您可以從中選擇并直接設置設備顯示大小和用戶代理的必要值。
注意！為了模擬選定的移動設備，Test Studio 強制瀏覽器進入調試模式。這帶來了一條消息“Progress Telerik Test Studio Extension”開始調試瀏覽器“，這是無法隱藏的。您可以忽略該消息并繼續執行測試。
注意！在執行測試時，在運行完成之前，不要啟動同一瀏覽器或任何其他應用程序的另一個實例！
響應式 Web 測試使用與標準 Web 測試相同的元素。也就是說，如果所測試的頁面在其響應式視圖中使用相同的元素，則可以重用Web測試中已記錄的步驟，并將這些步驟粘貼到新創建的響應式步驟中。
8.8 桌面應用程序測試
Test Studio錄制功能支持各種桌面應用程序。為了能夠針對特定應用程序啟動錄制會話，您需要在桌面測試中列出其可執行文件。桌面測試功能在測試階段與Test Studio R2 2022（v.2022.2.727）一起正式發布。它支持基本的記錄功能，包括突出顯示和部分測試執行，元素資源管理器中表示的元素存儲庫以及編輯記錄的元素。
Test Studio 提供了兩個選項來定義要自動化的應用程序 - 您可以為此測試指定可執行文件，也可以使用在項目級別設置的默認路徑。
Test Studio錄制功能支持各種桌面應用程序。為特定應用程序配置桌面測試后，即可開始記錄自動化方案。
在 Test Studio 桌面測試中錄制比錄制 Web 或 WPF 測試相對慢。這是因為底層技術及其功能。為了幫助改善用戶體驗，Test Studio 錄制器會指示操作是否發送得太早，并且無法正確獲取，并帶有紅色標簽，指出“尚未準備好錄制”。
8.9 負載測試
通過 Test Studio 獨立版中的負載測試功能，可以評估 Web 應用程序如何滿足可用性和用戶滿意度的業務需求。我們讓您輕松入門并找到幫助您做出決策所需的數據，但我們也為您提供了創建精心設計的復雜負載方案的靈活性和能力，以滿足您最苛刻的需求。
Telerik的Test Studio負載測試功能是一組服務和測試，當它們一起使用時，會將您的網站置于設定的用戶負載下。發送到應用程序服務器的用戶負載由正在運行的特定負載測試定義。使用Test Studio，您可以測量網站在負載下的性能。Test Studio 負載測試可以測量一系列有用的屬性，包括 HTTP 計時器和計算機性能指標。
負載測試有助于回答組織關于其系統在負載下的行為方式的一些最關鍵問題：
當成千上萬的其他用戶同時點擊我們的網站時，用戶在我們網站上的體驗如何？（一般負載測試）
當很多用戶已經點擊了好幾天時，我們的網站有多穩定？（浸泡測試)
在崩潰之前，我們的網站可以支持多少用戶？（壓力或傾翻測試）
8.9.1 負載測試
開始使用 Test Studio 負載測試非常簡單。Test Studio中是否有現有的功能測試？您是否在故障排除或監控期間捕獲了站點活動的 Fiddler 痕跡？
您可以使用已創建的 Web 測試設置功能強大的配置文件，而無需修改它們。您還可以快速定制“思考時間”延遲，以模擬真實用戶在瀏覽您的網站時所做的暫停?；蛘咧苯邮褂脕碜孕√崆偈植东@的寶貴數據，將其作為用戶配置文件導入Test Studio！
8.9.2 基本準則
若要充分利用負載測試，最好遵循以下簡單準則：
確保使用必要的動態目標對用戶配置文件進行參數化 - 這些目標允許您模擬多個不同的用戶正在使用所測試的應用程序。
確保你有有偏差的思考時間 - 這些有一個隨機的持續時間。通過讓一些用戶以不同的時間間隔坐在測試之外（思考），它不僅可以更好地模仿現實世界的使用情況，還可以使您的代理I / O不會如此擁擠。這可能有悖常理，但讓你的虛擬用戶停下來思考一段時間實際上會增加你的代理可以完成的用戶和請求的數量。
使用增加時間將用戶從少量用戶增加到較大數字。同樣，如果從較大的一致負載開始，沒有任何斜坡，則可能會阻塞 I/O。通過從較低的數字中提升，您可以為您的思考時間提供更好的參與機會。
在本地觸發負載測試運行。這種類型的執行通常在設計和調整測試時使用。它生成的結果可以很容易地用于解決可能的問題或缺少動態值調整。
負載測試的主要目標之一是對 Web 服務器運行大量 Web 請求。通常，如果使用單臺機器，則無法有效地實現這一點。要在應用程序服務器上執行實際負載，必須使用盡可能多的物理機。
8.9.3 運行測試
創建包含要執行的負載測試的測試列表。
將足夠數量的虛擬用戶分配給充當調度服務器的計算機。虛擬用戶數量應與將使用的執行計算機及其 CPU 單位數量相對應。每個 CPU 單元大約 8 個用戶似乎足以獲得真實的負載測試結果。如果分配了更多的用戶，則由于執行計算機 CPU 過載，可能會有 HTTP 請求排隊。
使用“在所選計算機之間分發測試”選項安排要執行的測試列表。
8.9.4 最佳實踐
若要充分利用負載測試，最好遵循幾個簡單的準則。
本地負載測試運行
在設計用戶配置文件以執行有效的 HTTP 請求時，通常使用本地執行負載測試。為了充分利用此類運行，需要記住以下幾個建議：
使用少量用戶 - 即使一個用戶也足以跟進哪些請求真正被執行。
使用較短的時間來運行測試 - 可以使用的最短時間為一分鐘，這通常足以執行用戶配置文件中的所有請求。
使用 Fiddler 捕獲從測試運行生成的流量 - 這樣您就可以跟蹤哪些是成功執行的 HTTP 調用，以及它們的響應是否符合預期。
使用 Test Studio 應用程序日志找出缺少的部分 - Test Studio 的應用程序日志還會記錄在工具中工作時的所有操作。在負載測試運行期間生成的日志中，可以找到已執行的 HTTP 請求。
與測試中的應用程序開發團隊合作 - 如今，Web應用程序很復雜，可以使用許多不同的技術進行構建。如果您需要對網頁進行負載測試，而您不熟悉詳細信息，那么與開發團隊就使用 Test Studio 進行負載測試展開討論會很有幫助。當然，應用程序的開發人員將能夠共享有關頁面和應用程序服務器的特定信息。
遠程負載測試列表運行
按照以下建議準備要在多臺計算機上執行的負載測試。
確保你有有偏差的思考時間。有偏差的思考時間有一個隨機的持續時間。通過讓一些用戶以不同的時間間隔坐在測試之外（思考），它不僅可以更好地模仿現實世界的使用情況，還可以使您的代理I / O不會如此擁擠。這可能有悖常理，但讓你的虛擬用戶停下來思考一段時間實際上會增加你的代理可以完成的用戶和請求的數量。
使用斜坡時間將用戶從少量用戶增加到較大數字。同樣，如果從較大的一致負載開始，沒有任何斜坡，則可能會阻塞 I/O。通過從較低的數字中提升，您可以為您的思考時間提供更好的參與機會。
使用更多 CPU，Test Studio負載代理是多線程的，因此請利用這一點，向代理提供更多 CPU 來提高吞吐量。通常，每個 CPU 單元大約 8 個用戶似乎足以獲得真實的負載測試結果。
使用更多代理。您使用的代理計算機越多，您一次可以使用的網絡端口就越多，從而緩解代理端的擁塞。
8.10 性能測試
自動化功能測試工具可幫助您為關鍵最終用戶方案構建自動化測試。使用 Test Studio 實現自動化后，可以自動運行這些方案，以幫助你發現任何回歸。應用程序的功能正確性是質量的一個衡量標準，另一個非常重要的衡量標準是性能測試。
績效衡量和基準測試 - 采取功能場景并衡量每個步驟的執行時間。不僅要測量總時間，還要測量客戶端與服務器時間。然后創建基準，以便以后進行比較，以進行回歸檢測或目標設置。
歷史視圖和比較 - 查看測試的歷史性能并比較兩個不同的快照，以幫助確定回歸發生的位置。
深入分析 - 通過比較客戶端與服務器時間來分析結果。在步驟級別跟蹤代碼，以查明導致最大瓶頸的確切代碼行。
如果對遠程服務器進行性能分析，則至少需要在其上安裝啟用了探查器服務的 Test Studio 運行時版本。在本地和遠程服務器上運行的 Test Studio 版本必須匹配。還要確保在遠程服務器上打開了正確的入站和出站端口。
8.10.1 選擇有效的自動 Web 測試
哪些 Web 測試是性能測試的良好候選者？
幾乎沒有驗證步驟或超時的特定用戶方案。
刪除所有變量以防止干擾。
8.10.2 開始測試
指定一個好的候選測試后，請轉到“性能”選項卡并開始使用：
- 收集性能數據 - 配置設置并創建性能運行。
- 歷史記錄視圖 - 可視化一段時間內的指標，實現性能目標，并使用基準測試功能建立性能基線。
- 概述 - 查看與服務器、網絡和客戶端相關的數據。
- 詳細信息視圖 - 查看對每個測試步驟、整個測試或自定義間隔的深入分析。
- 比較視圖 - 并排放置兩個性能運行，并使用增量閾值識別潛在的回歸或瓶頸。
8.11 編碼測試
Test Studio 允許您將測試中記錄的操作與針對任何特定和復雜方案的編碼解決方案相結合，這些方案需要自定義內置驗證和操作功能之外的自定義。
Test Studio 支持兩種類型的編碼語言 - C# 和 VisualBasic。添加第一個編碼項時，將在項目級別設置語言。在項目級別設置腳本語言后，無法將其更改為其他選項。如果需要將編碼的解決方案轉換為其他語言，則需要手動將code_轉換為其他腳本語言。
在 Test Studio 測試中，可以利用將錄制的步驟作為編碼函數重用，以及添加自己的自定義編碼邏輯。
在測試中添加第一個編碼步驟會自動創建與測試關聯的編碼文件。Test Studio 從測試切換到代碼文件，并允許在空測試方法中編寫自定義編碼函數。
使用任何自定義代碼擴展測試項目可能需要使用外部庫（如各種 .NET 程序集）或您自己的特定程序集文件。外部程序集在 Test Studio 中的項目級別添加為引用，并且可以在此項目中的所有測試中使用。
建議從全局程序集緩存中添加對 .NET 程序集的引用。這樣，如果在另一臺計算機上移動項目，則引用應開箱即用地匹配。
如果需要添加對自定義 dll 文件的引用（該文件未安裝在 GAC 中），我們建議將庫類文件保存在項目根文件夾內的專用文件夾中。這樣，dll 將始終與項目一起部署，并從該位置引用。
8.12 版本管理
8.12.1 要從簽入中排除的文件
對于任何源代碼管理系統，請簽入除以下文件之外的所有文件：
Pages.g.cs（或.vb） - 此文件是每次構建時自動生成的。
*.suo 文件 - 這是一個 VS 每用戶設置文件。
TestResults 文件夾中的任何內容。
項目 *.dll項目 bin 文件夾中的文件 - 此文件是每次生成時自動生成的。
如果還使用獨立版本，則需要排除“結果”文件夾。此文件夾僅由獨立版本創建，并保存測試列表運行的結果。
8.12.2 要簽入的文件
Visual Studio 測試項目也可能使用這些唯一的文件：
*.vsmdi - 這是一個Visual Studio文件。它存儲 Visual Studio 測試列表的定義。
*.testsettings - 這是一個Visual Studio文件。它存儲測試運行配置設置（默認超時、默認瀏覽器等）。
“屬性”文件夾中的文件 - 這是為每個 Visual Studio 項目創建的。它包含項目程序集的定義。
以下文件是Test Studio項目所獨有的：
*.tstest（或 .aii） - 這些包含實際的測試定義。
*.cs / *.vb - 這些包含編碼步驟的代碼。
*.resx - 這些包含情節提要的圖像。
*.imgstore - 這些包含與測試相關的元素的圖像。
Settings.aiis - 它包含特定于此Test Studio項目的屬性（例如，創建它的工具版本，錄制設置，程序集引用，TFS連接設置）。
.aiilist - 這些包含測試列表定義。
“探查器配置”文件夾中的 .tsprofconfig 文件 - 這是存儲性能配置設置的位置。是否將這些文件簽入到源代碼管理中取決于您是否要保存/共享此信息。
注意：TFS 插件會自動選擇正確的文件進行簽入。
8.12.3 升級由多個團隊成員使用的項目
其中一個團隊成員應該簽出測試項目，并在他的本地計算機上升級它。
升級項目后，同一成員應將升級后的項目簽回源代碼管理中。
其他團隊成員現在可以獲取項目的最新版本并使用它，而不會在較新版本的 Test Studio 中合并沖突。
8.12.4 使用Git
Test Studio 與基于 Git 的源代碼管理存儲庫無縫集成，以簡化 QA 和開發人員之間的協作。Git集成還可以促進QA團隊在同一測試項目上的工作，允許他們同時獨立地簽入他們的工作。
Test Studio 為 git 存儲庫提供了常規支持 - 這包括提交、推送、拉取和還原命令。
Test Studio 不提供在遠程提供程序中創建存儲庫的任何方法。相反，它由您決定要將項目存儲在哪個遠程提供程序中?？紤]到這一點，您必須首先在所選的遠程提供程序中創建一個空的遠程存儲庫，然后使用 Test Studio 將本地項目連接到該存儲庫。
如果嘗試將本地項目連接到存在現有項目的遠程存儲庫，則需要手動合并并解決沖突的項目文件。
Test Studio 支持的特定于源代碼管理的命令如下：
- 將更改提交到 Git - 將更改提交到本地存儲庫。
- 推送到 Git - 將更改推送到遠程存儲庫。
- 從 Git 拉取 - 從遠程存儲庫獲取最新更改。
- 放棄本地更改 - 將工作文件夾中的更改撤消回上次提交。
- 斷開與源代碼管理的連接 - 斷開當前項目與源代碼管理的連接。
從版本 2017 開始，R2 Test Studio支持管理遠程和本地存儲庫中的 Git 分支。
一旦本地項目連接到遠程 Git 存儲庫，或者在 Test Studio 中打開并本地克隆遠程項目，就可以在 Test Studio 中管理其分支。
本地項目也可以使用 Git 啟用源代碼管理，并且可以在 Test Studio 中維護本地分支。
對于本地存儲庫，只有提交作為選項可用。
8.12.5 使用TFS
Test Studio 與 Microsoft Team Foundation Server 無縫集成，以簡化 QA 和開發人員之間的協作。
TFS 集成還有助于 QA 團隊在同一測試項目上的工作，使他們能夠同時獨立地簽入其結果。除了 TFS 支持之外，Test Studio 還可以與任何其他基于文件的源代碼管理系統進行交互。
8.12.6 基于文件
Test Studio 可以與任何基于文件的源代碼管理系統進行交互。由于 Test Studio 直接與 Team Foundation Server 和 Git 集成，因此您需要使用第三方工具將文件簽入和簽出。Test Studio 將項目視為本地項目，因為文件不會在 Test Studio 中簽入和簽出。
8.13 持續集成
持續集成幾乎不斷地將各個開發人員的更改集成到主源代碼控制系統或存儲庫中，執行新構建，驗證構建，并針對這些構建運行自動測試。持續集成具有許多優點。其中包括用于測試目的的當前版本的持續可用性，立即測試所有更改，以及開發人員有機會在測試失敗或發現錯誤時將代碼庫恢復到無錯誤狀態，而無需浪費時間進行調試。
持續集成環境使用各種生成工具，包括 MSBuild。構建的自動化可以包括部署到與生產密切相關的測試環境中。生成可以包括要測試的項目，以及 Telerik 測試框架測試和 Test Studio 測試的編碼步驟。
生成完成后，測試可能會自動運行。生成自動化可以使用 ArtOfTest.Runner 或 MSTest 對生成執行 Telerik 測試。作為自動生成過程的一部分，Telerik 測試結果可以發布到自定義位置。
ArtOfTest.Runner將測試結果發布為.aiiresults文件；MSTest 將結果發布為 .trx 文件。
由于框架實際上驅動瀏覽器并與之交互，因此測試代理的設置是敏感的。許多自動生成服務器和測試代理在“本地系統”或“本地服務”帳戶下運行。這將導致 Telerik 測試失敗，因為這些類型的帳戶禁止瀏覽器交互。
測試代理（有時與生成服務器相同）必須在控制臺模式下運行（即，在登錄到測試計算機后通過命令行啟動）。將測試代理作為登錄到真實用戶帳戶的服務運行不能提供完整的功能。某些 Telerik 測試功能需要桌面交互，對于作為服務運行的測試代理，桌面交互處于禁用狀態。不要并行運行 Telerik 測試。Telerik 測試不是線程安全的。
9. 最佳實踐
9.1 添加現有測試腳本
如果您需要重用另一個項目的測試，最簡單，最安全的方法是使用內置選項導入現有測試文件
使用這種方法，您可以確保測試在新項目中保持其UniqueID屬性確實是唯一的。如果文件在 Test Studio（Windows 資源管理器）外部進行維護，則可能會導致該屬性重復，從而導致在計劃或遠程執行測試時出現錯誤。項目中重復的 UniqueID 屬性可能會導致存儲服務數據庫中的條目重復，并導致在執行測試列表時出現不當行為。
9.2 生成Test Studio應用程序日志
Test Studio 應用程序日志記錄記錄從工具觸發的所有事件，同時記錄測試、執行這些測試或在項目中維護元素和測試。它是一個強大的信息來源，有助于調查任何類型的問題。
日志是一個純文本文件，存儲在產品安裝一個 C：Program Files （x86）ProgressTest Studio 下的 Logs 子文件夾中。默認情況下，日志記錄處于禁用狀態，如果需要生成日志記錄，則首先需要啟用它。
9.3 使用 ID 和自動化 ID 進行元素標識
作為 QA 專業人員，在流程的早期參與開發團隊非常重要。本文將討論這樣做的眾多好處之一 - 編碼標準和使用ID來提高團隊生產力。預先需要這樣做，您可以大大減少測試用例維護。
無論您使用什么軟件進行測試自動化，識別元素的方法都起著至關重要的作用。對應用程序的微小更改通常會破壞測試的 find 邏輯，從而導致測試運行失敗。
要求開發團隊為動態 HTML 應用程序實現 ID，或為 Silverlight 應用程序實現自動化 ID。只要 ID 是唯一的，在對應用程序進行更改時，元素存儲庫就不需要維護。
我們的自動化測試工具在自動識別元素方面做得非常出色 - 這節省了無數個小時，并允許您繼續擴展回歸套件，同時保持項目按計劃進行。為什么不通過將ID作為編碼標準來實現并大大減少測試用例維護時間，將其提升到一個新的水平。
9.4 常規步驟與編碼步驟
相當多的客戶項目嚴重依賴代碼來實現他們的測試用例。
Test Studio 旨在將編碼保持在最低限度。Test Studio 將自動為您生成與冗長代碼塊相對應的步驟。
使用編碼步驟會增加遇到編譯錯誤以及與生成測試項目相關的其他錯誤的機會。
9.5 測試模塊化
術語“測試模塊化”通常用于描述如何配置項目的常見方法，以簡化其維護和感知。Test Studio 提供了許多功能來獲得出色的項目可見性，并且非常鼓勵實現它們的使用。有兩種主要方法可以實現良好的模塊化：測試即步驟和使用代碼。
“作為步驟測試”是最常用的方法。我們的想法是將腳本劃分為可由父測試調用的子測試。此類子測試的一個很好的例子是“登錄”和“注銷”。基本上，您可以將任何重復操作插入到子測試中，并在需要時調用它。我們不會限制您可以使用子測試進行深度，盡管它變得難以管理，并且我們不建議太深入。
在項目資源管理器中，可以在測試項目文件夾中創建子文件夾，以便更好地將主測試和子測試組織在一起。右鍵單擊項目節點，然后選擇“創建文件夾”以添加新文件夾。
9.6 使用代碼
在此方法中，您可以使用“腳本步驟”功能來調用自己的編碼函數。
對于全局可訪問的數據，我們最接近的內置功能是數據驅動測試。將子測試設置為“從父測試繼承數據”將允許您擁有全局項目數據。這將通過將父測試綁定到不同的數據集來參數化子測試。
Test Studio中還提供了已實現的提取步驟，該步驟將元素的值存儲到可以傳遞以進行數據綁定的變量中。上述方法也可以在代碼中獲得 - 在代碼中定義全局變量并在代碼文件中使用它們。您還可以選擇在代碼中獲取和設置變量的值，并將其傳遞給類似于“提取”步驟的非編碼步驟。
元素的查找邏輯也可以綁定到提取的變量或數據源。
