Data-driven Evidence Preservation Service Testing Method and System

Abstract

The present invention provides a data-driven method and system for testing deposit and certification services, including: Step 1: encapsulate interface functions through the interface testing framework Rest-Assured; Step 2: generate test cases through the unit testing framework Junit5, mark them through deposit tags and query tags, and use the interface functions in the test cases; Step 3: set a test data generation function and associate it with the test cases; Step 4: set operation parameters and execute the test cases to obtain test results. By using the call query serial number and the original text written into a file as query parameters, the present invention makes each deposit and query related to each other, closes the deposit and certification process loop, uses data-driven for the entire test process, automatically generates all test data, greatly improves the test efficiency, saves test time, and cooperates with continuous integration, so that the execution of tests does not require manual intervention.

Description

Technical Field

[0001] The present invention relates to the technical field of evidence storage service testing, and in particular, to a data-driven evidence storage service testing method and system. Background Art

[0002] At present, there is no unified interface for the upward operation interfaces of driving software among various products. For example, for products MD5500 and ESR, they use similar FLASH chips and basically the same functions, but the interfaces of the driving software are very different, and the number and positions of interface parameters are not the same.

[0003] When implementing the test design of driving software, since the functions completed by the objects to be tested are basically fixed (such as sending data, receiving data, configuration, verification, loopback, etc.), reuse can be basically achieved at the test plan level. However, due to the different interfaces provided by different driving software, reuse cannot be achieved in terms of test items, test cases, test scripts, test codes and other test pieces.

[0004] Correspondingly, every time testers receive a new test task for driving software, they need to re-perform test design and test implementation; and during the test execution process, due to design and implementation defects, test design and test implementation often need to be modified.

[0005] Patent document CN101158919A (application number: CN200710176970.7) discloses a data-driven unit test method, which includes the following steps: A. Write a data file for unit testing, and the data file includes a configuration data file and a message data file; B. Construct a driving function and a stub function according to the data file; C. Organize and execute test cases according to the data file, driving function and stub function. This patent realizes reading configuration and parameters from a file, generating test cases with the file constructor and stub function and executing them. However, there is no association between each use case, and it cannot well support the evidence storage system. Summary of the Invention

[0006] Aiming at the defects in the prior art, the purpose of the present invention is to provide a data-driven evidence storage service testing method and system.

[0007] According to the data-driven evidence storage service testing method provided by the present invention, it includes:

[0008] Step 1: Package interface functions through the interface testing framework Rest-Assured;

[0009] Step 2: Generate test cases through the unit testing framework Junit5, mark them through storing tags and querying tags, and use interface functions in the test cases;

[0010] Step 3: Set up the test data generation function and associate it with the test case;

[0011] Step 4: Set the running parameters, execute the test case, and obtain the test result.

[0012] Preferably, the said Step 1 includes: encapsulating, based on the Rest-Assured framework, the http interface functions that support submitting data to be processed to a specified resource and requesting data from a specified resource. The http interface functions receive parameters of map and String types, put the map-type parameters into the body or parameters of the request, use the String-type parameters as the resource locator of the request, and return the test execution result through the http interface functions.

[0013] Preferably, the said Step 2 includes:

[0014] Step 2.1: Write the deposit and query test cases based on the unit test framework Junit5, label each test case, and mark it as the deposit type or the query type;

[0015] Step 2.2: Through the deposit case, finally perform the file writing operation, and write the query serial number and the original parameter in the deposit result into the specified file;

[0016] Step 2.3: Through the query case, read the specified file, read the original text and the query serial number from the file, and compare the query result with the original text;

[0017] Step 2.4: Print the input parameters and the execution result in each test case;

[0018] Step 2.5: Associate each test case with a test data generation function;

[0019] Step 2.6: For each test case, read the configuration file to obtain the request address.

[0020] Preferably, the said Step 3 includes:

[0021] Step 3.1: Through the data generation function, read the parameter file to obtain the private key and the credential information;

[0022] Step 3.2: Associate with the deposit case, generate the deposit original text as needed, add a timestamp, and sign it with the private key;

[0023] Step 3.3: Associate with the query case, read the specified file as needed, obtain the query serial number and the original parameter, read the parameter, sign it with the private key, and add a timestamp.

[0024] Preferably, the said Step 4 includes:

[0025] Step 4.1: Write the parameters required for operation, the user's private key, the request path, and the host address information into the configuration file;

[0026] Step 4.2: Parse the configuration file to obtain the configuration information;

