A testing method and a testing system

Abstract

The present application provides a testing method and a testing system, which can perform a power-on test on a newly submitted first code through a first electronic device before merging the code into a main branch of the code after continuous integration verification in a typical software development process, or perform a power-on test on a newly submitted first code through a first electronic device during continuous integration verification in a typical software development process, or perform a power-on test on a newly submitted first code through a first electronic device before continuous integration verification in a typical software development process. The typical software development process includes continuous integration verification, merging the code into a main branch of the code, etc. Since the present application performs a power-on test on the code before merging the code into the main branch, the efficiency of locating "problem code" can be improved, so that the "problem code" can be located in a shorter time, thereby improving the overall R&D efficiency.

Description

Technical Field

[0001] The present application relates to the field of testing, and in particular to a testing method and a testing system. Background Art

[0002] The usual software development process is: submit code, CI access control verification, merge code into the main code branch, build software version and obtain the built software version, etc.

[0003] In the relevant scheme, after merging the code into the main branch of the code as mentioned above, the software version built based on the main branch is usually tested on the boot loader.

[0004] This power-on test method, when it is detected that the test machine cannot be powered on normally, is inefficient in locating the "problem code" that causes the failure to power on because it is based on the software version built on the main code branch after multiple codes are merged into the main code branch. Therefore, it takes a long time to locate the "problem code", affecting the overall R&D efficiency. Summary of the Invention

[0005] This application provides a testing method and a testing system that can improve the efficiency of locating "problem codes", so that "problem codes" can be located in a shorter time, thereby improving overall R&D efficiency.

[0006] In a first aspect, a testing method is provided, which is applied to a first electronic device in a testing system, wherein the first electronic device is used to perform continuous integration verification on first code submitted to a software development process, wherein the software development process includes continuous integration verification and merging the first code into a main code branch; and the method includes:

[0007] After performing continuous integration verification on the first code, before merging the first code into the main code branch, or before performing continuous integration verification on the first code, or during the process of performing continuous integration verification on the first code, the first electronic device performs a power-on test on the first code; if the result of the power-on test is a verification failure, continuous integration verification of the first code is prohibited, or merging the first code into the main code branch is prohibited.

[0008] In an embodiment of the present application, after the continuous integration verification in the usual software development process, before the code is merged into the main branch of the code, the newly submitted first code can be powered on and tested by the first electronic device. Or, during the continuous integration verification in the usual software development process, the newly submitted first code can be powered on and tested by the first electronic device. Or, before the continuous integration verification in the usual software development process, the newly submitted first code can be powered on and tested by the first electronic device. In this way, since the code is powered on and tested before being merged into the main branch, the efficiency of locating the "problem code" can be improved, so that the "problem code" can be located in a shorter time, thereby improving the overall R&D efficiency.

[0009] Furthermore, in an embodiment of the present application, when the result of the power-on test is verification failure, the continuous integration verification of the first code can be prohibited (prohibiting the continuous integration verification of the first code also prohibits the first code from being merged into the main code branch), or the merging of the first code into the main code branch can be prohibited, thereby intercepting the "problem code" (first code) from being merged into the main code branch, thereby ensuring the reliability of the main code branch.

[0010] In conjunction with the first aspect, in a possible implementation of the first aspect, the test system further includes a test device and a second electronic device, the first electronic device is electrically connected to the test device, the first electronic device is electrically connected to the second electronic device, and the second electronic device is electrically connected to the test device; and performing a power-on test on the first code includes:

[0011] The first electronic device generates a first executable file corresponding to the first code based on the first code; constructs an archive package of the first executable file through the second electronic device, and the archive package is a data package used to deploy the code on the test device; deploys the archive package to the test device; and performs a power-on test through the test device.

[0012] In an embodiment of the present application, the first electronic device can generate a first executable file based on the first code; construct an archive package of the first executable file through the second electronic device, and deploy the archive package to the test device, so that the first electronic device can be powered on and tested through the test device.

[0013] In conjunction with the first aspect, in a possible implementation of the first aspect, generating a first executable file corresponding to the first code based on the first code includes:

[0014] The first electronic device creates a first container; generates a first executable file corresponding to the first code in the first container based on the first code; and, after generating the first executable file corresponding to the first code based on the first code, before constructing an archive package of the first executable file through the second electronic device, the method also includes: transferring the first container to the second electronic device, the first container including the first executable file; and constructing the archive package of the first executable file through the second electronic device, including: constructing the archive package of the first executable file in the first container through the second electronic device.

[0015] In an embodiment of the present application, the first electronic device can generate a first executable file corresponding to the first code based on the first code in the first container (the first executable file can be considered as a compilation product generated based on the first code in the first container), the first electronic device transfers the first container to the second electronic device, and the second electronic device constructs an archive package of the first executable file in the first container. That is, after the first electronic device transfers the first container to the second electronic device, the second electronic device can reuse the compilation product generated based on the first code (i.e., the first executable file) to generate an archive package, without having to compile the first code again, thereby reducing the time and resources required for compilation, thereby indirectly shortening the duration of the power-on test and improving the efficiency of the power-on test.

[0016] Furthermore, since the second electronic device reuses the compiled product, and both the first electronic device and the second electronic device process the code in the first container, the consistency of the compiled product in the software environment of the first electronic device and the second electronic device can be ensured, thereby reducing problems caused by environmental differences.

[0017] In conjunction with the first aspect, in a possible implementation of the first aspect, performing a power-on test using a test device includes:

[0018] The first electronic device detects whether the operating system of the test device has completed startup; if it is detected that the operating system of the test device has not completed startup, it determines that the result of the power-on test is a verification failure; if it is detected that the operating system of the test device has completed startup, it detects whether the test device is in a black screen state; if it is detected that the test device is in a black screen state, it determines that the result of the power-on test is a verification failure; if it is detected that the test device is not in a black screen state, it determines that the result of the power-on test is a verification success.

[0019] In the embodiment of the present application, the first electronic device can combine the two aspects of detecting whether the operating system of the test device has completed startup and detecting whether the test device is in a black screen state to perform a power-on test. It can double-verify whether the test device has been powered on from the operating system level and the visual level, thereby improving the accuracy of the power-on test. It avoids the situation where the power-on test is performed by detecting whether the operating system has completed startup alone, which may lead to misjudgment of the test device due to delayed updates or abnormalities of the operating system, and avoids the situation where the power-on test is performed by detecting whether the test device is in a black screen state alone, which may lead to misjudgment that the test device is not powered on due to the long-term stay of the screen protector, lock screen interface or boot animation of the test device. In other words, the combination of the above two aspects can improve the accuracy and reliability of the power-on test, and avoids the misjudgment and limitations that may be caused by a single method.

[0020] Among them, detecting whether the test device is in a black screen state includes: the first electronic device takes a screenshot of the test device to obtain a screenshot image; and detecting whether the test device is in a black screen state based on multiple pixel values ​​included in the screenshot image.

[0021] Among them, detecting whether the test device is in a black screen state includes: a first electronic device takes a screenshot of the test device to obtain a screenshot image; based on the screenshot image and the first image, detecting whether the test device is in a black screen state, the first image is a preset stored image of the test device in a black screen state.

[0022] In conjunction with the first aspect, in a possible implementation of the first aspect, if the result of the power-on test is a verification failure, the state of the test device is set to an offline state; and if it is detected that the operating system of the test device has not completed startup, after determining that the result of the power-on test is a verification failure, and if it is detected that the test device is in a black screen state, after determining that the result of the power-on test is a verification failure, the method further includes:

[0023] The first electronic device performs a flashing process on the test device in an offline state; and changes the state of the test device from an offline state to an idle state.

[0024] In an embodiment of the present application, when the result of the power-on test is verification failure, the test device can be flashed to restore the test device in an abnormal state (for example, the abnormal state is the offline state) to a normal state (for example, the normal state is the idle state), thereby avoiding the situation where no test device is available due to all test devices being in an abnormal state during the power-on test.

[0025] In conjunction with the first aspect, in a possible implementation of the first aspect, deploying the archive package to the test device includes:

[0026] Perform incremental flashing on the test device based on the archive package.

[0027] In the embodiment of the present application, since the first electronic device deploys the archive package to the test device through incremental flashing, this incremental flashing method can reduce the amount of data transmission required when deploying the archive package, improve the deployment efficiency, and thus indirectly improve the test efficiency of the entire power-on test.

[0028] In conjunction with the first aspect, in a possible implementation of the first aspect, generating a first executable file corresponding to the first code based on the first code includes:

[0029] The first electronic device compiles the first code, and during the compilation process of the first code, or after the compilation process of the first code, compiles and verifies the first code; if the result of the compilation and verification is that the verification is successful, a first executable file corresponding to the first code is generated.

[0030] In the embodiment of the present application, the first electronic device can perform compilation verification on the first code during the process of compiling the first code or after compiling the first code, thereby improving the flexibility of the first electronic device in performing compilation verification.

[0031] Moreover, when the result of the compilation verification is successful, the first electronic device generates a first executable file corresponding to the first code. After that, the first electronic device can continue to execute the subsequent steps after generating the first executable file in the test method provided in the embodiment of the present application. That is to say, the compilation verification can serve as the "first checkpoint" of the test method of the embodiment of the present application, which improves the reliability of the first electronic device in performing power-on testing through the test equipment.

[0032] In conjunction with the first aspect, in a possible implementation of the first aspect, constructing an archive package of the first executable file by the second electronic device includes:

[0033] The first electronic device generates an application package based on the first executable file through the second electronic device, and the application package includes the first executable file; creates a first image file based on the application package through the second electronic device, and the first image file includes a system image file or a dynamic partition image file, and the first image file includes the application package; and constructs an archive package corresponding to the first code based on the first image file through the second electronic device.

[0034] In an embodiment of the present application, a first electronic device can generate an application package based on a first executable file through a second electronic device, where the application package includes a first executable file (the application package can be considered as a carrier for changing the code at the application level); a first image file can be created based on the application package through the second electronic device (the first image file can be considered as a carrier for changing the code at the operating system level); an archive package corresponding to the first code can be constructed based on the first image file through the second electronic device, and then the archive package can be deployed to a test machine for a power-on test. In this way, it is possible to test whether the first code has a power-on problem not only from the application level but also from the operating system level, so as to ensure that the first code will not introduce a power-on problem at either the application level or the operating system level, thereby ensuring the reliability of the power-on test.

