Software testing method and device, electronic equipment, storage medium and program product

Abstract

The present disclosure provides a software testing method, which relates to the field of business architecture and can also be used in the field of finance or other fields. The software testing method comprises: obtaining programs whose production versions change from a plurality of programs to obtain a list of changed programs; extracting business functions having a mapping relationship with the programs from a plurality of business functions to obtain target business functions for at least one program in the list of changed programs; determining business scenarios using the target business functions to obtain at least one to-be-tested business scenario; obtaining a transaction volume of the at least one to-be-tested business scenario, and evaluating a risk level of the to-be-tested business scenario; sorting the obtained to-be-tested business scenarios according to the transaction volume and the risk level to obtain a to-be-tested list; and sending the to-be-tested list to a test end to enable the test end to perform testing according to the to-be-tested list. The present disclosure also provides a software testing device, an electronic device, a storage medium and a program product.

Description

Technical Field

[0001] This disclosure relates to the field of business architecture, but can also be used in the financial field or other fields, specifically to a software testing method, apparatus, electronic device, storage medium and program product. Background Technology

[0002] To adapt to the development requirements of digital banking, commercial banks need to understand industry trends and analyze the threats and opportunities facing businesses. A business architecture can provide a comprehensive view of the relationships between various business operations within a commercial bank, facilitating the analysis of these threats and opportunities.

[0003] Currently, companies are focusing more on user experience and production operations in order to enhance their competitiveness. Under this R&D model, accurately defining the scope of software that needs testing has become a pressing technical problem. Summary of the Invention

[0004] In view of the above problems, this disclosure provides a software testing method, apparatus, electronic device, storage medium, and program product.

[0005] According to a first aspect of this disclosure, a software testing method is provided, applied in an architecture management system, the architecture management system including a business architecture and an IT architecture, the business architecture including multiple business functions and business scenarios using at least one of the business functions, the IT architecture including multiple programs, wherein the software testing method includes:

[0006] From multiple programs, obtain the programs that have changed in the production version to obtain a list of changed programs;

[0007] For at least one program in the modified program list, extract the business functions that have a mapping relationship with the program from multiple business functions to obtain the target business function;

[0008] Identify the business scenarios that use the target business function to obtain at least one business scenario to be tested;

[0009] Obtain the transaction volume of at least one of the business scenarios under test, and assess the risk level of the business scenarios under test;

[0010] Based on the transaction volume and the risk level, the obtained business scenarios to be tested are sorted to obtain a list of scenarios to be tested;

[0011] The test list is sent to the test terminal so that the test terminal can perform tests based on the test list.

[0012] According to embodiments of this disclosure, assessing the risk level of the business scenario under test includes:

[0013] The type of the business scenario to be tested is determined based on the customer information and / or business information of the business scenario to be tested;

[0014] The risk level of the business scenario to be tested is determined based on the pre-configured risk level and the correspondence between the types.

[0015] According to embodiments of this disclosure, the risk level includes a first risk level, and the step of sorting the obtained business scenarios to be tested based on the transaction volume and the risk level includes:

[0016] Extract the business scenarios to be tested with the risk level of the first risk level to obtain the first business scenario to be tested;

[0017] Based on the first risk level, the extracted first business scenarios to be tested are sorted to obtain a first sequence;

[0018] The first business scenario to be tested in the first sequence is sorted according to the transaction volume.

[0019] According to embodiments of this disclosure, the risk level includes a second risk level, which is lower than the first risk level. The step of sorting the obtained business scenarios to be tested based on the transaction volume and the risk level further includes:

[0020] Extract the business scenarios to be tested with a risk level of the second risk level to obtain the second business scenario to be tested;

[0021] Based on the transaction volume of the second business scenario to be tested, the extracted second business scenarios to be tested are sorted to obtain a second sequence.

[0022] The second business scenarios to be tested in the second sequence are sorted according to the second risk level.

[0023] According to embodiments of this disclosure, before sending the list of devices to be tested to the testing terminal, the software testing method further includes:

[0024] Obtain the workload of the test list and the testing capabilities of the test terminal;

[0025] Based on the workload of the test list and the testing capabilities of the testing terminal, at least a portion of the test list is selected and assigned recommended test tags.

[0026] According to embodiments of this disclosure, the workload of obtaining the list of items to be tested includes:

[0027] Determine whether the business scenario to be tested is a newly added business scenario;

[0028] If not, calculate the workload of the business scenario under test based on the existing test time of the business scenario under test;

[0029] If so, calculate the testing workload of the business scenario under test based on the number of business functions used in the business scenario under test; wherein, among the business functions used in the business scenario under test, the workload of the business functions that have changed is greater than the workload of the business functions that have not changed.

[0030] According to embodiments of this disclosure, acquiring the testing capabilities of the testing terminal includes:

[0031] Obtain the available test time for at least one test point in the test terminal;

[0032] Summarize the available test time obtained;

[0033] The testing capabilities of the testing terminal are determined based on the aggregated available testing time.

[0034] According to embodiments of this disclosure, the test list includes multiple test scenarios arranged according to preset rules. The step of selecting at least a portion of the test list and assigning recommended test tags based on the workload of the test list and the testing capabilities of the testing terminal includes:

[0035] For each business scenario to be tested in the test list, calculate the sum of the workload of the business scenario to be tested and the workload of the business scenarios to be tested preceding the business scenario to be tested, so as to obtain the test workload corresponding to each business scenario to be tested.

