写点什么

借助 AI 和 ML 技术减少缺陷滑移,将测试验证时间缩短一半

作者:Paul Derckx

  • 2023-09-22
    北京
  • 本文字数:3812 字

    阅读完需:约 13 分钟

大小:2.03M时长:11:47
借助AI和ML技术减少缺陷滑移,将测试验证时间缩短一半

可能很多人都会意识到,在软件开发项目中,验证时间经常会被拉长。为了按计划日期发布版本,发生在最后一刻的变更和缺陷修复需要验证团队具备一定的灵活性才能兑现交付承诺。于是我们不得不面对这些问题:我们能否提高灵活性?我们能否加大测试覆盖范围?我们能够提高效率?我们能否将验证时间缩短 50%?

 

在飞利浦磁共振(MR)业务系统集成与验证部门,我们正在实施我们的测试策略,预计会在两到三年内达成目标。在本文中,我将解释我们策略的两个重要“支柱”:左移和使用最先进的技术来支持我们的验证活动。

 

集成和验证所面临的挑战

 

我们面临的挑战与产品复杂性、测试中需要覆盖的配置数量的增加、并行程序执行以及分布在不同地点并与多个内部和外部供应商合作的工作模式有关。这些挑战直接影响了验证计划、工作时间分配和前导时间(lead time)。

 

影响验证执行前导时间的一个因素是缺陷滑移(slippage),特别是如果我们在项目的后期阶段才发现缺陷。这是一个我们可以改进的地方。在验证的最后阶段,我们不应该进行“测试”……验证应该是一项证明我们的产品符合需求规格的“文档性工作”。

 

验证总是发生在开发的最后阶段,这个阶段的“交付压力”很高。为了应对这种“压力”,我们必须在验证方式上变得更加智能和高效。我们的愿景是在减少验证前导时间的同时摆脱基于风险/影响的测试策略和在发布每一个版本时测试所有的东西!

 

为了实现这一愿景,我们的策略侧重于关注以下几点:

 

  • 向移——从缺陷检测变成缺陷预防,将测试重点从验证转向需求、开发和持续集成阶段。

  • 世界级团队——为不同的验证领域建立卓越中心,并在全球范围内管理能力/专业知识,包括在荷兰的贝斯特、印度的班加罗尔和浦那和中国的苏州建立集成和验证团队。

  • 测试覆盖——重构需求:将设计与需求分离,并将需求转到适当的组件/子系统/产品级别。在产品和子系统级别改进测试设计。通过操作剖面/工作流来提高测试覆盖率,即进行更接近实际客户使用场景的测试。

  • 测试自动化——使用最先进的技术来提高效率和测试自动化覆盖率。

  • 全球测试场部署——优化跨站点的测试配置,提升测试执行灵活性。

 

或许,推动测试和验证活动效率和有效性的最重要的因素是减少缺陷滑移。其次,它也是推动研发组织整体生产力的因素。我会详细说明这个问题。

 

你是否正在使用或考虑使用人工智能(AI)和机器学习(ML)来提高验证过程的效率和有效性?也许我们正在做的事情会激发你去探索类似的领域。

 

左移——从缺陷检测转向缺陷预防

 

我们在这方面的策略与缺陷滑移有关。对于每一个缺陷,我们都要问三个问题:

 

  • 缺陷是在哪个开发阶段发现的?

  • 缺陷应该在哪个阶段被发现?

  • 是什么导致了缺陷滑移?

 

在评估了缺陷滑移后,下一步就是查看数据。哪个开发阶段的滑移最多?这个可以通过滑移“热图”来显示:

 


你可以在帕累托图上深入了解其他细节,比如哪些子系统或功能区域显示出最高的缺陷滑移率。

 

期望一次性解决所有问题是不现实的。我们选择前 2 到 3 个出现最多缺陷滑移的阶段,然后与多学科团队一起深入研究,以了解其中的根本原因,包括需求缺失、需求分解中出现的差异或不一致、测试用例缺失、影响评估中出现的差异等。

 

了解根本原因让我们能够采取必要的行动做出改进,以防止在针对性的功能领域再次发生缺陷滑移。在最近的项目中,我们更加注重软件集成测试,因此验证首次通过率得到显著的提升。我们的验证时间表变得更加可预测。下一步是将重点转向开发和开发测试阶段。

 

在测试中应用机器学习和人工智能

 

如前所述,验证总是发生在项目的最后阶段,这一阶段的压力很大。我们的策略将有助于应对这种随“压力”而来的挑战,但我认为还有更多的可能性,例如,机器学习(ML)和人工智能(AI)可以帮助我们在测试方面变得更加智能吗?

 

我们目前正在探索一些领域,我认为 ML 和 AI 可以在这些领域发挥作用。

 

分析基础系统数据

 

