本子

目前搜索:

目前的软件测试,尤其是jy软件,它存在哪些具体问题,它目前的解决方式是什么,目前的软件测试的流程\应用是什么
什么是基于大模型的缺陷代码冗余噪声处理技术?
什么是软件测试需求分析

项目目的:

针对jy软件测试效率啊低\周期长\影响交付时间的问题,开展基于大模型实现软件测试需求分析和测试设计，基于大模型的缺陷代码中与噪声处理等技术研究，突破面向测试领域的指令微调，基于可回溯注意力的测试用例设计等技术关键技术，形成基于思维链增强的模型训练方法体系，构建军用软件测试专用大模型，实现测试效率测试质量的统一治理。
测试需求分析和测试用例设计
*具备测试大纲测试用例生成能力、软件需求文档审查能力、软件架构设计评测能力和军用基础软件安全漏洞测试分析能力，测试大纲测试用例生成效率提升50%，有效性生成测试大纲，有效性50%，测试大纲测试用率也就10%准确的。可构建主流军用软件编程语言CC11Java的软件架构设计评价指标，分析软件单元语句与功能需求和关系理论准确率70%与识别异常处理语句与功能需求的关系准确率70%，那么文档审查准确率80%，具备军用基础软件代码漏洞分析能力，误报率低于10%，漏报率小于等于10%，检测准确率提升15%。
什么是软件测试需求分析
- 软件测试需求分析解决“测什么”的问题，一般来自需求规格说明书中原始需求,根据需求规格说明书（原型图 SRS）去明确测试的内容，去细分需求，也就是提取测试点（软件包含多个测试的功能点，每个功能点又包含多个子功能测试点，测试点就是软件功能细分的最小单位）
目前软件测试方法的问题
- 文章1 测试用例不全面测试环境不稳定测试结果不准确测试人员技能不足测试时间不足
- 文章2测试覆盖率的不足, 测试用例设计不合理, 测试数据的不足
- 文章3缺乏自动化测试,缺乏有效的沟通机制,测试用例设计不充分
- 文章4 软件测试中常见的难题需求定义,时间限制,资源限制,技能水平,与开发团队的沟通,自动化测试难题,版本控制和跟踪,环境和配置管理,情景测试,报告和文档
目前软件测试方法问题:
- 典型流程：军用软件测试通常包含以下步骤：
- 需求分析：对软件的功能和安全需求进行详细分析。
- 测试计划制定：根据需求和系统架构设计测试计划，包括测试范围、测试策略和资源分配等。
- 测试用例设计：根据测试计划设计详细的测试用例，涵盖正常情况、边界情况及异常场景。
- 测试执行：在实际系统或仿真环境中执行测试用例，并记录测试结果。
- 缺陷分析与修复：对测试中发现的缺陷进行分析，并交由开发团队进行修复，修复后重新执行回归测试。
- 安全性与漏洞测试：特别针对军用软件的安全性需求，进行漏洞扫描、安全性验证等。
- 测试报告与审查：生成测试报告，并对测试结果进行审查，确保满足所有测试要求。
- 综上，当前的军用软件测试流程仍有较多手动操作，自动化和智能化水平不高，测试覆盖率和效率都有提升空间。引入大模型、机器学习等新兴技术能够大幅优化测试过程中的各个环节。
- 点击查看代码
  
  当前软件测试方法、工具和策略，尤其是在军用软件领域，面临着一些具体的问题和挑战，包括以下几个方面：
  1. 测试效率低、测试周期长
    军用软件由于其高安全性和复杂性要求，测试过程繁琐，测试周期通常较长。传统的手工测试和自动化测试工具，在处理复杂系统时效率有限，难以满足快速交付的需求。
  解决方式：
  
  自动化测试：引入更多的自动化测试工具，如单元测试、集成测试和回归测试工具，减少手动测试的时间。
  并行测试：通过分布式测试框架，在多台设备上并行执行测试任务，缩短整体测试时间。
  CI/CD集成：通过将测试流程融入持续集成和持续交付（CI/CD）管道，测试可以与开发同步进行，减少后期发现问题的成本。
  2. 测试用例设计复杂，覆盖率不足
  由于军用软件的复杂性，生成有效的测试用例是一项挑战。测试用例的设计需要覆盖各种边界情况和异常场景，但人工设计的用例往往无法覆盖所有关键路径，导致测试覆盖率不足。
  
  解决方式：
  
  基于模型的测试：利用软件架构或需求文档，生成符合业务逻辑的测试用例。通过模型的建立自动生成测试用例，提升测试覆盖率。
  随机测试生成：使用随机测试生成器来创建多种不同的输入，覆盖更多的异常场景和边界情况。
  3. 缺陷定位与噪声处理难度大
  军用软件中的代码往往存在大量的冗余或噪声代码，导致在进行缺陷定位时，可能需要花费大量时间去筛选有用信息。而且复杂的代码结构使得故障根因分析变得更加困难。
  
  解决方式：
  
  静态代码分析工具：通过静态代码分析工具（如SonarQube、Coverity等），自动检测潜在的代码缺陷，减少噪声干扰。
  基于机器学习的缺陷预测：利用机器学习技术，根据历史数据预测可能的缺陷位置，从而更高效地进行缺陷定位。
  4. 需求文档与测试的不一致性
  软件需求文档与实际测试设计之间的差异，可能导致测试中遗漏一些关键功能或异常场景的覆盖。这在军用软件中尤为严重，因为其需求的复杂性和安全性要求高。
  
  解决方式：
  
  需求追踪工具：使用需求管理工具（如Jira、DOORS等），将需求与测试用例进行追踪和映射，确保每个功能需求都有相应的测试用例。
  自然语言处理（NLP）技术：使用NLP技术分析需求文档，自动生成测试需求分析报告，并与测试用例进行匹配，减少人工审查需求文档带来的错误。
  5. 安全漏洞测试的不足
  军用软件对安全性要求极高，传统的安全漏洞检测方法，如静态分析和动态分析，无法充分检测出所有的潜在安全漏洞。同时，误报率高和漏报率严重影响了漏洞检测的效率。
  
  解决方式：
  
  模糊测试（Fuzzing）：利用模糊测试技术，生成大量异常或随机输入，测试软件在边缘情况和错误输入下的响应，发现潜在漏洞。
  动态污点分析：结合动态污点分析技术跟踪程序执行路径，找到潜在的安全漏洞，提高检测的准确性。
  大模型与AI技术：通过引入AI和大模型进行代码安全性分析，能够自动检测代码中的潜在漏洞，降低误报率，提升检测准确性。
  *
  点击查看代码
  
  目前的软件测试方法使用了多种技术、工具和策略，具体可分为以下几类，并且它们各自存在一些问题：
  1. 手动测试
    使用方式：测试人员手动执行测试用例，验证系统是否符合需求。这种方法通常用于功能测试、UI测试和探索性测试。
    问题：
  效率低：手动测试耗时长，尤其是面对大规模复杂系统时。
  不易重复：手动测试难以保持一致性，测试结果可能因测试人员不同而有所差异。
  覆盖率不足：手动测试受限于人力资源和时间，无法覆盖所有可能的场景和输入。
  1. 自动化测试
    使用方式：通过脚本编写自动化测试用例，执行回归测试、性能测试、单元测试等。例如使用Selenium、JUnit、TestNG等工具。
    问题：
  初始成本高：编写和维护自动化测试脚本需要投入大量资源，尤其是当系统复杂且频繁变化时。
  适应性差：自动化测试的脚本容易因UI或功能的微小变化而失效，导致频繁更新维护。
  无法覆盖复杂场景：自动化测试适用于重复性高、流程固定的场景，难以应对探索性测试和复杂业务逻辑。
  1. 静态代码分析
    使用方式：通过工具对代码进行静态分析，检测代码中的潜在错误、漏洞和不规范问题，典型工具如SonarQube、Coverity等。
    问题：
  误报率高：静态分析工具可能产生大量误报，增加了开发人员的工作负担，降低了分析效率。
  难以检测动态问题：静态分析无法发现运行时的逻辑错误或内存泄漏等问题，需要结合动态测试工具才能实现全面检测。
  1. 动态测试
    使用方式：在运行时对软件进行测试，验证程序的实际行为是否符合预期。这类测试包括单元测试、集成测试、系统测试等。
    问题：
  覆盖不全面：测试用例设计不当可能导致重要的逻辑路径或边界条件未被测试。
  维护难度大：随着系统功能的扩展和变化，动态测试的脚本和环境需要频繁更新，增加了维护的难度。
  1. 基于模型的测试
    使用方式：通过创建软件系统的模型，基于该模型自动生成测试用例，用于功能验证和异常处理测试。
    问题：
  模型构建复杂：构建准确的模型需要深入理解系统的业务逻辑和结构，且模型更新较为复杂。
  适用范围有限：这种方法适用于特定类型的系统，尤其是那些规则明确、可建模的系统，而对于动态、灵活的应用系统效果有限。
  1. 模糊测试（Fuzz Testing）
    使用方式：通过随机生成大量异常输入，测试系统对异常情况的处理能力，用于安全漏洞检测。
    问题：
  难以定位问题：模糊测试生成的异常输入可能触发问题，但难以精准定位问题的根本原因。
  覆盖不够深入：随机生成的输入虽然能覆盖大量边缘情况，但对一些特定的、业务逻辑相关的异常场景可能无法有效捕捉。
  1. 性能测试
    使用方式：通过模拟高负载环境，测试系统在压力下的响应和稳定性。常用工具包括JMeter、LoadRunner等。
    问题：
  环境搭建复杂：性能测试需要搭建接近真实环境的测试环境，且成本较高。
  测试结果不稳定：性能测试的结果受环境、网络和硬件等因素影响，可能出现不一致的测试结果。
  存在的主要问题总结：
  测试覆盖率不足：无论是手动测试还是自动化测试，通常都难以覆盖所有场景，尤其是边界条件和异常场景。
  
  测试效率低：手动测试耗时长，而自动化测试虽然能提升效率，但脚本的编写和维护成本较高。随着系统功能的不断变化，维护自动化测试的成本变得非常高。
  
  误报与漏报问题：静态分析和模糊测试等方法经常产生误报或漏报，增加了开发团队的负担，降低了测试结果的有效性。
  
  缺乏智能化和自动化的需求分析：需求与测试用例之间的联系较弱，测试设计往往依赖于人工分析，无法准确高效地从需求文档生成有效的测试用例。
  
  缺陷定位困难：缺陷的定位和修复仍然是一个复杂且耗时的过程，特别是在涉及大量噪声或冗余代码的系统中，找到根本原因可能需要大量时间。
  
  通过引入基于大模型的智能测试技术，可以缓解以上问题。例如，利用自然语言处理（NLP）分析需求文档，自动生成测试用例；利用大模型进行缺陷预测和自动修复，将有助于提升测试的效率和质量。
  - https://blog.csdn.net/xx_nm98/article/details/141036054
