Test report generation method and device, electronic equipment and readable storage medium

Abstract

The embodiment of the invention provides a test report generation method and device, electronic equipment and a readable storage medium, and the method is applied to a test platform, and comprises the steps: obtaining first information which is generated for a tested software package and comprises a software package identifier and a software package check code corresponding to the software package identifier from a release platform, then obtaining a first test result of the tested software package; and finally, based on the first test result and the first information, a test report is generated, and the test report comprises the first test result of the tested software package and the software package check code corresponding to the tested software package. As the software package check code in the test report is directly obtained from the release platform, the software package check code for the tested software package in the test report can be ensured to be consistent with the software package check code calculated by the release platform for the same tested software package; and the situation that the MD5 value of the software package recorded in the test report is not the MD5 value of the actual delivery version of the software package is avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a test report generation method and device, electronic equipment and readable storage medium. BACKGROUND

[0002] In the production process of a software package, the test platform is a key link for testing the software package. By using the test platform to perform testing on the software package, the quality of the software package can be effectively verified, thereby reducing the final online risk of the software package.

[0003] After the testing on the software package is completed by the test platform, a test report for the software package needs to be generated. The information to be filled in the test report includes the MD5 (Message-Digest Algorithm 5) value of the software package to be tested and the test result obtained after performing the testing on the software package.

[0004] However, since the test platform is generally not allowed to obtain the online code permission and the packaging operation permission for the code process in actual scenarios, the test platform does not have the ability to calculate the MD5 value of the software package. Therefore, the test personnel usually need to manually find the production record related to the software package to find the MD5 value of the software package, and then fill the found MD5 value into the test report. In actual applications, it is easy to make mistakes when filling the MD5 value into the test report by the manual way, for example, the test personnel may input the MD5 of one software package into the test report for other software packages, or may input the MD5 value of the wrong version of the software package into the test report due to not paying attention to the version iteration of the software package in time.

[0005] When the MD5 value filled in the test report is wrong, the MD5 value of the software package recorded in the test report may not be the MD5 value of the actual delivery version of the software package. SUMMARY

[0006] The purpose of the embodiments of the present application is to provide a test report generation method and device, electronic equipment and readable storage medium, so as to avoid the situation that the MD5 value of the software package recorded in the test report is not the MD5 value of the actual delivery version of the software package.

[0007] In the first aspect of the embodiments of the present application, a test report generation method is first provided, which is applied to a test platform, the test platform is in communication connection with a release platform, and the method comprises the following steps:

[0008] Obtain the first information generated by the release platform for the tested software package. The first information includes: software package identifier and software package verification code corresponding to the software package identifier; the software package verification code is calculated by the release platform for the tested software package of the test platform; the software package verification code is used to verify whether the tested software package has been modified.

[0009] Get the first test results of the tested software package;

[0010] Based on the first test results and the first information, a test report is generated. The test report includes the first test results of the tested software package and the software package checksum corresponding to the tested software package.

[0011] In a second aspect of this application, a test report generation apparatus is also provided, applied to a test platform, the test platform being communicatively connected to a publishing platform, the apparatus comprising:

[0012] The first acquisition module is used to acquire first information generated by the release platform for the tested software package. The first information includes: software package identifier and software package verification code corresponding to the software package identifier; the software package verification code is calculated by the release platform for the tested software package of the test platform; the software package verification code is used to verify whether the tested software package has been modified.

[0013] The second acquisition module is used to acquire the first test results of the tested software package;

[0014] The generation module is used to generate a test report based on the first test result and the first information. The test report includes the first test result of the tested software package and the software package check code corresponding to the tested software package.

[0015] In a third aspect of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0016] Memory, used to store computer programs;

[0017] When a processor executes a program stored in memory, it implements the steps of any of the above-described test report generation methods.

[0018] In another aspect of this application, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of any of the test report generation methods described above.

[0019] In another aspect of this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform the steps of any of the test report generation methods described above.

[0020] The test report generation method, apparatus, electronic device, and readable storage medium provided in this application embodiment can directly obtain first information generated for the tested software package, including a software package identifier and a software package verification code corresponding to the software package identifier, after the publishing platform calculates the software package verification code for the tested software package on the testing platform to verify whether the tested software package has been modified. Then, it can obtain the first test result of the tested software package. Finally, based on the first test result and the first information, it generates a test report, which includes the first test result of the tested software package and the software package verification code corresponding to the tested software package.

[0021] In this way, since the package checksum in the test report is obtained directly from the release platform, it can be guaranteed that the package checksum in the test report for the tested package is consistent with the package checksum calculated by the release platform for the same tested package. This avoids situations where the MD5 value of the package recorded in the test report is inconsistent with the MD5 value generated by the release platform, or the MD5 value of the package recorded in the test report is not the MD5 value of the actual delivered version of the package. This reduces the risk of audit failure caused by such discrepancies and helps ensure the normal release of the application. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0023] Figure 1 A schematic diagram of an application production system provided in the embodiments of this application;

[0024] Figure 2 A flowchart illustrating a first embodiment of the test report generation method provided in this application;

[0025] Figure 3 A flowchart illustrating a second implementation of the test report generation method provided in this application;

[0026] Figure 4 A flowchart illustrating a third implementation of the test report generation method provided in this application;

[0027] Figure 5 In order to be in Figure 1 The diagram shows the interaction on the application production system.

