ARTICLE · 1158397

《DevSecOps 环境下软件开发测试与评估指南》详解

发布时间：2026-10-11 21:02:47 最近访问：2026-10-11 21:02:47

一、指南基础信息

指南全称：Software Developmental Test and Evaluation in DevSecOps Guidebook（DevSecOps 软件开发测试与评估指南）
发布时间：2025 年 1 月
发布机构：美国国防部研究与工程副部长办公室，开发测试评估局（DTE&A）
公开状态：公开发布，无分发限制（Distribution Statement A）
编制目的：为美国国防部软件开发测试评估（DT&E）从业人员提供参考资料，适配 DevSecOps 开发‑安全‑运维一体化模式，改造测试评估的策略、规划、执行与分析流程，适配快速迭代开发框架；打通开发测试评估与独立作战测试评估（OT&E）、实弹测试评估（LFT&E）的目标衔接，保障各类软件密集型、赛博物理系统的测试工作落地。
适用范围：国防部各类采办路径下的软件项目，涵盖预研、原型、采办、在役维护全生命周期，包含 AI / 机器学习系统。
核心定位：本指南不替代现有政策文件，是对国防部现有测试评估体系的补充实操手册，后续会根据使用反馈迭代新版本。

二、指南框架结构

指南一共 6 个主体章节，外加附录、术语表、缩写表、参考文献。

章节	章节主题	核心内容简述
第 1 章	引言	指南目的、DT&E 活动边界、DevSecOps 基础框架、企业级测试政策、其他配套参考文件
第 2 章	DevSecOps 下 DT&E：角色、团队、权责与授权	梳理国防部采办管理、测试评估管理、产品开发团队、政府测试团队的岗位分工，厘清传统采办向 DevSecOps 转型后的权责变化
第 3 章	DevSecOps 下 DT&E：基础概念	DevSecOps 生态体系、度量指标两大模块，讲解软件流水线、各类环境、测试工具、软件测试指标、安全指标
第 4 章	DevSecOps 下 DT&E：跨阶段通用持续性活动	不局限单一阶段，全生命周期都要开展的测试工作：需求分析、测试策略规划、自动化工具选型、敏捷框架与 DT&E 融合、架构安全、软件保障与赛博测试、AI 系统测试注意事项
第 5 章	DevSecOps 下 DT&E：各阶段专项 DT&E 工作	按照 DevSecOps 完整生命周期（计划、开发构建、测试发布、交付、部署、运行‑监控‑反馈），逐个阶段拆解测试任务、目标、管控门限、各测试岗位工作内容
第 6 章	DevSecOps 下 DT&E：培训体系	测试人员培训、用户培训，覆盖 DevSecOps、自动化工具、科学测试分析技术、赛博测试、系统业务培训
附录	用例集	收集实际项目案例，用于后续版本迭代优化指南内容
附件	术语、缩写、参考文献、网页资源	统一解释专业词汇，罗列政策与工具参考来源

三、各章节要点

第 1 章引言

1.DT&E（开发测试评估）活动范围

开发测试评估从能力需求阶段启动，贯穿开发、OT&E 过渡、交付、部署、运维保障全流程；核心产出：决策依据、项目进度度量、技术债务识别、系统能力与局限刻画、需求合规评估、退出准则校验。DevSecOps 高速迭代模式要求测试评估采用自适应方法，迭代更新退出判定标准。

后续新版 DoDI 5000.DT 政策文件，会进一步扩大 DT&E 定义，将预研、原型试验、维持阶段系统全部纳入 DT&E 管理范畴。

2.DevSecOps 框架核心特征

DevSecOps 源于敏捷理念，是一套组织文化与实践体系，覆盖计划、开发、构建、测试、发布、交付、部署、运行、监控、反馈完整无限循环生命周期。