[0036] Based on the matching degree between the testing capabilities of the testing terminal and the testing workload of each of the business scenarios to be tested, the target business scenarios to be tested are determined from the business scenarios to be tested in the list of business scenarios to be tested.

[0037] Select a target business scenario to be tested from the list of business scenarios to be tested, as well as the business scenarios to be tested that precede the target business scenario to be tested, to obtain recommended business scenarios to be tested;

[0038] Assign recommended test tags to the recommended business scenarios to be tested.

[0039] According to embodiments of this disclosure, the software testing method further includes:

[0040] Obtain the test results from the test server;

[0041] Based on the test results, confirm the test coverage of at least one of the business functions used in the business scenario under test;

[0042] A test evaluation report is generated based on the test coverage of the business functions used in each of the aforementioned business scenarios to be tested.

[0043] According to embodiments of this disclosure, the production versions of the programs listed in the modified program list are identical.

[0044] A second aspect of this disclosure provides a software testing apparatus applied in an architecture management system, the architecture management system including a business architecture and an IT architecture, the business architecture including multiple business functions and at least one business scenario to which said business function applies, the IT architecture including multiple programs, wherein the software testing apparatus includes:

[0045] The first acquisition module is used to acquire the programs that have changed in the production version from multiple programs, so as to obtain a list of changed programs;

[0046] An extraction module is used to extract, from multiple business functions, the business functions that have a mapping relationship with the program for at least one program in the modified program list, so as to obtain the target business function;

[0047] The first processing module is used to determine the business scenario to which the target business function is applicable, so as to obtain at least one business scenario to be tested.

[0048] The second processing module is used to obtain the transaction volume of at least one of the business scenarios under test, and to assess the risk level of the business scenarios under test.

[0049] The test list generation module is used to sort the obtained test business scenarios according to the transaction volume and the risk level to obtain the test list.

[0050] The push module is used to send the list of items to be tested to the test terminal so that the test terminal can perform tests based on the list of items to be tested.

[0051] According to embodiments of this disclosure, the software testing apparatus further includes:

[0052] The second acquisition module is used to acquire the test results from the test terminal;

[0053] The third processing module is used to confirm the test coverage of at least one of the business functions used in the business scenario under test based on the test results.

[0054] The test evaluation report generation module is used to generate a test evaluation report based on the test coverage of the business functions used in each of the business scenarios under test.

[0055] A third aspect of this disclosure provides an electronic device comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the software testing method described above.

[0056] A fourth aspect of this disclosure also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the software testing method described above.

[0057] The fifth aspect of this disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the software testing method described above.

[0058] The above one or more embodiments have the following advantages or benefits:

[0059] In the architecture management system, the business scenarios affected by the changed program can be identified, thereby forming a test list to clarify the testing scope. Furthermore, embodiments of this disclosure can sort the test scenarios in the test list, allowing the testing end to selectively perform tests based on the sorting after the test list is pushed to the testing end, making the testing more targeted and improving its effectiveness. Attached Figure Description

[0060] The foregoing contents, as well as other objects, features, and advantages of this disclosure, will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0061] Figure 1 The illustrations depict application scenarios of software testing methods, apparatus, electronic devices, storage media, and program products according to embodiments of the present disclosure.

[0062] Figure 2 One of the flowcharts of a software testing method according to an embodiment of the present disclosure is illustrated schematically;

[0063] Figure 3 A flowchart illustrating the assessment of risk levels according to embodiments of this disclosure is shown schematically.

[0064] Figure 4a One of the flowcharts illustrating the sorting of service scenarios under test according to an embodiment of this disclosure is illustrated.

[0065] Figure 4b This schematically illustrates a second flowchart of sorting the service scenarios under test according to an embodiment of the present disclosure;

[0066] Figure 5 A second flowchart illustrating a software testing method according to an embodiment of the present disclosure is shown schematically.

[0067] Figure 6a A flowchart illustrating the workload of obtaining a list of tests according to an embodiment of this disclosure is shown schematically.

[0068] Figure 6b A flowchart illustrating the acquisition of testing capabilities of a testing terminal according to an embodiment of this disclosure is shown schematically.

[0069] Figure 7 A flowchart illustrating the allocation of recommended test labels according to embodiments of the present disclosure is shown schematically;

[0070] Figure 8 A flowchart of a software testing method according to an embodiment of the present disclosure is illustrated schematically;

[0071] Figure 9 A schematic block diagram of a software testing apparatus according to an embodiment of the present disclosure is shown.

[0072] Figure 10 A block diagram schematically illustrates an electronic device suitable for implementing a software testing method according to an embodiment of the present disclosure. Detailed Implementation

[0073] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0074] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0075] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0076] When using expressions such as "at least one of A, B, and C", they should generally be interpreted in accordance with the meaning that is commonly understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B, and C, etc.).

[0077] It should be noted that the software testing methods, apparatus, electronic devices, storage media, and program products provided in this disclosure relate to the business architecture field. The software testing methods, apparatus, electronic devices, storage media, and program products provided in the embodiments of this disclosure can be applied to the financial field or any field other than the financial field; this disclosure does not limit the application field of the software testing methods, apparatus, electronic devices, storage media, and program products.

[0078] In the technical solution disclosed herein, the collection, storage, use, processing, transmission, provision, disclosure, and application of user personal information comply with the provisions of relevant laws and regulations, necessary confidentiality measures have been taken, and there is no violation of public order and good morals.

