Test method and test system

Abstract

The invention provides a test method and a test system, and the method can carry out the boot test of a newly submitted first code through a first electronic device after the continuous integration verification in a general software research and development process and before the code is merged to a code main branch. Or in the process of continuous integration verification in the general software research and development process, the first electronic equipment is used for carrying out startup testing on the newly submitted first code, or before the continuous integration verification in the general software research and development process, the first electronic equipment is used for carrying out startup testing on the newly submitted first code. A common software research and development process comprises continuous integration verification, combination of codes to code main branches and the like, and since the codes are subjected to startup testing before the codes are combined to the main branches, the efficiency of positioning problem codes can be improved, the problem codes can be positioned in a short time, and the overall research and development efficiency is improved.

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 use the built software version, etc.

[0003] In the related 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 powered on and tested.

[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, as 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] The present application provides a testing method and a testing system, which can improve the efficiency of locating "problem codes", so that the "problem codes" can be located in a shorter period of time, thereby improving the overall research and development efficiency.

[0006] In a first aspect, a testing method is provided, which is applied to a first electronic device of a testing system, wherein the first electronic device is used to perform continuous integration verification on a first code submitted to a software development process, wherein the software development process includes continuous integration verification and merging the first code into a code main branch; and the method includes: After performing continuous integration verification on the first code, before merging the first code into a 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, performing continuous integration verification on the first code is prohibited, or merging the first code into the main code branch is prohibited.

[0007] The embodiment of the present application can perform a power-on test on the newly submitted first code through the first electronic device 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 through 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 through the first electronic device. In this way, since the power-on test is performed on the code before the code is 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 period of time, thereby improving the overall research and development efficiency.

[0008] Furthermore, in the 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 merging of the first code 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.

[0009] In combination 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: 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, 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.

[0010] 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.

[0011] In conjunction with the first aspect, in a possible implementation manner of the first aspect, generating a first executable file corresponding to the first code based on the first code includes: 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 building 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 building an archive package of the first executable file through the second electronic device, including: building an archive package of the first executable file in the first container through the second electronic device.

[0012] 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.

[0013] Furthermore, since the second electronic device reuses the compiled product, and the first electronic device and the second electronic device both 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.

[0014] In conjunction with the first aspect, in a possible implementation of the first aspect, performing a power-on test by a test device includes: The first electronic device detects whether the operating system of the test device has completed startup; when 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; when 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; when 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; when 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.

[0015] In the embodiment of the present application, the first electronic device can perform a power-on test by combining the detection of whether the operating system of the test device has completed startup and the detection of whether the test device is in a black screen state. 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 power-on test by only detecting whether the operating system has completed startup, which may misjudge the test device due to delayed updates or abnormalities of the operating system, and avoids the power-on test by only detecting whether the test device is in a black screen state, which may misjudge the test device as not powered on due to the long 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 avoid the misjudgment and limitations that may be caused by a single method.

[0016] 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.

[0017] 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 being a preset stored image of the test device in a black screen state.

[0018] In combination with the first aspect, in a possible implementation of the first aspect, when the result of the power-on test is a verification failure, the state of the test device is set to an offline state; and when 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 when 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: 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.

[0019] In the embodiment of the present application, when the result of the power-on test is a verification failure, the test device can be flashed to restore the test device in an abnormal state (for example, the abnormal state is an offline state) to a normal state (for example, the normal state is an 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.

[0020] In conjunction with the first aspect, in a possible implementation of the first aspect, deploying the archive package to the test device includes: Incrementally flash the test device based on the archive package.

[0021] In the embodiment of the present application, since the first electronic device deploys the archive package to the test device by 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.

[0022] In conjunction with the first aspect, in a possible implementation manner of the first aspect, generating a first executable file corresponding to the first code based on the first code includes: The first electronic device compiles the first code, and during the process of compiling the first code, or after compiling the first code, compiles and verifies the first code; when the result of the compilation and verification is that the verification is successful, a first executable file corresponding to the first code is generated.

[0023] 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.

[0024] Furthermore, when the result of the compilation verification is successful, the first electronic device generates a first executable file corresponding to the first code, and then 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. In other words, 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 a power-on test through the test equipment.

[0025] In conjunction with the first aspect, in a possible implementation of the first aspect, building an archive package of the first executable file by the second electronic device includes: 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.

[0026] 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, wherein 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.

[0027] In conjunction with the first aspect, in a possible implementation of the first aspect, during the process of performing continuous integration verification on the first code, performing a startup test on the first code includes: The first electronic device performs code quality verification on the first code, and performs a power-on test on the first code, the continuous integration verification including 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.

[0028] 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 ensured.

[0029] 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, 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 a first executable file generated by a first code, and the archive package is a data packet used to deploy the code on a test device; the test device is used to perform a power-on test.

[0030] The embodiment of the present application can perform a power-on test on the newly submitted first code through a 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 through a test system. Or, before the continuous integration verification in the usual software development process, the newly submitted first code can be powered on through a test system. In this way, since the code is powered on 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 period of time, thereby improving the overall research and development efficiency.

[0031] Furthermore, in the 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 merging of the first code 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.

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

[0033] 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.

[0034] 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.

[0035] 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. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0037] Figure 2 It is a schematic diagram of a test system provided in an embodiment of the present application.

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

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

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

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

