CN116107903A

CN116107903A - 一种车端服务化功能测试方法、装置、设备及介质

Info

Publication number: CN116107903A
Application number: CN202310163767.5A
Authority: CN
Inventors: 彭渝; 谢东辰; 郝金隆; 彭一轩; 黄强
Original assignee: Chongqing Changan Automobile Co Ltd
Current assignee: Chongqing Changan Automobile Co Ltd
Priority date: 2023-02-24
Filing date: 2023-02-24
Publication date: 2023-05-12

Abstract

本申请涉及软件测试技术领域，公开了一种车端服务化功能测试方法、装置、设备及介质，方法包括：获取车端应用中的多个服务和多个服务对应的待测功能参数；根据多个服务的功能特性，确定待测场景类别，并根据待测场景类别和预设的待测场景生成策略，对多个服务和待测功能参数进行组合以生成待测场景；根据待测场景，生成测试用例，控制预先配置的执行模拟器接收测试用例并执行对车端服务化功能的测试。本发明中，通过车端服务的功能特性将多个服务和待测功能参数进行组合得到待测场景，不会出现针对不同需求信息生成相同的测试场景的情况，避免了服务化功能测试的重复，提高了测试场景的覆盖，进而提高了测试效率。

Description

一种车端服务化功能测试方法、装置、设备及介质

技术领域

本申请涉及软件测试技术领域，具体涉及一种车端服务化功能测试方法、装置、设备及介质。

背景技术

SOA(Service-Oriented Architecture，面向服务的架构)定义了一种可通过服务接口复用软件组件的方法。此类接口会使用通用的通信标准，这些标准能够快速合并到新应用程序中，而不必每次都执行深度集成。SOA中的每项服务都包含执行完整的独立业务功能所需的代码和数据集成。这些服务接口提供松散耦合，即使不知道如何在底层实施集成，也可以调用这些接口。

随着车联网技术的发展，SOA已广泛应用到车端，服务化功能在车端应用中逐渐被使用，随着应用的逐渐增多及应用功能的多元化，车端服务化功能在应用中涉及的场景越来越多，给用户带来了极致的体验。但是，车端服务化架构在车端是一种新技术，目前没有系统的测试工具及方法；另外，车端服务化功能成千上万个，不同的应用存在服务化功能的重复调用，不同的应用场景中也会有很多不同的服务。因此，使用目前现有的软件测试方法对SOA中的服务化功能进行测试时，服务数量的庞大将会导致服务化功能测试的重复、测试场景多而覆盖不全、测试效率低下的问题。

发明内容

鉴于以上所述现有技术的缺点，本申请的目的在于提供一种车端服务化功能测试方法、装置、设备及介质，用于解决现有技术中服务化功能测试的重复、测试场景多而覆盖不全、测试效率低下的问题。

为实现上述目的及其他相关目的，本申请提供一种车端服务化功能测试方法，所述方法包括：

获取车端应用中的多个服务和所述多个服务对应的待测功能参数；

根据所述多个服务的功能特性，确定待测场景类别，并根据所述待测场景类别和预设的待测场景生成策略，对所述多个服务和待测功能参数进行组合以生成待测场景；

根据所述待测场景，生成测试用例，控制预先配置的执行模拟器接收所述测试用例并执行对车端服务化功能的测试。

于本申请的一实施例中，所述获取车端应用中的多个服务和所述多个服务对应的待测功能参数，包括：

获取车端应用需求信息；

解析所述车端应用需求信息，确定车端应用中的多个服务并调用所述多个服务对应的服务化功能参数需求信息；

根据所述服务化功能参数需求信息，得到所述多个服务对应的待测功能参数。

于本申请的一实施例中，所述根据所述服务化功能参数需求信息，得到所述多个服务对应的待测功能参数，包括：

根据所述服务化功能参数需求信息，确定每个服务对应的待测功能参数的参数类型；

若所述参数类型为字符串，则获取字符串参数的长度范围，得到第一参数范围；

若所述参数类型为数字，则获取数字参数的取值范围，得到第二参数范围；

对所述多个服务对应的第一参数范围和/或所述第二参数范围进行等价类划分，得到参数有效区间，并根据所述参数有效区间的边界值得到所述多个服务对应的待测功能参数。

于本申请的一实施例中，获取车端应用中的多个服务和所述多个服务对应的待测功能参数之后，还包括：

若所述待测功能参数为预设的优先级参数范围内的边界最小值，则将所述待测功能参数的优先级设置为第一等级优先级；

若所述待测功能参数为所述优先级参数范围内除边界最小值之外的其他边界值，则将所述待测功能参数的优先级设置为第二等级优先级；

