CN115599687A

CN115599687A - Method, device, equipment and medium for determining software test scene

Info

Publication number: CN115599687A
Application number: CN202211333281.3A
Authority: CN
Inventors: 吴泽曦; 周荣林; 张敏; 成文
Original assignee: Agricultural Bank of China
Current assignee: Agricultural Bank of China
Priority date: 2022-10-28
Filing date: 2022-10-28
Publication date: 2023-01-13

Abstract

The embodiment of the invention discloses a method, a device, equipment and a medium for determining a software test scene. The method comprises the following steps: establishing a transaction set to be processed based on target identifications corresponding to requests in software to be tested; wherein the target identifier is generated based on the identifier of the request and the identifier combination of the adjacent requests of the request; processing the transaction set to be processed through a frequent item set determining algorithm, and determining a target frequent item set meeting a preset support threshold; and determining a target association subset based on the confidence between any two non-empty subsets in the target frequent set and a preset confidence threshold, and determining a high-frequency request link based on a target identifier corresponding to the target association subset so as to build a test scene of the software to be tested based on the high-frequency request link. The problem that software testing is incomplete due to the fact that an existing testing scene is determined through manual experience and the testing scene is single is solved, software testing is conducted by determining the testing scene with high relevance, and testing comprehensiveness is improved.

Description

Method, device, equipment and medium for determining software test scene

Technical Field

The invention relates to the technical field of software testing, in particular to a method, a device, equipment and a medium for determining a software testing scene.

Background

In the field of software testing, a manual method is generally adopted for designing and selecting a test scene, and a software tester selects one or more transactions with the largest transaction amount as a high-frequency test scene according to experience or by referring to a system transaction log.

The manual method has two problems, namely, the time consumption is long, the efficiency is low, the method depends on the familiarity of a tester with the system and the testing experience, the manually designed testing scene is isolated and single, more transactions are selected due to factors such as the production transaction amount, the technical complexity and the correlation degree on the business process, and highly correlated products and functions generated by the use mode or the use habit of a client outside the business logic are not considered. That is to say, the determination of the test range of the current system does not take into account the factors of the customer behavior, so that some scenes and functions with extremely high use frequency may be missed, and further, hidden dangers are brought to the safety production. Therefore, how to determine a test scenario with a high use frequency, covering a comprehensive test scenario is a problem that needs to be solved urgently at present.

Disclosure of Invention

The invention provides a method, a device, equipment and a medium for determining a software test scene, which are used for realizing software test based on analysis of a user request and obtaining a test scene with higher relevance, and improving the test comprehensiveness.

According to an aspect of the present invention, a method for determining a software test scenario is provided, where the method includes:

establishing a transaction set to be processed based on target identifications corresponding to requests in software to be tested; wherein the target identifier is generated based on a combination of the identifier of the request and identifiers of neighboring requests of the request;

processing the to-be-processed transaction set through a frequent item set determination algorithm, and determining a target frequent item set meeting a preset support threshold; wherein the target frequent item set is a non-empty subset of the to-be-processed transaction set;

determining a target association subset based on the confidence between any two non-empty subsets in the target frequent set and a preset confidence threshold, and determining a high-frequency request link based on a target identifier corresponding to the target association subset, so as to build a test scene of the software to be tested based on the high-frequency request link.

According to another aspect of the present invention, there is provided an apparatus for determining a software test scenario, the apparatus comprising:

the system comprises a to-be-processed transaction set establishing module, a to-be-processed transaction set establishing module and a processing module, wherein the to-be-processed transaction set establishing module is used for establishing a to-be-processed transaction set based on target identifications corresponding to requests in software to be tested; wherein the target identifier is generated based on a combination of the identifier of the request and identifiers of neighboring requests of the request;

the target frequent item set determining module is used for processing the to-be-processed transaction set through a frequent item set determining algorithm and determining a target frequent item set meeting a preset support threshold; wherein the target frequent item set is a non-empty subset of the to-be-processed transaction set;

and the high-frequency request link determining module is used for determining a target association subset based on the confidence between any two non-empty subsets in the target frequent set and a preset confidence threshold, and determining a high-frequency request link based on a target identifier corresponding to the target association subset so as to build a test scene of the software to be tested based on the high-frequency request link.

