CN115495363A - 一种软件测试方法、电子设备及可读存储介质 - Google Patents

Abstract

本申请适用于软件测试技术领域，提供了一种软件测试方法、电子设备及可读存储介质，该方法包括：电子设备的电子控制单元中存储不同的软件测试阶段所需的测试策略，电子控制单元在接收到测试指令后，根据测试指令中携带的软件测试阶段查找需要的测试策略，然后基于查找到的测试策略对待测试程序进行测试，得到测试结果。相对于现有技术中在进行软件测试时，不同的软件测试阶段需要更换不同的测试设备的方法，本申请在一个电子设备中即可完成不同阶段的软件测试，省去了更换设备的时间，使软件测试更方便，效率更高。

Description

一种软件测试方法、电子设备及可读存储介质

技术领域

本申请属于软件测试技术领域，尤其涉及一种软件测试方法、电子设备及可读存储介质。

背景技术

软件测试是在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。在软件开发过程中，通过对软件的测试促进鉴定软件的正确性、完整性和安全性等。

软件测试分为不同的阶段，分别为单元测试阶段、集成测试阶段和确认测试阶段等。目前，在对软件进行测试时，不同的测试阶段需要使用不同的测试设备，若需要完成所有阶段的测试，则需要更换多个设备，软件测试工作效率低。

发明内容

本申请实施例提供了一种软件测试方法、电子设备及可读存储介质，可以解决软件测试效率低的问题。

第一方面，本申请实施例提供了一种软件测试方法，应用于电子设备中的电子控制单元，包括：

获取待测试程序；

在接收到测试指令后，基于所述测试指令携带的软件测试阶段，得到与所述软件测试阶段相匹配的测试策略；

基于与所述软件测试阶段相匹配的测试策略对所述待测试程序进行测试，得到与所述软件测试阶段相匹配的测试结果。

第二方面，本申请实施例提供了一种电子设备，包括电子控制单元，所述电子控制单元包括：

程序获取模块，用于获取待测试程序；

策略查询模块，用于在接收到测试指令后，基于所述测试指令携带的软件测试阶段，得到与所述软件测试阶段相匹配的测试策略；

软件测试模块，用于基于与所述软件测试阶段相匹配的测试策略对所述待测试程序进行测试，得到与所述软件测试阶段相匹配的测试结果。

第三方面，本申请实施例提供了一种终端设备，包括：存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面中任一项所述的软件测试方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面中任一项所述的软件测试方法。

第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面中任一项所述的软件测试方法。

本申请第一方面实施例与现有技术相比存在的有益效果是：本申请电子设备的电子控制单元中存储不同的软件测试阶段所需的测试策略，电子控制单元在接收到测试指令后，根据测试指令中携带的软件测试阶段查找需要的测试策略，然后基于查找到的测试策略对待测试程序进行测试，得到测试结果。相对于现有技术中在进行软件测试时，不同的软件测试阶段需要更换不同的测试设备的方法，本申请在一个电子设备中即可完成不同阶段的软件测试，省去了更换设备的时间，使软件测试更方便，效率更高。

可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一实施例提供的测试环境的结构示意图；

图2是本申请一实施例提供的软件测试方法的流程示意图；

图3是本申请一实施例提供的单元测试方法的流程示意图；

图4是本申请一实施例提供的集成测试方法的流程示意图；

图5是本申请一实施例提供的确认测试方法的流程示意图；

图6是本申请一实施例提供的电子控制单元的结构示意图；

图7是本申请一实施例提供的电子设备的结构示意图。

具体实施方式

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当……时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。

目前，软件测试的方法主要包括快速控制原型(Rapid Control Prototype，简称RCP)和硬件在环测试。RCP＝假的控制器+真的被控对象；HIL＝真的控制器+假的被控对象。由于RCP和硬件在环测试的应用范围有限，成本较高，现有的软件测试方法不能满足软件测试的需求。

基于上述原因，本申请提出一种软件测试方法。本申请在一个电子设备中设置虚拟电子控制单元(Electronic Control Unit，ECU)，在虚拟ECU中设置不同的测试策略，在进行不同阶段的软件测试时，使用不同的测试策略即可完成测试。电子设备可以为台式电脑、笔记本电脑等。

