谁编写自动化 UI 测试？开发人员还是测试人员？答案

【问题标题】：Who writes the automated UI tests? Developers or Testers?谁编写自动化 UI 测试？开发人员还是测试人员？
【发布时间】：2010-11-20 19:08:22
【问题描述】：

我们正处于一个大型项目的初始阶段，并且已经决定某种形式的自动化 UI 测试可能对我们有用，但还没有弄清楚它是如何工作的……

主要目标是自动化应用程序的基本安装和运行，因此如果开发人员造成重大损坏（例如：应用程序无法安装、网络无法连接、窗口不会显示等） 测试人员不必浪费时间（并因此而烦恼） 安装和配置损坏的构建

次要目标是帮助测试人员处理重复性任务。

我的问题是：谁应该创建这些类型的测试？我们团队的隐含假设是测试人员会这样做，但我在网上阅读的所有内容似乎总是暗示开发人员将创建它们，作为一种“扩展单元测试”。

一些想法：

开发人员似乎处于更好的位置，因为他们知道控件 ID、类等，并且对应用程序的工作方式有更好的了解
测试人员的优势在于不知道应用程序是如何工作的，因此可以生成可能更有用的测试
我使用IronRuby 和White 编写了一些初始脚本。这非常有效，并且足够强大，可以做任何事情，但是您需要能够编写代码来编写 UI 测试
我们尝试过的所有自动化 UI 测试工具（TestComplete 等）似乎都非常复杂和脆弱，虽然测试人员可以使用它们，但它们花费的时间大约是 100 倍，而且它们不断遇到由 UI 测试工具引起的“意外复杂性”。
我们的测试人员不会编写代码，虽然他们很聪明，但当我建议测试人员可以编写简单的 ruby 脚本时，我得到的只是有趣的表情（尽管所说的脚本比阅读和阅读要容易 100 倍）比那些似乎是自动化 UI 测试工具标准的乱七八糟的按钮和数据网格更写得好）。

非常感谢在开发人员和测试人员组成的团队中尝试过 UI 自动化的其他人提供的任何反馈。谁做了什么，效果好吗？提前致谢！

编辑：有问题的应用程序是一个 C# WPF“富客户端”应用程序，它使用 WCF 连接到服务器

【问题讨论】：

标签： automated-tests regression-testing ui-testing

【解决方案1】：

理想情况下，最终编写测试的应该是 QA。使用程序化解决方案的问题在于让 QA 人员快速使用该工具所涉及的学习曲线。开发人员当然可以通过指导来帮助完成这个学习曲线并帮助该过程，但这仍然需要时间并且会拖累开发。

另一种方法是使用一个简单的 GUI 工具，该工具支持一种语言（和数据脚本）并使 QA 能够直观地构建脚本，仅在真正需要时深入研究该语言的更精细细节 - 开发也可以在这里参与。

我见过的最成功的尝试肯定是后者，但设置它是困难的部分。 Selenium 对于简单的 Web 应用程序和通过应用程序的简单线程运行良好。 JMeter 也（用于 Web 服务的脚本化 Web 对话）运行良好......另一个选择是内部构建的测试工具 - 一个简单的工具，位于脚本语言（Groovy、Python、Ruby）之上，允许 QA通过 GUI 或数据文件将测试数据放入应用程序。数据文件可以是简单的属性文件，或者在更复杂的情况下是结构化的（例如 YAML 甚至 Excel）数据文件。这样他们就可以开始构建基本的冒烟测试，然后将其扩展到各种场景驱动的测试。

最后...我认为以这种方式测试富客户端应用程序要困难得多，但这取决于语言的性质和您可用的工具...

【讨论】：

我们决定让 QA 人员编写基本的“存根”脚本（使用 IronRuby，它非常易于读写），然后让开发人员进行修复代码和实现 QA 人员无法完成的部分。希望一切顺利
也许您应该尝试 IBM Functional Tester、HP QuickTestPro、Borland Silktest 或 MSVS Test Edition 等产品，而不是像 Selenium 这样的应用程序。至于网络应用程序，也有专门的库，如 WebAii 或 WatiN，可帮助编写脚本。无论如何，让您的 QA 人员学习和采用。很像开发人员 - 每天都需要学习新东西。

【解决方案2】：

根据我的经验，会编码的测试人员会换工作以提高开发人员的工资。

我同意你对自动化 UI 测试工具的看法。我工作过的每一个地方，只要有足够的钱可以买得起 WinRunner 或 LoadRunner 都买不起员工来实际使用它。价格可能已经发生变化，但当时，这些价格处于 5 位数到 6 位数的低位（想想入门房的价格）。这些产品很难使用，并且通常被卸载在一个锁着的柜子里，因为每个人都害怕破坏它们而惹上麻烦。

【讨论】：

