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

Question

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

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

第二个目标是帮助测试人员处理重复性任务。

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

一些想法：

• 开发人员似乎能够更好地做到这一点，因为他们知道控件 ID、类等，并且对应用程序的工作方式有更好的了解

• 测试人员的优势在于不知道应用程序是如何工作的，因此可以生成可能更有用的测试

• 我已经使用编写了一些初始脚本 铁红宝石 和 白色的. 。这非常有效，并且足够强大，可以做任何事情，但是您需要能够编写代码来编写 UI 测试

• 我们尝试过的所有自动化 UI 测试工具（TestComplete 等）似乎都非常复杂和脆弱，虽然测试人员可以使用它们，但需要花费大约 100 倍的时间，并且不断遇到“意外的复杂性”由UI测试工具引起的。

• 我们的测试人员不会编码，虽然他们很聪明，但当我建议测试人员可以编写简单的 ruby​​ 脚本时，我得到的只是有趣的表情（尽管所说的脚本比那些乱七八糟的乱七八糟的脚本更容易阅读和编写 100 倍）按钮和数据网格似乎是自动化 UI 测试工具的标准）。

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

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

Answer 1

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

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

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

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

Answer 2

根据我的经验，会编码的测试人员会跳槽以获取开发人员的加薪。

我同意你关于自动化 UI 测试工具的看法。我工作过的每个地方都足够富有，可以负担得起 WinRunner 或 LoadRunner，但却无法让员工实际使用它。价格可能已经改变，但当时，这些价格处于高 5 位数到低 6 位数的价格标签中（想想入门房的价格）。这些产品很难使用，并且通常被存放在上锁的柜子里，因为每个人都担心损坏它们会带来麻烦。

Answer 3

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

前段时间，我在几篇博客文章中表达了我对技能矩阵的想法。

如果有兴趣讨论：

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

谢谢。

Answer 4

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

Answer 5

提出测试的测试人员和实际编写测试的开发人员怎么样？

Answer 6

我相信首先这很大程度上取决于您使用的工具。

我公司目前使用 硒 （我们是一家 Java 商店）。

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

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

selenium.clickButton("Button Text")

...但在幕后检查按钮上的布局和标签是否正确，是否有 ID 等。

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

我最近意识到一个叫做 捻 （来自 Thoughtworks，基于 Eclipse 引擎构建），它是 Selenium 的包装器，允许编写简单的英语风格的测试。我希望能够将其提供给测试人员，他们可以用简单的英语编写简单的断言！

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

Answer 7

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

存根可以通过 QA/开发人员的组合来填写。这使您可以廉价地培训 QA 人员如何编写测试，并且他们通常会接受它，因为这可以进一步提高他们的工作保障。

Answer 8

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

其他需要考虑的因素：

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

-罗恩