仿真测试入门参考（15）：8000字说明仿真测试与多种开发流程的关系
“ 经常有朋友问如何学习仿真测试，于是想着把自己的一些经验和理解分享出来，希望能有所帮助。不过视野和技术有限，所说不一定对，供大家批评和参考。这是第15篇，仿真测试与多种开发流程的关系。”
自动驾驶是包括汽车、软件等多个产业的融合，汽车和软件产业发展多年，已有很多成熟的流程和方法。本文主要介绍仿真测试与汽车产业的功能安全和预期功能安全以及软件产业的软件测试和敏捷开发的关系。
1. 功能安全
系列国标《GB/T 34590 道路车辆 功能安全》（修改采用ISO 26262）中将功能安全（Functional Safety，FuSa）定义为：不存在由电气/电子系统的功能异常表现引起的危害而导致的不合理的风险。
根据这一定义，功能安全规范的对象为电气/电子系统，而不包含机械/液压等内容，功能安全只是整个车辆产品安全的一部分，而不是全部。其中提到的风险关注的是对人身健康的物理损害或者破坏，而不是对车辆或者交通设施等的损害。
本质安全的目标是确保系统中不存在可能引发风险的危险源，完全杜绝风险的发生；功能安全与本质安全不同，其不是以零风险为目标，而是通过一系列设计手段将其降低到可以接受的范围内。
GB/T 34590中为实现功能安全而进行了多方面的规范，包括：
（1）汽车安全生命周期
汽车安全生命周期包含了在概念阶段、产品开发、生产、运行、服务和报废期间的主要安全活动，对产品整个生命周期的内各个阶段都进行了规范和要求。具体的，可分为三个大的阶段：概念阶段、产品开发阶段以及生产、运行、服务和报废阶段。
概念阶段，首先通过相关项定义子阶段，明确功能安全要求研究的对象及其功能、要求和边界等内容；然后进行危害分析和风险评估子阶段，找出可能发生的危害事件，确定ASIL等级，得出为避免危害事件发生而需要满足的安全目标；最后在功能安全概念子阶段，通过安全分析由安全目标导出功能安全需求，并将其分配至系统架构，明确硬件/软件系统或组件应满足的安全需求及其ASIL等级。
产品开发阶段包括系统层面、硬件层面和软件层面三个层面。在系统层面，需要得到技术安全要求（即明确如何通过技术手段实现功能安全需求），并进行系统架构设计，并在硬件和软件层面的开发完成后进行系统集成和测试；在硬件层面和软件层面分别进行硬件和软件的开发及测试。
产品开发的三个层面的开发流程都基于V模型，V模型的左侧为设计和开发过程，右侧为集成和测试过程。软件层面的V模型如下图所示。
另外，汽车安全生命周期还对车辆生产、运行、服务和报废的计划、执行及监控流程中与功能安全相关的内容提出了具体要求。
（2）汽车安全完整性等级
汽车安全完整性等级（Automotive Safety Integrity Level，ASIL），用于描述危害事件的危害程度和定义相关项需要满足的功能安全要求的严格程度，共分为四个等级（A、B、C、D），D代表最高等级，A代表最低等级。
ASIL等级通过危害分析和风险评估得到。
首先，分析相关项的功能异常可能导致的整车层面的危害，并结合这一危害发生的运行场景得到危害事件，比如电子助力器eBooster的非预期制动会导致车辆非预期减速，这一危害发生在高速公路行驶和路口静止等红灯这两个场景时为两个不同的危害事件，其危害程度并不相同。
然后，评估危害事件的严重度、暴露概率和可控性等级。严重度S表示的是潜在的处于风险中的每个人受到的伤害情况，共分为S0~S3四个等级，S0表示无人员伤害，S3表示致命的伤害；暴露概率E表示运行场景发生的概率，共分为E0~E4五个等级，E0表示不可能发生，E4表示高概率发生；可控性C表示对人员能够充分控制危害事件以避免特定伤害的情况，共分为C0~C3四个等级，C0表示可控，C3表示难以控制。
最后，由危害事件的严重度、暴露概率和可控性等级确定其ASIL等级。具体的，可由下表得出。
ASIL等级 | D | C | B | A | QM |
S+E+C之和 | 10 | 9 | 8 | 7 | <7 |
确定ASIL等级的方法可参考《GB/Z 42285 道路车辆 电子电气系统ASIL等级确定方法指南》和《SAE J2980 ISO 26262 ASIL危害分类的注意事项》。
（3）各阶段的具体要求
提出了对功能安全管理、设计、实现、验证、确认和认可措施的具体要求，这些要求包括工作流程、建议采用的方法和交付物等，而且这些要求因ASIL等级的不同而不同。举例如下：
系统架构设计的验证，可采用检查、走查、仿真、系统原型和车辆测试以及系统架构设计分析等方法。对于走查，ASIL A的推荐等级为“++”（高度推荐），ASIL D 的推荐等级为“o”（不推荐也不对）；对于仿真，ASIL A的推荐等级为“+”（推荐），ASIL D 的推荐等级为“++”（高度推荐）。
系统集成测试中对功能安全和技术安全要求在系统层面正确执行情况可采用基于需求的测试、故障注入测试、背靠背测试等方法。对于故障注入测试，ASIL A的推荐等级为“+”，ASIL D 的推荐等级为“++”；对于背靠背测试，ASIL A 的推荐等级为“o”，ASIL D 的推荐等级为“++”。
软件架构设计可采用的标记法有自然语言、非形式记法、半形式记法和形式记法、对于半形式记法，ASIL A的推荐等级为“+”，ASIL D 的推荐等级为“++”。
嵌入式软件测试的测试环境可采用硬件在环、电子控制单元网络环境和整车环境；测试方法可采用基于需求的测试和故障注入测试。对于整车环境，ASIL A的推荐等级为“+”，ASIL D 的推荐等级为“++”；对于故障注入测试，ASIL A的推荐等级为“+”，ASIL D 的推荐等级为“++”。
（4）客户和供应商之间关系的要求
定义了客户和供应商在进行开发活动时的交互和上下游安全开发活动的依赖关系、职责分配和需要交换的工作成果。客户和供应商之间的角色和责任通过开发接口协议（DIA）定义。
（5）仿真测试与功能安全的关系
功能安全标准建议在多个测试验证阶段采用仿真测试方法，例如：系统架构设计的验证中可采用模型在环测试方法，系统集成测试中可通过模型在环和软件在环进行背靠背测试，基于需求的测试可由软件在环或硬件在环作为测试环境，嵌入式软件测试中高度推荐采用硬件在环作为的测试环境，安全确认阶段也可采用仿真测试。
仿真测试可以在V模型的不同阶段，提供符合要求的测试环境，快速配置测试场景、调整输入参数，批量运行测试并记录数据，不仅可以进行基于需求的测试，还可进行接口测试和故障注入测试，助力功能安全实现。
2. 预期功能安全
标准ISO 21448中将预期功能安全（Safety of The Intended Functionality，SOTIF）定义为：不存在由预期功能或其实现的不足引起的危害而导致不合理的风险。
功能安全主要针对系统性失效和随机硬件失效引起的危害，重点关注的是功能的失效；而预期功能安全主要针对非故障情况下、功能或其实现的不足而引起的危害，主要解决自身设计不足或者性能局限在一定的触发条件下导致的整车行为危害。
（1）SOTIF活动的目标
按照是否已知和是否安全，可将所用场景分为四个区域：已知安全（区域1）、已知不安全（区域2）、未知不安全（区域3）、未知安全（区域4），如下图所示：
SOTIF活动的目标是评估区域2和区域3中的潜在危险，并证明这两个区域中的场景造成的残余风险足够低，以此通过最小化区域2和区域3来最大化区域1。在开发初期，区域2和区域3的占比较高，通过SOTIF活动对已知场景进行评估、发现系统不足并改善设计，将部分场景从区域2移至为区域1，并证明区域2的残余风险足够低；对于区域3，通过真实场景、随机场景等方法，发现系统设计不足，将部分场景从区域3移至区域2，并基于统计结果，间接证明区域3的风险控制到合理可接受水平；区域4中的场景不构成危害风险，区域4中的场景被发现后将其移至区域1；整个过程中要最大化或者维护区域1，使其安全性得到提升或者保留。
（2）SOTIF危害事件因果模型
SOTIF分析时的危害事件因果关系模型如下图所示：
功能不足包括规范定义不足和性能局限两个方面：规范定义不足指系统规范定义不完整或者偏差，如自适应巡航系统（Adaptive Cruise Control，ACC）未考虑对卡车的识别，这会造成前方车辆为卡车时的危险行为；性能局限指由于硬件或者软件的限制，系统不能发挥理想的能力，如摄像头难以在低光照条件下有效感知外界信息，决策算法耗时较长而难以处理突发场景。
功能不足在一定的触发条件下会引发危害行为，进而引发整车级危害，如夜晚的道路上光线较暗（触发条件），仅采用摄像头作为传感器的自动紧急制动系统（Autonomous Emergency Braking，AEB）可能将路灯造成的阴影错误识别为障碍车，进而实施紧急制动的危险行为，这会引发被后车碰撞的危害。
整车级危害会在一定的场景下成为危害事件，若危害事件不能进行很好的控制从而避免危险，则可能会造成对人员的伤害。如自车非预期的紧急制动，在后方较近距离有后车跟随的场景下，若自车驾驶员不能迅速加速或者后车驾驶员不能及时减速（可控性不足），就会引发后车对自车追尾碰撞，造成两车成员伤亡。
（3）SOTIF基本流程
为实现最小化区域2和区域3的目标，根据SOTIF的危害事件因果模型，需要识别触发条件和功能不足并分析其可能造成的风险，根据风险程度完善功能设计，并进行验证。具体的流程如下图所示：
SOTIF成果评估阶段，对 SOTIF 活动产生的工作成果的完整性、正确性和一致性进行评审，给出并确认发布建议，包括“接受”、“有条件接受”或“拒绝”SOTIF发布的建议。通过SOTIF成果评估后进入运行阶段，定义并执行现场监控流程，保证运行期间SOTIF的实现。
（4）仿真测试与预期功能安全的关系
在已知场景的评估阶段，对感知、规划、执行的验证和系统集成验证都建议对选定的SOTIF相关用例和场景，结合已识别的触发条件采用MIL/SIL/HIL等仿真手段进行测试，并可采用仿真手段进行错误注入来模拟潜在的功能不足或触发条件。
在未知场景评估阶段可采用仿真测试方法实现随机输入测试、极端场景和边缘场景的测试、随机场景集 合测试、相关参数的分析和测试。
仿真测试测试效率高、资源消耗低和可重复性好的优点，不仅可以快速的进行已知场景的测试，还可以快速生成随机场景和边缘场景并对相关参数变化带来的效果进行快速评估，提高对未知场景的信心。另外，VeHIL、VIL和DIL等仿真手段将真实驾驶员置于整车环境操作，从而可实现对合理可预见的误用的测试。
3. 软件测试
（1）什么是软件测试
根据朱少民老师在《软件测试方法和技术》中所述，软件测试包含正反两个方面的认知。正向思维是：测试以验证软件是工作的为目的，用来验证软件符合需求定义和软件设计的程度。逆向思维是：测试是不能穷尽的，即使大量的测试只是一个样本实验，不能证明软件是正确的，只能说明发现的缺陷确实存在，而且正向思维不利于发现软件错误。
应当结合使用正向思维和逆向思维，实现效率和质量的平衡：需要效率、降低软件开发成本、加快软件发布速度时，更多采用逆向思维，尽快发现存在的缺陷；需要测试广度和高软件质量时，更多采用正向思维，尽可能进行全面的验证。
广义的软件测试不仅包括运行程序而进行的动态测试，还包括不运行程序而进行的需求评审、设计评审和代码评审等静态测试工作。通过静态测试，可以尽可能在软件开发的早期发现潜在的问题，降低修复缺陷的成本，提高软件质量。
（2）软件测试的分类
按照不同的视角可以将软件测试分为不同的类别，通过不同的分类方式可以对软件测试有更充分的理解。
a）按照测试方法或者测试方式分类
根据测试时软件是否被运行，可分为动态测试和静态测试：动态测试是通过查看软件运行时的表现进行测试；静态测试不运行软件，包括需求评审、设计评审、代码评审和代码分析等内容。
根据是否针对系统内部结构和具体算法进行测试，可分为白盒测试和黑盒测试：白盒测试也称为结构化测试或逻辑驱动测试，在已知系统内部工作过程和代码实现的情况下，对软件内部实现进行测试；黑盒测试也称为数据驱动测试或者基于需求规格的测试，把被测对象看成一个整体，测试软件是否按照需求规格正常工作。
按照是否由软件工具完成测试工作，可分为手工测试和自动化测试：手工测试由测试人员手工进行，自动化测试通过测试工具或测试脚本自动完成。
b）按照测试目的或者测试类型分类
可分为功能测试、性能测试、安全性测试、兼容性测试、可靠性测试、易用性测试和回归测试等，其中：
功能测试：验证每个功能是否按照预期工作。
性能测试：对系统在不同负载和工况下的运行情况和性能指标进行评测，如内存占用、CPU使用率、计算耗时等。
可靠性测试：验证系统能否长期、稳定、正常运行。
回归测试：在软件修改后，对可能影响到的原来正常的功能进行测试，以确保原有正常功能不产生新的问题。
c）按照测试层次分类
这其实也是按照软件测试的不同阶段进行分类，可分为单元测试、集成测试、系统测试和验收测试：
单元测试：在编码阶段，对软件的基本组成单元（类、函数、模块或组件）进行测试，验证软件单元是否实现了预期的功能。单元测试一般由编程人员完成。
集成测试：将通过单元测试的软件单元集成起来进行的测试，主要关注不同单元之间的接口是否存在问题。集成测试时一般采用渐增式集成方式，逐渐加入单元进行测试，直至所有单元被集成到一起。
系统测试：对集成测试完成的完整系统进行测试，包括功能测试和非功能测试。功能测试不考虑软件内部结构和实现方式，主要关注软件是否能够按照需求规格说明书正常操作和工作。非功能测试包括性能测试、安全性测试、兼容性测试和可靠性测试等。
验收测试：用于验证软件是否满足客户的各项要求，又称交付测试，一般在实际的用户环境运行，由用户参与共同完成。
（3）仿真测试与软件测试的关系
自动驾驶软件是自动驾驶系统的重要组成部分，仿真测试是对自动驾驶软件进行测试的一种有效的方法。
对照前述的测试分类，仿真测试时需要运行被测软件，是动态测试；不关注软件内部结构，主要关注软件在预期输入下的输出表现，是黑盒测试；可手工测试，也可进行自动化测试；可在实验室环境提供自动驾驶系统的运行环境，目前主要进行功能测试和回归测试，也可进行性能测试、可靠性测试、安全性测试和兼容性测试等非功能测试；被测对象是完整的自动驾驶系统或者大的软件模块，主要是系统测试，也可提供集成测试的运行环境和进行部分验收测试。
4.敏捷开发
上一节主要描述的是传统开发模式下的软件测试，在软件定义汽车迅猛发展的当下，敏捷开发模式受到愈来愈多的关注和应用，有必要对敏捷开发进行下介绍。
（1）敏捷软件开发宣言
敏捷开发通过不断收集开发过程中产生的开发耗时等数据，动态地调整开发范围，来实现务实的项目管理。
（2）极限编程实践
根据罗伯特·C·马丁所著的《敏捷整洁之道——回归本源》中所述，极限编程（eXtreme Programming, XP）是多种敏捷方法中定义最好、最完整和最不混乱的。其包括三个方面的实践：
a）业务实践，为软件开发团队与业务沟通的方式以及业务和开发团队管理项目的原则提供了框架，包括计划游戏、小步发布、验收测试和完整团队。
计划游戏告诉我们如何将项目分解和完成，具体过程是：①将项目目标转换为多个用户故事（从用户角度对系统功能的简短描述），并为每个故事估算点数（工作量）；②设定第一次迭代可完成的总故事点数，并选择高价值低成本的故事作为这次迭代中要完成的；③迭代中期节点前应编写完所有验收测试并自动化；④迭代的中期检查，将下半期的点数目标调整为上半期已完成的点数，并调整故事（可能增加或减少）；⑤迭代结束进行演示，展示功能的所有验收测试和单元测试都正常运行。注意：通过验收测试的故事才算是完成，因而一个故事中的任务实现了一部分不算完成，不计算点数。
小步发布建议开发团队应尽可能频繁地发布软件，实现持续交付。
验收测试通过业务方编写形式化的测试来描述每个用户故事的行为，QA负责将这些测试自动化，而这些测试由开发人员运行并通过。
完整团队是说开发人员、测试人员、管理人员等所有人是一个朝同一个目标前进的整体，而且物理距离越短，交流就越好，开发就越快、越准确。
b）团队实践，提供了开发团队内进行沟通和管理的框架和原则，包括隐喻、可持续节奏、代码集体所有和持续集成。
隐喻是为了有效地进行沟通，团队内部的受限制的、有纪律的词汇表，其中包含项目中的术语与概念，这个词汇表不一定是专业词汇，可以用生动形象的词汇代替。隐喻是整个项目各个阶段、所有人员使用的统一语言。
项目过程中要保持可持续的稳定输出节奏，加班、熬夜不是好的方式。
敏捷项目的代码由团队集体所有，任何团队成员可以随时检出代码，并改善项目中的任意模块。开发人员可以有所专长，但同时也必须是通才，保持在专长领域外的工作能力。代码集体所有使知识分散在团队中，极大提高了团队沟通和决策的能力。
持续集成，并持续构建（包含验收测试和单元测试），频繁地进行反馈闭环，了解开发进展。
c）技术实践，用以指导和约束程序员，来确保最高的技术质量，包括测试驱动开发、重构、简单设计和结对编程。
测试驱动开发的三规则：①先编写一个需要通过的测试，然后才能开发编写生产代码；②只允许编写一个刚好未通过的测试；③只允许编写一个刚好能使当前失败测试通过的生产代码。通过按照三规则进行测试代码和生产代码的快速切换（可能几秒钟），推进开发过程。遵守三规则可以带来很多好处：更少的调试、高质量的详细文档、有趣、完备的测试、解耦，更重要的是测试驱动开发可以给你修改老旧代码的勇气，因为具有完备的测试套件，可以随时查看修改的结果。
重构是一个持续的过程，而不是定期执行的过程，也不会作为一个故事出现在项目计划中。在测试驱动开发三规则的基础上再结合重构过程，就成为“红-绿-重构”循环：①创建一个未通过的测试（红）；②聚焦于以粗劣的想法草草地使代码工作起来，测试通过（绿）；③清理代码（重构）；④下一个循环。
简单设计的意思是：仅编写必要的代码，使得程序结构保持最简单、最小和最富表现力。简单设计的目标是，只要有可能，尽量降低代码的设计复杂度和认知负担。
结对编程是两个人共同解决一个编程问题，结对时间通常短暂（常见的是不超过一两个小时，甚至30分钟）、结对伙伴不固定、角色不固定。结对编程有助于知识在团队中的传播。
（3）仿真测试与敏捷开发的关系
测试驱动开发思想是敏捷开发的核心，每次迭代后用户故事的完成情况需要验收测试来评估，持续集成和重构也依赖于良好自动运行的测试。
仿真测试方法可以为自动驾驶算法的敏捷开发提供自动测试和自动评价，并用于持续集成，保障开发过程的进行。