[0042] Figure 7 It is a schematic diagram of recovering a test machine in an abnormal state provided in an embodiment of the present application.

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

[0044] 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.

[0045] 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.

[0046] Step 1: After the developer writes the code on the computer, he / she submits the code to the 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.

[0047] Step 2: After the developer submits the code on the computer, the continuous integration (CI) verification process can be triggered. The CI verification process can also be called CI access control verification. Specifically, the CI access control verification can be performed through the CI server. The CI access control verification includes various verifications of the newly submitted code, such as code style verification, compilation verification, unit testing, integration testing, etc. In the implementation, for example, after the version control server receives the submitted code, the computer can send a request to the CI server to start the CI access control verification. After receiving the request, the CI server can perform CI access control verification on the code.

[0048] 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).

[0049] The main branch of the code is the most core branch in the project and usually represents the stable version of the project. In many projects, the main branch is also called master or main. The main branch usually contains code that has been fully tested and reviewed and is considered ready for deployment to the production environment. In the early stages of software development, all development work may be carried out on the main branch, but as the project matures and the team expands, more branches are usually introduced to manage different development processes.

[0050] A branch is an independent code line created from the main branch to isolate specific feature development, fix bugs, or conduct 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.

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

[0052] Step 5: The developer can retrieve the built software version from the build server. For example, the developer 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 notifies the user's electronic device that a new version has been released and provides a download link or update mechanism.

[0053] The software development process in the relevant scheme is usually to perform a startup test on the software version built based on the main branch after the above step 4. For example, the installation package corresponding to the software version built based on the main branch is downloaded on the test machine, and then the test machine is checked whether it can be started normally. In this startup test method, when it is detected that the test machine cannot be started normally, because it is based on the software version built on the code main branch after multiple codes are merged into the code main branch, the efficiency of locating the code that causes the failure to start (the code that causes the failure to start can be referred to as "problem code") is low, so it takes a long time to locate the problem code, affecting the overall development efficiency. For example, multiple developers submit multiple codes through the above step 1, and after merging these multiple codes into the code main branch through step 4, the software version is built based on the code main branch, and then the startup test is performed. When it is detected that the test machine cannot be started normally, it is necessary to check whether the multiple codes have the problem of not starting, which leads to low efficiency in locating the problem code.

[0054] 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, a power-on test is performed during the CI access control verification in the above step 2. For another example, a 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, a 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 related solutions, since a power-on test is performed on each code before the code is 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.

[0055] 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 by wire or wireless means, which is not limited in the embodiment of the present application.

[0056] 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 a wireless transceiver function, etc. For example, the first electronic device may refer to Figure 1 The CI server shown. The embodiments of the present application do not limit the specific technology and specific device form used 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.

[0057] The second 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 construction server shown. The embodiments of the present application do 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.

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

[0059] It is to be understood that the test system illustrated in the embodiment 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, which is used to download the software version of the newly submitted code from the build server and deploy the software version to the test device.

[0060] For example, please refer to Figure 2 , Figure 2 It is a 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 by a CI server, the second electronic device is illustrated by a build server, and the test device is illustrated by a test mobile phone. Figure 2 The CI server shown in FIG. 1 is connected to the build server via a wired or wireless mode. The build server is connected to the deployment server via a wired or wireless mode. The deployment server is connected to the test mobile phone 1, the test mobile phone 2, and the test mobile phone 3 via a wired or wireless mode, respectively.