[0079] This disclosure provides a software testing method applied in an architecture management system. The architecture management system includes a business architecture and an IT architecture. The business architecture includes multiple business functions and business scenarios using at least one business function. The IT architecture includes multiple programs. The software testing method includes: obtaining a list of modified programs from the multiple programs, identifying programs whose production versions have been modified; for at least one program in the list of modified programs, extracting business functions that have a mapping relationship with the program from the multiple business functions to obtain a target business function; determining business scenarios using the target business function to obtain at least one business scenario to be tested; obtaining the transaction volume of at least one business scenario to be tested and assessing the risk level of the business scenario to be tested; sorting the obtained business scenarios to be tested according to the transaction volume and risk level to obtain a list of scenarios to be tested; and sending the list of scenarios to be tested to a testing terminal so that the testing terminal can perform tests according to the list of scenarios to be tested.

[0080] Using the testing method of this disclosure, in the architecture management system, the business scenarios affected by the changed program can be located based on the changed program, thereby forming a test list to clarify the testing scope. Furthermore, embodiments of this disclosure can also sort the test scenarios in the test list, so that after the test list is pushed to the testing end, the testing end can selectively perform tests according to the sorting, making the testing more targeted and improving the effectiveness of the testing.

[0081] Figure 1 The illustrations depict application scenarios of software testing methods, apparatus, electronic devices, storage media, and program products according to embodiments of this disclosure. Figure 1 As shown, application scenario 100 according to this embodiment may include terminal devices 101, 102, and 103, network 104, and server 105. Network 104 is used as a medium to provide a communication link between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0082] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0083] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0084] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using terminal devices 101, 102, and 103 (for example only). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0085] It should be noted that the software testing method provided in this disclosure embodiment can generally be executed by server 105. Correspondingly, the software testing apparatus provided in this disclosure embodiment can generally be located in server 105. The software testing method provided in this disclosure embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105. Correspondingly, the software testing apparatus provided in this disclosure embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105.

[0086] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0087] The following will be based on Figure 1 The described scene, through Figures 2 to 8 The software testing method of the disclosed embodiments is described in detail.

[0088] This disclosure provides a software testing method applied in an architecture management system. The architecture management system includes a business architecture and an IT architecture. The business architecture includes multiple business functions and business scenarios using at least one business function. The IT architecture includes multiple programs.

[0089] Figure 2A flowchart illustrating one of the software testing methods according to an embodiment of this disclosure is shown schematically, such as... Figure 2 As shown, the software testing in this embodiment includes steps S210 to S260. It should be noted that, although Figure 2 The steps in the diagram are shown sequentially as indicated by the arrows; however, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated herein, there is no strict order constraint on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the diagram may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0090] In step S210, the programs that have been modified in the production version are obtained from multiple programs to obtain a list of modified programs.

[0091] In this embodiment of the disclosure, information such as business architecture, IT architecture, the interface relationship between each business function in the business architecture and the programs in the IT architecture, business architecture or IT architecture change registration, and the production version of each program in the IT architecture can be obtained from the architecture management system. Whether the production version of a program has changed can be determined based on the production version number of the program. For example, for program A that is put into production on day N, its production version number is N1. If program A is put into production on day N+X, its production version number is N2. At this time, it can be determined that the production version of program A has changed.

[0092] In step S220, for at least one program in the change program list, the business functions that have a mapping relationship with the program are extracted from multiple business functions to obtain the target business function.

[0093] In this embodiment of the disclosure, in the architecture management system, a mapping relationship is configured between business functions in the business architecture and programs in the IT architecture. Business functions implement corresponding functions by using programs with which they have a mapping relationship. Therefore, in step S220, by extracting business functions with a mapping relationship to programs in the change program list, all business functions using this program can be found.

[0094] In step S230, the business scenarios that use the target business function are determined to obtain at least one business scenario to be tested.

[0095] In this embodiment of the disclosure, the architecture management system is also configured with information such as the applicable business scenarios for each business function in the business architecture. Therefore, after obtaining the target business function, the applicable business scenarios for the target business function can be obtained, thereby finding the business scenarios that use the target business function.

[0096] In step S240, the transaction volume of at least one business scenario to be tested is obtained, and the risk level of the business scenario to be tested is assessed.

[0097] In this embodiment of the disclosure, the transaction volume of each business scenario under test can be obtained from the production link log. The production link log may include multiple links, and at least one link consists of the program corresponding to the business function used by a business scenario. In the link, the link header includes the business scenario.

[0098] Optionally, the transaction volume within a predetermined period can be obtained. For example, the predetermined period can be "one day". That is, in this embodiment of the disclosure, the transaction volume of the business scenario under test for one day can be obtained.

[0099] Optionally, in this embodiment of the disclosure, the risk level of the business scenario under test can be assessed based on the customers and services involved. For example, the more customers involved in the business scenario under test, the higher the risk level; conversely, the fewer customers involved, the lower the risk level. As another example, the more important the services involved, the higher the risk level; conversely, the more common the services involved, the lower the risk level.

[0100] In step S250, the obtained business scenarios to be tested are sorted according to transaction volume and risk level to obtain a list of scenarios to be tested.

