A testing method and device

Abstract

The present application provides a testing method and device. The method comprises: when testing a system under test, determining the conflict domains to which test cases required for testing the system under test belong, wherein a conflict relationship exists between the test cases in the conflict domains, and no conflict relationship exists between test cases belonging to different conflict domains; when at least two conflict domains are determined, determining whether the at least two conflict domains meet a merging condition; when the merging condition is met, merging the test cases in the conflict domains that meet the merging condition to generate a top-level parent domain; when the merging condition is not met, using the conflict domains that do not meet the merging condition as the top-level parent domain; generating a corresponding number of test sub-processes based on the number of top-level parent domains obtained; and using each test sub-process to call the test cases in the top-level parent domain corresponding to the test sub-process to execute the test on the system under test.

Description

Technical Field

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

[0002] As the application scope of software products becomes wider and wider and their functions become more and more complex, the management of software quality is becoming more and more difficult. Although people have used many effective analysis, design and implementation methods in the process of software development, various errors cannot be avoided. Therefore, how to use more practical and effective methods to discover errors and defects in software products will become the primary task of software testers.

[0003] Currently available software testing methods include manual testing and automated testing. Automated software testing involves using automated testing tools or methods to automatically repeat tests according to the tester's predetermined plan and analyze the test results. In reality, test equipment resources are often scarce. To further improve the efficiency of automated testing and resource utilization, concurrent multi-path testing within a single test environment can be considered. This allows for equipment reuse, reduces hardware costs, and exponentially increases test execution speed.

[0004] However, in the current implementation of multi-channel concurrent testing, multiple test suites need to be manually created in advance and then placed in the overall test suite. The automated concurrent testing tool needs to distribute multiple processes (or threads) during execution, using the defined test suite as the minimum selection granularity for distributing the execution process, and then using the distributed processes to execute the test. In addition, the number of concurrency needs to be manually defined before execution, and the content of each sub-test suite that can be executed in parallel needs to be fixed in advance, and multi-channel testing shares the test environment. When the test process is started, the test sub-processes will be started according to the concurrency number, and the execution content of each sub-process is the use case in the pre-defined sub-test suite. The minimum granularity for distributing use cases to each concurrent process is the manually defined sub-test suite. As a result, when concurrent testing is performed on the same system under test (SUT), there is a high probability of conflicts between test cases, and the number of concurrency during test execution is limited by the number of manually defined sub-test suites, which cannot fully utilize the performance of multi-core processors, resulting in insufficient concurrency.

[0005] Therefore, when testing a system under test, how to solve the problem of low testing efficiency caused by the process used to test the system under test being limited by the number of manually defined sub-test suites is one of the technical issues worth considering. Summary of the Invention

[0006] In view of this, the present application provides a testing method and apparatus for solving the problem of low testing efficiency caused by the process for testing the system under test being limited by the number of manually defined sub-test suites when testing the system under test.

[0007] Specifically, this application is implemented through the following technical solutions:

[0008] According to a first aspect of the present application, a testing method is provided, comprising: when testing a system under test, determining a conflict domain to which test cases required for testing the system under test belong, wherein a conflict relationship exists between the test cases in the conflict domain, and no conflict relationship exists between test cases belonging to different conflict domains;

[0009] When at least two conflicting domains are determined, determining whether the at least two conflicting domains meet a merging condition;

[0010] When the merging conditions are met, the test cases in the conflicting domains that meet the merging conditions are merged to generate a top-level parent domain;

[0011] When the merge condition is not met, the conflict domain that does not meet the merge condition is used as the top-level parent domain;

[0012] Generate a corresponding number of test child processes based on the number of top-level parent domains obtained;

[0013] Each test sub-process is used to call the test case in the top-level parent domain corresponding to the test sub-process to execute the test on the system under test.

[0014] According to a second aspect of the present application, a testing device is provided, comprising:

[0015] A first determining module is configured to determine, when testing a system under test, the conflict domains to which test cases required for testing the system under test belong, wherein a conflict relationship exists between the test cases in the conflict domains, and no conflict relationship exists between test cases belonging to different conflict domains;