[0061] 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.

[0062] 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, etc.

[0063] It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the first electronic device. In other embodiments of the present application, the first electronic device may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0064] 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 mentioned above, and will not be described in detail here.

[0065] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (Application processor, App), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and / or a neural-network processing unit (neural-network processing unit, NPU), etc. Among them, different processing units may be independent devices or integrated in one or more processors.

[0066] 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.

[0067] The processor 110 may also be provided with a memory for storing instructions and data.

[0068] The wireless communication module 150 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the first electronic device. 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.

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

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

[0071] 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.

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

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

[0074] For example, please refer to Figure 4 , Figure 4 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.

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

[0076] 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 trigger 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 another example, code 1 is submitted to Figure 1 After the version control server is shown, the R&D personnel actively execute the operation of triggering the power-on test on the computer, so this operation can also be considered as a trigger event. For another 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 as a trigger event.

[0077] It should also be understood 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 system that supports Docker. Docker containers include application code, runtime environment, system tools, system libraries, etc.

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

[0079] The advantages of creating Docker include: ensuring consistent behavior of code in different environments (development, testing, production). Containers can be started and stopped quickly, making them easy to deploy and scale. Each container runs in an isolated environment and does not affect each other. Containers can be easily migrated between different devices.

[0080] In implementation, the CI server may create the container 1 by using a tool specifically created for Docker. The embodiment of the present application does not limit the method for creating the container 1.

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

[0082] 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.

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

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

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

[0086] It should also be understood that the compilation process generally consists of the following stages: The first stage: preprocessing, processing preprocessing instructions in the source code, such as expansion of macro definitions, conditional compilation instructions, etc.

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

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

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

[0090] 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.

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

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

[0093] 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 1 The version control server shown prohibits code 1 from being merged into the main branch of the code.

[0094] It should be understood that if the result of compile 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 boot. Therefore, compile verification can be considered the "first checkpoint" of the power-on test. If the result of compile verification is verification failure, the CI server will notify the startup test of the verification failure. Figure 1 The version control server shown in the figure prohibits merging code 1 into the main branch of the code after receiving the message.

[0095] It should also be understood that the CI server releases the resources occupied by container 1, which means releasing the resources of the CI server occupied by container 1, the purpose of which is to reduce the occupation of system resources 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 stopping and deleting container 1 to release the resources occupied by container 1, which is not limited in this embodiment of the present application.

[0096] S46, when the result of the compilation verification is that the verification is successful, an executable file 1 is generated.

[0097] 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.

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

[0099] 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.

[0100] The purpose of transferring container 1 from the CI server to the build server is that the build server can reuse the compilation product in container 1, namely, executable file 1. In this way, the build server does not need to compile code 1 again, which reduces the time and resources required for compilation, shortens the duration of the startup test, and improves the efficiency of the startup test. In addition, the build server reuses the compilation product in container 1, which can ensure the environmental consistency of the compilation product in the build server and the CI server, reducing the problems caused by environmental differences.

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

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

[0103] 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.

[0104] 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.

[0105] S49, the build server creates a system image file (system.img) or a dynamic partition image file (super.img) in container 1.

