CN115495363A

CN115495363A - Software testing method, electronic equipment and readable storage medium

Info

Publication number: CN115495363A
Application number: CN202211166699.XA
Authority: CN
Inventors: 蔡军
Original assignee: If Technology Co Ltd
Current assignee: If Technology Co Ltd
Priority date: 2022-09-23
Filing date: 2022-09-23
Publication date: 2022-12-20

Abstract

The application is applicable to the technical field of software testing, and provides a software testing method, electronic equipment and a readable storage medium, wherein the method comprises the following steps: the electronic control unit of the electronic equipment stores test strategies required by different software test stages, after receiving the test instruction, the electronic control unit searches the required test strategies according to the software test stages carried in the test instruction, and then tests the program to be tested based on the searched test strategies to obtain a test result. Compared with the method that different testing devices need to be replaced in different software testing stages when software testing is carried out in the prior art, the software testing method and the software testing device can complete software testing in different stages in one electronic device, save the time for replacing the device, enable software testing to be more convenient and have higher efficiency.

Description

Software testing method, electronic equipment and readable storage medium

Technical Field

The present application relates to software testing technologies, and in particular, to a software testing method, an electronic device, and a readable storage medium.

Background

Software testing is the process of operating a program under specified conditions to discover bugs, to measure software quality, and to evaluate whether it can meet design requirements. In the software development process, the correctness, integrity, safety and the like of the software are facilitated to be identified through testing of the software.

The software test is divided into different stages, namely a unit test stage, an integration test stage, a confirmation test stage and the like. At present, when software is tested, different testing devices are needed to be used in different testing stages, if testing in all stages needs to be completed, a plurality of devices need to be replaced, and the software testing efficiency is low.

Disclosure of Invention

The embodiment of the application provides a software testing method, electronic equipment and a readable storage medium, and can solve the problem of low software testing efficiency.

In a first aspect, an embodiment of the present application provides a software testing method, which is applied to an electronic control unit in an electronic device, and includes:

acquiring a program to be tested;

after receiving a test instruction, obtaining a test strategy matched with a software test stage based on the software test stage carried by the test instruction;

and testing the program to be tested based on the testing strategy matched with the software testing stage to obtain a testing result matched with the software testing stage.

In a second aspect, an embodiment of the present application provides an electronic device, including an electronic control unit, where the electronic control unit includes:

the program acquisition module is used for acquiring a program to be tested;

the strategy query module is used for obtaining a test strategy matched with a software test stage based on the software test stage carried by the test instruction after receiving the test instruction;

and the software testing module is used for testing the program to be tested based on the testing strategy matched with the software testing stage to obtain a testing result matched with the software testing stage.

In a third aspect, an embodiment of the present application provides a terminal device, including: a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the software testing method of any one of the above first aspects when executing the computer program.

In a fourth aspect, the present application provides a computer-readable storage medium, where a computer program is stored, and the computer program, when executed by a processor, implements the software testing method according to any one of the first aspect.

In a fifth aspect, an embodiment of the present application provides a computer program product, which, when run on a terminal device, causes the terminal device to execute the software testing method according to any one of the above first aspects.

Compared with the prior art, the embodiment of the first aspect of the application has the following beneficial effects: the electronic control unit of the electronic equipment stores different testing strategies required by the software testing stage, searches the required testing strategies according to the software testing stage carried in the testing instruction after receiving the testing instruction, and then tests the program to be tested based on the searched testing strategies to obtain the testing result. Compared with the method that different testing devices need to be replaced in different software testing stages when software testing is carried out in the prior art, the software testing method and the software testing device can complete software testing in different stages in one electronic device, save the time for replacing the device, enable software testing to be more convenient and have higher efficiency.

It is understood that the beneficial effects of the second aspect to the fifth aspect can be referred to the related description of the first aspect, and are not described herein again.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.

FIG. 1 is a schematic diagram of a test environment according to an embodiment of the present disclosure;

FIG. 2 is a schematic flowchart of a software testing method according to an embodiment of the present application;

FIG. 3 is a flow chart illustrating a method for testing a unit according to an embodiment of the present application;

FIG. 4 is a flowchart illustrating an integration testing method according to an embodiment of the present application;

