一文了解 Telerik Test Studio 测试神器
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树，添加特定于元素的步骤或在录制的步骤之间包括浏览器特定的操作或常见步骤。
- 旋转紧凑型录制工具栏 - 在垂直和水平之间更改紧凑型录制工具栏的方向。可以将其移动到浏览器/WPF 应用程序中的任意位置。
- 链接到文档 - 点击链接到我们详细描述录制过程的文档。
7.1 执行测试
记录第一个测试后，您需要执行它并检查这是否需要其他调整。
测试执行完成后，将有一个摘要，即执行了多少步以及运行的总体结果。每个步骤都指示为“通过”或“失败”，前面有一个绿色或红色圆圈。测试结果将自动生成，并且可以通过单击“查看日志”来查看详细信息。
8. 其它功能
8.1 测试列表
Test Studio中的测试列表是要按顺序执行的一组测试。您可以将自治测试组合在动态生成的列表中，每个测试都将在新的浏览器实例中执行。或者，您可以打包测试以按预定义的顺序运行 - 自力更生或依赖于列表中以前的测试。
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）\Progress\Test 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中还提供了已实现的提取步骤，该步骤将元素的值存储到可以传递以进行数据绑定的变量中。上述方法也可以在代码中获得 - 在代码中定义全局变量并在代码文件中使用它们。您还可以选择在代码中获取和设置变量的值，并将其传递给类似于“提取”步骤的非编码步骤。
元素的查找逻辑也可以绑定到提取的变量或数据源。