[0106] It should be understood that a customized APK1 usually represents code changes at the application level, and these changes need to be integrated into the system partition of the operating system. system.img is an image file that contains the operating system framework, libraries, and pre-installed applications (including 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 starts.

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

[0108] It should also be understood that when 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 power-on test can be performed on the test machine. It can not only test whether Code 1 has the problem of not booting up at the application level, but also test whether Code 1 has the problem of not booting up at the operating system level, so as to ensure that Code 1 will not introduce the problem of not booting up at either the application level or the operating system level.

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

[0110] 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.

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

[0112] 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.

[0113] S411, the CI server performs a power-on test by calling a test mobile phone in an idle state.

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

[0115] In implementation, for example, Figure 2 Among the three test mobile phones shown, test mobile phone 1 is in a busy state, test mobile phone 2 is in a maintaining state, and test mobile phone 3 is in an idle state, so the CI server calls test mobile phone 3 to perform a startup test.

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

[0117] S412, the CI server calls the test mobile phone in idle state, and changes the state of the test mobile phone from idle to busy.

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

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

[0120] 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 shown, at this time, the mobile phone can send a request to download the archive package to the deployment server to request downloading the archive package.

[0121] S414, the CI server performs incremental flashing on the test mobile phone based on the archive package.

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

[0123] In implementation, for example, when the archive package is obtained based on the packaging of system.img, the new system.img (system.img in the archive package downloaded from the build server) and the old system.img (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 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 (super.img in the archive package downloaded from the build server) and the old super.img (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 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.

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

[0125] 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.

[0126] S415, after the incremental flashing process is completed, the CI server detects whether the system of the test mobile phone has been started.

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

[0128] 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.

[0129] 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 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.

[0130] 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 boot 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.

[0131] In some embodiments, since the boot test is executed on the 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 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 the code and subsequent steps are shown.

[0132] 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 failure, execution is prohibited Figure 1 Step 2 and subsequent steps shown, for example, prohibit execution Figure 1 The steps for merging code 1 into the main branch of the code and subsequent steps are shown.

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

[0134] 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.

[0135] 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.

[0136] In the implementation, the following method can be used to detect whether the screen of the test phone is in a black screen state.

[0137] Method 1: For example: the CI server can send a screenshot instruction to the test phone. After receiving the instruction, the test phone performs a screenshot process 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.

[0138] It should be understood that, for example, in the Red Green Blue (RGB) color model, a pixel value in the 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, the G component and the B component in a pixel value are low and close to 0. Therefore, assuming that at least part of the pixel values ​​in the screenshot image (for example, all pixel values ​​or part of the pixel values) are within a preset value range 1 (the values ​​within the preset value range 1 refer to values ​​0 or values ​​near 0, for example, the preset value range 1 is [0,1], which is not limited in the embodiment of the present application), then it can be determined that the mobile phone is in a black screen state. Assuming that at least part 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.

[0139] Method 2: For example: the CI server can send a screenshot command to the test phone. After receiving the command, 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). When it is determined that the similarity is within the preset numerical range 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. When it is determined that the similarity is not within the preset numerical range 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.

[0140] It should be understood that, for example, the similarity of 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 mobile phone can calculate the mean square error of the pixel values ​​in the screenshot image and the preset image. When the mean square error is within the preset numerical range 2 (for example, the preset numerical range 1 is [0,1], which is not limited in the embodiment of the present application), it can be determined that the mobile phone is in a black screen state. When the mean square error is not within the preset numerical range 2, it can be determined that the mobile phone is not in a black screen state.

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

[0142] 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.

[0143] 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.

[0144] 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 main code branch.

[0145] 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.

[0146] 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 verification and the result of the CI access control verification is also successful verification, execution is allowed. Figure 1 Step 3 shown is a step of merging code 1 into the main branch of the code and subsequent steps.

[0147] 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 the code and subsequent steps are shown.

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

[0149] In the embodiment of the present application, Figure 1 Step 3 shown performs a power-on test on each new code submitted by the R&D personnel before merging code 1 into the main branch of the code. 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 the code is 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.

[0150] In addition, 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 the power-on test, 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 power-on test by detecting whether the system has completed startup alone, which may misjudge the test mobile phone due to delayed updates or abnormalities of system properties, and avoids the power-on test by detecting whether the screen is in a black screen state alone, which may misjudge the test mobile phone as not turned on due to the long 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 avoid the misjudgment and limitations that may be caused by a single method.

[0151] 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.

[0152] For example, please refer to Figure 5 , Figure 5 Schematic diagram of the software architecture of a test system provided in an embodiment of the present application. Figure 5 As shown, the CI server includes a code access control module, a status management module and a flashing module. Among them, the code access control module is used to perform startup tests on the newly submitted codes by the R&D personnel. The status management module is used to manage the status of the test machine. The status of the test machine includes idle, busy, offline, maintaining, etc. For the relevant explanation of the meaning of the above-mentioned status of the test machine, please refer to the above embodiment, which will not be repeated here. The flashing module is used to perform incremental flashing processing on the test machine.

[0153] 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, so as to facilitate updating the operating system in the test mobile phone through the archive package.

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

[0155] The following embodiments are combined Figure 5 The software architecture shown re-introduces the implementation process of the power-on test method provided in the embodiment of the present application.

[0156] For example, please refer to Figure 6 , Figure 6Schematic diagram of another power-on test process provided by an embodiment of the present application. The process includes: step S61 to step S632.

[0157] S61, the code access control module in the CI server receives a trigger event.

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

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

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

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

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

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

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

[0165] S65, the code access control module compiles and verifies the code 1 during the process of compiling the code 1 or after the code 1 is compiled.

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

[0167] S66: When the result of compiling and verifying the code 1 is that the verification fails, 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.

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

[0169] 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.

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

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

[0172] 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.

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

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

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

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

[0177] 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.

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

[0179] 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 may download the archive package from the deployment server.

[0180] 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).

[0181] It should be understood that Figure 4 It can be seen that after the build server builds the archive package, the CI server needs to call the test phone in the idle state to perform the boot test. The state management module in the CI server can manage the states of multiple test phones. Therefore, before the code access control module calls the test phone in the idle state, the code access control module can send a query to the state management module to see whether there is a test phone in the idle state among the multiple test phones.

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

[0183] For example, the state management module can query Figure 2Is 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.

[0184] S614, the status management module returns the identification of the test mobile phone with a Busy status to the code access control module.

[0185] 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.

[0186] S615, based on the above identification, 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 identification.

[0187] 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 to download the archive package from the construction module).

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