软件测试阶段可以包括单元测试、集成测试和确认测试等。本申请可以提前发现控制软件中存在的问题；便于使用调试功能分析仿真结果；便于连接自动化及智能测试工具，提高测试速度。另外，本申请中虚拟ECU为虚拟ECU程序，也就是本申请中软件测试的测试环境。

具体的，测试环境包括虚拟ECU和设备仿真模型，在确认测试时，若需要进行在环测试，虚拟ECU可以调用设备仿真模型进行测试。设备仿真模型可以为汽车仿真模型或摩托车仿真模型。

作为举例，在设备仿真模型为车辆仿真模型时，测试环境包括虚拟ECU和车辆仿真模型。

如图1所示，设备仿真模型可以包括虚拟CAN和I/O接口等。

另外，测试环境还可以通过标定工具对测试环境中的参数进行标定。通过配置工具对需要进行外部输入的数据进行配置。通过代码调试器对测试环境中的代码进行调试。

图2示出了本申请提供的软件测试方法的示意性流程图，参照图2，对该方法的详述如下：

S101，获取待测试程序。

在本实施例中，待测试程序可以是用户通过电子设备上的人机交互页面输入的程序，还可以是电子设备从存储设备中获取的程序。由于待测试程序是在虚拟的ECU中进行测试的，ECU为嵌入式软件，因此，待测试程序为嵌入式程序。

作为举例，待测试程序可以为应用在汽车上的程序或应用在摩托车上的程序等。

S102，在接收到测试指令后，基于所述测试指令携带的软件测试阶段，得到与所述软件测试阶段相匹配的测试策略。

在本实施例中，测试指令可以是用户通过点击电子设备上的按键或控件生成的指令。例如，用户点击电子设备上的单元测试按键后，生成测试指令，测试指令中携带的软件测试阶段为单元测试。

软件测试阶段包括单元测试、集成测试或确认测试。

预先在电子控制单元中设置不同的软件测试阶段匹配的测试策略。例如，单元测试匹配的测试策略为第一策略；集成测试匹配的测试策略为第二策略；确认测试匹配的测试策略为第三策略。第一策略、第二策略和第三策略为不同的策略。测试策略中可以包括需要提取的程序、对提取的程序的处理过程、测试用例和测试方法等。对提取的程序的处理过程包括头文件的配置和源文件的提取等。测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。

可选的，软件测试阶段和各个测试策略的对应关系可以以表格的形式进行存储。在接收到测试指令后，从表格中查找测试指令中携带的软件测试阶段对应的测试策略。

S103，基于与所述软件测试阶段相匹配的测试策略对所述待测试程序进行测试，得到与所述软件测试阶段相匹配的测试结果。

在本实施例中，测试策略由代码组成，运行测试策略中的代码可以对待测试程序进行测试，得到对应的测试结果。

本申请实施例中，电子设备的电子控制单元中存储不同的软件测试阶段所需的测试策略，电子控制单元在接收到测试指令后，根据测试指令中携带的软件测试阶段查找给阶段需要的测试策略，然后基于查找到的测试策略对待测试程序进行测试，得到测试结果。相对于现有技术中在进行软件测试时，不同的软件测试阶段需要更换不同的测试设备的方法，本申请在一个电子设备即可完成不同阶段的软件测试，也就是在一个测试平台上可以完成不同阶段的软件测试，省去了更换设备的时间，使软件测试更方便，效率更高、费用更少。

如图3所示，在一种可能的实现方式中，若软件测试阶段为单元测试，步骤S103的实现过程可以包括：

S201，从所述待测试程序中提取各个测试单元。

在本实施例中，单元测试是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，测试单元就是人为规定的最小的被测功能模块。

作为举例，若待测试程序为A，从A中提取出测试单元a和测试单元b。

S202，基于所述待测试程序中的头文件，配置各个所述测试单元运行所需的头文件。

在本实施例中，头文件作为一种包含功能函数、数据接口声明的载体文件，主要用于保存程序的声明。因此，为了使测试单元中的函数被调用，也就是在测试时测试单元中的函数可以正常运行，需要为测试单元配置头文件。待测试程序中存在测试单元运行所需的头文件，因此，从待测试程序的头文件中提取测试单元运行所需的头文件即可。具体的，从测试单元所在的.c和.h文件中可以查找该测试单元需要的头文件。