[0035] In conjunction with the first aspect, in a possible implementation of the first aspect, during the continuous integration verification of the first code, performing a startup test on the first code includes:

[0036] The first electronic device performs code quality verification on the first code, and performs a power-on test on the first code, where the continuous integration verification includes code quality verification, and the code quality verification includes at least code style verification, code unit test, and code integration test; when the result of the code quality verification is a successful verification, if the result of the power-on test is a successful verification, then the result of the continuous integration verification is determined to be a successful verification; when the result of the code quality verification is a successful verification, or when the result of the code quality verification is a failed verification, if the result of the power-on test is a failed verification, then the result of the continuous integration verification is determined to be a failed verification.

[0037] In an embodiment of the present application, during the process of continuous integration verification performed by the first electronic device, the first electronic device may perform code quality verification on the first code, and perform a power-on test on the first code; when the result of the code quality verification is a successful verification, if the result of the power-on test is a successful verification, then the result of the continuous integration verification is determined to be a successful verification; when the result of the code quality verification is a successful verification, or when the result of the code quality verification is a failed verification, if the result of the power-on test is a failed verification, then the result of the continuous integration verification is determined to be a failed verification, so that the reliability of the continuous integration verification can be guaranteed.

[0038] In a second aspect, a test system is provided, including a first electronic device, a second electronic device, and a test device, wherein the first electronic device is electrically connected to the test device, the first electronic device is electrically connected to the second electronic device, and the second electronic device is electrically connected to the test device; wherein,

[0039] The first electronic device is used to execute any method as in the first aspect; the second electronic device is used to build an archive package based on the first executable file generated by the first code, and the archive package is a data package used to deploy the code on the test device; the test device is used to perform a power-on test.

[0040] The embodiment of the present application can perform a power-on test on the newly submitted first code through the test system after the continuous integration verification in the usual software development process and before the code is merged into the main branch of the code. Or, during the continuous integration verification in the usual software development process, the newly submitted first code can be powered on and tested by the test system. Or, before the continuous integration verification in the usual software development process, the newly submitted first code can be powered on and tested by the test system. In this way, since the code is powered on and tested before being merged into the main branch, the efficiency of locating the "problem code" can be improved, so that the "problem code" can be located in a shorter time, thereby improving the overall R&D efficiency.

[0041] Furthermore, in an embodiment of the present application, when the result of the power-on test is verification failure, the continuous integration verification of the first code can be prohibited (prohibiting the continuous integration verification of the first code also prohibits the first code from being merged into the main code branch), or the merging of the first code into the main code branch can be prohibited, thereby intercepting the "problem code" (first code) from being merged into the main code branch, thereby ensuring the reliability of the main code branch.

[0042] In a third aspect, an electronic device is provided, wherein the electronic device is configured to execute the method provided in the first aspect. Specifically, the electronic device may include a processing unit configured to execute any possible implementation of the first aspect.

[0043] In a fourth aspect, an electronic device is provided, comprising: one or more processors; one or more memories; the one or more memories storing one or more computer programs, the one or more computer programs comprising instructions, which, when executed by the one or more processors, enable the electronic device to execute a method in any possible implementation of the above-mentioned first aspect.

[0044] In a fifth aspect, a computer-readable storage medium is provided, comprising computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes any one of the methods described in the first aspect.

[0045] In a sixth aspect, a chip is provided, comprising a memory for storing instructions; and a processor for calling and executing instructions from the memory, so that an electronic device equipped with the chip executes any one of the methods described in the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 It is a schematic diagram of a software development process.

[0047] Figure 2 Schematic diagram of a test system provided in an embodiment of the present application.

[0048] Figure 3 This is a structural diagram of a first electronic device provided in an embodiment of the present application.

[0049] Figure 4 This is a schematic diagram of a power-on test process provided in an embodiment of the present application.

[0050] Figure 5 It is a schematic diagram of the software architecture of a test system provided in an embodiment of the present application.

[0051] Figure 6 This is a schematic diagram of another power-on test process provided in an embodiment of the present application.

[0052] Figure 7 This is a schematic diagram of a test machine that recovers from an abnormal state, provided in an embodiment of the present application.

[0053] Figure 8 This is a schematic flow chart of a testing method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0054] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0055] Typically, the software development process includes the following steps: For example, please refer to Figure 1 , Figure 1 It is a schematic diagram of a software development process. Figure 1 The circles and numbers shown in represent steps.

[0056] Step 1: After writing code on a computer, developers submit the code to a version control server. The version control server includes a code repository that stores code and version information, as well as tools for managing and operating the code repository.

[0057] Step 2: After the developer submits code on their computer, they trigger the continuous integration (CI) verification process, also known as CI access control verification. Specifically, CI access control verification can be performed by the CI server. CI access control verification includes various verifications of the newly submitted code, such as code style verification, compilation verification, unit testing, and integration testing. In implementation, for example, after the version control server receives the submitted code, the computer can send a request to the CI server to initiate CI access control verification. Upon receiving this request, the CI server can perform CI access control verification on the code.

[0058] Step 3: After the CI access control verification is successful, the CI server can notify the version control server of the verification success message, and the version control server can merge the code into the main code branch (for example, master or main).

[0059] The main code branch is the most core branch in a project and typically represents the stable version of the project. In many projects, the main branch is also called master or main. The main branch typically contains code that has been thoroughly tested and reviewed and is considered ready for deployment to a production environment. In the early stages of software development, all development work may occur on the main branch. However, as the project matures and the team expands, additional branches are often introduced to manage different development processes.

[0060] A branch is an independent code line created from the main branch to isolate specific feature development, bug fixes, or experimental development without affecting the stability of the main branch. Developers can freely commit and merge code on the branch without worrying about affecting the main branch. The main purpose of branches is parallel development and risk isolation. They allow multiple developers or teams to work on different features or fixes at the same time without interfering with each other. Common branch types include: Feature Branch, a branch used to develop new features. Fix Branch, a branch used to fix specific bugs. Release Branch, used to prepare for the release of a new version, including final testing and documentation updates. Hotfix Branch, used to urgently fix problems in the production environment, is usually created directly from the main branch and eventually merged back to the main branch.

[0061] Step 4: After the version control server merges the code into the main code branch, it can trigger the software build process. Specifically, the build process is executed by the build server. In implementation, after the version control server merges the code into the main code branch, it can send a build request to the build server. Upon receiving the request, the build server executes the build process. For example, the build server can use a build tool to build the software version.

[0062] Step 5: Developers can access the built software version from the build server. For example, developers can download the built software version from the build server. Alternatively, the build server can deploy the built software version to the production environment. Alternatively, the build server can notify the user's electronic device of the new version release and provide a download link or update mechanism.

[0063] The software development process in the relevant solution typically involves, after step 4 above, performing a startup test on the software version built based on the main branch. For example, the installation package corresponding to the software version built based on the main branch is downloaded to a test machine, and then the test machine is tested to see if it can boot normally. This startup test method, if the test machine is found to be unable to boot normally, is inefficient in locating the code causing the boot failure (hereinafter referred to as "problem code") because it is based on the software version built on the main branch after multiple code lines have been merged into the main branch. This requires a long time to locate the problem code, impacting overall development efficiency. For example, if multiple developers submit multiple code lines through step 1 above, and after merging these multiple code lines into the main branch through step 4, a software version is built based on the main branch. A startup test is then performed. If the test machine is found to be unable to boot normally, multiple code lines need to be individually tested to see if there are any problems with the boot failure, resulting in low efficiency in locating the problem code.

[0064] In order to solve the above problems, an embodiment of the present application provides a testing method, which can perform a power-on test on each code before merging the code into the main branch of the code in the above step 3. For example, the power-on test is performed during the CI access control verification in the above step 2. For another example, the power-on test is performed before the CI access control verification in the above step 2. For another example, after the CI access control in the above step 2, the power-on test is performed before merging the code into the main branch of the code in step 3. After the power-on test verification is successful, subsequent steps such as merging the code into the main branch can be executed. After the power-on test verification fails, it is prohibited to merge the code that failed the verification into the main branch of the code. In this way, compared with the relevant scheme, since the power-on test is performed on each code before merging the code into the main branch, the efficiency of locating the problem code can be improved, so that the problem code can be located in a shorter time, thereby improving the overall R&D efficiency.

[0065] The test method provided in the embodiment of the present application is applied to a test system, wherein the test system includes a first electronic device, a second electronic device, and a test device. The devices in the test system are connected to each other via a wired or wireless connection, which is not limited in the embodiment of the present application.

[0066] The first electronic device may refer to a server, a server cluster, a cloud server, a laptop computer, a desktop computer, a tablet computer (Pad), a computer with wireless transceiver function, etc. For example, the first electronic device may refer to Figure 1 The embodiment of the present application does not limit the specific technology and specific device form adopted by the first electronic device. The first electronic device is used to call the test device to perform a startup test on the code newly submitted by the R&D personnel.

[0067] The second electronic device may refer to a server, a server cluster, a cloud server, a laptop, a desktop computer, a tablet computer (Pad), a computer with wireless transceiver function, etc. For example, the first electronic device may refer to Figure 1 The embodiment of the present application does not limit the specific technology and specific device form adopted by the second electronic device. The second electronic device is used to build the software version of the code newly submitted by the R&D personnel.

[0068] The test device can be a mobile phone, smart TV, wearable device, tablet computer, computer with wireless transceiver function, virtual reality (VR) electronic device, augmented reality (AR) electronic device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc. The embodiments of this application do not limit the specific technology and specific device form used by the test device. The test device is used to perform power-on test.

[0069] It is understood that the test system illustrated in the embodiments of the present application does not constitute a specific limitation on the test system. In other embodiments of the present application, the test system may include more or fewer devices than shown. For example, the test system may also include a deployment server that downloads the software version of the newly submitted code from the build server and deploys the software version to the test device.