若所述待测功能参数在所述优先级参数范围对应的等价范围内，则将所述待测功能参数的优先级设置为第三等级优先级；

根据所述多个服务对应的待测功能参数的第一等级优先级和/或第二等级优先级和/或第三等级优先级，得到第一优先级信息，所述第一优先级信息用于与所述待测场景组合得到所述测试用例。

于本申请的一实施例中，所述根据所述待测场景类别和预设的待测场景生成策略，对所述多个服务和待测功能参数进行组合以生成待测场景，包括：

若所述待测场景类别为固定场景，则调用预设的与所述固定场景对应的固定组合方式；

根据所述固定组合方式，对所述多个服务和所述多个服务对应的待测功能参数进行组合，得到所述待测场景。

若所述待测场景类别为自由组合场景，则根据所述多个服务和所述多个服务对应的待测功能参数生成键值对列表，所述键值对列表的键为所述多个服务对应的待测功能参数，所述键值对列表的值为所述多个服务，所述键值对列表的行数与所述多个服务对应的待测功能参数的数量一致；

根据预设的键值组合方式，将所述键值对列表中的键和值进行组合，得到所述待测场景。

于本申请的一实施例中，根据所述待测场景，生成测试用例之后，还包括：

生成所述测试用例对应的测试脚本，并将多个所述测试用例和所述测试用例对应的测试脚本组合，得到测试项目，所述测试项目在被调用时运行所述测试脚本以控制所述执行模拟器接收并运行所述测试用例；

根据所述第一优先级信息，分别将每个所述测试用例中待测功能参数的优先级叠加，得到叠加后的优先级；

根据每个所述测试用例中服务的数量和所述叠加后的优先级，判断每个所述测试用例的优先级；

若所述服务的数量与所述叠加后的优先级相等，则将所述测试用例的优先级设置为第一等级优先级；

若所述叠加后的优先级大于一倍所述服务的数量且小于或等于两倍所述服务的数量，则将所述测试用例的优先级设置为第二等级优先级；

若所述叠加后的优先级大于两倍所述服务的数量且小于或等于三倍所述服务的数量，则将所述测试用例的优先级设置为第三等级优先级；

若所述叠加后的优先级大于三倍所述服务的数量且小于或等于四倍所述服务的数量，则将所述测试用例的优先级设置为第四等级优先级；

根据所述第一等级优先级和/或第二等级优先级和/或第三等级优先级和/或第四等级优先级，得到第二优先级信息，所述第二优先级信息用于判断是否调用所述测试项目。

于本申请的一实施例中，得到第二优先级信息之后，还包括：

若所述第二优先级信息与预设的测试项目调用优先级匹配，则调用所述测试项目并运行所述测试脚本；

若所述执行模拟器无法接收所述测试用例，或所述执行模拟器无法运行所述测试用例，则判断所述测试用例存在缺陷；

将所述待测场景、第一优先级信息进行重新组合，得到新的测试用例并生成新的测试脚本。

于本申请的一实施例中，所述得到新的测试用例并生成新的测试脚本之后，还包括：

运行所述新的测试脚本，重新控制所述执行模拟器接收所述新的测试用例并执行对车端服务化功能的测试；

根据所述新的测试脚本的运行结果、执行模拟器运行所述新的测试用例的结果，生成测试日志。

于本申请的一实施例中，控制预先配置的执行模拟器接收所述测试用例并执行对车端服务化功能的测试之后，还包括：

获取所述执行模拟器返回的车端服务化功能测试结果，所述车端服务化功能测试结果包括测试用例缺陷和缺陷等级，所述缺陷等级与所述第二优先级信息相对应；

根据预设的缺陷等级与缺陷率的对应关系，计算测试项目中各测试用例缺陷的缺陷率，并叠加所述测试项目中各测试用例缺陷的缺陷率，得到测试项目缺陷率；

若所述测试项目缺陷率小于预设的缺陷率阈值，则确定车端服务化功能测试通过；

若所述测试项目缺陷率大于所述预设的缺陷率阈值，则确定车端服务化功能测试失败，并根据所述测试用例缺陷重新生成测试用例。

于本申请的一实施例中，还提供了一种车端服务化功能测试装置，所述装置包括：

数据获取模块，用于获取车端应用中的多个服务和所述多个服务对应的待测功能参数；

待测场景生成模块，用于根据所述多个服务的功能特性，确定待测场景类别，并根据所述待测场景类别和预设的待测场景生成策略，对所述多个服务和待测功能参数进行组合以生成待测场景；

测试模块，用于根据所述待测场景，生成测试用例，控制预先配置的执行模拟器接收所述测试用例并执行对车端服务化功能的测试。