[0028] Figure 6 This is a schematic diagram illustrating the operation flow of the test report generation method provided in this application embodiment on the test platform;

[0029] Figure 7 This is a schematic diagram of the test report generation device provided in the embodiments of this application;

[0030] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0031] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0032] In existing technologies, the first step in application production is the development of the application's source code. After the source code development is completed, the software package typically undergoes preliminary testing to verify whether there are any defects in its runtime logic. Once the application software package passes testing, it is then packaged and submitted to the distribution platform, which then performs the application's release.

[0033] Furthermore, the testing platform is required to issue a test report after completing the testing of the software package, and this report is also required for review by the auditing department. However, since the MD5 values ​​are currently manually entered into the test report, it is easy for the MD5 value recorded in the test report to differ from the MD5 value of the actual delivered version of the software package. This situation can prevent application vendors from proving the quality and security of their software packages during audits, posing audit risks and affecting the normal release of the software packages.

[0034] In view of this, the test report generation method, apparatus, electronic device and readable storage medium provided in the embodiments of this application are designed to avoid the situation where the MD5 value recorded in the test report is not the MD5 value of the actual delivered version of the software package.

[0035] Below, we will first introduce a test report generation method according to an embodiment of this application. This test report generation method can be applied to, for example... Figure 1 The system shown includes a test platform that communicates with the release platform. See also... Figure 2 The method for generating this test report specifically includes the following steps:

[0036] S110: Obtain the first information generated by the release platform for the tested software package. The first information includes: software package identifier and software package verification code corresponding to the software package identifier; the software package verification code is calculated by the release platform for the tested software package of the test platform; the software package verification code is used to verify whether the tested software package has been modified.

[0037] S120: Obtain the first test result of the tested software package.

[0038] S130: Based on the first test result and the first information, generate a test report. The test report includes the first test result of the tested software package and the software package checksum corresponding to the tested software package.

[0039] In some examples, a communication link or API can be established between the test platform and the release platform to enable communication between them. For instance, the test platform may define an HTTP (Hypertext Transfer Protocol) interface, which the release platform uses to communicate with it. Using an HTTP interface to facilitate communication between the test and release platforms reduces their coupling, making independent upgrades easier.

[0040] In some other examples, after the testing platform successfully tests the software package, it can package the tested package as a tested package and submit it to the distribution platform. The distribution platform can then obtain the identifier of the tested package and generate a package checksum corresponding to that identifier. This checksum can be used to verify whether the tested package has been modified. The checksum can be an MD5 value, a SHA1 (Secure Hash Algorithm 1) value, or a CRC32 (Cyclic Redundancy Check 32-bit) value.

[0041] In some examples, the MD5 value of the tested software package can be calculated using the MD5 algorithm, the SHA1 value can be calculated using the SHA1 algorithm, and the CRC32 value can be calculated using the CRC32 algorithm.

[0042] The specific form of the identifier for the tested software package can be selected according to actual needs, as long as it can uniquely identify a software package. For example, the name or ID of the tested software package can be used as the identifier for the tested software package.

[0043] In some other examples, when the contents of a package are modified, the package's attributes may also change. For example, the modification time or size of the package may change. Therefore, it is also possible to calculate the package checksum based on the package's attributes.

[0044] In some implementations, the testing platform may instruct the publishing platform to generate a package verification code corresponding to the package identifier after submitting the package to the publishing platform. Alternatively, the publishing platform may proactively generate a package verification code corresponding to the package identifier after receiving the packaged package from the testing platform.

[0045] In some other examples, after generating the package verification code corresponding to the package identifier, the publishing platform can proactively send the package identifier and the corresponding package verification code as the first piece of information to the aforementioned testing platform, or the testing platform can obtain them from the publishing platform, which is also possible.

[0046] After obtaining the first information generated by the release platform for the tested software package, the aforementioned testing platform can also obtain the first test result of the tested software package; wherein, the first test result is generated by the testing platform when testing the tested software package.

[0047] Finally, based on the first test results and the first information, a test report is generated. The test report includes the first test results of the tested software packages and the software package checksum corresponding to the tested software packages.

[0048] The test report generation method provided in this application provides that, since the package checksum in the test report is obtained directly from the release platform, it can ensure that the package checksum in the test report for the tested package is consistent with the package checksum calculated by the release platform for the same tested package. This avoids situations where the MD5 value of the package recorded in the test report is inconsistent with the MD5 value generated by the release platform, or where the MD5 value of the package recorded in the test report is not the MD5 value of the actual delivered version of the package. This reduces the risk of audit failure caused by such discrepancies and helps ensure the normal release of the application.

[0049] In some examples, the test platform has at least one tested project, and each tested project contains multiple tested software packages; in this regard, Figure 2 Based on the test report generation method shown, this application embodiment also provides a possible implementation method, such as... Figure 3 The diagram shown is a flowchart of a second embodiment of a test report generation method according to an example of this application. The method may include:

[0050] S210: For each tested project, obtain the first information generated by the release platform for the multiple tested software packages contained in that tested project. The first information includes: a software package identifier and a software package verification code corresponding to the software package identifier; the software package verification code is calculated by the release platform for the tested software packages of the testing platform; the software package verification code is used to verify whether the tested software packages have been modified.

[0051] S220: Obtain the first test result of the tested software package.

