Upgrading test method, electronic equipment and readable storage medium

Abstract

The invention discloses an upgrade test method, electronic equipment and a readable storage medium, and belongs to the technical field of computers. The method comprises the steps that a historical version, a target version and an auxiliary version are obtained, the version timestamp of the target version is larger than the version timestamp of the historical version and smaller than the version timestamp of the auxiliary version, the security patch timestamp of the historical version is larger than the security patch timestamp of the auxiliary version, and the security patch timestamp of the target version is smaller than the security patch timestamp of the auxiliary version; the time stamp is smaller than the security patch time stamp of the target version, and the software development kit corresponding to the auxiliary version does not comprise a version time stamp verification program; and for the target version, performing an automatic loop upgrade test based on the historical version and the auxiliary version.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an upgrade testing method, electronic device, and readable storage medium. Background Technology

[0002] Currently, before an Android version package is released, it needs to undergo cyclical upgrade testing, which includes the process of upgrading from a lower version to a higher version and vice versa. However, Android's mechanism does not support version rollback, specifically down from a higher version to a lower version. Therefore, automated cyclical upgrade testing cannot be achieved. Summary of the Invention

[0003] This application provides an upgrade testing method, an electronic device, and a readable storage medium, which can solve the problem of how to achieve automated version cycle upgrade testing.

[0004] To solve the above-mentioned technical problems, this application is implemented as follows: Firstly, an upgrade testing method is provided, the method comprising: obtaining a historical version, a target version, and an auxiliary version, wherein the version timestamp of the target version is greater than the version timestamp of the historical version and less than the version timestamp of the auxiliary version, the security patch timestamp of the historical version is greater than the security patch timestamp of the auxiliary version and less than the security patch timestamp of the target version, and the software development kit corresponding to the auxiliary version does not include a version timestamp verification program; and performing automated cyclic upgrade testing based on the historical version and the auxiliary version for the target version.

[0005] In a second aspect, an electronic device is provided, including a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the method as described in the first aspect.

[0006] Thirdly, a readable storage medium is provided, wherein at least one computer program is stored therein, which, when loaded and executed by a processor, implements the method described in the first aspect.

[0007] Fourthly, a computer program product is provided, the computer program product comprising at least one computer program that, when loaded and executed by a processor, implements the method described in the first aspect.

[0008] In this embodiment, by obtaining historical versions, target versions, and auxiliary versions, wherein the version timestamp of the target version is greater than the version timestamp of the historical version but less than the version timestamp of the auxiliary version, the security patch timestamp of the historical version is greater than the security patch timestamp of the auxiliary version but less than the security patch timestamp of the target version, and the software development kit corresponding to the auxiliary version does not include a version timestamp verification program, and then performing automated cyclic upgrade tests on the target version based on the historical version and auxiliary version, the problem of how to achieve high and low version cyclic upgrades during automated testing is solved, and no additional flashing tools are required, resulting in greater flexibility. This further realizes automated stress testing of Over-The-Air (OTA) version packages.

[0009] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0010] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0011] Figure 1 A schematic diagram of an upgrade testing method provided by an exemplary embodiment of this application is shown; Figure 2 This illustration shows a schematic diagram of a version upgrade sequence provided by an exemplary embodiment of this application; Figure 3 This illustration shows a schematic diagram of a version upgrade sequence provided by an exemplary embodiment of this application; Figure 4 This illustration shows a schematic diagram of a version upgrade sequence provided by an exemplary embodiment of this application; Figure 5 This illustration shows another schematic diagram of an upgrade testing method provided in an exemplary embodiment of this application; Figure 6 A schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application is shown. Detailed Implementation

[0012] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0013] Figure 1FIG. 0 shows a schematic flowchart of an upgrade test method provided by an exemplary embodiment of the present application. This method can be executed by an electronic device, which may include: a terminal device. In other words, this method can be executed by software or hardware installed in the electronic device. This method may include the following steps: S110: Obtain a historical version, a target version, and an auxiliary version.

[0014] Among them, the version timestamp of the target version is greater than the version timestamp of the historical version and less than the version timestamp of the auxiliary version. The security patch timestamp of the historical version is greater than the security patch timestamp of the auxiliary version and less than the security patch timestamp of the target version. The software development kit corresponding to the auxiliary version does not include a version timestamp verification program.

