A dmdis automated testing method and apparatus

Abstract

The application provides a DMDIS automatic testing method and device, and belongs to the technical field of automatic testing, which comprises the following steps: synchronizing test cases and mirror processes to a DMDIS process to be tested based on a test engine process; generating a disguised HTTP request based on the test engine process, instructing the DMDIS process to be tested to start the test cases and the mirror processes based on the disguised HTTP request, generating test case execution results, and storing the test case execution results; wherein the mirror processes are used to check whether the output of the test cases is the expected output. The application can realize the direct starting of the test cases and the mirror processes by program codes through the generation of the disguised HTTP request, and can check whether the output of the test cases is the expected output through the mirror processes in the testing process, so that manual checking or judgment of the test cases is not needed, and the automation degree and the testing efficiency of the DMDIS automatic testing are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of automation testing technology, in particular to a DMDIS automation testing method and device. BACKGROUND

[0002] DMDIS is a tool for data extraction, conversion and loading of relational databases and non-relational databases, structured data and unstructured data. When testing DMDIS, the three points are mainly tested. Therefore, a large number of test cases in the test work are ultimately developed around the three points. In the actual test process, the dependent relationship of the three components is drawn in a test process, and the running instruction of the test process is issued to DMDIS through the browser interface. After DMDIS learns the instruction, the loading component will read data from the data source entity as input, the data flows through the conversion component and is processed into the data format required by the user and adapted to the data source entity referenced by the loading component, and finally stored in the target data source entity by the loading component.

[0003] The DMDIS testing method in the prior art is to issue a test instruction to the browser by the test personnel, and then test based on the test instruction. Moreover, the test case execution result needs to be judged manually. With the increase of the type and quantity of DMDIS data sources, a large number of test cases are derived. Using the manual test start and manual test result confirmation method in the prior art will result in low automation degree of DMDIS testing, and thus low test efficiency.

[0004] Therefore, it is necessary to provide a DMDIS automation testing method and device to improve the automation degree of DMDIS testing and improve the test efficiency. SUMMARY

[0005] Therefore, it is necessary to provide a DMDIS automation testing method and device to improve the automation degree of DMDIS testing and improve the test efficiency.

[0006] In one aspect, to solve the above technical problems, the present application provides a DMDIS automation testing method, comprising:

[0007] synchronizing test cases and mirror processes to a DMDIS process to be tested based on a test engine process;

[0008] generating a disguised HTTP request based on the test engine process, instructing the DMDIS process to be tested to start the test cases and the mirror processes based on the disguised HTTP request, generating test case execution results, and storing the test case execution results;

[0009] The mirror process is used to check whether the output of the test case is the expected output.

[0010] In a possible implementation, the test engine process synchronizes the test case and the mirror process to the DMDIS process to be tested, including:

[0011] The test engine process initiates a synchronization instruction, and when the synchronization process receives the synchronization instruction, the test case and the mirror process in the baseline library process are synchronized to the DMDIS process to be tested.

[0012] In a possible implementation, the test engine process generates a disguised HTTP request based on the test case, including:

[0013] Obtaining a test case ID and a basic URL address of the test case;

[0014] Splicing the test case ID and the basic URL address to generate a unique URL;

[0015] Generating the disguised HTTP request instruction based on the unique URL.

[0016] In a possible implementation, the test engine process generates the disguised HTTP request instruction based on the unique URL, including:

[0017] Simulating login to the DMDIS process to be tested by using selenium;

[0018] Obtaining a login session returned after the DMDIS process to be tested is successfully logged in;

[0019] Obtaining a login token in the login session and splicing the login token to a request header;

[0020] Generating the disguised HTTP request instruction based on the request header and the unique URL.

[0021] In a possible implementation, the DMDIS process to be tested starts the test case and the mirror process based on the disguised HTTP request instruction, and generates a test case execution result, including:

[0022] Starting the test case based on the disguised HTTP request instruction, and determining whether the test case is executed successfully;

[0023] When the test case is executed successfully, starting the mirror process, and generating the test case execution result based on the mirror process.

[0024] In a possible implementation, the determination of whether the test case is executed successfully includes:

[0025] continuously query the execution status of the test case based on the execution ID of the test case; the execution status comprises a waiting state, a canceling state, a success state and a failure state;

[0026] determine whether the execution status is changed to the success state within a preset time, and if yes, the test case is executed successfully.

[0027] In a possible implementation, the storing of the test case execution result comprises:

[0028] storing the test case execution result in a preset data structure in the memory of the test engine process;

[0029] calling an xlwt module of Python, writing the test case execution result into a table, generating a result table, and sending the result table to an FTP server for archiving.

[0030] In a possible implementation, the test engine process comprises a first test engine process and a second test engine process, and the DMDIS automatic test method further comprises:

[0031] before the first test engine process starts the test case, determining whether the test case is used by the second test engine process based on a global case lock record table;

[0032] when the test case is not used by the second test engine process, starting and executing the test case by the first test engine process;

[0033] when the first test engine process executes the test case, adding the test case to the global case lock record table, and when the first test engine process finishes executing the test case, deleting the test case from the global case lock record table.

[0034] In a possible implementation, before the test engine process synchronizes the test case and the mirror process to the DMDIS process to be tested, the method comprises:

[0035] based on a plurality of preset scheduling times in a Jenkins continuous integration process, calling and starting the test engine process at each preset scheduling time.

[0036] In another aspect, the present application further provides a DMDIS automatic test device, comprising:

[0037] a synchronization unit configured to synchronize a test case and a mirror process to a DMDIS process to be tested based on a test engine process;

[0038] The automatic test unit is used for generating a disguised HTTP request based on the test engine process, instructing the DMDIS process to be tested to start the test case and the mirror process based on the disguised HTTP request, generating a test case execution result, and storing the test case execution result.

[0039] The mirror process is used for checking whether the output of the test case is an expected output.

[0040] The DMDIS automatic test method provided by the application can realize the direct starting of the test case and the mirror process through program codes, without the participation of testers, improves the automation degree of the DMDIS automatic test, and improves the test efficiency of the DMDIS.

[0041] Further, the mirror process is also started in the test process of the test case, the output of the test case can be checked through the mirror process, whether the output is an expected output, without the manual checking or judging of the output of the test case by testers, the automation degree of the DMDIS automatic test is further improved, and the test efficiency of the DMDIS is further improved. DETAILED DESCRIPTION

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the application, the following will briefly introduce the drawings needed to be used in the embodiments description. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0043] Figure 1 An embodiment flowchart of the DMDIS automatic test method provided by the application is shown in the figure.

[0044] Figure 2 An embodiment schematic diagram of a typical test case provided by the application is shown in the figure.

[0045] Figure 3 An embodiment schematic diagram of a typical mirror process provided by the application is shown in the figure.

[0046] Figure 4 The application Figure 1 An embodiment flowchart of generating a disguised HTTP request in step S102 in the application is shown in the figure.

[0047] Figure 5 The application Figure 4 An embodiment flowchart of step S403 in the application is shown in the figure.

[0048] Figure 6 The applicationFigure 1 An embodiment flow chart of generating test case execution result in step S102;

[0049] Figure 7 The present application Figure 6 An embodiment flow chart of step S601;

[0050] Figure 8 The present application Figure 1 An embodiment flow chart of storing test case execution result in step S102;

[0051] Figure 9 An embodiment flow chart of applying global test case lock provided by the present application;

[0052] Figure 10 An embodiment structure diagram of DMDIS automatic test device provided by the present application;

[0053] Figure 11 An embodiment structure diagram of electronic device provided by the present application. DETAILED DESCRIPTION

[0054] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0055] It should be understood that the schematic drawings are not drawn according to the actual proportions. The flow chart used in the present application shows the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flow chart can not be implemented in sequence, and the steps without logical context relationship can be reversed in sequence or implemented simultaneously. In addition, one or more other operations can be added to the flow chart or one or more operations can be removed from the flow chart by those skilled in the art under the guidance of the content of the present application. Some block diagrams shown in the drawings are functional entities, which do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different network and / or processor systems and / or microcontroller systems.

[0056] Reference to an "embodiment" in this document means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are they necessarily mutually exclusive of one another. As will be apparent to those of ordinary skill in the art, embodiments described herein can be combined with other embodiments.

[0057] The application provides a DMDIS automatic testing method and device, which are described below respectively.

[0058] Figure 1 An embodiment flowchart of the DMDIS automatic testing method provided by the application is shown in Figure 1 The DMDIS automatic testing method comprises the following steps.

[0059] S101, synchronizing a test case and a mirror process to a DMDIS process to be tested based on a test engine process;

[0060] S102, generating a disguised HTTP request based on the test engine process, instructing the DMDIS process to be tested to start the test case and the mirror process based on the disguised HTTP request, generating a test case execution result, and storing the test case execution result;