[0070] For example, please refer to Figure 2 , Figure 2 Schematic diagram of a test system provided in an embodiment of the present application. Figure 2 The test system shown includes a CI server, a build server, a deployment server, and a test mobile phone. Figure 2 The first electronic device is illustrated as a CI server, the second electronic device is illustrated as a build server, and the test device is illustrated as a test mobile phone. Figure 2 The CI server shown in FIG is connected to the build server via a wired or wireless connection. The build server is connected to the deployment server via a wired or wireless connection. The deployment server is connected to test phone 1, test phone 2, and test phone 3, respectively, via a wired or wireless connection.

[0071] In order to better understand the embodiments of the present application, the structure of each device in the test system of the embodiments of the present application is introduced below.

[0072] Figure 31 is a schematic diagram of the structure of a first electronic device provided in an embodiment of the present application. The first electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, an antenna 1, an antenna 2, a mobile communication module 140, a wireless communication module 150, a sensor module 160, and the like.

[0073] It should be understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the first electronic device. In other embodiments of this application, the first electronic device may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0074] It can also be understood that the structures of the second electronic device and the testing device can refer to the structure of the first electronic device described above, and will not be described in detail here.

[0075] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (App), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0076] In the embodiment of the present application, the processor of the first electronic device can perform a power-on test on the code that has not yet been merged into the main branch.

[0077] The processor 110 may also include a memory for storing instructions and data.

[0078] The wireless communication module 150 can provide wireless communication solutions applied to the first electronic device, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc. The wireless communication function of the first electronic device can be implemented through antenna 1, antenna 2, mobile communication module 140, wireless communication module 150, modem processor and baseband processor. Specifically in the embodiment of the present application, the first electronic device can be connected to the second electronic device or test equipment through antenna 1, antenna 2, mobile communication module 140, wireless communication module 150, etc.

[0079] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the first electronic device.

[0080] The internal memory 121 may be used to store computer executable program codes, where the executable program codes include instructions.

[0081] The sensor module 160 may include various types of sensors, such as a temperature sensor, a voltage sensor, a power sensor, a touch sensor, and the like.

[0082] This concludes the introduction to the hardware structure of the first electronic device. It is understood that Figure 3 The components included in the illustrated hardware structure do not constitute a specific limitation on the first electronic device. The first electronic device may have more or fewer components than shown in the figure, may combine two or more components, or may have a different component configuration. The various components shown in the figure may be implemented in hardware, including one or more signal processing and / or application-specific integrated circuits, software, or a combination of hardware and software.

[0083] The above embodiments introduce the hardware structure of each device in the test system. The following embodiments introduce the implementation of the power-on test in the test system.

[0084] For example, please refer to Figure 4 , Figure 4 This is a schematic diagram of a power-on test process provided by an embodiment of the present application. This process can be applied to Figure 2In the test system shown, the process includes steps S41 to S418.

[0085] S41: In response to a trigger event, the CI server creates a container 1. The trigger event is an event triggered based on code 1 for performing a startup test.

[0086] It should be understood that the triggering event may refer to: for example, please refer to Figure 1 , the R&D personnel submits the code to the computer, which can automatically trigger the CI access control verification. The embodiment of the present application can perform a power-on test during the CI access control verification process, so this operation can be considered a triggering event. For ease of description, the embodiment of the present application refers to the code submitted by the R&D personnel as code 1. Code 1 refers to the uncompiled code, which is the original text written by the R&D personnel in a programming language. For example, code 1 is submitted to Figure 1 After the version control server is connected, the developer can actively perform an operation on the computer to trigger the power-on test, so this operation can also be considered a trigger event. For example, after the CI access control verification is completed, the CI server can automatically trigger the power-on test operation, so this operation can also be considered a trigger event.

[0087] It's also important to understand that Docker is a containerization technology that allows developers to package applications and their dependencies into a lightweight, portable container that can run on any Docker-enabled system. Docker containers include application code, a runtime environment, system tools, and system libraries.

[0088] The CI server creates a Docker container, which can also be understood as the CI server applying to compile the Docker container. This Docker container contains all the environments and dependencies required to run the newly submitted code by the developer. For ease of description, this embodiment of the application refers to the container containing all the environments and dependencies required to run code 1 as container 1.

[0089] The advantages of creating Docker include: ensuring consistent code behavior across different environments (development, testing, and production). Containers can be quickly started and stopped, making deployment and scaling easier. Each container runs in an isolated environment without affecting others. Containers can be easily moved between different devices.

[0090] In implementation, the CI server can create container 1 through a tool specifically used to create Docker. The embodiment of the present application does not limit the method of creating container 1.

[0091] S42 , the CI server updates code 1 to container 1 .

[0092] In implementation, for example, the CI server may update code 1 to container 1 through a cherry-pick command, which is not limited in this embodiment of the present application.

[0093] It should be understood that the CI server updates Code 1 to Container 1 to ensure that the new code (Code 1) can be correctly loaded and recognized in the isolated environment.

[0094] S43, the CI server compiles code 1 in container 1.

[0095] It should be understood that compilation is the process of converting code 1 from source code into machine executable code. In implementation, for example, the CI server can compile code 1 through a compiler, translator, etc., which is not limited in this embodiment of the present application.

[0096] It should also be understood that the compilation process generally consists of the following stages:

[0097] The first stage: preprocessing, processing preprocessing instructions in the source code, such as the expansion of macro definitions, conditional compilation instructions, etc.

[0098] The second stage: compilation, which converts the preprocessed source code into an intermediate representation and then into target code (machine code or assembly language).

[0099] The third stage: assembly, converting assembly language code into machine code.

[0100] The fourth stage: linking, linking multiple target files or library files together to generate an executable file.

[0101] From the above, we can see that the result of compilation is to generate an executable file, which contains machine code that can be directly executed by the operating system.

[0102] S44 , the CI server performs compilation verification on the code 1 during the compilation process of the code 1 in the container 1 or after the compilation is completed.

[0103] During implementation, for example, the CI server can use tools such as a compiler to verify the compilation of code 1 during or after the compilation process. For example, the compiler can check whether the source code complies with the grammatical rules of the language, whether the types of variables and expressions are correct, whether correct type conversions are performed, and whether the logic of the source code complies with the semantic rules of the programming language.

[0104] S45: If the result of the compilation verification is verification failure, the CI server releases the resources occupied by container 1 and notifies the verification failure message to Figure 1The version control server shown prohibits code 1 from being merged into the main branch of the code.

[0105] It should be understood that if the result of the compilation verification is verification failure, it proves that Code 1 has syntax errors, type errors, semantic errors and other problems. Then Code 1 can be considered as the "problem code" mentioned above that causes the computer to not start. Therefore, the compilation verification can be considered the "first checkpoint" of the startup test. If the result of the compilation verification is verification failure, the CI server will notify the startup test failure message to Figure 1 The version control server shown in FIG. 1 prohibits merging code 1 into the main code branch after receiving the message.

[0106] It should also be understood that the CI server releasing the resources occupied by container 1 refers to releasing the CI server resources occupied by container 1. The purpose of this is to reduce the system resource usage of the CI server, improve the overall performance of the CI server, and reduce potential security risks. In implementation, the CI server can delete container 1 by using commands to stop and delete container 1 to release the resources occupied by container 1. This is not limited to this embodiment of the present application.

[0107] S46: If the result of the compilation verification is that the verification is successful, generate an executable file 1.

[0108] It should be understood that the executable file 1 is a compilation product generated by compiling the code 1. The executable file may also be called an execution file, a binary file, a program file, etc.

[0109] S47 , the CI server transfers container 1 to the build server, where container 1 includes executable file 1 .

[0110] In implementation, the CI server may transfer the container 1 to the build server through a file transfer tool, etc., which is not limited in this embodiment of the present application.

[0111] The CI server transfers container 1 to the build server so that the build server can reuse the compiled product in container 1, namely executable file 1. This eliminates the need for the build server to recompile code 1, reducing the time and resources required for compilation, shortening the startup test duration, and improving startup test efficiency. Furthermore, the build server's reuse of the compiled product in container 1 ensures environmental consistency between the build and CI servers, reducing issues caused by environmental differences.

[0112] S48 , the build server generates an application package 1 (Android Application Package, APK) in the container 1 based on the executable file 1 , where the application package 1 includes the executable file 1 .

[0113] Step S48 can also be understood as: the build server customizes the APK and other resources based on executable file 1 in container 1 to generate application package 1 (application package 1 may be referred to as APK1). For example, customizing the APK and other resources may include modifying the APK configuration based on executable file 1, adding or deleting functions represented by executable file 1, etc.

[0114] The purpose of step S48 is to integrate the executable file 1 into the application program so as to run it on the test device.

[0115] The embodiment of the present application does not limit the implementation method of customizing resources such as APK based on the executable file 1 in the container 1.

[0116] S49: The build server creates a system image file (system.img) or a dynamic partition image file (super.img) in container 1.

[0117] It should be understood that a customized APK1 typically represents code changes at the application level, and these changes need to be integrated into the operating system's system partition. system.img is an image file that contains the operating system framework, libraries, and pre-installed applications (including the customized APK1). Therefore, the customized APK1 needs to be included in system.img so that these applications can be loaded and used as part of the system when the device boots.

[0118] super.img is an image file that contains multiple system partitions, which may include system.img, vendor.img, etc. Although customized APK1 is integrated into system.img, they also indirectly become part of super.img.

[0119] It should also be understood that after the customized APK1 is integrated into system.img, these changes become part of the operating system. That is to say, after the test machine is flashed based on system.img or super.img, the boot test is performed on the test machine. It is possible to test not only whether Code 1 has the problem of not booting up at the application level, but also whether Code 1 has the problem of not booting up at the operating system level, to ensure that Code 1 will not introduce the problem of not booting up at either the application level or the operating system level.

[0120] In implementation, the build server may create super.img or system.img using a tool for creating an image file, which is not limited in this embodiment of the present application.

[0121] S410: The build server packages system.img or super.img in container 1 to generate an archive package, which includes the version number of the software version.

[0122] It should be understood that a bundled package refers to a compressed package that combines multiple files or directories into a single file. In the embodiments of the present application, the bundling process refers to packaging all dependencies, configuration files, documents, etc. in system.img or super.img into a single archive package. The purpose of bundling into an archive package is to facilitate distribution and deployment, so that the test machine can easily update the operating system based on the archive package. The embodiments of the present application do not limit the implementation method of the bundling process.