作为举例，若存在两个测试单元，分别为测试单元a和测试单元b。需要为测试单元a配置头文件，还需要为测试单元b配置头文件。

S203，提取每个所述测试单元中的第一源文件。

在本实施例中，源文件一般指用汇编语言或高级语言写出来的代码保存为文件后的结果。源文件为由源代码和数据构成的文件。源代码则是一组具有特定意义的可以实现特定功能的字符。源代码在大多数时候等于源文件。

一个测试单元中可以包括一个或多个源文件，本申请中将测试单元中包括的源文件记为第一源文件。

作为举例，从测试单元a中提取出一个第一源文件f。从测试单元b中提取出两个第一源文件，分别为第一源文件d和第一源文件k。

S204，提取所述第一源文件中的第一函数，并确定所述第一函数运行时是否需要调用第二函数，所述第二函数不在所述第一函数所在的第一源文件中。

在本实施例中，函数是一段封装好的，可以重复使用的代码。源文件中包括函数，将第一源文件中的函数记为第一函数。

在提取出第一函数后，判断第一函数在运行时是否需要调用其他函数，本申请中将第一函数需要调用的其他函数记为第二函数。

S205，若所述第一函数运行时不需要调用所述第二函数，基于各个所述测试单元对应的头文件，分别对各个所述测试单元中的第一函数进行测试，得到对所述待测试程序进行单元测试的测试结果。

在本实施例中，单元测试对应的测试策略中存在单元测试需要的测试用例，测试用例中给出了第一函数的输入和预期输出。在对第一函数进行测试时，可以使用单元测试需要的测试用例对第一函数进行测试。

在本实施例中，单元测试的测试结果为第一测试覆盖率。测试覆盖率是对测试完整程度的评测。测试覆盖率是由测试需求和测试用例的覆盖或已执行代码的覆盖的表示结果。测试覆盖率一方面可以衡量测试工作本身的有效性，提升测试效率，一方面可以提升代码质量，提升产品的可靠性，稳定性。第一测试覆盖率可以包括语句覆盖率、分支覆盖率和MC/DC覆盖率。语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。语句覆盖率＝被评价到的语句数量/可执行的语句总数x100％。分支覆盖技术用于覆盖控制流程图的所有分支，它至少覆盖一次决策点每个条件的所有可能结果(对与错)。MC/DC覆盖率为修正条件/判定覆盖。

在本实施例中，若第一测试覆盖率大于或等于第一预设值，则结束单元测试。第一预设值可以根据需要进行设置，例如，第一预设值可以为70％、75％或80％等。若第一测试覆盖率中包括多种覆盖率，则每种覆盖率均需要大于或等于对应的预设值。例如，第一测试覆盖率包括语句覆盖率和分支覆盖率，则语句覆盖率需要大于或等于第二预设值，分支覆盖率需要大于或等于第三预设值；第一预设值包括第二预设值和第三预设值。

若第一测试覆盖率小于第一预设值，则增加测试用例，继续对待测试程序进行单元测试，直至第一测试覆盖率大于或等于第一预设值。若第一测试覆盖率中包括多种覆盖率，且存在至少一种覆盖率小于对应的预设值，则需要继续进行单元测试。例如，第一测试覆盖率包括语句覆盖率和分支覆盖率；语句覆盖率需要小于第二预设值，分支覆盖率需要大于或等于第三预设值，则需要继续进行单元测试。

S206，若所述第一函数运行时需要调用所述第二函数，对需要调用的所述第二函数进行打桩处理，得到需要调用的所述第二函数的桩函数。

在本实施例中，若第一函数需要调用第二函数、且第二函数与第一函数不在同一个第一源文件中，则需要对第二函数进行打桩处理，得到桩函数。桩函数是模拟被测试模块所调用的模块，也就是用来代替第二函数。例如，第二函数B的桩函数为B1，也就是用B1代替B，那么，B称为原函数，B1称为桩函数。打桩就是编写或生成桩代码。对第二函数进行打桩处理，使第一函数在运行时不依赖于第二函数，使第一函数的测试更独立。