于本申请的一实施例中，还提供了一种电子设备，所述电子设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现如上所述的车端服务化功能测试方法。

于本申请的一实施例中，还提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序被计算机的处理器执行时，使计算机执行如上所述的车端服务化功能测试方法。

本发明的有益效果：

首先获取车端应用中的多个服务和所述多个服务对应的待测功能参数；然后根据所述多个服务的功能特性，确定待测场景类别，并根据所述待测场景类别和预设的待测场景生成策略，对所述多个服务和待测功能参数进行组合以生成待测场景；最后根据所述待测场景，生成测试用例，控制预先配置的执行模拟器接收所述测试用例并执行对车端服务化功能的测试。本发明中，通过车端服务的功能特性将多个服务和待测功能参数进行组合得到待测场景，不会出现针对不同需求信息生成相同的测试场景的情况，避免了服务化功能测试的重复，提高了测试场景的覆盖，进而提高了测试效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术者来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1是本申请的一示例性实施例示出的车端服务化功能测试方法的实施环境示意图；

图2是本申请的一示例性实施例示出的车端服务化功能测试方法的流程示意图；

图3是本申请的一示例性实施例示出的自由组合场景对应的场景生成策略示意图；

图4是本申请的一示例性实施例示出的用以支持车端服务化功能测试方法的台架示意图；

图5是本申请的另一示例性实施例示出的车端服务化功能测试方法的流程示意图；

图6是本申请的一示例性实施例示出的车端服务化功能测试装置的框图；

图7是本申请的另一示例性实施例示出的车端服务化功能测试装置的框图；

图8示出了适于本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

以下将参照附图和优选实施例来说明本发明的实施方式，本领域技术人员可由本说明书中所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。应当理解，优选实施例仅为了说明本发明，而不是为了限制本发明的保护范围。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

在下文描述中，探讨了大量细节，以提供对本发明实施例的更透彻的解释，然而，对本领域技术人员来说，可以在没有这些具体细节的情况下实施本发明的实施例是显而易见的，在其他实施例中，以方框图的形式而不是以细节的形式来示出公知的结构和设备，以避免使本发明的实施例难以理解。

首先需要说明的是，随着汽车新四化的趋势，现在新的汽车消费群体对车的要求也已经发生了巨大的改变，车在全面实现网联、自动驾驶、数据驱动的同时，也更趋向于直接触达用户，提升体验、服务，满足用户的个性化需求。SOA是一种软件架构，同时一种软件设计的思想，在SOA架构中，服务是最核心的抽象手段和系统最基础的单元。每个服务具备独立的功能，服务之间的接口遵循统一的标准，可互相访问，可组合扩展。在车端基于SOA架构下，随着应用的增多，服务的数量也随之增多，因此针对服务测试时测试场景的覆盖和测试的效率十分重要。现有部分技术中，通过需求定义测试项得到测试需求，再根据测试需求的路径进行扫描得到若干测试场景，并根据测试场景生成对应的测试数据，最后将测试数据添加至预期对应的所述场景中形成测试用例，并生成测试用例。上述技术方案中主要是对需求输入、测试需求生成、测试场景生成、测试用例输出的整个流程的描述，对测试需求的路径扫描如何得到的测试场景、测试数据如何生成的、如何将测试数据和测试场景结合生成测试用例等详细的过程并没有进行说明。另外，上述技术方案中，主要通过测试场景和数据组合方式来获得测试用例，虽然提高了测试用例的覆盖程度，但是存在重复的测试用例，进而增加了测试执行的工作量、降低了测试效率。最后，上述技术方案中并未公开如何进行测试执行、如何生成测试结果、如何回归生成测试用例和回归测试。因此，本申请实施例中的方案主要解决车端SOA架构下因应用的服务化功能增多、多元化而导致的服务化功能测试的重复、测试场景多而覆盖不全、测试效率低下的问题。

以下对本申请中的各技术名词进行说明：

string：是多种编程语言中的字符串，字符串是一个特殊的对象，属于引用类型。本申请实施例中，通过用户输入或系统录入的手段获取车端应用需求信息，车端应用需求信息限定了服务化功能参数需求信息，对参数的数据类型进行了限制。当参数的数据类型为string时，需确定string参数的长度范围，用于后续对待测功能参数的确定。

优先级：本申请实施例中的优先级包括待测功能参数的优先级、测试用例的优先级、缺陷的优先级。其中，在相同测试算力条件下同一批测试用例待测试时，可通过待测功能参数的优先级确定哪些测试用例需要被运行，哪些测试用例无需运行；测试用例的优先级，可指导执行模块选取执行包含测试用例和测试脚本的测试项目；缺陷的优先级，因为不同的测试用例对应着不同的优先级，那么这些测试用例在测试执行过程中出现的缺陷就会与测试用例相对应，不同等级优先级对应的缺陷的值也不同，可用于后续生成测试结果。

