Pressure measurement method and device for rapid bidding document generation based on automation

Abstract

The invention provides a pressure measurement method and device for rapid bidding document generation based on automation, and the method comprises the steps: creating an electronic bidding document file, and enabling the size of the electronic bidding document file to be adjusted according to a set demand; inputting item data of at least one electronic bidding document file, inserting the item data into a database, and generating at least one piece of pressure measurement item data by executing a storage process according to the input item data; generating at least one electronic biding document file, and verifying different project biding document files by verifying three values in the keyinfo.ini file of each electronic biding document file by using the corresponding pressure measurement project data; each electronic bidding document file is fragmented and stored in different file directories, and parameterized data files used for pressure test script execution are generated at the same time; and according to the parameterized file and the fragmented bidding document data, executing a performance test, verifying the throughput of a bidding document uploading scene interface, and improving the pressure test efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of bid document stress testing, and in particular to a stress testing method and device based on automated rapid bid document generation. Background Art

[0002] Suppliers upload bid documents very frequently, and in many cases, bid documents are uploaded in batches at a certain time. If you need to verify the throughput of the bid upload interface, you can implement it as follows according to the existing method:

[0003] 1. Create a bid document. The traditional way of making a bid document is for the staff to enter the contents of the bid document one by one through the bid document client and create multiple bid documents;

[0004] 2. Analysis of bid upload. Through business logic, we know that the steps of bid upload are as follows: the front end uploads the bid file in pieces (each piece is 2M in size), and the back end merges the piece data and verifies the integrity of the bid; if there is no error, the upload is successful, otherwise the upload fails.

[0005] 3. Split the bid document into pieces. Split the bid document file into pieces locally, with each piece being 2M in size. The specific commands are as follows:

[0006] split-b 2M\(encrypted\)Demo supplier A-K379990012023000011\(1\)-20231020.105624.Bidding document Dd; Note: The names of the fragment files all start with D00 and end with Dxx.

[0007] 4. Upload the bid document. Among them, obtaining the bid document md5 value, parameterized file maintenance, and script maintenance belong to the data preprocessing part.

[0008] 1) Get the md5 value of the bid document. Use the command to view the md5 value of the bid document file:

[0009] CertUtil-hashfile(encrypted)DemoVendorA-K379990012023000011(1)-20231020.105624.TenderMD5;

[0010] 2) Parameterized file maintenance. projectId is the project ID, md5 is the md5 value of the bid document file, totalSize is the bid document file size (note that it is the size in bytes), bidFilename is the bid file name, and bidFileDir is the name of the partition file directory;

[0011] 3) Maintain the stress test script. Modify the number of shard upload cycles:

[0012] For example:

[0013] The file starts with 00, and the last file is named 51, which is divided into 52 pieces in total. Generally, the size of the last piece is less than or equal to 2M. Therefore, the script needs to loop 51 times. The last piece needs to be requested separately (because the file size is inconsistent); that is, the size of the last piece of the file is directly obtained dynamically, without manual modification.

[0014] 4) Execute the bid upload. After completing the above data preprocessing operations, directly execute the script to complete the bid upload scenario;

[0015] 5. Verify the throughput of the bid upload interface.

[0016] Create multiple bid document data and complete the data preprocessing part of the bid upload step. Put the bid document segment data, parameterized files and execution scripts into the transmitter and compressor, and then perform performance testing to effectively evaluate the throughput of the bid upload scenario interface under the existing resource configuration of the system.

[0017] The above method for verifying the throughput of the bid upload interface has the following defects:

[0018] 1. It takes too long to prepare the bid data. Since the bid is created manually by entering the bid contents one by one through the bid client, this method takes a lot of time and is extremely inefficient, which is unsustainable.

[0019] 2. Bid slicing takes too much time. When executing commands locally to slice bid documents, the actions are repetitive and cumbersome, and the sliced ​​data needs to be uploaded to the compression machine again to prepare for subsequent stress testing.

[0020] 3. Parameterized file maintenance is cumbersome. After each bid data is created, the parameterized file of the bid data needs to be maintained once to prepare for subsequent stress testing. Summary of the invention