S207，基于各个所述测试单元对应的头文件和所述桩函数，分别对各个所述测试单元中的第一函数进行测试，得到对所述待测试程序进行单元测试的测试结果。

在本实施例中，步骤S207与步骤S205相似，请参照上述步骤S205的说明，在此不再赘述。

本申请实施例中，对待测试程序进行单元测试，可以检测每个测试单元能否实现设计需要的要求，发现测试单元存在的错误。

在一种可能的实现方式中，集成测试也可以称为组装测试，是在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试可以检验程序单元或部件的接口关系，逐步集成为符合要求的程序部件或整个***。

作为举例，先将测试单元S和测试单元H进行集成测试；然后加入测试单元Y，将测试单元S、测试单元H和测试单元Y进行集成测试。

如图4所示，具体的，若软件测试阶段为集成测试，步骤S103的实现过程可以包括：

S301，从所述待测试程序中提取应用层程序。

在本实施例中，应用层是为用户提供服务，具有网络传输的用户接口功能，主要负责在网络上用户与应用程序或应用程序与应用程序之间的通信。应用层是用户或应用程序接口与协议对网络访问的切入点。应用层程序也可以称为应用层软件。作为举例，如图1所示，应用层程序可以包括通过simulink模型自动生成的代码、手写代码和Autosar(汽车开放***架构)软件组件等。

S302，基于所述待测试程序中的头文件，配置所述应用层程序的头文件。

在本实施例中，为了在测试时应用层程序可以正常运行，需要为应用层程序配置头文件。

S303，提取所述应用层程序中的第二源文件。

在本实施例中，将应用层程序中的源文件记为第二源文件。

S304，若所述集成测试不包括所述待测试程序中的底层程序，基于所述应用层程序的头文件，对所述第二源文件进行集成测试，得到对所述待测试程序进行集成测试的测试结果。

在本实施例中，在提取出第二源文件后，判断集成测试是否需要对底层程序一并进行集成测试。具体的，测试指令中可以携带测试范围，若测试范围包括应用层程序，则需要对应用层程序进行集成测试，不需要对底层程序进行集成测试；若测试范围包括应用层程序和底层程序，则需要对应用层程序和底层程序进行集成测试。

测试范围可以用标识符进行表征，例如，若标识符为1，则不需要对底层程序进行集成测试；若标识符为2，则需要对底层程序进行集成测试。

若不需要对底层程序进行集成测试，则需要对第二源文件中的测试单元进行逐个集成测试，得到集成测试的测试结果。

集成测试对应的测试策略中存在集成测试需要的测试用例，根据集成测试需要的测试用例对第二源文件进行集成测试。测试用例可以进行重复使用。

集成测试的测试结果为第二测试覆盖率。第二测试覆盖率包括函数覆盖率和/或函数调用覆盖率。

若第二测试覆盖率包括函数覆盖率和函数调用覆盖率、且函数覆盖率大于或等于第四预设值、函数调用覆盖率大于或等于第五预设值，则集成测试完成。

若第二测试覆盖率包括函数覆盖率和函数调用覆盖率、且函数覆盖率大于或等于第四预设值、函数调用覆盖率小于第五预设值，则需要继续增加测试用例，对第二源文件继续进行集成测试。

若第二测试覆盖率包括函数覆盖率和函数调用覆盖率、且函数覆盖率小于第四预设值、函数调用覆盖率大于或等于第五预设值，则需要继续增加测试用例，对第二源文件继续进行集成测试。

S305，若所述集成测试包括所述待测试程序中的底层程序，提取所述待测试程序中的底层程序。

在本实施例中，底层程序也可以称为底层软件。底层程序通常是硬件的控制,逻辑运算的基本处理。例如，驱动程序。

作为举例，如图1所示，底层程序可以包括虚拟CAN程序、I/O接口程序、接口驱动程序和快闪存储器程序(FLASH ROM)等。

S306，基于所述待测试程序中的头文件，配置所述底层程序的头文件。

S307，提取所述底层程序中的第三源文件。

