Package file generation method, package file generation device and electronic equipment

Abstract

The present application discloses a package file generation method, a package file generation device, an electronic device, and a computer-readable storage medium, comprising: obtaining an original script file related to a method to be tested; filtering each field in the original script file based on a preset screening condition to obtain a target field, wherein the screening condition includes: matching a preset key field; shielding the target field in the original script file to obtain a new script file, wherein the new script file does not contain the target field; generating a target package file based on the new script file, wherein the target package file is used to implement testing of test data, wherein the test data includes data that meets the preset preconditions and data that does not meet the preconditions. Through the solution of the present application, the situation in which abnormal information is frequently returned due to incorrect input test data during the test process can be reduced, thereby saving test costs and improving the flexibility of the test process.

Description

Technical Field

[0001] The present application belongs to the field of data processing technology, and in particular relates to a package file generation method, a package file generation device, an electronic device, and a computer-readable storage medium. Background Art

[0002] Currently, many enterprise platforms require database calls. These database calls require running multiple methods to implement different functions. These methods may have numerous preconditions before being called or executed. When testing various platform functions, each method can only be executed properly if these preconditions are met. Otherwise, the method may fail to be called or executed due to unmet preconditions, causing the platform to experience an exception or return directly, preventing subsequent processes from proceeding. This requires verification personnel to prepare a large amount of accurate verification data upfront to verify each method in the platform, which is extremely costly. Summary of the Invention

[0003] In view of this, the present application provides a package file generation method, a package file generation device, an electronic device and a computer-readable storage medium, which can save testing costs and improve flexibility during the testing process.

[0004] A first aspect of the present application provides a package file generation method, comprising:

[0005] Get the original script file related to the method to be tested;

[0006] Filtering each field in the original script file based on a preset filtering condition to obtain a target field, wherein the filtering condition includes: matching a preset key field, the preset key field being used to indicate that the content returned by the return statement is abnormal content;

[0007] Masking the target field in the original script file to obtain a new script file, wherein the new script file does not contain the target field;

[0008] A target package file is generated based on the new script file, wherein the target package file is used to implement testing of test data, where the test data includes data that meets preset preconditions and data that does not meet the preconditions.

[0009] A second aspect of the present application provides a package file generation device, comprising:

[0010] An acquisition unit, used to acquire the original script file related to the method to be tested;

[0011] a screening unit, configured to screen each field in the original script file based on a preset screening condition to obtain a target field, wherein the screening condition includes: matching a preset key field, the preset key field being used to indicate that the content returned by the return statement is abnormal content;

[0012] a masking unit, configured to mask the target field in the original script file to obtain a new script file, wherein the new script file does not contain the target field;

[0013] A generating unit is configured to generate a target package file based on the new script file, wherein the target package file is used to implement testing of test data, wherein the test data includes data that meets preset preconditions and data that does not meet the preconditions.

[0014] The third aspect of the present application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the method of the first aspect are implemented.

[0015] A fourth aspect of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method of the first aspect are implemented.

[0016] A fifth aspect of the present application provides a computer program product, which includes a computer program. When the computer program is executed by one or more processors, it implements the steps of the method of the first aspect.

[0017] As can be seen from the above, in the present application scheme, the original script file related to the method to be tested is first obtained, and then the various fields in the original script file are screened based on the preset screening conditions to obtain the target field, wherein the screening conditions include: matching with the preset key fields, and then the target field in the original script file is shielded to obtain a new script file, wherein the new script file does not contain the target field, and finally a target package file is generated based on the new script file, wherein the target package file is used to implement the test of the test data, and the test data includes data that meets the preset preconditions and data that does not meet the preconditions. Through the present application scheme, the situation where abnormal information is frequently returned due to incorrect input test data during the test process can be reduced, the test cost is saved, and the flexibility in the test process is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0019] Figure 1 This is a schematic diagram of the implementation process of the package file generation method provided in the embodiment of the present application;

[0020] Figure 2 This is a structural block diagram of a package file generating device provided in an embodiment of the present application;