基于大模型的缺陷代码冗余噪声处理技术
- 名词解释
  - 大模型
  - 缺陷代码:缺陷代码是指软件中存在的错误代码，可能导致系统出现问题、功能失常、崩溃或出现安全漏洞。通常，缺陷代码隐藏在复杂的代码结构中，难以通过传统工具高效检测。
  - 冗余噪声代码：冗余噪声代码泛指在程序中不必要的、对系统功能没有贡献的代码片段，例如重复代码、过时的变量、无效的逻辑分支等。这些冗余代码会增加代码的复杂性，影响代码的可读性和维护性，甚至可能引入缺陷。这类噪声在缺陷定位和修复过程中会干扰分析，增加工作量。
  - 综合:通过大模型来自动识别、分析并处理这些冗余噪声代码，以优化代码质量和提高缺陷定位效率。
- 目前使用大模型进行代码缺陷\质量审查的产品:DeepCode CodeGuru SonarQube（无模型，代码规则）
  - DeepCode AI的混合方法使用多个模型和特定于安全的训练集来实现一个目的-保护应用程序。
- 缺陷代码检测
  - 大模型在代码缺陷检测领域的应用实践
  - 对应论文 Leveraging Deep Learning Models for Cross-function Null Pointer Risks Detection
  - 静态代码扫描(SA)指在软件工程中，程序员写好源代码后，在不运行计算机程序的条件下，对程序进行分析检查。在单元测试之前.
  - 当前扫描能力主要依赖人工经验生成规则，泛化能力弱且迭代滞后，导致漏出。该方法使用知识图谱+大模型，利用知识图谱提取片段（大模型输入的token有限），根据不同场景指定不同的上下文原码获取能力（代码切片）
  - 论文：基于深度学习的源代码缺陷检测研究综述软件雪豹