S308，基于所述应用层程序的头文件和所述底层程序的头文件，对所述第二源文件和所述第三源文件进行集成测试，得到对所述待测试程序进行集成测试的测试结果。

具体的，在对第二源文件进行集成测试时，需要一并将第三源文件陆续集成，进行集成测试，得到集成测试的测试结果。

步骤S308与步骤S304相似，请参照上述步骤S304的说明，在此不再赘述。

本申请实施例中，对待测试程序进行集成测试，可以检验与接口相关的错误，弥补单个测试单元测试的不足。

在一种可能的实现方式中，确认测试又称有效性测试，有效性测试是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定，它包含的信息就是软件确认测试的基础。

通过集成测试之后，软件已完全组装起来，接口方面的错误也已排除，确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。

如图5所示，具体的，若软件测试阶段为确认测试，步骤S103具体可以包括：

S401，从所述确认测试对应的测试策略中，提取所述确认测试对应的测试用例。

在本实施例中，确认测试对应的测试策略中存在进行确认测试需要的测试用例。

作为举例，若测试用例为对车辆中电机的转速控制的测试，测试用例中存在控制电机运行的输入参数和电机转速的预期的输出参数。

若测试用例为车辆中温度传感器的测试，测试用例中存在温度传感器的输入参数和预期的输出参数。

S402，若所述测试用例不需要进行在环测试，基于不需要进行所述在环测试的所述测试用例，对所述待测试程序进行确认测试，得到对所述待测试程序进行确定测试的测试结果。

在本实施例中，在环测试也可以称为硬件在环测试，硬件在环测试***是以实时处理器运行仿真模型来模拟受控对象的运行状态，通过I/O接口与被测的ECU连接，对被测ECU进行全方面的、***的测试。

确认测试的测试结果表征待测试程序是否满足预设要求。例如，电机转速是否在预设转速区间等。

S403，若所述测试用例需要进行在环测试，建立与所述设备仿真模型的通信连接。

在本实施例中，若测试用例需要进行在环测试，则需要将虚拟ECU与设备仿真模型建立通信连接，以便于将待测试程序的信号发送至设备仿真模型中，控制设备仿真模型进行动作。

具体的，从所述待测试程序中提取所述测试用例需要的接口程序，所述接口程序用于与所述设备仿真模型进行通信连接。

作为举例，提取待测试程序中CAN接口程序，利用CAN接口程序与设备仿真模型中的虚拟CAN接口进行通信连接。

S404，基于需要进行所述在环测试的所述测试用例和所述设备仿真模型，对所述待测试程序进行确认测试，得到对所述待测试程序进行确定测试的测试结果。

在本实施例中，在进行在环测试时，需要调用接口程序，以使得虚拟ECU可以控制设备仿真模型进行仿真测试。

在本实施例中，步骤S404与上述步骤S402相似，请参照上述步骤S402的说明，在此不再赘述。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

对应于上文实施例所述的软件测试方法，本申请实施例提供一种电子设备，该电子设备包括电子控制单元，如图6示出了电子控制单元的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图6，该电子控制单元500可以包括：程序获取模块510、策略查询模块520和软件测试模块530。

其中，程序获取模块510，用于获取待测试程序；

策略查询模块520，用于在接收到测试指令后，基于所述测试指令携带的软件测试阶段，得到与所述软件测试阶段相匹配的测试策略；

软件测试模块530，用于基于与所述软件测试阶段相匹配的测试策略对所述待测试程序进行测试，得到与所述软件测试阶段相匹配的测试结果。

在一种可能的实现方式中，在所述软件测试阶段为单元测试时，软件测试模块530具体可以用于：

从所述待测试程序中提取各个测试单元；

基于所述待测试程序中的头文件，配置各个所述测试单元运行所需的头文件；

提取每个所述测试单元中的第一源文件；

提取所述第一源文件中的第一函数，并确定所述第一函数运行时是否需要调用第二函数，所述第二函数不在所述第一函数所在的第一源文件中；

若所述第一函数运行时不需要调用所述第二函数，基于各个所述测试单元对应的头文件，分别对各个所述测试单元中的第一函数进行测试，得到对所述待测试程序进行单元测试的测试结果。