[0189] 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.

[0190] S617, the construction module sends the archive package to the startup test module.

[0191] S618, the startup test module downloads the archive package.

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

[0193] 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.

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

[0195] S621, the power-on test module performs incremental flashing processing.

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

[0197] 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 mobile phone has been completed).

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

[0199] As can be seen from the above embodiments, the CI server can detect whether the system of the test phone has completed startup by sending the getprop sys.boot_completed instruction to the test phone. After the test phone receives the instruction, if the test phone returns a value of "1" to the CI server, the CI server determines that the system of the test phone has completed startup. If the test phone returns a value of "0" to the CI server, the CI server determines that the system of the test phone has not completed startup. Therefore, instruction 5 in step S623 can also refer to "getprop sys.boot_completed".

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

[0201] S625, after receiving the notification 2, the code access control module detects that the system of the test mobile phone has not been started. At this time, the code access control module determines that the result of the power-on test is a verification failure. Then, the code access control module changes the state of the test mobile 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.

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

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

[0204] S627, after receiving the notification 3, the code access control module sends an 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).

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

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

[0207] S629, when the power-on test module detects that the screen of the test mobile phone is in a black screen state, the power-on test module 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).

[0208] S630, when the code access control module receives the notification 4, it determines that the result of the power-on test is a verification failure. Then, the code access control module changes the state of the test mobile 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.

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

[0210] S631, when the power-on test module detects that the screen after the test is not in a black screen state, the power-on test module 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 mobile phone is not in a black screen state).

[0211] 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 mobile phone from busy to idle through the state management module, ends the power-on test process, and notifies the verification success message to Figure 1 The version control server shown allows code 1 to be merged into the main branch of the code.

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

[0213] 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).

[0214] For example, please refer to Figure 7 , Figure 7It is a schematic diagram of recovering a test machine in an abnormal state provided in an embodiment of the present application.

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

[0216] It should be understood that Figure 1 After the server builds the software version in step 4, each test mobile phone can periodically download the software version (i.e., download the archive package, which includes the version number of the software version) from the build server. For example, each test mobile phone downloads 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 the present 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.

[0217] S72, the CI server flashes each test mobile phone.

[0218] for example, Figure 1 The CI server shown flashes each test mobile phone through a built-in flashing module, and the embodiment of the present application does not limit the implementation method of the flashing process.

[0219] Usually, after the CI server flashes each test phone, the status of each test phone can be set to idle.

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

[0221] S74, in passing Figure 4 When 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.

[0222] Please understand, please refer to Figure 4, when 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 screen state, both of which are cases where the result of the power-on test is a verification failure. When the result of the power-on test is a verification failure, the state of the test phone can be changed from busy to offline, and the power-on test process is terminated. After the software version of each test phone is periodically updated through 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.