[0021] Figure 3 Schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0023] Currently, many enterprise platforms rely on methods stored in databases to implement most core algorithms, key business processes, important interfaces, and scheduled data collection. Most of these methods are simply called from the front-end, some are called on a scheduled basis, and some are encapsulated as interfaces and provided to other platforms. After a method is executed, its results are typically displayed on the front-end, while some are directly stored in the backend, awaiting use by other methods. Still others are not displayed in the returned results until they are called from other platforms. Regardless of how these methods are called or displayed, they all require complex preconditions to be met before they can be executed. If these preconditions are not met, the method will not execute properly, and the program will throw an exception or return, preventing subsequent functions or processes from executing. Therefore, testing these methods requires manual preparation of test data, which must meet one or more preconditions to ensure that all methods under test are called and executed. If there is a requirement for data mutual exclusion in the preconditions, it is necessary to prepare multiple test data to verify different scenarios and methods respectively; if there are many preconditions, it is necessary to prepare a large amount of test data to test them separately, which results in a very large resource overhead spent on data preparation. Based on this, the embodiment of the present application proposes a package file generation method, a package file generation device and an electronic device, which can regenerate a new script file without changing the core business logic and algorithm of these methods. The new script file will be executed in the database to generate a new package file. The tester will directly call the new package file in the database during the smoke or test phase. In this way, only one piece of data is needed to cover all the functions of the test verification, and there is no need to worry about exiting the execution due to the data not meeting one or some preconditions. In order to illustrate the above technical solution of the present application, it is described below through specific embodiments.

[0024] Example 1

[0025] In the embodiment of the present application, the execution entity of the process is an electronic device such as a server or a personal computer. Figure 1 The following is a flowchart of the implementation of the package file generation method provided in Example 1 of the present application, which is detailed as follows:

[0026] Step 101, obtaining the original script file related to the method to be tested;

[0027] In an embodiment of the present application, the tester may first specify one or more methods in the platform as the method to be tested. After determining the above-mentioned method to be tested, it is necessary to further obtain the original script file related to the above-mentioned method to be tested. Specifically, each method in the platform is generally stored in a preset database. Therefore, the start address and end address of the above-mentioned method to be tested in the data dictionary table (dba_source) in the above-mentioned database can be obtained first, and then the above-mentioned original script file can be extracted from the above-mentioned database based on the above-mentioned start address and end address, that is, the code between the above-mentioned start address and the above-mentioned end address is extracted, that is, the original script file, wherein the above-mentioned start address refers to the starting row number start_num, and the above-mentioned end address refers to the ending row number end_num. Furthermore, the package header and package body name associated with the above-mentioned original script file under the correct system user name can also be queried in the above-mentioned data dictionary table, wherein the above-mentioned correct system user refers to the owner of the package header and package body associated with the above-mentioned original script file, that is, the user who actually executes the call.

[0028] Step 102: Filter each field in the original script file based on a preset filtering condition to obtain a target field;

[0029] In an embodiment of the present application, a user can pre-set filtering conditions in the electronic device, and the electronic device can then filter each field in the original script file based on the filtering conditions to obtain the target field. Specifically, the filtering conditions include: matching with a preset key field, wherein the preset key field is used to indicate that the content returned by the return statement is abnormal content; that is, filtering out fields that do not match the preset key field and retaining fields that match the preset key field. Then, the above step 102 can be performed as follows:

[0030] A1. Obtain and parse the preset configuration file to obtain key fields.

[0031] In an embodiment of the present application, the electronic device may pre-store a configuration file, which is generated based on the original package file. Based on this, the electronic device may first obtain and parse the above configuration file to obtain the key fields configured in the configuration file. Optionally, in addition to being configured with key fields, the above configuration file may also be configured with the following data: sql starting with the header name of the original package file, sql ending with the header name of the original package file, sql starting with the package name of the original package file, sql ending with the package name of the original package file, sql starting with the name of the method to be tested, sql ending with the name of the method to be tested, and the name of the target package file. Optionally, the generation process of the above configuration file may be to first obtain the source code of the original package file, then traverse the above source code to obtain all methods called by the above source code, then obtain the return statement in each method, and finally generate the above configuration file based on the return statement in each method obtained, wherein the above return statement refers to the return statement given in the method. Furthermore, in order to select key fields more specifically and avoid the configuration file from being too bloated, after obtaining the return statements in each method, each return statement can be analyzed, specifically to detect whether the content returned by each return statement is the preset exception content, that is, to detect whether each return statement will throw an exception or cause the program to exit execution, etc. If so, it is considered that the content returned by the above return statement is exception content; if not, it is considered that the content returned by the above return statement is non-exceptional content; after analyzing each return statement, the return statement whose returned content is the above exception content is determined as the key field, and the above configuration file is generated based on the determined key fields.

[0032] A2. Match each field contained in the original script file with the key field;

[0033] In the embodiment of the present application, the code in the original script file is traversed, and each field contained in the original script file is matched with each key field. Specifically, only when two fields are completely consistent will they be confirmed as matching.

[0034] A3. Identify the field that successfully matches the above key field as the target field.