键值对：在计算机科学中，键值对，也可以称为名值对或属性值对，是一种基本的数据表示。在需要通过开放式的数据结构在未修改现有的代码或数据的情况下进行扩展时，数据模型的全部或部分可以表示为元组的集合，每个元素都是名值对。

测试用例：Test Case，是为某个测试目标而编制的一组测试输入、执行步骤以及预期结果的集合，以便测试某个程序的路径或验证软件是否满足某个特定需求。本申请实施例中，测试用例中包含测试场景(测试场景中包含其对应的多个服务和待测功能参数)和待测功能参数的优先级信息。

测试脚本：Test script，为一个特定测试的一系列指令，是自动化执行测试过程的计算机可读指令，这些指令可以被自动化测试工具执行。为了提高测试脚本的可维护性和可复用性，必须在执行测试脚本之前进行构建。本申请实施例中，在得到测试用例后生成测试用例对应的测试脚本，测试脚本成功运行后会将测试用例传输至测试执行模拟器中并运行。

DI值：(Defect Index值，缺陷率值)，DI值是衡量软件质量高低的标准之一，可通过BUG(缺陷)的严重程度和数量对DI值进行计算。本申请实施例中，调用测试项目并运行其中的测试用例，通过测试用例运行结果中的缺陷个数、缺陷等级来确定当前测试项目的缺陷率。

图1是本申请的一示例性实施例示出的车端服务化功能测试方法的实施环境示意图。

参照图1所示，实施环境中可以包括车端服务化功能测试终端101、云端102和信息存储终端103。车端服务化功能测试终端101可包括平板电脑、笔记本电脑、台式电脑等电子设备，用于接收信息、生成测试项目、执行测试并生成测试结果。云端102可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器，可用于存储车端应用需求信息、测试日志和测试结果。信息存储终端103用于存储车端应用需求信息，也可用于获取车端服务化功能测试终端101传输的测试结果和/或测试日志并进行存储。

另外，本申请实施例提供的技术方案可以应用于车端服务化功能测试终端101，车端服务化功能测试终端101用于通过网络连接云端102和信息存储终端103并获取车端应用需求信息，同时云端102和信息存储终端103还接收车端服务化功能测试终端101生成的测试结果、测试日志并存储。

在本申请的一实施例中，车端服务化功能测试终端101获取车端应用中的多个服务和所述多个服务对应的待测功能参数；根据所述多个服务的功能特性，确定待测场景类别，并根据所述待测场景类别和预设的待测场景生成策略，对所述多个服务和待测功能参数进行组合以生成待测场景；根据所述待测场景，生成测试用例，控制预先配置的执行模拟器接收所述测试用例并执行对车端服务化功能的测试。通过车端服务的功能特性将多个服务和待测功能参数进行组合得到待测场景，不会出现针对不同需求信息生成相同的测试场景的情况，避免了服务化功能测试的重复，提高了测试场景的覆盖，进而提高了测试效率。

以上部分介绍了应用本申请技术方案的示例性实施环境的内容，接下来继续介绍本申请的车端服务化功能测试方法。

为解决现有技术中服务化功能测试的重复、测试场景多而覆盖不全、测试效率低下的问题，本申请的实施例分别提出一种车端服务化功能测试方法、一种车端服务化功能测试装置、一种电子设备、一种计算机可读存储介质以及一种计算机程序产品，以下将对这些实施例进行详细描述。

请参阅图2，图2是本申请的一示例性实施例示出的车端服务化功能测试方法的流程示意图，该方法可以应用于图1所示的实施环境。应理解的是，该方法也可以适用于其它的示例性实施环境，并由其它实施环境中的设备具体执行，本实施例不对该方法所适用的实施环境进行限制。

如图2所示，在一示例性的实施例中，车端服务化功能测试方法至少包括步骤S210至步骤S230，详细介绍如下：

在步骤S210中，获取车端应用中的多个服务和多个服务对应的待测功能参数。

需要说明的是，车端应用拥有着多种功能，基于SOA将车端应用划分为多个功能化的服务，当车端需要在某个场景中输出某个动作的执行信号时，通过预先配置的服务接口调用目标服务。本申请实施例中，获取车端应用的服务列表，服务列表中包括多个服务的名称、类型以及待测功能参数，待测功能参数可以是参数范围也可以是具体的参数值，本申请实施例中选取具体的参数值为待测功能参数。

