预防性测试Pro：一种可扩展的混合测试框架，结合可观测性与生成式人工智能实现主动式软件质量工程

摘要

PreventativeTestPro 是一种由人工智能驱动的测试框架，利用可观测性数据和大语言模型来自动化根本原因分析、测试用例生成和持续验证，旨在提高软件可靠性，并优化前后端系统的质量保证，从而实现更高效的工单管理支持。

摘要

本文介绍了一种复杂且可扩展的测试系统，该系统通过集成以可观测性驱动的自动化与人工智能增强的主动质量工程，以应对当前软件交付中的挑战。该系统通过引入一种基于可观测性的测试编排层，对开源混合测试平台 PreventativeTestPro 进行了增强。该平台结合了黑盒与白盒测试方法，利用日志、指标、事件和链路追踪，并结合浏览器端与服务器端监控，快速识别异常，优化测试用例选择，并自动生成功能、性能和安全测试套件。其显著特点是引入大语言模型（LLMs），以提供根本原因分析，并基于生产环境行为及已识别的异常自主构建新的测试用例，从而实现自适应的回归测试覆盖和智能化的修复响应。

该系统支持并发测试执行，并结合即时的AI驱动日志分析，促进运维与测试之间的持续反馈循环。已在多个企业场景中得到验证，包括基于微服务的SaaS平台和SAP BTP生态系统。来自四次生产环境部署及49名工程师组成的测试小组的实证结果表明，平均故障解决时间最多减少30%，SLA合规率超过95%，测试覆盖率和缺陷可追溯性均有显著提升。与行业标准工具的无缝集成体现了其即插即用的能力。

本研究提出了一种全面、独立于工具且具有前瞻性的质量工程方法，该方法与敏捷和DevOps原则保持一致。未来的研究方向包括通过机器学习实现动态异常分类，将方法扩展至移动设备及以用户体验为导向的系统，以及增强大语言模型的能力，以支持领域特定的测试开发和故障预测。

引言

敏捷范式在软件企业中的日益普及，引发了人们对持续集成环境的浓厚兴趣。此类系统的优势包括能够无缝整合常规的程序修改，从而加快软件演进速度并降低成本。因此，它能够高效地管理构建流程、测试执行以及测试结果报告等任务。软件测试自软件工程诞生之初便已实施，其目的在于评估软件质量¹。软件测试涵盖一系列旨在发现并解决软件在交付给最终用户前可能存在的各种错误的操作。软件测试是开发过程中成本较高的阶段²，其测试与调试成本占总开发成本的50%以上^3,4。回归测试的开销取决于应用程序的复杂程度以及测试套件的规模⁵。

敏捷方法导致生产环境中快速实施变更，进而由于反馈而引发大量支持问题。管理支持难题是一项极为重要且关键的职责，这一点从以下事实可见一斑：68%的消费者表示，他们愿意为以提供优质客户服务著称的企业的产品和服务支付溢价⁶。一项研究表明，获得卓越客户服务的客户中，有86%更有可能长期成为企业的忠实拥护者⁷。另一项研究表明，89%的买家如果拥有良好的客户服务体验，则更倾向于重复购买⁸。还有研究表明，93%的客户倾向于继续向提供优质客户服务的企业重复购买⁹。要提供卓越的客户服务，必须以高质量的标准及时有效地解决支持请求。当追求更快交付时，质量要素尤为关键，因为支持问题的解决成本会随着时间推移和升级层级的提高而增加¹⁰。

为了获得高质量，必须在确保对工单进行回归测试的全面测试覆盖的同时，定位并解决支持性问题。这一职责十分复杂，导致运营难度增加，尤其是在及时发现和解决支持性问题方面。支持性问题涵盖多种情况，如系统性能下降或意外故障，通常在软件系统的运行阶段出现。如果这些问题未能被迅速发现并纠正，可能导致长时间的停机、用户不满以及经济损失。目前利用可观测性信息进行测试需求的方法，往往受限于手动流程、被动而非主动的策略，以及异常检测与测试执行之间缺乏整合。当前明显缺乏通过实时可观测性数据主动识别支持性问题，并自动执行相应测试用例以提前预防潜在故障的能力。

