大多数功能测试用例和自动化测试用例在测试环境中以速度验证通过,但是很难保证这些用例在生产环境中具有相同的效果。特别是跨浏览器测试,则需要确保跨各种操作系统,运行在不同操作系统上的各种浏览器,浏览器版本无缝呈现Web应用程序。毕竟,在您实际进行生产测试之前,您可能永远都不知道用户会采用哪种鬼一样的搭配组合访问网站,对吗?
但是,说起来容易做起来难。作为敏捷测试人员,每周甚至每天都会收到新的测试要求。这就是为什么要求在生产环境中以及测试环境中都要进行完整测试的原因。从经验中,我知道如果手动完成,这可能是一个艰苦而艰巨的旅程。自动化这个时候就能够大显神威,帮助我们解决部分效率上的问题。
如果只是初入行的测试人员,那么很有可能您可能不是十分理解SDLC(自动化测试生命周期),并且您可能会怀疑生产环境和测试环境哪里不同?我们在生产中要测试跟生产环境测试区别在哪?
每个应用程序都在不同的环境中克隆。有些用于开发人员,有些用于测试人员,另一些用于您的客户。与客户进行交互的应用程序运行环境称为生产环境,而其他应用程序称为测试环境或开发环境。因此,每当新的增强功能进入发布周期时,便首先将其部署在属于开发人员的阶段环境中,以便他们可以对更改进行单元测试以及自测。确认更改后,将更改推送到测试人员所属的暂存环境中,他们可以在其中执行详细的集成和回归测试以验证代码更改。一旦测试团队通过了签字通过,更改就会进入生产环境的队列,您的客户可以在其中使用添加到应用程序中的最新功能。
尽管测试团队在测试环境中进行了详细的测试,但是一旦将更改推送到生产环境中,他们就应该执行另一轮详细的测试,以确保不会妨碍客户的用户体验。最后一轮测试称为验收测试。
几乎所有测试,除了在线下环境中经过验证的测试脚本之外,生产中的测试还包括测试环境无法识别或预测的测试用例,例如实际的购买、不同的网络环境甚至不同的地理环境。
您可以根据需要编写任意数量的用例,但这不足以复现实时生产环境。重现客户数据或预测其行为并不容易。同样,如果您的测试环境不是生产环境的精确克隆(在大多数情况下是正确的),那么很有可能在某次上线后爆发,或者错误发现问题的时机,错误浏览器兼容性的BUG。
这就是为什么在每个发布周期中,都必须在生产环境中进行跨浏览器测试的原因。但是,如果不是单调的话,要在数百种浏览器和操作系统上测试Web应用程序肯定会很复杂且低效率。很多时候,由于紧急热补丁导致紧急中断和测试时间不足,您甚至可能最终在最后1小时执行浏览器兼容性测试,因此,您可能最终只进行了冒烟测试而不是回归测试。
要解决浏览器兼容性问题,一般的方案是使用Selenium gird
。首先确保您已经准备好在零停机时间内在我们的在线Selenium Grid
上执行Selenium
测试自动化套件。其次在使用在线Selenium Grid
在生产中执行自动浏览器测试可以帮助您清除维护内部Selenium Grid
所花费的主要时间障碍,并跨不同的操作系统/设备/浏览器分别测试Web应用程序的功能。这可以帮助您确保在生产中验证产品的跨浏览器兼容性。
决不能忽视生产中的硒测试自动化。让我们看一下测试自动化在生产中的好处。
到目前为止,我们知道在生产中测试 Web 应用程序变得势在必行。但是我们需要自动化它吗?Selenium
测试自动化有什么好处,让我们看一看。
借助测试自动化的便利性,不仅测试 Web 应用程序,而且每天监控这些测试的结果得相当容易。团队可以自己开发直观的仪表板或者每日邮件通知,可帮助分析硒测试自动化套件执行的结果。您可以看到所有时间戳以及各种日志,以帮助您快速调试自动化测试脚本遇到的任何问题。
生产环境中的测试自动化可以帮助您在应用程序高峰时段安排一轮全面的自动浏览器测试。从而有助于在高负载情况下确保软件服务质量。
测试自动化可以帮助加快回归测试工作。这样,每次将新代码提交到生产中时,您所要做的就是运行您的测试脚本,并且所有内容都将在不同的浏览器之间自动验证。利用测试自动化还可以帮助更快地执行Beta程序,因此您可以立即获得新推出的功能和用户体验的反馈。
现实情况是,在许多公司中,测试团队往往犹豫不决,或者更忽视生产中的测试。这背后可能有多种原因。其一是敏捷测试器的寿命很艰苦,每周或每月他们的测试要求只会变大。另一个原因是过渡环境中测试周期造成的过度的劳累,测试工程师缺失在生产环境充分测试。在完成了测试环境测试套件后,在生产中测试相同的东西会成为一种让人刚到非常无趣的体验。
接下来的问题是围绕如何实现!!如何在生产中开始自动化测试?线上环境需要哪种自动化策略?让我们进一步探讨在生产中执行测试的策略或方法。
在此策略中,部署在两个类似的生产环境中完成,这些环境是蓝色和绿色,彼此相同。在任何时候,只有一个环境处于活动状态,为所有生产提供服务。在这种情况下,蓝色获取所有生产流量,绿色是蓝色克隆保持空闲。所有测试都以空闲状态(即绿色)进行,一旦测试以绿色完成,所有流量都路由到它,并成为新的生产。
在灰度测试中,新功能仅针对一小群最终用户推出。当确保应用程序在目标组中正常工作时,然后在针对所有用户发布新版本。
在A/B
测试中,您将应用程序的两个不同版本推广到最终用户。一个版本可以是旧版本,另一个版本可以是新推出的功能。然后可以进一步分析哪个版本性能更好,基于您保留性能更好的版本。
在此策略中,每当发现故障时,服务仍处于监视阶段时,都会将应用程序返回到以前的稳定版本。正确实现后,回滚可以帮助您实现以前的稳定应用状态,但实现不佳可能会导致数据丢失。
生产中测试的主要议程是确保应用程序在生产环境中稳定。为了避免故障,您需要使测试脚本自动化,以确保在所有最新的和旧版浏览器中都对应用程序进行了尝试和测试。自动化测试不仅可以自动化重复的测试用例,还可以帮助我们并行执行它们。最终,减少测试周期内的总体时间消耗和资源消耗。