Automated Testing Method, Device and Electronic Device for Mobile Operating System Upgrade

Abstract

The present application discloses an automated testing method, device and electronic device for mobile operating system upgrade, which relates to the field of information technology. The method includes: obtaining system interfaces whose behaviors change due to mobile operating system upgrade in an application or software development kit; generating a library file corresponding to the system interface; performing digital signature on the generated library file to obtain a digitally signed library file; respectively compiling test packages for simulating the behaviors of the system interface on different versions of operating systems based on the digitally signed library file, wherein the different versions of operating systems are generated by the upgrade of the mobile operating system; testing whether the application or the software development kit can run normally when the mobile operating system is upgraded on the same device according to the test packages corresponding to the different versions of operating systems. The present application can complete the upgrade test of the operating system only through one test device, thereby reducing the test cost.

Description

Technical Field

[0001] This application relates to the field of information technology, and particularly to an automated testing method, device and electronic device for mobile operating system upgrade. Background Art

[0002] Mobile operating systems such as Android, iOS, and HarmonyOS are updated relatively frequently. iOS releases two versions every year, and Android releases at least one new version every year. HarmonyOS is an operating system independently developed in China, and it is expected to maintain an iteration frequency of 1-2 new versions per year after its official commercial use. In this context, mobile software development faces a problem: when an SDK (Software Development Kit) or application developed on a low-version system is upgraded to a high-version system, due to changes in system interface behavior, the SDK or application may run abnormally. Therefore, every time a new system is released, compatibility testing needs to be performed on the new system.

[0003] Currently, after the mobile operating system is upgraded, once a problem occurs with the SDK or application, developers will fix the problem and at the same time find a test device for upgrade testing. However, due to the relatively frequent version updates of the mobile operating system, this existing testing method requires preparing multiple test devices, resulting in a relatively high testing cost. Summary of the Invention

[0004] In view of this, this application provides an automated testing method, device and electronic device for mobile operating system upgrade, and the main purpose is to complete the upgrade testing of the operating system only through one test device, thereby reducing the testing cost.

[0005] According to the first aspect of this application, an automated testing method for mobile operating system upgrade is provided, and the method includes:

[0006] Obtain the system interfaces in the application or software development kit whose behaviors have changed due to the upgrade of the mobile operating system;

[0007] Generate a library file corresponding to the system interface;

[0008] Perform digital signature on the generated library file to obtain a digitally signed library file;

[0009] Based on the digitally signed library file, compile test packages for simulating the behaviors of the system interfaces on different versions of the operating system respectively, where the different versions of the operating system are generated by the upgrade of the mobile operating system;

[0010] Test whether the application or the software development tool can run properly when the mobile operating system is upgraded on the same device according to the test packages corresponding to different versions of the operating system.

[0011] According to a second aspect of the present application, there is provided an automated test device for upgrading a mobile operating system, the device comprising:

[0012] An acquisition unit, configured to acquire system interfaces whose behaviors change due to the upgrade of the mobile operating system in an application or a software development toolkit;

[0013] A generation unit, configured to generate a library file corresponding to the system interface;

[0014] A signature unit, configured to perform a digital signature on the generated library file to obtain a digitally signed library file;

[0015] A compilation unit, configured to respectively compile test packages for simulating the behaviors of the system interfaces on different versions of the operating system based on the digitally signed library file, wherein the different versions of the operating system are generated by the upgrade of the mobile operating system;

[0016] A test unit, configured to test whether the application or the software development tool can run properly when the mobile operating system is upgraded on the same device according to the test packages corresponding to different versions of the operating system.

[0017] According to a third aspect of the present application, there is provided a storage medium, on which a computer program is stored, and when the program is executed by a processor, the automated test method for upgrading the mobile operating system described above is implemented.

[0018] According to a fourth aspect of the present application, there is provided an electronic device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, and when the processor executes the program, the automated test method for upgrading the mobile operating system described above is implemented.

