软件测试体系笔记：从模型到落地

整理自关于测试模型与测试分层的讨论，面向切片打印软件（Qt桌面应用 + 齿科医疗场景）的实际工作。

主线：测试思想 → 测试理论 → 测试分层 → 互联网与医疗工业界对比 → 场景落地。

第一部分：测试思想（总纲）

1.1 总钥匙：失败成本决定流程严格程度（风险定价）

场景	出bug的后果	流程取向
互联网产品	回滚/热修复，损失是用户流失	快速迭代，把风险摊平在发布中
医疗/工业软件	物理伤害、批次报废，损失不可承受	前置严格，把风险拦在发布前

理解任何测试流程差异，先问一句：这个产品的失败成本有多高？ 流程的严格程度本质上是对风险的定价方式。

1.2 质量成本曲线

质量总成本 = 一致性成本（预防 + 评价）+ 非一致性成本（内部失效 + 外部失效）。

早期预防投入很便宜（评审、UT），后期修复成本急剧上升：需求阶段改错是1倍成本，发布后改错可达10~100倍。
结论：质量是设计出来的、预防出来的，不是测出来的。测试只是质量活动的一环。
但一致性成本并非越高越好，两者存在平衡点（最经济质量控制水平）。

1.3 测试的局限性（必须建立的认知）

测试只能证明缺陷存在，不能证明缺陷不存在（Dijkstra）。全部用例通过 ≠ 无bug。
穷举测试不可能：输入组合是天文数字，测试必然是抽样。
因此测试设计的本质是风险驱动的抽样：把有限的测试资源投到风险最高的地方。
缺陷聚集性（80-20现象）：少数模块包含大多数缺陷。测试应聚焦修改频繁的、历史bug多的模块。
杀虫剂悖论：同一套用例反复跑，最终不再能发现新缺陷------用例需要持续评审、更新、补充。

1.4 验证与确认（Verification & Validation）

验证（Verification）：把产品做对------软件是否逐层符合设计/需求规格，回答"做得对吗"。
确认（Validation）：做对的产品------产品在真实用户场景中是否满足需求，回答"做对了吗"。
这两个概念是测试理论的地基，V模型的"V"即源于此。

1.5 需求---测试可追溯性

每条需求必须能双向对应到测试用例。受监管行业的硬性要求：

国际：FDA（美国医疗器械）、ISO 13485（医疗器械质量体系）、IATF 16949 / ASPICE（汽车）
国内：NMPA注册（医疗器械软件）、GMP体系
写注册文档时，"需求→设计→测试用例"的追溯链就是审评材料的核心结构。

1.6 尽早测试原则

缺陷发现越晚，修复成本越高。因此：

需求阶段就开始评审（静态测试），而不是等代码写完再测。
Shift-left（测试左移）：测试人员尽早介入需求分析，测试设计前置。

第二部分：测试理论（模型的现状与全貌）

2.0 总体判断

经典模型不再是流程模板，而是思维框架 和合规语言 。越严肃的领域（医疗、工业软件）越离不开。它们的"形"过时了，"神"还在。

2.1 V模型------最有生命力

核心不是那个V字图形，而是：① V&V的区分；② 需求---测试的追溯链。
结构：左侧自顶向下（需求→概要设计→详细设计→编码），右侧自底向上（单元测试→集成测试→系统测试→验收测试），每级测试与设计阶段对应。
现状：医疗器械、汽车、航空是硬性要求；现代实践没有推翻它，CI/CD流水线本质仍在跑V模型右边那列。

2.2 W模型------名字消亡，思想获胜

想表达"测试活动贯穿整个开发周期，不只是编码后"，开发一个V、测试一个V并行。
该思想已被shift-left测试、持续测试、TDD完全吸收，但没人再画那个W。

2.3 H模型与X模型（了解即可）

H模型：把测试独立出来，达到某个测试就绪点就执行，强调测试的独立性和迭代性；不像V/W那样绑定开发阶段。
X模型：试图融合V和H，提出"探索性测试"和"不基于设计的测试"，实际应用很少。
意义：说明行业早就认识到"测试活动不应被开发流程形状绑架"，为敏捷时代的独立测试流水线做了理论铺垫。

2.4 瀑布模型------作为流程死了，作为纪律还活着

作为开发流程：对迭代快的产品软件已过时（需求锁定数月再交付是自杀式做法）。
作为纪律：文档先行、阶段评审、变更控制，在安全关键和合规场景仍然必要。
现实：大量团队是"伪敏捷"------名义敏捷，关键环节（需求基线、发布评审、合规文档）仍是瀑布式闸门管理。