[0052] S230: Based on the first test results of multiple tested software packages included in the tested project and the first information corresponding to the multiple tested software packages, generate a test report corresponding to the tested project. The test report contains report entries for multiple tested software packages included in the tested project. Each report entry for a tested software package contains the first test result of one tested software package and the software package checksum corresponding to that tested software package.

[0053] In some examples, in real-world application scenarios, the testing platform can submit a large number of software packages to the release platform in batches. Therefore, in such scenarios, the release platform will also synchronize the initial information corresponding to these numerous software packages to the testing platform. For example, the initial information synchronized from the release platform to the testing platform might include: "Software Package 1: MD5 value 1", "Software Package 2: MD5 value 2", etc. Here, "Software Package 1: MD5 value 1" means that the MD5 value calculated for software package 1 is MD5 value 1.

[0054] In some examples, a project may contain multiple software packages. The testing platform can treat the project as a whole and test all the packages within it simultaneously to check for issues. Once the project passes the tests, it is designated as a tested project, and all its packages are listed as tested packages. This is then submitted to the release platform.

[0055] The release platform can generate corresponding package verification codes for all tested packages in the tested project, and then use the package identifier and the corresponding package verification code for each tested package as the first information of that tested package. Therefore, the release platform can obtain multiple pieces of first information corresponding to all tested packages in the tested project and synchronize these multiple pieces of first information to the testing platform.

[0056] In some implementations, the testing platform typically submits the tested project to the release platform only after the project has passed testing. Therefore, the testing platform has already obtained the test results for the project. Thus, after obtaining the first information generated by the release platform for the multiple tested software packages contained in the tested project, the platform can directly obtain the first test results of the multiple tested software packages contained in the tested project from the local machine.

[0057] In some other examples, after completing the testing of the software packages, the testing platform needs to issue a test report. This report must include the package checksum of the application being tested, as well as the test results obtained for that application. In practical applications, the testing platform issues a test report per project. A project may contain one or more applications. In this case, a single test report may contain report entries for the one or more tested software packages. Each report entry for a tested software package includes the first test result for that package and the corresponding package checksum.

[0058] In one example, a test report might take the form of: "Tested package 1, MD5 value 1, test result 1", "Tested package 2, MD5 value 2, test result 2", and so on. Here, "Tested package 1, MD5 value 1, test result 1" is the report entry corresponding to tested package 1.

[0059] In some examples, the testing platform may have a first database. After obtaining the first information generated by the release platform for multiple tested software packages included in the tested project, the testing platform stores the first information corresponding to each tested software package in the first database. Then, when a test report is needed for the tested project, the platform retrieves the first test results and the corresponding first information for each tested software package from the first database, thereby generating the corresponding test report.

[0060] In some examples, after generating a test report for a tested project, the testing platform can save it for staff to review in subsequent work or for auditing purposes.

[0061] It's understandable that after receiving the initial information synchronized from the release platform, the testing platform might not immediately use it to generate a test report. Therefore, storing the received initial information in a database makes it easier for the testing platform to retrieve this information when it needs to generate a test report later, and also prevents the loss of received initial information due to insufficient cache space.

[0062] In some examples, in real-world application scenarios, developers may continuously adjust and repackage the source code of the same application as needed. This means that the source code of an application may undergo multiple iterations and updates. Therefore, the MD5 checksum calculated by the distribution platform for the latest version of the same application is usually different from the MD5 checksum calculated for the previous version. For example, for application 1, the MD5 value calculated by the distribution platform for the first packaged package is "MD5 value 1-A"; however, after the developers readjust the source code of application 1, the MD5 value calculated by the distribution platform for the adjusted source code package is "MD5 value 1-B".

[0063] Thus, if the package checksum of the previous version of the software package is stored in the first database, and then the package checksum of the software package with the modified source code is received, storing both versions of the software package checksum in the first database will result in the package checksum being non-unique.

[0064] To address this situation, in this embodiment of the application, the testing platform can use the first information of the latest version of the software package to update the first information of the previous version of the software package already stored in the first database. This ensures that the first database records only one software package checksum for each software package, and that it is the software package checksum of the latest version of the application's software package. Consequently, the software package checksum filled in for that application in the final test report issued by the testing platform is the MD5 value of the latest version of the application's software package.

[0065] In some examples, after the aforementioned distribution platform obtains the latest version of the software package, it can generate a software package verification code for the latest version of the software package and send the software package verification code and the software package identifier of the latest version of the software package as updated first information to the testing platform. When the testing platform obtains the updated first information for any tested software package, it uses the updated first information to replace the first information of the tested software package already stored in the first database.

[0066] For example, when the test platform receives the updated first information synchronized from the release platform as "package 1: MD5 value 1-B", if the first database already stores the first information of package 1 as "package 1: MD5 value 1-A", the test platform will update the first information "package 1: MD5 value 1-A" already stored in the first database to "package 1: MD5 value 1-B", and the first database will no longer record the first information "package 1: MD5 value 1-A".

[0067] In some examples, after the development of a project is completed, the application software packages included in the project are usually tested first. After the tests are passed, the release platform is instructed to calculate the package checksum of the software packages.

[0068] However, in some practical work, developers may also test certain projects. These projects tested by the developers themselves can be called self-testing projects. The developers ensure that the released versions are correct, so the initial information for these self-testing projects can be directly stored in the primary database.

[0069] In practice, there is another type of project where testing is handled by a dedicated testing team. These projects, once tested and passed, require release; they can be called non-self-tested projects. For these non-self-tested projects, the package checksum of the software package must be recorded in the test report, and it must be ensured that the package checksum recorded in the test report is the same as the package checksum of the actual delivered version.