According to another aspect of the present invention, there is provided an electronic apparatus including:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores a computer program executable by the at least one processor, the computer program being executable by the at least one processor to enable the at least one processor to perform the method of determining a software test scenario according to any embodiment of the present invention.

According to another aspect of the present invention, there is provided a computer-readable storage medium storing computer instructions for causing a processor to implement the method for determining a software test scenario according to any one of the embodiments of the present invention when the computer instructions are executed.

According to the technical scheme of the embodiment of the invention, a transaction set to be processed is established based on the target identification corresponding to each request in the software to be tested; wherein the target identifier is generated based on a combination of the identifier of the request and identifiers of neighboring requests of the request; processing the to-be-processed transaction set through a frequent item set determination algorithm, and determining a target frequent item set meeting a preset support threshold; wherein the target frequent item set is a non-empty subset of the to-be-processed transaction set; the method comprises the steps of determining a target association subset based on the confidence between any two non-empty subsets in the target frequent set and a preset confidence threshold, determining a high-frequency request link based on a target identifier corresponding to the target association subset, and building a test scene of the software to be tested based on the high-frequency request link, so that the problem that the existing test scene is determined through manual experience, the test scene is single, the software test is incomplete is solved, the test scene with high association is determined to be subjected to the software test, and the test comprehensiveness is improved.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present invention, nor do they necessarily limit the scope of the invention. Other features of the present invention will become apparent from the following description.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

Fig. 1 is a flowchart of a method for determining a software test scenario according to an embodiment of the present invention;

fig. 2 is a flowchart of a method for determining a software test scenario according to a second embodiment of the present invention;

fig. 3 is a flowchart of a method for determining a software test scenario according to a third embodiment of the present invention;

fig. 4 is a schematic structural diagram of a device for determining a software test scenario according to a fourth embodiment of the present invention;

fig. 5 is a schematic structural diagram of an electronic device according to a fifth embodiment of the present invention.

Detailed Description

In order to make those skilled in the art better understand the technical solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are capable of operation in other sequences than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Example one

Fig. 1 is a flowchart of a method for determining a software test scenario according to an embodiment of the present invention, where the embodiment is applicable to a software test situation, and the method may be executed by a device for determining a software test scenario, where the device for determining a software test scenario may be implemented in a form of hardware and/or software, and the device may be configured in an electronic device with computing capability. As shown in fig. 1, the method includes:

s110, establishing a transaction set to be processed based on the target identification corresponding to each request in the software to be tested.

The software to be tested may be software that needs to be tested, such as an application program or a WEB system, and each request refers to a request sent by a user when using the software to be tested, and may be a login request, for example; correspondingly, each request corresponds to a target identifier, and the target identifier is generated based on the identifier of the request and the identifier combination of the adjacent requests of the request; the pending set may be a set comprising a plurality of elements.

Specifically, before testing the software, the target identifiers corresponding to the user requests in the software to be tested may be determined, a set, that is, a transaction set to be processed, is established with all the target identifiers as elements, and then a test scenario with a high association degree may be determined for testing the software according to the processing of the transaction set to be processed.

On the basis, before establishing the to-be-processed transaction set based on the target identifier corresponding to each request in the to-be-tested software, the method further includes: acquiring each request generated in the running of the software to be tested, and setting an identifier corresponding to each request; aiming at each request, determining a target identifier of the current request according to the identifier of the current request and the identifier of an adjacent request of the current request; and establishing a log record table based on each request and the target identifier of each request, so that when the software to be tested is tested, the target identifier corresponding to each request is obtained through the log record table.

The identifier of the current request refers to setting an identifier for each request, which is used to distinguish different requests, for example, the identifier of the login request is 1, the identifier of the logout request is 2, and the log record table may be a database table in which target identifiers corresponding to each request are stored.

Specifically, different user requests are generated during the running or using process of the software to be tested, the requests can be given to corresponding identifiers, and the different requests correspond to different identifiers. For each request, determining an adjacent request of the current request, which may be a previous request of the current request, and combining the identifier of the previous request and the identifier of the current request may generate a target identifier, that is, a target identifier corresponding to the current request. And determining the target identification corresponding to each request according to the mode. Further, each request and the target identifier corresponding to the request are stored in a database in the form of a database table, before software is tested, a log record table in the period can be extracted from the database according to the time periods of days, weeks, months and the like, and then the target identifier is searched from the log record table, so that the to-be-processed transaction set is established based on the target identifier. This has the advantage that the request adjacent to the request can be determined by the target identity of the request in order to determine a request link.