2.5 增量与迭代模型（瀑布到敏捷的中间态）

增量：把产品切成若干可交付的增量块，一块一块开发交付（如先骨架后血肉）。
迭代：反复打磨同一块，版本逐步逼近目标（如原型法）。
现代敏捷本质是"增量 + 迭代"的组合。

2.6 敏捷宣言与测试的变迁

敏捷宣言四条价值观：个体与互动高于流程与工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。

对测试的影响：

测试不再是独立阶段，而是贯穿每个迭代的持续活动。
文档精简但合规场景不能省（监管框架下的敏捷：文档该写还写，只是更精简、随迭代滚动更新）。
测试自动化成为前提：迭代速度快，手工回归跟不上，倒逼自动化。

2.7 ISTQB测试过程（通用测试流程）

测试计划：确定范围、策略、资源、进度、出口准则
测试分析与设计：分析测试依据，设计用例
测试实施：准备环境、数据、脚本
测试执行：跑用例、记录结果、提缺陷
出口准则评估：对照准则决定能否结束
测试总结：报告、经验教训

敏捷环境下这个流程压缩到一个迭代内完成，但环节一个不少。

2.8 测试成熟度：TMMi（了解）

测试过程成熟度五级（类比CMMI）：初始级 → 已管理 → 已定义 → 已度量 → 优化级。用于评估组织测试能力，大型企业过体系认证时会接触。

第三部分：测试分层

3.0 两个维度看测试

测试可以按"层级 "分（单元→集成→系统→验收），也可以按"类型"分（功能/性能/安全/可靠性...）。层级回答"测多大范围"，类型回答"测什么方面"。实际用例都是两维的交点，比如"系统级的性能测试"。

3.1 IPD七层（华为研发体系叫法，国内大型软硬件企业常见）

开发主导的四层（UT / IT / ST / BBIT）：

层级	全称	测什么	测试对象（依据）	责任人
UT	Unit Test 单元测试	单个函数/类是否符合详细设计	LLD详细设计	开发
IT	Integration Test 集成测试（单元间）	函数/类之间的接口配合	单元间接口设计	开发
ST（MST）	(Module) System Test 模块系统测试	单个模块作为整体是否符合模块需求	模块SRS	开发
BBIT	Building Block Interface Test 模块间接口测试	已验证模块逐层向上集成为可运行系统	系统设计分解结构	开发/测试

关键区别：UT测"每个零件是否牢固"，IT测"零件之间的接口"，MST后"模块牢固可用"，BBIT后"模块拼起来能跑"。
注意：BBIT ≠ 联调。联调通常涉及软硬件或不同产品间的配合；BBIT是严格按系统设计分解做逐层集成。
指标：覆盖率、千行代码缺陷率（kloc）等经验要求。

测试工程师主导的三层（SDV / SIT / SVT）：

层级	全称	范围/方法	测试对象（依据）
SDV	System Design Verification 系统设计验证	子系统/模块级，偏灰盒（关注内部实现）；除功能性能外含EMC、热测试、环境可靠性	设计需求（DR）
SIT	System Integration Test 系统集成测试	整机/完整产品级，纯黑盒（不关心内部实现）；比SDV增加可用性、可维护性、包装测试	整机设计需求
SVT	System Verification Test 系统验证测试	小批量试制阶段的验收测试；验证产品包需求（OR）；关注质量一致性，通常从试制生产线随机抽检	产品包需求（OR）

七层背后的三个核心逻辑：

架构分解的镜像：系统按"系统→子系统→模块→单元"自顶向下设计，测试自底向上逐层验证；每层测试对象就是上一层设计的输出物，需求与测试天然形成追溯链。
每层两件事：除SVT外，每层既测"本层每个构件"（n个构件测n次），又测"构件之间的接口"（n个UT对应1个IT，n个MST对应1个BBIT，以此类推）。
质量闸门：SDV/SIT/SVT对应IPD技术评审点（TR4A/TR5等），每级通过才能进入下一阶段------本质是把V模型的"阶段出口准则"工程化了。

3.2 互联网测试分层（测试金字塔）

IPD七层	互联网对应物
UT	单元测试（开发写，CI强制，覆盖率卡点）
IT / BBIT	服务间契约测试 / 接口自动化（Mock + 契约测试如Pact）
ST / SDV	端到端自动化（Selenium/Playwright、接口E2E）
SIT	预发环境全链路联调 + 回归测试集
SVT	没有直接对应------被"灰度发布 + 线上监控"取代