[0015] It can be understood that during the version upgrade process of Android, the software development kit (SDK) program of the current version will verify the version timestamp of the version to be upgraded. If the version timestamp in the version to be upgraded is higher than the version timestamp of the current version, the upgrade is allowed; otherwise, the upgrade is rejected. Therefore, in the embodiment of the present application, an auxiliary version is introduced. Suppose the historical version is O1, the corresponding version timestamp is T1, the target version is O2, the corresponding version timestamp is T2, and the auxiliary version is O3, the corresponding version timestamp is T3. Then T1 < T2 < T3. That is to say, the version timestamp of the auxiliary version O3 is the latest. In this way, when upgrading from O2 to O3, the SDK program of the target version will pass the verification, and thus upgrade to O3; when rolling back from O3 to O1, since the SDK corresponding to O3 does not include a version timestamp verification program, when rolling back from O3 to O1, the SDK corresponding to O3 will not verify the version timestamp of O1, and thus roll back to O1.

[0016] In addition, during each version update, the Android mechanism also requires verifying the security patch timestamp of the version to determine whether the patch is the latest. For example, if the release time of a certain patch is earlier than the patches already existing in the current version, then the patch may be outdated and will be rejected for installation. Based on this, for the historical version, target version, and auxiliary version provided in the embodiments of this application, the relationship of their security patch timestamps is that the security patch timestamp of the historical version is greater than the security patch timestamp of the auxiliary version and less than the security patch timestamp of the target version. Assume that the security patch timestamp of the historical version O1 is S1, the security patch timestamp of the target version O2 is S2, and the security patch timestamp of the auxiliary version O3 is S3. Then S3 < S1 < S2. That is to say, the security patch timestamp of the auxiliary version O3 is the oldest. When upgrading from O2 to O3, the version timestamp verification in the SDK corresponding to O2 can pass the verification smoothly. However, since the security patch timestamp of O3 is the oldest, after upgrading from O2 to the O3 version, the security patch version actually downgrades. Based on the Android mechanism, after version upgrade, if the security patch version downgrades, then perform a factory reset to complete the upgrade from O2 to O3.

[0017] Optionally, the target version can be a version to be released or a target historical version, where the version timestamp of the target historical version is higher than that of the historical version. Regarding the target historical version, it can be understood that, for example, when it is found that there are serious problems in the current version, it may be necessary to roll back to a stable historical version. In this case, re-performing stress testing can ensure that the target historical version can still withstand the load in the production environment; or, in order to evaluate the performance changes of the current version relative to the target historical version, then stress testing of the target historical version is also required, so that the results can be compared with the current version to determine whether there are performance changes.

[0018] S120: For the target version, perform an automated cyclic upgrade test based on the historical version and the auxiliary version.

[0019] After obtaining the historical version, target version, and auxiliary version, an automated cyclic upgrade test can be performed on the target version based on the historical version and the auxiliary version.

[0020] In this embodiment, by obtaining historical versions, target versions, and auxiliary versions, wherein the version timestamp of the target version is greater than the version timestamp of the historical version but less than the version timestamp of the auxiliary version, the security patch timestamp of the historical version is greater than the security patch timestamp of the auxiliary version but less than the security patch timestamp of the target version, and the software development kit corresponding to the auxiliary version does not include a version timestamp verification program, and then performing automated cyclic upgrade tests on the target version based on the historical version and auxiliary version, the problem of how to achieve high and low version cyclic upgrades during automated testing is solved, and no additional flashing tools are required, resulting in greater flexibility and further realizing automated stress testing of OTA version packages.

[0021] In one implementation, before performing automated cyclic upgrade testing based on the historical version and the auxiliary version for the target version, the method further includes: determining the current version of the test terminal by configuring the test terminal.

[0022] Configuring the test terminal version refers to installing an initial version on the test terminal as the current version. In other words, this current version can be any of the following: a historical version, a target version, or a supplementary version.

[0023] After determining the current version of the test terminal, an automated cyclical upgrade test is performed on the target version based on the historical version and the auxiliary version. This can include the following three methods: (1) In one implementation, the automated cyclic upgrade test based on the historical version and the auxiliary version for the target version may include the following steps: Step 1: In response to the determination that the current version is the historical version, upgrade the test terminal to the target version.