[0016] a judging module, configured to, when the first determining module determines at least two conflicting domains, judge whether the at least two conflicting domains meet a merging condition;

[0017] A merging module, configured to merge the test cases in the conflicting domains that meet the merging conditions when the judgment result of the judgment module is that the merging conditions are met, to generate a top-level parent domain;

[0018] a second determining module, configured to, when the determination result of the determining module is that the merging condition is not met, use the conflicting domain that does not meet the merging condition as a top-level parent domain;

[0019] A generation module is used to generate a corresponding number of test child processes according to the number of top-level parent domains obtained;

[0020] The test execution module is used to use each test sub-process to call the test case in the top-level parent domain corresponding to the test sub-process to execute the test on the system under test.

[0021] According to the third aspect of the present application, an electronic device is provided, comprising a processor and a machine-readable storage medium, wherein the machine-readable storage medium stores a computer program that can be executed by the processor, and the processor is prompted by the computer program to execute the method provided in the first aspect of the embodiment of the present application.

[0022] According to the fourth aspect of the present application, a machine-readable storage medium is provided, which stores a computer program. When called and executed by a processor, the computer program prompts the processor to execute the method provided in the first aspect of the embodiment of the present application.

[0023] Beneficial effects of the embodiments of the present application:

[0024] When testing the system under test, the concurrency is determined based on the conflict domains created based on the conflict relationships between test cases, that is, the conflict domains that meet the merging conditions are first merged to obtain the top-level parent domain, and then the conflict domains that do not meet the merging conditions are also determined as top-level parent domains, and then the concurrency is determined based on the number of determined top-level parent domains, that is, a number of test sub-processes consistent with the number of top-level parent domains is created, and then the created test sub-processes are used to call the test cases in the top-level parent domain to complete the test of the system under test, so that the concurrency determined in this application is no longer limited by the number of manually defined sub-test suites, but is determined based on the conflict relationship of the test cases, thereby better improving the concurrency efficiency; in addition, each test sub-process in this application only calls the test cases in the corresponding top-level parent domain, and does not call the test cases in other top-level parent domains, so that there will be no use case conflicts caused by multiple test subroutines calling the same test case. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 This is a flow chart of a testing method provided in an embodiment of the present application;

[0026] Figure 2a This is a schematic diagram of a situation where there is an intersection between the conflict domains provided in the embodiment of the present application;

[0027] Figure 2b This is a schematic diagram of another situation where there is an intersection between the conflict domains provided in the embodiment of the present application;

[0028] Figure 3 This is a schematic structural diagram of a testing device provided in an embodiment of the present application;

[0029] Figure 4This is a hardware structure diagram of an electronic device for implementing a testing method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0030] Exemplary embodiments are described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of the present application.

[0031] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. The singular forms "a," "the," and "the" used in this application are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and includes any or all possible combinations of one or more of the corresponding listed items.

[0032] It should be understood that although the terms first, second, third, etc. may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0033] Before introducing the test method provided in this application, the technical terms involved in this application are introduced:

[0034] Concurrency, Concurrent, in an operating system, refers to the period of time in which several programs are between startup and completion, and these programs are all running on the same processor, but only one program is running on the processor at any one time.

[0035] Collision Domain: In this application, it refers to a set of test cases that cannot be executed simultaneously on the same tested environment due to the mutual influence between the test characteristics.

[0036] Sub-collision domain, Sub-collision domain, in this application means that if any element of collision domain A is also an element of collision domain B, then collision domain A is called a sub-collision domain of collision domain B.

[0037] Parent Collision Domain, in this application, means that if collision domain A is a child domain of collision domain B, then collision domain B is the parent domain of collision domain A.

[0038] A test suite is a collection of related tests that can contain multiple test cases or sub-test suites. It is stored as a file or directory on the test execution host.

[0039] Sub TestSuite, a subset of a test suite, can contain multiple test cases or the next level of sub-test suite.

[0040] System under test (SUT): The test host usually interacts with the system through SSH connection, RESTful interface, etc.

[0041] JavaScript Object Notation, Json, is a lightweight data exchange format.

[0042] The test method provided in this application is described in detail below.

[0043] See also Figure 1 , Figure 1 This is a flow chart of a test method provided by the present application, which is applied to a test device. The method may include the following steps:

[0044] S101 . When testing a system under test, determine a conflict domain to which test cases required for testing the system under test belong.

[0045] In this embodiment, there is a conflict relationship between test cases in a conflict domain, and there is no conflict relationship between test cases belonging to different conflict domains.

[0046] In this step, when testing the system under test, the test cases to be executed may be selected according to the test strategy. When the test cases to be executed are determined, the conflict domain to which the selected test cases belong may be determined.

[0047] Optionally, the above-mentioned conflict domains are divided according to the conflict relationships between test cases. Specifically, the designer can determine the conflict relationships that may be stored between test cases based on experience, and then pre-set the rules that satisfy the conflict relationship based on each conflict relationship, and save them in the test equipment in the form of computer language, and at the same time create a corresponding conflict domain for each conflict relationship. On this basis, the test equipment can analyze all test cases one by one to determine the rules satisfied by each test case, and then write the test case into the conflict domain of the conflict relationship corresponding to the satisfied rule, and repeat the above process until all test cases are traversed, thereby dividing the test cases used to test the system under test into the corresponding conflict domain. The divided conflict domain is then saved in a file in Json format according to the standard data structure, and the file name can be named conflict domain name.json.

[0048] Optionally, the aforementioned conflict relationships may include, but are not limited to, installation and uninstallation, adding and deleting users, and capacity expansion and contraction. For example, in the case of installation and uninstallation, test cases for testing installation and uninstallation functions are written into the corresponding conflict domains for installation and uninstallation. Furthermore, to facilitate conflict domain management for designers and enable quick and easy access to conflict domains by the test equipment, conflict domains can be named according to conflict characteristics, such as "ConflictDomain_Add_Delete_User."

[0049] It should be noted that the test case can be named in the form of "number + name", for example, 1.1.1.10_Software Installation. The number is unique, that is, different test cases have different corresponding numbers.

[0050] Furthermore, the standard data structure described above is used to describe the test cases included in a collision domain. The data structure is in the form of a list dictionary. The standard data structure for this collision domain can be represented as: {collision domain name: test case number_name 1, test case number_name 2, ..., test case number_name M}.

[0051] Optionally, the collision domain may further include sub-collision domains, which are subsets of the collision domain. Each sub-collision domain can be understood as a classification of the collision domain, with each category corresponding to a sub-collision domain. Based on this, the data structure of the collision domain can be represented as: {collision domain name: [sub-collision domain 1, sub-collision domain 2, ..., sub-collision domain N, use case number_name 1, use case number_name 2, ..., use case number_name N]}. It should be noted that the data structure of the sub-collision domains described above is the same as that of the collision domain, and both are represented using a standard data structure.

[0052] Optionally, based on the above embodiments, the testing method provided in this embodiment further includes: when there is a new test case, determining whether the new test case has a conflict relationship with the test cases in the current conflict domains; when there is a conflict relationship and the existing conflict relationship is not a new conflict relationship, adding the new test case to the conflict domain with which it has a conflict relationship; when the existing conflict relationship is a new conflict relationship, creating a new conflict domain and adding the new test case to the new conflict domain.

[0053] Specifically, as product features grow, new test cases will also appear synchronously. Therefore, it is necessary to gradually add new test cases to the established conflict domain. Specifically, it is possible to determine whether there is a new conflict relationship between the newly added test case and the test cases in the established conflict domain. If a new conflict relationship exists, a new conflict domain is established, and the new test case and the test cases that have a new conflict relationship with the new test case are copied and placed in the new conflict domain. If no new conflict relationship exists, the new test case is added to the conflict domain that has a conflict relationship with the test case. In this way, the conflict domain can be updated.

[0054] S102: When at least two conflicting domains are determined, determine whether the at least two conflicting domains meet a merging condition; if so, execute step S103; if not, execute step S104.

[0055] Specifically, when it is determined that the number of conflict domains to which the test cases used to test the system under test belong is multiple, in order to determine an appropriate number of concurrency, the present application proposes that it can be determined whether the at least two conflict domains meet the merging condition.