投入比例：大量单元测试、适量接口测试、少量UI自动化（塔尖）。
常见反模式------冰淇淋筒：UI自动化臃肿、单元测试稀薄。
SVT被"生产环境验证"吞掉：先放1%流量（灰度），看错误率和业务指标，再全量。消费级产品最高效；医疗软件绝不可行（不能"灰度给1%的病人用"）。

3.3 测试类型（按测试目的分）

类型	关注点	典型工具/方法	层级
功能测试	功能是否符合需求	用例设计方法（见3.5）	各层
性能测试	响应时间、吞吐、资源占用	负载/压力/稳定性测试（LoadRunner、JMeter）	ST/SIT
安全测试	漏洞、注入、越权	渗透测试、静态扫描（SonarQube、Fortify）	各层
兼容性测试	不同OS/硬件/版本	兼容性矩阵	SIT
可靠性测试	长时间运行稳定性	老化测试、异常注入	SDV/SIT
易用性测试	用户体验	用户调研、可用性走查	SIT
回归测试	变更后存量功能完好	自动化回归集（见4.3）	各层
冒烟测试	主干流程通不通，决定要不要深测	核心用例子集	各层
探索性测试	边测边设计，发现脚本漏掉的缺陷	手工经验驱动	ST

3.4 白盒 / 黑盒 / 灰盒

白盒：看得见内部代码结构。依据：详细设计。方法：语句覆盖、判定覆盖、条件覆盖、路径覆盖（覆盖强度递增）。主要用于UT。
黑盒：只关心输入输出。依据：需求规格。方法：等价类、边界值等（见3.5）。主要用于ST/SIT/SVT。
灰盒：部分了解内部结构，介于两者之间（如SDV）。

3.5 黑盒测试用例设计方法（面试与实用并重）

等价类划分：把输入域划分为若干等价类，每类取一个代表值。有效等价类 + 无效等价类都要覆盖。
边界值分析：缺陷高发于边界。原则：取刚好等于、刚好大于、刚好小于边界的值。与等价类配合使用。
判定表（决策表）：多条件组合时，列出条件组合与动作的对应关系，避免遗漏。
因果图：条件之间有约束关系（与/或/非、互斥）时，先画因果图再转判定表。
场景法：基于业务流程画基本流和备选流（如导入模型→切片→导出，中途取消/文件损坏等）。
错误推测法：凭经验猜测易错点（空输入、超长输入、并发、时序、编码问题、文件损坏）。
正交试验：参数组合爆炸时，用正交表抽样减少用例数。

实用建议：等价类+边界值覆盖80%日常用例设计；流程类用场景法；刁钻场景靠错误推测。

第四部分：互联网 vs 医疗工业界：流程对比

4.1 总对比表

维度	IPD / 医疗工业界	互联网公司
流程骨架	阶段制 + TR评审闸门	敏捷sprint + 持续交付流水线
质量出口	阶段评审通过才走下一步	流水线绿灯（CI门禁）才能合入
发布频率	数月一个版本	每天多次
测试责任人	分层专职测试团队	开发为主 + SDET建设测试基础设施（测试开发比约1:5~1:10）
需求形态	需求规格基线锁定	用户故事进backlog，持续流动
最后一层验证	SVT小批量验收测试	灰度发布 + 可观测性 + A/B实验
文档	完整、受控、可审计	精简、代码即文档、Wiki滚动更新
缺陷态度	零容忍倾向，闸门拦截	快速修复，允许带小bug上线（有容错回滚兜底）

4.2 互联网侧关键实践

CI/CD流水线：合码 → 自动构建 → 静态检查（lint/sonar）→ 单元测试 → 打包部署测试环境 → 接口/E2E测试 → 预发 → 灰度 → 全量 → 监控。任何一环红灯即阻断。
DevOps：开发与运维一体化，用基础设施即代码（IaC）保证环境一致性，"你构建的，你运行"（You build it, you run it）。
可观测性三支柱：日志（Logging）、指标（Metrics）、链路追踪（Tracing），承担了一部分"线上验证"职责。
A/B实验：小流量对比验证产品决策，本质是"用真实用户做确认测试"。
混沌工程：主动注入故障（杀实例、断网络）验证系统韧性，对应可靠性验证。
契约测试：微服务间以契约为准，各自独立演进，取代重量级联调。