[0024] Since both the historical version O1 and the target version O2 are unmodified versions (i.e., O1's version timestamp is less than O2's, and O1's security patch timestamp is less than O2's), upgrading from O1 to O2 is a normal upgrade.

[0025] Step 2: In response to the determination that the test operation corresponding to the target version has been completed, upgrade the test terminal to the auxiliary version.

[0026] Understandably, after upgrading to the target version O2, testing is performed on version O2. Once this testing is complete, a rollback is needed, i.e., reverting to the historical version O1 to continue testing. In this embodiment, an auxiliary version O3 enables automatic rollback from O2 to O1. Rollback from O2 to O1 first requires upgrading O2 to O3. The version timestamp of O3 is specially processed and is the most up-to-date. Therefore, during the upgrade from O2 to O3, the version timestamp verification in the O2 SDK will pass successfully. However, since the security patch timestamp in version O3 is the oldest, the security patch version is effectively downgraded after upgrading from O2 to O3.

[0027] Therefore, in another implementation, upgrading the test terminal to the auxiliary version includes: installing the auxiliary version; performing a factory reset operation on the test terminal in response to a successful installation detection result for the auxiliary version; and determining that the test terminal has been upgraded to the auxiliary version in response to the completion of the factory reset operation.

[0028] In other words, if a security patch version is downgraded after an upgrade, a factory reset must be performed. This factory reset includes: after the upgrade process is complete and before the test terminal restarts, writing the keyword "wipe_data" to the Misc partition. This keyword is used to automatically boot uboot into the Recovery system to perform a factory reset when the test terminal restarts. Once the factory reset is complete, the current version has been upgraded to O3.

[0029] Step 3: In response to the successful upgrade detection result of the auxiliary version, the test terminal is rolled back to the historical version.

[0030] Understandably, after successfully upgrading from O2 to O3, no testing is needed for O3. The auxiliary version O3 is only used to roll back from a higher version to a lower version. During the rollback from O3 to O1, since the current O3 version timestamp is the latest, the rollback from O3 to O1 would be a downgrade, which, according to Android mechanisms, cannot be successfully implemented. However, because the O3 SDK has undergone special processing (i.e., it does not include a version timestamp verification program), it can be upgraded normally from O3 to O1. Furthermore, the security patch timestamp in O3 is the oldest, so the security patch version upgrade from O3 to O1 is considered an upgrade and will automatically succeed.

[0031] Step 4: In response to the judgment that the test operation corresponding to the historical version has been completed, return to upgrade the test terminal to the target version until the preset stop condition is met.

[0032] In (1) above, such as Figure 2 As shown, if the current version is auxiliary version O1, the next version will be upgraded to O2, then from O2 to O3, and then back to O1 from O3. At this point, the test terminal has gone through a complete version cycle upgrade, from O1->O2->O3->O1. The next step is to repeat this alternating process until the preset stopping condition is met, thus realizing an infinite loop stress test of three versions.

[0033] (2) In one implementation, the automated cyclic upgrade test based on the historical version and the auxiliary version for the target version includes: in response to the determination that the current version is the target version, upgrading the test terminal to the auxiliary version; in response to the determination that the upgrade detection result corresponding to the auxiliary version is successful, reverting the test terminal to the historical version; in response to the determination that the test operation corresponding to the historical version has been completed, upgrading the test terminal to the target version; in response to the determination that the test operation corresponding to the target version has been completed, returning to the step of upgrading the test terminal to the auxiliary version, until a preset stop condition is met.

[0034] For a detailed description of the implementation method, please refer to the content in (1) above, which will not be repeated here.

[0035] In (2) above, such as Figure 3 As shown, if the current version is auxiliary version O2, the next version will be upgraded to O3, then rolled back from O3 to O1, and then upgraded from O1 to O2. At this point, the test terminal has gone through a complete version cycle upgrade, from O2->O3->O1->O2. The next step is to repeat this alternating process until the preset stopping condition is met, thus realizing an infinite loop stress test of three versions.

[0036] (3) In one implementation, the automated cyclic upgrade test based on the historical version and the auxiliary version for the target version includes: in response to the determination that the current version is the auxiliary version, reverting the test terminal to the historical version; in response to the determination that the test operation corresponding to the historical version has been completed, upgrading the test terminal to the target version; in response to the determination that the test operation corresponding to the target version has been completed, upgrading the test terminal to the auxiliary version; in response to the determination that the upgrade detection result corresponding to the auxiliary version is successful, returning to the step of reverting the test terminal to the historical version, until a preset stop condition is met.