[0019] With the above technical solution, compared with the prior art, an automated testing method, device, and electronic device for mobile operating system upgrades provided by this application can generate a library file by obtaining system interfaces in an application or software development kit whose behaviors change due to mobile operating system upgrades, and based on the library file, compile test packages for simulating the behaviors of the system interfaces on different versions of the operating system, so as to test whether an application or software development can run properly on different versions of the operating system on the same device. Since the test packages compiled by this application can simulate the behaviors of system interfaces on different versions of the operating system, this application does not need to find devices installed with different versions of the operating system for upgrade testing. As long as the test packages corresponding to different versions of the operating system are installed on the same device in sequence, the behaviors of the system interfaces on different operating systems can be simulated, thereby completing the test. This can reduce the test cost and enable repeated testing. At the same time, by compiling test packages, this application can design various test scenarios, thereby making the test cases more comprehensive. In addition, this application can also be combined with an automated testing platform for automated testing to improve the test efficiency.

[0020] The above description is only an overview of the technical solution of this application. In order to be able to understand the technical means of this application more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features, and advantages of this application more obvious and understandable, the specific embodiments of this application are specifically given below. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings described herein are used to provide a further understanding of this application and form a part of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an improper limitation of this application. In the drawings:

[0022] Figure 1 A flowchart showing an automated testing method for mobile operating system upgrades provided by an embodiment of this application is shown;

[0023] Figure 2 A structural diagram showing an automated testing device for mobile operating system upgrades provided by an embodiment of this application is shown;

[0024] Figure 3 A structural diagram showing another automated testing device for mobile operating system upgrades provided by an embodiment of this application is shown. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0025] The following will refer to the drawings and describe this application in detail in conjunction with embodiments. It should be noted that, without conflict, the embodiments in this application and the features in the embodiments can be combined with each other.

[0026] The testing method of the prior art requires preparing multiple testing devices, resulting in a relatively high testing cost.

[0027] To solve the above problems, an embodiment of the present invention provides an automated testing method for mobile operating system upgrades, as Figure 1 shown. The method includes:

[0028] Step 101: Obtain system interfaces in an application or software development kit whose behaviors change due to a mobile operating system upgrade.

[0029] Among them, the mobile operating system includes Android, iOS, HarmonyOS, etc.

[0030] The embodiment of the present invention is mainly applicable to the scenario of testing an application or software development kit during a mobile operating system upgrade. The execution subject of the embodiment of the present invention is a device or equipment capable of performing mobile operating system upgrade testing.

[0031] For the embodiment of the present invention, system upgrade detection can be performed on the device where the application or software development kit is located to obtain system interfaces in the application or software development kit whose behaviors change due to a mobile operating system upgrade, thereby obtaining an interface set ChangeableSetA.

[0032] For example, for a tool kit for obtaining a device identifier on the Android system, it calls the system's interface for obtaining the mac address and the interface for obtaining the device serial number to generate the device identifier. The system interface for obtaining the mac address can normally return the mac address below Android 6.0, but can only return a fixed value at Android 6.0 and above. In addition, the system interface for obtaining the device serial number can normally return the device serial number below Android 9.0, but can only return a fixed value at Android 9.0 and above. Thus, it can be concluded that the system interfaces for obtaining the mac address and the device serial number change in behavior during system upgrade. Therefore, the system interfaces for obtaining the mac address and the device serial number are added to the interface set ChangeableSetA.

[0033] In addition, in addition to obtaining system interfaces whose behaviors change due to system upgrade through system upgrade detection, system interfaces that may change in behavior due to system upgrade can also be obtained through other judgments, and these system interfaces are added to the interface set ChangeableSetB.

[0034] Since it has been determined that certain system interfaces will change their behaviors due to operating system upgrades, resulting in the inability of applications or software development kits to implement business functions. At this time, developers need to adjust the business logic so that the applications or software development kits can also normally implement business functions during operating system upgrades and pass the upgrade tests.

[0035] Step 102: Generate a library file corresponding to the system interface.

[0036] For the embodiments of the present invention, after obtaining the system interface, a library file corresponding to the system interface is generated. For this process, step 102 specifically includes: writing the system interface into a target module; packaging the target module to obtain the library file corresponding to the system interface. The library file includes at least one of the following: jar package,.a static library,.so dynamic library, and.framework dynamic library, etc. It should be noted that the types of library files in the embodiments of the present invention are not limited to the above. In addition, one application or one software development kit can correspond to one target module, and different applications or different software development kits correspond to different target modules.

[0037] Specifically, the target module ChangeableModule will ultimately be packaged into a single jar package, or.a static library, or.so dynamic library, or.framework dynamic library, thereby obtaining the library file libraryA.