[0056] It should be noted that when the number of collision domains used to test the system under test is 1, the collision domain is directly used as the top-level parent domain to execute subsequent processes. However, in general, the number of collision domains required to test the system under test is more than one.

[0057] Optionally, step S102 may be performed according to the following process: determining whether the at least two conflicting domains have an intersection; and if so, confirming that the conflicting domains with the intersection meet the merging condition.

[0058] Specifically, it is determined whether the same test case exists in at least two collision domains. If so, it indicates that the collision domains with the same test case have an intersection, and it is confirmed that the collision domains with the intersection meet the merging condition.

[0059] It is worth noting that the existence of intersections between at least two conflict domains can be understood as: there are intersections between multiple conflict domains, but there is no common intersection between all parties. Figure 2a As shown, Figure 2a In the example, collision domain 1 and collision domain 2 intersect, collision domain 2 and collision domain 3 intersect, but collision domain 1 and collision domain 3 do not intersect. This situation can also be understood as at least two collision domains intersecting. In addition, the above-mentioned at least two collision domains intersecting can also be understood as: there is a common intersection between multiple collision domains, refer to Figure 2b As shown, Figure 2b In the example, collision domains 4, 5, and 6 all overlap.

[0060] S103: Merge the test cases in the conflicting domains that meet the merging conditions to generate a top-level parent domain.

[0061] In this step, since test cases across different collision domains don't conflict, a test case might belong to multiple collision domains. Therefore, to avoid duplicate test case execution during subsequent test flow execution, this step merges test cases within collision domains that meet the merge criteria. This means that only one identical test case from different collision domains remains after the merge. By performing this merge step, a top-level parent domain is obtained, ensuring that there are no duplicate test cases within the top-level parent domain.

[0062] Optionally, step S103 may be performed according to the following process: merging the test cases in the conflict domains that meet the merging condition to generate a parent conflict domain; determining whether the generated parent conflict domains meet the merging condition; if the merging condition is met, merging the test cases in the generated parent conflict domains to generate a new parent conflict domain, and continuing to determine whether the generated parent conflict domains meet the merging condition; if the merging condition is not met, determining the generated parent conflict domain as the top-level parent domain.

[0063] Specifically, when the conflict domains satisfying the above merging conditions are determined, the test cases in the conflict domains satisfying the merging conditions can be merged. It should be noted that the test cases satisfying the merging conditions can be Figure 2a and / or Figure 2b The collision domain of the intersection shown; Figure 2a For example, it is necessary to merge the test cases in conflict domain 1, conflict domain 2 and conflict domain 3, and retain only one identical test case, so as to obtain a parent conflict domain 1; when conflict domains 4 to 6 have Figure 2bWhen the intersection is shown, the test cases in conflict domains 4 to 6 are also merged, and only one identical test case is retained, so that a parent conflict domain 2 can be obtained. Similarly, each merged parent conflict domain can be obtained. Then, it is judged whether each of the above parent conflict domains meets the merging condition. When the merging condition is met, the parent conflict domains that meet the merging condition are merged to obtain a new parent conflict domain. Then, it is continued to judge whether the new parent conflict domains meet the merging condition until a parent conflict domain that does not meet the merging condition is determined. Then, the parent conflict domain that does not meet the merging condition is determined as the top-level parent domain.

[0064] S104: Regulate the conflicting domains that do not meet the merging conditions as top-level parent domains.

[0065] In this step, in actual applications, there may be a situation where the collision domain does not intersect with other collision domains. In this case, the collision domain can be used as a top-level parent domain to participate in subsequent processing.

[0066] It should be noted that after obtaining each top-level parent domain based on steps S103 and S104, each top-level parent domain can be expanded into a use case set and saved in a temporary file. The format of the temporary file can be Json format. The temporary file can be recorded as top-level parent domain K_expanded use case.json, and the content format is: {top-level parent domain name: [use case number_name 1, use case number_name 2, use case number_name 3,..., use case number_name K]}.

[0067] Optionally, the top-level parent domain expansion method is: convert the standard collision domain structure corresponding to each top-level parent domain into a top-level collision domain expansion structure. Because the standard collision domain is similar to the tree data structure in the file system, a recursive algorithm can be used to expand it layer by layer and remove duplicate items. The detailed process can be referred to the currently provided method and will not be described in detail here.