[0035] In the embodiment of the present application, when a field in the original script file is found to successfully match any key field, the field is identified as the target field. It should be noted that, given that there are multiple key fields, there may also be multiple target fields determined in this step, and the number of the above-mentioned key fields and target fields is not limited here.

[0036] Step 103: Mask the target field in the original script file to obtain a new script file;

[0037] In an embodiment of the present application, after the target field in the original script file is filtered out, the target field will be further masked. The masking process can be to delete the target field, or to replace the target field. Specifically, if the target field is masked by a replacement operation, the step 103 can be performed as follows: the target field in the original script file is replaced with a preset log write field to obtain a new script file, wherein the log write field is executed and the corresponding log write operation is performed. The preset log write field actually calls a log write method, that is, when encountering the target field, the target field is replaced with a log write method through a replacement operation. When the program runs to the original target field, the log write operation will be executed. It should be noted that the information written by the log write operation is not limited here. For example, the exception information thrown by the original target field (that is, the exception content returned by the original target field) can be written to the log file. Of course, for fields in the original script file that cannot be successfully matched with the target field, there is no need to perform a masking operation and can be directly retained. After all target fields in the original script file are masked, the resulting script file is a new script file. The new script file no longer contains the target field. Optionally, the log write field or other fields used to replace the target field may also be configured in the configuration file, which is not limited here. Furthermore, the generated new script file may be stored in the database for access by test users, which is not limited here.

[0038] Step 104: Generate a target package file based on the new script file.

[0039] In an embodiment of the present application, after obtaining a new script file, a target package file can be further generated based on the new script file. The target package file is used to implement testing of test data, where the test data includes data that meets preset preconditions and data that does not meet the preconditions. Specifically, considering that the new script file is usually stored in a database, and the database access rights and the execution rights of the test operations are usually only open to testers, the database can be called by the test user and the new script file can be executed based on the configuration file to generate a new header and body under the test user, that is, to generate a target package file. The test user specifically refers to the account corresponding to the tester. When calling the method in the target package file, since the fields that will throw or return exception content have been masked, regardless of whether the input test data meets the preconditions, it can be directly executed without exiting. When the input test data meets the preconditions, the corresponding data processing operations can be performed normally; when the input test data does not meet the preconditions, the exception information can be output to the log, and no forced exit will occur.

[0040] As can be seen from the above, through the solution of this application, the keywords that may throw abnormal content in the platform are blocked, and only less test data is needed to cover the test of all the methods to be tested, ensuring that the platform methods can be called normally, and through the log file, it can also be viewed which preconditions are met and which preconditions are not met by the input test data. Not only can the generated target package file be called normally without worrying about being forced to exit execution due to the input test data not meeting one or several preconditions, but it also provides a reference basis for the entire test plan or idea.

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

[0042] Example 2

[0043] The second embodiment of the present application provides a package file generation device, which can be integrated into an electronic device, such as Figure 2 As shown, the package file generation device 200 in the embodiment of the present application includes:

[0044] The acquisition unit 201 is used to acquire the original script file related to the method to be tested;

[0045] A screening unit 202 is configured to screen each field in the original script file based on a preset screening condition to obtain a target field, wherein the screening condition includes matching a preset key field, wherein the preset key field is used to indicate that the content returned by the return statement is abnormal content;

[0046] A masking unit 203 is configured to mask the target field in the original script file to obtain a new script file, wherein the new script file does not contain the target field;

[0047] The generating unit 204 is configured to generate a target package file based on the new script file, wherein the target package file is used to implement testing of test data, and the test data includes data that meets preset preconditions and data that does not meet the preconditions.

[0048] Optionally, the acquisition unit 201 includes:

[0049] An address acquisition subunit, configured to acquire the start address and end address of the method to be tested in a preset database;

[0050] The data extraction subunit is used to extract the original script file from the database based on the start address and the end address.

[0051] Optionally, the screening unit 202 includes:

[0052] The file parsing subunit is used to obtain and parse the preset configuration file to obtain key fields;

[0053] The field matching subunit is used to match each field contained in the original script file with the key field;

[0054] The field determination subunit is used to determine the field that successfully matches the above key field as the target field.

[0055] Optionally, the package file generating device further includes:

[0056] A storage unit, used for storing the new script file in the database;

[0057] Accordingly, the generating unit 204 is specifically configured to call the new script file in the database through a test user, and execute the new script file based on the configuration file to generate a target package file under the test user.

[0058] Optionally, the package file generating device 200 further includes:

[0059] A source code acquisition unit, used to obtain the source code of the original package file;