[0038] In some embodiments, in order to verify the integrity of the library file during subsequent testing, the embodiments of the present invention need to pre-develop a digital signature service or application. The function of this service or application is to generate an asymmetric key pair, digitally sign the incoming data, and display the signature result. The public key of this service or application needs to be exported for use during the development stage. Among them, the asymmetric algorithm can specifically be RSA, SM2, etc.

[0039] An application or software development kit can ultimately be composed of the library file libraryA compiled from the target module and the library files libraryB, libraryC, etc. compiled from the business function modules. When the business function module needs to call the system interfaces in ChangeableSetA or ChangeableSetB, it can be achieved by calling the system interfaces in libraryA.

[0040] Step 103: Digitally sign the generated library file to obtain a digitally signed library file.

[0041] For the embodiments of the present invention, in order to ensure the integrity of the library file and prevent attackers from tampering with and adding malicious code, it is necessary to digitally sign the library file so that the integrity of the library file can be verified based on the digital signature result when the APP runs. Among them, the digital signature result of the library file is in the corresponding configuration file, and the public key of the library file is built into the business function module that needs to call the library file in the application or software development kit. The business function module can verify the integrity of the library file based on the digital signature result and the public key of the library file when calling the library file.

[0042] Step 104: Based on the digitally signed library file, compile test packages for simulating the behaviors of the system interface on different versions of operating systems respectively.

[0043] Among them, the different versions of operating systems are generated by upgrading the mobile operating system.

[0044] For the embodiments of the present invention, after obtaining the library file, it is necessary to compile test packages corresponding to different versions of operating systems for the library file. For this process, step 103 specifically includes: compiling the system interfaces in the digitally signed library file respectively based on the behaviors of the system interface on different versions of operating systems to obtain test packages for simulating the behaviors of the system interface on different versions of operating systems.

[0045] For example, based on the library file libraryA, compile multiple test packages libraryA1, libraryA2, and libraryA3. Among them, libraryA1 is used to simulate the behavior of the system interface on operating system 1.0, libraryA2 is used to simulate the behavior of the system interface on operating system 2.0, and libraryA3 is used to simulate the behavior of the system interface on operating system 3.0.

[0046] In some embodiments, in order to ensure the integrity of the test package and prevent attackers from tampering with and adding malicious code, it is necessary to digitally sign the test package so that the integrity of the test package can be verified based on the digital signature result when the APP runs. Based on this, the method includes: digitally signing the test packages corresponding to different versions of the operating system respectively to obtain the digital signature results and public keys of the test packages corresponding to different versions of the operating system, wherein the digital signature results are in the corresponding configuration file, and the public keys are built into the business function modules that need to call the system interface in the application or software development kit; when the application or software development kit runs on any version of the operating system among different versions of the operating system and the business function module needs to call the system interface, the business function module obtains the digital signature result of the test package corresponding to any version of the operating system from the corresponding configuration file, and verifies whether the content of the test package corresponding to any version of the operating system is complete based on the digital signature result and the corresponding public key; if the content of the test package corresponding to any version of the operating system is complete, then the system interface call is made.

[0047] For example, the test package corresponding to operating system 1.0 is libraryA1, the test package corresponding to operating system 2.0 is libraryA2, and the test package corresponding to operating system 3.0 is libraryA3. Before the formal test, digital signatures are respectively applied to the test packages libraryA1, libraryA2, and libraryA3. Then, the public keys corresponding to the test packages libraryA1, libraryA2, and libraryA3 are built into the business function module. At the same time, the signature result corresponding to the test package libraryA1 is written into the configuration file of the application or the software development kit. Among them, if the product is an application, the digital signature result is directly written into its configuration file; if the product is a software development kit, the caller can write the signature result into the APP configuration file. During the formal test, when the business function module of the application or the software development kit calls the system interface, it will first obtain the public key and the digital signature result corresponding to libraryA1, and verify the integrity of the system interface in libraryA1. If the verification passes, the business function module will then call the system interface in the test package libraryA1; otherwise, an error will be returned. After completing the test of operating system 1.0, the signature result corresponding to the test package libraryA2 is written into the configuration file of the application or the software development kit. During the formal test, when the business function module of the application or the software development kit calls the system interface, it will first obtain the public key and the digital signature result corresponding to libraryA2, and verify the integrity of the system interface in libraryA2. If the verification passes, the business function module will then call the system interface in the test package libraryA2. Similarly, after completing the test of operating system 2.0, the signature result corresponding to the test package libraryA3 is written into the configuration file of the application or the software development kit. During the formal test, when the business function module of the application or the software development kit calls the system interface, it will first obtain the public key and the digital signature result corresponding to libraryA3, and verify the integrity of the system interface in libraryA3. If the verification passes, the business function module will then call the system interface in the test package libraryA3.