[0070] Therefore, in a test report generation method according to an embodiment of this application, the non-self-tested item can be regarded as a first type of tested item. Each first type of tested item contains multiple first type of tested software packages.

[0071] For the first type of tested items, the aforementioned testing platform can also obtain the package identifier of the first type of tested software package in the first type of tested items, and generate a first tested software package list corresponding to the first type of tested items based on the package identifier of the first type of tested software package.

[0072] Then the testing platform can obtain the second list of tested software packages corresponding to the first type of tested projects generated by the release platform; wherein, the second list of tested software packages is generated by the release platform based on multiple first type of tested software packages in the first type of tested projects.

[0073] It is understandable that after obtaining the first type of tested software package of the first type of tested project, the aforementioned release platform can generate a second list of tested software packages corresponding to the first type of tested project based on the identifier of the first type of tested software package.

[0074] After obtaining the first list of tested software packages and the second list of tested software packages, the aforementioned testing platform can compare the first list of tested software packages with the second list of tested software packages. If the first list of tested software packages and the second list of tested software packages are the same, it can be said that the tested software packages corresponding to the first list of tested software packages and the tested software packages corresponding to the second list of tested software packages are the same, both being first-type tested software packages. Then, the first information of multiple tested software packages can be stored in the first database.

[0075] The embodiments of this application will be illustrated with an example. Assume that the non-self-tested project is a first type of tested project 1, which includes software package 1, software package 2, and software package 3, a total of three software packages. Then, the testing platform can obtain the software package identifier of software package 1, the software package identifier of software package 2, and the software package identifier of software package 3, and then generate a first list of tested software packages.

[0076] If the publishing platform publishes three pieces of first information to the testing platform: “package 1: MD5 value 1”, “package 2: MD5 value 2”, and “package 3: MD5 value 3”, then the publishing platform can also generate a second list of tested packages containing the package identifier of package 1, the package identifier of package 2, and the package identifier of package 3.

[0077] When the testing platform compares the first and second lists of tested software packages, it finds that both lists contain the package identifiers for package 1, package 2, and package 3. This indicates that these three packages are not part of the self-test project, and a test report can be generated for them. Therefore, the initial information of multiple tested software packages can be stored in the first database.

[0078] In some other examples, when the first list of tested software packages is not exactly the same as the second list of tested software packages, it can be said that the first list of tested software packages contains software packages for the self-test project. In this case, only the first information corresponding to the software package identifiers in the first list of tested software packages that are the same as the software package identifiers in the second list of tested software packages can be stored in the first database.

[0079] For example, assuming that the first tested package list includes the package identifiers of package 4, package 5, and package 7, and the second tested package list includes the package identifiers of package 4, package 5, and package 6, then only the first information corresponding to package 4 and package 5 can be stored in the first database.

[0080] In one possible implementation of this application, for a non-self-testing project, the testing platform can search for the related project details of the non-self-testing project based on the PMS (Project Management System) associated with the non-self-testing project, determine the non-self-testing software packages with related relationships contained in the non-self-testing project based on the related project details, and generate a first list of tested software packages based on this.

[0081] In this embodiment, the associated project details refer to the association information between various non-self-testing software packages that have a relationship within the non-self-testing project. These associated project details may include each non-self-testing software package and its modified branches, the testing interface, major modifications and their database modifications, the scope of impact, and the deployment steps. For example, assuming the various non-self-testing software packages with a relationship are package a-package f, the generated first tested software package list may include the package identifiers of package a-package f. In this embodiment, generating the first tested software package list through the associated project details and comparing the first tested software package list with the second tested software package list ensures that the software packages corresponding to the MD5 values ​​filled in the test reports for non-self-testing projects are definitely tested. This also avoids the subsequent deployment of untested applications, preventing quality issues and audit risks.

[0082] exist Figure 2 Based on the test report generation method shown, this application embodiment also provides a possible implementation method, such as... Figure 4 The diagram shown is a flowchart of a third embodiment of a test report generation method according to an example of this application. The method may include:

[0083] S310: Obtain the test parameters of the software package to be tested, and perform tests on the software package to be tested based on the test parameters.

[0084] S320, after the test is passed, the software package to be tested is recorded as the tested software package and the first test result of the software package to be tested is recorded.

[0085] S330, Obtain the first information generated by the release platform for the tested software package. The first information includes: software package identifier and software package verification code corresponding to the software package identifier; the software package verification code is calculated by the release platform for the tested software package on the test platform; the software package verification code is used to verify whether the tested software package has been modified.

[0086] S340: Obtain the first test result of the tested software package.

[0087] S350 generates a test report based on the first test result and the first information. The test report includes the first test result of the tested software package and the software package checksum corresponding to the tested software package.

[0088] Those skilled in the art will understand that the test parameters required to perform tests on different applications generally differ. During the testing phase, for each software package under test, the test platform can configure test parameters for that software package according to specific test requirements in order to perform tests on that software package.

[0089] The specific parameter items included in the test parameters configured for a software package can be selected according to actual needs, and this application embodiment does not limit this. For example, these parameter items may include: parameter items for specifying the test environment, parameter items for specifying specific test data, parameter items for specifying the results items that should be displayed in the test report, etc.

