ADAS软件系统测试入门指南

发表于:2023-5-05 09:23

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:L5传教士    来源:CSDN

  前言
  自动驾驶系统测试新手入门必须了解的职责、测试流程、测试用例设计方法、测试内容及关注点。
  提示:以下是本篇文章正文内容,下面案例可供参考。
  一、概述
  1.角色
  测试人员:负责测试用例设计,测试执行,登录和验证Bug
  测试负责人:负责对测试人员登录的Bug进行确认,以及对Bug进行统计分析和评价,评审测试用例。
  PSM:参与测试用例评审,跟踪Bug状态。
  开发人员:参与测试用例评审,修改Bug。
  2.入口标准
  集成冒烟测试结束,软件系统测试启动。
  3.输入
  软件功能式样书及引用附件,附件包含但不限于:
  1)诊断调查表
  2)网络管理规范
  3)CAN信号矩阵
  4)Coding规范
  5)标定流程
  6)升级流程
  法规&标准(JT/T、GB、GB/T、ISO)
  4.输出
  ·软件系统测试用例
  · 软件系统测试报告
  · BUGlist
  5.出口标准
  · 软件系统测试活动结束
  · 测试用例执行覆盖率100%
  · 系统BUG数为0
  二、测试过程
  1.总览
  测试流程总体如下:
  2.需求分析
  依据规格人员提供的《软件功能式样书》,确定软件实现的功能,识别软件测试点。在需求分析的过程中,如果有不理解的功能点,应第一时间与规格人员沟通反馈,明晰测试需求。理解功能需求是编写有效测试用例的前提。
  3.制定测试策略
  根据《软件功能式样书》及版本Release Note评估测试工作量,决定采用的测试方法和测试范围。在满足按时交付和保证质量要求的前提下,合理安排测试所需的人员及测试周期。
  1)确定被测试对象和测试范围
  2)评估测试工作量
  3)确定角色分工和工作任务
  4)标识出测试各阶段的时间,任务,约束等条件
  5)考虑一定的风险分析及应急计划
  6)考虑和准备测试工具,协调测试仪器等测试资源,搭建测试环境
  7)定义测试完成标准
  4.测试用例编写
  根据《软件功能式样书》及引用附件,设计测试用例。
  5.测试用例评审
  测试人员完成用例编写后,需组织测试用例评审,参与评审的人员至少应包括测试负责人、开发人员及PSM。评审的形式可以是邮件评审,也可以是会议评审。评审人根据《软件功能式样书》及引用附件,结合以往项目的测试经验,对编写完成的测试用例进行评审,同时被评审人应记录汇总评审意见,生成测试用例评审记录表。
  6.测试用例修改
  评审测试用例如果出现错误或者测试用例不全以及式样变更要对原有测试用例进行修改和添加。测试执行中发现BUG后,开发人员修改BUG,程序的逻辑、结构等可能会影响之前测试用例时,需要根据当前版本程序,修改受影响的测试用例,满足当前程序测试的需求,并在测试用例文档的变更履历中简述修改内容。
  7.测试用例执行
  测试人员执行手动或自动化测试用例,对被测控制器进行验证。
  8.提交BUG
  发现程序中的BUG后,登录Bug管理工具,对BUG问题进行描述,选择测试负责人提交BUG。
  9.输出成果物
  完成测试后,将测试用例、测试报告等相关资料,上传至服务器,并通过邮件通知项目所有成员。
  10.漏出BUG分析
  项目测试过程中,不可避免地会漏出个别BUG到客户侧。对于这类问题,应给予充分的重视。在问题发生后,应及时地进行详尽的复盘总结,分析BUG漏出的原因,制定再发防止策略,并延展到其他项目上,形成问题分析报告。
  三、测试用例设计方法
  设计测试用例的主要依据是软件功能式样书、诊断调查表、标定规范及CAN信号矩阵 。另外,国标和平台测试用例也是在设计测试用例时的重要输入。在设计测试用例时,会按照式样书中规定的功能类型来划分用例的功能分类,再运用常用的测试用例设计方法和以往测试的经验来详细设计每条用例;常用的测试用例设计方法如下:
  1.文档转化法
  将式样书中所有的文字信息、示意图、流程图、状态图,所有项目需求达成的共识,以及需求确认的邮件沟通信息,直接转成测试用例。
  2.等价类划分
  将被测项按照式样书的条件项划分为若干个等价类,从等价类中选出一个测试用例,如果这个测试用例测试通过,则认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的功能覆盖,解决了不能穷举测试的问题。
  例如在CANmini信号验证测试中,用例不能覆盖信号所有的值,所以需将信号的值划分为几个等价类,来覆盖信号的取值区域。
  3.边界值法
  在测试取值类型为数值型的测试项时,若输入文档规定了取值范围,则选择恰好落在取值范围边界上和处在边界内、边界外的测试值来设计测试用例。
  式样书中描述:“若自车车速达到启动车速,则系统进入ready状态,启动车速为60km/h”
  1)车速从0加速到59,状态机为passive
  2)车速从59加速到60,状态机为ready
  3)车速从60减速到55,状态机为ready
  4)速度从60减速到54,状态机为passive
  4.场景设计法
  在设计实验室测试用例时,会在用例中设计通过模拟工具和硬件设施来模拟事件触发时的情景,使测试用例更容易理解、更具说服性,最大的降低因实验室环境的不全面导致的用例设计错误。
  例如:在版本稳定性验证的测试中,由于资源有限,不能使控制器在实车上长时间持续运行,需要在实验室使用实车版本的控制器,使摄像头对准实车录制的视频或可导致功能触发的静态图片进行验证。这样能在实验室尽可能的模拟控制器在实车场景中的运行状态。
  5.错误推断法
  根据以往的测试经验,在被测系统中容易出现Bug的功能点上有针对性地编写对于这些Bug的测试用例。
  例如在DTC测试中,以往测试时平台配置这部分容易出现问题,所以在设计用例时会分别添加配置自动挡和手动挡丢失部分信号而产生的不同结果。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号