解读汽车软件测试之“软件需求测试”

2024-05-26 19:05:54·  来源:水轻言  
 

1  概述


软件需求测试是汽车软件测试的第四级别。在此阶段之后,通常可以将软件交由验收团队或交付团队进行系统级测试。


测试目标:确保对集成的软件进行测试,以证明其符合软件需求。


测试依据:测试用例来源于软件需求,而表现形式可能是一份独立的软件需求说明书,也可能是在系统级需求或设计里做了软件标识的部分。


测试对象:运行在MCU或SOC上的集成软件。


测试设计:测试用例的设计可以选择如下方法,等价类划分(将输入数据划分为若干个等价类,从每个等价类中选取代表性的数据进行测试,以缩减测试用例)、边界值分析(重点关注输入值的边界条件,因为在这些边界附近,程序更容易出错)、决策表(用于描述在不同条件下的系统行为,帮助测试人员理解并测试复杂的逻辑条件)、状态转换测试(关注系统在不同状态之间的转换,确保系统在状态转换时能够正确工作)、错误猜测(基于测试人员的经验和直觉,猜测可能的错误并设计相应的测试用例)、负面测试(在某些情况下,测试人员需要考虑负面测试,即测试系统在不满足正常工作条件时的行为,如故障注入)。


测试环境:汽车软件开发中,我们常希望得到状态比较好的硬件,甚至实车环境,但软件需求测试并不追求于此,而且要尽量保证测试不受硬件的影响,因为要从理论逻辑层面保证软件需求被落实。比如,Matlab中基于模型的MIL测试环境、基于台架或虚拟ECU的SIL测试环境。当然,有时PC中无法模拟某些ECU或传感器,也只能使用真实硬件。


进入标准:完成必要的前序测试(如冒烟)且无重大问题、相关的测试设备(如线束、ECU、CANoe硬件)就位、已review并发布的软件需求测试用例与计划。


退出标准:已执行对应的测试用例、测试报告已完成、缺陷已录入工具链。除了常规的退出外,出于成本的考虑,还会有测试中止,比如,基本功能确认失效、发现的缺陷会影响其他功能测试结果有效性、对于发现的缺陷被修复后需重新测试的范围,或者在测试过程中,得知新的软硬件即将释放,也应综合评估后中止。


负责角色:软件测试人员。


2  测试用例选择


完整的软件需求测试会消耗大量的时间和资源,所以,我们需要在用例选择上做一个平衡,不全测,或者不是每次交付全测。一般有如下关注点。


产品风险大小:对于功能安全等级较高或者涉及到法律法规认证等高风险软件,通常,需要投入更多的资源在影响分析与测试量上,这是一个理所当然的决定。


不同配置下的功能是否适用:这需要我们有一个清晰的feature list或配置表,不适用的功能自然不需要测试。


功能是否实现:即便本配置有该功能,功能的成熟度也得达到可测水平。


变更的范围:结合接口文档、模型、追溯关系等,对软件组件自身的变更及其对未变更组件的影响进行评估,并进一步确认测试范围。有时,软件外部的系统环境或者车辆的变更都会影响到测试用例的选择。


历史测试状态:旧的版本、相近配置、相近分支或者平台主线的测试结果可能可以被当前软件沿用。一般在这里,也是基于变更来评估。


持续集成:为了确保基础功能没问题,我们可以设定一些关键的必测项,也就是不管什么修改,都至少运行这一套用例。结合自动化测试脚本,可以将其部署在持续集成流水线中。


全量测试:Delta测试很必要,但全量测试也不应舍弃,我们可以根据产品和项目特点制定一些执行全量测试的规则,比如,一年至少一次、切换分支基线后至少一次、发布D样件之前至少测试一次、软件上路试车前至少一次、发布10版软件后至少一次等。


3  双向可追溯性和一致性


所有软件级别的可测试需求必须至少被一个测试用例覆盖。


而为了检查测试覆盖率,必须能够通过工具实现测试报告、测试规范与相应需求之间的可追溯性,比较典型的是建立链接。




如果要发布的软件版本的测试覆盖率不完整,测试团队应向项目经理或客户汇报,并记录偏差原因和进行风险评估。


一致性呢,一般也只能通过评审来尽量保证。比如,软件测试人员应该参与软件需求的评审,而软件需求开发人员则参与软件测试的测试用例评审。


4  全文小结


本文首先从目标、对象、环境、进入/退出标准等方面概述了软件需求测试的基本概念和要求。

由于完整的软件需求测试会耗费大量的成本,如何选择测试用例进行Delta测试就是一个重要的课题,所以第二部分对此进行了介绍。

汽车软件开发中,一般至少应在这个层级及以上关注追溯。这也是本文最后一部分的内容。


5  写在最后


通常,处于软件开发末端的软件需求测试,承担了不该承担的拦截问题和保证交付的主要压力,让我们向他们致以歉意。




分享到:
 
反对 0 举报 0 收藏 0 评论 0
沪ICP备11026917号-25