CN117453537A

CN117453537A - Automatic testing method and device for embedded operating system, electronic equipment and medium

Info

Publication number: CN117453537A
Application number: CN202311360964.2A
Authority: CN
Inventors: 何阳轩; 彭志航; 曾宏安; 王辰曦; 刘娇健; 刘亮
Original assignee: Beijing Linx Technology Co ltd; State Grid Corp of China SGCC; Beijing Smartchip Microelectronics Technology Co Ltd; Electric Power Research Institute of State Grid Shaanxi Electric Power Co Ltd
Current assignee: Beijing Linx Technology Co ltd; State Grid Corp of China SGCC; Beijing Smartchip Microelectronics Technology Co Ltd; Electric Power Research Institute of State Grid Shaanxi Electric Power Co Ltd
Priority date: 2023-10-19
Filing date: 2023-10-19
Publication date: 2024-01-26

Abstract

The invention discloses an automatic testing method, an automatic testing device, electronic equipment and a medium for an embedded operating system, wherein the method comprises the steps of obtaining source codes of the embedded operating system; generating an embedded system file according to the embedded system source code, and publishing the embedded system file to a server; issuing the embedded system file and the test program thereof to an upper computer; triggering a test, and firstly powering on a target embedded test device; if the target embedded test equipment can be started normally, the upper computer operates the issued test program; if the test result is not the preset value of the test program or the behavior is not in accordance with the expectation, uploading a log and notifying relevant developers; if the test result is passed, returning the test result to the server and uploading the log file; if crashes in the test, the code location causing the crash is automatically located according to the test module information. The method solves the technical problems of low test coverage rate, low efficiency and easiness in being influenced by human factors in the related technology.

Description

Automatic testing method and device for embedded operating system, electronic equipment and medium

Technical Field

The invention relates to the technical field of operating systems, in particular to an automatic testing method, an automatic testing device, electronic equipment and a medium for an embedded operating system.

Background

In the related art, there are some limitations and challenges in automated testing for embedded operating systems. The current manual test method requires writing test cases, performing tests and analyzing results, which is inefficient in the case of large-scale tests and complex functional modules. In addition, manual testing is difficult to achieve comprehensive test coverage and consistent results, and is susceptible to human factors. The testers manually need to have deeper knowledge of the underlying hardware, which is difficult for the practitioners, while the developers are not familiar with the test flow, and the communication between the two parties is inefficient.

Aiming at the technical problems of low test coverage rate, low efficiency and easiness in human factor influence existing in the manual test method of the embedded operating system in the related technology, no effective solution is proposed at present.

Disclosure of Invention

The invention aims to overcome the technical defects and provide an automatic test method, device, electronic equipment and medium for an embedded operating system, so as to solve the technical problems of low test coverage rate, low efficiency and susceptibility to human factors in the related technology.

In order to achieve the technical purpose, the invention adopts the following technical scheme:

according to one aspect of the present invention, there is provided an automated testing method for an embedded operating system, including:

acquiring source codes of an embedded system;

generating an embedded system file according to the embedded system source code, and publishing the embedded system file to a server;

the embedded system file and the test program thereof are issued to an upper computer;

after the embedded system file is burnt and the upper computer acquires the test program, triggering the test, and starting the target embedded test equipment by powering on;

if the target embedded test equipment can be started normally, the upper computer operates the issued test program;

if the test result is not the preset value of the test program or the behavior is not in accordance with the expectation, uploading a log and notifying relevant developers;

if the test result is passed, returning the test result to the server and uploading the log file;

if crashes in the test, the code location causing the crash is automatically located according to the test module information.

Optionally, the test program includes a driver module test program.

Optionally, the automatically locating the code position causing the crash according to the test module information includes:

according to the name of the tested module, the printed register and stack area information and the address range corresponding to the debug file, the code position causing breakdown is automatically positioned.

According to another aspect of the present invention, there is also provided an embedded operating system automation test device, including:

the acquisition unit is used for acquiring the source codes of the embedded system;

the building and publishing unit is used for generating an embedded system file according to the embedded system source code and publishing the embedded system file to a server;

the issuing unit is used for issuing the embedded system file and the test program thereof to the upper computer;

the starting unit is used for triggering the test after the embedded system file is burnt and the upper computer acquires the test program, and starting the target embedded test equipment by powering on;

a test unit for: if the target embedded test equipment can be started normally, the upper computer operates the issued test program;

the test unit is further configured to: if the test result is not the preset value of the test program or the behavior is not in accordance with the expectation, uploading a log and notifying relevant developers;

the test unit is further configured to: if the test result is passed, returning the test result to the server and uploading the log file;

the test unit is further configured to: if crashes in the test, the code location causing the crash is automatically located according to the test module information.