[0021] The technical problem to be solved by the present invention is to provide a stress testing method and device based on automated rapid tender document generation, thereby improving the efficiency of stress testing and the efficiency of uploading electronic tender document files.

[0022] In a first aspect, the present invention provides a stress testing method based on automated rapid tender document generation, comprising:

[0023] Step 1: Create an electronic tender document file so that the size of the electronic tender document file is adjusted according to set requirements;

[0024] Step 2: Enter at least one piece of project data of the electronic bidding document into the database, and generate at least one piece of stress testing project data by executing the stored procedure based on the entered project data;

[0025] Step 3: Generate at least one electronic tender document file and use the corresponding stress test project data to verify different project tender documents by checking the three values ​​of projectId, bidForld and bidForIdHash in the keyinfo.ini file of each electronic tender document file; save each electronic tender document file in different file directories, and generate parameterized data files for stress test script execution;

[0026] Step 4: Perform performance testing based on the parameterized file and the sharded bid data to verify the interface throughput for the bid upload scenario.

[0027] In a second aspect, the present invention provides a stress testing device based on automatic rapid generation of tender documents, comprising:

[0028] Creating a file module to create an electronic tender document file so that the size of the electronic tender document file is adjusted according to set requirements;

[0029] Create a data module, enter at least one piece of project data of the electronic bidding document into the database, and generate at least one piece of stress testing project data by executing the stored procedure based on the entered project data;

[0030] Generate stress test file module, generate at least one electronic bid document file and use the corresponding stress test project data, verify different project bid documents by checking the three values ​​of projectId, bidForld and bidForIdHash in the keyinfo.ini file of each electronic bid document file; save each electronic bid document file in different file directories, and generate parameterized data files for stress test script execution;

[0031] The stress test upload module performs performance testing based on the parameterized file and the sharded bid data to verify the interface throughput of the bid upload scenario.

[0032] One or more technical solutions provided in the embodiments of the present invention have at least the following technical effects or advantages:

[0033] The method and device provided in the embodiment of the present application only require one electronic tender document to be provided on site, and multiple tender document project data are generated through a stored procedure and inserted into a database. At the same time, tender documents are automatically generated in batches based on project information and saved in different file directories in pieces, and parameterized data files are generated for stress testing script execution. The present invention improves the efficiency of tender document production, greatly shortens labor time, and reduces costs. In addition, the invention is also flexible and can implement stress testing execution for upload scenarios of tender documents of different sizes.

[0034] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The present invention will be further described below in conjunction with embodiments with reference to the accompanying drawings.

[0036] Figure 1 is a flow chart of the method in Embodiment 1 of the present invention;

[0037] Figure 2 It is a schematic diagram of the structure of the device in the second embodiment of the present invention. DETAILED DESCRIPTION

[0038] The technical solution in the embodiment of the present application has the following general idea:

[0039] According to the bidding documents provided by the project site (the file size will be customized according to the actual content), execute the SQL stored procedure based on the data in the file, batch create bidding project data and insert it into the database, the purpose of which is to find the corresponding project data information for subsequent bidding uploads. Batch create bidding documents and split them into pieces, each file is 2M in size and stored in different file directories. Execute the successfully debugged performance script file to simulate the bidding upload scenario for performance stress testing, and all test results will be recorded in detail. After completing the above process, all bidding documents and related data in the database will be safely deleted.

[0040] 1. Provide bidding documents

[0041] Manually create an electronic tender document file through our self-developed tender document client tool to ensure that the size of the tender document file can be flexibly adjusted. This step is a necessary prerequisite. Take the size of the manually created electronic tender document file as the prototype and batch generate tender documents with the same file size.

[0042] 2. Create bid project data in batches

[0043] The project data of multiple bids is inserted into the database by executing stored procedures, with the aim of finding the corresponding project information for subsequent bid uploads.

[0044] a) Prepare project site data, accurately match the provided SQL script with the scenario to be tested, and insert the corresponding data into the specified database. It is worth noting that all replication operations are completed through stored procedures. After the data is successfully inserted, the corresponding stored procedure can be viewed through the function column of the database system to confirm the integrity and accuracy of the data;

