您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 性能测试 > 正文

为CI/CD构建高性能的测试

发表于:2020-06-05 作者:陈峻译 来源:51cto

朋友,您还记得小时候听过的《三只小猪》的故事吗?面对大灰狼的来袭,只有建造了坚固的房屋(基础设施)的第三只小猪,才能逃过一劫。现如今,面对各种高速发展的持续集成与交付要求,我们同样需要构建好具有自动化特征的基础环境,以便快速地开展各种高性能的测试。

下面,我们来看看如何通过目标、技术和团队的准备,在快速增长的环境中,实现敏捷地高性能测试与发布。

定义高性能测试

从理论上说,那些具有高增长特征的初创企业最渴望高性能的测试。它们通常具有如下的“敏捷”特征:

  • 混乱状态–需要适应瞬息万变的内、外部环境。
  • 更少的用时–所有问题都需要得到全员的重视,并需要得到及时的解决。
  • 更少的资源–由于现有资源有限,因此需要善于向外部“借势”,以促进当前项目的集成与交付。
  • 市场压力–需要了解和评估外部风险,以迅速调整内部策略。
  • 奖励–善于发现点滴改进,及时反馈并鼓励整个团队。

为何要进行高性能测试?

纵观整个行业,应用业务技术在过去十年中发生了如下巨大的变化:

  • 使用范围–当前的应用服务往往可以运行在多个平台(Web应用端、或移动设备)上,而非某个专有的应用程序、或单个浏览器上。
  • 发布频率-我们经常按需且频繁地发布应用程序。
  • 流程–我们已经从瀑布式的开发方式,转变成为了持续交付。
  • 框架-过去的单栈本地部署(singe-stack on-premise)软件模式,已经转变成为如今使用开源、基于云端的开发与交付模式。

总之,我们沿用了十年的“最后再进行测试”的模式,已经不再行之有效。我们正在建立一种新的测试模式。

如何实现高性能测试

为了满足快速增长的环境需求,软件团队需要尽早了解现有的情况,以着手解决各种矛盾和问题。例如:您既可以使用思维导图将情况可视化,也可以通过划分短期和长期目标,让功能性团队专注于测试,让框架团队专注于系统的长期架构。

另一个值得关注的目标是:如何通过测试左移,尽早地发现缺陷。为此,我们需要了解现有的工具和需要添置的工具,软件质量的行业标准,本团队当前在构建自动化架构方面的实力,以及如何通过AI和机器学习(ML)的支持来提高效率。

建立团队

接下来,我们来讨论如何建立一支高性能测试的团队。

过去我们依靠的是专职的质检(QA)服务团队。如今,我们需要配备了集成Pod的真正敏捷团队。质量工程师作为他们的团队资源,在整个开发和交付过程中提供协助。在团队中,我们需要有人熟悉行为驱动设计(behavior-driven design)和测试驱动设计(test-driven design),有人会选择并使用自动化工具,有人需要考虑可测试性设计(design-for-testability)。

由于测试自动化的大部分会涉及到框架,因此我们需要熟悉构建代码的技能集,通过自动识别元素定位符(self-identifies element locators),来构建用于自动化控件的钩子(hooks),进而确保每次构建的一致性和实现自动化的可重复性。

测试自动化

过去,我们需要从单个供应商那里购买一整套测试工具。如今,开源的解决方案为自动化提供了丰富的资源。开源的方式不但可以降低维护的成本,而且能够让您更快、更容易地交付出具有可扩展性的软件产品。作为开源工具的“衍生品”,用户社区往往能够提供某些工具的最佳实践,以及各种宝贵的课程可供学习。

通常,我们可以在软件部署过程中的如下方面实现自动化:

  • 断言行为(Assertions on Action)
  • 初始化和清理
  • 数据建模与模拟
  • 配置
  • 各种安全建模的抽象
  • 包和帮助
  • API的使用情况
  • 各项面向未来的功能
  • 本地和云端设置
  • 速度
  • 各种调试功能
  • 跨浏览器
  • 模拟器与真实设备
  • 内置的报告与插件

行业标准

如今,对于自动化测试,业界基本上形成了如下四种类型的标准:

  • 质量–至少要能够通过全部测试的90%。
  • 运行时间–所有测试的平均运行时间应控制在两分钟之内。
  • 平台覆盖率–平均覆盖五个关键性的被测平台。
  • 并发性–在使用高峰期,测试至少要占用75%的可用运能。

