集成测试

被低估的集成测试：低空飞控软件质量的隐形关卡

当亿航EH216-S载人无人驾驶航空器在广州完成全球首条低空航线商业试飞时，很少有人会注意到，支撑它平稳完成起降、避障、航线切换全流程的，是飞控系统近百万行代码之间上万个接口的协同——而在这套系统投入试飞前，至少有三轮集成测试已经完成了对所有模块耦合关系的排障。在低空经济加速落地的今天，很多人把注意力放在eVTOL的动力设计、空域开放等看得见的环节，却少有人关注：飞控软件的集成测试，才是决定低空飞行器安全底线的隐形关卡。

很多人对软件测试的认知还停留在“单元测试找bug，系统测整体功能”的二分法里，集成测试往往被当成单元测试之后的“组装走个过场”。但实际上，集成测试从定义上就和前两者有着清晰的边界：按照清华大学出版社出版的软件测试教材界定，集成测试也叫组装测试、联合测试，是在单元测试完成后，将所有模块按照设计要求组装为子系统或系统，专门检验模块间接口、集成后功能正确性的测试工作——它解决的，恰恰是单元测试覆盖不到的问题：每个模块单独跑都没问题，拼在一起就出故障。

这绝不是杞人忧天。单元测试的本质是对独立软件组件的隔离验证，比如eVTOL飞控系统中，高度传感器数据读取模块单独测试可以输出正确数值，姿态调整模块单独运算也符合逻辑，但当两个模块对接时，如果其中一个模块输出的单位是米，另一个默认输入单位是英尺，单元测试根本发现不了这个问题，只有集成测试能揪出这个会导致坠机的接口错误。微软文档中对集成测试的定位说得很清楚：单元测试测试单独的类、方法，集成测试才验证两个甚至多个组件一起工作时，能不能输出符合预期的结果。对于低空飞行器这种安全优先级最高的领域，这样的接口错误哪怕只有一个，都是致命的。

集成测试的核心前提，是先摸清楚所有模块的相依性——也就是谁依赖谁，哪个模块出错会牵一发而动全身。很多测试团队在集成阶段踩坑，都是因为跳过了相依性分析直接开始组装测试，最后出了问题根本找不到根源。按照高等教育出版社在线课程的软件测试体系梳理，经过几十年的行业实践，当前主流的集成测试方法已经形成了覆盖不同场景的完整方案，从最经典的自顶向下、自底向上集成，到针对复杂核心系统的核心系统先行集成，再到基于调用关系的集成、敏捷开发模式下的高频集成，不同方法适配不同的产品开发节奏。

对于eVTOL飞控这种核心逻辑权重极高的系统，业内最常用的其实是核心系统先行集成法。先把飞控的核心导航模块、动力控制模块、故障应急模块这几个核心单元组装起来，先做核心模块间的集成测试，验证核心逻辑的接口正确性，再逐步把避障模块、通信模块、客舱控制模块这些周边模块一个个加进来测试。这种方法的好处是，核心逻辑的问题会在最早阶段被发现，而核心恰恰是整个系统安全的基础——毕竟如果核心模块的接口都不对，周边模块做的再对也没用。2023年我国某eVTOL整机企业在适航审查阶段，就通过核心先行集成测试发现了应急迫降模块和动力输出模块的握手协议不兼容问题，提前三个月完成了修复，避免了后期试飞阶段的重大风险。

而在敏捷开发成为主流的今天，越来越多的低空软件团队开始采用高频集成测试方法。也就是开发团队每隔1-2天就把新开发完成的模块集成到主干代码中做一次测试，而不是等到所有单元开发完成再做一次大集成。这种方法的优势非常明显：问题发现的早，修改成本低，比如某低空物流无人机企业的飞控开发团队，采用高频集成之后，接口类问题的平均修复时间从原来的2.3天缩短到了4小时，整体集成测试阶段的时间缩短了40%。