[0048] Step 105: According to the test packages corresponding to different versions of the operating system, test whether the application or the software development kit can run normally when the mobile operating system is upgraded on the same device.

[0049] For the embodiments of the present invention, during formal testing, test packages corresponding to different versions of the operating system are successively integrated into the application or software development kit, and installed on the same device for running, so as to obtain the return results of the application or software development kit running on the different versions of the operating system; if the return results of the application or software development kit running on the different versions of the operating system are consistent, it is determined that the application or the software development kit can run normally when the mobile operating system is upgraded.

[0050] Following the above example, first integrate the test package libraryA1 into the application or software development kit, and then install the application or software development kit integrated with libraryA1 on a test device (such as a mobile phone, tablet, etc.) for testing. After the application or software development kit runs successfully, replace the test package libraryA1 with the test package libraryA2, then integrate the test package libraryA2 into the application or software development kit, and install and run it to test whether the application or software development kit can run normally when the operating system is upgraded from 1.0 to 2.0. If the return results of the application or software development kit when the operating system is upgraded from 1.0 to 2.0 are consistent, it indicates that the application or software development kit can run normally when the operating system is upgraded from 1.0 to 2.0. Similarly, replace the test package libraryA2 with the test package libraryA3 to test whether the application or the operating system can run normally when the operating system is upgraded from 2.0 to 3.0. If the return results of the application or software development kit when the operating system is upgraded from 2.0 to 3.0 are consistent, it indicates that the application or software development kit can run normally when the operating system is upgraded from 2.0 to 3.0. That is, the system upgrade test of the embodiments of the present invention is equivalent to the replacement test of libraryA.

[0051] Among them, the successful operation of the software development kit means that the application integrated with the software development kit SDK runs successfully.

[0052] The embodiments of the present invention can simulate the behavior of the system interface on different operating systems by compiling test packages corresponding to different operating systems, and can repeat the test on one device. In addition, by compiling multiple test packages, the embodiments of the present invention can design various different test cases, so as to ensure that the application or software development kit can run normally when the system is upgraded, and improve the product quality.

[0053] Furthermore, the embodiments of the present invention can complete the replacement operation, packaging operation and installation operation of the test packages corresponding to different versions of the operating system based on the automated test framework script to achieve automated testing.

[0054] Specifically, since the system upgrade test of the embodiments of the present invention is equivalent to the replacement test of libraryA, operations such as replacement, packaging, and installation can be completed through scripts of automated test frameworks such as Appium, thereby realizing automated testing.

[0055] To make the technical solutions of the embodiments of the present invention clearer, taking the toolkit for obtaining device identifiers on the Android system as an example, the entire system upgrade test process will be described in detail.

[0056] The toolkit for obtaining device identifiers on the Android system calls the system's WifiManager interface and Build.SERIAL interface. Among them, the WifiManager interface is used to obtain the mac address, and the Build.SERIAL interface is used to obtain the device serial number.

[0057] The WifiManager interface returns normally on Android systems below 6.0, such as bc:d0:74:0d:76:6a, but will return the fixed value 02:00:00:00:00:00 on Android 6.0 and above systems. The Build.SERIAL interface returns normally on Android systems below 9.0, such as LKX0217C12001548, but will return the fixed value unknown on Android 9.0 and above systems.

[0058] If the toolkit concatenates the mac address and the device serial number as the device identifier, the following problems will occur: 1. When the Android system is upgraded from 5.0 to 6.0, the toolkit will return different device identifiers; 2. When the Android system is upgraded from 8.0 to 9.0, the toolkit will return different device identifiers.

[0059] Based on this, the embodiments of the present invention can write the WifiManager interface and the Build.SERIAL interface into the target module ChangeableModule, and then package the target module ChangeableModule to generate the library file libraryA.

[0060] At the same time, developers need to modify the logic for obtaining device identifiers to fix the problems that occur during system upgrades. For example, developers can consider obtaining the mac address and the device serial number through other methods provided by the system, or they can deprecate these two device information and use other devices, such as using the file ID, TEE flag, etc. as the device identifier.