And S120, processing the to-be-processed transaction set through a frequent item set determining algorithm, and determining a target frequent item set meeting a preset support threshold.

The frequent item set determining algorithm may be an Apriori algorithm or an FP-Growth algorithm, and is configured to determine a frequently-occurring subset from the set, where the preset support threshold may be a preset value, and is configured to determine a target frequent item set from the to-be-processed transaction set, where the target frequent item set is a non-empty subset of the to-be-processed transaction set.

Specifically, the frequent item set determining algorithm may determine one or more sets with frequent occurrence times from the to-be-processed transaction set as frequent item sets, specifically, may first determine non-empty subsets included in the to-be-processed transaction set, and calculate a support degree of each non-empty subset, where the support degree is a numerical value representing how frequently the non-empty subsets occur in the to-be-processed transaction set; and if the support degree of the non-empty subset is greater than a preset support degree threshold value, taking the non-empty subset as a target frequent item set. The number of the target frequent item sets can be one or more, and the non-empty subsets meeting the preset support threshold can be used as the target frequent item sets.

S130, determining a target association subset based on the confidence between any two non-empty subsets in the target frequent set and a preset confidence threshold, and determining a high-frequency request link based on a target identifier corresponding to the target association subset so as to build a test scene of the software to be tested based on the high-frequency request link.

The confidence threshold may be a preset value for determining the associated subset meeting the confidence threshold, and the high-frequency request link refers to a request link frequently occurring in software, and represents a user to frequently initiate a request according to the link.

Specifically, the confidence between any two non-empty subsets in the target frequent item may be calculated, and if the confidence of one non-empty subset to another non-empty subset is greater than a preset confidence threshold, it indicates that the two non-empty subsets not only occur frequently, but also have higher relevance, and are strong association rules. At this time, the target identifier corresponding to the target association subset may determine a current request and a previous request corresponding to the target identifier, and after determining a plurality of corresponding requests, the plurality of requests are connected in series to obtain a high-frequency request link, which indicates that the user often uses a corresponding function in the software to be tested according to the high-frequency request link. Therefore, a scene corresponding to the high-frequency request link can be used as a test scene, and the software to be tested can be tested.

In the embodiment, a scene corresponding to the high-frequency request link is used as a test scene to test the software to be tested, and highly-associated products and functions generated due to the use mode or use habit of a client outside the service logic are considered, so that the test scene is enriched, and the efficiency and accuracy of the design of the test scene are improved.

On the basis, the method further comprises the following steps: and dynamically adjusting the preset support threshold and the preset confidence threshold, and determining the test scene of the software to be tested based on the adjusted preset support threshold and the adjusted preset confidence threshold.

In practical application, the preset support threshold and the preset confidence threshold can be dynamically adjusted to obtain a high association test scene set under different conditions, and the strength of the association relationship is dynamically adjusted to further dynamically adjust the test range. The actual customer behavior is captured through the algorithm, the problems that a manual method is long in time consumption, low in efficiency and dependent on experience of testing personnel are solved to a certain extent, the testing scenes are enriched, and the efficiency and accuracy of testing scene design are improved.

Example two

Fig. 2 is a flowchart of a method for determining a software test scenario according to a second embodiment of the present invention, which is based on the above embodiments, and this embodiment describes in detail establishment of a transaction set to be processed, determination of a target frequent item, and determination of a high-frequency request link. The technical terms that are the same as or corresponding to the above embodiments are not repeated herein. As shown in fig. 2, the method includes:

s210, determining a transaction set based on the target identification of each request corresponding to the same user.

The target identifications corresponding to the requests of the same user form a transaction set, and different transaction sets correspond to different users.

It is understood that, the number of users using the software is usually multiple, each user has a corresponding request, and the target identifiers corresponding to the respective requests of the same user can be taken as elements to form a transaction set corresponding to the user.