[0027] Step 4.3: First execute the storage use case to obtain the query serial number, and then execute the query use case;

[0028] Step 4.4: Configure the integration tool Jenkins task to execute the certification test according to the pre-designed plan;

[0029] Step 4.5: Introduce the test project into the result visualization dependency test report to automatically generate allure, and view the test results through html.

[0030] According to the data-driven certification service test system provided by the present invention, it includes:

[0031] Module M1: Encapsulate interface functions through the interface test framework Rest-Assured;

[0032] Module M2: Generate test cases through the unit test framework Junit5, mark them with storage tags and query tags, and use interface functions in the test cases;

[0033] Module M3: Set the test data generation function and associate it with the test cases;

[0034] Module M4: Set the operation parameters and execute the test cases to obtain the test results.

[0035] Preferably, the module M1 includes: encapsulating http interface functions based on the Rest-Assured framework to support submitting data to be processed to the specified resource and requesting data from the specified resource. The http interface function receives parameters of map and String types, puts the map type parameters into the body or parameters of the request, uses the String type parameter as the resource locator of the request, and returns the test execution result through the http interface function.

[0036] Preferably, the module M2 includes:

[0037] Module M2.1: Write storage and query test cases based on the unit test framework Junit5, label each test case, and mark it as storage type or query type;

[0038] Module M2.2: Finally execute the write file operation through the storage use case, and write the query serial number and the original parameters in the storage result into the specified file;

[0039] Module M2.3: Read the specified file by referring to the test cases, read the original text and query serial number from the file, and compare the query result with the original text;

[0040] Module M2.4: Print the input parameters and execution results in each test case;

[0041] Module M2.5: Associate each test case with a test data generation function;

[0042] Module M2.6: Read the configuration file for each test case to obtain the request address.

[0043] Preferably, the module M3 includes:

[0044] Module M3.1: Read the parameter file through the data generation function to obtain the private key and certificate information;

[0045] Module M3.2: It is necessary to generate the original text for the deposit certificate when associating with the deposit case, stamp the timestamp, and sign with the private key;

[0046] Module M3.3: When associating with the query case, it is necessary to read the specified file, obtain the query serial number and the original text of the parameter, sign the read parameter with the private key, and stamp the timestamp.

[0047] Preferably, the module M4 includes:

[0048] Module M4.1: Write the parameters required for operation, the user's private key, the request path, and the host address information into the configuration file;

[0049] Module M4.2: Parse the configuration file to obtain the configuration information;

[0050] Module M4.3: First execute the deposit case to obtain the query serial number, and then execute the query case;

[0051] Module M4.4: Configure the integration tool Jenkins task to execute the deposit certificate test according to the pre-designed plan;

[0052] Module M4.5: Introduce the test project into the result visualization, depend on the test report to automatically generate allure, and view the test results through html.

[0053] Compared with the prior art, the present invention has the following beneficial effects:

[0054] (1) By writing the called query serial number and the original text into the file as query parameters, the deposit and query are associated with each other every time, the deposit certificate process is closed-loop, the entire test process uses data-driven, all test data is automatically generated, stamped with a timestamp, and signed, greatly improving the test efficiency, saving test time, and cooperating with continuous integration, the execution of the test does not require manual intervention;

[0055] (2) The test cases are distinguished by storage and query. First query and then store, which conforms to the characteristics of the evidence storage service and provides guarantee for the evidence storage service;

[0056] (3) The running configuration is read from a file, which is easy to modify, supports switching user credentials, and can support multiple environments;

[0057] (4) Introduce the dependency of result visualization, view through html, and the results are obvious at a glance. Description of the Drawings

[0058] Other features, objects, and advantages of the present invention will become more apparent by reading the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0059] Figure 1 It is a flowchart of the evidence storage service test method of the present invention;

[0060] Figure 2 It is a flowchart of the storage use case of the present invention;

[0061] Figure 3 It is a flowchart of the query use case of the present invention. Detailed Embodiments

[0062] The present invention will be described in detail below with reference to specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but do not limit the present invention in any form. It should be noted that those of ordinary skill in the art can make several changes and improvements without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0063] Embodiment:

[0064] The present invention provides a data-driven evidence storage service test method, which generates evidence storage service test data, automatically stores it in the evidence storage system, and then queries and verifies the results, improving the test efficiency of the evidence storage system.

[0065] Such as Figures 1 to 3 , specifically including the following steps:

[0066] Step 1: Package the interface function with Rest-Assured;