在步骤S220中，根据多个服务的功能特性，确定待测场景类别，并根据待测场景类别和预设的待测场景生成策略，对多个服务和待测功能参数进行组合以生成待测场景。

需要说明的是，待测场景类别包括固定场景类别和自由组合场景类别，其中，固定场景类别可例如为：高速公路行驶场景、自动泊车行驶场景；自由组合场景为车端服务化功能测试自由组合生成的场景，因为在车辆的实际使用过程中用户可根据个人喜好和当前需求对服务进行组合以实现场景的制定，所以本申请实施例中在服务化功能测试阶段对服务和待测参数进行自由组合，既能模仿真实环境下的场景生成过程又能提高场景的覆盖率。

在步骤S230中，根据待测场景，生成测试用例，控制预先配置的执行模拟器接收所述测试用例并执行对车端服务化功能的测试。

需要说明的是，本申请实施例中可直接根据待测场景生成测试用例；还可以将上述步骤S220中得到的多个待测场景与对应的待测功能参数的第一优先级信息组合，生成测试用例。执行模拟器接收测试用例并运行，实现对车端服务化功能的测试并输出测试结果。另外，当同一测试项目中包含多个测试用例时，可通过第一优先级信息决定运行哪些测试用例、不运行哪些测试用例，进而提高了测试效率。

由上述步骤S210至S230可知，本实施例提出的方案，通过车端服务的功能特性将多个服务和待测功能参数进行组合得到待测场景，不会出现针对不同需求信息生成相同的测试场景的情况，避免了服务化功能测试的重复，提高了测试场景的覆盖，进而提高了测试效率。

在本申请的一实施例中，图2所示步骤S210中的获取车端应用中的多个服务和所述多个服务对应的待测功能参数，包括如下步骤：

获取车端应用需求信息；

示例性的，车端服务化功能测试终端101通过网络获取云端102和/或信息存储终端103中预先存储的车端应用需求信息，车端应用需求信息可例如为服务列表，该服务列表中多个服务、多个服务的功能特性(即适用的场景)、多个服务的服务化功能参数需求信息，服务化功能参数需求信息中包括参数类型、参数范围等信息。

在本申请的一实施例中，根据所述服务化功能参数需求信息，得到所述多个服务对应的待测功能参数，包括如下步骤：

示例性的，通过服务化功能参数需求信息获取参数类型和参数范围，若参数为字符串参数则获取其长度范围，若参数为数字参数则获取其取值范围，然后根据等价类边界值的算法得到每个待测功能参数。需要说明的是，在测试过程中，有时选取同一参数范围内的多个参数得到待测功能参数，进而生成待测场景的过程中，部分不同的参数将会对应着同一待测场景，虽然提高了场景的覆盖率，但同时也增加了测试次数、降低了测试效率。本申请实施例中，通过等价类划分将不能穷举的测试过程进行合理分类，从而保证测试用例具有完整性和代表性。

在本申请的一实施例中，图2所示步骤S210中的获取车端应用中的多个服务和所述多个服务对应的待测功能参数之后，还包括如下步骤：

示例性的，得到第一优先级信息后，将第一优先级信息和测试场景组合得到测试用例，不同测试用例中包含不同测试场景，不同测试场景中包含不同的待测功能参数，不同待测功能参数对应的第一优先级信息能够指示是否运行测试用例。待测功能参数为优先级参数范围内的最小值时优先级为1；待测功能参数为优先级参数范围内的其他边界值时优先级为2；待测功能参数在等价类范围内时优先级为3；当待测功能参数不符合上述三种情况中的任一种时，优先级为4。

在本申请的一实施例中，待测场景类别包括固定场景，图2所示步骤S220中的根据所述待测场景类别和预设的待测场景生成策略，对所述多个服务和待测功能参数进行组合以生成待测场景，包括如下步骤：

示例性的，根据服务的功能特性，判断当前服务对应固定场景类型还是自由组合场景类型。例如：服务A可应用于第一固定场景和第二自由组合场景，服务B可应用于第二固定场景和第一自由组合场景，服务C可应用于第三固定场景，服务D可应用于第三自由组合场景，服务E可应用于第一固定场景，服务F可应用于第二固定场景，则将服务A、服务A对应的待测功能参数与服务E、服务E对应的待测功能参数进行组合以生成第一固定场景，将服务B、服务B对应的待测功能参数与服务F、服务F对应的待测功能参数进行组合以生成第一固定场景。

在本申请的一实施例中，待测场景类别包括自由组合场景，图2所示步骤S220中的根据所述待测场景类别和预设的待测场景生成策略，对所述多个服务和待测功能参数进行组合以生成待测场景，包括如下步骤：