FIG. 5 is a schematic flow chart illustrating a method for performing a validation test according to an embodiment of the present application;

FIG. 6 is a schematic structural diagram of an electronic control unit according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As used in the specification and appended claims, the term "if" may be interpreted contextually as "when 8230; \8230;" or "once" or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".

Furthermore, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used for distinguishing between descriptions and not necessarily for describing or implying relative importance.

Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise.

At present, a software testing method mainly includes Rapid Control Protocol (RCP) and hardware-in-the-loop testing. RCP = fake controller + true controlled object; HIL = true controller + false controlled object. Because the application range of the RCP and hardware in the ring test is limited, the cost is higher, and the existing software test method can not meet the requirement of the software test.

Based on the reasons, the application provides a software testing method. The method comprises the steps of setting a virtual Electronic Control Unit (ECU) in one Electronic device, setting different test strategies in the virtual ECU, and completing the test by using different test strategies when software tests at different stages are performed. The electronic device may be a desktop computer, a notebook computer, or the like.

The software testing phase may include unit testing, integration testing, validation testing, and the like. The method and the device can find the problems existing in the control software in advance; the simulation result is convenient to analyze by using the debugging function; the automatic and intelligent test tool is convenient to connect, and the test speed is improved. In addition, the virtual ECU in the present application is a virtual ECU program, that is, a test environment for software testing in the present application.

Specifically, the test environment includes a virtual ECU and a device simulation model, and when the test is confirmed, if the in-loop test needs to be performed, the virtual ECU may call the device simulation model to perform the test. The device simulation model may be an automobile simulation model or a motorcycle simulation model.

By way of example, when the device simulation model is a vehicle simulation model, the test environment includes a virtual ECU and a vehicle simulation model.

As shown in FIG. 1, the device simulation model may include a virtual CAN and I/O interfaces, among others.

In addition, the test environment can also calibrate parameters in the test environment through a calibration tool. And configuring the data needing external input through a configuration tool. Debugging the code in the test environment through a code debugger.

Fig. 2 shows a schematic flow chart of a software testing method provided by the present application, and with reference to fig. 2, the method is described in detail as follows:

s101, acquiring a program to be tested.

In this embodiment, the program to be tested may be a program input by a user through a man-machine interaction page on the electronic device, or may be a program acquired by the electronic device from the storage device. Because the program to be tested is tested in the virtual ECU, and the ECU is embedded software, the program to be tested is an embedded program.

By way of example, the program to be tested may be a program applied to a car or a program applied to a motorcycle, etc.

S102, after receiving a test instruction, obtaining a test strategy matched with the software test stage based on the software test stage carried by the test instruction.

In this embodiment, the test instruction may be an instruction generated by a user by clicking a button or control on the electronic device. For example, after a user clicks a unit test key on the electronic device, a test instruction is generated, and a software test stage carried in the test instruction is a unit test.

The software testing phase includes unit testing, integration testing, or validation testing.

Different test strategies matched with the software test stage are set in the electronic control unit in advance. For example, the unit tests the matching test policy as a first policy; the test strategy matched with the integrated test is a second strategy; and confirming that the test strategy matched with the test is the third strategy. The first policy, the second policy, and the third policy are different policies. The test strategy may include a program to be extracted, a processing procedure of the extracted program, a test case, a test method, and the like. The processing procedure of the extracted program includes configuration of a header file, extraction of a source file, and the like. The test case is a description of a test task performed on a specific software product, and embodies a test scheme, a method, a technology and a strategy.

Optionally, the corresponding relationship between the software testing phase and each testing policy may be stored in a table form. And after receiving the test instruction, searching a test strategy corresponding to the software test stage carried in the test instruction from the table.

S103, testing the program to be tested based on the testing strategy matched with the software testing stage to obtain a testing result matched with the software testing stage.

In this embodiment, the test policy is composed of codes, and the codes in the test policy are run to test the program to be tested, so as to obtain a corresponding test result.