S220, establishing a to-be-processed transaction set based on the transaction sets corresponding to the users.

Specifically, the transaction sets corresponding to all users form a to-be-processed transaction set, and the to-be-processed transaction set includes the transaction sets of all users, or all target identifiers.

And S230, calculating the support degree of each non-empty subset in the transaction set to be processed based on a frequent item set determination algorithm.

The support degree is determined based on the support number of the non-empty subsets and the number of the transaction sets, and the support number is the number of times of the non-empty subsets appearing in the transaction sets to be processed.

Specifically, for each subset in the transaction set to be processed, the number of times that each subset appears in the transaction set to be processed and the total number of the transaction sets in the transaction set to be processed are determined, and the ratio of the number of times to the total number of the transaction sets is used as the support degree of the non-empty subset.

S240, if the support degree of the non-empty subset meets a preset support degree threshold value, determining the non-empty subset as a target frequent item set.

Specifically, if the support degree of the non-empty subset is greater than the preset support degree threshold, the non-empty subset may be used as the target frequent item set. On the contrary, if the support degree of the non-empty subset is less than the preset support degree threshold value, the non-empty subset cannot be used as the target frequent item set.

S250, aiming at any two non-empty subsets, determining a first support degree of the first non-empty subset in the to-be-processed transaction set and a second support degree of a set formed by the first non-empty subset and the second non-empty subset in the to-be-processed transaction set.

Specifically, after the target frequent item set is determined, two subsets of the target frequent items are randomly selected as a first non-empty subset and a second non-empty subset, and a first support degree of the first non-empty subset and a second support degree formed by the first non-empty subset and the second non-empty subset are calculated, where a calculation method of the support degree is not described herein again.

And S260, determining a confidence coefficient between the first non-empty subset and the second non-empty subset based on the ratio of the second support degree to the first support degree, and if the confidence coefficient is greater than a preset confidence coefficient threshold value, determining the first non-empty subset and the second non-empty subset as target associated subsets.

Specifically, the ratio of the second support degree to the first support degree may be used as the confidence between the first non-empty subset and the second non-empty subset, and if the confidence is greater than the preset confidence threshold, the two subsets may be used as the target association subsets, that is, the two subsets have strong association. In the above manner, all target association subsets in the target frequent item set that meet the confidence threshold are determined.

S270, determining a high-frequency request link based on the target identification corresponding to the target association subset, and building a test scene of the software to be tested based on the high-frequency request link.

On the basis, the high-frequency request link is determined based on the target identification corresponding to the target association subset, so as to build a test scene of the software to be tested based on the high-frequency request link, and the method comprises the following steps: determining each target request associated with the target identifier based on at least two target identifiers corresponding to the target association subset; and processing each target request link to obtain a high-frequency request link, and performing deduplication processing on a scene corresponding to the high-frequency request link to obtain a test scene of the software to be tested.

In practical application, the target association subsets correspond to two non-empty subsets, each subset element has a corresponding target identifier, that is, at least two target identifiers in total, and the target identifiers correspond to identifiers of two requests, so that all the requests can be connected in series based on the request identifiers to obtain a high-frequency request link, and a scene corresponding to the high-frequency request link is subjected to deduplication processing, and the finally obtained scene is a test scene of the software to be tested.

EXAMPLE III

Fig. 3 is a flowchart of a method for determining a software test scenario according to a third embodiment of the present invention, where this embodiment is a preferred embodiment of the foregoing implementation, and a specific implementation manner of this embodiment may refer to a technical solution of this embodiment. The technical terms that are the same as or corresponding to the above embodiments are not repeated herein. As shown in fig. 3, the method includes:

and S300, determining an object needing to be subjected to dynamic test scene design.

For example, user behavior in a certain time period of a certain Web system is analyzed, and then a test scenario with high relevance is determined for system test.

S310, designing a log record table based on production transaction data, wherein each request in the Web system marks the presence of a chain-id to a user.

An id identifier is set for each request of a user in the Web system, and the id of the last request (the last item) is set as a request-id. The id and the request-id are combined to form a chain-id, and the chain-id is used as an item to record a database table.

And S320, sampling. Collecting periodic samples according to time periods of day, week, month and the like, and extracting a log record table in the period.