目前的一些LLM在代码方面的模型
- CodeT5+（2023）代码生成与代码理解方面的大模型
Software Testing With Large Language Models:Survey, Landscape, and Vision 综述论文
- 传统方法问题：自动化单元测试用例生成。尽管存在各种方法，包括基于搜索、基于约束或基于随机的技术来生成一套单元测试，但生成的测试的覆盖率和有意义性仍远远不能令人满意。移动GUI测试方面，现有的研究采用随机/基于规则的方法、基于模型的方法和基于学习的方法，无法理解GUI页面的语义信息，往往无法实现全面的覆盖。
- LLMs通常用于测试用例准备（包括单元测试用例生成、测试oracle生成和系统测试输入生成）、程序调试和bug修复，而我们没有发现将LLMs应用于早期测试生命周期任务（如测试需求、测试计划等）的实践。约三分之一的研究通过预训练或微调方案使用LLMs，而其他研究则采用提示工程与LLMs通信以引导其行为实现期望的结果。
- 软件测试流程：测试需求分析-测试计划-测试设计-测试用例准备-测试执行-测试报告-bug修复与回归测试-发布
  - 测试用例生成
    - 测试前缀通常是一系列方法调用语句或赋值语句，旨在将焦点方法驱动到可测试状态；然后测试断言作为规范，用于检查焦点方法的当前行为是否满足预期，例如测试断言。
    - 传统的单元测试生成技术利用基于搜索、基于约束或基于随机的策略来生成一套单元测试，主要目标是最大化被测软件的覆盖率。然而，生成的测试的覆盖率和有意义性仍远远不能令人满意。由于LLMs在代码生成等任务中展示出了promising的结果，并且考虑到代码生成和单元测试用例生成都涉及生成源代码，最近的研究已将代码生成的领域扩展到包括单元测试用例生成。尽管取得了初步成功，但单元测试用例生成与一般代码生成之间存在细微差别，这表明需要更有针对性的方法。
    - 方法：预训练或微调LLMs用于单元测试用例生成，为单元测试用例生成设计有效的提示，基于附加文档的测试生成， LLM和基于搜索的方法生成单元测试，