左移测试与安全：通过自动化单元、功能、安全、集成测试，在早期就嵌入安全校验，安全和功能同步开发；
迭代增量交付：依靠 CI/CD 持续集成持续交付，向用户快速迭代软件能力，但速度不能牺牲软件质量与安全性；
设置控制闸门：每个阶段结束设置决策控制点，根据测试结果判断是否流转下一阶段；
区分持续交付与持续部署：持续交付指推送到预生产环境，持续部署直接上线生产环境。

3.配套政策体系

引用 DoDI 5000 系列国防部指令、自适应采办框架 AAF、风险管理框架 RMF，提出连续开发测试评估（dTEaaC）三大核心原则：

围绕作战人员需求构建持续学习循环；
及时提供决策支撑；
将测试评估融入数字工程创新生态。

同时强调要使用科学测试分析技术 STAT保障测试严谨性。

第 2 章角色、团队、权责与授权

DevSecOps 模式改变传统采办岗位工作模式，强调协同共识式决策，而非自上而下命令管控，主要分为四大类团队。

1.国防部项目管理团队

里程碑决策当局 MDA、项目执行官 PEO、项目经理 PM、产品保障经理 PSM。重点概念：MVP 最小可行产品、MVCR 最小可行能力版本、CR 能力迭代版本。DevSecOps 不再等待完整大版本交付，优先交付 MVP/MVCR 快速获取作战人员反馈。

2.国防部测试评估管理团队

首席开发测试人员 CDT：统筹全部 DT&E 活动，需要获得开发方自动化测试工具、测试数据访问权限；
T&E WIPT 测试评估工作层集成产品团队：多利益相关方协同，编写测试主计划 TEMP / 测试策略 TES，统筹 DT&E、OT&E、LFT&E；
SW‑ITT 软件集成测试团队：政府测试人员 + 开发人员共同组成，构建集成测试矩阵，明确各项测试由谁负责执行；
CyWG 赛博工作组：负责赛博测试规划执行报告，支撑 RMF 授权，开展基于任务的赛博风险评估 MBCRA。

3.产品开发团队

包含项目经理、产品负责人、软件主管、开发团队（架构师、开发工程师、QA、UI/UX、DevSecOps 工程师、人因工程师、安全倡导者 Security Champion）。

安全倡导者是开发团队内部角色，充当安全团队和开发人员桥梁，参与威胁建模、安全风险管控，推动安全编码落地。

4.政府测试团队

分为项目级、军种级、监督层三类；包含开发测试 DT、作战测试 OT、互操作性测试团队。

关键要求：政府测试团队需要接入测试 / 预生产环境，环境配置尽量复刻真实生产环境；测试人员需要掌握自动化测试工具技能。

第 3 章基础概念

3.1 DevSecOps 生态系统

生态由规划、软件工厂、运维三大部分组成，核心载体是软件流水线（Pipeline），流水线串联工具、流程、环境，实现测试、构建、发布自动化。

1.四大关键环境

环境	用途
开发环境	开发编码，单元测试、小规模集成测试
测试环境	系统级、系统之系统级 DT&E 测试，尽量复刻生产环境，开展手动赛博测试
预生产（Staging）环境	用户验收测试 UAT，OT&E 作战测试，完全复刻生产配置
生产环境	真实作战运行环境，具备版本回滚能力

2.测试工具分类

测试管理工具：管理测试计划、用例、需求可追溯矩阵 RTM；
测试执行工具：自动化执行用例，开展性能、压力、负向测试；
挑战：不同工具间数据互通、接口兼容、环境差异是常见痛点，优先选用国防部企业软件工厂降低集成难度。

3.控制闸门：

流水线各个节点设置 go/no‑go 决策点，单元测试、SAST 静态安全扫描、系统集成测试结果作为闸门决策输入。

3.2 度量指标 Metrics

指标来源于 CI/CD、配置管理、自动化测试工具生成海量数据；指标目的是提升透明度、设定可量化目标、支撑决策、感知安全态势、强化反馈闭环。