[0037] For a detailed description of the implementation method, please refer to the content in (1) above, which will not be repeated here.

[0038] In (3) above, such as Figure 4 As shown, if the current version is auxiliary version O3, the next version will revert to O1, then upgrade from O1 to O2, and then upgrade from O2 to O3. At this point, the test terminal has gone through a complete version cycle upgrade, from O3->O1->O2->O3. The next step is to repeat this alternating process until the preset stopping condition is met, thus realizing an infinite loop stress test of three versions.

[0039] In this embodiment of the application, regardless of whether the current version of the test terminal is a historical version, a target version, or an auxiliary version, an infinite loop stress test of these three versions can be achieved.

[0040] In one implementation, the method further includes: obtaining the version package of the version to be installed via an over-the-air (OTA) download channel during each version update. It is understood that before upgrading the test terminal to the target version, the method further includes: obtaining the version package of the target version via an OTA download channel; before upgrading the test terminal to the auxiliary version, the method further includes: obtaining the version package of the auxiliary version via an OTA download channel; and before reverting the test terminal to the historical version, the method further includes: obtaining the version package of the historical version via an OTA download channel.

[0041] In other words, the version packages corresponding to historical versions, target versions, and auxiliary versions are OTA version packages. An OTA version package is a software update package implemented through Over-The-Air (OTA) technology. During the cyclic upgrade test, OTA technology allows new software update packages to be downloaded from a remote server via a wireless network, thereby enabling remote upgrades to the software or firmware of the test terminal.

[0042] The following is a flowchart illustrating another upgrade testing method based on the above embodiments, as shown below. Figure 5 As shown, the following steps may be included: S510: Retrieves historical versions, target versions, auxiliary versions, and upgrade strategy files.

[0043] Among them, auxiliary version O3 meets the following conditions: 1) The O3 version was compiled at the latest time; 2) O3's security patch is the oldest; 3) The O3 version will not perform timestamp rollback interception and verification during the upgrade process.

[0044] The upgrade strategy document specifies the upgrade order for each version: historical version O1 -> target version O2 -> auxiliary version O3 -> historical version O1.

[0045] S520: If the current version of the test terminal is a historical version, start the test, parse the upgrade policy file, obtain the address of the target version from the policy file, and upgrade the test terminal to the target version.

[0046] Since versions O1 and O2 are normal commercial versions, and version O2 has a newer build timestamp than O1, it is possible to successfully upgrade from O1 to O2.

[0047] S530: Parses the upgrade policy file, obtains the address of the auxiliary version from the policy file, and upgrades the test terminal from the target version to the auxiliary version.

[0048] Because the O3 version timestamp is specially processed and is the most up-to-date, the version timestamp verification in the O2 SDK will pass successfully during the upgrade from O2 to O3. However, since the security patch timestamp in the O3 version is the oldest, the security patch version is actually downgraded after upgrading from O2 to O3. According to Android's mechanism, if a security patch version downgrade occurs after a version upgrade, a factory reset is required. Therefore, during the upgrade from O2 to O3, before rebooting, the test terminal needs to automatically write the keyword "wipe_data" to the Misc partition. This keyword will guide uboot to automatically enter the Recovery system and perform a factory reset during reboot. After the factory reset is completed, the version has been upgraded to O3.

[0049] S540: Parses the upgrade strategy file, obtains the address of the historical version from the strategy file, and reverts the test terminal from the current auxiliary version to the historical version.

[0050] In this case, since O3 has the latest version timestamp, upgrading from O3 to O1 would be considered a version timestamp downgrade, which, according to Android's mechanism, should not be possible. However, because the O3 SDK has undergone special processing—specifically, disabling version timestamp verification—it can be upgraded normally from O3 to O1. Meanwhile, the current security patch timestamp for O3 is the oldest; therefore, upgrading from O3 to O1 is considered an upgrade in security patch version and requires no special handling.

[0051] S550: Determine whether the stopping condition is met.

