导读

理论的危机

(资料图片)

图2：2023年上海车展博世展台的DevOps造型

图3：DevOps模型

目标系统本身的差异性影响测试的范围。我们知道手机的众包测试，它是为了验证适配不同类型手机而进行的海量测试。如果汽车系统可以提供百分之一百标准化的抽象层，汽车应用只要兼容这个抽象层就可以运行在所有的汽车系统上。这样就只需要测试一个目标系统，就可以代替全体目标系统的测试。然而这是不现实的事情，在高度标准化的Android生态下也需要众包测试来验证目标系统的类型差异。何况汽车的复杂度远远大于手机，其标准化的道路会遥远而漫长。因此，众包测试也可能是软件定义汽车需要采取的测试策略。

目标系统与外部交互的差异性影响测试的范围。汽车系统会与环境和人进行交互，并且做出响应。时间，空间和人的交互都会改变汽车系统的响应行为。这就要求我们，只有汽车系统进行了全空间域和全时间域的测试才是完备的验证测试。也就是说，在所有时间和空间发生的事情都测试一遍，逻辑上才是全域覆盖的完备测试。但是我们知道这是不可能做到的事情，汽车系统测试必须做出妥协：一种方式是时间和空间变化对目标系统的扰动很小可以忽略不计；另一种方式是我们在时间上和空间上目标系统都一直伴随存在一个测试系统，发现问题就及时修正，当修正地足够快且足够多的时候就可以无限逼近测试的全覆盖了。

软件定义的汽车隐含地提供了个性化产品服务的特征，“持续”导致研发态永远在路上，个性化导致测试资源需要分布更细的粒度和更大的范围。我们知道资源永远是有限的，那么在现有的资源下我们提供的测试方案：

多种因素导致软件定义汽车测试的危机，测试的危机严重影响了DevOps的循环，严重的以至于撕裂莫比乌斯环。难道我们必须退化到传统的瀑布模型吗？显然不是，我们需要新的方法处理汽车研发的新问题。

V模型侧重流程和验证，属性偏“硬”；DevOps侧重文化和惯例，属性偏“软”。俗话说：“量体裁衣，看菜吃饭”，我们需要的是软件定义汽车自己的研发理论模型，而不是简单的拼接或缝合。面对软件定义汽车这样新的研发场景，我们需要寻找的是一种具有高度复杂硬件，在高度复杂交互环境和高度安全要求下实施软件研发的工作模型。当然，这里一定有继承，这里也一定有扬弃，在“不断推进实践基础上的理论创新”的指引下提出我们的思考。

前面我们论述了“软件定义汽车的危机，本质上是测试的危机”，所以，首先我们要继承“测试先行”和“测试驱动”的核心理念。接着，我们试图寻找一个简单的，直观的，可运行的测试驱动模型，裁剪繁琐的流程过程，追求极致敏捷，追求自动与智能。我们先从“测试驱动”的理念入手，观察软件定义汽车研发，探索我们的思考。我们从两个视角进行观察，一个是从空间视角，另一个是从时间视角。

我们先从空间的视角观察软件定义汽车研发。一切的来源还是需求，根据测试驱动的理念，需求经过演化在空间上我们得到一个二元系统，一个是面向最终产品功能的目标系统；另一个是面向产品支持运作的支撑系统。无论是目标系统还是支撑系统，都是可运行系统。这里所说的可运行系统强调的是系统的可执行性，即被万物皆代码驱动的（万物皆代码，everything as code），而不是文档驱动的系统。测试驱动且测试先行的二元系统模型如下图。

图5：测试驱动的二元系统

支持系统是测试驱动且测试先行的系统，是以测试为主体，包含研发运维的综合系统。支撑系统优先于目标系统进行部署和执行。根据这个模型，汽车产品是目标系统与支撑系统的统一体。基于测试先行的原则，支撑系统的生命周期不但早于而且长于目标系统。软件定义汽车产品是符合冰山模型的产品，一部分在前台，一部分在后台。前台是冰山露出水面的部分，后台是冰山水面下的底座，底座的支撑系统才是整个产品的核心竞争力。

图6：海中冰山理论

更多的思考