[0061] The mirror process is used to check whether the output of the test case is the expected output.

[0062] It should be noted that, in order to improve the comprehensiveness of the DMDIS test, the test case and the mirror process should cover all basic functions of the DMDIS.

[0063] A typical test case is shown in Figure 2 The test case comprises a data reading component, a data conversion component, and a data loading component, and the data loading component comprises the expected output of the test case.

[0064] A typical mirror process is shown in Figure 3 The mirror process comprises a data comparison component, which is used to determine whether the output of the test case is consistent with the expected output, and when the output of the test case is not consistent with the expected output, the test case is recorded in a judgment table. The test engine process determines whether the test case being executed is in the judgment table. If the test case being executed is in the judgment table, it is determined whether the output of the test case is consistent with the expected output. When the output of the test case is not consistent with the expected output, it is determined that the test fails, and the test case is deleted from the judgment table. If the test case being executed is not in the judgment table, it is determined that the test passes.

[0065] The data comparison component is a member of the data conversion component.

[0066] Compared with the prior art, the DMDIS automatic test method provided by the embodiment of the application can realize direct starting of the test case and the mirror process through the program code without the participation of the test personnel, improve the automation degree of the DMDIS automatic test, and improve the test efficiency of the DMDIS.

[0067] Further, the embodiment of the application also starts the mirror process in the test process of the test case, and can check whether the output of the test case is the expected output through the mirror process, without the manual checking or judging of the output of the test case by the test personnel, further improving the automation degree of the DMDIS automatic test, and further improving the test efficiency of the DMDIS.

[0068] In some embodiments of the application, step S101 comprises:

[0069] The test engine process initiates a synchronization instruction, and when the synchronization process receives the synchronization instruction, the test case and the mirror process in the baseline library process are synchronized to the DMDIS process to be tested.

[0070] Specifically, when the synchronization process receives the synchronization instruction, the test case and the mirror process in the baseline library process are packaged to generate a data packet, and then the data packet is sent to the DMDIS to be tested, and then the data packet is unpacked to obtain the test case and the mirror process.

[0071] The DMDIS process in which the stable version of the test case and the mirror process is placed is referred to as a baseline library process.

[0072] It should be understood that the synchronization process itself has no data backup or restoration function, and what it does is to call the data backup and restoration function, data download and upload function of the DMDIS itself.

[0073] In some embodiments of the application, as shown in Figure 4 The step S102 of generating a disguised HTTP request based on the test engine process comprises:

[0074] S401, obtaining the test case ID and the basic URL address;

[0075] S402, splicing the test case ID and the basic URL address to generate a unique URL;

[0076] S403, generating a disguised HTTP request instruction based on the unique URL.

[0077] The test engine process is based on the HTTP protocol.

[0078] It should be noted that the test engine process needs to first obtain the meta information of all test cases and mirror processes, that is, the names and IDs of all test cases and mirror processes form a list, for this purpose, it needs to communicate with the baseline library process, and the meta information of the baseline library process is equivalent to the meta information of the DMDIS process to be tested; secondly, the test engine process also needs to know the request body format, which is obtained in advance by the test engineer from the DMDIS and is hard coded in the test engine process.

[0079] In some embodiments of the present application, as shown in Figure 5 Step S403 includes:

[0080] S501, selenium is used to simulate login to the DMDIS process to be tested;

[0081] S502, obtaining the login session returned after the DMDIS process to be tested is logged in successfully;

[0082] S503, obtaining the login token in the login session and concatenating the login token to the request header;

[0083] S504, generating a disguised HTTP request instruction based on the request header and the unique URL.

[0084] Wherein, selenium is a tool for simulating browser operation. The browser in the embodiment of the present application is Chrome browser.

[0085] It should be noted that step S504 specifically uses the requests network communication module of Python to carry the request header and send an HTTP request instruction to the DMDIS process to be tested with a unique URL.

[0086] It should be further noted that after receiving the HTTP request instruction, the DMDIS process to be tested will allocate an execution ID (executeId) for the current test case and return the execution ID to the test engine process.

[0087] Then only the execution ID needs to be stored in the judgment table, and whether the test case passes the test is determined by the execution ID.

[0088] Since the mirror process is to compare the output of the test case with the expected output, that is, the output obtained based on the test case execution, in order to avoid invalid execution of the mirror process, in some embodiments of the present application, as shown in Figure 6 The step S102 of starting the test case and the mirror process based on the disguised HTTP request instruction to the DMDIS process to be tested generates a test case execution result, which includes:

[0089] S601, based on the camouflage HTTP request instruction, the DMDIS process to be tested starts a test case, and it is judged whether the test case is executed successfully;

[0090] S602, when the test case is executed successfully, an image process is started, and a test case execution result is generated based on the image process.

[0091] The embodiment of the application starts the image process only when it is judged that the test case is executed successfully, avoids invalid start of the image process, and reduces the load in the DMDIS automatic test process.

[0092] It should be noted that if the image process fails, the test result of the test case is directly determined as a failure.

[0093] In some embodiments of the application, as shown in Figure 7 The judgment of whether the test case is executed successfully in step S601 comprises:

[0094] S701, based on the execution ID of the test case, the execution state of the test case is continuously queried; the execution state comprises a waiting state, a cancellation state, a success state and a failure state;

[0095] S702, it is judged whether the execution state is changed to the success state within a preset time, and if yes, the test case is executed successfully.

[0096] The embodiment of the application confirms whether the test case is executed successfully through two-dimensional parameters of time and state, improves the timeliness and efficiency of the DMDIS automatic test.

[0097] In some embodiments of the application, as shown in Figure 8 The storage of the test case execution result in step S102 comprises:

[0098] S801, the test case execution result is stored in the memory of the test engine process in a preset data structure;

[0099] S802, the xlwt module of Python is called, the test case execution result is written into a table, a result table is generated, and the result table is sent to an FTP server for archiving.

[0100] The embodiment of the application integrates the test case execution result into an Excel file, which is convenient for archiving, realizes archiving of numerous test case execution results, and is convenient for subsequent analysis of the automatic test result, and provides guidance for subsequent maintenance and upgrading of the DMDIS.

[0101] xlwt module is an extension module in python specially used for writing Excel, and can realize the functions of manually creating forms, writing in specified cells, and specifying cell styles, etc.

[0102] The preset data structure can be a data structure composed of a test case ID of a test case, a result, and a failure reason when the result is a failure.

[0103] The FTP server (File Transfer Protocol Server) is a computer that provides file storage and access services on the Internet and provides services according to the FTP protocol. Simply put, a server that supports the FTP protocol is an FTP server.

[0104] For the case of multi-version parallel testing, conflicts will occur because all test cases depend on the same set of data sources. To solve this conflict, in some embodiments of the present application, the test engine process includes a first test engine process and a second test engine process corresponding to different versions of the DMDIS process to be tested, and as shown in Figure 9 The DMDIS automated testing method also includes:

[0105] S901, before the first test engine process starts the test case, judging whether the test case is used by the second test engine process based on the global case lock record table;

[0106] S902, when the test case is not used by the second test engine process, the first test engine process starts the test case;

[0107] S903, when the first test engine process executes the test case, the test case is added to the global case lock record table, and when the first test engine process finishes executing the test case, the test case is deleted from the global case lock record table.

[0108] By setting the global case lock, the same test case can only be used by one test engine and cannot be used by two test engine processes simultaneously, avoiding conflicts and improving the orderliness and reliability of the DMDIS automated testing process.

[0109] In some actual application scenarios, it is necessary to repeatedly start the test engine process for automated testing. To achieve this purpose, in some embodiments of the present application, before step S101, it further includes:

[0110] Based on multiple preset scheduling times in the Jenkins continuous integration process, the test engine process is called and started at each preset scheduling time.

[0111] The embodiment of the present application can call and start the test engine process at each preset scheduling time by setting the Jenkins continuous integration process, so as to repeatedly call and execute steps S101-S102, and further to realize repeated automatic testing in an unattended manner, and further improve the automation degree and efficiency of the DMDIS automatic testing.

[0112] In the Jenkins continuous integration process, a plurality of timing tasks are included, each task is started at a preset scheduling time, and each task is a test step in steps S101-S102.

[0113] In one specific embodiment of the present application, the DMDIS automatic testing method is specifically: the Jenkins continuous integration process executes a timing task, repeatedly starts the test engine process, the test engine process notifies the test case synchronization process to synchronize the test cases and the mirror process on the baseline library process to the DMDIS process to be tested, so that the DMDIS process to be tested copies the test cases and the mirror process on the baseline library process. Then instruct the Chrome browser process to log in to the DMDIS service and obtain a login token. Then call the Requests module of Python to fake a HTTP request to instruct the DMDIS process to be tested to start the test cases, and continuously inquire about the running status of all test cases. If the test case execution is successful, instruct the mirror process to perform result verification work, and store the test case execution results of all test cases in a specific data structure. At the same time, notify the global case lock process to lock the test cases being executed and unlock the test cases executed. After the test case queue composed of the test cases is consumed, the structure body data storing the test case execution results in the memory is read, a test report is generated and sent to the test report storage process.