Optionally, the test program includes a driver module test program.

According to another aspect of the present invention, there is also provided an electronic apparatus including: a processor and a memory;

the memory has stored thereon a computer readable program executable by the processor;

the processor, when executing the computer readable program, implements the steps of the method as described above.

According to another aspect of the present invention, there is also provided a computer-readable storage medium storing one or more programs executable by one or more processors to implement the steps in the above-described method.

The automatic test method, the automatic test device, the electronic equipment and the medium for the embedded operating system can be directly tested by a program preset by a developer, collect related information and feed back the related information to the developer, shorten the whole development period, ensure the test coverage rate and solve the technical problems of low test coverage rate, low efficiency and easiness in being influenced by human factors of the manual test method in the related technology.

Drawings

FIG. 1 is a schematic flow chart of an automatic test method for an embedded operating system according to an embodiment of the present invention;

FIG. 2 is a flow chart of an automatic test method for an embedded operating system according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of a hardware architecture for implementing an automatic test method for an embedded operating system according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of an embodiment of an automatic test device for embedded operating system;

fig. 5 is a block diagram of a terminal that may implement an automated test method for embedded operating systems in accordance with an embodiment of the present invention.

Detailed Description

In order to make the present application solution better understood by those skilled in the art, the following description will be made in detail and with reference to the accompanying drawings in the embodiments of the present application, it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, shall fall within the scope of the present application.

Based on the above problems, the present invention provides an automatic testing method for an embedded operating system, so as to solve the technical problems in the related art. The following is a detailed description.

Example 1

According to an embodiment of the present invention, an automatic test method for an embedded operating system is provided, and in combination with fig. 1, the method includes the following steps:

s1, acquiring source codes of an embedded system;

s2, generating an embedded system file according to the embedded system source code, and publishing the embedded system file to a server;

s3, the embedded system file and the test program thereof are issued to an upper computer;

s4, after the upper computer acquires a test program, triggering a test, and starting target embedded test equipment by powering on;

s5, if the target embedded test equipment can be started normally, the upper computer operates the issued test program;

s6, if the test result is not the value preset by the test program or the behavior does not accord with the expectation, uploading a log and notifying relevant developers;

s7, if the test result is passed, returning the test result to the server, and uploading the log file;

s8, if the code is crashed in the test, automatically positioning the code position causing the crash according to the information of the test module.

The embodiment can directly test by a program preset by a developer, collect related information and feed back the related information to the developer, shorten the whole development period, ensure the test coverage rate, and solve the technical problems of low test coverage rate, low efficiency and easiness in being influenced by human factors in the manual test method in the related technology.

In a more specific embodiment, in conjunction with FIG. 2, the embedded operating system automated test method comprises the steps of:

s101, acquiring embedded system source codes by an automatic construction system

After pushing the source code, the developer triggers the automatic construction system so that the automatic construction system can compile according to the automatic construction system configuration file of the corresponding branch.

S102, constructing a system and issuing.

In step S102, as described above, as an example, the automated build system compiles according to the automated build system configuration file of the corresponding branch. And can issue to the server according to the submitting branch and the submitting time of the embedded system. Because the embedded system has a plurality of branches in the development process, and meanwhile, the latest source codes at the upstream of the part may need to be merged, more versions exist on the release server, and management is required according to construction time, branches and the like.

S103, downloading the system and burning.

In step S103, after the system compiling and generating system is automatically built, a job name is defined as test, and the test program and the embedded system file are issued to the host computer.

In order to facilitate management, release, construction and test, an automatic construction system triggers the construction and issues the construction to an upper computer to start the test.

S104, whether the power-on test system can be started normally or not.

After the system is burnt, after the upper computer acquires a test program, the built system triggers the test, and the target embedded test equipment is powered on first.

The target embedded device is directly powered by the upper computer, and whether the target embedded device is started or not is determined through a program.

If the device cannot be started normally, step S105 is performed, an error message is returned, and a log is uploaded, and as an example, the log file may be uploaded to the publishing server.

Because of a plurality of development branches in actual development, uncontrollable problems are possibly introduced in the process of modifying and merging codes, and the system can not be started normally seriously. Therefore, in step S105, it is first detected whether the target embedded device can be started, if not, if it is determined that there is a multi-branch file, an uncontrollable problem is introduced during the process of modifying and merging codes, and the log is timely sent to a tester or a developer for alarming.

If the device can be started normally, step S106, the function test of the driving module is executed.

In step S106, the upper computer will run the test program issued by the build system.