4.3 概念辨析（易混三兄弟）

回归测试 = 一种目的：代码变更后重跑已有用例，确认存量功能没坏（修复bug、加新功能最容易弄挂旧逻辑）。
CI（持续集成） = 一种机制：代码合入主干即自动触发"编译→测试→报告"。
质量门禁 = CI的用法：回归用例全绿才允许合入。
关系：CI是流水线，回归测试集是流水线上跑的内容，门禁是阻断策略。前提：能进CI的必须是自动化用例。

4.4 医疗工业界侧关键实践

医疗器械软件生命周期标准 IEC 62304（国内对应 YY/T 0664）：软件安全性分级（A/B/C级），C级（可能直接或间接导致死亡/严重伤害，如种植导板设计软件）要求最完整的文档、验证、追溯体系。
风险管理 ISO 14971（国内 YY/T 0316）：风险分析→评价→控制→ residual risk 接受，测试用例与风险控制措施对应。
配置管理：软件版本、开发工具链、依赖全部受控，保证"可重现的构建"。
变更控制：任何变更走变更流程，评估影响范围，回归测试范围基于影响分析确定。
确认/再确认：软件重大更新可能触发医疗器械再注册或变更注册；实物打印的"过程确认"需重跑。

4.5 一句话总结

IPD是"把每个阶段验证透了再走下一步"；互联网是"让流水线自动把关、让线上数据说话"。两者是同一套测试思想在不同失败成本下的不同展开。

第五部分：场景落地：切片打印软件怎么测

5.1 测试活动分层映射表

测试活动	层级	说明	能否进CI
切片算法、网格修复等函数	UT	GTest / Qt Test，开发自写	✅
引擎与UI层的数据接口	BBIT级	模块间接口验证	✅
输入模型→切片→比对G-code/层片	ST级 + golden-master	见5.2	✅
界面核心流程点击（导入→切片→导出）	E2E / 系统测试	黑盒，塔尖少而精	✅
切片速度、内存占用（大模型）	ST级性能测试	计时、profiling	✅
畸形文件鲁棒性（空/损坏/超大STL）	ST级健壮性	错误推测法设计	✅
实际打印出件并测量	SVT / 系统验证	涉及硬件、材料、环境，超软件边界	❌ 周期性执行
证明既定参数下持续达标	过程确认	注册体系活动，软件版本是关键变量	❌

5.2 核心实践：Golden-Master回归集

切片引擎非常适合做基准数据测试（golden-master）：

挑20~50个代表性模型：含破面、薄壁、悬垂、多孔结构、文字雕刻面等刁钻情况；
保存各模型的期望切片输出（G-code / 层片数据）；
接入CI，每次提交自动切片 + 自动比对。

原理：切片结果是确定性的、可自动比对的。这比手工抽查高效得多，且桌面软件团队普及率低，容易做出亮点。

注意：golden-master的期望输出本身要经人工评审确认（否则错误被固化）。算法有合理变更时，基准需人工评估后再更新。

5.3 实物侧验证的工程化

实物打印进不了CI，但可周期化、标准化：

固定标准模型 + 固定打印机 + 固定材料 + 固定参数；
打印后测量关键尺寸（尺寸精度、翘曲、孔径、支撑接触面质量）；
形成测试报告存档；换软件版本时重跑一遍（影响工艺确认的变更需评估再确认范围）。

5.4 可测试性驱动重构

原则：难以测试的代码，往往就是设计有问题的代码。
症状：一个函数长到要按"子功能"分别测试------说明它违背了单一职责原则，是几个功能挤在一个函数体里。
做法：不是研究怎么测，而是先拆后测。例：slice()拆出validateMesh()、generatePaths()、optimizePaths()，每个小函数是清晰单元，各配UT；原函数变为组合调用，配少量集成测试即可。
切片管线天然是多阶段（读取→修复网格→分层→生成路径→优化），尽早按阶段拆开，是golden-master方案能落地的前提。
依赖注入、接口抽象是C++提升可测试性的常用手段（将文件IO、设备访问抽象成接口，测试时用Mock替代）。

5.5 Qt/C++ 测试工具链速查