[0061] Further, according to the library file libraryA, three test packages libraryA, libraryB, and libraryC are compiled. Among them, for the test package libraryA, the WifiManager interface returns normal values, and the Build.SERIAL interface returns normal values; for the test package libraryB, the WifiManager interface returns 02:00:00:00:00:00, and the Build.SERIAL interface returns normal values; for the test package libraryC, the WifiManager interface returns 02:00:00:00:00:00, and the Build.SERIAL interface returns unknown.

[0062] Then, digital signature processing is performed on the test packages libraryA, libraryB, and libraryC respectively to obtain the digital signature results corresponding to the test packages libraryA, libraryB, and libraryC. The signature results are written in the corresponding configuration files. Then, the test packages libraryA, libraryB, and libraryC are integrated into the device identification toolkit in sequence and installed on the same device for operation. The installation replacement order is libraryA1, libraryA2, libraryA3. The content to be tested is: 1. Whether the device identification returned by the toolkit is consistent when the Android system is upgraded from 5.0 to 6.0 (libraryA1 -> libraryA2); 2. Whether the device identification returned by the toolkit is consistent when the Android system is upgraded from 8.0 to 9.0 (libraryA2 -> libraryA3). If the device identification is consistent in both of the above scenarios, it means that the developers have fixed the problem this time.

[0063] Testers can deploy the above-compiled test packages libraryA, libraryB, and libraryC in an automated testing service such as Appium, write scripts to automatically complete replacement, packaging, installation and operation, and testing, so as to be able to automate the system upgrade test during each regression test.

[0064] An automated testing method for mobile operating system upgrades provided by an embodiment of the present invention. By obtaining system interfaces in an application or software development kit whose behaviors change due to mobile operating system upgrades, generating library files, and based on the library files, respectively compiling test packages for simulating the behaviors of the system interfaces on different versions of the operating system, it is possible to test whether an application or software development tool can operate normally on different versions of the operating system on the same device. Since the test packages compiled by the embodiments of the present invention can simulate the behaviors of system interfaces on different versions of the operating system, the embodiments of the present invention do not need to find devices installed with different versions of the operating system for upgrade testing. As long as the test packages corresponding to different versions of the operating system are sequentially installed on the same device, the behaviors of the system interfaces on different operating systems can be simulated, thereby completing the test, which can reduce the test cost and achieve repeated testing. At the same time, by compiling test packages, the embodiments of the present invention can design various test scenarios, making the test cases more comprehensive. In addition, the embodiments of the present invention can also be combined with an automated testing platform for automated testing to improve the test efficiency.

[0065] Further, as Figure 1 a specific implementation of the method shown, this embodiment provides an automated testing device for mobile operating system upgrades, as Figure 2 shown. The device includes: an acquisition unit 31, a generation unit 32, a signature unit 33, a compilation unit 34, and a testing unit 35.

[0066] The acquisition unit 31 can be used to obtain system interfaces in an application or software development kit whose behaviors change due to mobile operating system upgrades.

[0067] The generation unit 32 can be used to generate library files corresponding to the system interfaces.

[0068] The signature unit 33 is used to perform digital signature on the generated library files to obtain digitally signed library files.

[0069] The compilation unit 34 can be used to respectively compile test packages for simulating the behaviors of the system interfaces on different versions of the operating system based on the digitally signed library files, where the different versions of the operating system are generated by the mobile operating system upgrade.

[0070] The testing unit 35 can be used to test whether the application or the software development tool can operate normally when the mobile operating system is upgraded on the same device according to the test packages corresponding to different versions of the operating system.

[0071] In some embodiments, the obtaining unit 31 may be specifically configured to perform a system upgrade detection on the device where the application or the software development kit is located, so as to obtain a system interface in the application or the software development kit whose behavior has changed due to the upgrade of the mobile operating system.

[0072] In some embodiments, the generating unit 32 may be specifically configured to write the system interface into a target module; and package the target module to obtain a library file corresponding to the system interface, where the library file includes at least one of the following: a jar package, a static.a library, a dynamic.so library, and a dynamic.framework library.

[0073] In some embodiments, the compiling unit 34 may be specifically configured to compile the system interfaces in the digitally signed library file respectively based on the behaviors of the system interfaces on different versions of the operating system, so as to obtain a test package for simulating the behaviors of the system interfaces on different versions of the operating system.