[0114] In order to better implement the DMDIS automatic testing method in the embodiment of the present application, on the basis of the DMDIS automatic testing method, the embodiment of the present application also provides a DMDIS automatic testing device, as shown in Figure 10 The DMDIS automatic testing device 1000 includes:

[0115] A synchronization unit 1001 is configured to synchronize the test cases and the mirror process to the DMDIS process to be tested based on the test engine process.

[0116] An automatic testing unit 1002 is configured to generate a fake HTTP request based on the test engine process, instruct the DMDIS process to be tested to start the test cases and the mirror process based on the fake HTTP request, generate test case execution results, and store the test case execution results.

[0117] The mirror process is used to verify whether the output of the test case is the expected output.

[0118] The DMDIS automated testing device 1000 provided in the above embodiments can implement the technical solutions described in the above DMDIS automated testing method embodiments. The specific implementation principles of each module or unit can be found in the corresponding content in the above DMDIS automated testing method embodiments, and will not be repeated here.

[0119] like Figure 11 As shown, the present invention also provides an electronic device 1100. The electronic device 1100 includes a processor 1101, a memory 1102, and a display 1103. Figure 11 Only some components of the electronic device 1100 are shown, but it should be understood that it is not required to implement all the components shown, and more or fewer components may be implemented instead.

[0120] In some embodiments, processor 1101 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in memory 1102 or process data, such as the DMDIS automated testing method of the present invention.

[0121] In some embodiments, processor 1101 may be a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, processor 1101 may be local or remote. In some embodiments, processor 1101 may be implemented on a cloud platform. In one embodiment, the cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, internal cloud, multi-cloud, etc., or any combination thereof.

[0122] In some embodiments, memory 1102 may be an internal storage unit of electronic device 1100, such as a hard disk or memory of electronic device 1100. In other embodiments, memory 1102 may also be an external storage device of electronic device 1100, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. equipped on electronic device 1100.

[0123] Furthermore, the memory 1102 may include both internal storage units of the electronic device 1100 and external storage devices. The memory 1102 is used to store application software and various types of data installed on the electronic device 1100.

[0124] The display 1103 may, in some embodiments, be an LED display, a liquid crystal display, a touch liquid crystal display, an OLED (Organic Light-Emitting Diode) touch, or the like. The display 1103 is used to display information of the electronic device 1100 and to display a visualized user interface. The components 1101-1103 of the electronic device 1100 communicate with each other through a system bus.

[0125] In some embodiments of the present application, when the processor 1101 executes the DMDIS automated test program in the memory 1102, the following steps can be implemented:

[0126] Synchronizing the test case and the mirror process to the DMDIS process to be tested based on the test engine process;

[0127] Generating a camouflage HTTP request based on the test engine process, instructing the DMDIS process to be tested to start the test case and the mirror process based on the camouflage HTTP request, generating a test case execution result, and storing the test case execution result;

[0128] The mirror process is used to verify whether the output of the test case is the expected output.

[0129] It should be understood that, in addition to the above functions, the processor 1101 can also implement other functions when executing the DMDIS automated test program in the memory 1102. For details, refer to the description of the corresponding method embodiments.

[0130] Further, the type of the electronic device 1100 referred to in the embodiments of the present application is not specifically limited, and the electronic device 1100 can be a portable electronic device such as a mobile phone, a tablet computer, a personal digital assistant (PDA), a wearable device, a laptop, or the like. Exemplary embodiments of the portable electronic device include, but are not limited to, a portable electronic device running an IOS, an android, a microsoft, or another operating system. The portable electronic device described above can also be another portable electronic device, and it should also be understood that, in some other embodiments of the present application, the electronic device 1100 can also not be a portable electronic device, but a desktop computer having a touch-sensitive surface (such as a touch panel).

[0131] Correspondingly, the embodiments of the present application also provide a computer-readable storage medium for storing computer-readable programs or instructions, which, when executed by a processor, can implement the steps or functions in the DMDIS automated test method provided by the above method embodiments.