[0060] A source code traversal unit is used to traverse the source code to obtain all methods called by the source code;

[0061] A return statement obtaining unit is used to obtain the return statement in each method;

[0062] The configuration file generating unit is used to generate the above configuration file according to the return statements in each method obtained.

[0063] Optionally, the configuration file generating unit includes:

[0064] The abnormal content detection subunit is used to detect whether the content returned by each return statement is the preset abnormal content;

[0065] A key field determination subunit is used to determine the return statement whose returned content is the above-mentioned abnormal content as a key field;

[0066] Based on the determined key fields, the above configuration file is generated.

[0067] Optionally, the masking unit 203 is specifically configured to replace the target field in the original script file with a preset log writing field to obtain a new script file, wherein the log writing field performs a corresponding log writing operation after being executed.

[0068] As can be seen from the above, through the solution of this application, the keywords that may throw abnormal content in the platform are blocked, and only less test data is needed to cover the test of all the methods to be tested, ensuring that the platform methods can be called normally, and through the log file, it can also be viewed which preconditions are met and which preconditions are not met by the input test data. Not only can the generated target package file be called normally without worrying about being forced to exit execution due to the input test data not meeting one or several preconditions, but it also provides a reference basis for the entire test plan or idea.

[0069] Example 3

[0070] The third embodiment of the present application provides an electronic device. Figure 3 The electronic device 3 in the embodiment of the present application includes: a memory 301, one or more processors 302 ( Figure 3Only one is shown) and a computer program stored in memory 301 and executable on the processor. Memory 301 is used to store software programs and modules. Processor 302 executes the software programs and modules stored in memory 301 to perform various functional applications and data processing to obtain resources corresponding to the aforementioned preset events. Specifically, processor 302 implements the following steps when executing the computer program stored in memory 301:

[0071] Get the original script file related to the method to be tested;

[0072] Filtering each field in the original script file based on a preset filtering condition to obtain a target field, wherein the filtering condition includes: matching a preset key field, the preset key field being used to indicate that the content returned by the return statement is abnormal content;

[0073] Masking the target field in the original script file to obtain a new script file, wherein the new script file does not contain the target field;

[0074] A target package file is generated based on the new script file, wherein the target package file is used to implement testing of test data, and the test data includes data that meets preset preconditions and data that does not meet the preconditions.

[0075] Assuming that the above is the first possible implementation, in a second possible implementation provided based on the first possible implementation, the above-mentioned obtaining of the original script file related to the method to be tested includes:

[0076] Obtain the starting address and ending address of the above-mentioned method to be tested in a preset database;

[0077] The original script file is extracted from the database based on the start address and the end address.

[0078] In a third possible implementation provided on the basis of the second possible implementation, the fields in the original script file are filtered based on the preset filtering conditions to obtain the target fields, including:

[0079] Get and parse the preset configuration file to get the key fields;

[0080] Match each field contained in the above original script file with the above key fields;

[0081] The field that successfully matches the above key field is determined as the target field.

[0082] In a fourth possible implementation provided on the basis of the third possible implementation, the processor 302 further implements the following steps when running the computer program stored in the memory 301:

[0083] Storing the new script file in the database;

[0084] Accordingly, the target package file is generated based on the new script file, including:

[0085] The new script file in the database is called by a test user, and the new script file is executed based on the configuration file to generate a target package file under the test user.

[0086] In a fifth possible implementation provided on the basis of the third possible implementation, the processor 302 implements the following steps when running the computer program stored in the memory 301:

[0087] Get the source code of the original package file;

[0088] Traverse the above source code and get all the methods called by the above source code;

[0089] Get the return statement in each method;

[0090] Generate the above configuration file based on the return statements in each method obtained.

[0091] In a sixth possible implementation provided on the basis of the fifth possible implementation, generating the configuration file according to the obtained return statements in each method includes:

[0092] Check whether the content returned by each return statement is the preset abnormal content;

[0093] Determine the return statement whose returned content is the above-mentioned abnormal content as the key field;

[0094] Based on the determined key fields, the above configuration file is generated.

[0095] In a seventh possible implementation provided on the basis of the first possible implementation, generating the configuration file according to the obtained return statements in each method includes:

[0096] The target field in the original script file is replaced with a preset log writing field to obtain a new script file, wherein the corresponding log writing operation is performed after the log writing field is executed.

[0097] It should be understood that in the embodiment of the present application, the processor 302 may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0098] The memory 301 may include a read-only memory and a random access memory, and provides instructions and data to the processor 302. A portion or all of the memory 301 may also include a non-volatile random access memory. For example, the memory 301 may also store device type information.