S330, integrating a log record table in the collected production transaction data period sample to form a transaction set D according to the chain-id of the user, and taking the transaction set D as the basis of the association rule mining.

And integrating the log record table to form a transaction set. According to the chain-id of a single user in a database table, completely traversing all k requests of the user in the process of login to logout and integrating the k requests into 1 transaction, and recording the transaction as T, wherein T is a k-item set with the length of k, and each element in the item set T is the chain-id. And traversing all the client requests T1, T2 and … … in sequence, and integrating to form a transaction set D = { T1, T2, T3, … and Tn }.

S340, dynamically setting the minimum support degree and the minimum confidence degree of the association rule to be SUPmin and CONFmin respectively.

And S350, excavating a frequent item set I by using an Apriori algorithm or an FP-growth algorithm based on the transaction set D and the minimum support SUPmin.

And (4) performing data mining based on the transaction set D and the dynamically set minimum support SUPmin value to generate frequent item sets. And (3) mining a frequent item set I by using an Apriori algorithm or an FP-growth algorithm aiming at a transaction set D = { T1, T2, T3, …, tn }, wherein the I is an item set with the support degree not less than SUPmin.

And S360, data mining is carried out based on the frequent item set I and the minimum confidence coefficient CONFmin, and a strong association rule is obtained.

And (4) carrying out data mining based on the frequent item set I and the dynamically set minimum confidence coefficient CONFmin numerical value to obtain a strong association rule. For each set of frequent items I, all non-empty subsets of I are generated, and for each non-empty subset s of I, if s is greater than the confidence of I-s, support _ count (I)/support _ count(s) > = CONFmin, the rule "s- - > (I-s)" is output. Since the rules are generated from a frequent set of items, each rule automatically satisfies the minimum support SUPmin, and strong association rules can be generated as long as the minimum confidence CONFmin is greater than or equal to the recalculated minimum support SUPmin.

And S370, sequentially traversing all strong association rules, and determining a transaction scene with higher association degree.

And dynamically determining a high-association transaction scene according to the strong association rule. And (3) excavating frequent item sets, finding M strong association rules in total, and for each strong association rule's- - > (I-s)', connecting transaction full links in series according to the chian-id of items in the item sets s and the I-s, thereby determining a transaction scene with higher association degree. And sequentially traversing all strong association rules to determine M transaction scenes with higher association degree.

And S380, carrying out duplicate removal, combination and application on the transaction scenes, wherein the finally formed set is a test scene set with higher association.

And (4) combining and applying the transaction scenes to determine the test scenes with higher association. And removing duplication from the M transaction scenes, wherein the finally formed set is a test scene set with higher association degree, and the set considers the factors of customer behaviors, is used as a scene and a function with extremely high use frequency, and can be used for performing system test on the Web system. The set does not have repeated transaction paths, and the test scenario with the longest transaction link is the longest transaction path of the Web system user.

And S390, dynamically adjusting the values of the minimum support SUPmin and the minimum confidence CONFmin, and dynamically obtaining a high-association test scene set under different conditions.

In this embodiment, by sampling the user behavior of the Web system within a certain time period, the problem of how to determine a test scenario with a higher association for performing system testing can be solved. According to the technical scheme, all requests of a user from login to logout are completely traversed through a log record table design mode of marking chain-id for each request of the user in a Web system, so that a transaction set D is formed by integrating log record tables in collected production transaction data period samples and is used as a basis for association rule mining.