虽然LLMs，特别是Davinci，获得了良好的召回率，但LLMs的假阳性率远远高于开源代码扫描工具（Flawmart [10] ，RATS [11] ）以及商业静态分析工具Checkmarx [12] 。Flawfinder、RATS、Checkmarx和VulDeePecker的性能数据基于Li等人发表的论文 [18] 。虽然定制的深度学习神经网络模型VulDeePecker表现最好，但目前尚不清楚它将如何在不同类型的代码上执行（例如，看起来不像代码小工具的代码）。相比之下，LLMs是通用模型。

静态分析是我们分析的自然参考点，因为我们使用LLMs来分析源代码。静态分析使用定义良好的规则，可以精确定位漏洞的确切位置。两种类型的常用规则是数据流分析（即，污点传播）和模式匹配。很难想象LLMs“理解”数据流的概念，我们将使用示例来说明情况确实如此。与静态分析工具不同，在静态分析工具中，必须手动指定易受攻击的代码模式，LLMs似乎非常擅长学习通常与漏洞相关的代码模式。这就解释LLMs印象深刻的召回性能。他们非常擅长学习和检测这些模式，并对样本进行微调。回想一下，从 Table II 开始，微调的Davinci模型达到了94%的真阳性率，类似于定制的神经网络系统。然而，由于我们的非易受攻击的测试用例是针对漏洞的修补代码，因此与易受攻击的代码片段相比，它们通常包含相对较小的代码更改，因此可能不会显着改变代码的整体模式，从而导致LLM产生高误报。LLMs换句话说，LLM可以在多行代码中识别易受攻击的代码模式，而不知道实际导致漏洞的原因。