[0123] It should also be understood that during the packaging process, a version number of the software version can also be generated. The version number is usually composed of numbers and possible letter prefixes. The embodiment of the present application does not limit the implementation method of generating the version number.

[0124] S411: The CI server performs a power-on test by calling a test mobile phone in an idle state.

[0125] It should be understood that the test phone status includes idle, busy, offline, and maintaining. If the test phone status is idle, it means that the test phone can be used for power-on testing. If the test phone status is busy, it means that the test phone is currently being used for power-on testing. If the test phone status is offline or maintaining, it means that the test phone cannot be used for power-on testing.

[0126] In implementation, for example, Figure 2 Among the three test phones shown, test phone 1 is in a busy state, test phone 2 is in a maintaining state, and test phone 3 is in an idle state. Then the CI server calls test phone 3 to perform a power-on test.

[0127] The process of performing a power-on test on the test mobile phone can refer to the following steps S412 to S418.

[0128] S412: The CI server calls the test phone in idle state and changes the state of the test phone from idle to busy.

[0129] S413, the test phone downloads the archive package from the build server.

[0130] In implementation, for example, the test mobile phone may send a request to the build server to download the archive package, so as to request downloading the archive package. This embodiment of the present application does not limit this.

[0131] In some embodiments, after generating the archive package in step S410, the build server may also send the archive package to Figure 2 The deployment server is shown. At this time, the mobile phone can send a request for downloading the archive package to the deployment server to request downloading the archive package.

[0132] S414: The CI server performs incremental flashing on the test mobile phone based on the archive package.

[0133] It should be understood that incremental flashing is a system upgrade method that only updates the changed parts of the existing system, rather than replacing the entire system image. This method reduces the amount of data required for the upgrade, improves upgrade efficiency, and reduces the risk of upgrade failure.

[0134] In implementation, for example, when the archive package is obtained based on the packaging of system.img, the new system.img (the system.img in the archive package downloaded from the build server) and the old system.img (the system.img in the original operating system of the test machine) can be compared to generate an update package containing only the difference parts, the update package includes the executable file 1, and the operating system of the test phone is updated through the update package. For another example, when the archive package is obtained based on the packaging of super.img, the new super.img (the super.img in the archive package downloaded from the build server) and the old super.img (the super.img in the original operating system of the test machine) can be compared to generate an update package containing only the difference parts, the update package includes the executable file 1, and the operating system of the test phone is updated through the update package. The embodiment of the present application does not limit the method of incremental flashing processing.

[0135] It should also be understood that since super.img is an image file that contains multiple system partitions, which may include system.img, the processing efficiency of incremental flashing of the test mobile phone when the archive package is obtained based on the packaging of system.img is higher than the processing efficiency of incremental flashing of the test mobile phone when the archive package is obtained based on the packaging of super.img.

[0136] In the embodiment of the present application, the incremental flashing method can reduce the amount of data transmission required for upgrading the system, thereby improving the upgrade efficiency, thereby improving the test efficiency of the entire power-on test.

[0137] S415: After the incremental flashing process is completed, the CI server detects whether the system of the test mobile phone has completed startup.

[0138] In implementation, for example, the CI server can send the getprop sys.boot_completed command to the test phone to detect whether the test phone's system has completed booting. After the test phone receives this command, if the test phone returns a value of "1" to the CI server, the CI server determines that the test phone's system has completed booting. If the test phone returns a value of "0" to the CI server, the CI server determines that the test phone's system has not completed booting.

[0139] It should be understood that detecting whether the system of the test mobile phone has completed startup can be considered the "second checkpoint" of the power-on test.

[0140] S416, when detecting that the system of the test phone has not completed startup, the CI server determines that the result of the power-on test is verification failure, the CI server changes the status of the test phone from busy to offline, ends the power-on test process, and prohibits merging code 1 into the code main branch.

[0141] In the implementation, for example, when the test phone returns the value "0" to the CI server, the CI server determines that the result of the power-on test is a verification failure. At this time, it is proved that code 1 is the "problem code" that causes the phone to not start up, so the "problem code" can be located. After that, the CI server can change the status of the test phone from busy to offline, and the CI server ends the power-on test process when it receives the value "0" returned by the test phone.

[0142] In some embodiments, since the startup test is executed on the CI server Figure 1 The power-on test is performed during the process of step 2 (CI access control verification) shown in the figure. Therefore, if the result of the power-on test is verification failure, the result of the CI access control verification is also verification failure. If the result of the CI access control verification is verification failure, execution is prohibited. Figure 1 The steps for merging code 1 into the main branch of code and subsequent steps are shown.

[0143] In some embodiments, since the boot test is executed on the CI server Figure 1 The power-on test is performed before step 2 shown in the figure. Therefore, if the result of the power-on test is verification failure, execution is prohibited. Figure 1 Step 2 and subsequent steps shown, for example, prohibit the execution of Figure 1 The steps for merging code 1 into the main branch of code and subsequent steps are shown.

[0144] In some embodiments, since the boot test is executed on the CI server Figure 1 After step 2 and before step 3, the power-on test is performed. Therefore, if the result of the power-on test is verification failure, execution is prohibited. Figure 1 Step 3 shown is the step of merging code 1 into the main branch of the code and subsequent steps.

[0145] S417 , when it is detected that the system of the test mobile phone has not been completely started, the CI server detects whether the screen of the test mobile phone is in a black screen state.

[0146] It should be understood that the black screen state of the test mobile phone screen generally refers to a state in which the screen does not display any image or content and the screen is completely dark or turned off.

[0147] During implementation, you can use the following methods to detect whether the screen of the test phone is in a black screen state.

[0148] Method 1:

[0149] For example: the CI server can send a screenshot instruction to the test phone. After receiving the instruction, the test phone performs screenshot processing to obtain a screenshot image. The test phone detects whether the screen of the test phone is in a black screen state by detecting the pixel values ​​in the screenshot image. For example, the test phone determines whether at least part of the pixel values ​​in the screenshot image are within the preset numerical range 1. When at least part of the pixel values ​​are within the preset numerical range 1, it is determined that the phone is in a black screen state. At this time, the test phone sends a notification to the CI server that the phone is in a black screen state. After receiving the notification, the CI server can detect that the screen of the test phone is in a black screen state. When at least part of the pixel values ​​are not within the preset numerical range 1, it is determined that the phone is not in a black screen state. At this time, the test phone sends a notification to the CI server that the phone is not in a black screen state. After receiving the notification, the CI server can detect that the screen of the test phone is not in a black screen state.

[0150] It should be understood that, for example, in the Red Green Blue (RGB) color model, a pixel value in a screenshot image is composed of a red component (R component), a green component (G component), and a blue component (B component). When the screen of the test mobile phone is in a black screen state, the values ​​of the R component, G component, and B component in a pixel value are low and close to 0. Therefore, assuming that at least some of the pixel values ​​in the screenshot image (for example, all pixel values ​​or some pixel values) are within a preset value range 1 (values ​​within the preset value range 1 refer to values ​​0 or near 0, for example, the preset value range 1 is [0,1], which is not limited in this embodiment of the present application), then it can be determined that the mobile phone is in a black screen state. Assuming that at least some of the pixel values ​​in the screenshot image are not within the preset value range 1, then it can be determined that the mobile phone is not in a black screen state.

[0151] Method 2:

[0152] For example: The CI server can send a screenshot instruction to the test phone. After receiving the instruction, the test phone performs screenshot processing to obtain a screenshot image. The test phone determines the similarity between the screenshot image and a preset image (the preset image refers to a pre-stored image of the test phone in a black screen state). If it is determined that the similarity is within the preset numerical range of 2, it can be determined that the phone is in a black screen state. At this time, the test phone sends a notification to the CI server that the phone is in a black screen state. After receiving the notification, the CI server can detect that the screen of the test phone is in a black screen state. If it is determined that the similarity is not within the preset numerical range of 2, it can be determined that the phone is not in a black screen state. At this time, the test phone sends a notification to the CI server that the phone is not in a black screen state. After receiving the notification, the CI server can detect that the screen of the test phone is not in a black screen state.

[0153] It should be understood that, for example, the similarity between two images can be represented by the mean square error of the pixel values ​​in the two images. The smaller the mean square error, the more similar the two sets of images are. In implementation, for example, the test phone can calculate the mean square error of the pixel values ​​in the screenshot image and the preset image. If the mean square error is within a preset numerical range of 2 (for example, the preset numerical range 1 is [0, 1], which is not limited in this embodiment of the present application), it can be determined that the phone is in a black screen state. If the mean square error is not within the preset numerical range of 2, it can be determined that the phone is not in a black screen state.

[0154] It should also be understood that, for example, the similarity between two images can be represented by the Hamming distance between the two images. The smaller the Hamming distance, the more similar the two images are. In implementation, for example, the test phone can calculate the hash value of the screenshot image and the hash value of the preset image, and then calculate the two hash values ​​to obtain the Hamming distance between the screenshot image and the preset image. If the Hamming distance is within the preset numerical range 2 (for example, the preset numerical range 1 is [0, 1], which is not limited in this embodiment of the present application), it can be determined that the phone is in a black screen state. If the Hamming distance is not within the preset numerical range 2, it can be determined that the phone is not in a black screen state.

[0155] It should be noted that when the CI server detects that the test phone is in a black screen state, the CI server determines that the result of the power-on test is a verification failure. The CI server changes the state of the test phone from busy to offline, ends the power-on test process, and prohibits merging code 1 into the main code branch.

[0156] It should also be noted that detecting whether the screen of the test phone is in a black state can be considered the "third level" of the power-on test.

[0157] S418, when the CI server detects that the test phone is not in a black screen state, the CI server determines that the result of the power-on test is a successful verification, and the CI server changes the state of the test phone from busy to idle, ends the power-on test process, and allows code 1 to be merged into the code master branch.

[0158] It should be understood that when the CI server detects that the test phone is not in a black screen state, it proves that code 1 is not the "problem code" that causes the phone to fail to boot. In this way, the CI server can change the state of the test phone from busy to idle so that the test phone can be used to perform boot tests on the code submitted by the R&D personnel.