示例性的，参见图3，图3是本申请的一示例性实施例示出的自由组合场景对应的场景生成策略示意图。首先获取服务的个数A和待测功能参数的数量B；然后根据A和B生成图3所示的键值对列表，键值对的行数为B行，键值对的值为所有服务，键值对的值的数量为A；最后根据预设的键值组合方式，将键值对列表中的键和值进行组合，得到待测场景，本实施例中预设的键值组合方式为借助启发式算法组合所有的键和值，并按照两两测试的原理生成测试场景。图3所示的自由组合场景对应的场景生成策略示意图中，包括服务A和服务B，服务A对应着参数值1、参数值2、参数值3，服务B对应着参数值1、参数值2，根据两两测试的原理将键值对列表中的键和值进行组合，可得到四个待测场景。本申请实施例中，自由组合场景可以模拟用户在车端进行场景制定时的服务和参数组合情况，自由组合场景生成策略可借助启发式算法，按照两两测试的原理设计测试场景。经验证对于任意自由组合场景，使用启发式算法能够达到90％以上的场景覆盖率。

在本申请的一实施例中，图2所示步骤S230中的根据所述待测场景，生成测试用例之后，还包括如下步骤：

示例性的，将待测场景、第一优先级信息组合得到测试用例后，生成测试用例对应的测试脚本，然后将多个测试用例及其对应的测试脚本组合生成测试项目，一个测试项目中可包含多个测试用例和这多个测试用例对应的测试脚本。需要说明的是，可根据实际情况对测试项目进行创建、修改、删除等操作，测试项目支持测试用例的增加、删除、修改和导出等操作，还可根据上一轮测试结果中的BUG(缺陷)情况生成与服务化功能相关的回归测试用例，并根据回归测试用例生成回归测试项目。

示例性的，服务的数量为M，叠加后的优先级为N，当M＝N时，测试用例的优先级为1；当M＜N≤2M时，测试用例的优先级为2；当2M＜N≤3M时，测试用例的优先级为3；当3M＜N≤4M时，测试用例的优先级为4。在同等算力条件下多个测试项目被调用时，可通过上述测试用例的优先级决定调用哪些测试项目、不调用哪些测试项目，进而提高测试效率。

在本申请的一实施例中，得到第二优先级信息之后，还包括如下步骤：

示例性的，当测试用例对应的第二优先级信息与预设的测试项目调用优先级相匹配时，可例如：当测试项目中多个测试用例的优先级都为1和/或2，预设的测试项目调用优先级为1和2，则调用测试项目。测试项目被调用后，运行其中的测试脚本，以将多个测试用例传输至预先配置的执行模拟器中运行。需要说明的是，当执行模拟器无法接收测试用例或无法运行测试用例时，则代表测试脚本出错和/或测试用例存在缺陷，可对测试脚本进行调试以确保脚本正确可用，然后重新生成测试项目；或对待测场景和第一优先级信息进行重新组合以生成回归测试用例，以确保测试用例可运行。上述步骤中通过对测试脚本的调试和回归测试用例的生成，能够保证预定的需要运行的测试用例能够在测试过程中准确运行，进而提高了测试的准确性。

在本申请的一实施例中，得到新的测试用例并生成新的测试脚本之后，还包括如下步骤：

本实施例中，调用测试项目并运行时，控制台会实时打印测试项目中每一条的测试用例的运行日志，当出现测试脚本运行失败、测试用例运行失败时，将运行失败的结果、BUG生成日志，以使测试人员及时对问题进行调整保证测试项目的正常运行。在重新生成测试脚本和测试用例并运行后，生成测试日志，然后可将出现问题的情况存储在测试日志中，以便测试人员查阅。

在本申请的一实施例中，图2所示步骤S240中的控制预先配置的执行模拟器接收所述测试用例并执行对车端服务化功能的测试之后，还包括如下步骤：

示例性的，测试项目执行完成后，根据BUG的等级计算出本次测试的DI值，然后与设定的DI阈值进行比较，如果大于预设的DI阈值，则判定本次测试不通过，并根据BUG清单生成回归测试用例，然后再通过回归测试项目重新执行；如果执行结果的DI值小于预设的DI阈值，则判定测试通过，并生成测试报告，达到整个测试的闭环。其中，通过优先级对每个测试用例中BUG的严重等级进行描述，BUG等级与其所处的测试用例的优先级相对应，例如：优先级为1的测试用例中出现的BUG的等级也为1，优先级为2的测试用例中出现的BUG的等级也为2。当优先级高的测试用例出现BUG时，代表该BUG严重程度较高，所以使BUG的等级与第二优先级信息对应能够确定当前测试项目中所有BUG的严重程度。当BUG的等级为1时即为致命级别；当BUG的等级为2时即为严重级别；当BUG的等级为3时即为一般级别；当BUG的等级为4时即为提示级别。