[0101] In this embodiment of the disclosure, the sorting method can be determined according to the risk level of the business scenario under test. For example, it can be sorted first by transaction volume and then by risk level; or it can be sorted first by risk level and then by transaction volume; or some business scenarios under test can be sorted first by risk level and then by transaction volume, while other business scenarios under test can be sorted first by transaction volume and then by risk level, etc.

[0102] In step S260, the list of items to be tested is sent to the test terminal so that the test terminal can perform tests based on the list of items to be tested.

[0103] In this embodiment of the disclosure, the business scenarios to be tested in the test list are arranged in a predetermined order. When the test terminal performs the test, it can select a portion of the business scenarios to be tested based on its own test resources. For example, it can select a portion of the business scenarios to be tested at the beginning of the test list.

[0104] Using the testing method of this disclosure, in the architecture management system, the business scenarios affected by the changed program can be located based on the changed program, thereby forming a test list to clarify the testing scope. Furthermore, embodiments of this disclosure can also sort the test scenarios in the test list, so that after the test list is pushed to the testing end, the testing end can selectively perform tests according to the sorting, making the testing more targeted and improving the effectiveness of the testing.

[0105] The following is combined Figures 2 to 9 The software testing method of the present disclosure embodiments will be further described.

[0106] In some specific embodiments, the production versions of the programs in the modified program list are the same.

[0107] In this embodiment of the disclosure, modified programs and their planned production dates can be queried from the architecture management system. The program is then assigned to the corresponding production version based on its production date. Subsequently, programs with the same production version constitute a test list.

[0108] Figure 3 A flowchart illustrating the risk level assessment according to an embodiment of this disclosure is shown, such as... Figure 3 As shown, in some specific embodiments, step S240 includes steps S241 to S242.

[0109] In step S241, the type of the business scenario to be tested is determined based on the customer information and / or business information of the business scenario to be tested.

[0110] In this embodiment of the disclosure, customer information may include the types of customers involved in the business scenario under test. For example, the business scenario under test may involve a certain type of customer, or it may involve multiple or even all types of customers. Business information may include information such as the business type, business channels, and partners involved in the business scenario under test.

[0111] Optionally, the type of the test scenario can be determined based on either the business or the customers involved. For example, if the test scenario may involve all types of customers (businesses), it indicates a large impact and can be considered a Type 1 scenario. If the test scenario may involve a specific type of customer (business), it indicates a moderate impact and can be considered a Type 2 scenario. If the test scenario may involve a sub-type of customers (businesses) under a specific type of customer, it indicates a small impact and can be considered a Type 3 scenario.

[0112] Optionally, the type of business involved in the business scenario under test can be determined based on information such as the frequency of occurrence of the scenario. For example, if the business scenario under test occurs frequently, it can be considered that the business type involved in the scenario is a basic business operation.

[0113] Optionally, customer information and business information can be combined to determine the type of business scenario to be tested. For example, if the business scenario to be tested involves a certain type of business of a certain type of customer, it means that the impact of the business scenario to be tested is very small, and the business scenario to be tested can be considered as the fourth type.

[0114] In step S242, the risk level of the business scenario under test is assessed based on the pre-configured correlation between the risk level and the type of the business scenario under test.

[0115] In this embodiment of the disclosure, a mapping relationship between risk levels and the types of business scenarios to be tested can be configured in the risk level lookup table. For example, the risk level lookup table can be configured with multiple risk levels and a correspondence between each risk level and the type of business scenario to be tested.

[0116] For example, when the business scenario under test is of type 1, its impact is relatively broad, therefore, the risk level of this type of business scenario can be set to high in the risk level comparison table. When the business scenario under test is of type 2, its impact is moderate, therefore, the risk level of this type of business scenario can be set to moderate in the risk level comparison table. When the business scenario under test is of type 3 or 4, its impact is relatively small, therefore, the risk level of this type of business scenario can be set to low in the risk level comparison table.

[0117] In some specific embodiments, the risk level includes a first risk level. Figure 4a This illustration schematically shows one of the flowcharts for sorting the service scenarios under test according to an embodiment of the present disclosure, such as... Figure 4a As shown, in some specific embodiments, step S250 includes steps S251 to S253.

[0118] In step S251, the business scenarios to be tested with a risk level of first risk level are extracted to obtain the first business scenario to be tested.

[0119] In step S252, the extracted first business scenarios to be tested are sorted according to the first risk level to obtain the first sequence.

[0120] In step S253, the first business scenario to be tested in the first sequence is sorted according to the transaction volume.

[0121] In this embodiment of the disclosure, the first risk level can be a higher risk level. For example, multiple business scenarios to be tested include business scenario C1, business scenario C2, business scenario C3, business scenario C4, and business scenario C5. The risk level of business scenarios C1 and C2 is risk level D1, the risk level of business scenarios C3 and C4 is risk level D2, and the risk level of business scenario C5 is risk level D3. Among them, risk level D1 is higher than risk level D2, risk level D2 is higher than risk level D3, and risk levels D1 and D2 belong to the first risk level. Therefore, from the business scenarios to be tested C1, C2, C3, C4 and C5, we can select the business scenarios to be tested C1, C2, C3 and C4. For these business scenarios to be tested, we can first sort them by risk level, and then sort them by transaction volume of each business scenario to be tested.

[0122] As mentioned earlier, business scenarios with higher risk levels have a wider impact. For these business scenarios, their risk levels can be prioritized to ensure that the business scenarios with a wider impact are ranked higher in the test list.