缺乏全面且统一的解决方案，会导致软件维护和可靠性方面出现诸多不利后果。这些因素包括因问题发现延迟而导致的系统停机时间延长、在查找相关测试用例时增加大量人工工作量，以及对系统可靠性的信任度下降。此外，未能准确地将已识别的异常与测试用例相关联，会导致测试覆盖率不足，进而可能造成重要问题未被解决。

造成这种差异的根本原因可能在于现有监控和测试系统的碎片化结构。许多当前系统缺乏将可观测性数据分析与相关测试用例执行顺畅集成的能力。此外，依赖固定规则和人工流程来将异常与测试用例关联，阻碍了快速而准确地解决新问题的能力。

为了深入了解行业如何处理支持性问题以及开展预防性测试，我们通过对该领域的专业人员进行访谈，开展了一项描述性研究¹¹。根据访谈数据，实施任何解决方案过程中遇到的最大障碍是缺乏充足的时间以确保质量。在访谈过程中，还记录了若干关注点，包括人员技能提升、维护成本高、投资回报率低，以及工具的选择与集成¹¹。这些信息也在 Katalon 的"2024 年质量现状报告"¹²中得到了验证。在提出针对访谈中所提及问题的解决方案之前，我们对现有工具进行了比较评估，以确定是否存在能够解决上述问题的现成工具或算法^13,14。目前，我们尚缺乏专门针对访谈中讨论的困难而设计的必要工具或算法。

本研究提出了一种创新方法，利用可观测性数据在早期阶段（甚至在问题被报告之前）检测支持性问题并执行相应的测试用例，从而提高软件系统的可靠性与健壮性。该策略基于利用可观测性数据识别异常情况，建立与潜在问题的关联，并触发执行高度可能揭示问题根本原因的针对性测试用例。所建议的解决方案旨在弥合软件运维与测试之间的鸿沟，实现对支持性问题的主动且快速响应。当测试套件中缺少必要测试用例时，该方案还支持生成新的测试用例，从而提升测试覆盖率。所提出的方法还旨在解决Katalon访谈及报告中提出的关切问题^11,12,13,14。

在控制理论中，可观测性（observability）指的是根据系统的外部输出推断其内部状态的程度。在软件工程领域，可观测性的概念是指通过使用日志、指标、追踪和事件等输出来监控和理解软件系统状态的能力^15,16,17。我们的文献分析包括对可观测性及其在软件测试中应用的考察。然而，我们发现该主题的相关文献较为有限。因此，我们还纳入了关于创新性预防测试及相关研究的讨论。我们的文献综述进一步划分为三个不同类别。

Bogatinovski 等人¹⁸ 提出CLog，一种上下文感知的神经网络与聚类技术，旨在通过识别关键子过程并检测突发上下文转换期间的故障，以应对日志数据不稳定和故障覆盖不足的问题。Busby等¹⁹ 提出一种基于日志的方法，用于生成匿名化的测试用例，预测用户操作序列以实现无个人数据的复现；然而，并发性及日志记录级别差异仍是显著的限制因素。Lee and Kang²⁰ 建议实施一种面向软件产品线测试的测试架构，以在存在变异性机制的情况下提高可观测性和可控性。QEX 模型²¹ 结合不同测试来源的数据，在测试进行过程中提供清晰且有用的信息。Lal 和 Kumar²² 强调能够观察和控制智能测试的重要性。他们建议使用人工智能驱动的自动化，以使测试更快速、更高效且更全面。Briand 等人²³ 说明面向切面编程在 Java 中对契约和不变式进行有效插桩的应用，而 Baral 和 Offutt²⁴ 强调由错误的测试断言所导致的问题 "盲法测试，" 无法识别错误行为。