[0159] In some embodiments, since the embodiments of the present application are executed on a CI server Figure 1 The power-on test is performed during step 2 (CI access control verification) shown in the figure. Therefore, if the result of the power-on test is successful and the result of the CI access control verification is also successful, execution is allowed. Figure 1 Step 3 shown is the step of merging code 1 into the main branch of the code and subsequent steps.

[0160] In some embodiments, since the boot test is executed on the CI server Figure 1 The power-on test is performed before step 2 shown in the figure, so if the result of the power-on test is verification success, execution is allowed. Figure 1 Step 2 and subsequent steps shown, for example, allow execution Figure 1 The steps for merging code 1 into the main branch of code and subsequent steps are shown.

[0161] In some embodiments, since the boot test is executed on the CI server Figure 1 After step 2 and before step 3, the power-on test is performed. Therefore, if the result of the power-on test is successful, execution is allowed. Figure 1 Step 3 shown is the step of merging code 1 into the main branch of the code and subsequent steps.

[0162] In the embodiment of the present application, Figure 1 In step 3 shown, before merging code 1 into the main branch of the code, a power-on test is performed on each new code submitted by the R&D personnel. After the power-on test verification is successful, subsequent steps such as merging the code into the main branch can be executed. After the power-on test verification fails, the code that failed the verification is prohibited from being merged into the main branch of the code. In this way, compared with related solutions, since a power-on test is performed on each code before merging the code into the main branch, the efficiency of locating the problem code can be improved, so that the problem code can be located in a shorter time, thereby improving the overall R&D efficiency.

[0163] Moreover, the embodiment of the present application combines the detection of whether the system of the test mobile phone has completed startup and the detection of whether the screen of the test mobile phone is in a black screen state. These two aspects are used for power-on testing, which can double-verify whether the test mobile phone has been turned on from the operating system level and the visual level, thereby improving the accuracy of the detection. It avoids the situation where the power-on test is performed by detecting whether the system has completed startup alone, which may lead to the misjudgment of the test mobile phone due to delayed updates or anomalies of system properties, and avoids the situation where the power-on test is performed by detecting whether the screen is in a black screen state alone, which may lead to the misjudgment that the test mobile phone is not turned on due to the long-term stay of the screen protector, lock screen interface or boot animation of the test mobile phone. In other words, the combination of the above two aspects can improve the accuracy and reliability of the power-on test, and avoids the misjudgment and limitations that may be caused by a single method.

[0164] The above embodiments introduce the implementation method of power-on test in the test system provided in the embodiment of the present application. The following embodiments first introduce the software architecture of the test system provided in the embodiment of the present application, and then introduce the power-on test method again in combination with the software architecture.

[0165] For example, please refer to Figure 5 , Figure 5 This is a schematic diagram of the software architecture of a test system provided in an embodiment of the present application. Figure 5As shown, the CI server includes a code access control module, a status management module, and a flashing module. The code access control module is used to perform startup tests on newly submitted code by developers. The status management module is used to manage the status of the test machine, which includes idle, busy, offline, maintaining, and other states. For an explanation of the meaning of these test machine states, please refer to the previous examples and will not be repeated here. The flashing module is used to perform incremental flashing on the test machine.

[0166] The build server includes a build module, which is used to build an archive package based on the executable file 1 generated by the code 1. The archive package is used to facilitate updating the operating system in the test mobile phone.

[0167] The test mobile phone includes a power-on test module, which is used to perform a power-on test on the test mobile phone after the operating system is updated.

[0168] The following examples are combined Figure 5 The software architecture shown here again introduces the implementation process of the power-on test method provided in the embodiment of the present application.

[0169] For example, please refer to Figure 6 , Figure 6 FIG. 1 is a schematic diagram of another power-on test process provided by an embodiment of the present application. The process includes: Step S61 to Step S632.

[0170] S61: The code access control module in the CI server receives a trigger event.

[0171] For the meaning of the trigger event, please refer to the above embodiment and will not be repeated here.

[0172] S62 , the code access control module creates container 1 in response to the triggering event.

[0173] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0174] S63 , the code access control module updates the code 1 to the container 1 .

[0175] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0176] S64 , the code access control module compiles code 1 in container 1 .

[0177] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0178] S65 , the code access control module performs compilation verification on the code 1 during the process of compiling the code 1 or after the compilation of the code 1 is completed.

[0179] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0180] S66: When the result of the code access control module compiling and verifying the code 1 is a verification failure, the code access control module releases the resources occupied by the container 1 and notifies the verification failure message to the Figure 1 The version control server shown prohibits code 1 from being merged into the main branch of the code.

[0181] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0182] S67 , when the result of compiling and verifying the code 1 is successful, the code access control module generates an executable file 1 in the container 1 .

[0183] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0184] S68 , the code access control module sends container 1 (container 1 carries executable file 1 ) to the construction module in the construction server.

[0185] This step can be considered as transferring container 1 from the code gate module in the CI server to the build module in the build server.

[0186] S69 , the construction module generates APK1 in container 1 , and APK1 carries executable file 1 .

[0187] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0188] S610: The construction module creates a system image file or a dynamic partition image file in container 1.

[0189] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0190] S611: The construction module packages the system image file or the dynamic partition image file in the container 1 to generate an archive package, which includes the version number of the software version.

[0191] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0192] In some embodiments, after generating the archive package, the construction module in the construction server may send the archive package to the deployment server, so that the test mobile phone can download the archive package from the deployment server.

[0193] S612: The code access control module in the CI server sends instruction 1 to the status management module (the instruction 1 is used to query the test mobile phone whose status is idle).

[0194] It should be understood that Figure 4 As you can see, after the build server creates the archive, the CI server needs to call an idle test phone for startup testing. The CI server's status management module manages the status of multiple test phones. Therefore, before the code access control module calls the idle test phone, it can query the status management module to see if any of the multiple test phones are in the idle state.

[0195] S613, after receiving instruction 1, the status management module queries whether there is a test phone in the idle state among multiple test phones, and if a test phone in the idle state is found among the multiple test phones, randomly selects one as the test phone for this test and changes the state of the test phone from idle to busy.

[0196] For example, the state management module can query Figure 2 Is there a test phone in the idle state among the three test phones shown? Assuming that the states of these three test phones are all idle, the state management module can use any one of the three test phones (such as test phone 2) as the phone for this test and change the state of test phone 2 from idle to busy. Figure 2 Among the three mobile phones shown, the state of the test mobile phone 2 is idle, so the state management module can use the test mobile phone 2 as the mobile phone for this test and change the state of the test mobile phone 2 from idle to busy.

[0197] S614: The status management module returns the identifier of the test mobile phone with the Busy status to the code access control module.

[0198] Typically, each test mobile phone has a unique identifier, for example, the identifier may refer to a unique device identification code, a mobile device identification code, etc. The embodiment of the present application does not limit the identifier of the test mobile phone.

[0199] S615 , based on the above identifier, the code access control module sends instruction 2 (the instruction is a call instruction for performing a power-on test in a busy state) to the power-on test module in the test mobile phone corresponding to the identifier.

[0200] S616 , after receiving instruction 2 , the startup test module sends request 1 to the construction module in the construction server (the request 1 is used to request downloading of the archive package from the construction module).

[0201] Steps S616 to S618 can be considered as a process in which the startup test module downloads the archive package.

[0202] In some embodiments, after receiving instruction 2, the power-on test module may send request 1 to the construction module in the deployment server. After receiving request 1, the deployment server may send an archive package to the power-on test module.

[0203] S617: The construction module sends the archive package to the startup test module.

[0204] S618, download the archive package of the startup test module.

[0205] S619: The code access control module in the CI server sends instruction 3 to the flashing module (this instruction 3 is used to call the flashing module to perform incremental flashing on the test mobile phone that has downloaded the archive package).

[0206] Steps S619 to S621 can be considered as a process in which the code access control module calls the flashing module to perform incremental flashing on the test mobile phone.

[0207] S620: The flashing module sends instruction 4 to the boot test module (instruction 4 is an instruction for performing incremental flashing on the test mobile phone).

[0208] S621, the boot test module performs incremental flashing processing.

[0209] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0210] S622, the flashing module in the CI server sends a notification 1 to the code access control module (the notification 1 is used to notify the code access control module that the incremental flashing process of the test phone has been completed).

[0211] S623, after receiving the notification 1, the code access control module sends an instruction 5 to the power-on test module (the instruction 5 is an instruction for detecting whether the system of the mobile phone has been tested).

[0212] As can be seen from the above embodiment, the CI server can detect whether the test phone's system has completed booting by sending the "getprop sys.boot_completed" command to the test phone. After receiving this command, if the test phone returns a value of "1" to the CI server, the CI server determines that the test phone's system has completed booting. If the test phone returns a value of "0" to the CI server, the CI server determines that the test phone's system has not completed booting. Therefore, command 5 in step S623 can also refer to "getprop sys.boot_completed."

[0213] S624, after receiving instruction 5, the power-on test module sends notification 2 (carrying the value "0") to the code access control module.

[0214] S625, after receiving the notification 2, the code access control module detects that the system of the test mobile phone has not completed the startup. At this time, the code access control module determines that the result of the power-on test is verification failure. Then, the code access control module changes the state of the test mobile phone from busy to offline through the status management module, ends the power-on test process, and notifies the verification failure message to Figure 1 The version control server shown prohibits code 1 from being merged into the main branch of the code.

[0215] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0216] S626 , after receiving instruction 5 , the power-on detection module sends notification 3 (carrying a value “1”) to the code access control module.

[0217] S627, after receiving the notification 3, the code access control module sends the instruction 6 to the power-on test module (the instruction 6 is an instruction for detecting whether the screen of the test mobile phone is in a black screen state).

[0218] S628, the power-on test module detects whether the screen of the test mobile phone is in a black screen state.

[0219] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0220] S629 , when the power-on test module detects that the screen of the test mobile phone is in a black screen state, it sends a notification 4 to the code access control module (the notification 4 is used to notify the code access control module that the test mobile phone is in a black screen state).

[0221] S630, when the code access control module receives the notification 4, it determines that the result of the power-on test is verification failure. Then the code access control module changes the state of the test phone from busy to offline through the state management module, ends the power-on test process, and notifies the verification failure message to Figure 1 The version control server shown prohibits code 1 from being merged into the main branch of the code.