软件测试关键指标：测试覆盖率、自动化测试覆盖率、缺陷密度、缺陷移除效率、回归测试有效性、缺陷检测 / 修复平均时间 MTTD/MTTR、测试环境稳定性等。
软件安全关键指标：识别漏洞数量与严重等级、自动化安全测试覆盖率、误报率、高风险漏洞修复占比、安全事件响应时间、漏洞修复时间等。

注意：指标只是数字，必须人工解读，不能单纯依靠指标自动做决策；不要堆砌大量无效指标，聚焦对任务决策有价值的指标。

第 4 章跨阶段通用持续性活动

这部分工作不局限 DevSecOps 某一个阶段，在整个迭代周期反复开展。

1.测试前置：战略规划阶段测试考量

需求分析：测试团队早期介入，保证需求可度量、可测试、可实现，避免模糊主观描述；赛博需求和业务需求同等处理；
敏捷需求流转：从能力需求 CNS 分解成 Epics、Feature，再拆解用户故事 User Story，缺陷回流到待办列表重新排优先级；
连续授权 cATO：替代传统一次性 ATO 运行授权，依靠持续监控、自动化评估风险，适配频繁迭代发布。

2.测试策略与规划

TEMP 测试主计划或者定制化测试策略 TES 作为核心文档；内容覆盖任务关键功能、赛博安全、人因、条令文档培训、互操作性、可扩展性、安全性、供应链风险管理；引入 IDSK 集成决策支撑关键框架，打通测试数据和项目各项决策。

软件采办路径有法定 1 年约束：资金到位 1 年内必须交付可演示的 MVCR 最小可行能力版本，测试团队必须适配这个时间约束。

3.自动化工具选型

工具选型准则：可信透明、数据格式标准化、工具互通集成、具备对抗 CI/CD 流水线网络攻击的安全能力；优先复用政府软件工厂已有工具。同时要结合数字工程 MBSE 基于模型系统工程，建立数字线程支撑自动化测试。

4.敏捷与 DT&E融合

将测试活动嵌入 Sprint 迭代全流程：迭代规划、开发、测试、评审回顾，自动化执行测试，跨团队协作，持续改进；用户故事必须附带清晰可测试的验收准则。

5.DevSecOps 架构安全

落地零信任原则；基础设施即代码 IaC、安全即代码 SaC；将安全策略、安全检查编写进代码，流水线自动执行安全校验。

6.赛博与软件保障测试评估

自动化安全测试（SAST/DAST/IAST）不能替代人工渗透对抗测试；开展 SCA 软件成分分析、SBOM 软件物料清单监控；持续执行 MBCRA 基于任务的赛博风险评估。

7.AI/ML 系统测试特殊难点

AI 机器学习系统除了代码测试外，还需要校验训练数据集质量；统计化测试判定标准；ML 组件功能验证，该领域指南尚在编制中。

第 5 章 DevSecOps 各阶段 DT&E 专项工作

本章节是指南实操核心，划分 DevSecOps 完整生命周期，每个阶段明确测试活动、目标、控制闸门（是否可以进入下一阶段）。

1.Plan 计划阶段

主要工作：定义 “完成的标准（Definition of Done）”、编写软件测试计划、威胁建模（STRIDE 框架）、MBCRA 基于任务的赛博风险评估。

“完成的标准” 不是代表产品彻底终结，而是本轮迭代增量版本满足验收条件，作为控制闸门的检查清单，DT&E 团队要参与评审，确保覆盖系统级、赛博安全测试。

2.Develop/Build 开发构建阶段

重点测试：单元测试、SAST 静态应用安全测试、功能测试、回归测试、用户故事演示、SCA 软件成分分析、SBOM 监控、合规校验。

单元测试主要由开发团队完成，政府测试团队审核单元测试完备性；SBOM 要跟踪所有开源、第三方组件版本，匹配漏洞库及时发现供应链风险。

3.Test/Release 测试发布阶段

重点测试：SAST 二次扫描、系统集成测试、回归测试、互操作性测试、DAST 动态安全测试、API 测试、IAST 交互式应用安全测试、人因集成 HSI 测试、面向任务 DT&E、赛博 DT&E、渗透测试。