Rott²⁵ 指出现代 Teamscale 中的分析与可视化功能通过让测试人员访问与特定问题和情境相关的已处理工件，从而强化了软件测试过程。Collins 和 Lucena²⁶ 强调在部署到生产环境之前，在 CI 流水线中运行大量测试的重要性。他们认为，分层测试是确保产品质量并减少支持问题的有效方法。

BugSwarm²⁷ 提供了一种通过将根本原因与其相应解决方案相关联来分析持续集成（CI）测试失败的方法。Dudila 和 Letia²⁸ 研究了白盒测试与黑盒测试方法，提出了一种协调一致的策略，以减少开发过程中的调试工作量。Fushihara 等人²⁹ 调查了 Python 应用程序中的"测试坏味"，通过分析代码修改过程中这些坏味的演变情况，以改进测试代码的管理。SUPERNOVA³⁰ 是一个利用数据、自动化和机器学习来提升质量保证的测试选择与故障预防系统。Araujo³¹ 提出了一种专注于软件老化问题的维护策略：当代码可以修改时采用纠正性维护，而在修改可能导致系统停机时则采用预防性策略，从而降低服务故障的发生次数。Andrew 等人³² 研究了并行化的变异测试，该过程通过反复对类进行变异、测试和重新加载，直至评估完所有变体。Dunn 等人³³ 提出了安全漏洞度量方法，通过对组件分配权重以突出全面测试的重要性。最后，Huo 等人³⁴ 使用顺序集合索引来定位缺陷并确认问题，表明在软件应用中，根本原因通常与大多数失败的测试用例相关联。

方案

系统架构与原型概述：

本研究提出了一种改进且可适应的原型系统——PreventativeTestPro，该系统体现了利用可观测性数据和大语言模型（LLMs）来进一步提升支持问题解决能力的主动式质量工程方法。该系统旨在通过合成监控、可观测性数据与生成式人工智能（GenAI）的集成，实现异常检测、根本原因分析以及针对未覆盖场景的测试用例智能执行与开发的自动化，从而应对现代软件交付中的挑战。该架构具有模块化特点，包含三个核心组件：可观测性数据收集与分析器、由生成式人工智能驱动的智能层，以及测试编排与执行引擎，具体如图1所示。

图1：所提出系统的输入与输出。 可观测性数据、观察器输出、测试用例库以及映射规则作为输入，与BHRAMARI测试平台一同提供，用于构建AI驱动的测试环境，以增强测试用例的鲁棒性。该系统生成异常的检测机制、AI生成的建议、相关测试用例的执行、文档记录与报告，以及缺失测试用例的识别与创建。请点击此处查看此图的放大版本。

图2展示了所提出方法的架构。该图说明了系统的输入、处理和输出过程，同时全面描绘了系统整体结构，并进一步转化为详细解释，以增强对底层特征的理解。

图2：所提出系统的系统架构，包含可观测性数据收集器与分析器、由生成式AI驱动的智能层，以及测试编排与执行引擎。 本图展示了PreventativeTestPro系统的内部架构，分为三层：可观测性收集层从多个来源聚合数据，包括浏览器事件、日志、HAR文件、后端日志、指标和链路追踪数据。生成式AI智能层利用这些数据进行根因分析、对异常进行优先级排序，并通过大语言模型（LLMs）自主生成测试用例（UI、API、手动）和文档。BHARAMARI模块还负责建立新的测试环境。测试编排与执行引擎将差异映射到测试用例，同时执行测试，评估结果，并向工程团队、工单系统和仪表盘报告，以实现实时监控与问题解决进度跟踪。 请点击此处查看该图的放大版本。