[0222] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0223] S631, when the power-on test module detects that the screen after the test is not in a black screen state, it sends a notification 5 to the code access control module (the notification 5 is used to notify the code access control module that the test phone is not in a black screen state).

[0224] S632, after receiving the notification 5, the code access control module determines that the result of the power-on test is successful. Then, the code access control module changes the state of the test phone from busy to idle through the state management module, ends the power-on test process, and notifies the user of the successful verification message. Figure 1 The version control server shown allows code 1 to be merged into the main branch of the code.

[0225] Regarding the implementation of this step, please refer to the above embodiment and will not be repeated here.

[0226] The above embodiments are combined Figure 5 The implementation process of the power-on test method provided in the embodiment of the present application is introduced. The following implementation introduces the process of recovering a test machine in an abnormal state (for example, the abnormal state is the offline state mentioned in the above embodiment).

[0227] For example, please refer to Figure 7 , Figure 7 This is a schematic diagram of a test machine that recovers from an abnormal state, provided in an embodiment of the present application.

[0228] S71, periodically update the software version of each test mobile phone.

[0229] It should be understood that Figure 1 After the server builds the software version in step 4, each test phone can periodically download the software version (i.e., download the archive package, which includes the software version number) from the build server. For example, each test phone can download the software version to the server at a preset frequency (e.g., once a day, three times a day, etc., which is not limited in this embodiment of the application). Figure 1 It shows that the build server sends a request to download the software version, and the build server sends the software version to each test mobile phone, so that the software version of each test mobile phone is updated.

[0230] S72: The CI server flashes each test phone.

[0231] for example, Figure 1 The CI server shown performs flashing processing on each test mobile phone through the built-in flashing module. The embodiment of the present application does not limit the implementation method of the flashing processing.

[0232] Typically, after the CI server flashes each test phone, the status of each test phone may be set to idle.

[0233] S73, passed Figure 4 The method steps shown are used to perform power-on test. Figure 4In S412 shown, the CI server calls the test mobile phone in the idle state obtained in step S72 to perform a power-on test.

[0234] S74, in passing Figure 4 If the result of the power-on test in the method steps shown is verification failure, the CI server has changed the state of the test phone from busy to offline. At this time, the CI server needs to flash the test phone and then set the state of the test phone to idle.

[0235] Please understand, please refer to Figure 4 If, at step S416, the system of the test phone is detected to have not completed booting, or if, at step S417, the system of the test phone is detected to have completed booting but the screen of the test phone is detected to be black, both cases indicate that the boot test has failed verification. In such cases, the state of the test phone can be changed from busy to offline, and the boot test process ends. After periodically updating the software version of each test phone at step S71, the CI server needs to flash the test phone in the offline state and then set the state of the test phone to idle.

[0236] In the embodiment of the present application, when the result of the power-on test is verification failure, the test phone can be flashed to restore the test phone in an abnormal state (for example, the abnormal state is the offline state) to a normal state (for example, the normal state is the idle state), thereby avoiding the situation where there are no available test phones due to all test phones being in an abnormal state during the power-on test.

[0237] The following is a summary of the solutions involved in the above embodiments.

[0238] For example, please refer to Figure 8 , Figure 8 This is a schematic flow chart of a test method provided in an embodiment of the present application. This method can be performed by the first electronic device in the test system mentioned in the above embodiment, or by a processor or chip in the first electronic device, and this embodiment of the present application does not impose any limitations. For ease of description, the method is described in detail using the first electronic device as an example. The method includes steps S81 to S82.

[0239] S81, after performing continuous integration verification on the first code, before merging the first code into the main code branch, or before performing continuous integration verification on the first code, or during the process of performing continuous integration verification on the first code, the first electronic device performs a power-on test on the first code.

[0240] It should be understood that the first code refers to, for example, Figure 1 The developer is shown writing new code on a computer. The first code can also refer to Code 1 mentioned in the above embodiment. Continuous integration verification refers to the CI access control verification mentioned in the above embodiment. The meaning of the main branch of the code can be referred to in the above embodiment and will not be repeated here. The first electronic device can refer to the CI server mentioned in the above embodiment.

[0241] It should also be understood that the software development process usually includes, please refer to Figure 1 The process includes submitting code, CI gate verification, merging code into the main code branch, building the software version, and obtaining the built software version.

[0242] The software development process in the relevant scheme is usually to merge the above code into the main branch of the code, and then conduct a startup test on the software version built based on the main branch. Figure 1 The test machine shown downloads the installation package corresponding to the software version built based on the main branch, and then checks whether the test machine can boot normally. This power-on test method is less efficient in locating "problem code" if it detects that the test machine cannot boot normally, because it is based on the software version built on the main branch after multiple code lines are merged into the main branch. Therefore, it takes a long time to locate the problem code, affecting overall R&D efficiency.

[0243] In the embodiment of the present application, after the CI access control verification in the usual software development process, before the code is merged into the code main branch, the newly submitted first code can be powered on and tested through the CI server. It is also possible to perform a power-on test on the newly submitted first code through the CI server during the CI access control verification process in the usual software development process. It is also possible to perform a power-on test on the newly submitted first code through the CI server before the CI access control verification in the usual software development process. This ensures that the power-on test is performed before the code is merged into the main branch.

[0244] S82: When the result of the power-on test of the first electronic device is verification failure, the first electronic device prohibits continuous integration verification of the first code, or prohibits merging the first code into the main code branch.

[0245] It should be understood that, assuming that the first electronic device performs a power-on test on the newly submitted first code through the CI server after the CI access control verification in the usual software development process and before merging the code into the code main branch, then if the result of the power-on test is a verification failure, the execution can be prohibited. Figure 1 Shows the steps for merging code into the main branch of the code.

[0246] Assume that during the CI access control verification process in the usual software development process, the first code submitted is powered on and tested by the CI server. If the result of the power-on test is a verification failure, it proves that the result of the CI access control verification is a verification failure. At this time, the subsequent steps of the CI access control verification of the code in the usual software development process are prohibited. For example, the subsequent steps can refer to Figure 1 Shows the steps for merging code into the main branch of the code.

[0247] Assume that before the CI access control verification in the usual software development process, the newly submitted first code is powered on and tested through the CI server. If the power-on test result is a verification failure, the CI access control verification step and subsequent steps of the code in the usual software development process are prohibited.

[0248] In an embodiment of the present application, after the continuous integration verification in the usual software development process, before the code is merged into the main branch of the code, the newly submitted first code can be powered on and tested by the first electronic device. Or, during the continuous integration verification in the usual software development process, the newly submitted first code can be powered on and tested by the first electronic device. Or, before the continuous integration verification in the usual software development process, the newly submitted first code can be powered on and tested by the first electronic device. In this way, since the code is powered on and tested before being merged into the main branch, the efficiency of locating the "problem code" can be improved, so that the "problem code" can be located in a shorter time, thereby improving the overall R&D efficiency.

[0249] Furthermore, in an embodiment of the present application, when the result of the power-on test is verification failure, the continuous integration verification of the first code can be prohibited (prohibiting the continuous integration verification of the first code also prohibits the first code from being merged into the main code branch), or the merging of the first code into the main code branch can be prohibited, thereby intercepting the "problem code" (first code) from being merged into the main code branch, thereby ensuring the reliability of the main code branch.

[0250] In some embodiments, the test system further includes a test device and a second electronic device; and performing a power-on test on the first code includes:

[0251] The first electronic device generates a first executable file corresponding to the first code based on the first code; constructs an archive package of the first executable file through the second electronic device, and the archive package is a data package used to deploy the code on the test device; deploys the archive package to the test device; and performs a power-on test through the test device.

[0252] It should be understood that the test device may refer to the test mobile phone mentioned in the above embodiment, and the second electronic device may refer to the build server mentioned in the above embodiment. The CI server, the build server, and the test mobile phone are electrically connected to each other via wired or wireless means.

[0253] It should also be understood that the first executable file refers to the executable file 1 mentioned in the above embodiment, and the archive package refers to Figure 4 or Figure 6 The archive package mentioned.

[0254] During implementation, the first electronic device may use a compilation tool to generate a first executable file corresponding to the first code based on the first code, which is not limited in this embodiment of the present application.

[0255] The second electronic device can use a compilation tool to generate a first executable file corresponding to the first code based on the first code, and then build an archive package of the first executable file. It can also reuse the compilation product (first executable file) of the first electronic device to build an archive package of the first executable file. This embodiment of the present application is not limited to this.

[0256] The first electronic device may send a deployment instruction to the test device. After receiving the deployment instruction, the test device downloads the archive package from the second electronic device or the deployment server, and then deploys the archive package to the test device.

[0257] After generating the archive package, the second electronic device can distribute the archive package to the test device so that the test device deploys the archive package. Alternatively, the second electronic device can send the archive package to a deployment server, which can then distribute the archive package to the test device so that the test device deploys the archive package. This embodiment of the present application is not limited to this.

[0258] The first electronic device can perform a power-on test on the test device by detecting whether the operating system of the test device has completed startup. Alternatively, the power-on test can be performed by detecting whether the test device is in a black screen state. Alternatively, the power-on test can be performed on the test device by combining the two methods of detecting whether the operating system of the test device has completed startup and detecting whether the test device is in a black screen state, which is not limited in the embodiments of the present application.

[0259] In an embodiment of the present application, the first electronic device can generate a first executable file based on the first code; construct an archive package of the first executable file through the second electronic device, and deploy the archive package to the test device, so that the first electronic device can be powered on and tested through the test device.

[0260] In some embodiments, generating a first executable file corresponding to the first code based on the first code includes:

[0261] The first electronic device creates a first container; generates a first executable file corresponding to the first code in the first container based on the first code; and, after generating the first executable file corresponding to the first code based on the first code, before constructing an archive package of the first executable file through the second electronic device, the method also includes: transferring the first container to the second electronic device, the first container including the first executable file; and constructing the archive package of the first executable file through the second electronic device, including: constructing the archive package of the first executable file in the first container through the second electronic device.