[0090] In this embodiment, the test parameters configured for each software package to be tested can be predefined in the test platform. Therefore, the test platform can obtain the test parameters of the software package to be tested, and then test the software package to be tested based on these test parameters. After the test is passed, the software package to be tested can be regarded as a tested software package, and the first test result of the software package to be tested can be recorded so that a test report can be generated based on the first test result.

[0091] It is understood that steps S330 to S350 in this step are the same as or similar to steps S110 to S130 in the first embodiment, and will not be described again here.

[0092] Furthermore, those skilled in the art will understand that, in order to comprehensively identify the various potential risks that an application may pose, it is generally necessary to perform multiple different types of tests on the application. In some examples, multiple first test units can be integrated within the testing platform according to actual needs, and different first test units can be used to perform different types of tests. Moreover, different first test units are pre-configured with corresponding test parameters.

[0093] In other words, various types of testing capabilities can be encapsulated into independent units (first test units), and these independent units can be integrated into the testing platform so that the testing platform can be used to execute various types of tests. This application does not limit the specific number and function of the first test units to be integrated into the testing platform; those skilled in the art can select them according to actual needs. The first test unit can be a test unit that tests various branches of a tested software package.

[0094] In some examples, the test parameters obtained by the testing platform specifically include test parameters configured for each software package to be tested. In this embodiment, for a software package to be tested, the testing platform specifically determines the first test unit for the test indicated by the test package based on the parameter items included in the test parameters configured for that software package; then it calls the first test unit to execute the test, so that the first test unit performs the test on that software package.

[0095] In the embodiments of this application, different types of tests correspond to different test items. Therefore, the parameter item in the test parameters configured for a software package under test corresponds to which type of test, that is, it represents the type of test indicated by the software package under test. In practical applications, the correspondence between parameter items and test types can be predefined on the test platform so that the test platform can determine the specific test type.

[0096] Of course, it is also possible that multiple different types of tests are specified for a single software package to be tested. The testing platform can determine the specific types of these multiple different types based on the same principles as described above, which will not be elaborated here.

[0097] In this embodiment of the application, by encapsulating different types of test functions into different first test units and integrating them on the test platform, and by having the test platform flexibly call different test units according to the parameter items included in the test parameters, the complexity of operation when multiple different types of tests need to be executed is greatly simplified and reduced, and it is also more conducive to improving test efficiency.

[0098] It should be noted that in some examples, when setting parameters and test parameters in the test platform, some parameters can be defined in the test platform as variable names. For example, suppose the test parameters configured for a software package include the size of the application's software package. When the developer predefines this parameter in the test platform, they will define the variable name "size" and the test parameter is α M (megabytes). Then, the parameter and test parameter set in the test platform will ultimately be "size=α M".

[0099] In some examples, in embodiments of this application, in addition to using a first test unit to test the software package, a second test unit can also be used to test the software package. The second test unit is a test unit that tests the software package as a whole. The second test unit may include: a stress test unit for performing stress testing, a difference test unit for performing diff testing, and an automated test unit for performing automated testing, etc.

[0100] In some examples, after obtaining the first test result and before generating a test report based on the first test result and the first information, a call instruction for a second test unit can be received from the publishing platform. This call instruction includes the name and address information of the second test unit. Then, based on the call instruction, the second test unit is invoked to test the tested software package, obtaining the second test result. Finally, a test report is generated based on the first test result, the first information, and the second test result. This allows the generated test report to include not only the results of testing branches within the software package but also the results of testing the entire software package, making the test report more comprehensive.

[0101] For example, suppose the testing platform integrates a difference testing unit and a stress testing unit. The difference testing unit corresponds to parameters diff-1 to diff-n, and the stress testing unit corresponds to parameters pre-1 to pre-m. When the testing platform receives a call instruction to test a pre-tested software package, if these calls contain address information corresponding to parameters diff-1 to diff-n, then it will use that address information to call the difference testing unit to perform the test on the pre-tested software package.

[0102] In some examples, the aforementioned publishing platform can display extended fields, where developers can enter the name and address information of the second test unit to be invoked. The publishing platform can then generate invocation instructions based on the entered name and address information of the second test unit.

[0103] In some examples, when the pre-deployment test type indicated for the packaged software package includes multiple different types, the test platform can specifically indicate different test environments for the second test unit used to execute the multiple different types of tests when calling the second test unit to execute the tests, so that the different second test units can execute different types of tests in different test environments.

[0104] In one example, parameters such as `primary_address` and `secondary_address` can be used to specify different test environments for different second test units. For instance, the `primary_address` parameter can be used to instruct the differential test unit to perform differential tests in test environment 1, and the `secondary_address` parameter can be used to instruct the stress test unit to perform stress tests in test environment 2.

[0105] By assigning different test environments to different second test units, each second test unit can be isolated in a different environment to run its test functions. This ensures that the test functions of each second test unit can be executed in parallel without interfering with each other, which helps to improve test efficiency and also helps to ensure that the test process does not affect the production environment.

[0106] Furthermore, it should be understood that as requirements continue to evolve, in some application scenarios, in addition to the test units already integrated into the test platform, those skilled in the art may need to add further test units to the test platform to perform other types of tests, thereby expanding the testing functionality provided by the test platform. In response to this, in some examples, an open parameter system can be designed to support the invocation of newly added test units.

[0107] In one example, when communication between the test platform and the release platform is implemented via an HTTP interface, the above purpose can be achieved by extending fields (such as the custom_params field).