In the embodiment of the application, the electronic control unit of the electronic device stores different testing strategies required by software testing stages, after receiving the testing instruction, the electronic control unit searches the testing strategies required by the stages according to the software testing stages carried in the testing instruction, and then tests the program to be tested based on the searched testing strategies to obtain the testing result. Compared with the method that different testing devices need to be replaced at different software testing stages when software testing is carried out in the prior art, the software testing at different stages can be completed on one electronic device, namely the software testing at different stages can be completed on one testing platform, so that the time for replacing the devices is saved, the software testing is more convenient, the efficiency is higher, and the cost is less.

As shown in fig. 3, in a possible implementation manner, if the software testing stage is a unit test, the implementation process of step S103 may include:

s201, extracting each test unit from the program to be tested.

In this embodiment, the unit test refers to checking and verifying the minimum testable unit in the software. For the meaning of the unit in the unit test, generally, the specific meaning is determined according to the actual situation, for example, the unit in the C language refers to a function, the unit in the Java refers to a class, and the graphical software may refer to a window or a menu. In general, the test unit is the minimum functional module under test specified by human.

By way of example, if the program to be tested is a, test unit a and test unit b are extracted from a.

S202, configuring the head files required by the running of each test unit based on the head files in the program to be tested.

In this embodiment, the header file is used as a carrier file containing function functions and data interface declarations, and is mainly used for storing declarations of programs. Therefore, in order to make the function in the test unit called, that is, the function in the test unit can normally operate at the time of test, it is necessary to configure a header file for the test unit. The head files required by the running of the test unit exist in the program to be tested, so that the head files required by the running of the test unit are extracted from the head files of the program to be tested. Specifically, the head file required by the test unit can be searched from the files of.c and.h where the test unit is located.

By way of example, if there are two test units, test unit a and test unit b, respectively. It is necessary to configure the header file for the test unit a and also to configure the header file for the test unit b.

S203, extracting a first source file in each test unit.

In this embodiment, the source file generally refers to the result of saving the code written in the assembly language or the high-level language as a file. A source file is a file made up of source code and data. The source code is a set of characters having a specific meaning that can implement a specific function. The source code is most of the time equal to the source file.

One or more source files may be included in one test unit, and a source file included in a test unit is referred to as a first source file in this application.

By way of example, a first source file f is extracted from test unit a. Two first source files, namely a first source file d and a first source file k, are extracted from the test unit b.

S204, extracting a first function in the first source file, and determining whether a second function is required to be called when the first function runs, wherein the second function is not in the first source file where the first function is located.

In this embodiment, the function is a piece of packaged, reusable code. The source files comprise functions, and the functions in the first source file are marked as first functions.

After the first function is extracted, whether the first function needs to call other functions during operation is judged, and the other functions needing to be called by the first function are marked as second functions in the application.

And S205, if the second function does not need to be called when the first function runs, respectively testing the first function in each test unit based on the header file corresponding to each test unit to obtain a test result of unit testing the program to be tested.

In this embodiment, a test case required by the unit test exists in the test strategy corresponding to the unit test, and the test case gives an input and an expected output of the first function. When the first function is tested, the first function can be tested by using a test case required by unit test.

In this embodiment, the test result of the unit test is the first test coverage. Test coverage is an assessment of the integrity of the test. Test coverage is the result of a representation of coverage by test requirements and test cases or coverage by executed code. The test coverage rate can measure the effectiveness of test work per se and improve the test efficiency, and on the one hand, the code quality and the reliability and the stability of products can be improved. The first test coverage may include statement coverage, branch coverage, and MC/DC coverage. Statement coverage is the design of a number of test cases and the running of the program under test so that each executable statement is executed at least once. Statement coverage = number of statements evaluated/total number of executable statements x100%. The branch override technique is used to override all branches of the control flow graph, which overrides all possible outcomes (true versus false) for each condition at a decision point at least once. The MC/DC coverage is the correction condition/decision coverage.

In this embodiment, if the first test coverage is greater than or equal to the first preset value, the unit test is ended. The first preset value may be set as needed, for example, the first preset value may be 70%, 75%, or 80%. If the first test coverage rate includes multiple coverage rates, each coverage rate needs to be greater than or equal to a corresponding preset value. For example, the first test coverage includes statement coverage and branch coverage, and then the statement coverage needs to be greater than or equal to a second preset value, and the branch coverage needs to be greater than or equal to a third preset value; the first preset value includes a second preset value and a third preset value.