[0223] 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 that is in an abnormal state (for example, the abnormal state is an offline state) to a normal state (for example, the normal state is an 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.

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

[0225] For example, please refer to Figure 8 , Figure 8 : is a schematic flow chart of a test method provided in an embodiment of the present application. The method can be executed 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 the embodiment of the present application does not make any limitation. For ease of description, the method is described in detail by taking the first electronic device as an example. The method includes steps S81 to S82.

[0226] 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.

[0227] It should be understood that the first code refers to, for example, Figure 1 The developer shown writes new code on the computer. The first code can also refer to the 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.

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

[0229] The software development process in the relevant scheme usually involves merging the above code into the main branch of the code and then conducting 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 detects whether the test machine can be powered on normally. This power-on test method, when it is detected that the test machine cannot be powered on normally, is inefficient in locating "problem codes" because it is based on the software version built on the main branch of the code after multiple codes are merged into the main branch of the code. Therefore, it takes a long time to locate the problem code, affecting the overall R&D efficiency.

[0230] The embodiment of the present application can perform 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 main branch of the code. 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 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 merging the code into the main branch.

[0231] 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.

[0232] 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, execution can be prohibited. Figure 1 Shows the steps to merge code into the main branch of the code.

[0233] Assume that during the CI access control verification process in the usual software development process, the newly submitted first code is powered on and tested through 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 performing CI access control verification on the code in the usual software development process are prohibited. For example, the subsequent steps can refer to Figure 1 Shows the steps to merge code into the main branch of the code.

[0234] 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, at this time, the CI access control verification step and subsequent steps of the code in the usual software development process are prohibited.

[0235] The embodiment of the present application can perform a power-on test on the newly submitted first code through the first electronic device 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 through 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 through the first electronic device. In this way, since the power-on test is performed on the code before the code is 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 period of time, thereby improving the overall research and development efficiency.

[0236] Furthermore, in the 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 merging of the first code 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.

[0237] 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: 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, 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.

[0238] 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 in a wired or wireless manner.

[0239] 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.

[0240] In 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.

[0241] 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 construct an archive package of the first executable file. It can also reuse the compilation product (first executable file) of the first electronic device to construct an archive package of the first executable file. The embodiment of the present application is not limited to this.

[0242] 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.

[0243] After generating the archive package, the second electronic device may distribute the archive package to the test device so that the test device deploys the archive package. The archive package may also be sent to a deployment server, and the deployment server distributes the archive package to the test device so that the test device deploys the archive package. This embodiment of the application does not limit this.

[0244] The first electronic device may perform a power-on test on the test device by detecting whether the operating system of the test device has completed startup. The power-on test on the test device may also be performed by detecting whether the test device is in a black screen state. The power-on test on the test device may also be performed 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.

[0245] 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.

[0246] In some embodiments, based on the first code, generating a first executable file corresponding to the first code includes: 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 building 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 building an archive package of the first executable file through the second electronic device, including: building an archive package of the first executable file in the first container through the second electronic device.

[0247] It should be understood that the first container refers to the container 1 mentioned in the above embodiment. The CI server creates container 1, which can also be understood as the CI server applying to compile container 1. This container 1 contains all the environments and dependencies required to run the first code newly submitted by the R&D personnel. The implementation method of the first electronic device creating the first container can be referred to the above embodiment, which will not be repeated here.

[0248] Regarding the implementation method 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.

[0249] In 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.

[0250] 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.

[0251] Furthermore, since the second electronic device reuses the compiled product, and the first electronic device and the second electronic device both 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.

[0252] In some embodiments, performing a power-on test by a test device includes: The first electronic device detects whether the operating system of the test device has completed startup; when 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; when 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; when 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; when 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.

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

[0254] In the embodiment of the present application, the first electronic device can perform a power-on test by combining the detection of whether the operating system of the test device has completed startup and the detection of whether the test device is in a black screen state. 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 power-on test by only detecting whether the operating system has completed startup, which may misjudge the test device due to delayed updates or abnormalities of the operating system, and avoids the power-on test by only detecting whether the test device is in a black screen state, which may misjudge the test device as not powered on due to the long 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 avoid the misjudgment and limitations that may be caused by a single method.

[0255] 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.

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

[0257] 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 being a preset stored image of the test device in a black screen state.

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

[0259] In some embodiments, when the result of the power-on test is a verification failure, the state of the test device is set to an offline state; and when 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 when 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: 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.

[0260] 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 which 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 ends. Figure 7 After the software version of each test phone is periodically updated in step S71, the CI server needs to flash the test phone in the offline state, and then change the state of the test phone from offline to idle (which can also be understood as changing the state of the test phone from an abnormal state to a normal state, i.e., an idle state). The embodiment of the present application does not limit the implementation method of the flashing process.

[0261] In the embodiment of the present application, when the result of the power-on test is a verification failure, the test device can be flashed to restore the test device in an abnormal state (for example, the abnormal state is an offline state) to a normal state (for example, the normal state is an 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.

[0262] In some embodiments, deploying the archive package to the test device includes: The first electronic device performs incremental flashing on the test device based on the archive package.

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

[0264] It should also be understood that in some embodiments, the archive package is obtained based on the packaging of the system.img mentioned in the above embodiments. In other embodiments, the archive package is obtained based on the packaging of the super.img mentioned in the above embodiments. 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) can be compared with the old system.img (the system.img in the original operating system of the test machine), and an update package containing only the difference part can be generated, and the update package includes executable file 1, and the operating system of the test mobile 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) can be compared with the old super.img (the super.img in the original operating system of the test machine), and an update package containing only the difference part can be generated, and the update package includes executable file 1, and the operating system of the test mobile phone is updated through the update package. The embodiment of the present application does not limit the method of incremental flashing processing.

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