[0045] b) First find the manually entered source data and record the corresponding project ID, i.e. projectId;

[0046] c) Open the corresponding stored procedure and execute the operation. During the execution, fill the manually entered source data item ID into the specified position. When the same copy data script needs to be used in different scenarios, in order to distinguish the data of different scenarios copied by the script, it is recommended to adjust the name of each item appropriately to ensure that the source of the data and the usage scenario can be clearly distinguished;

[0047] d) When executing a stored procedure, num represents the number of data items to be copied, and target_project_ids is the project ID of the corresponding source data. For example, if you want to copy and generate 50 projects, enter 50 in num and the source data project ID in target_project_ids and execute the procedure; after execution, 50 data items with different projectIds (project IDs) will be generated.

[0048] e) When preparing data for the bid upload scenario, you need to provide the projectId (project ID) and bidForld (bid ID) values ​​generated by the stored procedure. These values ​​will serve as the data basis for the subsequent batch creation of bid documents. The projectId is a randomly generated value with a fixed number of digits; the bidForld is a randomly generated value with a fixed number of digits; and bidForld corresponds to projectId one by one;

[0049] 3. Automatically generate multiple tender documents

[0050] In the system program, different project bid documents are verified by checking the three values ​​of projectId, bidForld and bidForIdHash in the keyinfo.ini file of each bid document. The function of generating bid documents and saving them in different file directories also generates parameterized data files for the stress test script to execute. Specific steps:

[0051] 1) For example, insert 100 bidding project data into the database and generate 100 bidding documents (for each bidding document, the three values ​​of projectId, bidForld and bidForIdHash in the keyinfo.ini file need to be replaced);

[0052] Note: The bidForldHash value is the bidForld value followed by 20, which is encrypted with md5. Then copy and replace the encrypted 32-digit lowercase characters.

[0053] 2) Split the bid into 2M pieces and place them in different file directories with projectId (project ID) values ​​as names.

[0054] 3) Automatically generate CSV files to provide parameterized files for subsequent stress testing.

[0055] By generating multiple bid documents and storing them in different file directories, and at the same time generating parameterized files (i.e. CSV files) for subsequent stress testing execution:

[0056] Command execution: Generate bid documents and place them in different file directories;

[0057] Generate a parameterized file (CSV file) for subsequent stress testing execution.

[0058] 4. Verify the throughput of the bid upload interface

[0059] Based on the generated parameterized files and segmented bidding document data, a performance test is performed to verify the interface throughput of the bidding document upload scenario. The interface throughput is compared with the number of electronic bidding document files that need to be uploaded. If the requirements are met, no processing is performed. If the requirements are not met, resources are adjusted so that the interface throughput meets the upload requirements. For example, if 300 bidding document files are uploaded and the throughput is insufficient or there is a problem with the service resources, the problem needs to be solved by expanding resources or optimizing the program.

[0060] 5. Data cleaning

[0061] After uploading the bid, if you need to repeatedly use the batch-created bid data for stress testing, you can clear the corresponding data as follows according to projectld (project ID) and then upload it again. For example, if you create 300 bid data and upload 300 data for stress testing, if you want to perform stress testing on 100 data again, you can clear the 100 data and perform stress testing again, or add 100 data again through the automation tool. Both methods are acceptable.

[0062] --Clear the uploaded bid data (the following script modifies project_name using the date+scenario method when copying data. If the data is not modified when copied, the corresponding data in these three tables needs to be distinguished separately).