And if the first test coverage rate is smaller than the first preset value, adding test cases, and continuing to perform unit test on the program to be tested until the first test coverage rate is larger than or equal to the first preset value. If the first test coverage rate includes multiple coverage rates and at least one coverage rate is smaller than the corresponding preset value, the unit test is required to be continued. For example, the first test coverage includes statement coverage and branch coverage; and if the statement coverage rate needs to be less than a second preset value and the branch coverage rate needs to be greater than or equal to a third preset value, continuing the unit test.

S206, if the first function needs to call the second function when running, piling the second function needing to be called to obtain a pile function of the second function needing to be called.

In this embodiment, if the first function needs to call the second function, and the second function and the first function are not in the same first source file, the second function needs to be subjected to pile driving processing to obtain a pile function. The stub function is a module that simulates the module being called by the test module, i.e. is used instead of the second function. For example, the second function B has a stub function of B1, i.e. B1 is substituted for B, then B is called the primitive function and B1 is called the stub function. Piling is the writing or generation of pile code. And piling the second function, so that the first function does not depend on the second function during running, and the test of the first function is more independent.

And S207, respectively testing the first function in each test unit based on the header file and the stub function corresponding to each test unit to obtain a test result for performing unit test on the program to be tested.

In this embodiment, step S207 is similar to step S205, please refer to the description of step S205, and will not be repeated herein.

In the embodiment of the application, the unit test is performed on the program to be tested, whether each test unit can meet the requirement of design requirements can be detected, and errors existing in the test units can be found.

In one possible implementation, the integration test, which may also be referred to as an assembly test, is an ordered, incremental test of all program modules based on the unit test. The integration test can check the interface relation of the program unit or the component, and gradually integrate the program unit or the component into a program component or the whole system which meets the requirement.

For example, first, the test unit S and the test unit H are subjected to an integration test; then, a test unit Y is added, and the test unit S, the test unit H and the test unit Y are subjected to integration test.

As shown in fig. 4, specifically, if the software testing stage is an integration test, the implementation process of step S103 may include:

s301, extracting the application layer program from the program to be tested.

In this embodiment, the application layer is used for providing services for users, has a user interface function of network transmission, and is mainly responsible for communication between users and applications or between applications and applications on the network. The application layer is the entry point for network access by users or application program interfaces and protocols. An application layer program may also be referred to as application layer software. By way of example, as shown in fig. 1, the application layer program may include code automatically generated by a simulink model, handwritten code, autosar (open systems architecture for automobiles) software components, and the like.

S302, configuring the header file of the application layer program based on the header file in the program to be tested.

In this embodiment, in order that the application layer program can normally run during testing, a header file needs to be configured for the application layer program.

S303, extracting a second source file in the application layer program.

In this embodiment, a source file in the application layer program is referred to as a second source file.

S304, if the integration test does not comprise the bottom program in the programs to be tested, the second source file is subjected to the integration test based on the header file of the application layer program, and a test result of the integration test on the programs to be tested is obtained.

In this embodiment, after the second source file is extracted, it is determined whether the integration test needs to be performed on the underlying program together. Specifically, the test instruction may carry a test range, and if the test range includes an application layer program, the application layer program needs to be subjected to an integration test, and the underlying program does not need to be subjected to the integration test; if the test range comprises the application layer program and the bottom layer program, the integration test of the application layer program and the bottom layer program is needed.

The test scope may be characterized by an identifier, for example, if the identifier is 1, then the integration test on the underlying program is not required; if the identifier is 2, then the integration test needs to be performed on the underlying program.

If the integration test of the bottom layer program is not needed, the test units in the second source file need to be subjected to the one-by-one integration test to obtain a test result of the integration test.

And the test strategy corresponding to the integration test has a test case required by the integration test, and the second source file is subjected to the integration test according to the test case required by the integration test. The test case can be reused.

The test result of the integration test is a second test coverage. The second test coverage includes function coverage and/or function call coverage.

And if the second test coverage rate comprises a function coverage rate and a function call coverage rate, the function coverage rate is greater than or equal to a fourth preset value, and the function call coverage rate is greater than or equal to a fifth preset value, the integration test is completed.