[0068] S105 : Generate a corresponding number of test child processes according to the obtained number of top-level parent domains.

[0069] Specifically, in order to avoid the prior art where the concurrent number of test sub-processes is limited by manually set test sub-suites, this application creates test sub-processes that match the number of top-level parent domains generated in steps S101 to S104 when creating sub-processes.

[0070] S106: Utilize each test sub-process to call a test case in the top-level parent domain corresponding to the test sub-process to execute a test on the system under test.

[0071] In this step, after creating a number of test subprocesses equal to the number of top-level parent domains, each test subprocess is used to call the test case in the top-level parent domain corresponding to the subprocess, thereby completing the test of the system under test.

[0072] Optionally, after all test sub-processes have executed the corresponding test cases, the execution logs can be merged and processed to generate a test report and output it so that the test designer can analyze whether the system under test is normal and possible problems based on the test report.

[0073] Optionally, based on any of the above embodiments, the testing method provided in this embodiment further includes:

[0074] If it is determined that the test cases required for testing the system under test are in the non-conflicting domain, generating corresponding test subprocesses according to the test cases in the non-conflicting domain for testing the system under test; and using each test subprocess to call the corresponding test cases in the non-conflicting domain to execute the test on the system under test;

[0075] Specifically, in actual applications, there may be a situation where a test case does not conflict with any other test cases. In this case, the test case can be stored in a non-conflict domain. Furthermore, the test cases in the non-conflict domain do not conflict with the test cases in the conflict domain, and the test cases in the non-conflict domains do not conflict with each other. On this basis, when it is confirmed that the test case used to test the system under test is in the non-conflict domain, a corresponding test sub-process is created for the test case in the non-conflict domain used to test the system under test, and the test case is then called using the corresponding test sub-process to complete the test of the system under test.

[0076] It should be noted that there may be at least one test case in the non-conflict domain for testing the system under test, and the specific number may be determined according to actual conditions.

[0077] Furthermore, when there is a new test case, if there is no conflict relationship between the new test case and the test cases in the established conflict domain, and there is no conflict relationship between the new test case and the test cases in the non-conflict domain, the new test case is written into the non-conflict domain.

[0078] Optionally, in actual applications, there may be situations where the performance resources of the test equipment are relatively limited, and there may be situations where the test equipment cannot support too many concurrency numbers. In view of this, this embodiment can set a maximum value. After determining the top-level parent domain, it can be determined whether the number of top-level parent domains is greater than the maximum value. If it is greater, a test sub-process is created with the maximum value. Although the test tasks need to queue for execution, the concurrency number is not limited by manual configuration. When the number of top-level parent domains is not greater than the maximum value, if there is a test case in a non-conflict domain, it can be determined whether the sum of the number of sub-processes created based on the non-conflict domain and the number of top-level parent domains is greater than the above-mentioned maximum value. If it is greater, a test sub-process is also created with the maximum value. Although the test tasks need to queue for execution, the concurrency number is not limited by manual configuration.

[0079] By implementing the testing method provided by the present application, when testing the system under test, the concurrency is determined based on the conflict domains created based on the conflict relationships between the test cases, that is, the conflict domains that meet the merging conditions are first merged to obtain the top-level parent domain, and then the conflict domains that do not meet the merging conditions are also determined as the top-level parent domains, and then the concurrency is determined based on the number of determined top-level parent domains, that is, a number of test sub-processes consistent with the number of top-level parent domains is created, and then the created test sub-processes are used to call the test cases in the top-level parent domain to complete the testing of the system under test, so that the concurrency determined by the present application is no longer limited by the number of manually defined sub-test suites, but is determined based on the conflict relationship of the test cases, thereby better improving the concurrency efficiency; in addition, each test sub-process in the present application only calls the test cases in the corresponding top-level parent domain, and does not call the test cases in other top-level parent domains, so that there will be no use case conflicts caused by multiple test subroutines calling the same test case.

[0080] To better understand the testing method provided by this application, assume that there is a test suite containing 1,000 test cases. Based on real-time testing requirements, 200 test cases are selected and executed to test a system under test (SUT). The testing process for this SUT based on the testing method provided by this application is as follows:

[0081] During the test case design phase, the test designer divides the test cases according to their characteristics. In this example, the test equipment divides the test cases into 10 conflict domains and 1 non-conflict domain based on the conflict relationship:

[0082] For example: Conflict Domain_User Management, Conflict Domain_Alarm Detection, Conflict Domain_Object I / O Service, Conflict Domain_File I / O Service, Conflict Domain_Block I / O Service, Conflict Domain_Registration Information, Conflict Domain_Resource Management, Conflict Domain_File I / O Service, Conflict Domain_System Management, Conflict Domain_Security Management, and Non-Conflict Domain. Furthermore, the test equipment has saved this conflict domain data in a file of a specified format.

[0083] When testing the system under test, 200 test cases to be executed are selected from the entire test set based on actual real-time testing requirements. Based on the pre-recorded conflict domains to which the test cases belong, 190 test cases are distributed across the eight conflict domains, with the remaining 10 test cases located in non-conflict domains. By determining whether the eight conflict domains meet the merging conditions, the conflict domains that meet the merging conditions are merged. For example, if all eight conflict domains meet the merging conditions, the program implemented according to the merging rules automatically and in real time merges the eight conflict domains, ultimately generating five top-level parent domains (the ideal number of top-level parent domains is eight, depending on actual calculation results). Five test sub-processes are then generated based on the five top-level parent domains. Furthermore, ten test cases are located in non-conflict domains, and corresponding test sub-processes are generated for each of these ten test cases, ultimately generating 5 + 10 = 15 test sub-processes, constituting a 15-way concurrent test.

[0084] The conflict domains are divided and solidified during the use case design. Each time, a different set of test cases is selected according to the test strategy. When the execution is triggered, the program calculates and generates the maximum number of concurrent tests that can be supported in real time for testing, without the need to repeatedly divide the concurrent sub-test suites with manpower.

[0085] At this point, when the test is executed, the test cases to be executed are arbitrarily selected from the full test case set according to the test strategy, the maximum non-conflicting concurrency number is automatically calculated in real time, and a test subset that can adapt to multi-way concurrency is automatically generated and dynamically adapted; as many channels as possible are executed concurrently on a single set of SUTs, which improves execution efficiency, makes full use of test resources, and saves test equipment costs; since the demarcation of the conflict domain is determined by test designers who are familiar with the features when designing the use cases, during subsequent version verification, test managers do not need to be deeply familiar with the conflict relationship between test features, and can directly select appropriate test cases according to the version test strategy to automatically implement concurrent testing.

[0086] Based on the same inventive concept, the present application also provides a testing device corresponding to the above-mentioned testing method. The implementation of the testing device can be specifically referred to the above-mentioned description of the testing method, and will not be discussed here one by one.

[0087] See also Figure 3 , Figure 3A testing device provided by an exemplary embodiment of the present application is provided in a testing device, and the device includes:

[0088] A first determining module 301 is configured to determine, when testing a system under test, the conflict domains to which test cases required for testing the system under test belong, wherein conflict relationships exist between test cases in the conflict domains, and no conflict relationships exist between test cases belonging to different conflict domains;

[0089] A first judging module 302 is configured to judge whether the at least two conflicting domains meet a merging condition when the first determining module 301 determines at least two conflicting domains;

[0090] A merging module 303 is configured to merge the test cases in the conflicting domains that meet the merging conditions to generate a top-level parent domain when the judgment result of the first judging module 302 is that the merging conditions are met;

[0091] A second determining module 304 is configured to, when the determination result of the first determining module 302 is that the merging condition is not met, use the conflicting domain that does not meet the merging condition as the top-level parent domain;

[0092] A generating module 305 is configured to generate a corresponding number of test child processes according to the number of top-level parent domains obtained;

[0093] The test execution module 306 is configured to use each test sub-process to call a test case in the top-level parent domain corresponding to the test sub-process, so as to execute a test on the system under test.

[0094] Optionally, the generating module 305 is further configured to generate a corresponding test sub-process according to the test case for testing the system under test in the non-conflict domain when the first determining module 301 determines that the test case required for testing the system under test is in the non-conflict domain;