[0266] In the embodiment of the present application, since the first electronic device deploys the archive package to the test device by 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.

[0267] In some embodiments, based on the first code, a first executable file corresponding to the first code is generated; The first electronic device compiles the first code, and during the process of compiling the first code, or after compiling the first code, compiles and verifies the first code; when the result of the compilation and verification is that the verification is successful, a first executable file corresponding to the first code is generated.

[0268] The implementation method can refer to the above Figure 4 The implementation method of steps S43 to S46 shown in FIG. 1 is not repeated here.

[0269] 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.

[0270] Furthermore, when the result of the compilation verification is successful, the first electronic device generates a first executable file corresponding to the first code, and then 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. In other words, 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 a power-on test through the test equipment.

[0271] In some embodiments, constructing an archive package of the first executable file by the second electronic device includes: 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.

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

[0273] 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 configuration of APK based on executable file 1, adding or deleting functions represented by executable file 1, etc. Customized APK1 usually represents changes in code at the application level, and these changes need to be integrated into the system partition of the operating system. 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 starts. super.img is an image file that contains multiple system partitions, which may include system.img, vendor.img, etc. Although customized APK1 is integrated in system.img, they also indirectly become part of super.img.

[0274] For more information about this implementation, please refer to the above Figure 4 The implementation method shown in steps S48 to S49 shown in FIG. Figure 6 The implementation methods shown in S69 to S611 are not repeated here.

[0275] 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, wherein 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, which can test whether the first code has a power-on problem not only from the application level but also from the operating system level, thereby ensuring 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.

[0276] In some embodiments, during the process of performing continuous integration verification on the first code, performing a startup test on the first code includes: The first electronic device performs code quality verification on the first code, and performs a power-on test on the first code, the continuous integration verification including 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.

[0277] 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.

[0278] It should also be understood that, during the CI access control verification process, the first electronic device may simultaneously perform code quality verification and power-on test, or may perform power-on test before code quality verification, or may perform power-on test after code quality verification, and the embodiments of the present application are not limited to this.

[0279] It can also be understood that when the result of the power-on test is a verification failure, the first electronic device determines that the result of the CI access control verification is a verification failure, regardless of whether the result of the code quality verification is a verification success or a verification failure. When the result of the power-on test is a verification success, the first electronic device determines that the result of the CI access control verification is a verification success only when the result of the code quality verification is a verification success.

[0280] 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 ensured.

[0281] The embodiment of the present application provides a test system, including a first electronic device, a second electronic device and a test device; wherein, The first electronic device is used to perform Figure 8 The first electronic device is shown to have various possible operations that can be performed; the second electronic device is used to build an archive package based on a first executable file generated by a first code, and the archive package is a data package used to deploy the code on a test device; the test device is used to perform a power-on test.

[0282] 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.

[0283] The embodiment of the present application can perform a power-on test on the newly submitted first code through a 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 through a test system. Or, before the continuous integration verification in the usual software development process, the newly submitted first code can be powered on through a test system. In this way, since the code is powered on 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 period of time, thereby improving the overall research and development efficiency.