[0067] Step 1.1: Package the http interface function that supports the post and get methods based on the Rest-Assured framework. The interface function receives parameters of map and String types. The map is placed in the body or param of the request as a parameter, and the String is the request url. The function finally returns the execution result.

[0068] Step 2: Prepare test cases with Junit5, mark them with storage tags and query tags, and use the interface function in the test cases;

[0069] Step 2.1: Write the deposit and query test cases based on Junit5, tag each test case, and label it as the deposit type or query type;

[0070] Step 2.2: The deposit use case finally performs the file writing operation, and writes the query serial number and the original parameter in the deposit result into the specified file;

[0071] Step 2.3: The query use case reads the specified file, reads the original text and the query serial number from the file, and compares the query result with the original text;

[0072] Step 2.4: Print the input parameters and the execution results in each test case;

[0073] Step 2.5: Each test case is associated with a test data generation function;

[0074] Step 2.6: Each test case reads the configuration file to obtain the request address.

[0075] Step 3: Prepare the test data generation function and associate it with the test cases;

[0076] Step 3.1: The data generation function reads the parameter file to obtain the private key and the credential information;

[0077] Step 3.2: To be associated with the deposit use case, it is necessary to generate the original deposit text, add a timestamp, and sign it with the private key;

[0078] Step 3.3: To be associated with the query use case, it is necessary to read the specified file, obtain the query serial number and the original parameter, read the parameter, sign it with the private key, and add a timestamp.

[0079] Step 4: Set the running parameters and execute the test cases;

[0080] Step 4.1: Write the parameters required for running, the user's private key, the request path, and the host address information into the configuration file;

[0081] Step 4.2: Parse the configuration file to obtain the configuration information;

[0082] Step 4.3: First execute the deposit use case to obtain the query serial number;

[0083] Step 4.4: Then execute the query use case;

[0084] Step 4.5: Configure the Jenkins task to execute the deposit test according to the plan

[0085] Step 5: Generate a report;

[0086] Step 5.1: The test project introduces the result visualization dependency allure;

[0087] Step 5.2: View the test results through html.

[0088] According to the data-driven evidence storage service test system provided by the present invention, it includes: Module M1: encapsulate interface functions through the interface test framework Rest-Assured; Module M2: generate test cases through the unit test framework Junit5, mark them through storage tags and query tags, and use interface functions in the test cases; Module M3: set a test data generation function and associate it with the test cases; Module M4: set operation parameters and execute the test cases to obtain test results.

[0089] The Module M1 includes: encapsulating an http interface function based on the Rest-Assured framework to support submitting data to be processed to a specified resource and requesting data from a specified resource. The http interface function receives parameters of map and String types, puts the map-type parameter into the body or parameters of the request, uses the String-type parameter as the resource locator of the request, and returns the test execution result through the http interface function.

[0090] The Module M2 includes: Module M2.1: write evidence storage and query test cases based on the unit test framework Junit5, label each test case, and mark it as a storage type or a query type; Module M2.2: perform a write file operation through the storage use case at the end of execution, and write the query serial number and the original parameter in the storage result into a specified file; Module M2.3: read the specified file through the query use case, read the original text and the query serial number from the file, and compare the query result with the original text; Module M2.4: print the input parameters and the execution result in each test case; Module M2.5: associate each test case with a test data generation function; Module M2.6: read the configuration file for each test case to obtain the request address.

[0091] The Module M3 includes: Module M3.1: read the parameter file through the data generation function to obtain the private key and credential information; Module M3.2: associate with the storage use case to generate the original evidence storage, add a timestamp, and sign it with the private key; Module M3.3: associate with the query use case to read the specified file, obtain the query serial number and the original parameter, read the parameter, sign it with the private key, and add a timestamp.

[0092] The module M4 includes: Module M4.1: Write the parameters required for operation, the user's private key, the request path, and the host address information into the configuration file; Module M4.2: Parse the configuration file to obtain the configuration information; Module M4.3: First execute the storage use case to obtain the query serial number, and then execute the query use case; Module M4.4: Configure the integration tool Jenkins task to execute the evidence storage test according to the pre-designed plan; Module M4.5: Introduce the test project into the result visualization, depend on the test report to automatically generate allure, and view the test results through html.

[0093] Those skilled in the art know that in addition to implementing the system, device, and its various modules provided by the present invention in the form of pure computer-readable program code, the method steps can be logically programmed to enable the system, device, and its various modules provided by the present invention to be in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers to implement the same program. Therefore, the system, device, and its various modules provided by the present invention can be regarded as a kind of hardware component, and the modules included therein for implementing various programs can also be regarded as the structure within the hardware component; the modules for implementing various functions can also be regarded as either software programs for implementing the method or the structure within the hardware component.