[0095] The test execution module 306 is further configured to use each test subprocess to call the corresponding test case in the non-conflicting domain to execute the test on the system under test;

[0096] There is no conflict relationship between the test cases in the non-conflict domain and the test cases in the conflict domain, and there is no conflict relationship between the test cases in the non-conflict domain.

[0097] Optionally, the first determining module 302 is specifically configured to determine whether the at least two conflicting domains have an intersection; if so, confirming that the conflicting domains with the intersection meet a merging condition.

[0098] Optionally, the merging module 303 is specifically configured to merge the test cases in the conflict domains that meet the merging condition to generate a parent conflict domain; determine whether the generated parent conflict domains meet the merging condition; if the merging condition is met, merge the test cases in the generated parent conflict domains to generate a new parent conflict domain, and continue to determine whether the generated parent conflict domains meet the merging condition; if the merging condition is not met, determine the generated parent conflict domain as the top-level parent domain.

[0099] Optionally, the conflict domains are divided according to the conflict relationships between test cases. On this basis, the testing apparatus provided in this embodiment further includes:

[0100] The second judgment module (not shown in the figure) is used to judge whether there is a conflict relationship between the newly added test case and the test cases in each current conflict domain when there is a newly added test case;

[0101] A writing module (not shown in the figure) is configured to add the newly added test case to the conflict domain with which the conflict relationship exists when the second judgment module determines that a conflict relationship exists and the existing conflict relationship does not belong to a new conflict relationship;

[0102] The creation module (not shown in the figure) is configured to create a new conflict domain and add the newly added test case to the new conflict domain when the second judgment module determines that the existing conflict relationship is a new conflict relationship.

[0103] Based on the same inventive concept, the embodiment of the present application provides an electronic device, such as Figure 4 As shown, the electronic device can be the aforementioned test device and includes a processor 401 and a machine-readable storage medium 402. The machine-readable storage medium 402 stores a computer program executable by the processor 401, and the processor 401 is prompted by the computer program to execute the test method provided in any embodiment of the present application. In addition, the electronic device also includes a communication interface 403 and a communication bus 404, wherein the processor 401, the communication interface 403, and the machine-readable storage medium 402 communicate with each other via the communication bus 404.

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

[0105] The communication interface is used for communication between the above electronic device and other devices.

[0106] The memory may include random access memory (RAM), DDR SRAM (Double Data Rate Synchronous Dynamic Random Access Memory), or non-volatile memory (NVM), such as at least one disk storage. Optionally, the memory may be at least one storage device located remotely from the processor.

[0107] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.

[0108] In addition, an embodiment of the present application provides a machine-readable storage medium, which stores a computer program. When called and executed by a processor, the computer program prompts the processor to execute the test method provided by the embodiment of the present application.

[0109] As for the electronic device and machine-readable storage medium embodiments, since the method contents involved are basically similar to the aforementioned method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0110] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0111] The implementation process of the functions and effects of each unit / module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0112] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely schematic, wherein the units / modules described as separate components may or may not be physically separated, and the components displayed as units / modules may or may not be physical units / modules, that is, they may be located in one place, or they may be distributed over multiple network units / modules. Some or all of the units / modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0113] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A testing method, characterized in that: include: When testing a system under test, determining the conflict domains to which test cases required for testing the system under test belong, wherein a conflict relationship exists between test cases in the conflict domains, and no conflict relationship exists between test cases belonging to different conflict domains; When at least two conflicting domains are determined, determining whether the at least two conflicting domains meet a merging condition; When the merging conditions are met, the test cases in the conflicting domains that meet the merging conditions are merged to generate a top-level parent domain; When the merge condition is not met, the conflict domain that does not meet the merge condition is used as the top-level parent domain; Generate a corresponding number of test child processes based on the number of top-level parent domains obtained; Using each test sub-process to call the test case in the top-level parent domain corresponding to the test sub-process to execute the test on the system under test; The determining whether the at least two conflicting domains meet a merging condition includes: Determining whether the at least two conflict domains have an intersection; If so, it is confirmed that the conflict domains with intersections meet the merging conditions.