[0063] DELETE from gpx__bid.bid_supplier file WHERE PROJECT._ID in(SELECT IDfrom gpe_bidopening.bid_open_projectWHERE PROJECT__NAME like*%1108Bid document upload%');

[0064] DELETE from gpe_bidopening.bid_open_file WHERE PROJECT_ID in(SELECTID from gpe_bidopening.bid_open_projectWHERE PROJECT._NAME like*%1108Bid document upload%');

[0065] DELETE from gpe_bidopening.bid_open_decryption_file WHERE PROJECT_IDin(SELECT ID from gpe_bidopening bid_open_projectWHEREPROJECT_NAME like '%1108Bid document upload%').

[0066] Embodiment 1

[0067] like Figure 1 As shown, this embodiment provides a stress testing method based on automatic rapid generation of tender documents, including:

[0068] Step 1: Create an electronic tender document file so that the size of the electronic tender document file is adjusted according to set requirements;

[0069] Step 2: Enter at least one piece of project data of the electronic bidding document into the database, and generate at least one piece of stress testing project data by executing the stored procedure based on the entered project data;

[0070] Step 3: Generate at least one electronic tender document file and use the corresponding stress test project data to verify different project tender documents by checking the three values ​​of projectId, bidForld and bidForIdHash in the keyinfo.ini file of each electronic tender document file; save each electronic tender document file in different file directories, and generate parameterized data files for stress test script execution;

[0071] Step 4: Perform performance testing based on the parameterized file and the sharded bid data to verify the interface throughput of the bid upload scenario.

[0072] In this embodiment, preferably, the step 2 is specifically:

[0073] Prepare project site data, match the provided SQL scripts with the scenarios to be tested, and enter the corresponding data into the designated database;

[0074] According to the entered project data, at least one stress testing project data is generated by executing the stored procedure. Each stress testing project data corresponds to a project ID, that is, projectId; and the project ID is filled in the specified position.

[0075] In this embodiment, preferably, step 3 is specifically:

[0076] Generate a set number of electronic tender documents as required, set corresponding stress test project data for each electronic tender document, and the keyinfo.ini file of each electronic tender document includes: projectId, bidForld and bidForIdHash; bidForld is the bidding ID;

[0077] Each electronic tender document file is segmented according to the set size, stored in a folder with projectId as the folder name, and a parameterized file is generated.

[0078] In this embodiment, preferably, the bidForldHash is a combination of bidForld followed by 20, and then after md5 encryption, the encrypted 32-digit lowercase is copied and replaced.

[0079] Based on the same inventive concept, the present application also provides a device corresponding to the method in Example 1, see Example 2 for details.

[0080] Embodiment 2

[0081] like Figure 2 As shown, in this embodiment, a stress testing device based on automatic rapid tender document generation is provided, including:

[0082] Creating a file module to create an electronic tender document file so that the size of the electronic tender document file is adjusted according to set requirements;

[0083] Create a data module, enter at least one piece of project data of the electronic bidding document into the database, and generate at least one piece of stress testing project data by executing the stored procedure based on the entered project data;

[0084] Generate stress test file module, generate at least one electronic bid document file and use the corresponding stress test project data, verify different project bid documents by checking the three values ​​of projectId, bidForld and bidForIdHash in the keyinfo.ini file of each electronic bid document file; save each electronic bid document file in different file directories, and generate parameterized data files for stress test script execution;

[0085] The stress test upload module performs performance testing based on the parameterized file and the sharded bid data to verify the interface throughput of the bid upload scenario.

[0086] In this embodiment, preferably, the production data module is specifically:

[0087] Prepare project site data, match the provided SQL scripts with the scenarios to be tested, and enter the corresponding data into the designated database;

[0088] According to the entered project data, at least one stress testing project data is generated by executing the stored procedure. Each stress testing project data corresponds to a project ID, that is, projectId; and the project ID is filled in the specified position.

[0089] In this embodiment, preferably, the module for generating a stress test file is specifically:

[0090] Generate a set number of electronic tender documents as required, set corresponding stress test project data for each electronic tender document, and the keyinfo.ini file of each electronic tender document includes: projectId, bidForld and bidForIdHash; bidForld is the bidding ID;

[0091] Each electronic tender document file is segmented according to the set size, stored in a folder with projectId as the folder name, and a parameterized file is generated.

[0092] In this embodiment, preferably, the bidForldHash is a combination of bidForld followed by 20, and then after md5 encryption, the encrypted 32-digit lowercase is copied and replaced.

[0093] Since the device introduced in the second embodiment of the present invention is a device used to implement the method of the first embodiment of the present invention, those skilled in the art can understand the specific structure and deformation of the device based on the method introduced in the first embodiment of the present invention, so it is not described here in detail. All devices used in the method of the first embodiment of the present invention belong to the scope of protection of the present invention.

[0094] Although the specific implementation modes of the present invention are described above, those skilled in the art should understand that the specific implementation modes described are only illustrative and are not intended to limit the scope of the present invention. Equivalent modifications and changes made by those skilled in the art in accordance with the spirit of the present invention should be included in the scope of protection of the claims of the present invention.

Claims

1. A stress testing method based on automated rapid tender document generation, characterized in that: include: Step 1: Create an electronic tender document file so that the size of the electronic tender document file is adjusted according to set requirements; Step 2: Enter at least one piece of project data of the electronic bidding document into the database, and generate at least one piece of stress testing project data by executing the stored procedure based on the entered project data; Step 3: Generate at least one electronic bidding document and use the corresponding stress test project data to verify different project bidding documents by checking the three values ​​of projectId, bidForld and bidForIdHash in the keyinfo.ini file of each electronic bidding document; Each electronic tender document file is divided into pieces and saved in different file directories, and parameterized data files are generated for the execution of stress testing scripts; Step 4: Perform performance testing based on the parameterized file and the sharded bid data to verify the interface throughput for the bid upload scenario.

2. A stress testing method based on automated rapid tender document generation according to claim 1, characterized in that: The step 2 is specifically as follows: Prepare project site data, match the provided SQL scripts with the scenarios to be tested, and enter the corresponding data into the designated database; According to the entered project data, at least one stress testing project data is generated by executing the stored procedure. Each stress testing project data corresponds to a project ID, that is, projectId; and the project ID is filled in the specified position.

3. The stress testing method based on automated rapid tender document generation according to claim 1, characterized in that: The step 3 is specifically as follows: Generate a set number of electronic tender documents as required, set corresponding stress test project data for each electronic tender document, and the keyinfo.ini file of each electronic tender document includes: projectId, bidForld and bidForIdHash; bidForld is the bidding ID; Each electronic tender document file is segmented according to the set size, stored in a folder with projectId as the folder name, and a parameterized file is generated.

4. The stress testing method based on automated rapid tender document generation according to claim 3 is characterized in that: The bidForldHash is a combination of bidForld followed by 20, which is then encrypted with md5 and the encrypted 32-digit lowercase characters are copied and replaced.

5. A stress testing device based on automated rapid tender document generation, characterized in that: include: Create a file module to create an electronic tender document file so that the size of the electronic tender document file is adjusted according to set requirements; Create a data module, enter at least one piece of project data of the electronic bidding document into the database, and generate at least one piece of stress testing project data by executing the stored procedure based on the entered project data; Generate stress test file module, generate at least one electronic bidding document file and use the corresponding stress test project data to verify different project bidding documents by checking the three values ​​of projectId, bidForld and bidForIdHash in the keyinfo.ini file of each electronic bidding document file; Each electronic tender document file is divided into pieces and saved in different file directories, and parameterized data files are generated for the execution of stress testing scripts; The stress test upload module performs performance testing based on the parameterized file and the sharded bid data to verify the interface throughput of the bid upload scenario.

6. A stress testing device based on automated rapid tender document generation according to claim 5, characterized in that: The production data module is specifically: Prepare project site data, match the provided SQL scripts with the scenarios to be tested, and enter the corresponding data into the designated database; According to the entered project data, at least one stress testing project data is generated by executing the stored procedure. Each stress testing project data corresponds to a project ID, that is, projectId; and the project ID is filled in the specified position.

7. The stress testing device based on automated rapid tender document generation according to claim 5, characterized in that: The module for generating stress test files is specifically: Generate a set number of electronic tender documents as required, set corresponding stress test project data for each electronic tender document, and the keyinfo.ini file of each electronic tender document includes: projectId, bidForld and bidForIdHash; bidForld is the bidding ID; Each electronic tender document file is segmented according to the set size, stored in a folder with projectId as the folder name, and a parameterized file is generated.

8. A stress testing device based on automated rapid tender document generation according to claim 7, characterized in that: The bidForldHash is a combination of bidForld followed by 20, which is then encrypted with md5 and the encrypted 32-digit lowercase characters are copied and replaced.

Images