If the second test coverage rate comprises a function coverage rate and a function call coverage rate, the function coverage rate is greater than or equal to a fourth preset value, and the function call coverage rate is smaller than a fifth preset value, the test cases need to be added continuously, and the second source file is subjected to the integration test continuously.

If the second test coverage rate comprises a function coverage rate and a function call coverage rate, the function coverage rate is smaller than a fourth preset value, and the function call coverage rate is larger than or equal to a fifth preset value, the test cases need to be added continuously, and the second source file is subjected to integration test continuously.

S305, if the integration test comprises the bottom program in the programs to be tested, extracting the bottom program in the programs to be tested.

In this embodiment, the underlying program may also be referred to as underlying software. The underlying program is usually the basic process of controlling, logical operations of hardware. Such as a driver.

By way of example, as shown in FIG. 1, the underlying programs may include virtual CAN programs, I/O interface programs, interface drivers, and FLASH memory programs (FLASH ROM), among others.

S306, configuring the header file of the bottom layer program based on the header file in the program to be tested.

S307, extracting a third source file in the bottom layer program.

S308, performing integration test on the second source file and the third source file based on the header file of the application layer program and the header file of the bottom layer program to obtain a test result of performing integration test on the program to be tested.

Specifically, when performing an integration test on the second source file, the third source files need to be integrated one by one, and the integration test is performed to obtain a test result of the integration test.

Step S308 is similar to step S304, please refer to the description of step S304, and will not be described herein again.

In the embodiment of the application, the integrated test is carried out on the program to be tested, so that errors related to the interface can be detected, and the defect of the test of a single test unit is overcome.

In one possible implementation, the validation test is also called a validity test, which is a method of using a black box test to verify whether the software to be tested meets the requirements listed in the requirement specification under a simulated environment. The task is to verify that the functionality and performance and other characteristics of the software are consistent with the user's requirements. The functional and performance requirements for software are specified explicitly in the software requirements specification, and the information it contains is the basis for the software validation test.

After the integration test, the software is completely assembled, the error in the interface is eliminated, and the confirmation test can be started. The validation test should check whether the software can operate as per the contract requirements, i.e., whether the validation criteria in the software requirements specification are met.

As shown in fig. 5, specifically, if the software testing stage is a confirmation test, the step S103 may specifically include:

s401, extracting a test case corresponding to the confirmation test from the test strategy corresponding to the confirmation test.

In this embodiment, the test strategy corresponding to the verification test includes a test case required for performing the verification test.

For example, if the test case is a test for controlling the rotation speed of a motor in a vehicle, an input parameter for controlling the operation of the motor and an expected output parameter for the rotation speed of the motor exist in the test case.

If the test case is the test of the temperature sensor in the vehicle, the input parameters and the expected output parameters of the temperature sensor exist in the test case.

S402, if the test case does not need to be subjected to the in-loop test, performing a confirmation test on the program to be tested based on the test case which does not need to be subjected to the in-loop test to obtain a test result for performing a confirmation test on the program to be tested.

In this embodiment, the in-loop test may also be referred to as a hardware-in-loop test, where the hardware-in-loop test system simulates an operating state of a controlled object by running a simulation model on a real-time processor, and is connected to the tested ECU through an I/O interface to perform an omnidirectional and systematic test on the tested ECU.

And confirming whether the testing result of the test represents that the program to be tested meets the preset requirement or not. For example, whether the motor speed is in a preset speed interval, etc.

And S403, if the test case needs to be subjected to in-loop test, establishing communication connection with the equipment simulation model.

In this embodiment, if the test case needs to perform an in-loop test, the virtual ECU needs to establish a communication connection with the device simulation model, so as to send a signal of the program to be tested to the device simulation model and control the device simulation model to operate.

Specifically, an interface program required by the test case is extracted from the program to be tested, and the interface program is used for being in communication connection with the device simulation model.

For example, a CAN interface program in the program to be tested is extracted, and the CAN interface program is used for performing communication connection with a virtual CAN interface in the device simulation model.

S404, based on the test case and the equipment simulation model which need to be subjected to the in-loop test, the program to be tested is subjected to a confirmation test, and a test result of the program to be tested is obtained.