As an example, the test program mainly includes a driver module test and an interface test, where in the driver module test in the conventional manual test, a developer is required to write an explanatory document such as a driver instruction manual and a hardware connection document for a tester to read and build an environment, and meanwhile, the tester is required to know the driving principle of the bottom layer to some extent, which requires a relatively high requirement for most testers, and the building and preparation of the whole test environment takes a relatively long time. Meanwhile, the possibility of system breakdown caused by the test of the driving module is high, and a tester is required to provide a debugging environment of a system breakdown site for a developer to locate problems. The test environment built by the method is directly pre-written by the developer as a test program, the test environment can be reserved, the communication cost of the test personnel and the developer is reduced to the maximum extent, and the problem of repeated time is not required.

And S107, uploading logs when the driving function is not in line with expectations, and notifying a driving developer.

In step S107, if it is detected that the test result of the driver module is not a value preset by the test program or the behavior does not conform to the expectation, a log is uploaded, and a developer of the relevant driver is notified.

This is the case where the drive does not operate as intended, although the modification does not cause the system to fail to start. In the related art, the system is started normally, and a tester is driven to work normally by default. Until the system is found to not realize the expected function in the formal work, the system returns to check the driving fault, thereby influencing the normal operation condition of the system and improving the fault rate. In step S107, first, in the test procedure, the working parameters driven by the root driving module set a threshold for the working parameters, if the threshold is not preset, the driving developer is informed to adjust the driving parameters, so that the troubleshooting operation of the driving faults is pre-arranged in the test stage and is completed in an automatic test mode, and the fault rate of the embedded device in normal operation is reduced.

If the test of each driving module is passed, step S108 is executed, the driving function is normal, the test result is returned, and the log is uploaded, namely, the log is uploaded to the release server.

By checking the test result and the log file, the developer confirms that the current modification does not affect other parts of the system, and meanwhile, the code submitted at this time can complete the expected function.

S109, automatically positioning the relevant code position when the system crashes.

If the system crashes in the test driving module, the test program automatically locates the code position causing the crash according to the name of the tested module, the printed register and stack area information and the address range of the corresponding module of the corresponding debugging file, so that a developer can conveniently and quickly find the code position and correct the code position, the test efficiency is improved, and the test fault is timely detected.

From the description of the above embodiments, it will be clear to a person skilled in the art that the method according to the above embodiments may be implemented by means of software plus the necessary general hardware platform, but of course also by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk), comprising several instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method described in the embodiments of the present application.

Fig. 3 shows a connection manner of the hardware devices corresponding to the implementation of the method. For example, the upper computer may be a desktop plus a serial port debugging device, or may be a single board computer with a serial port debugging function, where the upper computer is connected to an embedded device through a serial port, one path is sending, mainly sending a debugging instruction, the other path is receiving, mainly receiving serial port printing information, and according to a returned test value, the test program automatically performs corresponding processing, if the system cannot be started normally, and cannot print system version information, notifies a corresponding branch maintainer and uploads a log, if the system crashes in a test driving process, the test system automatically locates a code part with a problem according to a tested driving module and a debugging file, and notifies a corresponding driver developer by mail, and the corresponding developer information is in a maintainer file in a document part of the code. After the test is finished, the log file is uploaded to the corresponding version directory of the release server no matter whether the test result is successful or failed. But different operations, such as crash analysis, can be performed according to the return value preset by the test program.

Example two

According to an embodiment of the present invention, there is provided an automatic testing device for an embedded operating system, including, in combination with fig. 4:

an acquiring unit 21, configured to acquire embedded system source codes;

the building and publishing unit 22 is configured to generate an embedded system file according to the embedded system source code, and publish the embedded system file to a server;

a issuing unit 23, configured to issue the embedded system file and the test program thereof to an upper computer;

the starting unit 24 is used for triggering a test after the embedded system file is burned and the upper computer acquires a test program, and starting the target embedded test equipment by powering on;

a test unit 25 for: if the target embedded test equipment can be started normally, the upper computer operates the issued test program;

Optionally, the test program includes a driver module test program.

Alternatively, specific examples in this embodiment may refer to examples described in the foregoing embodiments, and this embodiment is not described herein.

It should be noted that the above modules are the same as examples and application scenarios implemented by the corresponding steps, but are not limited to what is disclosed in the above embodiments. It should be noted that, the above modules may be implemented in a corresponding hardware environment as part of the apparatus, and may be implemented in software, or may be implemented in hardware, where the hardware environment includes a network environment.

Fig. 5 is a block diagram of a terminal according to an embodiment of the present application, and as shown in fig. 5, the terminal may include: one or more (only one is shown) processors 101, memory 103, and transmission means 105, as shown in fig. 5, the terminal may further comprise input output devices 107.