示例性的，将等级为1的BUG的DI值设置为10、等级为2的BUG的DI值设置为3、等级为3的BUG的DI值设置为1、等级为4的DI值设置为0.1，然后将每个测试用例的BUG的DI值进行叠加，即可得到测试项目的DI值。

在本申请的一实施例中，参见图4，图4是本申请的一示例性实施例示出的用以支持车端服务化功能测试方法的台架示意图。本实施例中，通过搭建测试台架来对车端服务化功能进行测试，图4中，测试台架主要包括电脑PC(Personal Computer，个人计算机)端、车机端、部署控制模块的mcu(Microcontroller Unit，微控制器)、执行模拟器，其中执行模拟器可例如为CANoe(CAN open environment，一款用于总线开发的设备)，车机端可例如为Android车机端。

测试台架的具体搭建过程包括如下步骤：

(1)电脑PC端部署自动测试系统的上位机通过ADB(Android Debug Bridge，调试桥)线/串口线连接车机端、通过串口线连接mcu、通过串口线连接执行模拟器。

(2)Android车机端上部署被测应用，并确保应用已启用，并通过以太网连接mcu。

(3)mcu部署业务信号处理模块，并将业务通过信号的方式传给执行模拟器。

(4)执行模拟器主要是模拟信号的收发，并与mcu通过局域网相连。

该测试台架主要保证pc端自动测试系统运行的测试脚本触发Android车机端上应用执行服务化功能，执行的信号转成车端可接收的can/canfd/link等网络信号并通过服务化调用的方式传输到mcu上，mcu将信号传输给执行模拟器，然后测试脚本控制执行模拟器将执行情况原路返回到车机的应用上形成台架信号的闭环。

在本申请的一实施例中，参见图5，图5是本申请的另一示例性实施例示出的车端服务化功能测试方法的流程示意图。图5中，通过图4所示的测试台架实现车端服务化功能测试，具体包括如下步骤：

将车端应用需求信息导入图4所示的测试台架中，车端应用需求信息导入时需按照预定的统一格式导入，以便pc端的自动测试系统识别；

根据导入的车端应用需求信息，识别出详细的服务列表及相关的信息，然后根据服务清单中的参数信息生成测试数据及第一优先级信息，根据服务的功能特性，区分出测试场景是固定场景还是自由组合的场景，然后再根据这两种场景的性质生成对应的测试场景；

把第一优先级信息与测试场景组合，生成测试用例，并根据场景参数的第一优先级信息计算出测试用例的第二优先级信息；

通过台架调试，判断执行模拟器是否能正常接收或执行测试用例，若失败则重新生成测试用例；

把调试通过的测试用例添加到测试项目中，支持对测试项目及项目中的测试用例进行增删改的操作；

运行测试项目，将测试项目中每一条的测试用例的运行结果生成测试日志，当出现台架异常、功能异常，将功能异常生成的BUG记录在测试日志中，台架异常时则通知测试人员，及时对台架的问题进行调整保证测试项目正常执行；

测试项目执行完成后，根据BUG的等级计算出本次测试的DI值，然后与设定的DI阈值进行比较，如果大于预设的DI阈值，则判定本次测试不通过，并根据BUG清单生成回归测试用例，然后再通过回归测试项目重新执行；如果执行结果的DI值小于预设的DI阈值，则判定测试通过，并生成测试报告，达到整个测试的闭环。

图6是本申请的一示例性实施例示出的车端服务化功能测试装置的框图。该装置可以应用于图1所示的实施环境。该装置也可以适用于其它的示例性实施环境，并具体配置在其它设备中，本实施例不对该装置所适用的实施环境进行限制。

如图6所示，该示例性的车端服务化功能测试装置包括：

数据获取模块601，用于获取车端应用中的多个服务和所述多个服务对应的待测功能参数；

待测场景生成模块602，用于根据所述多个服务的功能特性，确定待测场景类别，并根据所述待测场景类别和预设的待测场景生成策略，对所述多个服务和待测功能参数进行组合以生成待测场景；

测试模块603，用于根据所述待测场景，生成测试用例，控制预先配置的执行模拟器接收所述测试用例并执行对车端服务化功能的测试。

在该示例性的车端服务化功能测试装置中，通过车端服务的功能特性将多个服务和待测功能参数进行组合得到待测场景，不会出现针对不同需求信息生成相同的测试场景的情况，避免了服务化功能测试的重复，提高了测试场景的覆盖，进而提高了测试效率。