[0108] To facilitate understanding, we will first briefly explain the meaning and function of extended fields. Specifically, the aforementioned deployment platform can predefine extended fields, which can be used to invoke newly added test units.

[0109] It's easy to understand that after adding a new test unit to the testing platform (this new test unit is different from the existing test units already integrated into the testing platform), the testing platform previously lacked the functionality to execute tests using the new test unit. In this case, if it's necessary to call the new test unit to perform tests on the software package, the name and address information of the test unit used to implement the new test unit's testing functionality can be set in the extended fields of the release platform. The release platform then sends this information to the test unit to enable the invocation of the new test unit.

[0110] Let's illustrate this with an example. Suppose that the test platform already has differential testing units and stress testing units integrated, and then an automated testing unit is added to the test platform later. After the automated testing unit is added to the test platform, the release platform can fill in the name and address information of the testing unit used to implement the automated testing in this extended field and send it to the test platform to enable the invocation of the automated testing unit.

[0111] Specifically, by using an open parameter system, after relevant personnel have integrated new test units into the test platform according to their needs, they can easily call the new test units to implement new test functions without having to frequently update the interface definition of the test platform. The operation is simple and facilitates the expansion and upgrading of test functions within the test platform.

[0112] In some examples, the testing platform can perform a pre-push verification on the MD5 value populated in the test report after it has been generated, before actually pushing the report.

[0113] The push notification of a test report mentioned here can be understood as placing the test report in a state that is visible to the user, so that the user can read the content recorded in the test report.

[0114] The specific process of pre-push verification is as follows: For each report entry in the test report, verify whether the MD5 value recorded in the report entry is consistent with the reference MD5 value recorded in the first database (i.e., the MD5 value corresponding to the application in the first database for the report entry); if the verification results of all report entries are consistent, the verification passes and the test platform pushes the verified test report; otherwise, the verified test report is not pushed.

[0115] By performing the above pre-push verification before the actual push of the test report, it is possible to avoid the situation where the test platform fills the test report with an incorrect MD5 value due to unexpected factors such as reading errors when reading the MD5 value in the first database and filling it with the MD5 value in the test report in the early stage. This helps to further ensure the accuracy of the MD5 value filled in the final pushed test report.

[0116] To more clearly illustrate the test report generation method of this application's embodiments, the following will be combined with... Figure 5 and Figure 6 To explain, first, the developers put the source code into the Git repository for the test code. Then, they notify the testers, who perform system initialization and environment preparation. Next, they obtain the package to be tested (i.e., the code to be tested) and its branches from the Git repository using a testing platform. They then test the test code (the package to be tested and its branches). After testing, the testers can notify the developers to tag the package that passes the test, preparing it for deployment. The developers can then use the release platform to tag the tested package and generate its MD5 hash. Git is an open-source distributed version control system.

[0117] The testing platform can then obtain information such as the project identifier (project_key), the names of multiple software packages, the MD5 value and package name corresponding to the software package, the release platform ID, the step node ID, and the reason for change from the HTTP request. Here, the step node can be the branch node ID of the application, and the reason for change can be the reason for changing the branch of the application.

[0118] Then, based on the project identifier, it is determined whether the project level is a self-test project or a non-self-test project. If it is a self-test project, the MD5 values ​​of all software packages in the project are saved to the first database mentioned above.

[0119] If the project is not a self-tested project (i.e., the first type of tested project), the testing platform can also obtain the identification information of all software packages in the non-self-tested project, and then generate a list of valid applications for testing (i.e., the first list of tested software packages). The testing platform can also obtain the application information passed in by the release platform (i.e., the second list of tested software packages), and compare the passed application information with the valid applications for testing saved by the testing platform (i.e., comparing the first list of tested software packages and the second list of tested software packages). Only when the identifier of the tested software package exists in both the first list of tested software packages and the second list of tested software packages will the set_MD5 interface be called to save the MD5 information of the tested software package to the database (i.e., the first database), thereby realizing the synchronization of the MD5 value from the release platform to the testing platform. Furthermore, since this application only synchronizes the MD5 values ​​of tested software packages that exist in both the first list of tested software packages and the second list of tested software packages, it effectively controls the MD5 value synchronization process to a certain extent through the list of tested software packages.

[0120] In some examples, when generating a list of tested packages, an empty list container can be set up first, and then the identification information of the tested packages can be stored in the list container, thereby generating a list of tested packages.

[0121] In other examples, when an update is received for a tested software package in any project, the information of that tested software package can be updated, such as the MD5 value, the name of the tested software package, and the release platform ID.

[0122] In some examples, the testing platform can also obtain parameters of a specified testing environment sent by the release platform, and then determine the testing environment to be tested based on the parameters of the specified testing environment.

[0123] Then, the release platform sends test parameters for automating or stress testing the tested software package. These parameters may include the name and address of the test unit for automated testing or the test unit for stress testing. These parameters are then used to invoke either the automated or stress testing unit to perform the tests.

[0124] In some examples, various data can also be recorded during the testing process, including: the name of the project being tested, the task ID, the name of the test unit, and the second test result.

[0125] Finally, the MD5 value can be obtained from the first database, and a test report can be generated based on the MD5 value, the first test result, and the second test result to ensure that the MD5 value in the test report is consistent with the MD5 value of the tested software package, and there will be no audit and quality risks caused by the MD5 of untested applications.

[0126] After generating the test report, the scrumTagResult function can be called to notify the release platform to continue releasing the tested software package.

