GUI自动化记录方法的比较
GUI自动化记录方法的比较
提问于 2014-01-20 07:40:30
我最近加入了自动化小组。我们目前正在为我们的web应用程序开发一个自动化框架，它已经在生活环境中存在了一段时间。我设计并开发了一个框架来执行任何使用Sahi开源4.4记录的测试脚本。我被困在评估用于记录GUI测试用例的方法上。
在测试下的应用程序: AUT是一个web应用程序，它使用AJAX，也有一些定制的图表和报告。
可用的录音方法如下
- 记录回归错误:在系统中有大约3000种被关闭/打开的bug，它们可以被自动化并作为回归套件使用。在这里的前期问题，即使在3000记录流量，自动化可能不涵盖完整的网络应用程序。
- 记录您的业务流程:此方法将记录业务流程及其验证。这将最终涵盖完整的网络应用，如果使用数据驱动测试聪明。但是web应用程序是复杂的，即使有数据驱动的测试，也可以有大量的流。我们也在很短的时间内运行，这可能会限制这种方法。另外，有些流非常复杂，因此脚本及其数据驱动的支持可能变得非常复杂，并且不可维护。
- 独立记录验证和流程:这种方法将将验证记录为单独的测试用例，将实际的业务用例记录为单独的测试用例。这将减少我的记录脚本的大小，因此将是可维护的。分离给了我一个确切的失败点，说明它是字段验证失败，还是业务流程是failing.Hence，我对脚本失败的调试。但我无法决定这种做法是否有任何看不见的问题。
我的查询/关注：
- 我想知道我是否可以继续使用方法3作为我的记录方法，或者是否有任何其他的改变或一个新的方法完全。我正在寻找其他公司是如何录制的，但无法得出结论。
- 我想评估一下我的方法3是否能够忍受我们即将采用的敏捷方法。
- 如果我的录制工具Sahi开放源码的选择是正确的或不适用于AJAX。
- 无论是将记录工具输出作为脚本导出，还是将其导出为像java代码一样的编程语言导出。
回答 1
Stack Exchange QA用户
回答已采纳
发布于 2014-01-20 13:05:44
在这里很难给出一个明确的答案，但我可以给你一些想法。
- 将可维护性作为第一优先级。根据我的经验，一旦一个回归套件启动并运行，它可能需要很长一段时间才会消失。
- 在可维护性之后，查看80/20规则-- 20%的应用程序获得了80%的使用。这是您的最高回归ROI的来源。
- 在设置了80/20规则之后，查找覆盖范围中的空白。这将显示为大多数回归错误报告来自客户的领域。手动测试人员还将知道应用程序的哪些部分是最脆弱的。
- 每次在回归测试中添加覆盖率时，从添加的功能的核心功能开始。然后扩展到80/20规则。在此之后，您可以考虑添加针对该特性报告的bug的测试。
- 别担心工具。如果它能够到达它需要到达的页面上的组件，那么它就足以完成任务。
- 在采用敏捷的过程中，做好应对混乱的准备。我还没有看到任何不包括完全混乱阶段的敏捷实现的采用。对于GUI自动化，您需要考虑的是，您不会针对移动目标进行自动化:通常，GUI自动化应该在每一段功能稳定之后进行。任何尝试GUI自动化之前，这变成了打击(是的，我一直在那里)。无论您选择哪种方法，都不会有任何影响--构建GUI回归所需的时间不会因为开发方法的变化而改变。从好的方面来说，如果转向更敏捷的方法增加了单元测试，那么您应该能够减少GUI回归的数量，这些回归集中在更适合于单元测试领域的领域。
- 录音/回放是危险的。我怎么强调都不够。几乎每个工具都以“无代码”为卖点，但事实是，迟早您需要使用记录功能来识别您需要与之交互的组件，然后编写您的交互以获得最大的可重用性和可维护性。
- 输出并不重要--可重用性和可维护性就是如此。只要您可以在任何系统上运行回归，任意地旋转和旋转系统，那么您是将工具输出导出为脚本还是作为可编译/编译语言导出并不重要。
。
页面原文内容由Stack Exchange QA提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://sqa.stackexchange.com/questions/7570
复制相关文章
相似问题
腾讯云开发者