In this embodiment, when performing the in-loop test, it is necessary to call an interface program so that the virtual ECU can control the device simulation model to perform the simulation test.

In this embodiment, step S404 is similar to step S402, please refer to the description of step S402, and the description thereof is omitted here.

It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

Corresponding to the software testing method described in the foregoing embodiments, the present embodiment provides an electronic device, which includes an electronic control unit, and fig. 6 shows a structural block diagram of the electronic control unit, and for convenience of description, only the parts related to the present embodiment are shown.

Referring to fig. 6, the electronic control unit 500 may include: a program acquisition module 510, a policy query module 520, and a software testing module 530.

The program obtaining module 510 is configured to obtain a program to be tested;

the strategy query module 520 is configured to, after receiving the test instruction, obtain a test strategy matching the software test stage based on the software test stage carried by the test instruction;

a software testing module 530, configured to test the program to be tested based on the testing policy matched with the software testing stage, so as to obtain a testing result matched with the software testing stage.

In a possible implementation manner, when the software testing phase is a unit test, the software testing module 530 may specifically be configured to:

extracting each test unit from the program to be tested;

configuring a header file required by the running of each test unit based on the header file in the program to be tested;

extracting a first source file in each test unit;

extracting a first function in the first source file, and determining whether a second function is required to be called when the first function runs, wherein the second function is not in the first source file where the first function is located;

if the first function does not need to call the second function when running, the first function in each test unit is tested respectively based on the header file corresponding to each test unit, and a test result of unit testing on the program to be tested is obtained.

In a possible implementation manner, the software testing module 530 may be further specifically configured to:

if the first function needs to be called when running, piling the second function needing to be called to obtain a pile function of the second function needing to be called;

and respectively testing the first function in each test unit based on the head file and the stub function corresponding to each test unit to obtain a test result for performing unit test on the program to be tested.

In a possible implementation manner, when the software testing stage is an integration test, the software testing module 530 may specifically be configured to:

extracting an application layer program from the program to be tested;

configuring a header file of the application layer program based on the header file in the program to be tested;

extracting a second source file in the application layer program;

and if the integration test does not comprise the bottom program in the programs to be tested, performing the integration test on the second source file based on the header file of the application layer program to obtain a test result of performing the integration test on the programs to be tested.

if the integration test comprises a bottom program in the programs to be tested, extracting the bottom program in the programs to be tested;

configuring a header file of the bottom layer program based on the header file in the program to be tested;

extracting a third source file in the bottom layer program;

and performing integration test on the second source file and the third source file based on the header file of the application layer program and the header file of the bottom layer program to obtain a test result of performing integration test on the program to be tested.

In a possible implementation manner, when the software testing stage is a confirmation test, the software testing module 530 may specifically be configured to:

extracting a test case corresponding to the confirmation test from the test strategy corresponding to the confirmation test;

if the test case does not need to be subjected to the in-loop test, performing a confirmation test on the program to be tested based on the test case which does not need to be subjected to the in-loop test to obtain a test result for performing a determination test on the program to be tested.

after extracting the test case corresponding to the validation test from the test strategy corresponding to the validation test, the method further includes:

if the test case needs to be subjected to in-loop test, establishing communication connection with the equipment simulation model;

and performing confirmation test on the program to be tested based on the test case and the equipment simulation model which need to perform the in-loop test to obtain a test result for performing the confirmation test on the program to be tested.

It should be noted that, for the information interaction, execution process, and other contents between the above-mentioned devices/units, the specific functions and technical effects thereof are based on the same concept as those of the embodiment of the method of the present application, and specific reference may be made to the part of the embodiment of the method, which is not described herein again.

It should be clear to those skilled in the art that, for convenience and simplicity of description, the foregoing division of the functional units and modules is only used for illustration, and in practical applications, the above function distribution may be performed by different functional units and modules as needed, that is, the internal structure of the apparatus may be divided into different functional units or modules to perform all or part of the above described functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

An embodiment of the present application further provides an electronic device, and referring to fig. 7, the terminal device 600 may include: at least one electronic control unit 610, a memory 620, and a computer program stored in the memory 620 and operable on the at least one electronic control unit 610, wherein the electronic control unit 610, when executing the computer program, implements the steps in any of the above-described method embodiments, such as the steps S101 to S103 in the embodiment shown in fig. 2. Alternatively, the electronic control unit 610, when executing the computer program, implements the functions of the modules/units in the above-described device embodiments, such as the functions of the program acquisition module 510 to the software testing module 530 shown in fig. 6.