生产环境的测试

您是否考虑过将测试移至生产环境(Shift Right)?我们提出该方法的原因有如下四个方面:

  • 功能标记–在生产环境中进行测试,可以采集到真实的数据,以用于测试。
  • 流量分配–我们可以逐步引入新的功能,并在不影响整个客户群体验的情况下,针对被测案例,跟进获取到的部分目标用户的实时数据。
  • 内部测试(Dog Fooding) –采用CDN之类的快速部署功能,将内部用户引导到新的功能服务上。
  • 净减少–通过减少额外的开销,使应用程序可以使用真实的数据集进行测试,并且能在不影响整个客户群的情况下快速定位问题。

总之,生产环境中的测试,可以让累计的大型发布,变成一组组基于通用代码的小型迭代。由于有不同职能的人员参与测试,因此也确保了客户群不会因为大幅度升级而感到不适。

人工智能(AI)/机器学习(ML)

AI/ML工具的使用不但能够提高整个团队的工作效率,而且还能够满足高性能测试环境的质量需求。其中,Applitools就是一个被AI赋能了的测试工具。它通过自动化视觉AI,来开展各种回归式的视觉测试,自动验证页面的提交,进而帮助企业以更低的成本,更快地发布软件项目。例如:某个医药网站有着上百个介绍药物适应症和注意事项的页面。为了确保这些页面一致性,我们可以使用Applitools去进行验证。它可以在不到12分钟的时间内完成完整的视觉回归,并运行350个测试案例,其中包括2500项检查。而我们如果采用手动验证的话,则需要六个小时以上。

ReportPortal.io

作为一个统一的自动化测试平台,ReportPortal.io可以实现报告的收集,分析,可视化,以及集成多种测试框架,其中包括:TestNG和Selenium等。在实际应用中, Reportportal.io能够显示一天中不同时段的测试运行方式,发现其中的错误,进而帮助团队实现无缝的发布和改善其统计的信息。同时,Reportportal.io中任何失败的测试用例,都可以被作为测试结果日志,直接链接到Reportportal.io的用户界面中。

此外,我们可以配合使用行为驱动设计(BDD),来描述被测功能的所需行为,进而满足客户所需的高性能和高可用性。

设立质量目标

我们在快速增长的环境中,需要事先设立软件的质量目标,以满足用户和运行环境的需求。其中包括:

  • 有分布式质量检查小组,提供7*24的质量检查支持。
  • 有专门从事测试的SDET(软件测试开发人员)团队。
  • 有一个能够简化任何POC(为观点提供证据)的即插即用式强大框架。
  • 一个使用Travis(自动化集成部署服务)测试的稳定管道。
  • 通过完全自动化将回归的时间减少90%。

建立团队和技术栈

当然,为了实现上述目的,我们需要雇用一个具有开发素养和测试素养的团队,也就是说,他们应当同时具备编程和测试自动化的相关能力。同时,我们在技术栈方面的投入包括如下方面:

  • Python和Selenium WebDriver。
  • BDD。
  • 能够在云端运行的Browserstack。
  • 针对视觉回归的Applitools。
  • Jenkins、Travis和Google Drone for CI。
  • Jira和TestRail的相关文档。

在此基础上,我们可以确定CI/CD的四项成功标准:

  • 速度与并行化(parallelization)。
  • BDD易于调试与阅读。
  • 在CI/CD中实现跨浏览器、跨设备的覆盖。
  • 实现视觉验证。

为CI/CD测试设定QA期望

在CI/CD的环境中,测试和构建往往并非同步进行的。因此,我们需要事先设定好构建与测试的频率。您可以借鉴如下公司的设定标准:

  • 质量检查人员每小时针对最新的版本运行73次测试,以检查目标站点是否能正常运行。
  • 任何新的构建都需要在6种跨浏览器上试运行,并确保涉及到所有的关键性业务路径。
  • 除部分测试外,每晚例行执行300个回归测试。

当然,上述只是某些个案,您可以根据自身企业和项目的特点,不断地进行增加和完善。

结论

俗话说:“工欲善其事,必先利其器”。正如我们开头提到的《三只小猪》的故事那样,要想在高速增长的公司内部,让质量工程师能够迅速地开展成功有效的高性能测试,我们需要对自动化、团队人员、AI/机器学习、乃至基础架构,事先进行有针对性的投资、改造和完善。

【原标题】Acing High-Performance Tests for CI/CD (作者: Michael Battat )