可观测性数据采集与分析模块作为平台的感知系统，持续大规模、多维度地收集被评估应用的数据。在前端监控方面，部署合成监控代理以监测浏览器端事件，例如文档对象模型（DOM）结构、用户操作（如点击、悬停和输入）以及捕获网络和API请求与响应信息的HAR文件。OBSERVER还集成了PreventativeTestPro，以增强浏览器的功能。后端监控侧重于日志分析，获取并处理服务器端的可观测性信息，包括应用程序日志、错误、信息和调试消息、堆栈跟踪与异常日志、响应时间等性能指标，以及使用OpenTelemetry或New Relic等技术进行的链路追踪。系统将与模拟用户流量和交互的合成代理协同工作，日志采集器则对传入的实时数据进行压缩。所收集的数据随后被归一化为结构化格式，并传递给其他处理单元进行进一步分析。

PreventativeTestPro 的核心是一个由生成式人工智能驱动的智能层，该层利用大型语言模型（LLM）（如 GPT）读取和分析可观测性数据，并对数据进行上下文化处理，进而生成响应。该模块执行根本原因分析：通过解析根本原因日志和调用链追踪，以易于理解的方式解释技术故障，例如指出代码某一行出现空指针异常（NullPointerException），并推断问题的可能成因，例如某个变量未初始化。在测试用例生成方面，系统通过将异常模式或一系列事件转换为可执行的测试脚本（例如 Selenium 测试或 API 测试）来自动生成测试；同时也会生成人工可读的测试流程，供质量保证人员手动执行。API 测试通过将 HAR 文件和调用链日志转换为一系列带有预期断言的 API 请求而实现演化。所有生成的测试用例还通过与 BHRAMARI 集成，进一步配备高效的测试环境。推荐系统会根据所分析系统的运行行为，提出进一步的改进措施、测试覆盖率提升建议以及 CI/CD 集成机会。AI 引擎通过提示工程和上下文增强技术，利用结构化的可观测性数据，使用提示模板将结构化查询传递给大型语言模型，最终以功能形式生成输出，例如代码片段、测试用例规范以及自然语言形式的文档。

测试编排与执行引擎模块负责处理测试优先级、调度和执行，能够基于代码变更覆盖范围、标签以及异常映射实现自动化验证。测试的映射与选择过程涉及通过映射规则引擎将地图或仪器模式中的异常与已知测试用例相关联，然后根据既定的映射关系运行相应的测试用例。并发测试执行功能支持在不同环境中同时运行多种类型的测试，例如功能测试、性能测试或安全测试，并协调在自动化流水线中使用 Selenium、JMeter 和 ZAP 等工具。反馈回路机制确保执行结果被记录下来，一旦测试失败，相关变更将被传递至支持系统（如 Jira 和 Azure DevOps），以便跟踪并解决问题。

假设：

H1（运行效率）：假设将可观测性数据与人工智能驱动的智能相结合，将提升运行指标，特别是缩短平均解决时间（H1a）、平均分析时间（H1b）、生产问题平均检测时间（H1c）以及生产环境中修复措施的平均部署时间（H1d）。这些改进应有助于加快问题的检测、分析和部署速度，同时将系统停机时间降至最低，从而更易于满足服务等级协议（SLA）的要求（H1e）。

H2（测试有效性）：人们还普遍认为，提高测试覆盖率（H2a）、并行执行测试用例（H2b）以及智能测试优先级排序（H2c）将提升软件测试的有效性。AI 生成的建议（H2d）也有望在测试和运维工作流中提供支持。这将有助于更快地发现缺陷，加速反馈循环，并支持具有预防性且可持续的质量保证实践。

范围与受众：

本原型展示了整体系统设计、核心思想，以及如何逐步设置和运行 PreventativeTestPro 框架。同时详细说明了如何配置合适的测试环境/样本输入，并提供了故障排查建议。本内容面向已掌握 Java 基础知识、希望学习如何通过预防性测试提升软件可靠性与效率的软件质量工程师。

环境设置：

补充文件 1 包含与 PreventativeTestPro 进行通信所需的分步说明和程序。其中包括安装必要环境的说明、如何启动和停止工具的服务，以及对工具基本用法的清晰解释。如需获取更详细的文档，包括高级工具的使用说明、安装设置说明及其他组织性细节，请参考该项目专用的官方 GitHub 资源：https://github.com/sohambpatel/PreventativeTests/wiki 上的特定 Wiki 页面，以及 https://github.com/sohambpatel/PreventativeTests?tab=readme-ov-file/readme 上的主 README 文件。