本阶段大量执行手动赛博对抗测试，验证系统在作战任务场景下真实能力，输出是否可以发布到预生产环境的闸门决策。

4.Deliver 交付阶段

回归测试、互操作性测试、性能测试；收集系统级性能指标，评估系统作战有效性、适用性、生存能力。

5.Deploy 部署阶段

初始 / 后续作战测试评估 OT&E、互操作性认证，判定是否交付给真实用户使用。

6.Operate/Monitor/Feedback 运行‑监控‑反馈阶段

系统持续监控、价值评估、故障检测、日志审计；线上发现缺陷回流到产品待办列表，驱动下一轮迭代开发测试。

全流程关键点：所有阶段测试结果、工件最大化共享复用，各测试组织之间结果互认，避免重复测试。

第 6 章培训

DevSecOps 是文化变革，需要配套人员培训。

测试人员培训：DevSecOps 理念培训、自动化测试工具、STAT 科学测试分析技术、系统业务知识、赛博测试培训。
用户培训：作战使用人员掌握新版本功能、操作流程，参与用户故事演示、验收测试。

四、结论与最佳实践

1.测试左移，测试全生命周期介入

DT&E 不能等到开发结束才开展；测试团队在需求阶段就要参与，参与定义用户故事、验收标准、完成标准，在每一轮 Sprint 迭代中持续开展测试，而不是传统瀑布式后期集中测试。

2.充分自动化，但不放弃人工测试

单元、回归、SAST/DAST 等大量重复性测试依托 CI/CD 流水线自动化；但是赛博渗透、复杂任务场景评估、部分人因测试必须依靠人工；自动化不能发现全部漏洞。

3.强调各类测试工件、测试结果共享复用

开发团队的测试结果、测试脚本、SBOM 物料清单，政府测试团队可以复用，减少重复测试；不同测试机构之间结果互认，提升效率，缩短迭代周期。

4.以任务 / 作战使命为核心导向，而不是只看代码功能

测试不只验证代码功能正确，必须结合作战任务线程，评估系统对任务的实际价值；MBCRA 基于任务的赛博风险评估作为赛博测试的输入依据。

5.建立清晰的控制闸门机制

DevSecOps 快速迭代不等于没有管控；每个流转节点设置 go/no‑go 判定，以单元、集成、安全、任务测试结果作为闸门输入，防止存在高风险缺陷的版本流向生产环境。

6.独立政府测试团队的定位变化

政府测试团队不再包揽全部测试，开发团队承担底层单元、模块级测试；政府测试重点做系统集成层面、任务场景、赛博安全、互操作性的独立评估，同时监督开发方测试质量，核查测试完备性。

7.安全是内置属性，不是附加补丁

安全即代码 SaC，威胁建模、SCA、SBOM、SAST/DAST 嵌入流水线每一步；供应链安全（开源、第三方组件）是 DevSecOps 测试评估不可缺失部分。

8.度量指标服务于决策，拒绝指标形式主义

收集指标的目的是辅助项目风险与进度判断，指标需要人工解读，不盲目追求高数字，优先选择和作战任务强相关的指标。

9.反馈闭环非常关键

生产环境监控得到的故障、用户反馈，必须回流到开发‑测试环节，驱动迭代优化，形成 DevSecOps 无限循环。

10.针对 AI/ML 系统需要特殊测试考量

AI 系统除软件本身外，训练数据集质量、统计性判定标准、模型组件有效性都是测试重点，国防部正在编制专门针对 AI 测试评估的配套文档。

五、指南局限性

本指南主要聚焦自动化赛博 DT&E，手动赛博测试完整流程会在后续《DoD Cyber DT&E Guidebook V3.0》补充；
AI/ML 系统测试仅提出注意事项，详细方法论等待专门指南；
为 MVP 初始版本，后续版本将收集项目实际用例持续更新完善。

#DevSecOps #软件开发测试评估 #指南 #软件工厂