在一种可能的实现方式中，软件测试模块530具体还可以用于：

若所述第一函数运行时需要调用所述第二函数，对需要调用的所述第二函数进行打桩处理，得到需要调用的所述第二函数的桩函数；

基于各个所述测试单元对应的头文件和所述桩函数，分别对各个所述测试单元中的第一函数进行测试，得到对所述待测试程序进行单元测试的测试结果。

在一种可能的实现方式中，在所述软件测试阶段为集成测试时，软件测试模块530具体可以用于：

从所述待测试程序中提取应用层程序；

基于所述待测试程序中的头文件，配置所述应用层程序的头文件；

提取所述应用层程序中的第二源文件；

若所述集成测试不包括所述待测试程序中的底层程序，基于所述应用层程序的头文件，对所述第二源文件进行集成测试，得到对所述待测试程序进行集成测试的测试结果。

在一种可能的实现方式中，软件测试模块530具体还可以用于：

若所述集成测试包括所述待测试程序中的底层程序，提取所述待测试程序中的底层程序；

基于所述待测试程序中的头文件，配置所述底层程序的头文件；

提取所述底层程序中的第三源文件；

基于所述应用层程序的头文件和所述底层程序的头文件，对所述第二源文件和所述第三源文件进行集成测试，得到对所述待测试程序进行集成测试的测试结果。

在一种可能的实现方式中，在所述软件测试阶段为确认测试时，软件测试模块530具体可以用于：

从所述确认测试对应的测试策略中，提取所述确认测试对应的测试用例；

若所述测试用例不需要进行在环测试，基于不需要进行所述在环测试的所述测试用例，对所述待测试程序进行确认测试，得到对所述待测试程序进行确定测试的测试结果。

在一种可能的实现方式中，软件测试模块530具体还可以用于：

在所述从所述确认测试对应的测试策略中，提取所述确认测试对应的测试用例之后，所述方法还包括：

若所述测试用例需要进行在环测试，建立与所述设备仿真模型的通信连接；

基于需要进行所述在环测试的所述测试用例和所述设备仿真模型，对所述待测试程序进行确认测试，得到对所述待测试程序进行确定测试的测试结果。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述***中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请实施例还提供了一种电子设备，参见图7，该终端设备600可以包括：至少一个电子控制单元610、存储器620以及存储在所述存储器620中并可在所述至少一个电子控制单元610上运行的计算机程序，所述电子控制单元610执行所述计算机程序时实现上述任意各个方法实施例中的步骤，例如图2所示实施例中的步骤S101至步骤S103。或者，电子控制单元610执行所述计算机程序时实现上述各装置实施例中各模块/单元的功能，例如图6所示程序获取模块510至软件测试模块530的功能。

示例性的，计算机程序可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器620中，并由电子控制单元610执行，以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序段，该程序段用于描述计算机程序在终端设备600中的执行过程。

存储器620可以是终端设备的内部存储单元，也可以是终端设备的外部存储设备，例如插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。所述存储器620用于存储所述计算机程序以及终端设备所需的其他程序和数据。所述存储器620还可以用于暂时地存储已经输出或者将要输出的数据。

本申请实施例提供的软件测试方法可以应用于计算机、平板电脑、笔记本电脑、上网本、个人数字助理(personal digital assistant，PDA)等终端设备上，本申请实施例对终端设备的具体类型不作任何限制。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的终端设备、装置和方法，可以通过其它的方式实现。例如，以上所描述的终端设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被一个或多个处理器执行时，可实现上述各个方法实施例的步骤。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被一个或多个处理器执行时，可实现上述各个方法实施例的步骤。

同样，作为一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时实现可实现上述各个方法实施例中的步骤。

其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random AccessMemory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括是电载波信号和电信信号。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种软件测试方法，其特征在于，应用于电子设备中的电子控制单元，所述方法包括：

获取待测试程序；

在接收到测试指令后，基于所述测试指令携带的软件测试阶段，得到与所述软件测试阶段相匹配的测试策略；

基于与所述软件测试阶段相匹配的测试策略对所述待测试程序进行测试，得到与所述软件测试阶段相匹配的测试结果。