[0099] As can be seen from the above, through the solution of this application, the keywords that may throw abnormal content in the platform are blocked, and only less test data is needed to cover the test of all the methods to be tested, ensuring that the platform methods can be called normally, and through the log file, it can also be viewed which preconditions are met and which preconditions are not met by the input test data. Not only can the generated target package file be called normally without worrying about being forced to exit execution due to the input test data not meeting one or several preconditions, but it also provides a reference basis for the entire test plan or idea.

[0100] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the above-mentioned device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0101] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

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

[0103] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the system embodiments described above are merely schematic. For example, the division of the above modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0104] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0105] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The above-mentioned computer program can be stored in a computer-readable storage medium, and the computer program, when executed by the processor, can implement the steps of the above-mentioned various method embodiments. Among them, the above-mentioned computer program includes computer program code, and the above-mentioned computer program code can be in source code form, object code form, executable file or some intermediate form, etc. The above-mentioned computer-readable storage medium may include: any entity or device that can carry the above-mentioned computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer-readable memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the above-mentioned computer-readable storage medium can be appropriately increased or decreased according to the requirements of legislation and patent practices in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practices, computer-readable storage media does not include electrical carrier signals and telecommunication signals.

[0106] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A package file generation method, characterized in that: include: Get the original script file related to the method to be tested; Filtering each field in the original script file based on a preset filtering condition to obtain a target field, wherein the filtering condition includes: matching a preset key field, the preset key field being used to indicate that the content returned by the return statement is abnormal content; Masking the target field in the original script file to obtain a new script file, wherein the new script file does not contain the target field; generating a target package file based on the new script file, wherein the target package file is used to implement testing of test data, the test data including data that meets preset preconditions and data that does not meet the preconditions; The fields in the original script file are screened based on the preset screening conditions to obtain the target fields, including: Get and parse the preset configuration file to get the key fields; Match each field contained in the original script file with the key field; Determine the field that successfully matches the key field as the target field; The target field in the original script file is masked to obtain a new script file, including: Replacing the target field in the original script file with a preset log writing field to obtain a new script file, wherein after the log writing field is executed, the abnormal content returned by the target field is written into the log file; The package file generation method further includes: Get the source code of the original package file; Traversing the source code to obtain all methods called by the source code; Get the return statement in each method; The configuration file is generated according to the return statements in each method obtained.

2. The package file generation method according to claim 1, wherein: The obtaining of the original script file related to the method to be tested includes: Obtaining the starting address and ending address of the method to be tested in a preset database; The original script file is extracted from the database based on the start address and the end address.

3. The package file generation method according to claim 1, wherein: After masking the target field in the original script file to obtain the new script file, the package file generation method further includes: Storing the new script file in a database; Accordingly, generating a target package file based on the new script file includes: The new script file in the database is called by a test user, and the new script file is executed based on the configuration file, so as to generate a target package file under the test user.

4. The package file generation method according to claim 3, wherein: Generating the configuration file according to the return statements in each method obtained includes: Check whether the content returned by each return statement is the preset abnormal content; Determine the return statement whose returned content is the abnormal content as a key field; The configuration file is generated based on the determined key fields.

5. A package file generating device, characterized in that: include: An acquisition unit, used to acquire the original script file related to the method to be tested; a screening unit, configured to screen each field in the original script file based on a preset screening condition to obtain a target field, wherein the screening condition includes: matching a preset key field, the preset key field being used to indicate that the content returned by the return statement is abnormal content; a masking unit, configured to mask the target field in the original script file to obtain a new script file, wherein the new script file does not contain the target field; a generating unit, configured to generate a target package file based on the new script file, wherein the target package file is used to implement testing of test data, the test data including data that meets preset preconditions and data that does not meet the preconditions; Wherein, the screening unit comprises: The file parsing subunit is used to obtain and parse the preset configuration file to obtain key fields; A field matching subunit, configured to match each field contained in the original script file with the key field; A field determination subunit, configured to determine a field that successfully matches the key field as a target field; The shielding unit is specifically configured to replace the target field in the original script file with a preset log writing field to obtain a new script file, wherein after the log writing field is executed, the abnormal content returned by the target field is written into the log file; Wherein, the package file generating device further includes: A source code acquisition unit, used to obtain the source code of the original package file; A source code traversal unit, used for traversing the source code to obtain all methods called by the source code; A return statement obtaining unit is used to obtain the return statement in each method; The configuration file generating unit is used to generate the configuration file according to the return statements in each method obtained.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 4 are implemented.

7. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 4 are implemented.

Images