LoadRunner 用于性能测试，实际上很难掌握。问题不在于它使用的 C，而在于相关性和分析网络流量。至于 GUI 自动化测试，QTP 是更好的选择。它允许通过记录和回放来构建测试，也可以在 VBScript 中编写相同的测试脚本。价格可能仍然是个问题。

【解决方案3】：

在我最终转向测试和测试自动化之前，我作为应用程序开发人员工作了 7 年多。测试比编码更具挑战性，任何想要成功的自动化开发人员都应该掌握测试技能。

前段时间，我在几篇博文中发表了我对技能矩阵的看法。

如果有兴趣讨论：

http://automation-beyond.com/2009/05/28/qa-automation-skill-matrices/

谢谢。

【讨论】：

哦，对于安装和基本的运行自动化，如果没有实际的功能测试，你真的不需要 QTP 或 TestComplete。试试 AutoIt（它是免费的）。
我非常怀疑任何 QA 的薪水是否与优秀的开发人员的薪水相匹配，因此从 Dev 转向 QA 似乎是一件奇怪的事情，从职业角度来看。说testing is much more challenging than coding 是一个非常基于意见的说法。我两者都做，并且更喜欢编码

【解决方案4】：

我认为让开发人员编写测试将是最有用的。这样，您可以在整个开发周期中进行“破损检查”，而不仅仅是在最后。如果您每晚进行自动化构建，您可以在它们很小的时候捕获并修复它们，以免它们变成巨大的、卑鄙的、吃人的 bug。

【讨论】：

【解决方案5】：

测试人员提议测试，而开发人员实际编写测试呢？

【讨论】：

一般来说，开发人员忙于编写 QA 将要测试的代码，而没有时间编写测试。我不了解贵公司，但在我工作过的每一家公司中，如果开发人员有时间编写测试，（错误）经理就会批评该开发人员，因为该开发人员应该添加更多功能。
thinkworks“Twist”应用程序看起来是按照这种东西建模的

【解决方案6】：

我相信起初这在很大程度上取决于您使用的工具。

我们公司目前使用Selenium（我们是Java商店）。

Selenium IDE（在 Firefox 中记录操作）工作正常，但开发人员需要手动纠正它对我们的 web 应用程序所犯的错误，因此它并不适合 QA 编写测试。

我过去尝试过的一件事（取得了一些成功）是将库函数编写为 Selenium 函数的包装器。他们读的是简单的英语：

selenium.clickButton("Button Text")

...但在幕后检查按钮上的正确布局和标签，有一个 id 等。

不幸的是，这需要进行大量设置才能轻松编写测试。

我最近发现了一个名为 Twist 的工具（来自 Thoughtworks，基于 Eclipse 引擎构建），它是 Selenium 的包装器，允许编写简单的英语风格的测试。我希望能够将这个提供给测试人员，他们可以用简单的英语编写简单的断言！

它也会自动为新断言创建存根，因此测试人员可以编写测试，并在需要新代码时将它们传递给开发人员。

【讨论】：

这基本上是我对我的 ruby 脚本所做的（在白色框架上抽象）。我有类似 "ok_button = window.find_button("OK"); ok_button.click" 的代码

【解决方案7】：

我发现最合理的选择是拥有足够的规范，以便 QA 人员可以将测试存根，基本上弄清楚他们想要在每个“屏幕”或每个组件上测试什么，然后将它们存根。存根的命名应使它们对所测试的内容非常具有描述性。这也提供了一种明确功能需求的方法。事实上，以这种方式完成需求特别容易，并且可以帮助非技术人员真正渡过他们自己的泥潭。

可以通过 QA/开发人员的组合来填写存根。这使您可以廉价地培训 QA 人员如何编写测试，并且他们通常会大吃一惊，因为这可以提高他们的工作安全性。

【讨论】：

QA 人员将如何取消测试？他们会编写一个充满测试的实际代码文件吗？还是给你一个充满要求的word文档？我认为开发人员会用实际的 UI 自动化代码填充存根？
QA 实际上是函数存根，或者其他可能的函数。这些名称应该作为敏捷文档。您应该能够解析这个，并在骆驼案例上运行一个简单的拆分，以获得符合每个要求的粗略句子。

【解决方案8】：

我认为这主要取决于您的测试团队的技能水平、可用的工具以及开发人员和测试人员如何互动的团队文化。我现在的情况是我们有一个比较技术的测试团队。所有测试人员都应具备开发技能。在我们的例子中，测试人员编写 UI 自动化。如果您的测试团队没有这些技能，他们将无法取得成功。在这种情况下，开发人员最好为您编写 UI 自动化。

其他需要考虑的因素：

测试人员还有哪些其他测试任务？您的客户是谁，他们对质量的期望是什么？开发团队的技能水平如何？他们对测试自动化工作的意愿如何？

-罗恩

【讨论】：