【直播回顾】深度分享 | 北汽新能源黄颍华《汽车软件测试的发展和展望》
发表日期：2022-04-15被浏览： 1396次返回
编者按
iSQE于2022年推出了一个全新的对话系列直播，聚焦不同行业，邀请不同行业的优秀人才给大家分享技术热点，在分享结束后采取了一对一访谈的形式进行直播交流。首播聚焦于汽车行业并已于3月31日圆满落幕，邀请到了北汽新能源三电中心电控测试部黄颍华老师，对汽车行业的软件测试的发展进行了深度分享，其从汽车软件测试的背景、ISTQB与极狐汽车的结合点，在极狐汽车的落地、自动化与低代码以及可见的未来等四个方面进行了分享，以下是黄颍华老师演讲的文字版内容。
嘉宾按
大家晚上好！下面就由我来给大家介绍汽车软件测试的发展与展望，这一部分的内容也是结合我多年的经验、对汽车软件测试的实际感触以及我们的一些成果内容给大家做一些分享，一共分为四个部分。
一、汽车软件测试印象
1、从时间方面看
首先我们来讲汽车软件的测试印象。介绍汽车软件测试的一个发展过程。从2007年左右，新能源汽车属于刚开始自研的一个状态。真正的一个自研其实应该可以追溯到2001年左右，但是那个时候还没有产品。直到2007年左右开始研发出了产品。那时的市场规模级别是数十台左右的试运行车辆，而且用户的反馈吐槽比较多，质量也不好，我也调研过甚至有些用户是直接就放弃了，直接把新能源的零部件给拆了。基于此，其实当时的一个计算软件的系统质量的话是并不高的。
同时还有一些研发机构也在做改制，把燃油车改成CNG。当时在改制过程当中，用的软件也是simulink。从软件测试理论上来说，应该是有这种需求的。但是当时实际的一个情况是，那个车辆本身有一个背景是以油车为主。油车的测试当时就是供应商去实施，整个软件的算法是很稳定的。它主要是围绕功率、排放和油耗，它有一些燃烧模型体体系，几种燃烧模型也有很多套路。基本上一套发动机的软件会像搭积木一样给你搭起来，然后标定完成软件发布。
当时中国汽车行业软件的测试需求就是这么一个背景，当然，结果是不好。当时市场上用户虽然说反馈不好。但是企业也不是以此作为一个利润点。当时实际的情况也很艰难，很多团队的话，最多也就是两到三个人。基本上是能够让测试设备运行起来就已经是很不错了。如果能够在一个月以内，把现在的所谓的硬件闭环的环境调通，就是顶级的选手了。然后当时我们的一个感受是，我们花了一个月基于之前的一些需求把闭环的环境做好，但是那个时候别人在动力总成台架上基本已经调试的差不多了。动力总层也是调试以开发为主。当时我们构建出来这个抬架之后就是用来给开发持续再去做调试。虽然有做一些这种测试，但是事实上不叫测试，其实还是在实施一些和开发协同的调试工作。而且当时的文档情况是，经常都是信号找不到、接口指向不明。当然也会带来理解性的偏差。开发和测试术语上是根本对不上的。这就是当时的一个情况。
2010年左右，基本上各个OEM开始开发一些三电控制器。这个时候的软件开发基本上还是集中在新能源。后续的一些内容上也都是集中在新能源。
为什么会有这些背景的介绍，大家要理解一个事情，汽车软件测试和软件测试是一样的。它是基于一些市场的需要才会被提起、才会被要求。因此我们得知道它的背景。否则你是没有办法去开展软件测试这个活动。
在当时，三电这一块的软件，基本上就开始做了。但是当时客户群体，主要还是以大客户的一些订单为主。虽然有一些问题，但是会通过一些公关的方式被掩埋下去，没有特别大量的爆发出来。在这个阶段，一些国外的标准已经开始被引入。功能安全标准其实在很早前就、已经引入过来了，只是很多主机厂可能当时没有用。然后各类的一些控制方法，还有一些这种新能源方面的应用，在实践的过程中，逐渐被推导出来了。比如：预充，当时最开始的时候，我们一上电，啪，就把电容给整爆了。后来才知道，需要先有一个预充。还有均衡、能量管理、扭曲管理，都逐渐被推导出来。有一些是借鉴的，比如：扭曲管理，由于当时属于功能开发的内容越来越多，当时分了一部分人出来去做测试，这个时候的测试实施，基本上有一些是开发人员。如果说大家听过ISTQB，从我叙述的这个过程，你就应该有所感触。因为它这么一个发展过程，在ISTQB大纲里面也是这么一个过程。
当时MIL、SIL、HIL，在各个公司就开始去运用了，每个公司用的不一样。尤其是HIL测试这一块很多公司都开始采购了。但是由于当时的软件使用的一些瓶颈很多公司用不起来。当时我们统计过，从HIL建模到最后出结果，要打开十多个软件，还有独立的一些小应用。要打开一大堆东西，记很多事情。就导致当时很多东西用不起来。这个时候测试参与人员还是比较有限。虽然软件的需求和功能越来越多了，但是市场化的一些质量反馈因为有的被公关给掩埋下去了，所以企业还没有感觉到疼痛。因此这个时候还是没有很多独立的测试团队。只是会有一些人去开展这个工作。这些就是在那个阶段的一个情况。
另外在那个阶段，汽车软件测试本身已经发展成了一项业务。测试人员也会内卷，他想把业务干好就会不断地思考。当时因为软件的各种不便在这么一个背景下，基于API的一些二次开发就往前走了。
2015年左右，三电算法，基本上开始井喷。功能安全的内容，引发的一系列落地。冗余、两套算法、同时保障、还有AUTOSAR架构。本身标准的一个架构，在汽车开发软件上的一些落地。我个人认为，此时的市场需求还是属于是被产品定义的，因为当时新能源汽车主要的瓶颈还是集中在三电上。因此，大家都在主攻这一块的内容，但是在这个阶段已经有一些个人用户开始使用新能源汽车了，并且此时各个主机厂都逐渐开始发力。在这个阶段测试已经明确地作为研发流程当中的一个固定内容被支持。
在我们的ISTQB大纲里面其实也有被提及，测试需要被质量保障的一些活动，整个流程所支持。在ISTQB的第一章里面就提到“测试是质量保障的一个手段之一，它可以被质量保障所支持”。在那个阶段基本上就作为一个固定的内容被支持了。用于知识测试的文档基本上也变成了一个固化的内容，有一些协议文档，比如：当时像电子电器架构图、协议文档，我们在2010年的左右的时候找开发去要都不会给我们，很难拿得到。在这个阶段测试任务开始急速增长了。自动化这一块，就被大量地考虑，但是在这个阶段的自动化部分，还是缺少对测试的一个整体思考。并没有去考虑自动化在快速迭代的时候，可能并不是解决效率的一个好方法。
在这个阶段，基本上各个企业都把测试引入到了一个业务流程当中，包括对于测试设计的一些要求、过程的要求、以及测试术语的统一。
2018年左右，车联网和智能驾驶，人车互动的一些相关功能开始井喷。搭载的传感器数量和种类都越来越多，基本上这就是属于是在这个阶段的一些变化。
这两年大家应该都有所感触，做软件测试需要了解的内容越来越多，而且越来越新。包括OTA，SOA。而且新能源汽车在这一个阶段开始被逐渐接受。由于企业能够感受到，个人用户对质量软件的重点关注，并且在互联网上，各种事件也被快速地曝光，所以各个企业对测试的一个需求也就逐渐加大。在这个阶段，基本上各个公司的独立测试团队就开始形成。
独立的业务团队在各种的软件测试框架下，为了逐渐提升测试业务,他们开始搜集各类的测试过程数据，逐渐开始做自己的测试平台。在这个阶段，也在逐地构建测试团队，除了做测试报告之外，很多团队都会对一个项目的整体数据去做业务分析。在当时是为了应对各种不同的一些接口。比如：手机APP、云端、网端。很多的工具就被引入到这个行业当中去。
而且这个阶段，语音这一块的功能被开发出来，针对大数据的一些软件测试方法也被不断地提出。测试自动化这一块，基本上是非常广泛的一个要求。以上就是我们整个的汽车软件测试发展的背景。
总体而言，根据历史过往我们可以看见，软件测试的需求以及各种技术的发展，本质上还是来源于市场的需要。市场运行软件数量的持续增加，使用软件客户对不可靠软件的一个接受程度也是在逐渐降低。这些都会促使我们测试发展、促使企业对测试的需求。
我们也要清楚一点，软件测试不是唯一的保障手段！为什么要明确这个内容？其实整个测试活动的质量保障过程当中，你是要去和开发协同的。测试不是唯一的一个手段。比如像我们公司，北汽的测试团队，经常会帮开发，开发一些工具。有的时候我们会发现，可能他工具化程度高一点，后面测试的业务量也会少一点。他不是唯一的手段，开发的工具化、还有一些平台化，还有比如我们前面需求做得好一点，各种各样的手段。都是可以提升质量的一些手段，不是唯一的。但是随着软件测试越来越复杂、技术运用越来越广，这些都会使汽车软件测试的人员的要求，开始爆发式的增长。从我们刚才对以往历史的分析就可以看到。但是面对同一个问题时，解决方法不是唯一的，不是只有人的提升，才是解决问题的方法，即使我们不提升，市场也会逐渐地衍生出它自己的解决方法。
2、从数据方面看
接下来我们从实际的数据去看一下汽车软件测试的变化情况。
OTA的数据：这个内容并不是一个全新的技术。我2017年买了一辆汽车,这么多年以来一直都会给我发短信，不断推送要给你做什么什么升级，诸如此类。其实OTA并不是一个很新的技术。它的这种被要求有个更深层次的背景是新能源汽车的一个软件的快速发展，所以我们不能固定的去看OTA。
另外就是我们作为测试必须得去了解开发的一个发展和这个功能，它本身的市场背景。否则你不知道怎么去制定测试方案，这也是一个比较重要的内容。我收集的前面蓝色的柱状图，是某三家销量比较高的车型OTA的次数的一个情况。我们公司的极狐汽车前也完成了八次，现在基本上每年都会有持续OTA的计划。OTA也不排除有的企业是为了修复软件bug，目前来看OTA还是给车主带来的词汇内容是比较多的，而且OTA在整个测试过程当中，不是单纯的车端功能测试，基本上在整个测试过程当中，我们是针对，整个OTA活动的整个过程在实施测试。它可能在很多地方引入问题，这也是在我们ISTQB里面提到的“问题的引入，我们要去找根因”其实你找到根因之后，在哪些阶段去做测试，也是面对这种新技术的时候，我到底该如何去做测试的一个求解方法。从根因的角度去分析，并随着OTA的逐渐常态化，我们也可以感受到，未来汽车的软件测试可能会一直持续到汽车的停产。不会因为量产之后测试团队就被消除掉，比如像很多很多游戏测试在上线之后，测试团队先就被消除，留下运维。
举例：这张图是某公司BMS的一个软件代码的一个行数，我也有一个大概的数据。我们可以看到它的一些代码行数，还有文档和测试用例的数量。基本上是每三年都翻了一翻。它的复杂程度、功能数都在激增，这也和我们前面说到的历史数据基本吻合。这些都是客观数据。另外，从这个独立的测试团队上来说，测试团队的一个数量经过十年的发展。从完全没有一个测试团队，从公司都没有独立的测试团队，到目前为止我看到的有一定规模的主机厂，基本上都有自己的独立软件测试团队。
ISTQB认证人数上来看，2017年左右汽车行业的认证人数大概在100人左右；2018年是140左右；到了2021年，我们可以看到这个增长非常的吓人，这几年真的增长非常快，基本上是到了1300多人。从方方面面的数据和过往的一些事情，都在告诉我们汽车软件的测试离不开整个市场的需求。因此软件测试团队的一个使命应该是与市场、与企业的诉求相结合。不能抛开这个东西去谈测试技术。
二、ISTQB与极狐汽车
接下来我来给大家介绍一下ISTQB在我们极狐品牌汽车当中的落地。大家可能好多人都做过ISTQB的培训。像我们的这种知识体系，它肯定是普适性的，因为它面向的是全行业，它的内容其实是非常有用的。
下面我会给大家讲述我们是怎么去落地的。首先你必须得在工作当中时刻带着知识内容去思考，去重构你的业务。否则，第一它没办法落地，第二可能你的业务发展也没有头绪。
01介绍极狐背景
2015年我们公司完成了测试的一个自动化执行工具的开发并投入了使用。我们当时非常明确如何去实施自动化。我个人认为，其实相对来说是比较容易实现的。但是有一个问题是经过我们在整个研发活动当中的一系列测试之后。我们的汽车软件能否正常运行？能否减少公司对软件质量的一个焦虑？我们当时是回答不了这个问题，我们是缺少头绪的。
2010年左右我就接触和了解过ISTQB，看过一些内容。因此当时我在2015年底的时候，就因为遇到的上述的这些问题，我就开始去请教ISTQB的资深专家，崔老师和周老师，就开始引入ISTQB。经过数年的一个转换，我们也将成果运用到了我们的极狐阿尔法T以及极狐阿尔法S的一些测试上。通过我们对以往的测试执行数据的统计，计算出累计完成了12万公里9000小时的一个控制器的测试。我们对我们的测试数据在一定约束条件下进行一个统计分析，抛开控制器的硬件差异来说，软件对于每个用户生产质量基本上是一致的。因此我们可以认为每辆用户车上的软件均经过了12万公里的一个测试，并且这种测试工况不同于以往用户行驶12公里，我们的12万公里，重复程度会比较少一点。
02 ISTQB在极狐中的落地
我们从ISTQB的第一章内容开始讲。我们也不能够完全展开，因为整个ISTQB大纲要讲1到两天才能讲完。所以我们选其中的一些内容来讲。
首先ISTQB第一章的内容，告诉我们。“不同的一些测试级别，我们要制定不同的测试目标。”如果大家学过ISTQB应该有这个印象。在各个级别应该要发现不同的软件问题，那我们怎么去落地呢？当时，其实我们是制定的开发做单元测试，他有他自己的一些要求：要做覆盖、要做一些接口覆盖，还有代码的覆盖。然后我们有一些测试团队去实施部件的集成测试和实车测试。
我们在不同的阶段也制定了一些不同的要求。比如：我是你的下游，我在测试过程当中，发现了一些应该由你测试出来的问题，但是被我发现了，我就会给你反馈，而且可能还告诉到科长或者是领导那。有时情况还是比较激烈。测试团队与测试团队之间可能都有激烈的冲突。这一个现象好的结果就是各个级别都会去坚守自己的一些应该覆盖和应该去测试的内容和应该发现的问题。
ISTQB第一章有一个内容是“特定的一些使用的环境，就是未必是你的软件的问题，你的使用环境也可能会导致你的软件失效”。其实这一个内容，我们也有展开，但是我在展开的时候并没有从当时我们提到软件需要有一些维度、可靠性、稳定性等方面展开。为什么没有从那个地方展开？其实是我们在整个应用过程当中发现，我们的企业没有对应的指标要求，你让我一个测试团队拿着前面开发的一堆文档按照那个维度去给你整理好，其实难度还是比较大的，所以针对环境的适应性这一块我们是很明确很清晰的。然后，我们就把他落到了一个环境可能会导致软件失效的这么一个内容上。我们根据这一个点去展开、去扩展，针对这种环境应该做哪些适应性测试？这样在不同的环境下，软件就会变得更可靠。
基于这一点去展开就可以扩充出一套适应性的测试方法、流程和要求出来。我们现在的整个扩充的过程，除了大家可能会去做的高温高寒，但是高温高寒，其实我们是要做软件的适应性测试。然后同时，就是兼容性测试，装兼容可能大家也会去做。手机金融也会去做。除此之外也延展到了线检。因为控制器本身是有差异的，你也可以认为你的软件在控制器上的一个差异，那你软件的运行环境也会不一样。所以我们做了一个非常深入的延展。
以上，就是关于ISTQB第一章中我们做的一些落地方法分享。
ISTQB第二章告诉我们测试需要与开发过程进行集成。因此我们在整个研发过程当中一直很关注开发的实施情况。虽然当时大家都在提倡微模式，但是我们认为那不是微模式，我们认为他们就是在做敏捷，就是在做增量迭代开发。因此我们当时识别到了之后就将实施过程当中的这些软件分成了稳定的部分和不稳定的部分。
对于稳定的部分，当时采用的是增量的方式去应对，会定期把它转换成自动化用例，便于后续回归。一批次一批次的这种自动化用例。后续他去做迭代的时候，稳定的功能我们也会去给他做回归。
不稳定的部分，我们就不开发测试用例。那个时候我们会采用和开发人员协同调试的方式去稳定这个功能。在最开始的时候，整个周期还比较长，到现在的话，我们的一个功能开发到稳定也可能十几天，还是挺快的，逐渐大家配合熟悉后，这个模式就这么推下去了。同时我们也会针对整个研发周期，在固定的时候去做一些回归。
ISTQB第三章这一块的内容，是主要为评审。我们在实际应用的时候也确实将评审的做了很多的分类。比如：针对一些问题的内容，我们会开展一些非正式的评审，随时讨论；对于代码和功能的一致性，我们也会做走查。评审会比较快速地发现问题。最开始开发人员不愿意，我们基于这个收益我们要求他们开放代码，开放代码便于走查。因为很多时候开发都会提，不看代码是为了你好，然后你看到代码变成我一样。其实不是这样的，因为我们在新版的ISTQB大纲里面也会讲到“开发人员如果带着测试的思维，也可以实施测试”。
其实测试做久了之后就会发现，测试人员，其实也需要了解开发同样的内容，并不是只了解测试的内容就可以了；而开发人员可能也需要理解测试需要的内容，否则也没有办法提供符合要求的设计文档，没有办法和测试人员协同起来，把测试给做完。开发人员和测试人员在某种程度上的知识体系是非常相似的。以前可能有一些测试会简单一点，比如：最开始做手机测试，手机打开之后会屏幕会亮，可能一堆人坐在那个房间里面，不停甩手机，但是现在不是这样。做测试要了解内容和开发比起来差不了太多，一样要了解很多内容。你不了解，好多测试做不了，最起码也做不好。
我们会针对一些疑难问题做技术评审。同时对测试环境这一块也会做技术评审。在技术评审的时候，我们也会有一些明确要求，比如说没有同等的一些技术人员在场，这个评审是没有意义的。我非常深刻地认识到这点，这种评审会开也白开，没有用。在审查这一块，我们会对重点的交付物做审查，会开展非常正式的评审。那个时候我印象中就是评报告，可能会评到晚上七八点，可能会开始做分发，完了之后肯定是决策者在场，也会有朗读者。朗读者,有的时候就是作者自己朗读，朗读后再进行陈述，我们会按照这种方式去做，最后把报告重点的交付物交付到项目上。虽然看着很繁琐，但是用这种方式很少会有出错的问题也会发现很多形式上的问题，也会有一些这种检查清单。这都是我们在评审这一块的一些内容。
对于第四章的测试设计这一块，大家可能经常都会用。我们在部件测试的时候使用黑盒测试技术，但是我们同时也会针对一些流程跳转做MCDC。MCDC的十次覆盖，除了做黑盒之外。白盒我们以前也做过，但是每一个测试要求是不一样的，但是我们在做部件的一些集成测试的时候，我们也会要求用MCDC，这也符合白盒测试技术，可以运用在各个级别上的要求。这一点，在你不知道的时候可能会给你带来困扰，因为有的人会觉得我不应该在黑盒测试的时候使用白盒测试技术，有的人可能会有这样的困扰，其实这种方法是没有问题的。因为白盒测试技术里面提到的覆盖方法和内容可以运用在各个级别当中去。所以在这么一个知识结构下。在你的测试技术应用上也会给你带来技术自信。大家都是这么做的，经过全球一系列的专家认为都是可以这么做的，所以这一点对大家其实是蛮重要的。可以支持你的测试技术的落地。这种覆盖方法，也并没有给我们带来测试爆炸的些情况。
对于基于经验的测试技术，我们其实不是单纯的邀请人员去实施测试,我们会收集这种现象和问题，然后基于经验的分析。一些典型的很有趣的测试问题和现象，有的问题和现象真的是偶然发现的，前两天我们非常偶然的发现了一个问题。在某种情况下，这个功能就失效了，真的是恰好就在那个情况下失效了，但是一深入一延展，我们把它延展到别的功能上。所以这种基于经验的测试，不单是可以去选有经验的人去实施测试，还可以去搜集偶发的一些问题，去做基于大家经验的一个分析，把它延展成常规的测试内容，以此对我们的测试做补充。因为基于经验的测试主要目的是对测试做补充。我觉得，这个内容可以给大家做一个比较好的参考。
ISTQB第五章的测试管理方面，我们基本上是将测试人员分成了测试DRE和测试VSE。他们基本上是承担测试经理的角色。计划、整体的管控、问题调度，都是他们去做。我们的测试报告这么多年以来是深入贯彻ISTQB。
经常我们都是在改，因为里面给我们提到的这么一个内容。就是你要根据利益干系人的情况去选内容，所以我们经常会去选我们的测试报告的阅读者到底需要哪些内容？因为我做汽车行业很多年了，以前看很多这种测试报告。尤其是有一些给我们的报告，一来就是很大一摞。就是我都不知道我要看什么，几百页，这个太难弄了是不是？我做分析就一堆纸放在那，打印也不好打印，这么多内容。所以我们也会针对利益干系人，我们一直在修改我们的测试报告应该去呈现的内容。但是可能会有人担心测试报告改了之后没有对比性，这个不用担心，因为我们所有的这种报告的数据，基本上都是在一个测试平台上。这一块也是有一些前提的。但如果你把你的测试报告作为你的唯一数据源，按照刚才的方式可能就会有问题。
ISTQB第五章里面也提到了，除了测试报告，测试报告有两种，一个是我们阶段性、结果性的报告，二是测试总体。我们是当时弄完之后连续两年每个月，都会针对测试的整体数据做测试的总结分析，每月出月报，发给我们的管理者去看。现在我们的管理层都升成总经理了。我们当时通过这种整体数据分析的方式，挖掘了很多流程类的问题，很多流程问题都是在那个阶段去解决的。这两年没做的原因，一是疫情方面。二是行业竞争压力大，流失也比较严重。
在风险测试方面，我们每年会统计测试用例对于问题的一些贡献程度。到底每一个用例每年贡献了多少个问题出来，我们会把它作为基于后续我们做风险测试的一个重要依据。这一块也是可以给大家一个比较好的参考。
第六章的工具的内容，对我们的帮助是比较大的。尤其是使用工具代价方面。在第六章里面就会讲“使用工具本身是有代价的”。我们针对使用工具，可能会带来的一些代价。在引入多款工具之前均进行了非常详细的分析、研究和适用。我们在这个过程当中规避了不少风险。
我们在引入工具时会深入考虑学习成本和数据兼容，因为这些内容都是ISTQB第六章里面明确提出了的这些内容。另外我们也研发了自己的测试工具，在接下来演讲的第三部分会给大家详细叙述这个内容。
三、自动化与低代码
01背景
自动化的代价-学习成本
我们在实施自动化的过程当中，最开始使用的是大量的测试脚本开发、实施开发。我们发现一个问题，精通业务的人，未必喜欢代码，有些对业务很精通，对被测对象很了解，他并不精通代码。而精通代码的人，比较喜欢研究各种效果实现，发个声音，一个UI界面和弹窗，但是他对于如何去测试才能够有效地发现问题，这一块他其实不擅长，有时候还会有些排斥，影响他发挥了，影响他学写代码了。大家可能会觉得，那我找两者都有的人就好了。基本上没有。非常非常少，这种心理可不是这么简单的，他不是一个普适性，他这就是两类人。因此，自动化测试实施就有一个问题。如何开展才能够在有效发现问题的同时大范围的去展开，所有人都可以去开展这个自动化测试？
自动化的代价-杀虫剂效应
同时自动化的这种固化的自动测试脚本，也会有个问题。你会发现你的固化的一个脚本。你发现的问题会越来越少，因为你一直都这么测试,这几个跳转来回跳,完了之后变化不大。后续开发人员逐渐适应就会避坑，这个避坑是一个天然的反应。即使后期，我们将数据与用例脱钩，他只是数据上的一个变化，你的跳转没有变化，你这整个程序流转过程没有变化。
自动化的代价-穷尽测试
固化的测试脚本，可能会导致我们的问题越来越少。另外我们也尝试过自动化的用例生成工具，但是不是现在大家说的是一款2010或者2011年的非常早的工具。当时我们用那个工具的时候生成用例非常吓人，把我们整得很崩溃，生成了一堆用例，整个搭建深层模型的过程很累，生成了一堆用例，挑也不好挑。当时我想到很多方法，要不我们编个程序去挑吧，其实也没办法挑，整了半天挑不出来合适的用例。后来那个工具就放在那，它现在有一些新的作用以后有机会可以给大家去分享这个工具。
工具的存在都有其本身的意义，我们中国的软件测试、汽车软件测试。其实也是一个过程，这些过程，国外也经历过，他们经历的比我们早，在那个阶段推出的这个软件其实是有它的使命的，只是在我们当时那个阶段没有把它用对。
02低代码自动化测试的介绍
低代码的概念
后来我们在上述的这个情况下，选了低代码的自动化测试技术。低代码，简单来讲就是构建一种可以完整表达又没有严格的编程技术要求的计算机语言，它本身其实也是语言。它没有严格的编程技术要求，它本身也是一个编程，但是不严格，整个规则不严格，也容易理解，能够完整表达，这些都是它的前提。一般的自动化场景，就是需要人员会编程，这就会导致刚才说的那种排斥的现象。主要可能会让你的用人面变窄，更主要的是我们的测试是服务于企业的，但是企业主要是需要测试发现问题，不是让我们去开发工具。因此，我们应该针对，这些可以有效发现问题的人，来开发工具。这类人能够更快速的去挖掘问题的人,要为他们去开发工具，我们的工具应该更多面向的是这个对象。
03自动化测试设计工具
我们最开始做了一版，后来觉得界面或者是需求表达那一块有一些欠缺。当时我们和赛迪做了一些合作，就是中国软件评测中心。由赛迪完善了针对需求的一些图形化表达这一块的内容，之后我们在需求表达基础上进行了用例生成算法的开发，并且在生成用例之后，我们还发现，在整个过程当中，我们还有了额外的收益，在生存的过程当中，发现了需求文档间的逻辑，就是需求文档和文档间的内部逻辑错误、冲突，互相之间矛盾了。
我们之前得到的用例，也会通过中间线的一个转换可以实现在任意级别上的一个运行。目前主要是在汽车行业里面用。我们在这个工具上首先解决的，是用例设计质量的一个不稳定性的问题，就是用例设计的不稳定，这最开始也是我们的初衷。当时我们的用例，不评审根本就不知道覆盖的全不全，但是评一个用例就是几个小功能，评了四五个小时，评了，整个人都很崩溃。然后这一块只要我们提前把测试强度提前注入，作为一个约束边界，基本上就可以生成一个完整的用例集，没有任何遗漏。另外，我们在生成用例集的时候，也会结合整信号，在整个用例中的整体取值情况，去优化我们的用例数量。去避免一些用例爆炸的情况。我们在整个算法过程当中一定要注意，测试用例的生成可能会给你带来用例爆炸。那么你再去做工具脚本的时候，一定要去尽力避免这个内容。完整的内容是蛮复杂的，这个有的内容也不太方便展开。
另外我们还在建立属于测试结果与测试设计之间的数据闭环。我们的测试结果，比如我们用这种方式去生存的用例，那么可能会发现一些什么软件问题。根据发现软件的问题，我们再去优化之前生存的用例，这样就可以形成一个闭环，通过这种方式不断地去丰富你的用例。避免重复的生成，让开发逐渐地去适应你的一个生成方法。
未来，我们还有一个计划，可能还会去与市场的一些数据相结合，可以去生成更有价值的一些用例。
四、可见的未来
第四部分给大家分享一下，我们未来可能会面对的一些情况。根据以上的内容，我们可以看出所有的发展基本上都源于需求。我们如果想知道未来应该要做什么？就要知道他需要什么。
01探测深度的变化
首先，从探测深度的变化，我从公司的一些分享内容上能够看出，目前来说，各个团队所发现的问题，在一个变化的过程当中。最开始可能大家发现的都是接口问题、功能逻辑以及文档问题。这些在评审、测试过程中都容易发现。渐渐地大家发现的问题开始转变，开始发现内存的问题、性能的问题以及场景完整性的问题。场景完整性可能在自动驾驶中比较多。还有设计的一些内在矛盾。整个方向都在发生转变也就是探测深度的变化，一切事物的发展都得卷，但其实卷不是绝对的贬义词，有的时候是一个褒义词，因为在这种卷的氛围下，可能一些技术就会不断的去迭代出来。目前来看，各个公司发现的软件问题，已经开始卷起来了，逐渐开始向我提到的这些问题上去做了。因此可以预测，未来会逐渐从形式化的测试转变为工具化。因为我们做很多测试都必须得工具化，比如：内存、性能等，可能会是一个非常深度的工具化。
02重点测试方向
在重点测试方向上也会有转变。最开始，我们可能是看内容和文档的符合性。后续智能驾驶、座舱这一块内容出来了之后，更多强调的是设计与用户的一个符合性。现在我也了解到很多公司都在关注需求工程这一块的内容，这肯定也是未来的一个趋势。
更深入地讲，在满足了设计与用户的符合性需求之外。可能未来我们还要面临整个软件的设计与企业经营的符合性。即怎样通过测试让整个软件的功能链条本身是可靠的，或给企业带来的损失是他可以接受的范围以内。因为现在大家都在讲究快速发布，现在问你快速发布，对于企业来说。符不符合他的一个经营指标，这个问题很多时候是很难回答，没有数据，也回答不了。
从功能的变化上说，除了目前存在的智能座舱，智能驾驶，逐渐地会发现功能现在已经开始按照功能链条设计。如PPT所示，除了云端、车端，人端大家可能想的是APP，但是我在PPT里给你们画了两个图，一个是近端感知，一个是远端感知。在我看来，人在远端对车的需求和感知和在近端对车的需求和感知，本质上是不一样的。企业对你的要求会往这个方向去走，测试的重点还是来源于市场的期望，市场对不佳的软件的接受程度越来越低。
03软件开发与测试的集成过程
开发与测试的一个集成过程会变得很不一样。以前开发与测试同步进行，完了之后同步发布。开发和测试不断地迭代，迭代完了之后发布。在未来的某个阶段可能会逐渐变成开发、测试、发布三个事情同步推进，可能介入的点不一样，但是基本上是同步推进。刚才和大家提到，随着汽车软件OTA的不断应用，OTA也在卷，大家都在说我们企业可以给用户带来什么。您的企业可以给用户带来什么？所以它会变成一个持续的一个过程。以后的整个过程，不能到了那个阶段就把团队就给释放出来，你的资源未必能完全释放出来，除了你资源释放不出来之外，可能你的一些测试资产都得持续保留，你的测试资产测试数据的一个时间长度可能会拉到非常长，得考虑很远的东西。关于我提到的OTA这部分内容，有的人也许觉得不一定是一个趋势。我也了解到，现在有的企业对于OTA这一块内容，不像以前那样，我基于现有的这些硬件，应该去做一些什么样的优化；企业已经开始深度部署，会计划在未来，将有的功能通过什么样的方式带给用户的，它整个的开发链条变长了。不是说不好，这是市场的需求，一切都是经济的一个过程。
04汽车软件测试的组成
汽车软件的组成，也发生了很大的变化。最开始可能是C代码，来变成simulink代码。现在语言特别丰富。大家会发现一个汽车软件里面有多种语言，大家应该能够深入体会。这对测试工程师，尤其是系统测试工程师来说，要了解的内容越来越多了。我一直都强调一点，测试工程师不去了解你的被测对象是没有办法去把软件测试做好的。
05企业在汽车软件上的竞争
最后，企业在汽车软件上的一个竞争。刚才我提到的第一个点是长远的一个布局。在整个长远布局当中,你的测试资产怎样去重用，就变得非常重要。我记得在2011年、2012年左右。我可能在这个项目上做的一个模型，到了下个项目我又重搭了一个。但现在不是，现在测试资产重用非常重要。从长远布局的上来看，现在我们有的这种测试台架，不是量产后就拆了，有的台架目前计划一直用到六个月过后，因为担心可能没地方放。但是从长远来看，可能有的台架可能会放好几年。因为随时随地可能都得去做这个测试。
另外，现在软件的迭代速度非常快。他除了在开发端，可能会去做一些架构之外。在测试端，你的一个快速回归，也是非常重要的。我们之前也做过一些尝试，能否把算力变成测试资源，我们也正在研究。
另外，是数据化，现在很多功能都是数据驱动的，是基于数据去做的。我不知道用数据驱动是否合适？因为在测试中“数据驱动“是另一个意思。它是一个数据化的一个过程，比如：我们的智能驾驶和座舱的语音这一块很多内容都是属于是数据化的。数据化的内容对测试来说，就不再是针对单件的测试。你得有全局和概率测算的概念。其中，也给大家避个坑。因为很多人会提到，“不是说你做了这个测试，通过率是多少吗？但是为什么我的这一个键有问题？”和大家说明一下，他其实是在用一个单件的问题在打你的整体的、全局的一个概率问题，本身是有问题的。要和大家说明的是我们通过功能的测试的时候，它不再是一个单个样本的概念，是一个全局样本的概念。全局样本概念只能是针对全局的测试失效，不能是单个样本的测试失效。以上是我的一个分享内容。
嘉宾简介
黄颍华
15年工作经验，11年汽车控制器软件测试经验，7年测试团队管理经验，6年测试自动化工具开发经验，有2项国际发明专利，擅长测试自动化、测试流程体系设计与优化，其研发的测试工具作为独立创新点获得2020年中国汽车工业科技进步奖一等奖。带领北汽新能源软件测试团队获得国际首个汽车行业TMMi 3级认证证书，中国汽车学会团体标准-CSAE-177-新能源汽车控制器软件功能测试规范主编人，参与ISO/IEC/IEEE 29119中国区的审核工作，ISTQB汽车软件测试工程认证的本地化工作，拥有ISTQB、IREB、TMMi培训师证书以及TMMi评估师证书。
资料获取