博闻焦点|不想舍弃Selenium,如何解决UI测试自动化的Selenium问题?( 二 )


挑战3:调试和诊断自动化故障
调试和诊断Selenium测试非常困难 , 并且可能会浪费大量的时间(尤其是在与不断变化的UI结合使用时) 。 我们发现 , 各种解决方案都试图通过为自己的框架提供高级报告功能来解决这一难题 , 但是随后 , 测试人员最终被锁定在专有平台或IDE中 。 如果您打算在整个余生中继续使用该供应商或工具 , 那么这是“好的” , 但是想要保留开源所提供的原始自由的Selenium用户又如何呢?
解决方案:智能自动化和报告
为了解决这一挑战 , 您可以结合使用报告和测试执行分析 , 以及IDE工具 。
通过将报告工具(如Parasoft Selenic)插入现有的CI / CD管道中 , 您可以更轻松地了解哪些测试失败以及原因 。 通过运行时自我修复 , Parasoft Selenic可以防止由于不稳定的测试而导致构建不必要地失败 。 测试完成后 , Selenic将提供修复那些损坏的测试的建议 , 这些建议可以直接导入IDE以进行自动修复 。
IDE本身(例如Eclipse和IntelliJ)具有调试功能 , 可让您在Selenium测试中设置断点并在特定点暂停应用程序 , 因此您可以提取有关UI状态以及可能发生的情况的信息 , 因为应用程序失败 。
挑战4:执行整个脚本所花费的时间
与在应用程序的API/服务层上运行的测试相比 , 自动UI测试的运行时间更长(并且比隔离的单元测试要更长) , 并且创建的UI测试越多 , 执行这些测试所花费的时间就越多 , 并且您需要等待CI/CD管道反馈的时间更长 。 问题在于 , 由于频繁的代码更改 , 管道每天要触发多次 , 因此您不能等到第二天(有时是在周末)才能获得有用的反馈 。 需要一种优化测试套件执行的方法 , 以在快速反馈与全面覆盖之间取得平衡 。
解决方案:测试影响分析
您可以在这里利用诸如Parasoft Selenic的测试影响分析之类的技术 。 通过跟踪每个Selenium测试涵盖的代码 , 并将其与代码库中的更改相关联 , 您可以确定需要执行以验证代码更改的测试子集的优先级 。 使用Parasoft Selenic , 您无需访问基础代码 , 因为它只需扫描二进制文件(例如.war或文件) , 识别在构建之间已更改了哪些类 , 然后将其映射到受影响的测试用例即可启用 。 您可以将一部分Selenium测试作为CI/CD管道的一部分运行 。 (查看Parasoft Selenic:如何在CI/CD管道中修复Selenium)
挑战5:创建脚本所需的知识和技能
最后 , 首先创建Selenium测试所需的知识和技能会使Selenium的使用令人望而却步 。 根据我们与谁交谈 , 这是人们所面临挑战中的第一个或最后一个 。 我们通常会看到 , 当用户刚开始使用Selenium时 , 他们面临的第一大挑战是测试创建-但是一旦他们开始并建立成熟的测试实践 , 它就不再是第一挑战 , 而实际上是另一个挑战问题变得更加重要 。 因此 , 从我的角度来看 , 克服最初的障碍是真正的挑战 。
解决方案:代码助手
诸如无代码的Selenium和NLP驱动的Selenium创建之类的事情 , 但是我还没有特别看到一种能像我们所有人希望的那样运作的东西 。 Selenium的主要现实之一是它的代码 。 这是好是坏?很好 , 因为如果您需要做的事情超出了“常规做法”范围 , 可以通过快速Google搜索找到一些好的代码示例 。 这很糟糕 , 因为它是代码 , 这对某些测试人员来说是一个障碍 。
因此 , 您需要成为一名开发人员来构建Selenium脚本吗?答案是否定的 , 但是某些开发技能确实可以提供帮助 。 正如我之前提到的 , 许多出色的新UI测试工具都具有可以构建Selenium脚本的记录器 , 例如Parasoft Selenic , SeleniumIDE和Katalon 。 这些帮助器工具将为刚接触Selenium的用户提供快速入门 , 并在无代码和已编码之间提供中间立场 。 当然 , 您必须意识到没有一个UI记录和回放工具是完美的(当然 , 也有解决这些挑战的方法) 。


推荐阅读