这一分析提出了一个可能的未来研究方向，人们可能会将LLM轻松学习易受攻击的代码模式的能力与另一种更严格的程序分析技术相结合，以实现更好的漏洞检测性能。我们提出了几个案例研究，从我们的结果来支持这一分析。在 Figures 2 - 5 中，每个图中的第一个代码片段直接取自测试数据。

三个漏洞检测数据集（即，Devign、Reveal和Big-Vul）

Deep Learning Based Vulnerability Detection: Are We There Yet?
首先，我们从两个大规模流行的现实世界项目（Chromium和Debian）中策划了一个新的漏洞数据集，以评估现有技术在现实世界漏洞预测环境中的性能。代码示例被注释为脆弱/中立，利用其问题跟踪系统。由于代码和注释都来自现实世界，因此使用这样的数据集检测漏洞反映了现实的漏洞预测场景。我们还使用了Zhou等人提出的FFMPeg+Qemu数据集。令我们惊讶的是，我们发现现有的模型在现实世界中表现不佳。如果我们直接使用预先训练的模型来检测真实世界的漏洞，平均而言，性能下降了 ∼ 73%。即使我们用真实世界的数据重新训练这些模型，它们的性能也会比报告的结果下降 ∼ 54%。例如，VulDeePecker [3] 在他们的论文中报告了86.9%的精度。然而，当我们在真实的世界数据集上使用VulDeePecker的预训练模型时，其精度降低到11.12%，经过重新训练后，精度变为17.68%。经过彻底调查，发现存在以下问题：

模型不充分。最流行的模型将代码视为令牌序列，而不考虑在漏洞预测中起重要作用的语义依赖关系。此外，当使用基于图的模型时，它并不专注于增加脆弱类别和中性类别之间的类别分离。因此，在现实场景中，它们的准确率和召回率都很低。
学习不相关的特征。使用最先进的解释技术 [9] ，我们发现当前的模型本质上是在学习与漏洞无关的不相关特征，这些特征可能是数据集的伪影。
数据重复。大多数现有方法中的训练和测试数据包含重复（高达68%）;因此，人为地夸大了报告的结果。
数据不平衡。现有的方法并不能缓解现实世界中脆弱性分布的类不平衡问题 [10] ，其中中性代码比脆弱代码更频繁。
展示了如何更有原则的方法来收集数据和模型设计，根据我们的实证研究结果，可以导致更好的解决方案。对于数据收集，我们讨论了如何管理包含静态和演化（即，bug-fix）的性质。对于模型构建，我们展示了表示学习 [11] 可以在传统DL方法之上使用，以增加脆弱样本和中性样本之间的类分离。

