创建测试用例
为ECU制定测试计划和测试用例需要设计和测试团队之间密切合作。对ECU要求进行文档记述是此过程的一个关键步骤。通常，这些要求可以分为三个高级类别：安全性、功能性和性能。
安全性
在产品设计中，我们应用称为故障模式和影响分析（FMEA）的过程来定性地识别可能的故障及其对系统的整体影响。FMEA是20世纪40年代末测试军事系统的可靠性工程师开发的，并沿用至今。当识别出可能的故障时，就会详细描述故障并分配相应的概率值、严重程度值以及计算出的总体风险值（概率和严重程度的乘积）。表2显示了一个FMEA表的示例。
表2. 设计工程师创建故障模式和影响分析表作为有效的安全测试起点。 （表格由Quanser提供）
完成FMEA后，设计工程师会添加一些功能来减缓识别到的风险最大的故障。 例如，他们可以添加传感器来检测机械组件的故障，然后软件会自动将车辆切换到跛行回家模式，以防止进一步损害。 测试这些补救措施是ECU验证和确认的关键部分。如果要为每个故障设计相应的测试用例，需要设计团队提供故障树分析（FTA）。 图10显示一个FTA的例子。
图10. 在创建对安全至关重要的测试用例时，故障树分析是一个重要的参考文档。
使用FTA作为流程图，您可以为每个具有足够高风险的FMEA项目设计测试用例（“足够高”的阈值由产品管理人员设定）。考虑到一些故障的危险系数非常高，如果能在HIL仿真中对这些项目进行测试，那将是一项非常有价值的投资。
在验证安全要求时，必须确保测试准确无误，尤其是对于汽车和航空航天等必须符合功能安全标准的受管制行业。错误的验证可能导致项目在投入生产和处于安全关键状态时，产生极为不利的后果。另外，由于电子复杂性的不断增加，相同的时间内需要进行的测试增多，这就引入了自动化验证需求。但是，我们如何知道所使用的测试自动化工具是否如预期的那样正常工作？自行开发测试自动化工具的成本可能非常高，特别是在设计时需要确保工具的功能安全性。除此之外，还需要对整个验证过程进行详细且全面的文档记述。正确地创建该文档可能非常耗时，因此所使用的任何工具必须能够生成适当的工件，这使得许多人认为手动工具认证是唯一的方法。
使用在某些方面符合特定功能安全项目要求的COTS验证工具可以满足这一需求，且可让您对测试工具充满信心。 NI联盟合作伙伴CertTech针对NI测试自动化软件工具TestStand开发了一款资格鉴定包。 TestStand是一款随时可运行的测试管理软件，旨在帮助您更快地开发、执行和部署自动化测试系统。由于CertTech工程师对受监管行业和功能安全标准非常熟悉，他们很理解用户迫切需要使用符合DO-178C和ISO 26262等标准的合格工具。TestStand鉴定包全面覆盖了最常用功能的要求和测试种类，提供了验证指定要求的全套测试以及一个易于扩展的框架，因此用户可以根据需要扩展测试覆盖范围。此外，CertTech还使用工具生成了所需的文档，作为合规性的必要工件。这个文档是必不可少的，因为我们的总体目标是确保验证过程的完全透明性，以便测试可以快速地重建。 借助鉴定包，CertTech将生成该文档所需的时间缩短了95%。
一些较新的功能安全标准，如ISO 26262和DO-178C要求项目使用“合格工具”来完成一些不需要人工审核的验证和确认任务，这使得使用像TestStand这样的合格工具变得更为重要。这些标准需要您对未进行适当测试的工具的总体影响进行评估，然后判定一个TCL值，也就是ISO 26262等标准所称的工具置信度（ Tool Confidence Level，TCL）。两个主要因素决定了TCL：工具影响（TI）和工具错误检测（TD）。 TI1和TI2是TI的两个级别。当故障软件工具不可能违反安全要求时，则选择TI1。其他所有情况均选择TI2。 TD分为TD1、TD2和TD3。 TD1表示工具检测错误的置信度很高，TD2表示置信度中等，TD3表示置信度很低。测试工具的不同TCL等级意味着用户所承担的额外负担也有所不同。
表3. ISO 26262标准中的工具置信度意味着对工具进行鉴定时的工作量不同
TCL2工具对于用户的价值最大，因为任何TCL1工具不是对安全没有任何实质影响，就是已经具有高置信度，因而不需要额外的资格鉴定和文档记述。而TCL3工具置信度较低，不管如何都需要一定程度的人工资格鉴定。
功能性
从高层次来说，ECU功能的测试非常简单。我们可以简单地逐个功能进行测试；但是嵌入式软件的详细信息可以帮助发现需要严格测试的可能故障点。因此，功能测试的设计同样需要与ECU设计团队密切合作。
此外，特定ECU的特性可以与状态图相结合来指导测试用例的设计。
性能
与安全和功能测试用例不同，设计基于性能的测试却不需要与ECU设计团队协作。这些测试的开发通常从用户的角度来考虑。设计团队能接受的对于用户来说可能是无法接受的，因而这些反馈非常重要。幸好，有些用户关心的性能问题，例如每加仑英里数（MPG），可以根据联邦政府定义的测试程序直接变为测试用例。图11显示了联邦政府针对市区驾驶规定的车速随时间的变化图（FTP-75）。
图11. 联邦政府针对车辆MPG性能规定标准化测试，例如FTP-75驾驶工况。
另一种基于性能的测试是内部性能，例如总线消息时序、ECU CPU利用率或ECU事件
响应时间。这些类型的测试可能需要测试仪具有额外的功能，包括ECU校准、调试数据链路（以读取微处理器参数）和/或过程数据日志时间戳发布（以验证可接受的总线消息行为）。有关使用NI DIAdem软件进行此分析的示例，请查看 时间相关的NI VeriStand数据日志。 需求创建、可追溯性和实现
需求可追溯性的重要性
为了确保嵌入式软件和一般软件的质量，经证明在软件开发过程的所有阶段跟踪需求工件是非常重要的。典型的软件过程包括研究、定义、开发、测试和部署。通过跟踪来建立各种关系以及分析软件更改的影响是软件开发过程的常见操作，尤其是对于故障成本非常高或故障可能导致生命危险的领域。
经证明，软件项目如果缺乏足够的需求可追溯性，就会出现较多严重影响系统安全性和可靠性的缺陷。即使是微小的变化，也可能产生很大的连锁效应，导致最终产品无法完全满足项目启动时确定的所有要求。
由于监管机构出于对安全问题的考虑，以及企业不期望发生代价巨大的产品召回事件，因此两者联手，制定了大量关于需求管理的标准、最佳工程实践和软件工具。在未来的项目中，应对需求可追溯性进行硬性规定
测试自动化
在现代测试系统中，从最上层的功能到测量仪器均可自动化。这是一个复杂的过程，涉及来自不同供应商的多个工具和不同操作系统，其中一些任务可能需要在实时HIL系统上执行。因此需要尽早与工具提供商确认，以确保兼容性。测试自动化是经济高效地确保需求可追溯性的关键因素。
除了执行测试脚本来驱动虚拟汽车之外，具有前瞻性思维的组织还会使用测试自动化框架来进一步实现测试执行和自动化。借助这些框架，就可以批量运行测试，对测试数据执行后期处理和分析，并生成报告，且运行时无需任何人工交互。只需配置测试系统，测试执行就可以独立完成。测试自动化可自动将产品需求和测试用例链接到测试结果，帮助工程师更有效地进行沟通。这样就无需人工对测试数据与需求进行比较，从而提高了工作效率。
ECU测试团队的一个高级目标是开发一个提供足够测试覆盖率的测试用例库。这个库是确保ECU质量的关键因素。随着测试用例库不断扩展，测试可以设置为连夜自动运行或者在软件发生变化时自动触发运行回归测试。及时的回归测试报告可以避免最新出现的嵌入式软件错误持续数周并逐渐变得难以修复。
来源：恩艾NI
