0

我们目前正在使用 Selenium Webdriver 和 JUnit 对 B2C 产品进行冒烟测试。由于我们使用的是 Selenium，因此脚本完全依赖于 UI。鉴于该产品不是一家技术初创公司，UI 和工作流程以极高的频率不断变化/发展。

后果：本应验证应用程序神圣性的冒烟测试不断失败。团队花费更多时间修复脚本而不是验证构建。

我很确定那里的大多数自动化人员都会面临类似的问题，尤其是。具有快速的开发周期。期待看到业内其他面临类似问题的人采取的一些方法。

注意：前端是用PHP开发的

4

2 回答 2

0

被测系统越通用，在 Selenium 之上拥有一个框架以减少更改的维护工作就越重要。对于被测系统中最常见的更改，有几种已知模式可以帮助您减少维护工作：

  • 通过使用 UIMaps 对应用程序的 UI 建模，处理更改的 ID、CSS 类或类似更改非常容易

  • PageObjects 减少了较大的 UI 更改的工作量（例如，当输入字段从 TextBox 更改为 Dropdown 字段时）

  • 在不了解底层技术表示的情况下，使用关键字驱动测试对测试用例进行建模。即关键字从用户的角度封装了一个动作——关键字的示例可以是：“loginWithValidUser()”</p>

  • 如果 UI / 应用程序 / 工作流发生剧烈且频繁的变化，请不要只使用 UI 进行冒烟测试。大多数情况下，通过在没有任何 Web-UI 的情况下调用 WebServices 来测试某些功能也很有帮助

于 2014-11-26T11:52:03.307 回答
0

Webdriver 大致是这样工作的：有一个起点，webdriver 与之交互（例如通过模拟按钮按下），然后找到下一个要交互的​​项目。下一项可能在下一页或同一页上。可以通过各种方式找到它，通过 id 或 class="foo" 的第三个 div 等。

测试是页面加载是否为 200 OK，字符串“login”是否出现在特定位置等等

改变 UI 的问题是所有元素都“移动”。ids 改变，第三个 div 类 foo 消失。这意味着 webdriver 交互失败，如果他们正在寻找特定元素的测试也会失败

一种解决方案是针对一组 id 进行开发和测试。这些 id 将引用固定的 UI 元素。在 webdriver 中的所有搜索都应该使用 id。编写 PHP 的开发团队会将 ID 放在正确的位置。

这组 id 也可以用作某种规范的基础，并且可以用来以不同的方式向不同的利益相关者解释 UI 流程。

我不知道有任何特定产品可以处理在测试和开发代码中管理 id 的过程，但是维护这样的“词典”来描述 UI 项不应该是一项主要任务

于 2014-11-26T09:25:28.203 回答