The memory 103 may be used to store software programs and modules, such as program instructions/modules corresponding to the methods and apparatuses in the embodiments of the present application, and the processor 101 executes the software programs and modules stored in the memory 103, thereby performing various functional applications and data processing, that is, implementing the methods described above. Memory 103 may include high-speed random access memory, but may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 103 may further include memory remotely located with respect to processor 101, which may be connected to the terminal via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission device 105 is used for receiving or transmitting data via a network, and can also be used for data transmission between the processor and the memory. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 105 includes a network adapter (Network Interface Controller, NIC) that may be connected to other network devices and routers via a network cable to communicate with the internet or a local area network. In one example, the transmission device 105 is a Radio Frequency (RF) module for communicating with the internet wirelessly.

Wherein in particular the memory 103 is used for storing application programs.

The processor 101 may call an application stored in the memory 103 via the transmission means 105 to perform the following steps: acquiring source codes of an embedded system;

after the upper computer acquires a test program, triggering a test, and starting target embedded test equipment by powering on;

It will be appreciated by those skilled in the art that the above-mentioned structure of the terminal is merely illustrative, and the terminal may be a smart phone (such as an Android mobile phone, an iOS mobile phone, etc.), a tablet computer, a palm computer, a mobile internet device (Mobile Internet Devices, MID), a PAD, etc. Fig. 5 is not limited to the structure of the electronic device. For example, the terminal may also include more or fewer components (e.g., network interfaces, display devices, etc.) than shown in fig. 5, or have a different configuration than shown in fig. 5.

Those of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be implemented by a program for instructing a terminal device to execute in association with hardware, the program may be stored in a computer readable storage medium, and the storage medium may include: flash disk, read-only memory (Read)Only Memory, ROM), random access Memory (Random Access Memory, RAM), magnetic or optical disk, and the like.

Embodiments of the present application also provide a storage medium. Alternatively, in the present embodiment, the above-described storage medium may be used for executing the program code of the above-described method.

Alternatively, in this embodiment, the storage medium may be located on at least one network device of the plurality of network devices in the network shown in the above embodiment.

Alternatively, in the present embodiment, the storage medium is configured to store program code for performing the steps of: acquiring source codes of an embedded system;

if crashes in the test, the code location causing the crash is automatically located according to the test module information. Alternatively, specific examples in this embodiment may refer to examples described in the foregoing embodiments, and this embodiment is not described herein.

Alternatively, in the present embodiment, the storage medium may include, but is not limited to: u disk, read-only memory (ROM, read)An Only Memory), a random access Memory (RAM, random Access Memory), a removable hard disk, a magnetic disk, or an optical disk, or the like.

The foregoing embodiment numbers of the present application are merely for describing, and do not represent advantages or disadvantages of the embodiments.

The integrated units in the above embodiments may be stored in the above-described computer-readable storage medium if implemented in the form of software functional units and sold or used as separate products. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions to cause one or more computer devices (which may be personal computers, servers or network devices, etc.) to perform all or part of the steps of the methods described in the various embodiments of the present application.

In the foregoing embodiments of the present application, the descriptions of the embodiments are emphasized, and for a portion of this disclosure that is not described in detail in this embodiment, reference is made to the related descriptions of other embodiments.

In the several embodiments provided in this application, the described embodiments of the apparatus are merely illustrative, such as the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, such as multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interfaces, units or modules, or may be in electrical or other forms.

The units described as separate units may or may not be physically separate, and units shown 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 may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

The foregoing is merely a preferred embodiment of the present application and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the principles of the present application and are intended to be comprehended within the scope of the present application.

Claims

1. The automatic testing method of the embedded operating system is characterized by comprising the following steps of:

acquiring source codes of an embedded system;

2. The automated test method of embedded operating systems of claim 1, wherein the test program comprises a driver module test program.

3. The automated testing method of an embedded operating system of claim 2, wherein automatically locating code locations that cause crashes based on test module information comprises:

4. The method for automated testing of an embedded operating system of claim 1, wherein publishing the embedded system file to the server comprises:

and publishing the embedded system file to a server according to the submitting branch and the submitting time.

5. The automatic testing device of the embedded operating system is characterized by comprising:

the starting unit is used for triggering the test after the upper computer acquires the test program, and starting the target embedded test equipment by powering on;

6. The automated test equipment of claim 5, wherein the test program comprises a driver module test program.

7. The automated testing apparatus of claim 5, wherein automatically locating code locations that cause crashes based on test module information comprises:

8. The automated testing device of claim 5, wherein publishing the embedded system file to the server comprises:

9. An electronic device, comprising: a processor and a memory;

the processor, when executing the computer readable program, implements the steps of the method according to any of claims 1-4.

10. A computer readable storage medium storing one or more programs executable by one or more processors to implement the steps of the method of any of claims 1-4.