[0284] Furthermore, in the 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 merging of the first code 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.

[0285] 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 the present application.

[0286] The embodiment of the present application provides a computer program product, when the computer program product is run on an electronic device, the electronic device executes the technical solution in the above embodiment. Its implementation principle and technical effect are similar to those of the above method-related embodiments, and will not be repeated here.

[0287] The embodiment of the present application provides a readable storage medium, the readable storage medium contains instructions, when the instructions are executed in 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.

[0288] The embodiment of the present application provides a chip, the chip is used to execute instructions, when the chip is running, the technical solution in the above embodiment is executed. The implementation principle and technical effect are similar, and will not be repeated here.

[0289] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part 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, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital video disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0290] 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 various embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution, and 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.

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

[0292] 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, "at least one" is intended to mean "one or more", and "more than one" is intended to mean "two or more", unless otherwise specified.

[0293] The term "and / or" in this article is merely a description of the association relationship of associated objects, indicating that there may 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.

[0294] In this document, the term "at least one of..." means all or any combination of the listed items. For example, "at least one of A, B and C" may 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 may be singular or plural, B may be singular or plural, and C may be singular or plural.

[0295] Those of ordinary skill 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 to be beyond the scope of this application.

[0296] 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 can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0297] 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.

[0298] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope 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 protection scope of the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A testing method, characterized in that: A first electronic device applied to a test system, wherein the first electronic device is used to perform continuous integration verification on a first code submitted to a software development process, wherein the software development process includes continuous integration verification and merging the first code into a code main branch; And, the method comprises: After performing continuous integration verification on the first code, before merging the first code into the code main 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 power-on test on the first code; When 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 test system further includes a test device and a second electronic device; and the power-on test on the first code includes: Based on the first code, generate a first executable file corresponding to the first code; Building an archive package of the first executable file by the second electronic device, wherein the archive package is a data package for deploying code on the test device; deploying the archive package to the test device; A power-on test is performed by using the test equipment.

3. The method according to claim 2, characterized in that The generating, based on the first code, a first executable file corresponding to the first code includes: Create a first container; generating, in the first container, a first executable file corresponding to the first code based on the first code; and, After generating a first executable file corresponding to the first code based on the first code and before constructing an archive package of the first executable file by the second electronic device, the method further includes: transferring the first container to the second electronic device, wherein the first container includes the first executable file; and, The step of constructing an archive package of the first executable file by the second electronic device includes: The archive package of the first executable file is constructed in the first container by the second electronic device.

4. The method according to claim 2, characterized in that: The power-on test is performed by the test device, including: Detecting whether the operating system of the test device has completed startup; In the case where it is detected 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 starting, 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, it is determined that the result of the power-on test is a successful verification.

5. The method according to claim 4, 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.

6. The method according to claim 4, 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, wherein the first image is a preset stored image of the test device in a black screen state.

7. The method according to claim 4, characterized in that In the case where 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 it is detected 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 it is detected that the test device is in a black screen state, the method further includes: Flashing the test device in an offline state; The state of the test device is changed from an offline state to an idle state.

8. The method according to any one of claims 2 to 7, characterized in that: The step of deploying the archive package to the test device includes: Incrementally flash the test device based on the archive package.

9. The method according to any one of claims 2 to 7, characterized in that: The generating, based on the first code, a first executable file corresponding to the first code includes: Compiling the first code, and during or after compiling the first code, compiling and verifying the first code; When the result of the compilation verification is that the verification is successful, a first executable file corresponding to the first code is generated.

10. The method according to any one of claims 2 to 7, characterized in that: The step of constructing an archive package of the first executable file by the second electronic device includes: generating, by the second electronic device based on the first executable file, an application package, wherein the application package includes the first executable file; Creating a first image file based on the application package by the second electronic device, 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; The archive package corresponding to the first code is constructed by the second electronic device based on the first image file.

11. 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.

12. 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 used to perform the method according to any one of claims 1 to 11; The second electronic device is used to construct 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.

13. 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, which, when executed by the one or more processors, enable the electronic device to perform the method as claimed in any one of claims 1 to 11.

14. 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 11.

15. A chip, characterized in that: The chip comprises: 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 as claimed in any one of claims 1 to 11.

Images