[0123] In some specific embodiments, the risk level includes a second risk level, which is lower than the first risk level. Figure 4b This schematically illustrates a second flowchart of sorting the service scenarios under test according to an embodiment of this disclosure, such as... Figure 4b As shown, in some specific embodiments, step S250 further includes steps S254 to S256.

[0124] In step S254, the business scenarios to be tested with a risk level of the second risk level are extracted to obtain the second business scenario to be tested.

[0125] In step S255, the extracted second business scenarios to be tested are sorted according to the transaction volume of the second business scenario to be tested to obtain a second sequence.

[0126] In step S256, the second business scenarios to be tested in the second sequence are sorted according to the second risk level.

[0127] In this embodiment of the disclosure, the second risk level can be a lower risk level. For example, multiple business scenarios to be tested include business scenario C1', business scenario C2', business scenario C3', business scenario C4', business scenario C5', and business scenario C6'. The risk level of business scenarios C1' and C2' is risk level D1', the risk level of business scenarios C3' and C4' is risk level D2', and the risk level of business scenarios C5' and C6' is risk level D3'. Among them, risk level D1' is higher than risk level D2', risk level D2' is higher than risk level D3', and risk levels D2' and D3' belong to the second risk level. Therefore, from the business scenarios to be tested C1', C2', C3', C4', C5', and C6', we can select the business scenarios to be tested C3', C4', C5', and C6'. For these business scenarios to be tested, we can first sort them by transaction volume, and then sort them by risk level.

[0128] As mentioned earlier, the impact of test scenarios with lower risk levels is smaller. Since transaction volume can reflect information such as the frequency of occurrence of the test scenario, transaction volume can be given priority for these test scenarios, thereby ensuring that the test scenarios with higher frequency of occurrence are ranked higher.

[0129] Figure 5 A second flowchart illustrating a software testing method according to an embodiment of this disclosure is shown schematically, such as... Figure 5 As shown, in some specific embodiments, before sending the list of items to be tested to the test terminal, the software testing method further includes steps S310 to S320.

[0130] In step S310, the workload of the test list and the testing capabilities of the test terminal are obtained.

[0131] In this embodiment of the disclosure, the workload of all or part of the business scenarios to be tested in the test list can be calculated, and the total workload of the test list can be obtained by summarizing them.

[0132] Optionally, the business scenarios to be tested in the test list include: business scenarios that have been tested in previous tests and new business scenarios that have not appeared in previous tests. Figure 6a A flowchart illustrating the workload of obtaining a list of items to be tested according to embodiments of this disclosure is shown, such as... Figure 6a As shown, in some specific embodiments, step S310 includes steps S311 to S313.

[0133] In step S311, determine whether the business scenario to be tested is a newly added business scenario. If not, proceed to step S312; if yes, proceed to step S313.

[0134] In step S312, the workload of the business scenario under test is calculated based on the existing test time of the business scenario under test.

[0135] In step S313, the testing workload of the business scenario under test is calculated based on the number of business functions used in the business scenario under test. Among the business functions used in the business scenario under test, the workload of business functions that have changed is greater than the workload of business functions that have not changed.

[0136] For example, consider a business scenario under test, which uses two business functions: E1 and E2. Business function E1 corresponds to the business function in the previously released production version that has undergone changes, while business function E2 remains unchanged. In this example, different workload weights can be assigned to business functions E1 and E2. For instance, assuming a workload weight of "1" is assigned to business function E2, then a workload weight of "2" or even higher can be assigned. The final workload of business functions E1 and E2 can then be obtained by combining their actual workload with their workload weights, thus ensuring that the final workload of business function E1 is greater than that of business function E2.

[0137] In this embodiment of the disclosure, by using the above method, when calculating the workload of the test list, the workload of newly added business scenarios is calculated, while the workload of existing test scenarios can be directly obtained, thereby saving computing resources and reducing the computing load. Furthermore, the calculation process of the workload of the test scenarios can be further refined based on whether the business functions used in the test scenarios have changed, which can effectively improve the calculation accuracy.

[0138] In some specific embodiments, the testing capability of the testing end can be estimated based on factors such as the number of test team members, the available testing time for each tester, and the work efficiency of each tester.

[0139] Figure 6b A flowchart illustrating the acquisition of testing capabilities of the testing terminal according to an embodiment of this disclosure is shown, such as... Figure 6bAs shown, in some specific embodiments, step S310 further includes steps S314 to S316.

[0140] In step S314, the available test time for at least one test point in the test terminal is obtained.

[0141] In this embodiment of the disclosure, the test point may include a computer or test personnel. Taking the test point including test personnel as an example, the available test time can be determined based on the average daily testing capacity of the test personnel and their current work content.

[0142] In step S315, the obtained available test time is summarized.

[0143] In step S316, the testing capability of the testing terminal is determined based on the aggregated available testing time. For example, the available testing time of each testing worker can be summed, and then combined with the average work efficiency of each testing worker to determine the total testing capability of the testing terminal.

[0144] After step S310, step S320 is executed.

[0145] In step S320, based on the workload of the test list and the testing capabilities of the testing end, at least a portion of the test list is selected and assigned recommended test labels.

[0146] In this embodiment of the disclosure, after the list of tests to be tested is sent to the testing end, when the testing resources of the testing end are relatively tight, the testing scenarios of the business scenarios to be tested with recommended testing tags can be selected for testing, thereby improving the effectiveness of the test.