示例输入：

示例输入文件可在 GitHub 仓库中找到：https://github.com/sohambpatel/PreventativeTests/tree/main/preventativetestframework/Inputs。该框架可立即运行这些文件中预设的测试用例和数据集。这些文件作为参考输入，用于检查环境配置，并获得本实验方案中描述的相同结果。

样本输出：

GitHub 代码仓库（https://github.com/sohambpatel/PreventativeTests/tree/main/preventativetestframework/SampleOutputs）包含预防性测试框架原始格式的输出数据具体示例。通过这些文件，用户可直接查看生成报告和指标的布局与详细信息，展示该工具在运行过程中所取得的结果。本指南有助于了解数据处理流程，并在重现实验过程时验证框架的预期行为。

执行原型：

本部分提供了使用 PreventativeTestPro 框架的详细逐步指南。为了帮助用户重现该工作流程，每个阶段均按顺序进行描述。本节以结构化格式呈现执行步骤，以便更轻松地重现结果、指出关键检查点，并确保 PreventativeTestPro 框架能够在不同的实验或操作环境中保持一致地使用。

在此步骤中，可使用 PreventativeTestPro 图形用户界面选择最佳的预防性测试工作流程。图3展示了五个选项，每个选项代表测试过程中的不同步骤：并行执行测试、通过优先处理现有测试用例从监控输出创建测试套件、创建手动测试用例、创建自动化测试用例以及查找根本原因。当用户做出选择后，指定的工作流程即开始运行。随后，在后续阶段可添加其他模式（例如由人工智能驱动的测试用例生成或根本原因分析）。这一结构清晰的界面提供了一种可重复且可分解为更小部分的预防性测试研究方法。

图3：系统的用户界面1。 本图展示了 PreventativeTestPro 的用户界面，用户可从中选择五种不同的预防性测试方式：1. 预防性测试，并行执行：启动测试；2. 预防性测试：基于合成应用监控最终确定测试套件；3. 预防性测试：使用生成式人工智能（GenAI）生成手动测试用例；4. 预防性测试：使用生成式人工智能（GenAI）生成自动化测试用例；5. 预防性测试：使用生成式人工智能（GenAI）进行根本原因分析。每次仅可选择其中一项。该模块化设计简化了预防性测试流程，并引入了由人工智能驱动的测试生成与诊断功能。请点击此处查看此图的高清版本。

图4展示了该框架的并行执行界面。在此步骤中，用户需输入待测试应用的URL以及包含配置参数的属性文件的绝对路径。设置输入后，用户可点击“开始测试”按钮同时启动测试，该操作还将监控被测网站，并生成安全日志、性能日志、控制台日志和JavaScript日志。用户可通过点击“停止测试”按钮终止正在进行的测试。点击“获取建议”按钮，可从记录的日志中获得由人工智能驱动的分析洞察。该设计确保了多种测试类别（功能、性能和安全）能够同时运行，从而更快速地发现潜在问题。

图4：系统的用户界面2。 本图展示了PreventativeTestPro框架的并行执行模式。用户需指定目标应用的URL以及包含配置信息的属性文件路径。可选操作包括“开始测试”（并行运行功能、安全性和性能测试并记录日志）、“停止测试”（终止执行）和“获取建议”（从日志和指标中获取AI驱动的分析结果）。 请点击此处查看此图的放大版本。

图5展示了PreventativeTestPro框架中基于监控的测试终止界面。在此步骤中，用户需设置监控输出文件的路径、用于获取错误或异常节点的JSON路径查询语句，以及用于保存所生成测试用例的测试仓库路径。在设置完输入信息后，用户可首先获取与之对应的类名和方法名，然后根据所找到的类和方法，对测试拉取中的测试用例进行排序。该优先级排序步骤展示了如何利用监控数据对测试用例进行有效排序。