The technical scheme of the embodiment is a design and integration method based on a log record table of production transaction data and a transaction set. And setting an id identifier for each request of a user in the Web system, and setting the id of the last request as a request-id. The id and the request-id are combined to form a chain-id, and the chain-id is used as an item to record a database table. According to the chain-id of a single user in a database table, completely traversing all k requests of the user in the process of login to logout and integrating the k requests into 1 transaction, wherein the transaction is marked as T, T is a k-item set with the length of k, and each element in the item set T is the chain-id. And traversing all the client requests T1, T2 and … … in sequence, and integrating to form a transaction set D = { T1, T2, T3, … and Tn }. And dynamically setting a minimum support degree SUPmin and a minimum confidence degree CONFmin of the association rule. Excavating a frequent item set I by using an Apriori algorithm or an FP-growth algorithm based on a transaction set D and a minimum support SUPmin; and (4) performing data mining based on the frequent item set I and the minimum confidence coefficient CONFmin to obtain a strong association rule. And traversing all strong association rules in sequence to determine a transaction scene with higher association degree. And performing duplicate removal, combination and application on the transaction scenes, wherein the finally formed set is a test scene set with higher association, the set considers the factors of customer behaviors, is used as a scene and a function with extremely high use frequency, and can be used for performing system test on the Web system. And dynamically adjusting the values of the minimum support degree SUPmin and the minimum confidence degree CONFmin, so as to dynamically obtain a high-association test scene set under different conditions. The method can dynamically determine the test scene with higher relevance. Aiming at a transaction table D = { T1, T2, T3, …, tn }, mining a frequent item set by using an Apriori algorithm or an FP-Growth algorithm, finding strong association rules, and then sequencing the strong association rules from high to low according to confidence degrees, wherein the total number of the strong association rules is M. And for each strong association rule's- > (I-s)', serially connecting a transaction full link according to the item sets s and the chian-id of the items in the I-s, thereby determining a transaction scene with high association degree. And sequentially traversing all strong association rules to determine M transaction scenes with higher association degree. And removing duplication from the M transaction scenes, wherein a set formed finally is a test scene set with high association degree, the set considers the factors of customer behaviors, is used as a scene and a function with extremely high use frequency, and can be used for performing system test on the Web system. The set does not have repeated transaction paths, and the test scenario with the longest transaction link is the longest transaction path of the Web system user. And dynamically adjusting the values of the minimum support degree SUPmin and the minimum confidence degree CONFmin, so as to dynamically obtain a high-association test scene set under different conditions.

According to the technical scheme of the embodiment of the invention, a transaction set to be processed is established based on the target identification corresponding to each request in the software to be tested; wherein the target identifier is generated based on a combination of the identifier of the request and identifiers of neighboring requests of the request; processing the to-be-processed transaction set through a frequent item set determination algorithm, and determining a target frequent item set meeting a preset support threshold; wherein the target frequent item set is a non-empty subset of the to-be-processed transaction set; the method comprises the steps of determining a target association subset based on the confidence between any two non-empty subsets in the target frequent set and a preset confidence threshold, determining a high-frequency request link based on a target identifier corresponding to the target association subset, and setting up a test scene of the software to be tested based on the high-frequency request link, so that the problem that the existing test scene is determined through manual experience and the test scene is single, so that the software test is incomplete is solved, the test scene with high association is determined to perform the software test, and the test comprehensiveness is improved.

Example four

Fig. 4 is a schematic structural diagram of a device for determining a software test scenario according to a fourth embodiment of the present invention. As shown in fig. 4, the apparatus includes:

a pending transaction set establishing module 410, configured to establish a pending transaction set based on a target identifier corresponding to each request in the software to be tested; wherein the target identifier is generated based on a combination of the identifier of the request and identifiers of neighboring requests of the request;

a target frequent item set determining module 420, configured to process the to-be-processed transaction set through a frequent item set determining algorithm, and determine a target frequent item set that meets a preset support threshold; wherein the target frequent item set is a non-empty subset of the to-be-processed transaction set;

the high-frequency request link determining module 430 determines a target association subset based on the confidence between any two non-empty subsets in the target frequent set and a preset confidence threshold, and determines a high-frequency request link based on a target identifier corresponding to the target association subset, so as to build a test scenario of the software to be tested based on the high-frequency request link.

On the basis of the device, the device further comprises:

the identification acquisition module is used for acquiring each request generated in the running of the software to be tested and setting an identification corresponding to each request;

a target identifier determining module, configured to determine, for each request, a target identifier of a current request according to an identifier of the current request and identifiers of neighboring requests of the current request;

and establishing a log record table based on each request and the target identifier of each request, so that when the software to be tested is tested, the target identifier corresponding to each request is obtained through the log record table.

On the basis of the above apparatus, the pending transaction set creating module 410 includes:

the transaction set determining module is used for determining a transaction set based on the target identification of each request corresponding to the same user;

and the to-be-processed transaction set determining module is used for establishing the to-be-processed transaction set based on the transaction set corresponding to each user.