[0147] In some specific embodiments, the test list includes multiple test scenarios arranged according to preset rules. For example, the multiple test scenarios in the test list can be sorted in the manner described in the foregoing embodiments. Figure 7 A flowchart illustrating the allocation of recommended test labels according to embodiments of the present disclosure is shown, such as... Figure 7 As shown, step S320 includes steps S321 to S324.

[0148] In step S321, for each business scenario to be tested in the test list, the workload of the business scenario to be tested is calculated as the sum of the workload of the business scenario to be tested and the workload of the business scenarios to be tested preceding the business scenario to be tested, so as to obtain the test workload corresponding to each business scenario to be tested.

[0149] In step S322, the target business scenario to be tested is determined from the business scenarios to be tested list based on the matching degree between the testing capabilities of the testing terminal and the testing workload of each business scenario to be tested.

[0150] In this embodiment of the disclosure, the ratio of the testing capability of the testing terminal to the testing workload of each business scenario under test can be calculated to determine the matching degree between the testing capability of the testing terminal and the testing workload of each business scenario under test. For example, a ratio close to a preset ratio can be extracted from the calculated ratio. Optionally, the preset ratio can be set to "1", that is, the closer the extracted ratio is to the preset ratio, the closer the testing capability of the testing terminal is to the corresponding testing workload. Therefore, the business scenario under test corresponding to the testing workload in this ratio can be used as the target business scenario under test.

[0151] In step S323, the target business scenario to be tested and the business scenarios to be tested preceding the target business scenario to be tested are selected from the list of business scenarios to be tested to obtain the recommended business scenarios to be tested.

[0152] In step S324, recommended test tags are assigned to the recommended business scenarios to be tested.

[0153] In this embodiment of the disclosure, the above method can be used to assign recommended test tags to the first N business scenarios to be tested in the test list, thereby informing the testing end that they can be tested first. Here, N is the sequence number of the target business scenario in the test list.

[0154] Optionally, in the list of business scenarios to be tested, other business scenarios to be tested can still be retained, allowing the testing end to select according to its own needs.

[0155] Figure 8 A flowchart of a software testing method according to an embodiment of the present disclosure is illustrated in the schematic diagram, as shown in Figure 3. Figure 8 As shown, in some specific embodiments, the software testing method further includes steps S410 to S430.

[0156] In step S410, the test results of the test terminal are obtained. For example, the test status of the link corresponding to the business scenario under test can be obtained from the test link log of the test terminal.

[0157] In step S420, based on the test results, the test coverage of the business functions used in at least one business scenario under test is confirmed.

[0158] In step S430, a test evaluation report is generated based on the test coverage of the business functions used in each business scenario to be tested.

[0159] In this embodiment of the disclosure, the test link log may include multiple links, at least one link consisting of programs corresponding to the business functions used in a business scenario under test. Optionally, the test coverage of the business scenario under test can be determined by checking the test status of each program in the link to confirm whether all programs corresponding to the business scenario under test have been tested.

[0160] Optionally, the link corresponding to the business scenario under test can be found from the test link log. Through this link, the tested program can be found. Other programs (untested programs) corresponding to the business scenario under test can be pieced together through the connection relationship between the business architecture and the IT architecture.

[0161] Optionally, for a business scenario to be tested that already exists in the production link log, the complete link of the business scenario to be tested can be obtained from the production link log, and then compared with the corresponding link in the test link log to determine the test coverage of the business scenario to be tested.

[0162] Optionally, for untested programs, the effectiveness of the test (risk assessment) can be performed according to the type of the corresponding business scenario to be tested.

[0163] Optionally, among the business scenarios to be tested in the test list: business scenarios with higher risk levels can be listed as mandatory test items, and business scenarios with moderate risk levels but a high proportion of transaction volume within a period can also be listed as mandatory test items. When testing on the testing side, for mandatory test items in the test list that have not been tested, a prompt message can be generated for the mandatory test item, informing the user to fill in the reason for not testing and the corresponding risk response measures.

[0164] In this embodiment of the disclosure, different test evaluation reports can be generated based on whether the business scenario under test is a mandatory test item. For example, if a mandatory test item is not tested, the test evaluation is deemed severely inadequate, and possible risk warnings and related business explanations are provided. The remaining untested content can be evaluated as having deficiencies, and possible risk warnings and related business explanations are provided.

[0165] Optionally, the untested mandatory items can be further divided into "selected but not tested" and "not selected". For these two situations, corresponding risk warnings can be given respectively, and the scope of the untested items can be explained. For example, the risk warning for mandatory items that are "selected but not tested" is of a higher level than the risk warning for mandatory items that are "not selected".

[0166] Optionally, users can query test evaluation reports by production version.

[0167] Optionally, test evaluation reports can be generated daily. These reports can help users understand the current situation, adjust strategies in a timely manner, and ensure that risks are effectively controlled before production.

[0168] The software testing method of this disclosure can evaluate the effectiveness of the actual test content based on the test list before production, and indicate the potential risks in production and operation, so as to facilitate the production and operation unit to formulate countermeasures in advance and ensure safe production and operation.

[0169] Based on the above software testing method, this disclosure also provides a software testing apparatus applied in an architecture management system. The architecture management system includes a business architecture and an IT architecture. The business architecture includes multiple business functions and at least one business scenario applicable to each business function. The IT architecture includes multiple programs. The following will be combined with... Figure 9 The device is described in detail.

