TAF 自动化测试：集成与 UI 两条测试线
TAF（Test Automation Framework）是 Aras 提供的独立测试产品， 用于编写和执行 Aras Innovator 自动化测试。它同时支持 AML 集成测试 与 Selenium Web UI 测试， 并提供 Visual Studio 扩展、项目模板和 TAF 库。
先纠正一个常见误解
“使用 NUnit/MSTest 连接 IOM”可以是一套自建集成测试，但它不因此自动成为 Aras TAF。 只有使用与目标版本匹配的 TAF 产品、模板、库和许可，才应称为 TAF 测试。
1. 适用版本与许可
本文以 TAF 1.51 官方安装指南为基线：
| 项目 | TAF 1.51 官方要求 |
|---|---|
| Aras Innovator | 12.0 SP18、Release 17～34 |
| Visual Studio | Community / Professional / Enterprise 2019 |
| .NET | .NET Framework 4.7.2 |
| C# | 7.1 |
| 许可 | Aras TAF 或 Platinum-level subscription，目标实例需有效 TAF Feature License |
TAF 1.51 的部分应用专用 API 还有自己的应用版本矩阵，不能只看平台行。 Release 35～39 不在上述 1.51 基础兼容范围内；使用这些 Innovator Release 时，应向 Aras 获取明确兼容的 TAF 版本，不要自行推断“向后兼容”。
三套版本必须一起锁定
测试仓库应同时记录 Innovator Release、TAF Release 和被测应用 Release。 浏览器与客户端操作系统则按该 Innovator Release 的 Platform Specifications 选择。
2. 两类测试各自验证什么
2.1 AML 集成测试
适合验证：
- Item 新增、编辑、版本和生命周期规则。
- Server Method、Server Event 与权限行为。
- AML 返回结果、错误和数据关系。
- 包导入后的关键配置是否可用。
它跨越服务器与数据库边界，不是纯单元测试。测试失败可能来自认证、许可、权限、环境数据或服务状态。
2.2 Selenium Web UI 测试
适合验证：
- 用户能否通过真实客户端完成业务流程。
- CUI 命令、表单、搜索、关系页签和对话框是否可用。
- 不同 Identity 看到的界面是否符合预期。
- Responsive 与 Classic Form 的用户路径是否回归。
UI 测试比集成测试更慢，也更受浏览器、数据和布局变化影响。关键规则优先放在集成层，少量主路径放在 UI 层。
3. 安装前的决策门
在安装 VS 扩展前完成以下核对：
- 从官方 TAF 文档库选择具体 TAF Release。
- 核对 Innovator、应用、浏览器、VS 与 .NET 矩阵。
- 确认目标实例具有有效 Feature License。
- 明确测试环境，不允许默认指向生产。
- 为测试账号配置最小必要 Identity。
- 决定哪些场景是 AML、哪些是 UI。
如果任何一项无法确认，应暂停安装和脚本迁移。强行修改项目 Target Framework 不会创造官方兼容性。
4. 用官方模板建立工程
TAF 安装指南的目标是安装带模板的 Visual Studio 扩展。工程应从已安装的 TAF 模板创建， 而不是从空白 NUnit 项目猜测程序集、基类和配置键。
建议的仓库边界如下：
tests/
├── integration/ # 由 TAF AML integration 模板生成
├── ui/ # 由 TAF Selenium 模板生成
├── data/ # 可重复装载的测试数据
├── environment/ # 非秘密的环境模板
└── README.md # 版本矩阵与运行命令实际 .csproj、配置文件和类名以对应 TAF 模板生成结果为准。本文不虚构跨版本通用的 TAF API。
不提交秘密
服务器 URL 可以模板化；用户名、密码、证书和 OAuth secret 应由开发机秘密存储或 CI secret 注入。 不要把真实密码写入 App.config 后提交 Git。
5. 设计一个可重复的测试
每个用例至少写清五部分：
| 部分 | 示例 |
|---|---|
| Given | 测试用户拥有 Design Engineer，存在一个专用 Draft Item |
| When | 使用受支持 API 执行一次目标动作 |
| Then | 返回非错误，状态和关系符合规则 |
| Cleanup | 按已记录 ID 清理，或恢复隔离数据库快照 |
| Evidence | 测试名、时间、目标 Release、日志和结果文件 |
5.1 数据唯一性
测试名称和业务键应包含本次运行的唯一后缀，避免并发冲突：
TAF_<scenario>_<run-id>记录创建结果的 ID，不要在清理阶段用宽泛条件删除“所有 TAF_ 开头”的数据。
5.2 清理必须独立执行
如果把清理写在断言后面，断言失败会跳过清理。应使用模板支持的 teardown/finally 机制， 或者为整个测试环境使用可恢复快照。
5.3 错误也是结果
权限拒绝、必填校验和非法状态迁移应断言明确错误类别或稳定消息片段。 不要只断言“抛了异常”，否则网络失败也会被误判为业务规则通过。
6. 可复现实验：先证明 TAF 安装正确
不要一上来迁移全部回归测试。先建立两个最小烟雾测试。
6.1 AML smoke test
- 从 TAF 模板创建 AML integration 项目。
- 使用专用测试账号连接隔离 Innovator。
- 查询一个由测试准备脚本创建的固定 Item。
- 断言返回一条记录及稳定属性。
- 运行两次，确认结果相同且无新增垃圾数据。
6.2 UI smoke test
- 从 TAF 模板创建 Selenium UI 项目。
- 使用 Platform Specifications 支持的浏览器。
- 登录、打开一个 OOTB 搜索页、执行固定查询并退出。
- 保存测试结果与失败截图。
- 在开发机和 CI agent 各运行一次。
6.3 通过标准
- 测试运行器能发现两个用例。
- 目标环境日志能关联到测试账号。
- UI 用例失败时有截图或浏览器日志。
- 无凭据出现在源码、控制台和制品中。
- 第二次运行不依赖第一次残留数据。
7. 流水线分层
推荐按反馈速度分层，而不是每个 PR 都跑全部 UI 用例。
| 阶段 | 测试 | 典型触发 |
|---|---|---|
| PR 快速检查 | 静态检查、少量 AML smoke | 每次提交 |
| 集成检查 | 包导入、AML 回归 | 合并请求或每日 |
| UI 主路径 | 少量 Selenium 场景 | 每日或发布候选 |
| 完整回归 | 全套受支持测试 | 发布门禁 |
流水线必须显式部署被测包、准备数据、运行测试、收集结果并清理环境。 “启动 vstest.console.exe”只是运行器步骤，不代表这些环境动作自动存在。
8. 常见错误
把手写 IOM 测试称作 TAF
它可以有价值，但应标注为“自建 IOM 集成测试”，除非确实引用 TAF 产品库和模板。
忽略 Feature License
TAF 1.51 需要对应订阅和目标实例许可。普通 Innovator 许可不等于 TAF 许可。
宣称 TAF 1.51 支持 R39
官方 1.51 基础矩阵截至 R34。R35+ 必须查对应新版本或向 Aras 确认。
只在测试正文末尾删除数据
测试中途失败会遗留数据。使用 teardown/finally 或环境快照。
把 UI XPath 当永久 API
界面结构会变化。优先使用 TAF 模板与库提供的抽象，并把 UI 用例控制在关键路径。
9. 官方依据
- Aras Test Automation Framework 文档库
- TAF 1.51 Overview
- TAF 1.51 Software and Hardware Requirements
- TAF 1.51 Installation Guide PDF
- Aras Innovator VS AML Integration Test Plugin
文档最后核验：2026-08-13。