2. The method according to claim 1, characterized in that Also includes: When it is determined that the test case required for testing the system under test is in the non-conflict domain, generating a corresponding test sub-process according to the test case for testing the system under test in the non-conflict domain; Using each test subprocess to call the corresponding test case in the non-conflict domain to execute the test on the system under test; There is no conflict relationship between the test cases in the non-conflict domain and the test cases in the conflict domain, and there is no conflict relationship between the test cases in the non-conflict domain.

3. The method according to claim 1, characterized in that Merge the test cases in the conflicting domains that meet the merge conditions to generate a top-level parent domain, including: Merge the test cases in the conflict domains that meet the merging conditions to generate a parent conflict domain; Determine whether the generated parent conflict domains meet the merging condition; When the merging condition is met, the test cases in the generated parent conflict domains are merged to generate a new parent conflict domain, and the step of determining whether the generated parent conflict domains meet the merging condition is continued; When the merging condition is not met, the generated parent conflict domain is determined as the top-level parent domain.

4. The method according to any one of claims 1 to 3, characterized in that: The conflict domain is divided according to the conflict relationship between the test cases; the method further includes: When there is a new test case, determine whether the new test case has a conflict relationship with the test cases in the current conflict domains; When a conflict relationship exists and the existing conflict relationship does not belong to a new conflict relationship, the newly added test case is added to the conflict domain with which the conflict relationship exists; When the existing conflict relationship is a new conflict relationship, a new conflict domain is created and the newly added test case is added to the new conflict domain.

5. A testing device, characterized in that: include: A first determining module is configured to determine, when testing a system under test, the conflict domains to which test cases required for testing the system under test belong, wherein a conflict relationship exists between the test cases in the conflict domains, and no conflict relationship exists between test cases belonging to different conflict domains; a first judging module, configured to, when the first determining module determines at least two conflicting domains, judge whether the at least two conflicting domains meet a merging condition; a merging module configured to merge the test cases in the conflicting domains that meet the merging conditions to generate a top-level parent domain when the judgment result of the first judgment module is that the merging conditions are met; a second determining module, configured to, when the determination result of the first determining module is that the merging condition is not met, use the conflicting domain that does not meet the merging condition as a top-level parent domain; A generation module is used to generate a corresponding number of test child processes according to the number of top-level parent domains obtained; A test execution module, configured to use each test sub-process to call a test case in a top-level parent domain corresponding to the test sub-process to execute a test on the system under test; The first judgment module is specifically configured to judge whether the at least two conflict domains have an intersection; if so, confirming that the conflict domains with the intersection meet the merging condition.

6. The device according to claim 5, characterized in that The generating module is further configured to generate a corresponding test sub-process according to the test case for testing the system under test in the non-conflict domain when the first determining module determines that the test case required for testing the system under test is in the non-conflict domain; The test execution module is further configured to use each test subprocess to call the corresponding test case in the non-conflicting domain to execute the test on the system under test; There is no conflict relationship between the test cases in the non-conflict domain and the test cases in the conflict domain, and there is no conflict relationship between the test cases in the non-conflict domain.

7. The device according to claim 5, characterized in that The merging module is specifically configured to merge the test cases in the conflict domains that meet the merging condition to generate a parent conflict domain; determine whether the generated parent conflict domains meet the merging condition; if the merging condition is met, merge the test cases in the generated parent conflict domains to generate a new parent conflict domain, and continue to determine whether the generated parent conflict domains meet the merging condition; When the merging condition is not met, the generated parent conflict domain is determined as the top-level parent domain.

8. The device according to any one of claims 5 to 7, characterized in that: The conflict domain is divided according to the conflict relationship between the test cases; the device further includes: The second judgment module is used to judge whether there is a conflict relationship between the newly added test case and the test cases in each current conflict domain when there is a newly added test case; a writing module configured to add the newly added test case to the conflict domain with which the test case has a conflict relationship when the second judging module determines that a conflict relationship exists and the existing conflict relationship is not a new conflict relationship; The creating module is configured to create a new conflict domain and add the newly added test case to the new conflict domain when the determination result of the second determining module is that the existing conflict relationship is a new conflict relationship.

Images