[0170] Figure 9 A schematic diagram illustrating the structure of a software testing apparatus according to an embodiment of the present disclosure is shown, such as... Figure 9 As shown, the software testing device 900 of this embodiment includes a first acquisition module 910, an extraction module 920, a first processing module 930, a second processing module 940, a test list generation module 950, and a push module 960.

[0171] The first acquisition module 910 is used to acquire the programs whose production versions have been modified from multiple programs, so as to obtain a list of modified programs. In one embodiment, the first acquisition module 910 can be used to execute step S210 described above, which will not be repeated here.

[0172] The extraction module 920 is used to extract, from multiple business functions, the business functions that have a mapping relationship with the program for at least one program in the modified program list, so as to obtain the target business function. In one embodiment, the extraction module 920 can be used to perform the step S220 described above, which will not be repeated here.

[0173] The first processing module 930 is used to determine the business scenario to which the target business function is applicable, so as to obtain at least one business scenario to be tested. In one embodiment, the first processing module 930 can be used to execute the step S230 described above, which will not be repeated here.

[0174] The second processing module 940 is used to acquire the transaction volume of at least one business scenario under test and to assess the risk level of the business scenario under test. In one embodiment, the second processing module 940 can be used to execute step S240 described above, which will not be repeated here.

[0175] The test list generation module 950 is used to sort the obtained test business scenarios according to transaction volume and risk level to obtain a test list. In one embodiment, the test list generation module 950 can be used to perform step S250 described above, which will not be repeated here.

[0176] The push module 960 is used to send the list of items to be tested to the test terminal, so that the test terminal can perform tests according to the list of items to be tested. In one embodiment, the push module 960 can be used to perform step S260 described above, which will not be repeated here.

[0177] The software testing apparatus of this disclosure, within an architecture management system, can identify business scenarios affected by changes in the program, thereby generating a test list to clarify the testing scope. Furthermore, embodiments of this disclosure can sort the test scenarios in the test list, allowing the testing end to selectively perform tests based on the sorting after the test list is pushed to the testing end, making the testing more targeted and improving its effectiveness.

[0178] According to embodiments of this disclosure, any multiple modules among the first acquisition module 910, extraction module 920, first processing module 930, second processing module 940, test list generation module 950, and push module 960 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the first acquisition module 910, extraction module 920, first processing module 930, second processing module 940, test list generation module 950, and push module 960 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), programmable logic array (PLA), system-on-a-chip, system-on-a-substrate, system-on-package, application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, and firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the first acquisition module 910, extraction module 920, first processing module 930, second processing module 940, test list generation module 950, and push module 960 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0179] In some specific embodiments, the software testing apparatus further includes:

[0180] The second acquisition module is used to acquire the test results from the test end.

[0181] The third processing module is used to determine the test coverage of the business functions used in at least one business scenario under test based on the test results.

[0182] The test evaluation report generation module is used to generate a test evaluation report based on the test coverage of the business functions used in each business scenario under test.

[0183] Figure 10 A block diagram schematically illustrates an electronic device suitable for implementing a software testing method according to an embodiment of the present disclosure, such as... Figure 10 As shown, an electronic device 1000 according to an embodiment of the present disclosure includes a processor 1001, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage portion 1008 into a random access memory (RAM) 1003. The processor 1001 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1001 may also include onboard memory for caching purposes. The processor 1001 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0184] RAM 1003 stores various programs and data required for the operation of electronic device 1000. Processor 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. Processor 1001 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 1002 and / or RAM 1003. It should be noted that the programs may also be stored in one or more memories other than ROM 1002 and RAM 1003. Processor 1001 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0185] According to embodiments of this disclosure, the electronic device 1000 may further include an input / output (I / O) interface 1005, which is also connected to a bus 1004. The electronic device 1000 may also include one or more of the following components connected to the I / O interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the I / O interface 1005 as needed. A removable medium 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1010 as needed so that computer programs read from it can be installed into the storage section 1008 as needed.

[0186] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the software testing method according to the embodiments of this disclosure.

[0187] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 1002 and / or RAM 1003 and / or one or more memories other than ROM 1002 and RAM 1003 described above.

[0188] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the software testing methods provided in the embodiments of this disclosure.

[0189] When the computer program is executed by the processor 1001, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0190] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 1009, and / or installed from a removable medium 1011. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0191] In such an embodiment, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by processor 1001, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0192] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0193] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0194] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0195] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A software testing method applied in an architecture management system, the architecture management system comprising a business architecture and an IT architecture, the business architecture comprising multiple business functions and business scenarios using at least one of the business functions, the IT architecture comprising multiple programs, characterized in that, The software testing methods include: From multiple programs, obtain the programs that have changed in the production version to obtain a list of changed programs; For at least one program in the modified program list, extract the business functions that have a mapping relationship with the program from multiple business functions to obtain the target business function; Identify the business scenarios that use the target business function to obtain at least one business scenario to be tested; Obtain the transaction volume of at least one of the business scenarios under test, and assess the risk level of the business scenarios under test; Based on the transaction volume and the risk level, the obtained business scenarios to be tested are sorted to obtain a list of scenarios to be tested; Determine whether the business scenario to be tested is a newly added business scenario; If not, calculate the workload of the business scenario under test based on the existing test time of the business scenario under test; If so, in the business functions used in the business scenario under test, different workload weights are assigned to the business functions that have changed and the business functions that have not changed, and the test workload of the business scenario under test is calculated according to the workload weights; wherein, in the business functions used in the business scenario under test, the workload of the business functions that have changed is greater than the workload of the business functions that have not changed. Obtain the testing capabilities of the testing terminal, and based on the workload of the test list and the testing capabilities of the testing terminal, select at least a portion of the test list and assign recommended test tags to it; The test list, which is assigned recommended test tags, is sent to the test terminal so that the test terminal can perform tests based on the test list.