[0074] In some embodiments, the testing unit 35 may be specifically configured to sequentially integrate the test packages corresponding to different versions of the operating system into the application or the software development kit, and install them on the same device for running, so as to obtain the return results of the application or the software development kit when running on different versions of the operating system; if the return results of the application or the software development kit when running on different versions of the operating system are consistent, it is determined that the application or the software development tool can run normally when the mobile operating system is upgraded.

[0075] In some embodiments, as Figure 3 shown, the apparatus further includes: a verification unit 36.

[0076] The signing unit 33 may also be used to respectively digitally sign the test packages corresponding to different versions of the operating system, so as to obtain the digital signature results and public keys of the test packages corresponding to different versions of the operating system, where the digital signature results are in the corresponding configuration file, and the public keys are built into the business function modules in the application or the software development kit that need to call the system interface.

[0077] The verification unit 36 can be used to, when the application or software development kit runs on any version of the operating system among the different versions of the operating system and the service function module needs to call the system interface, the service function module obtains the digital signature result of the test package corresponding to any version of the operating system from the corresponding configuration file, and based on the digital signature result and the corresponding public key, verify whether the content of the test package corresponding to any version of the operating system is complete; if the content of the test package corresponding to any version of the operating system is complete, then perform the system interface call.

[0078] In some embodiments, the test unit 35 can also be used to complete the replacement operation, packaging operation and installation operation of the test packages corresponding to the different versions of the operating system based on the automated test framework script, so as to implement automated testing.

[0079] It should be noted that for other corresponding descriptions of each functional unit involved in the automated test device for mobile operating system upgrade provided in the embodiments of the present invention, reference can be made to Figure 1 the corresponding description in, which will not be elaborated here.

[0080] Based on the method as shown in Figure 1 above, correspondingly, the present embodiment also provides a storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the automated test method for mobile operating system upgrade as shown in Figure 1 above.

[0081] Based on such an understanding, the technical solution of the present application can be embodied in the form of a software product, and the software product can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), including several instructions for causing an electronic device (which can be a personal computer, a server, or a network device, etc.) to execute the methods in various implementation scenarios of the present application.

[0082] Based on the method as shown in Figure 1 above, and Figure 2 and Figure 3 the virtual device embodiment shown above, in order to achieve the above object, the embodiments of the present application also provide an electronic device, which can specifically be a personal computer, a tablet computer, a server, or other network devices, etc. The device includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to implement the automated test method for mobile operating system upgrade as shown in Figure 1 above.

[0083] Optionally, the above-mentioned physical device may further include a user interface, a network interface, a camera, a Radio Frequency (RF) circuit, sensors, an audio circuit, a WI-FI module, etc. The user interface may include a display and an input unit such as a keyboard, etc. Optionally, the user interface may further include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface, a wireless interface (such as a WI-FI interface), etc.

[0084] Those skilled in the art can understand that the above-mentioned structure of the physical device provided in this embodiment does not constitute a limitation on the physical device, and it may include more or fewer components, or combine certain components, or arrange different components.

[0085] The storage medium may further include an operating system and a network communication module. The operating system is a program for managing the hardware and software resources of the above-mentioned physical device, and supports the operation of information processing programs and other software and / or programs. The network communication module is used to implement communication between components inside the storage medium, and communication between other hardware and software in the information processing physical device.

[0086] Through the description of the above embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus a necessary general hardware platform, or by hardware.

[0087] In the embodiment of the present invention, by obtaining system interfaces whose behaviors change due to the upgrade of the mobile operating system in an application or a software development kit, generating library files, and based on the library files, respectively compiling test packages for simulating the behaviors of the system interfaces on different versions of the operating system, it is possible to test whether an application or a software development tool can run normally on different versions of the operating system on the same device. Since the test packages compiled in the embodiment of the present invention can simulate the behaviors of the system interfaces on different versions of the operating system, the embodiment of the present invention does not need to find devices installed with different versions of the operating system for upgrade testing. As long as the test packages corresponding to different versions of the operating system are sequentially installed on the same device, the behaviors of the system interfaces on different operating systems can be simulated, thereby completing the test, and thus the test cost can be reduced and repeated testing can be achieved. At the same time, in the embodiment of the present invention, by compiling test packages, various test scenarios can be designed, so that the test cases are more comprehensive. In addition, the embodiment of the present invention can also be combined with an automated test platform for automated testing to improve the test efficiency.

