51Testing软件测试论坛

标题: 不应该使用Selenium自动化的10个测试场景 [打印本页]

作者: lsekfe 时间: 2021-2-24 10:48
标题: 不应该使用Selenium自动化的10个测试场景
　尽管在很多情况下测试自动化是有意义的，但一些测试场景是不应该使用[url=]自动化测试[/url]工具的，比如Selenium、WebDriver。　　下面有10个示例，来解释为什么自动化在这种情况下使用时没有意义的，我还将为您提供每种方法的替代方法。
　　1.验证码
　　CAPTCHA是完全自动的公共的图灵测试，以区分计算机和人类之间的区别的简称，它的存在是为了防止自动化，因此甚至不值得尝试。
　　在测试过程中，有两种主要策略可以解决CAPTCHA检查问题。如下：
　　1）在测试环境中禁用CAPTCHA。这可能是被测软件中的简单配置。或者甚至可以在测试的URL参数中配置；
　　2）添加一个挂钩，以允许测试绕过验证码。
　　2.外观测试
　　视觉自动化测试意味着检查页面如何呈现和呈现给最终用户。这对于检查多种设备和屏幕分辨率非常有价值。我们中的许多人试图通过使用代码检查单个页面上是否存在数十个甚至数百个元素来做到这一点。WebDriver不是正确的工具。
　　相反，最好使用专用的视觉测试工具。这是我以最受欢迎的屏幕分辨率测试网站的示例：

　　实现代码：

　　3.双因素认证
　　您不应该通过UI自动化的另一种情况是双因素身份验证（或2FA）。即使用“身份验证器”移动应用（例如GoogleAuthenticator或MicrosoftAuthenticator）生成一次密码，并通过SMS或电子邮件发送一次密码的地方。
　　在Selenium中自动化它是一个巨大的挑战，但这并不意味着它无法完成。尽管可以自动化，但它是要添加的另一层，并不安全。因此，最好避免完全自动化。
　　解决2FA检查的三个选项如下：
　　1）在测试环境中为某些用户禁用2FA，因此您可以在自动化中使用这些用户凭据。
　　2）在测试环境中禁用2FA。
　　3）如果您从某些IP登录，请禁用2FA。（通过这种方式，您可以配置测试计算机的IP来避免这种情况。）
　　4.文件下载
　　通过API自动执行文件下载不是理想的方法，因为API不会公开下载进度。下载文件不被视为模拟用户与Web平台交互的必要方面。
　　因此，您应该考虑完成此解决方法：
　　使用Selenium和任何必需的cookie查找链接，并将其传递给HTTP请求库，例如REST保证（Java），fetch（JavaScript）或libcurl（跨平台）。
　　5.HTTP响应代码
　　HTTP状态代码是Internet上网站服务器给出的标准响应代码。当网页或其他资源无法正确加载时，这些代码有助于确定问题的原因。在自动化功能测试中，检查状态码不是测试失败的特别重要的细节；之前的步骤更为重要。
　　最好将API测试保留在这一层。WebDriver不是API测试工具。因此，您可以使用诸如RESTAssured（Java），fetch（JavaScript）和RestSharp（.NET）之类的库。
　　6.Gmail、电子邮件和Facebook登录
　　您不应该通过UI自动化的另一种情况是Gmail，电子邮件和Facebook登录。不建议使用WebDriver登录这些类型的网站。这违反了使用条款，而且速度慢且不可靠。
　　一般而言，较长的测试更加脆弱且不可靠，这使您面临测试失败的风险。对超过20亿次测试的研究证实，持续时间超过2分钟的测试失败的可能性是原来的两倍。
　　相反，最好使用电子邮件提供商提供的API，或者对于Facebook，使用公开显示用于创建测试帐户的API的开发人员工具服务。（GmailAPI在这里。）
　　使用API似乎有些额外的工作，但是您将获得速度，可靠性和稳定性的回报。API也不太可能更改。但是，网页和HTML定位器经常更改，并且需要您更新测试框架。
　　7.性能测试
　　通常不建议使用Selenium和WebDriver进行性能测试，因为它并未针对工作进行优化，因此您不太可能获得有价值的结果。WebDriver测试受到许多外部和内部脆弱性的影响，而这超出了您的控制范围。
　　其中包括浏览器的启动速度，HTTP服务器的速度，托管JavaScript或CSS的第三方服务器的响应以及WebDriver实现本身的检测损失等。它将导致结果变化。您将获得较慢的性能测试，其中包括后端和前端性能。
　　而是使用免费工具（例如GoogleLighthouse）来提高前端性能。然后，使用免费工具（如ApacheJMeter）执行单独的负载或压力测试。
　　为了发现需要改进的地方，您需要能够独立于环境差异来分析总体性能，识别不良的代码实践并分解单个资源（即CSS或JavaScript）的性能。
　　8.链接爬虫
　　我不建议使用WebDriver进行链接爬虫，换句话说，通过链接来爬网。您可以做到，但是WebDriver绝对不是此任务的理想工具，因为它需要一些时间才能启动。这可能需要一分钟的时间，具体取决于测试的编写方式，只是要转到页面并遍历文档对象模型。
　　此外，编写遍历页面和捕获链接的逻辑只是浪费时间。
　　除了使用WebDriver，还有许多更简单的方法。可以搜索这两个免费工具：
　　www.brokenlinkcheck.com，它在几分钟之内就找到了我网站上所有断开的链接。
　　www.deadlinkchecker.com
　　9.视频流
　　如今，视频流越来越流行，但是您可能不想通过UI对其进行自动化。Selenium通常无法识别视频控件。JavaScriptExecutor和flex-ui-selenium可以在某种程度上起作用，但是它们并不完全可靠。
　　相反，请查看StreamTest，它是一个免费工具，可以衡量最终用户的体验质量。您甚至可以添加监视。
　　10.崩溃恢复
　　恢复测试是一种软件测试技术，可验证软件从故障（例如软件和硬件崩溃）中恢复的能力。您可能要测试应用程序的崩溃恢复。最好手动测试。这并不是说您不能使用Selenium进行测试，但是这样做并不可行或无益。
　　对于可靠性测试，从开发的各个阶段（例如设计和操作阶段）收集数据。由于成本和时间等限制，测试受到限制。
　　在这些情况下使用替代测试
　　以上是您不应该通过UI自动化的十大场景。包括验证码测试、外观测试、双因素验证、视频、崩溃、链接爬虫、性能测试、文件下载、http状态码、电子邮件登录。
　　您可以在工作时参考它们，并尝试在开发，编码和测试时确定最佳的方法。
　　尽管在某些情况下有变通办法，但首先考虑为什么不应该自动化这些特定元素的原因。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)