2. The software testing method according to claim 1, characterized in that, The assessment of the risk level of the business scenario under test includes: Based on the customer information and / or business information of the business scenario to be tested, determine the type of the business scenario to be tested; The risk level of the business scenario to be tested is determined based on the pre-configured risk level and the correspondence between the types.

3. The software testing method according to claim 1, characterized in that, The risk level includes a first risk level. The process of ranking the obtained business scenarios to be tested based on the transaction volume and the risk level includes: Extract the business scenarios to be tested with the risk level of the first risk level to obtain the first business scenario to be tested; Based on the first risk level, the extracted first business scenarios to be tested are sorted to obtain a first sequence; The first business scenario to be tested in the first sequence is sorted according to the transaction volume.

4. The software testing method according to claim 3, characterized in that, The risk level includes a second risk level, which is lower than the first risk level. The step of sorting the obtained business scenarios to be tested based on the transaction volume and the risk level further includes: Extract the business scenarios to be tested with a risk level of the second risk level to obtain the second business scenario to be tested; Based on the transaction volume of the second business scenario to be tested, the extracted second business scenarios to be tested are sorted to obtain a second sequence; The second business scenarios to be tested in the second sequence are sorted according to the second risk level.

5. The software testing method according to claim 1, characterized in that, The acquisition of the testing capabilities of the testing terminal includes: Obtain the available test time for at least one test point in the test terminal; Summarize the available test time obtained; The testing capabilities of the testing terminal are determined based on the aggregated available testing time.

6. The software testing method according to claim 1, characterized in that, The test list includes multiple business scenarios to be tested arranged according to preset rules. The step of selecting at least a portion of the test list and assigning recommended test tags based on the workload of the test list and the testing capabilities of the testing terminal includes: For each business scenario to be tested in the test list, calculate the sum of the workload of the business scenario to be tested and the workload of the business scenarios to be tested preceding the business scenario to be tested, so as to obtain the test workload corresponding to each business scenario to be tested. Based on the matching degree between the testing capabilities of the testing terminal and the testing workload of each of the business scenarios to be tested, the target business scenarios to be tested are determined from the business scenarios to be tested in the list of business scenarios to be tested. Select a target business scenario to be tested from the list of business scenarios to be tested, as well as the business scenarios to be tested that precede the target business scenario to be tested, to obtain recommended business scenarios to be tested; Assign recommended test tags to the recommended business scenarios to be tested.

7. The software testing method according to claim 1, characterized in that, The software testing method also includes: Obtain the test results from the test server; Based on the test results, confirm the test coverage of at least one of the business functions used in the business scenario under test; A test evaluation report is generated based on the test coverage of the business functions used in each of the aforementioned business scenarios to be tested.

8. The software testing method according to claim 1, characterized in that, The production versions of the programs listed in the modified program list are the same.

9. A software testing apparatus, applied in an architecture management system, the architecture management system comprising a business architecture and an IT architecture, the business architecture comprising multiple business functions and at least one business scenario to which said business function applies, the IT architecture comprising multiple programs, characterized in that, The software testing device includes: The first acquisition module is used to acquire the programs that have changed in the production version from multiple programs, so as to obtain a list of changed programs; An extraction module is used to extract, from multiple business functions, the business functions that have a mapping relationship with the program for at least one program in the modified program list, so as to obtain the target business function; The first processing module is used to determine the business scenario to which the target business function is applicable, so as to obtain at least one business scenario to be tested. The second processing module is used to obtain the transaction volume of at least one of the business scenarios under test, and to assess the risk level of the business scenarios under test. The test list generation module is used to sort the obtained test business scenarios according to the transaction volume and the risk level to obtain a test list; determine whether the test business scenario is a new business scenario; if not, calculate the workload of the test business scenario based on the existing test time; if yes, assign different workload weights to the business functions used in the test business scenario for the changed business functions and the unchanged business functions, and calculate the test workload of the test business scenario based on the workload weights; wherein, among the business functions used in the test business scenario, the workload of the changed business functions is greater than the workload of the unchanged business functions; obtain the testing capabilities of the testing end, and select at least a portion of the test list and assign recommended test tags according to the workload of the test list and the testing capabilities of the testing end; The push module is used to send the list of test objects with recommended test tags to the test terminal, so that the test terminal can perform tests according to the list of test objects with recommended test tags.

10. The software testing apparatus according to claim 9, characterized in that, The software testing device also includes: The second acquisition module is used to acquire the test results from the test terminal; The third processing module is used to confirm the test coverage of at least one of the business functions used in the business scenario under test based on the test results. The test evaluation report generation module is used to generate a test evaluation report based on the test coverage of the business functions used in each of the business scenarios under test.

11. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors perform the software testing method according to any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that, It stores executable instructions that, when executed by a processor, cause the processor to perform the software testing method according to any one of claims 1 to 8.

13. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the software testing method according to any one of claims 1 to 8.

Images