[0262] It should be understood that the first container refers to container 1 mentioned in the above embodiment. The CI server's creation of container 1 can also be understood as the CI server requesting the compilation of container 1. This container 1 contains all the environments and dependencies required to run the first code submitted by the developer. The implementation of the first electronic device creating the first container can be found in the above embodiment and will not be further elaborated here.

[0263] Regarding the implementation of transferring the first container from the first electronic device to the second electronic device, reference may be made to step S47 in the above embodiment, which will not be described in detail here.

[0264] During implementation, the second electronic device may reuse the compilation product (ie, the first executable file) in the first container to construct an archive package of the first executable file, wherein the archive package includes any one of the following contents: APK1, super.img, and system.img.

[0265] In an embodiment of the present application, the first electronic device can generate a first executable file corresponding to the first code based on the first code in the first container (the first executable file can be considered as a compilation product generated based on the first code in the first container), the first electronic device transfers the first container to the second electronic device, and the second electronic device constructs an archive package of the first executable file in the first container. That is, after the first electronic device transfers the first container to the second electronic device, the second electronic device can reuse the compilation product generated based on the first code (i.e., the first executable file) to generate an archive package, without having to compile the first code again, thereby reducing the time and resources required for compilation, thereby indirectly shortening the duration of the power-on test and improving the efficiency of the power-on test.

[0266] Furthermore, since the second electronic device reuses the compiled product, and both the first electronic device and the second electronic device process the code in the first container, the consistency of the compiled product in the software environment of the first electronic device and the second electronic device can be ensured, thereby reducing problems caused by environmental differences.

[0267] In some embodiments, performing a power-on test using a test device includes:

[0268] The first electronic device detects whether the operating system of the test device has completed startup; if it is detected that the operating system of the test device has not completed startup, it determines that the result of the power-on test is a verification failure; if it is detected that the operating system of the test device has completed startup, it detects whether the test device is in a black screen state; if it is detected that the test device is in a black screen state, it determines that the result of the power-on test is a verification failure; if it is detected that the test device is not in a black screen state, it determines that the result of the power-on test is a verification success.

[0269] For more information about this implementation, please refer to Figure 4 The implementation of steps S415 to S418 shown in FIG. Figure 6 The steps shown in step S623 to step S632 are not repeated here.

[0270] In the embodiment of the present application, the first electronic device can combine the two aspects of detecting whether the operating system of the test device has completed startup and detecting whether the test device is in a black screen state to perform a power-on test. It can double-verify whether the test device has been powered on from the operating system level and the visual level, thereby improving the accuracy of the power-on test. It avoids the situation where the power-on test is performed by detecting whether the operating system has completed startup alone, which may lead to misjudgment of the test device due to delayed updates or abnormalities of the operating system, and avoids the situation where the power-on test is performed by detecting whether the test device is in a black screen state alone, which may lead to misjudgment that the test device is not powered on due to the long-term stay of the screen protector, lock screen interface or boot animation of the test device. In other words, the combination of the above two aspects can improve the accuracy and reliability of the power-on test, and avoids the misjudgment and limitations that may be caused by a single method.

[0271] Among them, detecting whether the test device is in a black screen state includes: the first electronic device takes a screenshot of the test device to obtain a screenshot image; and detecting whether the test device is in a black screen state based on multiple pixel values ​​included in the screenshot image.

[0272] Regarding this implementation method, please refer to the method 1 mentioned in the above embodiment, which will not be repeated here.

[0273] Among them, detecting whether the test device is in a black screen state includes: a first electronic device takes a screenshot of the test device to obtain a screenshot image; based on the screenshot image and the first image, detecting whether the test device is in a black screen state, the first image is a preset stored image of the test device in a black screen state.

[0274] Regarding this implementation method, please refer to the second method mentioned in the above embodiment, which will not be repeated here.

[0275] In some embodiments, if the result of the power-on test is a verification failure, the state of the test device is set to an offline state; and if it is detected that the operating system of the test device has not completed startup, after determining that the result of the power-on test is a verification failure, and if it is detected that the test device is in a black screen state, after determining that the result of the power-on test is a verification failure, the method further includes:

[0276] The first electronic device performs a flashing process on the test device in an offline state; and changes the state of the test device from an offline state to an idle state.

[0277] In implementation, for example, please refer to Figure 4 , if it is detected through S416 that the system of the test phone has not been started up, or it is detected that the system of the test phone has been started up, but it is detected through S417 that the screen of the test phone is in a black state, both of these situations are cases where the result of the power-on test is a verification failure. If the result of the power-on test is a verification failure, the state of the test phone can be changed from busy to offline (the offline state can be considered as an abnormal state of the test phone due to verification failure), and the power-on test process is ended. Figure 7 After periodically updating the software version of each test phone in step S71, the CI server needs to flash the test phones that are in the offline state, and then change the state of the test phones from offline to idle (which can also be understood as changing the state of the test phones from an abnormal state to a normal state, i.e., an idle state). This embodiment of the application does not limit the implementation method of the flashing process.

[0278] In an embodiment of the present application, when the result of the power-on test is verification failure, the test device can be flashed to restore the test device in an abnormal state (for example, the abnormal state is the offline state) to a normal state (for example, the normal state is the idle state), thereby avoiding the situation where no test device is available due to all test devices being in an abnormal state during the power-on test.

[0279] In some embodiments, deploying the archive package to the test device includes:

[0280] The first electronic device performs incremental flashing on the test device based on the archive package.

[0281] It should be understood that incremental flashing is a system upgrade method that only updates the changed parts of the existing system, rather than replacing the entire system image. This method reduces the amount of data required for the upgrade, improves upgrade efficiency, and reduces the risk of upgrade failure.

[0282] It should also be understood that in some embodiments, the archive package is obtained by packaging the system.img mentioned in the above embodiments. In other embodiments, the archive package is obtained by packaging the super.img mentioned in the above embodiments. In implementation, for example, if the archive package is obtained by packaging the system.img, the new system.img (the system.img in the archive package downloaded from the build server) can be compared with the old system.img (the system.img in the original operating system of the test machine) to generate an update package containing only the differences. The update package includes executable file 1, and the operating system of the test phone is updated using the update package. For another example, if the archive package is obtained by packaging the super.img, the new super.img (the super.img in the archive package downloaded from the build server) can be compared with the old super.img (the super.img in the original operating system of the test machine) to generate an update package containing only the differences. The update package includes executable file 1, and the operating system of the test phone is updated using the update package. The embodiments of this application do not limit the method of incremental flashing.

[0283] It should also be understood that since super.img is an image file that contains multiple system partitions, which may include system.img, the processing efficiency of incremental flashing of the test mobile phone when the archive package is obtained based on the packaging of system.img is higher than the processing efficiency of incremental flashing of the test mobile phone when the archive package is obtained based on the packaging of super.img.

[0284] In the embodiment of the present application, since the first electronic device deploys the archive package to the test device through incremental flashing, this incremental flashing method can reduce the amount of data transmission required when deploying the archive package, improve the deployment efficiency, and thus indirectly improve the test efficiency of the entire power-on test.

[0285] In some embodiments, based on the first code, a first executable file corresponding to the first code is generated;

[0286] The first electronic device compiles the first code, and during the compilation process of the first code, or after the compilation process of the first code, compiles and verifies the first code; if the result of the compilation and verification is that the verification is successful, a first executable file corresponding to the first code is generated.

[0287] The implementation method can be found in the above Figure 4The implementation method of steps S43 to S46 shown in FIG will not be repeated here.

[0288] In the embodiment of the present application, the first electronic device can perform compilation verification on the first code during the process of compiling the first code or after compiling the first code, thereby improving the flexibility of the first electronic device in performing compilation verification.

[0289] Moreover, when the result of the compilation verification is successful, the first electronic device generates a first executable file corresponding to the first code. After that, the first electronic device can continue to execute the subsequent steps after generating the first executable file in the test method provided in the embodiment of the present application. That is to say, the compilation verification can serve as the "first checkpoint" of the test method of the embodiment of the present application, which improves the reliability of the first electronic device in performing power-on testing through the test equipment.

[0290] In some embodiments, constructing an archive package of the first executable file by the second electronic device includes:

[0291] The first electronic device generates an application package based on the first executable file through the second electronic device, and the application package includes the first executable file; creates a first image file based on the application package through the second electronic device, and the first image file includes a system image file or a dynamic partition image file, and the first image file includes the application package; and constructs an archive package corresponding to the first code based on the first image file through the second electronic device.

[0292] It should be understood that the first image file refers to a system image file (eg, system.img mentioned in the above embodiment) or a dynamic partition image file (eg, super.img mentioned in the above embodiment).

[0293] It should also be understood that generating application package 1 based on executable file 1 can be understood as customizing APK and other resources based on executable file 1 to generate APK1. For example, customizing APK and other resources may include modifying the APK's configuration based on executable file 1, adding or removing functionality represented by executable file 1, and so on. Customized APK1 typically represents code changes at the application level, and these changes need to be integrated into the operating system's system partition. system.img is an image file that contains the operating system framework, libraries, and pre-installed applications (including customized APK1). Therefore, customized APK1 needs to be included in system.img so that these applications can be loaded and used as part of the system when the device boots. super.img is an image file that contains multiple system partitions, which may include system.img, vendor.img, and so on. Although customized APK1 is integrated into system.img, it also indirectly becomes part of super.img.

[0294] For more information on this implementation, please refer to the above Figure 4 The implementation shown in steps S48 to S49 can also be referred to Figure 6 The implementation methods shown in S69 to S611 are not repeated here.

[0295] In an embodiment of the present application, a first electronic device can generate an application package based on a first executable file through a second electronic device, where the application package includes a first executable file (the application package can be considered as a carrier for changing the code at the application level); a first image file can be created based on the application package through the second electronic device (the first image file can be considered as a carrier for changing the code at the operating system level); an archive package corresponding to the first code can be constructed based on the first image file through the second electronic device, and then the archive package can be deployed to a test machine for a power-on test. This can not only test whether the first code has a power-on problem at the application level, but also test whether the first code has a power-on problem at the operating system level, so as to ensure that the first code will not introduce a power-on problem at either the application level or the operating system level, thereby ensuring the reliability of the power-on test.

[0296] In some embodiments, during the continuous integration verification of the first code, performing a startup test on the first code includes:

[0297] The first electronic device performs code quality verification on the first code, and performs a power-on test on the first code, where the continuous integration verification includes code quality verification, and the code quality verification includes at least code style verification, code unit test, and code integration test; when the result of the code quality verification is a successful verification, if the result of the power-on test is a successful verification, then the result of the continuous integration verification is determined to be a successful verification; when the result of the code quality verification is a successful verification, or when the result of the code quality verification is a failed verification, if the result of the power-on test is a failed verification, then the result of the continuous integration verification is determined to be a failed verification.

[0298] It should be understood that code quality verification refers to the verification operations that CI access control verification originally needs to perform, including at least code style verification, code unit testing, and code integration testing.

[0299] It should also be understood that during the CI access control verification process, the first electronic device can perform code quality verification and power-on test at the same time, or perform power-on test before code quality verification, or perform power-on test after code quality verification. The embodiments of the present application do not limit this.

[0300] It is also understood that if the result of the power-on test is verification failure, the first electronic device determines that the result of the CI access control verification is verification failure, regardless of whether the result of the code quality verification is verification success or verification failure. If the result of the power-on test is verification success, the first electronic device determines that the result of the CI access control verification is verification success only if the result of the code quality verification is verification success.

[0301] In an embodiment of the present application, during the process of continuous integration verification performed by the first electronic device, the first electronic device may perform code quality verification on the first code, and perform a power-on test on the first code; when the result of the code quality verification is a successful verification, if the result of the power-on test is a successful verification, then the result of the continuous integration verification is determined to be a successful verification; when the result of the code quality verification is a successful verification, or when the result of the code quality verification is a failed verification, if the result of the power-on test is a failed verification, then the result of the continuous integration verification is determined to be a failed verification, so that the reliability of the continuous integration verification can be guaranteed.

[0302] The embodiment of the present application provides a test system, including a first electronic device, a second electronic device and a test device; wherein,

[0303] The first electronic device is used to execute Figure 8The first electronic device shown may perform various operations; the second electronic device is used to build an archive package based on the first executable file generated by the first code, and the archive package is a data package used to deploy the code on the test device; the test device is used to perform a power-on test.

[0304] For more information about this test system, please refer to Figure 2 In the test system shown, the first electronic device can also perform various operations that may be performed by the CI server mentioned in the above embodiments, the second electronic device can also perform various operations that may be performed by the build server mentioned in the above embodiments, and the test device can also perform various operations that may be performed by the test mobile phone mentioned in the above embodiments, which will not be repeated here.

[0305] The embodiment of the present application can perform a power-on test on the newly submitted first code through the test system after the continuous integration verification in the usual software development process and before the code is merged into the main branch of the code. Or, during the continuous integration verification in the usual software development process, the newly submitted first code can be powered on and tested by the test system. Or, before the continuous integration verification in the usual software development process, the newly submitted first code can be powered on and tested by the test system. In this way, since the code is powered on and tested before being merged into the main branch, the efficiency of locating the "problem code" can be improved, so that the "problem code" can be located in a shorter time, thereby improving the overall R&D efficiency.

[0306] Furthermore, in an embodiment of the present application, when the result of the power-on test is verification failure, the continuous integration verification of the first code can be prohibited (prohibiting the continuous integration verification of the first code also prohibits the first code from being merged into the main code branch), or the merging of the first code into the main code branch can be prohibited, thereby intercepting the "problem code" (first code) from being merged into the main code branch, thereby ensuring the reliability of the main code branch.

[0307] It should be noted that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0308] The present application provides a computer program product that, when executed on an electronic device, enables the electronic device to execute the technical solution in the above embodiment. The implementation principle and technical effects are similar to those of the above method-related embodiments and will not be described in detail here.

[0309] The embodiment of the present application provides a readable storage medium, which contains instructions. When the instructions are executed on an electronic device, the electronic device executes the technical solution of the above embodiment. The implementation principle and technical effect are similar and will not be repeated here.

[0310] The present application provides a chip for executing instructions. When the chip is running, the technical solution of the above embodiment is executed. The implementation principle and technical effect are similar and will not be described here.

[0311] In the above embodiments, all or part of the embodiments can be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a high-density digital video disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0312] It should be understood that the “embodiment” mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, the various embodiments in the entire specification do not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in the various embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

[0313] Those skilled in the art will understand that the various numerical numbers such as first and second involved in this application are only for the convenience of description and are not used to limit the scope of the embodiments of this application, and also indicate the order of precedence.

[0314] In this application, elements expressed in the singular are intended to mean "one or more" rather than "one and only one" unless otherwise specified. In this application, unless otherwise specified, "at least one" is intended to mean "one or more" and "a plurality" is intended to mean "two or more."

[0315] The term "and / or" in this article is merely a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. A can be singular or plural, and B can be singular or plural.

[0316] The term "at least one of..." in this document refers to all or any combination of the listed items. For example, "at least one of A, B and C" can mean: A exists alone, B exists alone, C exists alone, A and B exist at the same time, B and C exist at the same time, and A, B and C exist at the same time. A can be singular or plural, B can be singular or plural, and C can be singular or plural.

[0317] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0318] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0319] The same or similar parts between the various embodiments in this application can refer to each other. In the various embodiments in this application, and the various implementation methods / implementation methods / implementation methods in each embodiment, if there is no special explanation and logical conflict, the terms and / or descriptions between different embodiments and the various implementation methods / implementation methods / implementation methods in each embodiment are consistent and can be referenced to each other. The technical features in different embodiments and the various implementation methods / implementation methods / implementation methods in each embodiment can be combined to form new embodiments, implementation methods, implementation methods, or implementation methods according to their inherent logical relationships. The above-described implementation methods of this application do not constitute a limitation on the scope of protection of this application.

[0320] The above is only a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or replacements within the technical scope disclosed in the present application, which should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims. In short, the above is only a preferred embodiment of the technical solution of the present application, and is not used to limit the scope of protection of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A testing method, characterized in that: A first electronic device used in a test system, the first electronic device is used to perform continuous integration verification on a first code submitted to a software development process, the software development process including continuous integration verification and merging the first code into a main code branch, the test system also including a test device and a second electronic device; And, the method comprises: After performing continuous integration verification on the first code, before merging the first code into the code master branch, or before performing continuous integration verification on the first code, or during the process of performing continuous integration verification on the first code, performing a startup test on the first code, including: Create the first container; generating, in the first container, a first executable file corresponding to the first code based on the first code; Transferring the first container to the second electronic device, where the first container includes the first executable file; Generate, by the second electronic device, an application package in the first container based on the first executable file, wherein the application package includes the first executable file, and the archive package is a data package for deploying code on the test device; creating, by the second electronic device, a first image file based on the application package, wherein the first image file includes a system image file or a dynamic partition image file, and the first image file includes the application package; Building the archive package corresponding to the first code based on the first image file by the second electronic device; Performing incremental flashing on the test device based on the archive package; Perform a power-on test using the test equipment; If the result of the power-on test is verification failure, continuous integration verification of the first code is prohibited, or merging the first code into the code main branch is prohibited.

2. The method according to claim 1, characterized in that The power-on test is performed by the test equipment, including: Detecting whether the operating system of the test device has completed startup; In the case of detecting that the operating system of the test device has not completed startup, determining that the result of the power-on test is a verification failure; When detecting that the operating system of the test device has completed startup, detecting whether the test device is in a black screen state; In the case where it is detected that the test device is in a black screen state, determining that a result of the power-on test is a verification failure; When it is detected that the test device is not in a black screen state, the result of the power-on test is determined to be a successful verification.

3. The method according to claim 2, characterized in that The detecting whether the test device is in a black screen state includes: Performing screenshot processing on the test device to obtain a screenshot image; Based on a plurality of pixel values ​​included in the screenshot image, it is detected whether the test device is in a black screen state.

4. The method according to claim 2, characterized in that The detecting whether the test device is in a black screen state includes: Performing screenshot processing on the test device to obtain a screenshot image; Based on the screenshot image and the first image, it is detected whether the test device is in a black screen state, where the first image is a preset stored image of the test device in a black screen state.

5. The method according to claim 2, characterized in that If the result of the power-on test is a verification failure, the state of the test device is set to an offline state; and after determining that the result of the power-on test is a verification failure when detecting that the operating system of the test device has not completed startup, and after determining that the result of the power-on test is a verification failure when detecting that the test device is in a black screen state, the method further includes: Flashing the test device that is in an offline state; The state of the test device is changed from offline to idle.

6. The method according to any one of claims 1 to 5, characterized in that Generating a first executable file corresponding to the first code based on the first code in the first container includes: Compiling the first code in the first container, and performing compilation verification on the first code during or after compiling the first code; If the result of the compilation verification is that the verification is successful, a first executable file corresponding to the first code is generated.

7. The method according to claim 1, characterized in that The step of performing a startup test on the first code during the continuous integration verification of the first code includes: Performing code quality verification on the first code and performing a startup test on the first code, wherein continuous integration verification includes code quality verification, and code quality verification includes at least code style verification, code unit testing, and code integration testing; When the result of the code quality verification is successful, if the result of the power-on test is successful, then the result of the continuous integration verification is determined to be successful. In a case where the result of the code quality verification is verification success, or in a case where the result of the code quality verification is verification failure, if the result of the power-on test is verification failure, it is determined that the result of the continuous integration verification is verification failure.

8. A testing system, characterized in that: It includes a first electronic device, a second electronic device and a testing device; wherein, The first electronic device is configured to perform the method according to any one of claims 1 to 7; The second electronic device is used to build an archive package based on the first executable file generated by the first code, and the archive package is a data package used to deploy the code on the test device; The testing device is used for performing a power-on test.

9. An electronic device, characterized in that: include: one or more processors; one or more memories; The one or more memories store one or more computer programs, and the one or more computer programs include instructions. When the instructions are executed by the one or more processors, the electronic device performs the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The method comprises computer instructions, which, when executed on an electronic device, cause the electronic device to execute the method according to any one of claims 1 to 7.

11. A chip, characterized in that: The chip includes: a memory for storing instructions; A processor, configured to call and execute the instructions from the memory, so that an electronic device equipped with the chip executes the method according to any one of claims 1 to 7.

Images