[0094] The specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. Without conflict, the embodiments of the present application and the features in the embodiments can be combined arbitrarily.

Claims

1. A data-driven evidence storage service testing method, characterized in that, it includes: Step 1: Encapsulate interface functions through the interface testing framework Rest-Assured; Step 2: Generate test cases through the unit testing framework Junit5, mark them with storage tags and query tags, and use the interface functions in the test cases; Step 3: Set up a test data generation function and associate it with the test cases; Step 4: Set running parameters and execute the test cases to obtain test results; The said Step 1 includes: Based on the Rest-Assured framework, encapsulate http interface functions that support submitting data to be processed to a specified resource and requesting data from a specified resource. The http interface functions receive parameters of map and String types, put the map-type parameters into the body or parameters of the request, use the String-type parameters as the resource locator of the request, and return the test execution results through the http interface functions; The said Step 2 includes: Step 2.1: Write evidence storage and query test cases based on the unit testing framework Junit5, label each test case, and mark it as a storage type or a query type; Step 2.2: Perform a write file operation through the storage use case at the end, and write the query serial number and the original parameter in the storage result into a specified file; Step 2.3: Read the specified file through the query use case, read the original text and the query serial number from the file, and compare the query result with the original text; Step 2.4: Print the input parameters and execution results in each test case; Step 2.5: Associate each test case with a test data generation function; Step 2.6: Read the configuration file for each test case to obtain the request address; The said Step 3 includes: Step 3.1: Read the parameter file through the data generation function to obtain the private key and credential information; Step 3.2: Associate with the storage use case to generate the original evidence storage, add a timestamp, and sign it with the private key; Step 3.3: Associate with the query use case to read the specified file, obtain the query serial number and the original parameter, read the parameter, sign it with the private key, and add a timestamp; The said Step 4 includes: Step 4.1: Write the parameters required for running, the user's private key, the request path, and the host address information into the configuration file; Step 4.2: Parse the configuration file to obtain the configuration information; Step 4.3: First execute the storage use case to obtain the query serial number, and then execute the query use case; Step 4.4: Configure the integration tool Jenkins task to execute the evidence storage test according to the pre-designed plan; Step 4.5: Introduce the test project into the result visualization, depend on the test report to automatically generate allure, and view the test results through html.

2. A data-driven evidence storage service testing system, characterized in that, it includes: Module M1: Encapsulate interface functions through the interface testing framework Rest-Assured; Module M2: Generate test cases through the unit testing framework Junit5, mark them with storage tags and query tags, and use the interface functions in the test cases; Module M3: Set up a test data generation function and associate it with the test cases; Module M4: Set the running parameters, execute the test cases, and obtain the test results; The module M1 includes: encapsulating http interface functions based on the Rest-Assured framework to support submitting data to be processed and requesting data from specified resources. The http interface functions receive parameters of map and String types, put the map-type parameters into the body or parameters of the request, use the String-type parameters as the resource locator of the request, and return the test execution results through the http interface functions; The module M2 includes: Module M2.1: Write the deposit and query test cases based on the unit test framework Junit5, and label each test case as a deposit type or a query type; Module M2.2: Finally, perform a write file operation through the deposit use case, and write the query serial number and the original parameter in the deposit result into a specified file; Module M2.3: Read the specified file through the query use case, read the original text and the query serial number from the file, and compare the query result with the original text; Module M2.4: Print the input parameters and execution results in each test case; Module M2.5: Associate each test case with a test data generation function; Module M2.6: Read the configuration file for each test case to obtain the request address; The module M3 includes: Module M3.1: Read the parameter file through the data generation function to obtain the private key and credential information; Module M3.2: Associated with the deposit use case, it is necessary to generate the deposit original text, add a timestamp, and sign with the private key; Module M3.3: Associated with the query use case, it is necessary to read the specified file, obtain the query serial number and the original parameter, read the parameter, sign with the private key, and add a timestamp; The module M4 includes: Module M4.1: Write the parameters required for running, the user's private key, the request path, and the host address information into the configuration file; Module M4.2: Parse the configuration file to obtain the configuration information; Module M4.3: First execute the deposit use case to obtain the query serial number, and then execute the query use case; Module M4.4: Configure the integrated tool Jenkins task to execute the deposit test according to the pre-designed plan; Module M4.5: Introduce the test project into the result visualization, depend on the test report to automatically generate allure, and view the test results through html.

Images