[0052] At this point, the test terminal has completed a full version cycle upgrade, from O1->O2->O3->O1. Then it checks whether the stopping condition is met. If not, it returns to S520. This alternating process is repeated, thus achieving an infinite loop stress test with three versions.

[0053] like Figure 6 As shown, this application embodiment also provides an electronic device 600, including a processor 610 and a memory 620. The memory 620 stores a program or instructions that can run on the processor 610. When the program or instructions are executed by the processor 610, they implement the various processes of the above-described upgrade test method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0054] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described upgrade test method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0055] The processor mentioned above is the processor in the terminal described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk. In some examples, the readable storage medium may be a non-transient readable storage medium.

[0056] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the embodiments shown in the above-described upgrade test method, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0057] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0058] This application also provides a computer program / program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the embodiments shown in the above-described upgrade test method, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0059] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0060] From the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of computer software products plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware. The computer software product is stored in a storage medium (such as ROM, RAM, magnetic disk, optical disk, etc.) and includes several instructions to cause the terminal or network-side device to execute the methods described in the various embodiments of this application.

[0061] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other implementations under the guidance of this application without departing from the spirit and scope of the claims. All of these implementations are within the protection scope of this application.

Claims

1. An upgrade testing method, characterized in that, include: Obtain historical versions, target versions, and auxiliary versions, wherein the version timestamp of the target version is greater than the version timestamp of the historical version and less than the version timestamp of the auxiliary version, the security patch timestamp of the historical version is greater than the security patch timestamp of the auxiliary version and less than the security patch timestamp of the target version, and the software development kit corresponding to the auxiliary version does not include a version timestamp verification program. For the target version, automated cyclical upgrade tests are performed based on the historical version and the auxiliary version.

2. The method of claim 1, wherein, Before performing automated cyclical upgrade tests on the target version based on the historical version and the auxiliary version, the method further includes: The current version of the test terminal is determined by configuring the version of the test terminal.

3. The method of claim 2, wherein, The automated cyclic upgrade test for the target version, based on the historical version and the auxiliary version, includes: In response to the determination that the current version is a historical version, the test terminal is upgraded to the target version; In response to the determination that the test operation corresponding to the target version has been completed, the test terminal is upgraded to the auxiliary version; In response to the successful upgrade detection result of the auxiliary version, the test terminal is reverted to the historical version. In response to the determination that the test operation corresponding to the historical version has been completed, the process returns to upgrade the test terminal to the target version until the preset stop condition is met.

4. The method of claim 2, wherein, The automated cyclic upgrade test for the target version, based on the historical version and the auxiliary version, includes: In response to the determination that the current version is the target version, the test terminal is upgraded to the auxiliary version; In response to the successful upgrade detection result of the auxiliary version, the test terminal is reverted to the historical version. In response to the determination that the test operation corresponding to the historical version has been completed, the test terminal is upgraded to the target version; In response to the determination that the test operation corresponding to the target version has been completed, the process returns to upgrading the test terminal to the auxiliary version until the preset stop condition is met.

5. The method of claim 2, wherein, The automated cyclic upgrade test for the target version, based on the historical version and the auxiliary version, includes: In response to the determination that the current version is the auxiliary version, the test terminal is reverted to the historical version; In response to the determination that the test operation corresponding to the historical version has been completed, the test terminal is upgraded to the target version; In response to the determination that the test operation corresponding to the target version has been completed, the test terminal is upgraded to the auxiliary version; In response to the successful upgrade detection result of the auxiliary version, the process returns to reverting the test terminal to the historical version until the preset stop condition is met.

6. The method according to any one of claims 3-5, characterized in that, Upgrading the test terminal to the auxiliary version includes: Install the aforementioned auxiliary version; In response to the successful installation test result of the auxiliary version, a factory reset operation is performed on the test terminal. Upon completion of the factory reset operation, the test terminal is determined to be upgraded to the auxiliary version.

7. The method according to any one of claims 3-5, characterized in that, The method further includes: During each version update, the version package to be installed is obtained through an over-the-air download technology channel.

8. An electronic device, comprising: It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the upgrade test method as described in any one of claims 1-7.

9. A readable storage medium, characterized by, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the upgrade test method as described in any one of claims 1-7.

10. A computer program product, characterised in that, The computer program product includes program instructions that, when executed by a computer, cause the computer to perform the steps of the upgrade testing method as described in any one of claims 1-7.

Images