Illustratively, the computer program may be divided into one or more modules/units, which are stored in the memory 620 and executed by the electronic control unit 610 to accomplish the present application. The one or more modules/units may be a series of computer program segments capable of performing specific functions, which are used to describe the execution of the computer program in the terminal device 600.

The memory 620 may be an internal storage unit of the terminal device, or may be an external storage device of the terminal device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like. The memory 620 is used for storing the computer program and other programs and data required by the terminal device. The memory 620 may also be used to temporarily store data that has been output or is to be output.

The software testing method provided by the embodiment of the application can be applied to terminal equipment such as a computer, a tablet computer, a notebook computer, a netbook, a Personal Digital Assistant (PDA) and the like, and the specific type of the terminal equipment is not limited at all.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed terminal device, apparatus and method may be implemented in other ways. For example, the above-described terminal device embodiments are merely illustrative, and for example, the division of the modules or units is only one logical function division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in the form of hardware, or may also be implemented in the form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the methods of the embodiments described above may be implemented by a computer program, which may be stored in a computer readable storage medium and used by one or more processors to implement the steps of the embodiments of the methods described above.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow of the method of the embodiments described above can be realized by a computer program, which can be stored in a computer-readable storage medium and can realize the steps of the method embodiments described above when the computer program is executed by one or more processors.

Also, as a computer program product, when the computer program product runs on a terminal device, the terminal device is enabled to implement the steps in the above-mentioned method embodiments when executed.

Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, read-Only Memory (ROM), random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain suitable additions or subtractions depending on the requirements of legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media may not include electrical carrier signals or telecommunication signals in accordance with legislation and patent practice.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not depart from the spirit and scope of the embodiments of the present application, and they should be construed as being included in the present application.

Claims

1. A software testing method is characterized by being applied to an electronic control unit in electronic equipment, and the method comprises the following steps:

acquiring a program to be tested;

2. The software testing method of claim 1, wherein when the software testing phase is a unit test, the testing the program to be tested based on the testing strategy matched with the software testing phase to obtain the testing result matched with the software testing phase comprises:

extracting each test unit from the program to be tested;

extracting a first source file in each test unit;

3. The software testing method of claim 2, wherein after said determining whether the first function requires a call to a second function while running, the method further comprises:

if the first function needs to call the second function when running, piling the second function needing to be called to obtain a pile function of the second function needing to be called;

4. The software testing method of claim 1, wherein when the software testing phase is an integration testing, the testing the program to be tested based on the testing strategy matched with the software testing phase to obtain the testing result matched with the software testing phase comprises:

extracting an application layer program from the program to be tested;

extracting a second source file in the application layer program;

and if the integration test of the bottom layer program in the to-be-tested program is not needed, performing the integration test on the second source file based on the header file of the application layer program to obtain a test result of performing the integration test on the to-be-tested program.

5. The software testing method of claim 4, wherein after said extracting a second source file in the application layer program, the method further comprises:

if the integration test needs to be carried out on the bottom program in the programs to be tested, extracting the bottom program in the programs to be tested;

extracting a third source file in the bottom layer program;

6. The software testing method of claim 1, wherein when the software testing phase is a confirmation test, the testing the program to be tested based on the testing strategy matched with the software testing phase to obtain the testing result matched with the software testing phase comprises:

7. The software testing method of claim 6, wherein an equipment simulation model is further provided in the electronic equipment;

and performing a confirmation test on the program to be tested based on the test case and the equipment simulation model which need to perform the in-loop test, so as to obtain a test result for performing a confirmation test on the program to be tested.

8. An electronic device comprising an electronic control unit, the electronic control unit comprising:

the program acquisition module is used for acquiring a program to be tested;

9. An electronic device comprising a memory, an electronic control unit, and a computer program stored in the memory and executable on the electronic control unit, characterized in that the electronic control unit implements the software testing method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out a software testing method according to any one of claims 1 to 7.