[0127] In some examples, if a project has already sent a test report to the release platform, and then resents the test report with the reason for the change, the scrumTagResult function can be called to send a change report email to the release platform.

[0128] In some examples, throughout the entire testing process, a test report generation method according to an embodiment of this application can also record anomalies during the testing process to form an anomaly log, and can also record normal logs at key nodes.

[0129] For example, key nodes may include the following:

[0130] The first key node is the node where the release platform synchronizes the MD5 value with the test platform. At this node, the content that can be recorded in the log includes: project name, name of tested package, and MD5 value.

[0131] The second key point is to conduct the second test phase. At this point, the information that can be recorded in the log includes: task ID, test environment, and test unit name.

[0132] The third key step is the verification process before the push notification. At this stage, the information that can be recorded in the logs includes the project name and the verification result.

[0133] Corresponding to the above method embodiments, this application also provides a test report generation apparatus, see [link to relevant documentation]. Figure 7The diagram below shows the structure of the test report generation device provided in this application embodiment. The device specifically includes:

[0134] The first acquisition module 710 is used to acquire first information generated by the release platform for the tested software package. The first information includes: software package identifier and software package verification code corresponding to the software package identifier; the software package verification code is calculated by the release platform for the tested software package of the test platform; the software package verification code is used to verify whether the tested software package has been modified.

[0135] The second acquisition module 720 is used to acquire the first test result of the tested software package;

[0136] The generation module 730 is used to generate a test report based on the first test result and the first information. The test report includes the first test result of the tested software package and the software package check code corresponding to the tested software package.

[0137] The test report generation device provided in this application embodiment ensures that the package checksum in the test report is consistent with the package checksum calculated by the release platform for the same tested package, since the package checksum in the test report is directly obtained from the release platform. This avoids situations where the MD5 value of the package recorded in the test report is inconsistent with the MD5 value generated by the release platform, or where the MD5 value of the package recorded in the test report is not the MD5 value of the actual delivered version of the package. This reduces the risk of audit failure caused by such discrepancies and helps ensure the normal release of the application.

[0138] In some examples, the test platform has at least one tested project, and each tested project contains multiple tested software packages;

[0139] In this regard, the first acquisition module 710 is specifically used for:

[0140] For each tested project, obtain the first information generated by the release platform for the multiple tested software packages contained in that tested project;

[0141] Module 730 is generated, specifically for:

[0142] Based on the first test results of multiple tested software packages included in the tested project and the first information corresponding to the multiple tested software packages, a test report corresponding to the tested project is generated. The test report contains report entries of multiple tested software packages included in the tested project. Each report entry of a tested software package contains the first test result of a tested software package and the software package check code corresponding to the tested software package.

[0143] In some examples, a first database is set up in the test platform; in this regard, the above-mentioned device further includes: a storage module, used to store the first information of multiple tested software packages in the first database after obtaining the first information generated by the release platform for multiple tested software packages contained in the tested project;

[0144] Accordingly, the aforementioned generation module 730 is specifically used for:

[0145] The first information of multiple tested software packages contained in the tested project is obtained from the first database, and a test report corresponding to the tested project is generated based on the first test results of the multiple tested software packages contained in the tested project and the first information corresponding to the multiple tested software packages.

[0146] In some examples, at least one tested item is a first-class tested item, which is an item tested by a tester; each first-class tested item contains multiple first-class tested software packages;

[0147] In this regard, the above-mentioned apparatus may further include: a list generation module, used to: obtain the package identifier of a first type of tested package before storing the first information of multiple tested package software into a first database, and generate a first tested package list corresponding to the first type of tested items based on the package identifier of the first type of tested package software;

[0148] The list retrieval module is used to: retrieve the list of second tested software packages corresponding to the first type of tested projects generated by the release platform; the second tested software package list is generated by the release platform based on multiple first type of tested software packages in the first type of tested projects.

[0149] The aforementioned storage module is specifically used for:

[0150] When the first list of tested software packages is the same as the second list of tested software packages, the first information of multiple tested software packages is stored in the first database.

[0151] In some examples, the above-described apparatus further includes an update module, configured to: after storing first information of a plurality of tested software packages in a first database, when an updated first information for any tested software package is obtained, replace the first information of the tested software package already stored in the first database with the updated first information.

[0152] In some examples, the above-described apparatus further includes: a first test module, configured to: obtain test parameters of the software package to be tested before obtaining the first test result of the tested software package, and perform a test on the software package to be tested based on the test parameters; and after the test is passed, treat the software package to be tested as the tested software package and record the first test result of the software package to be tested.

[0153] In some examples, the test platform integrates multiple first test units, each used to execute different types of tests; each first test unit is pre-configured with corresponding test parameters.

[0154] Specifically, the aforementioned test module is used to: determine the first test unit corresponding to the test parameters;

[0155] The first test unit corresponding to the test parameters is invoked to test the software package to be tested.

[0156] In some examples, the device also includes: a calling module for:

[0157] Receive the calling instruction for the second test unit sent by the publishing platform. The calling instruction includes the name and address information of the second test unit.

[0158] The second test module is used to call the second test unit to test the tested software package based on the call command, and obtain the second test result;

[0159] Module 730 is generated, specifically for:

[0160] A test report is generated based on the first test result, the first information, and the second test result.

[0161] In some examples, an HTTP interface is defined on the test platform, and the release platform communicates with the test platform through the HTTP interface.