需要说明的是，上述实施例所提供的车端服务化功能测试装置与上述实施例所提供的车端服务化功能测试方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。上述实施例所提供的车端服务化功能测试装置在实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能，本处也不对此进行限制。

在本申请的一实施例中，参见图7，图7是本申请的另一示例性实施例示出的车端服务化功能测试装置的框图。

图7所示的车端服务化功能测试装置包括：

数据处理模块：获取导入的车端应用需求信息，根据车端应用需求信息得到待测功能参数和第一优先级信息。

测试场景生成模块：根据多个服务、待测功能参数生成固定场景和/或自由组合场景。

测试用例管理模块：根据测试场景、第一优先级信息生成测试用例和测试脚本，将测试用例和测试脚本组合生成测试项目，并将测试用例文档进行存储，测试用例管理模块可支持对测试项目中的测试用例进行增加、修改、删除等操作。

执行模块：支持单个测试脚本、批量测试脚本的调试，运行测试项目中的测试脚本以将测试用例传输至执行模拟器中。

执行模拟器模块：配合测试脚本模拟执行器的收发指令，运行接收的测试用例以进行车端服务化功能测试。

日志模块：记录脚本调试及运行时执行模块和执行模拟器模块输出的结果，支持在线实时查看以及执行完后的日志回放。

测试报告生成模块：该模块主要对项目执行后的结果进行分析，会根据用户设定的DI阈值去判断测试是否通过，如果测试项目的DI值大于DI阈值则为测试失败，根据BUG清单生成回归测试用例；如果测试项目的DI值小于DI阈值，则视为测试通过，并自动生成测试报告。

可以理解的是，图7所示的车端服务化功能测试装置与上述实施例所提供的车端服务化功能测试方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。

本申请的实施例还提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现上述各个实施例中提供的车端服务化功能测试方法。

图8示出了适于本申请实施例的电子设备的计算机系统的结构示意图。需要说明的是，图8示出的电子设备的计算机系统800仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图8所示，计算机系统800包括中央处理单元(Central Processing Unit，CPU)801，其可以根据存储在只读存储器(Read-Only Memory，ROM)802中的程序或者从储存部分808加载到随机访问存储器(Random Access Memory，RAM)803中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 803中，还存储有系统操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(Input/Output，I/O)接口805也连接至总线804。

以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分807；包括硬盘等的储存部分808；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入储存部分808。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(CPU)801执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

本申请的另一方面还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被计算机的处理器执行时，使计算机执行如前所述的车端服务化功能测试方法。该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中。

本申请的另一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各个实施例中提供的车端服务化功能测试方法。

上述实施例仅示例性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，但凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims

1.一种车端服务化功能测试方法，其特征在于，所述方法包括：

2.根据权利要求1所述的车端服务化功能测试方法，其特征在于，所述获取车端应用中的多个服务和所述多个服务对应的待测功能参数，包括：

获取车端应用需求信息；

3.根据权利要求2所述的车端服务化功能测试方法，其特征在于，所述根据所述服务化功能参数需求信息，得到所述多个服务对应的待测功能参数，包括：

4.根据权利要求3所述的车端服务化功能测试方法，其特征在于，获取车端应用中的多个服务和所述多个服务对应的待测功能参数之后，还包括：

5.根据权利要求1所述的车端服务化功能测试方法，其特征在于，所述根据所述待测场景类别和预设的待测场景生成策略，对所述多个服务和待测功能参数进行组合以生成待测场景，包括：

6.根据权利要求1所述的车端服务化功能测试方法，其特征在于，所述根据所述待测场景类别和预设的待测场景生成策略，对所述多个服务和待测功能参数进行组合以生成待测场景，包括：

7.根据权利要求4所述的车端服务化功能测试方法，其特征在于，根据所述待测场景，生成测试用例之后，还包括：

8.根据权利要求7所述的车端服务化功能测试方法，其特征在于，得到第二优先级信息之后，还包括：

9.根据权利要求8所述的车端服务化功能测试方法，其特征在于，所述得到新的测试用例并生成新的测试脚本之后，还包括：

10.根据权利要求7所述的车端服务化功能测试方法，其特征在于，控制预先配置的执行模拟器接收所述测试用例并执行对车端服务化功能的测试之后，还包括：

11.一种车端服务化功能测试装置，其特征在于，所述装置包括：

12.一种电子设备，其特征在于，所述电子设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现如权利要求1至10中任一项所述的车端服务化功能测试方法。

13.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，当所述计算机程序被计算机的处理器执行时，使计算机执行如权利要求1至10中任一项所述的车端服务化功能测试方法。