图 5：系统的用户界面 3。 本图展示了如何在 PreventativeTestPro 框架中利用合成监控输出来优先排序测试套件。用户需输入监控输出文件的路径、用于获取异常/错误的 JSON 路径，以及测试仓库（离线）的路径。“获取类/方法名”和“获取测试用例”选项可用于将映射异常转换为可执行的测试用例，从而确保运行时问题被纳入测试流程。请点击此处查看此图的放大版本。

图6展示了PreventativeTestPro的手动测试用例生成界面。在此步骤中，用户需提供堆栈跟踪文件的绝对路径以及配置属性文件的路径，以告知程序从何处查找显示异常的堆栈跟踪文件。输入信息设置完成后，用户可运行“生成测试用例”选项，该功能将异常转换为结构化的手动测试用例。这确保了以往发生的运行时错误始终被纳入测试流程。该框架通过自动化测试用例生成过程，简化了测试用例的创建，减少了人工操作，提高了测试覆盖率和测试的可靠性，并防止相同问题再次发生。此步骤是问题发现与预防性保障质量之间至关重要的连接环节。

图6：系统的用户界面3。 本图展示了PreventativeTestPro的测试用例生成界面。该界面可将异常堆栈跟踪转换为可在行为驱动开发（BDD）中使用的手动测试用例。用户只需提供堆栈跟踪文件和属性文件的路径，然后点击“生成测试用例”按钮，系统便会自动生成与已发现故障相匹配的测试用例。这确保了运行时问题始终被转化为可重复执行的回归测试。请点击此处查看此图的放大版本。

图7展示了PreventativeTestPro的自动化测试用例生成界面。在此步骤中，用户需提供观测性JSON输出文件的绝对路径以及属性配置文件的路径。当点击“生成自动化测试用例”按钮后，系统将处理监控数据，并生成可用于复现先前所发现问题的测试用例。

图 7：系统的用户界面 4。 本图展示了 PreventativeTestPro 的自动化测试用例生成界面，该界面可生成利用可观测性数据运行的测试。用户需提供属性文件的路径和可观测性 JSON 输出文件的路径，然后点击“生成自动化测试用例”按钮，即可生成可在 Selenium 和 TestNG 格式下运行的测试脚本。 请点击此处查看此图的放大版本。

图8：系统的用户界面5。 本图展示了用于根本原因分析（RCA）的PreventativeTestPro异常检测界面。用户需提供属性文件和堆栈跟踪文件的路径，然后选择RCA以启动由人工智能驱动的分析。此步骤将检测到的异常转化为结构化的诊断洞察，确保故障能够以可重复且针对具体问题的方式被修复。请点击此处查看此图的放大版本。

故障排除：

表1列出了仅与应用程序代码相关的最重要故障排除要点。这些要点可帮助快速记忆在运行PreventativeTestPro框架时如何解决代码层面的问题。项目文档为希望进一步排查影响应用程序整体功能问题的读者提供了更详细的信息和分步说明。完整资源可通过以下链接获取： https://github.com/sohambpatel/PreventativeTests/wiki/How-to-use%3F。这一补充参考资料不仅帮助用户修复编码问题，还能学习如何排查功能故障，从而更有效地使用该框架。

错误行为	根本原因	如何修复？
应用程序无法启动	未设置 Java 路径	在环境变量中设置 JAVA_HOME
服务器启动失败	端口 8080/9090 已被占用（特别是在使用 Docker 时）	更新 Docker 的端口映射
GenAI 内容为空	令牌可能已过期	重新生成令牌，并在将其作为输入提供之前，更新 config.properties 文件中的配置
框架生成的浏览器实例无法连接网络	ZAP 服务器未运行，或 ZAP 凭据不正确	在运行应用程序前开启 ZAP；如果 ZAP 已运行但问题仍然存在，请在将其作为输入提供之前，更新 config.properties 文件中的 ZAP 凭据