[0088] Those skilled in the art can understand that the attached drawings are only schematic diagrams of a preferred implementation scenario, and the modules or processes in the attached drawings are not necessarily essential for implementing the present application. Those skilled in the art can understand that the modules in the devices in the implementation scenario can be distributed in the devices of the implementation scenario according to the description of the implementation scenario, or can be correspondingly changed and located in one or more devices different from this implementation scenario. The modules in the above implementation scenario can be combined into one module, or can be further split into multiple sub-modules.

[0089] The above serial numbers of the present application are only for description and do not represent the advantages or disadvantages of the implementation scenarios. The above disclosure only shows several specific implementation scenarios of the present application. However, the present application is not limited thereto, and any changes that can be conceived by those skilled in the art should fall within the protection scope of the present application.

Claims

1. An automated testing method for mobile operating system upgrades, characterized in that Including: Obtain system interfaces in an application or software development kit whose behaviors change due to a mobile operating system upgrade; Generate a library file corresponding to the system interface; Perform digital signature on the generated library file to obtain a digitally signed library file; Based on the digitally signed library file, respectively compile test packages for simulating the behaviors of the system interface on different versions of the operating system, where the different versions of the operating system are generated by the upgrade of the mobile operating system; According to the test packages corresponding to the different versions of the operating system, test whether the application or the software development tool can run normally when the mobile operating system is upgraded on the same device.

2. The method according to claim 1, wherein The obtaining of the system interfaces in the application or software development kit whose behaviors change due to a mobile operating system upgrade includes: Perform system upgrade detection on the device where the application or the software development kit is located to obtain the system interfaces in the application or the software development kit whose behaviors change due to a mobile operating system upgrade.

3. The method according to claim 1, wherein The generating of the library file corresponding to the system interface includes: Write the system interface into a target module; Package the target module to obtain the library file corresponding to the system interface, and the library file includes at least one of the following: jar package,.a static library,.so dynamic library, and.framework dynamic library.

4. The method according to claim 1, wherein The compiling of the test packages for simulating the behaviors of the system interface on different versions of the operating system based on the digitally signed library file includes: Based on the behaviors of the system interface on different versions of the operating system, respectively compile the system interfaces in the digitally signed library file to obtain test packages for simulating the behaviors of the system interface on different versions of the operating system.

5. The method according to claim 1, wherein The testing of whether the application or the software development tool can run normally when the mobile operating system is upgraded on the same device according to the test packages corresponding to the different versions of the operating system includes: Integrate the test packages corresponding to the different versions of the operating system into the application or software development kit in sequence, and install and run them on the same device to obtain the return results of the application or software development kit running on the different versions of the operating system; If the return results of the application or software development kit running on the different versions of the operating system are consistent, it is determined that the application or the software development tool can run normally when the mobile operating system is upgraded.

6. The method according to claim 1, wherein The method further includes: Respectively perform digital signature on the test packages corresponding to the different versions of the operating system to obtain the digital signature results and public keys of the test packages corresponding to the different versions of the operating system, where the digital signature results are in the corresponding configuration files, and the public keys are built into the business function modules in the application or software development kit that need to call the system interface. When the application or software development kit runs on any version of the operating system among the different versions of the operating system, and the business function module needs to call the system interface, the business function module obtains the digital signature result of the test package corresponding to any version of the operating system from the corresponding configuration file, and based on the digital signature result and the corresponding public key, verifies whether the content of the test package corresponding to any version of the operating system is complete; If the content of the test package corresponding to any version of the operating system is complete, the system interface call is performed.

7. The method according to any one of claims 1-6, characterized in that The method further includes: Based on the automated test framework script, complete the replacement operation, packaging operation and installation operation of the test packages corresponding to the different versions of the operating system to implement automated testing.

8. An automated test device for mobile operating system upgrades, characterized in that Including: An acquisition unit for acquiring the system interfaces in the application or software development kit whose behaviors change due to the upgrade of the mobile operating system; A generation unit for generating a library file corresponding to the system interface; A signature unit for digitally signing the generated library file to obtain a digitally signed library file; A compilation unit for respectively compiling test packages for simulating the behaviors of the system interface on different versions of the operating system based on the digitally signed library file, wherein the different versions of the operating system are generated by the upgrade of the mobile operating system; A test unit for testing whether the application or the software development tool can run normally when the mobile operating system is upgraded on the same device according to the test packages corresponding to the different versions of the operating system.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

10. An electronic device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

Images