用途	工具
Qt单元测试	Qt Test模块（QTestLib，支持GUI事件模拟）
C++单元测试	Google Test（最主流）、Catch2
代码覆盖率	gcov + lcov（Linux）、OpenCPPCoverage（Windows）、BullseyeCoverage
UI自动化	Qt自带QTest + 基于accessible接口，或截图比对（像素级回归）
Python侧（如有脚本）	pytest-qt
静态检查	Clang-Tidy、Cppcheck、SonarQube
Mock框架	Google Mock、Trompeloeil
CI工具	Jenkins、GitLab CI、GitHub Actions
内存/并发错误	Valgrind、AddressSanitizer、ThreadSanitizer

5.6 3D打印软件特有验证点清单

切片几何正确性：层片轮廓与模型截面一致，无破面漏切
切片完整性：层数正确，层高均匀，无丢层重复层
路径正确性：无碰撞、无空走刀异常、填充率符合设置
支撑有效性：悬垂角度识别正确，支撑可去除
尺寸精度链：STL单位/缩放、补偿参数（收缩、xy补偿）正确传递
大模型性能：千万级面片不崩溃，内存可控
文件兼容性：STL（ASCII/二进制）、OBJ、3MF（含颜色/多材料信息）
G-code方言：不同打印机指令集（Marlin/Klipper等）正确输出

5.7 判断口诀（速用）

层级判断：结果只在软件内部比较 → 系统测试；物理打印出来才算数 → 系统验证；要证明"持续达标"以满足监管 → 过程确认。
UT判断：直接调代码、无外部依赖 → UT；从用户界面操作黑盒 → 系统/E2E测试；调独立UI组件类的接口 → 仍是UT（区别于点界面）。
流程判断：失败成本高 → 前置严格（文档+评审）；失败成本低 → 快速迭代+快速回滚。

附录A：术语速查表

缩写	全称	一句话解释
UT	Unit Test	测单个函数/类是否符合详细设计
IT	Integration Test	测单元/构件之间的接口配合
ST / MST	(Module) System Test	测单个模块整体是否符合模块需求
BBIT	Building Block Interface Test	已验证模块逐层集成为可运行系统（≠联调）
SDV	System Design Verification	子系统级设计验证，灰盒，含可靠性测试
SIT	System Integration Test	整机级集成测试，纯黑盒
SVT	System Verification Test	小批量试制验收，验证产品包需求（OR）
UAT	User Acceptance Test	用户验收测试（验收测试的一种）
DR	Design Requirement	设计需求
OR	Offering Requirement	产品包需求
SRS	Software Requirement Specification	软件需求规格
TR	Technical Review	IPD技术评审点
kloc	千行代码	缺陷率统计单位
CI	Continuous Integration	持续集成，合码即自动构建+测试
CD	Continuous Delivery/Deployment	持续交付/部署
E2E	End-to-End	端到端测试，黑盒全流程
Golden-Master	基准数据测试	比对已知正确输出
Shift-left	测试左移	测试活动前置到开发早期
SDET	Software Development Engineer in Test	测试开发工程师
TDD	Test-Driven Development	测试驱动开发（红-绿-重构）
BDD	Behavior-Driven Development	行为驱动开发（Given-When-Then）
V&V	Verification & Validation	验证与确认
回归测试	Regression Testing	变更后重跑已有用例确认存量功能没坏
冒烟测试	Smoke Test	主干流程通了才值得深测
质量门禁	Quality Gate	用例全绿才允许合入/流转
冰淇淋筒	Ice Cream Cone	UI自动化臃肿、单测稀薄的反模式
杀虫剂悖论	Pesticide Paradox	同一套用例反复跑不再发现新缺陷
IEC 62304 / YY/T 0664	医疗器械软件生命周期	软件安全性分级（A/B/C级）要求
ISO 14971 / YY/T 0316	医疗器械风险管理	风险分析-评价-控制全流程
ASPICE	Automotive SPICE	汽车行业软件过程能力标准
TMMi	Test Maturity Model integration	测试过程成熟度模型
IaC	Infrastructure as Code	基础设施即代码
Mock	模拟对象	替代真实依赖的可控测试替身

附录B：推荐阅读与考证路径

入门体系：ISTQB Foundation（国际软件测试认证，国内软考"软件评测师"）
经典书目：《软件测试》（Ron Patton）、《Google软件测试之道》（How Google Tests Software）
进阶：TMMi模型、探索性测试（《探索式软件测试》James Whittaker）
工程实践：《持续交付》（Jez Humble）、《单元测试的艺术》
UT-IT-ST-BBIT-SDV-SIT-SVT

笔记完。建议后续增补：CI流水线配置实例、各层测试用例模板、测试报告模板。