表1：常见的系统错误及快速解决方案。 本表列出了常见的特定应用程序错误、故障排除方法以及可用于解决问题的快速修复措施。

结果

最初，我们实时分享了与多个行业合作开展的案例研究所得结果。此外，我们还提供了使用该框架和算法的测试人员所获得的结果，以及关于结果有效性潜在风险的最终观察结论。

行业案例研究结果：

根据我们的研究，该研究侧重于实际应用并解决支持性问题，我们已与四家软件公司合作，共享该框架并获取实时结果。产业界的参与及成果证明了其在现实应用中的实用性与优势。

案例研究 1：

GazonTech 是一家专注于网络技术、流媒体平台、在线游戏、视频会议和智能家居自动化的软件企业。我们开发的解决方案已专门应用于其流媒体平台，并已在特定模块中部署，能够捕获并分析该模块的运行结果。每家公司都有各自的一套流程来管理支持性问题并交付修复方案。该公司还采用多种发布模式将变更推送至生产环境，包括“每日发布”（daily doses），即在每日的生产窗口期内快速修复支持性问题；“每周发布”（...

讨论

本研究介绍了PreventativeTestPro，这是一个综合性的测试与可观测性平台，通过整合合成监控、可观测性数据以及由生成式人工智能驱动的自动化技术，提升软件质量保证水平。该系统包含三个核心模块：可观测性数据采集与分析模块、由生成式人工智能驱动的智能层，以及测试编排与执行引擎。这些组件共同构建了一个反馈闭环，其中实时系统行为指导测试用例的生成、故障检测以及持续的测试验证。该方法通过将智能化、上下文敏感的测试生成技术直接嵌入软件开发流程，融合了传统的黑盒测试与白盒测试技术。

本研究的科学贡献在于创新性地应用大语言模型（LLMs）分析复杂的可观测性数据，以获得可操作的洞察，包括根本原因分析（RCA）、测试用例生成以及系统行为优化建议。PreventativeTestPro 通过将日志、链路追踪、HAR 文件和 DOM 事件作为 AI 流程的结构化输入，实现了从原始遥测数据到诊断与纠正输出的自动化转换。这拓展了人工智能增强型软件工程的前沿，并为基于实时系统指标的持续验证和测试驱动开发创造了新的机遇。表6³⁵

材料

本文使用的材料清单

姓名	公司	目录编号	评论
Apache Maven	Apache 软件基金会	3.9.6	用于 Java 项目的依赖和项目管理工具
ChatGPT (GPT-3.5 Turbo API)	OpenAI	https://platform.openai.com/api-keys	用于从日志中生成基于 AI 的测试建议、生成手动测试用例、生成自动化测试用例以及获取根本原因分析
计算机（开发/测试机器）	标准台式机/笔记本电脑	-	用于开发、执行和测试 PreventativeTestPro
磁盘空间	-	-	建议至少保留 10 GB 的可用磁盘空间，用于存储日志、报告和测试产物
Docker	Docker 公司	27 (https://docs.docker.com/desktop/setup/install/windows-install/)	用于容器化，以确保在不同环境中具有可重复性
Git	Git SCM	git version 2.45.2.windows.1	用于开发与协作的版本控制系统
GitHub 仓库	GitHub	https://github.com/sohambpatel/PreventativeTests	包含源代码、文档、数据集和示例的公开仓库
Google Chrome	Google	140.0.7339.128	用于合成监控和测试的主要浏览器
Java	Oracle / OpenJDK	21.0.2	用于 PreventativeTestPro 的软件开发与执行
操作系统	平台无关	-	该工具可在任何安装了 Java 和 Maven 的操作系统上运行（Windows、Linux、macOS）
OWASP ZAP	OWASP 基金会	2.14.0	安全扫描与漏洞检测工具
处理器	-	-	建议使用 Intel i5 或更高版本（或同等性能处理器），以支持并行执行和 AI 处理
内存	-	-	建议至少配备 8 GB 内存，以支持测试运行和基于浏览器的监控