我们可以访问已安装的基础系统的日志文件,用来提高我们产品的质量和可靠性。通过了解客户如何使用系统,我们可以设计出尽量接近产品真实使用情况的测试用例,从而提高测试覆盖范围——这些信息可以从日志文件中提取。

 

客户数据工作流的一个重要方面是扫描并生成不同的解剖图像。我们的客户根据自己的偏好创建扫描协议来优化对比度、分辨率、扫描速度等,导致的结果是不同的解剖结构使用了大量的扫描协议。因此,要为验证活动创建输入并在可接受的验证时间表内执行完它们是不现实的。

 

于是我们问自己:在整个已安装的基础系统中是否存在一些可以代表典型应用场景的扫描协议?通过数据挖掘和过滤技术,我们可以在几分钟内为超过 160 个解剖场景生成典型的扫描协议,这是无法通过人工手动实现的。我们得到了一组可管理的扫描协议,涵盖了不同的解剖结构,具有最佳的可实现的覆盖范围,并尽可能接近真实客户使用场景。下一步,我们正在尝试提取可以与这些扫描协议相结合的典型操作,如图像后处理、存档或打印数据等。

 

自动化变更影响分析

 

我们正在试验产品级别的代码覆盖率度量。如果能够在产品级别为已经自动化的测试进行代码覆盖率度量,我们就可以训练出检测测试用例与代码之间可追溯性的算法。然后,如果修改了代码,我们是否能够自动识别出相关的测试并作为 CI 管道的一部分来执行?事实上,我们正在使用人工智能来自动分析代码变更影响。

 

如果我们可以加入测试执行结果(通过/失败的测试)和缺陷的历史数据会怎么样?然后我们能够自动地包含适当级别的回归测试吗?我们目前正在探索这一想法——概念验证仍然需要做一些计划。

 

合成数据

 

测试 MR 功能需要图像数据。在这方面,我们主要使用体模(Phantom)。体膜是一种特殊构造的物体,用于磁共振扫描仪成像。体模包含了扫描时产生一致和可预测结果的模式和流体。使用体模会导致我们错过使用扫描患者真实图像数据进行测试时可能遇到的解剖结构变化。对于内部的验证活动,我们可以扫描志愿者,但可用性和图像数据仍然十分有限。所以,我们正在探索将合成数据作为测试输入。

 


“无限”的数据和数据的多样性将增加测试覆盖范围。用于自动化测试的合成数据有助于我们提高测试系统的利用率。而且,GDPR 不适用于合成数据。

 

缺陷分类

 

我们探索的另一个可能应用 AI 的领域是缺陷管理。假设我们可以根据标题、缺陷描述和属性自动将缺陷分配给相应的团队去诊断或解决,那会怎样呢?我们就可以知道一个缺陷是否与之前提交的缺陷重复了,或者根据之前拒绝的理由建议再次拒绝它。

 

目前,所有缺陷都由缺陷审查委员会(DRB)负责管理。DRB 由来自不同领域/职能的专家组成,他们花费大量的时间阅读和理解缺陷内容,并决定下一步的措施。如果可以不经 DRB 讨论评审,并同意由 AI 算法提出的提案来分配缺陷,那么时间将会显著减少。使用现有缺陷数据库的训练数据和测试数据的效果看起来不错,主要的问题在于缺陷的某些属性数据发生了变化,例如,组织/团队名称发生了变更。在训练算法之前,需要进行数据验证和填充。

 

提升效率的好处

 

我们最希望获得的好处是提高验证的可预测性和缩短验证的前导时间。如前所述,我们的目标是将验证前导时间缩短 50%。我们因此能够在设计和集成过程中越来越多地利用我们的专业知识,而不仅仅是执行验证测试。我们已经开始了这个旅程,但还没有达到终点。

 

提高可预测性的一个重要因素是减少缺陷滑移。如果每一个开发阶段滑移了一个缺陷,都会增加修复成本。在验证阶段发现缺陷需要进行重新验证,并带来额外的回归测试。假设每个缺陷平均需要 3 到 5 天的工作量用于怎段、修复和验证,那么你就可以轻松地计算出可以节省多少工作量。每个人都更愿意在可创造价值的事情上投入。

 

到目前为止,我们学到了什么

 

基于对缺陷滑移的管理和分析将焦点左移,这确保了我们的关注点是正确的。在接近产品实际用户使用场景的测试覆盖中,AI 和 ML 技术已经被证明非常有用。第一批结果显示,在影响分析和(合成)数据创建等领域的效率提升看起来很有希望。但我们也才刚刚开始,仍然需要在旅程中不断学习。

 

