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

Question

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

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

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

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

一些想法:

开发人员似乎更适合这样做，因为他们知道控件 ID、类等，并且对应用程序的工作方式有更好的了解

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

我已经使用 IronRuby 编写了一些初始脚本和 White .这非常有效，并且功能强大到几乎可以做任何事情，但是您需要能够编写代码来编写 UI 测试

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

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

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

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

Answer 1

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

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

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

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