On the basis of the foregoing apparatus, the target frequent item set determining module 420 includes:

the support degree determining module is used for calculating the support degree of each non-empty subset in the transaction set to be processed based on the frequent item set determining algorithm; the support degree is determined based on the support number of the non-empty subset and the number of the transaction sets, and the support number is the number of times of the non-empty subset appearing in the transaction set to be processed;

and the support degree judging module is used for determining the non-empty subset as the target frequent item set if the support degree of the non-empty subset meets the preset support degree threshold value.

On the basis of the above device, the high frequency request link determining module 430 includes:

the first and second support degree determining modules are used for determining a first support degree of a first non-empty subset in the set of the to-be-processed transactions and a second support degree of a set formed by the first non-empty subset and a second non-empty subset in the set of the to-be-processed transactions aiming at any two non-empty subsets;

and the confidence degree judging module is used for determining the confidence degree between the first non-empty subset and the second non-empty subset based on the ratio of the second support degree to the first support degree, and if the confidence degree is greater than the preset confidence degree threshold, determining the first non-empty subset and the second non-empty subset as target associated subsets.

a target request determining module, configured to determine, based on at least two target identifiers corresponding to the target association subset, each target request associated with the target identifier;

and the test scene determining module is used for obtaining the high-frequency request link by processing each target request link and carrying out deduplication processing on a scene corresponding to the high-frequency request link so as to obtain a test scene of the software to be tested.

According to the technical scheme of the embodiment of the invention, a transaction set to be processed is established based on the target identification corresponding to each request in the software to be tested; wherein the target identifier is generated based on a combination of the identifier of the request and identifiers of neighboring requests of the request; processing the transaction set to be processed through a frequent item set determining algorithm, and determining a target frequent item set meeting a preset support threshold; wherein the target frequent item set is a non-empty subset of the to-be-processed transaction set; the method comprises the steps of determining a target association subset based on the confidence between any two non-empty subsets in the target frequent set and a preset confidence threshold, determining a high-frequency request link based on a target identifier corresponding to the target association subset, and building a test scene of the software to be tested based on the high-frequency request link, so that the problem that the existing test scene is determined through manual experience, the test scene is single, the software test is incomplete is solved, the test scene with high association is determined to be subjected to the software test, and the test comprehensiveness is improved.

The device for determining the software test scenario provided by the embodiment of the invention can execute the method for determining the software test scenario provided by any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

EXAMPLE five

Fig. 5 is a schematic structural diagram of an electronic device according to a fifth embodiment of the present invention. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed herein.

As shown in fig. 5, the electronic device 50 includes at least one processor 51, and a memory communicatively connected to the at least one processor 51, such as a Read Only Memory (ROM) 52, a Random Access Memory (RAM) 53, and the like, wherein the memory stores a computer program executable by the at least one processor, and the processor 51 may perform various suitable actions and processes according to the computer program stored in the Read Only Memory (ROM) 52 or the computer program loaded from a storage unit 58 into the Random Access Memory (RAM) 53. In the RAM 53, various programs and data necessary for the operation of the electronic apparatus 50 can also be stored. The processor 51, the ROM 52, and the RAM 53 are connected to each other via a bus 54. An input/output (I/O) interface 55 is also connected to bus 54.

A plurality of components in the electronic apparatus 50 are connected to the I/O interface 55, including: an input unit 56 such as a keyboard, a mouse, or the like; an output unit 57 such as various types of displays, speakers, and the like; a storage unit 58 such as a magnetic disk, an optical disk, or the like; and a communication unit 59 such as a network card, modem, wireless communication transceiver, etc. The communication unit 59 allows the electronic device 50 to exchange information/data with other devices via a computer network such as the internet and/or various telecommunication networks.

The processor 51 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of the processor 51 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various dedicated Artificial Intelligence (AI) computing chips, various processors running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, or the like. The processor 51 performs the various methods and processes described above, such as the determination of software test scenarios.

In some embodiments, the method of determining a software test scenario may be implemented as a computer program tangibly embodied in a computer-readable storage medium, such as storage unit 58. In some embodiments, part or all of the computer program may be loaded and/or installed onto the electronic device 50 via the ROM 52 and/or the communication unit 59. When the computer program is loaded into the RAM 53 and executed by the processor 51, one or more steps of the above described method of determining a software test scenario may be performed. Alternatively, in other embodiments, the processor 51 may be configured by any other suitable means (e.g., by means of firmware) to perform the determination method of the software test scenario.

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), system on a chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