我们也想要改进其他东西,但也必须接受我们不能一次做完所有事情的现实。我们需要做出选择,快速获胜有助于快速取得成果,推动变革,并获得继续进行后续改进的预算。怀有愿景、选择战略,并制定路线图和优先事项是推动持续改进的一个途径。这将为我们继续履行运营承诺提供“喘息的空间”。

 

未来 ML 和 AI 将为测试领域带来些什么

 

随着人工智能算法越来越多地集成到我们的产品中,对于算法的训练和验证来说,有充足的高质量数据就变得至关重要。我预计其他行业也将如此,我坚信合成数据将成为一个重要的推动因素。因为我们处理的是病人的数据,所以 GDPR 使得使用真实图像数据变得越来越困难,从这个角度看,合成数据将会有所帮助。

 

我还相信,鉴于我们的案例,整个行业也将会采用人工智能/机器学习技术。例如,集成和验证历史数据为自动化影响评估并确定需要进行哪些测试提供了可能性。人工智能还支持自动计划适当级别的(回归)测试。分析和处理基础系统的数据,了解客户如何使用我们的产品,这对于提高测试覆盖范围来说至关重要。设计好客户如何使用我们产品的可检测性,以及能够连接到基础系统获取这些信息,都是至关重要的。

 

原文链接

https://www.infoq.com/articles/test-strategy-verification-effectiveness-efficiency/


相关阅读:

AI大模型背后的惊人数字:问ChatGPT 5个问题,耗水500毫升?训练一次GPT-3,碳排放量相当于开车往返月球?

企业级生成式AI应用,如何克服“幻觉”问题

2023-09-22 08:004666

评论

发布
暂无评论
发现更多内容

【超干货】阿里内部 Spring Boot 笔记,全硬核知识点

程序知音

Java spring 架构 springboot 后端技术

【C 语言】const 关键字

謓泽

11月月更

HEM亮相华为HDC2022开发者大会,助力企业数字化办公

最新动态

小白入门:什么是CURD?

wljslmz

数据库 sql crud 11月月更

设计千万级学生管理系统的考试试卷存储方案

小虎

架构训练营

Vue-VueRouter使用

格斗家不爱在外太空沉思

vue.js VueRouter 11月月更

漏洞扫描的种类

穿过生命散发芬芳

漏洞扫描 11月月更

Verilog语法入门

梦笔生花

Verilog 11月月更 组合逻辑电路

华为云从入门到实战 | AI云开发ModelArts入门与WAF应用与部署

TiAmo

华为 华为云 云开发 11月月更

披荆斩棘成功上岸美团、字节、华为,分享Java面经及答案

程序知音

Java java面试 后端技术 Java面试八股文

架构实战营模块四

Geek_408c99

云栖探馆!云小宝首秀遇上老司机小龙,猜猜谁赢了?

OpenAnolis小助手

龙蜥社区 2022云栖大会 小龙 云小宝 开源活动

从0制作一个web端网易云

格斗家不爱在外太空沉思

vue.js axios 11月月更

随机森林-分类森林

烧灯续昼2002

Python 机器学习 算法 随机森林 11月月更

为了面试字节,熬夜肝完这份Redis笔记后,我终于“硬”了一回

小小怪下士

Java redis 程序员 面试

架构误区系列(Architecture Pitfall)

agnostic

构架师

架构误区系列1:简单依靠扩容解决容量问题

agnostic

架构误区

Go语言入门14—Channel

良猿

Go golang 后端 11月月更

设计模式之美-面向对象

GalaxyCreater

设计模式

uniapp-如何在邀请页面生成海报

格斗家不爱在外太空沉思

vue.js uniapp 11月月更

【LeetCode】三角形最小路径和Java题解

Albert

算法 LeetCode 11月月更

SAP UI5 barcode 控件的 feature 检查探测机制单步调试 - checkCordovaInIframe

汪子熙

JavaScript Fiori SAP UI5 ui5 11月月更

【云原生】Nacos-TaskManager 任务管理的使用

石臻臻的杂货铺

云原生 nacos 11月月更

一次遍历导致的崩溃

小小怪下士

Java 程序员

全网首次公开!阿里巴巴分布式系统设计核心原理技术内幕

程序员小毕

程序员 架构 面试 分布式 程序人生

华为开发者大会HDC2022:HMS Core 持续创新,与开发者共创美好数智生活

HarmonyOS SDK

HMS Core

【愚公系列】2022年11月 微信小程序-app.json配置属性

愚公搬代码

11月月更

数据库系统的组成

阿泽🧸

数据库 11月月更

使用TSDB自动检测时序数据的异常情况

CnosDB

IoT 时序数据库 开源社区 CnosDB infra

极客时间架构训练营模块四作业

李晨

架构

架构实战营模块4作业

冷夫冲

架构实战营

借助AI和ML技术减少缺陷滑移,将测试验证时间缩短一半_AI 工程化_InfoQ精选文章