[0132] Those skilled in the art can understand that all or part of the processes of the above-mentioned embodiment methods can be instructed by a computer program to relevant hardware (such as a processor, a controller, etc.) to be completed, and the computer program can be stored in a computer readable storage medium. Among them, the computer readable storage medium is a magnetic disk, an optical disk, a read-only memory or a random access memory, etc.

[0133] The above describes in detail the DMDIS automatic testing method and device provided by the present application. The principles and implementation manners of the present application are described by using specific examples. The above description of the embodiments is only used to help understand the method of the present application and its core idea. Meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation manners and application ranges will be changed. In summary, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A DMDIS automated testing method, characterized by, The method comprises the following steps: synchronizing test cases and mirror processes to a DMDIS process to be tested based on a test engine process; generating a disguised HTTP request based on the test engine process, instructing the DMDIS process to be tested to start the test cases and the mirror processes based on the disguised HTTP request, generating test case execution results, and storing the test case execution results; wherein the mirror processes are used to verify whether the output of the test cases is the expected output; the step of generating the disguised HTTP request based on the test engine process comprises the following steps: obtaining a test case ID and a basic URL address of the test cases; splicing the test case ID and the basic URL address to generate a unique URL; generating the disguised HTTP request based on the unique URL.

2. The DMDIS automated testing method of claim 1, wherein, the step of synchronizing the test cases and the mirror processes to the DMDIS process to be tested based on the test engine process comprises the following steps: the test engine process initiates a synchronization instruction, and when the synchronization process receives the synchronization instruction, the test cases and the mirror processes in the baseline library process are synchronized to the DMDIS process to be tested.

3. The DMDIS automated testing method of claim 1, wherein, the step of generating the disguised HTTP request based on the unique URL comprises the following steps: using selenium to simulate logging in to the DMDIS process to be tested; obtaining a login session returned after the DMDIS process to be tested logs in successfully; obtaining a login token in the login session and splicing the login token to a request header; generating the disguised HTTP request based on the request header and the unique URL.

4. The DMDIS automated testing method of claim 1, wherein, the step of instructing the DMDIS process to be tested to start the test cases and the mirror processes based on the disguised HTTP request to generate test case execution results comprises the following steps: instructing the DMDIS process to be tested to start the test cases based on the disguised HTTP request, and determining whether the test cases are executed successfully; when the test cases are executed successfully, starting the mirror processes and generating the test case execution results based on the mirror processes.

5. The DMDIS automated testing method of claim 4, wherein, the step of determining whether the test cases are executed successfully comprises the following steps: continuously querying an execution state of the test cases based on an execution ID of the test cases; the execution state comprises a waiting state, a cancellation state, a success state and a failure state; determining whether the execution state is changed to the success state within a preset time, and if yes, the test cases are executed successfully.

6. The DMDIS automated testing method of claim 1, wherein, the step of storing the test case execution results comprises the following steps: storing the test case execution results in a memory of the test engine process in a preset data structure; calling an xlwt module of Python, writing the test case execution results into a table, generating a result table, and sending the result table to an FTP server for archiving.

7. The DMDIS automated testing method of claim 1, wherein, if the test engine process comprises a first test engine process and a second test engine process, the DMDIS automatic test method further comprises the following steps: before the first test engine process starts the test cases, determining whether the test cases are used by the second test engine process based on a global test case lock record table. When the test case is not used by the second test engine process, the first test engine process starts and executes the test case; When the first test engine process executes the test case, the test case is added to the global case lock record table, and when the first test engine process finishes executing the test case, the test case is deleted from the global case lock record table.

8. The DMDIS automated testing method of claim 1, wherein, Before the test engine process synchronizes the test case and the mirror process to the DMDIS process to be tested, further comprising: Based on multiple preset scheduling times in the Jenkins continuous integration process, the test engine process is called and started at each preset scheduling time.

9. A DMDIS automated testing device, characterized by, Comprise: A synchronization unit for synchronizing test cases and mirror processes to a DMDIS process to be tested based on a test engine process; An automated test unit for generating a fake HTTP request based on the test engine process, instructing the DMDIS process to be tested to start the test case and the mirror process based on the fake HTTP request, generating test case execution results, and storing the test case execution results; Wherein, the mirror process is used to verify whether the output of the test case is the expected output; The test engine process generates a fake HTTP request, comprising: Obtaining the test case ID and the base URL address; Splicing the test case ID and the base URL address to generate a unique URL; Generating the fake HTTP request based on the unique URL.

Images