Computer programs for implementing the methods of the present invention can be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the computer programs, when executed by the processor, cause the functions/acts specified in the flowchart and/or block diagram block or blocks to be performed. A computer program can execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present invention, a computer-readable storage medium may be a tangible medium that can contain, or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. A computer readable storage medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Alternatively, the computer readable storage medium may be a machine readable signal medium. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user may provide input to the electronic device. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), blockchain networks, and the Internet.

The computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also called a cloud computing server or a cloud host, and is a host product in a cloud computing service system, so that the defects of high management difficulty and weak service expansibility in the traditional physical host and VPS service are overcome.

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present invention may be executed in parallel, sequentially, or in different orders, and are not limited herein as long as the desired results of the technical solution of the present invention can be achieved.

The above-described embodiments should not be construed as limiting the scope of the invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for determining a software test scenario is characterized by comprising the following steps:

2. The method of claim 1, before establishing the set of transactions to be processed based on the target identifier corresponding to each request in the software to be tested, further comprising:

acquiring each request generated in the running of the software to be tested, and setting an identifier corresponding to each request;

aiming at each request, determining a target identifier of the current request according to the identifier of the current request and the identifier of an adjacent request of the current request;

3. The method of claim 1, wherein the establishing a set of transactions to be processed based on the target identifier corresponding to each request in the software to be tested comprises:

determining a transaction set based on target identifications of all requests corresponding to the same user;

and establishing the transaction set to be processed based on the transaction set corresponding to each user.

4. The method according to claim 3, wherein the determining a target frequent item set that meets a preset support threshold by processing the to-be-processed transaction set through a frequent item set determination algorithm comprises:

calculating the support degree of each non-empty subset in the transaction set to be processed based on the frequent item set determination algorithm; the support degree is determined based on the support number of the non-empty subset and the number of the transaction sets, and the support number is the number of times of the non-empty subset appearing in the transaction set to be processed;

and if the support degree of the non-empty subset meets the preset support degree threshold value, determining the non-empty subset as the target frequent item set.

5. The method of claim 4, wherein determining a target association subset based on a confidence between any two non-empty subsets in the target frequent set and a preset confidence threshold comprises:

for any two non-empty subsets, determining a first support degree of a first non-empty subset in the set of transactions to be processed and a second support degree of a set consisting of the first non-empty subset and a second non-empty subset in the set of transactions to be processed;

determining a confidence level between the first non-empty subset and the second non-empty subset based on a ratio of the second support level to the first support level, and determining the first non-empty subset and the second non-empty subset as target associated subsets if the confidence level is greater than the preset confidence level threshold.

6. The method according to claim 5, wherein the determining a high-frequency request link based on the target identifier corresponding to the target association subset to build a test scenario of the software to be tested based on the high-frequency request link comprises:

determining each target request associated with the target identifier based on at least two target identifiers corresponding to the target association subset;

and obtaining the high-frequency request link by processing each target request link, and performing deduplication processing on a scene corresponding to the high-frequency request link to obtain a test scene of the software to be tested.

7. The method of claim 1, further comprising:

and dynamically adjusting the preset support threshold and the preset confidence threshold, and determining the test scene of the software to be tested based on the adjusted preset support threshold and the adjusted preset confidence threshold.

8. An apparatus for determining a software test scenario, comprising:

the to-be-processed transaction set establishing module is used for establishing a to-be-processed transaction set based on the target identification corresponding to each request in the to-be-tested software; wherein the target identifier is generated based on a combination of the identifier of the request and identifiers of neighboring requests of the request;

9. An electronic device, characterized in that the electronic device comprises:

at least one processor; and

the memory stores a computer program executable by the at least one processor, the computer program being executable by the at least one processor to enable the at least one processor to perform the method of determining a software test scenario of any one of claims 1-7.

10. A computer-readable storage medium storing computer instructions for causing a processor to implement the method for determining a software test scenario of any one of claims 1-7 when executed.