我们进一步经验性地确定，使用语义信息（基于图的模型），重复数据删除和平衡训练数据可以显着提高漏洞预测。按照这些步骤，我们可以将文献中表现最好的模型的准确率和召回率分别提高33.57%和128.38%。
为了解决现有数据集的局限性（突出问题1和2），我们策划了一个更强大和全面的真实的世界数据集，ReVeal，通过跟踪两个开源项目的过去的漏洞：Linux Debian Kernel和Chromium（Chrome的开源项目）。我们选择这些项目是因为：（i）这是两个流行且维护良好的公共项目，具有很大的发展历史，（ii）这两个项目代表了两个重要的程序域（操作系统和浏览器），表现出不同的安全问题，（iii）这两个项目都有大量的公开可用的漏洞报告。
为了管理我们的数据，我们首先收集已经修复的问题，并提供公开的补丁。对于Chromium，我们抓取了它的bug存储库Bugzilla。 3 对于Linux Debian内核，我们从Debian安全跟踪器收集了问题。 4 然后我们识别与漏洞相关的问题，即，我们选择那些标有“安全”的补丁。该识别机制受到现有文献 [30] 中提出的安全问题识别技术的启发。Zhou等人 [31] 提出的方法过滤掉了没有安全相关关键字的提交。
对于每个补丁，我们提取了相应的脆弱和修复版本（即，旧版本和新版本）的C/C++源文件和头文件，这些文件在修补程序中进行了更改。我们注释所有更改的函数的先前版本（即，补丁之前的版本）为“易受攻击的”并且所有改变的功能的固定版本（即，补丁后的版本）为“干净”。此外，补丁中未涉及的其他功能（即，那些保持不变的）都被注释为“干净”。以这种方式注释代码模拟了真实世界的漏洞预测场景，其中DL模型将学习在其范围内的所有其他函数的上下文中检查易受攻击的函数。此外，保留脆弱函数的固定变量有助于DL模型学习可修复补丁的性质。

在实际数据中，中性样本的数量（即，负面示例）的数量远远超过易受攻击的示例（即，正例），如 Table 1 所示。如果不加以解决，这会在模型中引入不希望的偏差，限制其预测性能。此外，所提取的脆弱和中性示例的特征向量在特征空间中表现出显著的重叠。这使得区分易受攻击的示例和中立的示例变得困难。在不考虑重叠的情况下训练DL模型会使其容易受到预测性能差的影响。
为了缓解上述问题，我们提出了一个两步的方法。首先，我们使用重采样来平衡训练数据中脆弱和中立样本的比例。接下来，我们在重新平衡的数据上训练一个表示学习模型，以学习一个能够最佳区分脆弱和中性示例的表示。

为了处理脆弱类和中立类数量的不平衡，我们使用了“合成少数过采样技术”（简称SMOTE） [36] 。它通过改变数据中不同类的频率来运行。具体地，SMOTE对多数类（即，随机删除一些示例），同时对少数类进行超采样（通过创建合成示例），直到所有类具有相同的频率。在脆弱性预测的情况下，少数类通常是脆弱的例子。SMOTE已被证明在具有不平衡数据集 [37] 、 [38] 的多个域中是有效的。在超采样过程中，SMOTE会挑选一个易受攻击的样本，并找到 k 个最近的易受攻击的邻居。然后，它通过在自己和它的一个随机最近邻居之间进行插值来构建少数类的合成成员。在欠采样期间，SMOTE会随机从训练集中删除中性样本。重复这个过程，直到脆弱示例和中立示例之间达到平衡。请注意，虽然我们使用现成的SMOTE来重新平衡训练数据，但其他数据重新平衡技术（例如，MWMOTE [39] ，ProWSyn [40] ）。尽管如此，SMOTE作为ReVeal管道中的再平衡模块是可配置的，可以很容易地被其他再平衡技术取代。不同的再平衡技术之间的比较超出了本研究的范围。

GRACE: Empowering LLM-based software vulnerability detection with graph structure and in-context learning
Evaluation of ChatGPT Model for Vulnerability Detection

会议笔记：

哈深：1.2与1.3合并是训练部分微调部分，2-5为调优部分，第一部分不要放思维链增强
张：第一部分表示数据从哪来怎么处理数据集几类为重点，采集预处理微调技术比较普遍，偏重于数据一些
费：把指令微调放进关键技术里。研究内容稍微扩一下，
第二版大纲
王勇：不建议再动，推荐高老师思路。第一部分就是采集预处理。标题不变化。第一大模型构建思维链增强的模型训练方法要贯穿始终。需求里面有一个调优的过程。

