持续测试是指在软件开发生命周期中的不同阶段纳入自动反馈的过程,其中包括探索性测试等自动化测试外的活动。持续测试是 CI/CD 流程取得成效的关键因素,通过提高代码质量来避免付出多余的人力、物力和财力,从而加快 DevOps 流程。在 Dan Ashby 创建的 DevOps 持续测试模型图(如图 1)中,他表明我们可以在任何一个阶段进行测试。
图1 DevOps模型中的持续测试
对于持续测试存在一个误区:持续测试就是测试左移。这是两种不同的方法,测试左移是指将测试活动在软件开发生命周期中的介入时机向前推动,以便尽早发现问题。持续测试与测试左移是两种不同的方法,因此测试左移不能作为不执行持续测试的借口。
一、 什么是持续测试
“持续测试是指每次代码更改时定期执行的自动化测试,这些测试作为软件交付的一部分进行,以推动对推送到代码存储库的最新更改进行更快的反馈。”这是 BrowserStack 对持续测试的定义,也是大多数组织通常所采用的定义。
虽然自动化测试在实现持续测试方面发挥着重要作用,但持续测试并不只是包括自动化测试这么简单。
根据图 1 中的持续测试模型图的左侧,通过提前开始讨论和质疑需求来检验计划,这个过程就能够进行测试。通过在本地拉取代码并探索功能来测试分支,也能够进行测试。此外,当进行代码审查并确保自动化测试的有效性时,同样会就会发生测试,甚至测试还发生在合并和构建过程中。
另一方面,图 1 中持续测试模型的右侧显示,一旦更改发布并部署,测试也会持续进行。如果使用金丝雀发布或蓝绿部署等部署技术,这些技术也会经过测试以确保部署成功。当更改部署到生产环境中后,真实用户会不断测试这些更改。但测试并不止于此,还发生在监控阶段,通过收集指标和数据来持续推动改进。
持续测试不只是自动测试,还可以在其他测试模式中实现,例如软件开发生命周期之前进行测试的想法。持续测试需要建立在开放学习、协作的团队文化中,必须鼓励团队成员尝试不同的方法,并确定哪种方法适合团队的测试需求。
二、 如何实施持续性能测试
传统方法的性能测试是如何进行的,为什么这种方法的测试不能很好地扩展?
传统的性能测试被视为发布到生产之前的最后一项活动。它在验证系统的主要功能之后进行,并需要一组专门的性能测试人员。然而,由于性能测试位于最后阶段,一旦性能测试期间发现任何 Bug,修复这些 Bug 就需要付出多余的人力、物力和财力。此外,随着功能的快速开发和发布需求,传统的性能测试方法难以融入到敏捷模式中。
那么,如何实施持续性能测试方法呢?通过引入自动化性能测试,在添加新更改时自动触发是不够的。我们要记住持续测试不仅是指自动化测试,参考 Dan Ashby 的持续测试模型,我们可以将性能测试纳入软件开发生命周期的各个阶段。
1、规划
在讨论中将性能要求作为每个功能的一部分,并根据现有服务级别协议(SLA)创建验收标准和已制定的服务级别目标(SLO)是很重要的。如果没有 SLA 或 SLO,团队可以一起合作制定这些 SLA 和 SLO。同时,考虑将性能要求纳入到完成定义(DoD)中,这可以提高团队对性能的认识,确保性能需求在开发的每个功能中得到充分考虑。
2、分支及编码
团队成员可以审查代码并检查可能出现的任何性能瓶颈。同时,在开发代码的同时编写自动化性能测试也是非常有用的。在此阶段,性能测试主要是针对较低级别的组件进行的,而不是全面的端到端性能测试。团队成员可以从性能角度对的组件进行,例如:
·专注于协议级别的测试,不涉及 UI。
· 针对特定的 API 端点进行测试,并观察随着负载逐渐增加,响应时间的变化。
· 通过提前执行压力或峰值测试来查找 API 端点的痛点。
除了自动化测试之外,还可以尝试配对测试,并在本地探索应用程序,以发现自动化测试无法发现的性能问题,例如检查应用程序的感知性能。
3、合并
当开发人员将代码推动到构建步骤并在某些情况下引入功能环境时,利用快速可靠的自动化测试来实现快速反馈循环非常重要。
从性能角度来看,作为 CI/CD 的一部分,可以运行前一阶段确定的组件性能测试。开发人员还可以这些测试到冒烟性能测试中,以验证应用程序在承受最小负载时的运行情况。
从后端性能的角度来看,这些测试应该以更少的虚拟用户或更短的持续时间运行。如果专注于前端或客户端性能,还可以使用专门针对客户端性能的工具,在几个页面上运行基本检查以获取数据。
4、构建
当功能合并到主分支时,可以进行更多接近用户体验的性能测试。测试或开发人员应该专注于端到端性能测试,而不只是组件级的性能测试,因为需要验证典型用户在使用过程中可能进行的主要流程。以下是一些从性能角度进行的端到端测试示例:
· 每次将代码部署到临时环境时,自动运行平均负载测试,以评估系统在典型负载下的性能。
· 运行端到端性能测试来模拟用户的完整使用流程,并在后端服务面临高负载时找到浏览器级别的瓶颈。在这个阶段,性能测试更加现实,并尝试模拟典型用户的行为。
· 可以选择手动触发压力、峰值或持续性能测试,将其集成到 CI 上。
· 如果将结果集成到可视化仪表板中,团队可以持续观察性能趋势,并使用数据通知是否可以安全地将代码部署到生产环境中。
5、发布和部署
当功能在生产中发布时,可以通过运行状况测试来验证部署是否成功。在某些公司中,可能没有适合进行性能测试的预生产环境,因此可以选择在生产环境中进行测试。
为了避免对用户造成的干扰,可以在商定的窗口期间(如非高峰时段)进行负载测试,这可以确保在测试期间不会对用户的正常使用产生负面影响。
6、运行和监控
一旦代码上线,用户会不断地对其进行测试。为了了解与性能相关的用户痛点,建立一个渠道来获取用户反馈,将其纳入下一个迭代中。同时,拥有监控解决方案也是持续测试的一种方法。这可以实时获得用户遇到的性能问题,例如页面响应时间过慢、在不同数据服务上出现的请求失败等。
三、写在最后
这并不是一成不变的,而是作为参考指南提供。持续测试并不意味着自动化的性能测试,而是在软件开发的整个生命周期中嵌入和不断改进性能,以便我们在各个阶段都能了解产品的性能。
通过持续测试,我们可以及时发现和解决性能问题,确保产品在不同阶段都能满足性能需求。这有助于提高用户体验、减少用户痛点,并为产品的稳定性和可靠性打下坚实基础。
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:【文末小卡片领取】
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!