偿还安全关键型汽车软件的技术债务

　　车辆已经从机械设备发展为复杂的集成技术平台，其嵌入式软件为所有主要系统提供动力，包括：发动机控制、动力总成、制动、驾驶员辅助和信息娱乐。现在，研究预测，到 2017 年，五分之四的新车将拥有互联网连接［1］。随着消费级信息娱乐软件和安全关键软件之间的界限变得模糊，这种“永远在线”的连接将带来新的挑战。

　　例如，远程信息处理系统提供车载语音控制应用程序等功能，以及与 GPS 系统交互以实现导航和交通功能。很快，车辆的 GPS 系统将不仅仅用于指示方向。随着我们进入联网和自动驾驶汽车的时代，诸如“自动 SOS”之类的功能将在这种现有的远程信息处理架构之上构建，该功能可以在发生碰撞时召唤帮助。

　　当阅读最近有关主要汽车制造商与美国国家公路交通安全管理局 （NHTSA） 达成协议将自动紧急制动 （AEB） 作为大多数汽车的标准设备的新闻时，我想到了从消费级向安全关键型转变的另一个例子。到 2021 年，AEB 系统由软件控制，这些软件为摄像头、雷达、接近传感器等提供动力，所有这些都需要完美运行，以便在驾驶员反应缓慢时安全停车。这也意味着以前用于被动驾驶辅助（例如停车）的嵌入式摄像头现在将成为安全关键系统的一部分。

　　前方无法克服的质量问题

　　大多数新软件应用程序都建立在遗留代码库之上。由于大量金钱和时间投资已投入到开发现有应用程序中，因此自然会对尽可能多地利用已经完成的工作感兴趣。

　　重用现有代码的问题在于，遗留应用程序通常背负着大量的技术债务。技术债务是系统初始设计和开发过程中走捷径的隐喻。这种“债务”通常是由于软件的持续开发而没有正确的质量控制流程造成的，通常是由于发布新版本的巨大业务压力。所产生的技术债务的累积责任最终使软件难以维护。

　　减少技术债务和提高质量的关键是重构组件（在不改变其外部行为/API 的情况下重构应用程序组件的过程），但开发人员常常因为害怕破坏现有功能而犹豫不决。重构的最大障碍之一是缺乏足够的测试来形式化应用程序的现有正确行为。

　　如果没有足够的测试，很难重构应用程序并且不会导致功能或性能的回归。根据 Gartner 的一项研究，“缺乏可重复的测试用例限制了组织以客观、可衡量的方式展示功能等效性的能力。”缺乏足够的测试最终意味着软件应用程序无法轻易修改以支持新的应用程序。特征。

　　偿还技术债务

　　基线测试，也称为特征测试，对于测试不足的遗留代码库很有用。已经部署的应用程序的开发人员不太可能返回并实现所有应该生成的低级测试。他们正确地认为部署的应用程序“运行良好”，那么他们为什么要花几个月的时间重新测试呢？

　　在这种情况下，更好的选择是使用自动测试用例生成 （ATG） 来快速提供一组基线测试，以捕获和表征现有应用程序行为。虽然这些测试不能证明正确性，但它们确实使应用程序今天所做的工作正式化，这非常强大，因为它允许验证未来的更改以确保它们不会破坏现有功能。

　　拥有一套完整的基线测试的另一个好处是可以使用基于变更的测试 （CBT） 来减少总测试周期时间。完整的应用程序测试需要一到两周的时间并不少见。使用基于更改的测试，可以在几分钟内测试小的更改。基于更改的测试计算每个代码更改所需的最小测试用例集，并仅运行这些测试。

　　因此，开发人员能够对代码进行增量更改，并确保这些更改不会破坏软件的现有行为。他们还能够做进一步的分析，如果有什么东西被打破了，如果引入了一个错误，一个实际上应该存在的功能已经被删除，或者是否有一个应该解决的错误，因为它可能有其他后果。

　　到银行进行基线测试

　　在支持物联网的世界中，大量遗留代码将进入新应用程序的关键路径。如果没有适当的软件质量方法来确保此遗留代码的完整性，系统的整体安全性可能会受到影响。

　　基线测试可以帮助减少现有代码库中的技术债务，让开发人员有信心重构和增强这些代码库，并最终让这些遗留应用程序的所有者获得更多价值。

　　审核编辑：郭婷