为什么集成测试越来越重要？我们从低空飞控软件的开发趋势就能看出来：现在的eVTOL飞控软件，代码量早已突破百万行级别，模块化拆分越来越细，一个飞控系统往往会拆分出上百个独立开发的单元模块，模块之间的调用关系、接口数量呈指数级增长。根据国内头部eVTOL企业公开的适航资料，主流机型的飞控软件接口数量超过12000个，接口之间的相依关系超过30000组，这么多接口组合在一起，出问题的概率远高于早年的固定翼无人机。单元测试只能覆盖单个模块，系统测试是从用户端看整体功能出不出问题，真出了问题，系统测试只能告诉你“哪里不对”，只有集成测试能告诉你“是哪两个模块对接出了错”。

这个定位，恰恰是很多行业新手容易混淆的。比如有人会问：我都做系统测试了，为什么还要单独做集成测试？拿ASP.NET Core开发的低空运营平台举例子：我们做单元测试的时候，会单独测航班查询接口的查询方法，单独测用户权限验证方法，两个单独跑都没问题。做集成测试的时候，我们会把权限模块和航班查询模块拼在一起，测有权限的用户能不能查到，没权限的用户能不能拦截——这一步单独测的时候都测不到，而系统测试的时候，可能只会测一遍成功场景，就直接过了，如果刚好测试用例用的是管理员账号，就可能漏掉权限校验和查询模块接口不匹配的问题，最后放到生产环境，就会出现普通用户查不到订单的故障。这个小问题放在低空运营平台只是影响体验，如果放在飞控系统，就是影响安全的大问题。

现在行业里还有一个误区，就是认为集成测试是纯软件环节的事，和硬件无关。实际上，现在低空飞行器的软件硬件耦合越来越深，飞控软件和传感器、动力电机的集成，也是集成测试覆盖的范围。比如传感器模块的硬件驱动是一个单元，飞控的航迹计算模块是另一个单元，硬件驱动输出的数据格式是16位整型，航迹计算模块预期的是32位浮点型，这个硬件软件之间的接口错误，也是集成测试要抓的问题。国内某头部低空测绘无人机企业，就曾经在集成测试阶段发现，激光雷达的硬件驱动模块和点云建模模块的数据精度不匹配，导致建模出现厘米级误差，这个问题如果等到整机集成后再发现，光是重新打样硬件就要耽误两个月的工期。

从整个行业的发展来看，现在集成测试正在从“可选环节”变成“刚需环节”，尤其是低空经济领域，适航审查对软件质量的要求越来越高，中国民航局发布的eVTOL适航标准中，明确要求对软件模块间的所有接口进行验证，这个验证工作，就是集成测试的核心内容。按照现在的行业惯例，一款拿到适航证的eVTOL，飞控软件的集成测试投入，一般会占到整个软件开发测试投入的35%左右，这个比例还在逐年上升——因为随着功能越来越复杂，接口越来越多，集成测试的权重只会越来越高。

很多人说，现在有了大模型自动生成单元测试用例，有了自动化测试工具，测试的工作量是不是变小了？实际上，单元测试确实可以很大程度上靠自动化生成，但集成测试需要先做相依性分析，需要根据模块之间的耦合关系设计测试用例，这个工作目前还是需要有经验的测试工程师来完成，尤其是核心系统的集成，相依性梳理错了，整个测试都是无效的。这也是为什么现在低空领域专业的集成测试人才缺口越来越大，头部企业给出的资深集成测试工程师年薪已经突破了80万，还是一将难求。

回到低空经济这个赛道，我们总在说安全是底线，那安全的底线到底在哪里？不是外形酷炫的整机，不是拿到批复的航线，是每一行代码、每一个接口都能按照预期工作，不会在飞行过程中出问题。集成测试就是守住这条底线的最后一道前置关卡——它不面向公众展示，也不会出现在企业的发布会通稿里，但它的每一次运行、每一个bug的修复，都是在给低空飞行的安全兜底。当未来越来越多的载人eVTOL飞上城市天空的时候，我们应该记得，这些平稳飞行的背后，是无数测试工程师在集成测试阶段，对上万个接口做的一次次验证。