2.如权利要求1所述的软件测试方法，其特征在于，在所述软件测试阶段为单元测试时，所述基于与所述软件测试阶段相匹配的测试策略对所述待测试程序进行测试，得到与所述软件测试阶段相匹配的测试结果，包括：

从所述待测试程序中提取各个测试单元；

基于所述待测试程序中的头文件，配置各个所述测试单元运行所需的头文件；

提取每个所述测试单元中的第一源文件；

提取所述第一源文件中的第一函数，并确定所述第一函数运行时是否需要调用第二函数，所述第二函数不在所述第一函数所在的第一源文件中；

若所述第一函数运行时不需要调用所述第二函数，基于各个所述测试单元对应的头文件，分别对各个所述测试单元中的第一函数进行测试，得到对所述待测试程序进行单元测试的测试结果。

3.如权利要求2所述的软件测试方法，其特征在于，在所述确定所述第一函数运行时是否需要调用第二函数之后，所述方法还包括：

若所述第一函数运行时需要调用所述第二函数，对需要调用的所述第二函数进行打桩处理，得到需要调用的所述第二函数的桩函数；

基于各个所述测试单元对应的头文件和所述桩函数，分别对各个所述测试单元中的第一函数进行测试，得到对所述待测试程序进行单元测试的测试结果。

4.如权利要求1所述的软件测试方法，其特征在于，在所述软件测试阶段为集成测试时，所述基于与所述软件测试阶段相匹配的测试策略对所述待测试程序进行测试，得到与所述软件测试阶段相匹配的测试结果，包括：

从所述待测试程序中提取应用层程序；

基于所述待测试程序中的头文件，配置所述应用层程序的头文件；

提取所述应用层程序中的第二源文件；

若不需要对所述待测试程序中的底层程序进行所述集成测试，基于所述应用层程序的头文件，对所述第二源文件进行集成测试，得到对所述待测试程序进行集成测试的测试结果。

5.如权利要求4所述的软件测试方法，其特征在于，在所述提取所述应用层程序中的第二源文件之后，所述方法还包括：

若需要对所述待测试程序中的底层程序进行所述集成测试，提取所述待测试程序中的底层程序；

基于所述待测试程序中的头文件，配置所述底层程序的头文件；

提取所述底层程序中的第三源文件；

基于所述应用层程序的头文件和所述底层程序的头文件，对所述第二源文件和所述第三源文件进行集成测试，得到对所述待测试程序进行集成测试的测试结果。

6.如权利要求1所述的软件测试方法，其特征在于，在所述软件测试阶段为确认测试时，所述基于与所述软件测试阶段相匹配的测试策略对所述待测试程序进行测试，得到与所述软件测试阶段相匹配的测试结果，包括：

从所述确认测试对应的测试策略中，提取所述确认测试对应的测试用例；

若所述测试用例不需要进行在环测试，基于不需要进行所述在环测试的所述测试用例，对所述待测试程序进行确认测试，得到对所述待测试程序进行确定测试的测试结果。

7.如权利要求6所述的软件测试方法，其特征在于，所述电子设备中还设有设备仿真模型；

在所述从所述确认测试对应的测试策略中，提取所述确认测试对应的测试用例之后，所述方法还包括：

若所述测试用例需要进行在环测试，建立与所述设备仿真模型的通信连接；

基于需要进行所述在环测试的所述测试用例和所述设备仿真模型，对所述待测试程序进行确认测试，得到对所述待测试程序进行确定测试的测试结果。

8.一种电子设备，其特征在于，包括电子控制单元，所述电子控制单元包括：

程序获取模块，用于获取待测试程序；

策略查询模块，用于在接收到测试指令后，基于所述测试指令携带的软件测试阶段，得到与所述软件测试阶段相匹配的测试策略；

软件测试模块，用于基于与所述软件测试阶段相匹配的测试策略对所述待测试程序进行测试，得到与所述软件测试阶段相匹配的测试结果。

9.一种电子设备，包括存储器、电子控制单元以及存储在所述存储器中并可在所述电子控制单元上运行的计算机程序，其特征在于，所述电子控制单元执行所述计算机程序时实现如权利要求1至7任一项所述的软件测试方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的软件测试方法。

Images