把4架构需求拿掉放到第三个里。4.2放到3.4。
代码漏洞没提。
对于开源项目的已知漏洞的检测。未知漏洞不知道

张：基础软件做过操作系统麒麟数据库金仓达蒙
调优技术。高：在1.3有一个方法体系、框架，讲一讲通用技术而不是领域知识，后面讲对应场景内怎么用。提示学习上下文学习检索增强思维链 1.2里写到训练部分，构建一个大模型作为基础。基于私有数据做模型的微调。调优和后面的有重叠

定分工：
1 哈工大
2 测试需求南航
3 李诗怡
4 关键科技
5 哈工程-716
国内外现状写每个单位对应的
指标验证方法条件写各自的
现有研究基础先提供一下
针对每个研究内容有一个大图，基于大图写子章节。没有业务流程全是技术路线

明天晚上8点讨论一下看看困难，之前就得出一版6号中午交本子定位：工大工程大模型，716测试

5.软件测试大模型原型系统研制与应用验证
5.1软件测试专用大模型原型系统研制
架构、功能：测试需求分析审查、测试用例生成工具、软件架构设计评审工具、漏洞识别工
具等
5.1.1 系统架构设计
测试需求分析审查模块、测试用例生成工具模块、软件架构设计评审模块、漏洞识别工具模块。
整体架构画一个图
5.1.2 核心功能设计
测试需求分析审查：大模型如何识别和审查需求文档中的潜在问题。
测试用例生成工具：基于大模型的自动化测试用例生成方法。
软件架构设计评审：基于大模型分析架构设计的合理性和潜在风险。
漏洞识别工具：大模型如何在代码中自动检测漏洞。

5.2软件测试专用大模型应用验证研究
场景、流程：型号场景
5.2.1 应用验证场景选择
这部分716应该有现成的？
5.2.2 应用流程分析
在实际型号测试流程中的应用，包括各个测试环节中大模型的作用和流程优化。
5.2.3 测试结果评估（指标
如何分析大模型在测试需求分析、用例生成、架构评审和漏洞检测中的具体表现。定量和定性评估其指标，覆盖要求

以大模型为线

数据怎么采集拿到调优有了大模型效果更好设计一些工具用它
前面模型可以忽略假设有一个基础模型

架构设计放在第三个里

军用软件特点:
(a)产品和服务的提供受军方相关管理和技术要求的约束，需考虑军方要求的符合性因素;
(b)军事领域的多样性和军事保密引起的非公开性等因素在无形中形成了技术门槛，需考虑在不同军事应用领域的测试工程经验因素;
(c)军用软件研制通常会随装备研制阶段进行迭代，需考虑开展回归测试等相关售后服务需求因素。
目前，我国软件测评实验室获取到国家和军方认证的已经达到300多家，软件测试工作实施过程中各项活动的生命周期
目前主要还是由测评实验室的测评人员进行人工驱动。如何对软件测试的生命周期进行更高效的管控，以提高测试效率和测试质量，是目前国内外学者研究的重要课题。
《GJB 5000A-2008军用软件研制能力成熟度模型》和《GJBZ 141-2016军用软件测试指南》
军用软件测试过程具有投资大、周期长、风险高的特点，在测试过程存在很多的不确定因素，导致了测试结果的不确定性和不可预见
高昂的持有成本。通用性不足。难以满足新形势下的测试需求。
总结
目前的软件测试,尤其是jy软件,它存在哪些具体问题,它目前的解决方式是什么,目前的软件测试的流程\应用是什么
- 现有的测试方法成本高,周期长.对于军用软件通用性不足,人工程度很高,难以满足新形势下的测试需求。
什么是基于大模型的缺陷代码冗余噪声处理技术?
*