[0162] This application also provides an electronic device, such as... Figure 8 As shown, it includes a processor 801, a communication interface 802, a memory 803, and a communication bus 804. The processor 801, communication interface 802, and memory 803 communicate with each other via the communication bus 804.

[0163] Memory 803 is used to store computer programs;

[0164] When the processor 801 executes the program stored in the memory 803, it implements the method steps of the test report generation method provided in any of the foregoing embodiments.

[0165] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0166] The communication interface is used for communication between the aforementioned terminal and other devices.

[0167] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0168] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0169] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements any of the test report generation methods described in the above embodiments.

[0170] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the test report generation methods described in the above embodiments.

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

[0172] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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 said element.

[0173] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the embodiments for the test report generation apparatus, electronic device, and readable storage medium are basically similar to the method embodiments, and therefore the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0174] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method for generating test reports, characterized in that, The method is applied to a testing platform that is communicatively connected to a release platform, and includes: The system obtains first information generated by the publishing platform for the tested software package. The first information includes: a software package identifier and a software package verification code corresponding to the software package identifier; the software package verification code is calculated by the publishing platform for the tested software package of the testing platform; the software package verification code is used to verify whether the tested software package has been modified. Obtain the first test result of the tested software package; Based on the first test result and the first information, a test report is generated, which includes the first test result of the tested software package and the software package checksum corresponding to the tested software package.

2. The method according to claim 1, characterized in that, The test platform has at least one tested project, and each tested project contains multiple tested software packages; The step of obtaining the first information generated by the publishing platform for the tested software package includes: For each tested project, obtain the first information generated by the release platform for the multiple tested software packages contained in that tested project; The step of generating a test report based on the first test result and the first information includes: Based on the first test results of multiple tested software packages included in the tested project and the first information corresponding to the multiple tested software packages, a test report corresponding to the tested project is generated. The test report contains report entries of multiple tested software packages included in the tested project. Each report entry of a tested software package contains the first test result of a tested software package and the software package check code corresponding to the tested software package.

3. The method according to claim 2, characterized in that, The test platform is equipped with a first database; After obtaining the first information generated by the publishing platform for the multiple tested software packages included in the tested project, the method further includes: Store the first information of the plurality of tested software packages into the first database; The step of generating a test report corresponding to the tested project based on the first test results of multiple tested software packages included in the tested project and the first information corresponding to the multiple tested software packages includes: The first information of multiple tested software packages contained in the tested project is obtained from the first database, and a test report corresponding to the tested project is generated based on the first test results of the multiple tested software packages contained in the tested project and the first information corresponding to the multiple tested software packages.

4. The method according to claim 3, characterized in that, The at least one tested item is a first-category tested item, which is an item tested by testers; each first-category tested item contains multiple first-category tested software packages; Before storing the first information of the plurality of tested software packages into the first database, the method further includes: Obtain the package identifier of the first type of tested package, and generate a first list of tested packages corresponding to the first type of tested projects based on the package identifier of the first type of tested package; Obtain the second list of tested software packages corresponding to the first type of tested projects generated by the publishing platform; the second list of tested software packages is generated by the publishing platform based on multiple first type of tested software packages in the first type of tested projects. The step of storing the first information of the plurality of tested software packages into the first database includes: When the first list of tested software packages is the same as the second list of tested software packages, the first information of the plurality of tested software packages is stored in the first database.

5. The method according to claim 3, characterized in that, After storing the first information of the plurality of tested software packages into the first database, the method further includes: When an updated first information for any tested software package is obtained, the updated first information is used to replace the first information of that tested software package already stored in the first database.

6. The method according to claim 1, characterized in that, Before obtaining the first test result of the tested software package, the method further includes: Obtain the test parameters of the software package to be tested, and perform tests on the software package to be tested based on the test parameters; After the test is passed, the software package to be tested is designated as the tested software package, and the first test result of the software package to be tested is recorded.

7. The method according to claim 6, characterized in that, The testing platform integrates multiple first testing units, each of which is used to perform different types of tests; each first testing unit is pre-configured with corresponding test parameters. The testing of the software package to be tested based on the test parameters includes: Determine the first test unit corresponding to the test parameters; The first test unit corresponding to the test parameters is invoked to test the software package to be tested.

8. The method according to claim 1, characterized in that, Before generating the test report based on the first test result and the first information, the method further includes: Receive a calling instruction for the second test unit sent by the publishing platform, the calling instruction including the name and address information of the second test unit; Based on the invocation instruction, the second test unit is invoked to test the tested software package and obtain the second test result; The step of generating a test report based on the first test result and the first information includes: A test report is generated based on the first test result, the first information, and the second test result.

9. The method according to claim 1, characterized in that, The test platform is defined with an HTTP interface, and the publishing platform communicates with the test platform through the HTTP interface.

10. A test report generation device, characterized in that, The device is applied to a testing platform that is communicatively connected to a release platform, and includes: The first acquisition module is used to acquire first information generated by the release platform for the tested software package. The first information includes: a software package identifier and a software package verification code corresponding to the software package identifier; the software package verification code is calculated by the release platform for the tested software package of the test platform; the software package verification code is used to verify whether the tested software package has been modified. The second acquisition module is used to acquire the first test result of the tested software package; The generation module is used to generate a test report based on the first test result and the first information. The test report includes the first test result of the tested software package and the software package checksum corresponding to the tested software package.

11. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-9.

Images