Test system for computer software development

Abstract

The invention relates to the technical field of software testing, and discloses a testing system for computer software development. Comprising the following steps: regularly identifying an update state of a computer software system, judging whether to-be-tested software exists or not, identifying a test target and test characteristics of the to-be-tested software from a test request, screening out a target task from test tasks, simulating a basic scene and a software test scene, and identifying a test state of the to-be-tested software. A corresponding test result is determined; compared with the prior art, the method and the device can ensure that the screened target task can keep an extremely high correlation degree with the to-be-tested software, and the software test scene with two levels is simulated through the to-be-tested software and the target task, so that the test requirements of the to-be-tested software can be efficiently met, and the test efficiency is improved. Therefore, an efficient, safe and accurate test environment is provided for the test operation of the to-be-tested software, and the accuracy of a computer software test result is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing. More specifically, the present invention relates to a testing system for computer software development. Background Art

[0002] With the rapid development of computer technology, the scale and complexity of software systems have been continuously increasing. Software quality has become a key factor affecting user experience and enterprise competitiveness. In order to better improve user experience and increase market competitiveness, it is necessary to continuously develop computer software. At the same time, after software development, it is also necessary to perform performance testing on the developed software to ensure that the developed software can maintain strong usability.

[0003] The patent application with the publication number CN115617670A discloses a software testing management method, storage medium, and system, including obtaining test data of a software testing task and a task evaluation rule configured for the software testing task, reviewing and analyzing the test data according to the task evaluation rule to obtain an analysis result of the test data, performing quantization processing on the analysis result according to a preset quantization rule to obtain a test work index of the analysis result, matching the test work index with a task production index to obtain a matching result, and determining whether to adjust the task evaluation rule according to the matching result;

[0004] When testing existing computer software, the method of comparing relevant parameters in the test software with test rules one by one is adopted to achieve the test effect of the test software. For example, in the above patent application, by constructing a complete software testing management system, it can intuitively evaluate the testing work done by software testers, improving the evaluation accuracy of the work efficiency of software testers. Although this method can achieve software testing operations, by comparing and testing the test software with test rules one by one, on the one hand, it will lead to a large workload of testing operations, indirectly increasing the probability of errors in test results. On the other hand, the single-dimensional and hierarchical testing method cannot achieve an efficient association effect between the test software and the test rules, resulting in low accuracy of subsequent software test results.

[0005] In view of this, the present invention proposes a testing system for computer software development to solve the above problems. Summary of the Invention

[0006] To overcome the above-mentioned defects of the prior art and to achieve the above object, the present invention provides the following technical solution: A testing system for computer software development, which is applied to a test server and includes:

[0007] A test determination module, taking one update cycle as a standard, regularly identifies the update status of the computer software system and determines whether there is software to be tested;

[0008] The parsing and extraction module, if there is software to be tested, receives an input test request, identifies the test objectives of the software to be tested from the test request, and extracts test features corresponding to the test objectives. The test features include a basic rate value, a synchronous parallel value, and a limit response value;

[0009] The matching and screening module identifies the task attributes of the test tasks in the task library, matches the tasks to be verified from the test tasks, calculates the matching index of the tasks to be verified, and filters out the target tasks according to the matching index;

[0010] The scenario simulation module builds a basic scenario with test workstations based on the target tasks, and simulates the basic scenario as a software test scenario with test trigger conditions based on the test features;

[0011] The software testing module collects the comprehensive test parameters of the software test scenario, intelligently identifies the test status of the software to be tested. The test status includes a high-performance state and a low-performance state, and determines the corresponding test results.

[0012] Furthermore, the update status includes updated and not updated. The identification methods for updated and not updated are as follows:

[0013] Query the version information of the computer software system through the attribute management system, and extract the software version number from the version information, which is recorded as the original version number;

[0014] After the duration corresponding to an update cycle, query the version number of the version information in the computer software system to obtain the real-time version number;

[0015] When the original version number and the real-time version number are exactly the same, record the update status as not updated;

[0016] When the original version number and the real-time version number are not exactly the same, record the update status as updated;

[0017] The determination method for whether there is software to be tested is as follows:

[0018] When the update status of the computer software system is not updated, it is determined that there is no software to be tested;

[0019] When the update status of the computer software system is updated, it is determined that there is software to be tested.

[0020] Furthermore, the test objectives include running security, architecture stability, calculation accuracy, and version compatibility. The identification methods for running security, architecture stability, calculation accuracy, and version compatibility are as follows:

[0021] Receive and parse the input test request, parse the request data in the test request into a software part and a requirement part, and identify the key fields in the requirement part through natural language processing technology;

[0022] When the key field is "security", the test objective of the software to be tested is running security;

[0023] When the key field is "stable", the test objective of the software to be tested is architecture stability;

[0024] When the key field is "accurate", the test objective of the software to be tested is calculation accuracy;

[0025] When the key field is "compatible", the test objective of the software to be tested is version compatibility.

[0026] Furthermore, the extraction method of the base rate value is as follows:

[0027] Parse out the comments of all the codes in the software part of the test request one by one, and record the codes with comments of programs, data, and documents as valid codes;

[0028] Within an update cycle, query the moment of the first transmission and the moment of the last transmission of the valid codes through timestamps, and count the number of valid codes at the moment of the last transmission to obtain the transmission volume value;

[0029] Compare the transmission volume value with the duration between the moment of the first transmission and the moment of the last transmission to obtain the base rate value;

[0030] The expression of the base rate value is:

[0031]

[0032] In the formula, JC sl is the base rate value, CS lz is the transmission volume value, SC qz is the duration between the moment of the first transmission and the moment of the last transmission.

[0033] Furthermore, the task attributes include unrelated tasks and related tasks, and the identification methods for unrelated tasks and related tasks are as follows:

[0034] Parse out the task remarks of all the test tasks in the task library one by one, and mark the task texts of the task remarks;

[0035] Record the test tasks with task texts consistent with the test objectives of the tasks to be tested as marked tasks, and extract the task rate value, task parallel value, and task response value in the marked tasks;

[0036] Compare the task rate value, task parallel value, and task response value of the marking task with the base rate value, synchronous parallel value, and limit response value of the task to be tested respectively. Mark the marking tasks with a task rate value greater than the base rate value, a task parallel value greater than the synchronous parallel value, and a task response value less than the limit response value as tasks to be verified, and obtain A tasks to be verified.

[0037] Furthermore, the calculation method of the matching index is as follows:

[0038] Subtract the task rate value of each of the A tasks to be verified from the base rate value of the task to be tested to obtain A rate differences;

[0039] Subtract the task parallel value of each of the A tasks to be verified from the synchronous parallel value of the task to be tested to obtain A parallel differences;

[0040] Subtract the task response value of each of the A tasks to be verified from the limit response value of the task to be tested to obtain A response differences;

[0041] Multiply the rate differences, parallel differences, and response differences of the A tasks to be verified by their corresponding weight factors respectively and then add them up to obtain A matching indices;

[0042] Arrange the A tasks to be verified in descending order according to the matching index, and mark the task to be verified in the first place as the target task.

[0043] Furthermore, the method for building the basic scenario is as follows:

[0044] Construct two inner and outer combined closed contours on the test server. Mark the inner closed contour as the test contour and the outer closed contour as the task contour;

[0045] Create a note box on the task contour and import the task text of the target task into the note box to generate a task contour with notes;

[0046] Establish three independent test workstations within the test contour, and set up two test units in each of the three test workstations, denoted as the first unit and the second unit respectively;

[0047] Import the task rate value, task parallel value, and task response value of the target task into the first unit of the three test workstations respectively, and convert the three test workstations into a half-rate workstation, a half-parallel workstation, and a half-response workstation respectively to construct the basic scenario.

[0048] Furthermore, the test trigger condition is: when there is no abnormal unit in the test workstation, it is determined that the software test scenario is triggered.

[0049] Furthermore, the simulation method of the software test scenario is as follows:

[0050] Import the base rate value, synchronous parallel value, and limit response value of the software to be tested into the second units of the half-rate station, half-parallel station, and half-response station respectively to generate a rate station, a parallel station, and a response station;

[0051] When there is a blank test unit in the rate station or the value in the second unit is not the base rate value, there is an abnormal unit in the rate station;

[0052] When there is a blank test unit in the parallel station or the value in the second unit is not the synchronous parallel value, there is an abnormal unit in the parallel station;

[0053] When there is a blank test unit in the response station or the value in the second unit is not the limit response value, there is an abnormal unit in the response station;

[0054] Trigger and determine the basic scenario through the test trigger condition, and simulate the basic scenario that meets the test trigger condition as a software test scenario.

[0055] Furthermore, the test results include qualified software and unqualified software:

[0056] The determination methods for qualified software and unqualified software are as follows:

[0057] Synchronously input the collected unit throughput, resource occupancy rate, request error rate, minimum response duration, and number of security vulnerabilities into the machine learning model to identify the test status of the software to be tested;

[0058] When the test status is a high-performance state, determine the test result of the software to be tested as qualified software;

[0059] When the test status is a low-performance state, determine the test result of the software to be tested as unqualified software.

[0060] The technical effects and advantages of a test system for computer software development according to the present invention:

[0061] 1. By regularly identifying the update status of the computer software system and determining whether there is software to be tested, the software to be tested can be regularly and accurately identified from the computer software system, which can not only ensure that newly developed software can be monitored in a timely manner, but also reasonably reduce the monitoring burden of newly developed software, avoiding the high burden brought by traditional real-time continuous monitoring operations;

[0062] 2. By identifying the test objectives of the software to be tested from the test requests and extracting the test features corresponding to the test objectives, the relevant parameters and indicators that need to be tested in the software to be tested can be comprehensively represented, and the lower limit standards in multiple dimensions during the test of the software to be tested can be clarified, thus laying a foundation for the subsequent test of the software to be tested;

[0063] 3. By matching the to-be-verified tasks from the test tasks, calculating the matching index of the to-be-verified tasks, and screening out the target tasks according to the matching index, the matching degree between the test tasks in the task library and the software to be tested can be numerically represented, providing an accurate reference basis for the subsequent matching and screening of the target tasks, so as to ensure that the selected target tasks can maintain a very high degree of association with the software to be tested and ensure that the software to be tested can maintain the best overall state in the subsequent tests;

[0064] 4. By building a basic scenario with test workstations and simulating the basic scenario as a software test scenario with test trigger conditions, the software to be tested and the target tasks can be simulated into a software test scenario with two levels, enabling the software test scenario to effectively match the construction requirements of the target tasks and efficiently adapt to the test requirements of the software to be tested, thereby providing an efficient, safe and accurate test environment for the test operation of the software to be tested, effectively avoiding the problems of insufficient test stability and poor test accuracy existing in the test environment under a single hierarchical structure. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Figure 1 It is a schematic diagram of the modules of a test system for computer software development provided in Embodiment 1 of the present invention;

[0066] Figure 2 It is a schematic flowchart of a test method for computer software development provided in Embodiment 2 of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0067] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0068] Embodiment 1: Please refer to Figure 1 As shown, the test system for computer software development described in this embodiment is applied to a test server and includes:

[0069] A test determination module, taking an update cycle as a standard, regularly identifies the update status of the computer software system and determines whether there is software to be tested;

[0070] In the normal development and testing applications of computer software, it usually takes a certain amount of time to identify relevant software and execute projects, which can not only ensure that newly developed software can be detected in a timely manner but also reasonably reduce the monitoring burden of newly developed software. Therefore, it is necessary to use the update cycle as the monitoring cycle of the computer software system to regularly monitor the status of the computer software system;

[0071] Based on the above, the update cycle is the monitoring duration used to collect and determine whether there is newly developed software in the computer software system. Specifically, the update cycle is not a constant duration but is related to the computer's own status and historical update frequency. Generally speaking, when the computer's own status is better, the longer the duration used to collect and determine whether there is newly developed software in the computer at this time, the relatively larger the update cycle. When the computer's historical update frequency is higher, the higher the frequency of newly developed software in the computer during the past period, the relatively smaller the update cycle;

[0072] Exemplarily, when the duration of the computer's self - security check is 30 minutes and the historical update frequency is 0.02 times per minute, the update cycle is 2 minutes.

[0073] After determining the update cycle, it is necessary to use the duration corresponding to one update cycle as a standard to regularly monitor and identify the update status of the computer software system, as a basis for judging whether there is newly developed software in the computer software system, and record the existing newly developed software as software to be tested, so that the software to be tested can be used as the software for subsequent development and testing;

[0074] The update status includes updated and not updated; updated means that after one update cycle, there is newly developed software in the computer software system, and not updated means that after one update cycle, there is no newly developed software in the computer software system;

[0075] The methods for identifying updated and not updated are as follows:

[0076] Query the version information of the computer software system through the attribute management system, and extract the software version number from the version information, which is recorded as the original version number; the version information is a specific representation of the version model to which the computer software system belongs at the current moment and serves as the data basis for judging whether the computer software system has undergone iteration, update, or upgrade;

[0077] After the duration corresponding to one update cycle, query the version number of the version information in the computer software system to obtain the real - time version number;

[0078] When the original version number and the real - time version number are exactly the same, it means that the computer software system has not had a status update after one update cycle, and the update status is recorded as not updated;

[0079] When the original version number and the real-time version number are not exactly the same, it indicates that the computer software system has undergone a status update after an update cycle. Then, the update status is recorded as updated.

[0080] After identifying the update status of the computer software system, it is possible to determine whether there is newly developed software in the computer software system that needs to be tested;

[0081] The method for determining whether there is software to be tested is as follows:

[0082] When the update status of the computer software system is not updated, it means that there is no newly developed software in the computer software system and no subsequent software testing operation is required. Then, it is determined that there is no software to be tested;

[0083] When the update status of the computer software system is updated, it means that there is newly developed software in the computer software system and subsequent software testing operations are required. Then, it is determined that there is software to be tested.

[0084] It should be noted that the number of software to be tested in the computer software system is one or more. When there are multiple software to be tested, each software to be tested exists independently of each other, and the test operation process for each software to be tested is the same. Therefore, in order to simplify the test steps for multiple software to be tested, in this embodiment, the number of software to be tested is limited to 1, that is, there is exactly one software to be tested in the computer software system.

[0085] The parsing and extraction module, if there is software to be tested, receives the input test request, identifies the test target of the software to be tested from the test request, and extracts the test features corresponding to the test target;

[0086] A test request refers to a request that needs to be sent to the test server to test the software to be tested when there is software to be tested in the computer software system, so that the test request can comprehensively represent the relevant test requirements of the software to be tested;

[0087] The test target is used to represent the test purpose that the software to be tested should achieve during this software test process and serves as a data dimension for evaluating the software to be tested. During the test process of a software to be tested, usually only one test target exists to ensure that the software to be tested can be tested in a safe, stable, and reasonable state;

[0088] The test objectives include running security, architecture stability, calculation accuracy, and version compatibility. Among them, running security refers to the self - security state of the software to be tested in the computer software system; architecture stability refers to the coding stability state of the software to be tested in the computer software system; calculation accuracy refers to the data calculation accuracy rate of the software to be tested in the computer software system; version compatibility refers to the system compatibility performance of the software to be tested in the computer software system.

[0089] The identification methods for running security, architecture stability, calculation accuracy, and version compatibility are as follows:

[0090] Receive and parse the input test request, parse the request data in the test request into a software part and a requirements part, and identify the key fields in the requirements part through natural language processing technology. The software part is used to represent the test code in the software to be tested in the test request, as the specific content in the software to be tested. The requirements part is used to represent the test requirements in the software to be tested in the test request, as the test purpose of the software to be tested. The key fields are used to concisely represent the true meaning in the requirements part.

[0091] When the key field is "security", it indicates that the security performance of the software to be tested needs to be tested in the test request, and the test objective of the software to be tested is running security.

[0092] When the key field is "stable", it indicates that the stability performance of the software to be tested needs to be tested in the test request, and the test objective of the software to be tested is architecture stability.

[0093] When the key field is "accurate", it indicates that the accuracy performance of the software to be tested needs to be tested in the test request, and the test objective of the software to be tested is calculation accuracy.

[0094] When the key field is "compatible", it indicates that the compatibility performance of the software to be tested needs to be tested in the test request, and the test objective of the software to be tested is version compatibility.

[0095] After identifying the test objective of the software to be tested, based on the test objective, the test features corresponding to the test objective can be extracted from the test request, so that the test features can represent the specific detail bottom line that the software to be tested should embody and be tested in this test, and can be used as an important basis for subsequent testing of the software to be tested.

[0096] The test features include a basic rate value, a synchronous parallel value, and a limit response value. The basic rate value is the minimum data transfer rate when the software to be tested runs normally in the computer software system, and serves as the lower limit of the data transfer rate for subsequent related operations of the software to be tested.

[0097] The method for extracting the basic rate value is as follows:

[0098] Parse out the comments of all codes in the software part of the test request one by one, and mark the codes with comments of programs, data, and documents as valid codes;

[0099] Within an update cycle, query the moment of the first transmission and the moment of the last transmission of the valid codes through timestamps, and count the number of valid codes at the moment of the last transmission to obtain the transmission volume value;

[0100] Compare the transmission volume value with the duration between the moment of the first transmission and the moment of the last transmission to obtain the basic rate value;

[0101] The expression of the basic rate value is:

[0102]

[0103] In the formula, JC sl is the basic rate value, CS lz is the transmission volume value, SC qz is the duration between the moment of the first transmission and the moment of the last transmission.

[0104] The synchronous parallel rate refers to the minimum value of the ratio between the number of data processed synchronously and the total number when the software under test is running normally in the computer software system, and is used as the parallel lower limit for subsequent relevant synchronous processing operations of the software under test; the synchronous parallel rate is obtained by querying the minimum value of the synchronous parallel rate of the software part of the test request at the same moment.

[0105] The limit response value refers to the maximum value of the instruction response duration when the software under test is running normally in the computer software system, and is used as the duration lower limit for subsequent relevant instruction response operations of the software under test; the limit response value is obtained by querying the maximum value of the instruction response duration of the software part of the test request for the valid codes.

[0106] It should be noted that the basic rate value, synchronous parallel value, and limit response value can represent the minimum requirements for the software under test in three dimensions of data transmission, synchronous processing, and response duration in the computer software system, provide a comparison basis for subsequent test task matching and screening for the software under test, and can also set the basic tone for the subsequent test process.

[0107] The matching and screening module identifies the task attributes of the test tasks in the task library, matches the tasks to be verified from the test tasks, calculates the matching index of the tasks to be verified, and screens out the target tasks according to the matching index;

[0108] A test task refers to a task that can match the test characteristics of the software to be tested and meet the test objective requirements of the software to be tested. Usually, test tasks are software tasks formulated to achieve test objectives based on the test characteristics of the software to be tested without negative interference factors. A task library refers to a collection of a large number of test tasks of different types, enabling the test tasks in the task library to meet the test requirements of various software to be tested;

[0109] Task attributes are used to specifically represent whether a test task can meet the test objective requirements of the task to be tested, that is, to clearly represent the degree of association between the test task and the task to be tested. Task attributes include irrelevant tasks and associated tasks. An irrelevant task means that there is no association between the test objective and test characteristics of the test task and the task to be tested, and an associated task means that there is an association between the test objective and test characteristics of the test task and the task to be tested;

[0110] The identification methods for irrelevant tasks and associated tasks are as follows:

[0111] Analyze one by one the task remarks of all test tasks in the task library and mark the task words in the task remarks. Task remarks refer to the overall content remarks of the test requirements corresponding to the test task, and task words are the direct text words regarding the test requirements in the task remarks;

[0112] Mark the test tasks whose task words are consistent with the test objective of the task to be tested as marked tasks, and extract the task rate value, task parallel value, and task response value in the marked tasks. The task rate value, task parallel value, and task response value are used to specifically represent the data processing rate, synchronous parallel quantity, and instruction response duration in the marked tasks, and their extraction methods are the same as those for the basic rate value, synchronous parallel value, and limit response value of the task to be tested as described above;

[0113] Compare the task rate value, task parallel value, and task response value of the marked tasks with the basic rate value, synchronous parallel value, and limit response value of the task to be tested respectively, and mark the marked tasks whose task rate value is greater than the basic rate value, task parallel value is greater than the synchronous parallel value, and task response value is less than the limit response value as tasks to be verified, obtaining A tasks to be verified.

[0114] When tasks to be verified are matched, at this time, the number of tasks to be verified is relatively large, and the degree of test association between each task to be verified and the task to be tested also varies. In order to obtain the test task with the highest degree of test association, it is necessary to calculate the matching index for the tasks to be verified, so that the matching index can numerically represent the degree of test association between the tasks to be verified and the task to be tested, and the larger the matching index, the higher the degree of test association between the tasks to be verified and the task to be tested;

[0115] The calculation method of the matching index is as follows:

[0116] Subtract the task rate values of A tasks to be verified from the base rate value of the task to be tested respectively to obtain A rate differences;

[0117] The expression of the rate difference is:

[0118] SL cza = SL rwa - SL jc ;

[0119] In the formula, SL cza is the rate difference of the ath task to be verified, a = 1, 2,..., A, SL rwa is the task rate value of the ath task to be verified, SL jc is the base rate value of the task to be tested;

[0120] Subtract the task parallel values of A tasks to be verified from the synchronous parallel value of the task to be tested respectively to obtain A parallel differences;

[0121] The expression of the parallel difference is:

[0122] BX cza = BX rwa - BX tb ;

[0123] In the formula, BX cza is the parallel difference of the ath task to be verified, BX rwa is the task parallel value of the ath task to be verified, BX tb is the synchronous parallel value of the task to be tested;

[0124] Subtract the task response values of A tasks to be verified from the limit response value of the task to be tested respectively to obtain A response differences;

[0125] The expression of the response difference is:

[0126] XY cza = XY jx - XY rwa ;

[0127] In the formula, XY cza is the task response value of the ath task to be verified, XY jx is the limit response value of the task to be tested, XY rwa is the task response value of the ath task to be verified;

[0128] Multiply the rate differences, parallel differences and response differences of A tasks to be verified by the corresponding weight factors respectively and then add them up to obtain A matching indexes;

[0129] The expression for the matching index is as follows:

[0130] PP zsa = σ 1 * SL cza + σ 2 * BX cza + σ 3 * XY cza ;

[0131] In the formula, PP zsa is the matching index of the ath task to be verified, and σ 1 , σ 2 , σ 3 are the weight factors of the rate difference, parallel difference, and response difference respectively, and σ 1 , σ 2 , σ 3 are all greater than 0; σ 1 , σ 2 , σ 3 are used to balance the proportions of the rate difference, parallel difference, and response difference in the matching index, that is, to ensure that the rate difference, parallel difference, and response difference can reasonably affect the change in the size of the matching index, thereby ensuring the calculation accuracy of the matching index;

[0132] Arrange the A tasks to be verified in descending order of the matching index, and record the task to be verified in the first place as the target task.

[0133] It should be noted that selecting the task to be verified in the first place as the target task can ensure that the performance of the target task in terms of rate, parallelism, and response is in the best overall state, enabling the target task to maximize the satisfaction of the test requirements of the task to be tested.

[0134] The scenario simulation module builds a basic scenario with test workstations based on the target task, and simulates the basic scenario as a software test scenario with test trigger conditions based on the test features;

[0135] After screening out the target task, according to the specific test requirements and data of the target task and the task to be tested, the corresponding final test scenario can be matched and simulated. In order to ensure that the simulated final test scenario can meet the two aspects of requirements of the target task and the task to be tested, the final test scenario needs to be simulated at two-dimensional levels to achieve the simulation effect of two levels of test scenarios;

[0136] In the first-level simulation, it is necessary to build a basic scenario that matches the target task based on the target task, so that the basic scenario can be used as the first-level test simulation scenario;

[0137] The method for building the basic scenario is as follows:

[0138] Build two inner and outer combined closed contours on the test server, and mark the inner closed contour as the test contour and the outer closed contour as the task contour; the closed contour is used to represent the two-level boundaries in the basic scenario, so that one closed contour corresponds to one level boundary, and the inner and outer combined closed contour can ensure that the finally formed software test scenario can have two independent levels;

[0139] Create a note box on the task contour and import the task text of the target task into the note box to generate a task contour with notes; the note box is used to limit the import position of the task text within the task contour;

[0140] Establish three independent test workstations within the test contour, and set two test units in each of the three test workstations, denoted as the first unit and the second unit respectively; the test workstation is used to limit the import position of data within the test contour, and the test unit is the smallest part that makes up the test workstation and directly corresponds to the relevant data in the target task and the software to be tested;

[0141] Import the task rate value, task parallel value, and task response value of the target task into the first unit of the three test workstations respectively, convert the three test workstations into a half-rate workstation, a half-parallel workstation, and a half-response workstation respectively, and build the basic scenario.

[0142] After building the basic scenario, the basic scenario at this time cannot be directly connected to the software to be tested. Therefore, it is necessary to simulate the basic scenario based on the test characteristics of the software to be tested, simulate the basic scenario into a software test scenario, so that the software test scenario can be directly associated with the test characteristics of the software to be tested;

[0143] In the simulation of the second level, after simulating the software test scenario, it is necessary to set test trigger conditions in the software test scenario, so that the test trigger conditions can be used as the basis for judging and controlling whether the software test scenario is tested;

[0144] The test trigger condition is: when there is no abnormal unit in the test workstation, it is determined that the software test scenario is triggered; thus, the stability of the software test scenario can be effectively judged and identified, improving the trigger condition of the software test scenario and avoiding the phenomenon of mis-triggering of the software test scenario;

[0145] The simulation method of the software test scenario is as follows:

[0146] Import the base rate value, synchronous parallel value, and limit response value of the software to be tested into the second units of the half-rate station, half-parallel station, and half-response station respectively to generate a rate station, a parallel station, and a response station;

[0147] When there is a blank test unit in the rate station or the value in the second unit is not the base rate value, it means that there is an import omission or import error in the test unit of the rate station at this time, so there are abnormal units in the rate station;

[0148] When there is a blank test unit in the parallel station or the value in the second unit is not the synchronous parallel value, it means that there is an import omission or import error in the test unit of the parallel station at this time, so there are abnormal units in the parallel station;

[0149] When there is a blank test unit in the response station or the value in the second unit is not the limit response value, it means that there is an import omission or import error in the test unit of the response station at this time, so there are abnormal units in the response station;

[0150] Trigger and determine the basic scenario through the test trigger condition, and simulate the basic scenario that meets the test trigger condition as a software test scenario.

[0151] The software test module collects the comprehensive test parameters of the software test scenario, intelligently identifies the test status of the software to be tested, and determines the corresponding test results;

[0152] The comprehensive test parameters refer to the relevant change parameters when the software to be tested is simulated and run in the software test scenario, which can specifically and multi-dimensionally represent the performance of the software to be tested in the software test scenario, and at the same time serve as the basis for judging the performance strength of the software to be tested;

[0153] The comprehensive test parameters include unit throughput, resource occupancy rate, request error rate, minimum response duration, and the number of security vulnerabilities;

[0154] Specifically, the unit throughput is used to represent the number of relevant data and requests processed per unit time when the software test scenario tests the software to be tested. The resource occupancy rate is used to represent the proportion of the system and memory occupied when the software test scenario tests the software to be tested. The request error rate is used to represent the proportion of request errors and failures when the software test scenario tests the software to be tested. The minimum response duration is used to represent the shortest duration of the response instruction when the software test scenario tests the software to be tested. The number of security vulnerabilities is used to represent the number of security hazards and vulnerabilities when the software test scenario tests the software to be tested;

[0155] Since the unit throughput, resource occupancy rate, request error rate, minimum response time, and the number of security vulnerabilities are all specific parameters used for testing the software to be tested, the unit throughput, resource occupancy rate, request error rate, minimum response time, and the number of security vulnerabilities can be obtained through the system query tool of the computer software system.

[0156] After collecting the unit throughput, resource occupancy rate, request error rate, minimum response time, and the number of security vulnerabilities, based on these parameters, the test status of the software to be tested can be identified through the machine learning model in artificial intelligence technology, and the test results corresponding to the software to be tested can be judged according to different test statuses.

[0157] The test status includes high-performance status and low-performance status; the high-performance status means that the developed software to be tested performs well in the software test scenario, and the low-performance status means that the developed software to be tested performs poorly in the software test scenario.

[0158] The test result is used to indicate whether the developed software to be tested meets the normal and efficient use of the computer software system. The test results include qualified software and unqualified software, so as to be able to correspondingly represent the software to be tested in high-performance status and low-performance status.

[0159] The determination methods for qualified software and unqualified software are as follows:

[0160] Synchronously input the collected unit throughput, resource occupancy rate, request error rate, minimum response time, and the number of security vulnerabilities into the machine learning model to identify the test status of the software to be tested.

[0161] When the test status is high-performance status, it means that the software to be tested performs well in the software test scenario, and the test result of the software to be tested is determined to be qualified software.

[0162] When the test status is low-performance status, it means that the software to be tested performs poorly in the software test scenario, and the test result of the software to be tested is determined to be unqualified software.

[0163] It should be noted that the machine learning model is an existing technology in artificial intelligence technology. In this embodiment, the machine learning model adopts any one of the CNN neural network model or the AlexNet in artificial intelligence technology. After collecting the unit throughput, resource occupancy rate, request error rate, minimum response duration, and the number of security vulnerabilities and the test status in a large number of different types of software to be tested and software test scenarios, the unit throughput, resource occupancy rate, request error rate, minimum response duration, and the number of security vulnerabilities of the software to be tested and the software test scenario are used as the training basis, and the corresponding test status is used as the training result to continuously repeat the training of the machine learning model, so that the machine learning model can identify the corresponding test status according to the input comprehensive test parameters.

[0164] In this embodiment, by regularly identifying the update status of the computer software system and determining whether there is software to be tested, the software to be tested can be accurately identified from the computer software system regularly, which can not only ensure that newly developed software can be monitored in a timely manner, but also reasonably reduce the monitoring burden of newly developed software, avoiding the high burden brought by traditional real-time continuous monitoring operations.

[0165] By identifying the test objectives of the software to be tested from the test requests and extracting the test features corresponding to the test objectives, the relevant parameters and indicators to be tested in the software to be tested can be comprehensively represented, and the lower limit standards in multiple dimensions during the testing process of the software to be tested can be clarified, thus laying a foundation for the subsequent testing of the software to be tested.

[0166] By matching the tasks to be verified from the test tasks, calculating the matching index of the tasks to be verified, and screening out the target tasks according to the matching index, the matching degree between the test tasks in the task library and the software to be tested can be numerically represented, providing an accurate reference basis for the subsequent matching and screening of the target tasks, ensuring that the selected target tasks can maintain a very high degree of association with the software to be tested, and ensuring that the software to be tested can maintain the best overall state in the subsequent testing.

[0167] By building a basic scenario with test workstations and simulating the basic scenario as a software test scenario with test trigger conditions, the software to be tested and the target tasks can be simulated into a software test scenario with two levels, enabling the software test scenario to not only effectively match the construction requirements of the target tasks, but also efficiently adapt to the test requirements of the software to be tested, thereby providing an efficient, safe and accurate test environment for the test operation of the software to be tested, effectively avoiding the problems of insufficient test stability and poor test accuracy existing in the test environment with a single hierarchical structure during software testing.

[0168] By collecting the comprehensive test parameters of the software test scenario, intelligently identifying the test status of the software to be tested, and determining the corresponding test results, it is possible to quickly and accurately identify and determine the test results of the software to be tested by combining artificial intelligence technology, thereby providing an evaluation basis for the final software performance of the software to be tested.

[0169] Embodiment 2: Please refer to Figure 2 As shown, for the parts not described in detail in this embodiment, refer to the description in Embodiment 1. A test method for computer software development is provided, which is applied to a test server and implemented based on a test system for computer software development, including:

[0170] S1: Taking an update cycle as a standard, regularly identify the update status of the computer software system and determine whether there is software to be tested;

[0171] S2: If there is software to be tested, receive the input test request, identify the test objectives of the software to be tested from the test request, and extract the test features corresponding to the test objectives;

[0172] S3: Identify the task attributes of the test tasks in the task library, match the tasks to be verified from the test tasks, calculate the matching index of the tasks to be verified, and screen out the target tasks according to the matching index;

[0173] S4: Based on the target tasks, build a basic scenario with test workstations, and based on the test features, simulate the basic scenario into a software test scenario with test trigger conditions;

[0174] S5: Collect the comprehensive test parameters of the software test scenario, intelligently identify the test status of the software to be tested, and determine the corresponding test results.

[0175] Specifically, in S1, the update status includes updated and not updated. In S2, the test objectives include running security, architecture stability, calculation accuracy, and version compatibility. The test features include basic rate value, synchronous parallel value, and limit response value. In S4, the test trigger condition is: when there is no abnormal unit in the test workstation, it is determined that the software test scenario is triggered. In S5, the test status includes high-performance status and low-performance status, and the test results include qualified software and unqualified software.

[0176] The above is only the specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of changes or substitutions, which should all be covered by the protection scope of the present invention.

Claims

1. A computer software development test system, applied to a test server, characterized in that: include: The test determination module regularly identifies the update status of the computer software system based on an update cycle and determines whether there is software to be tested; The parsing and extraction module receives the input test request if there is software to be tested, identifies the test target of the software to be tested from the test request, and extracts the test features corresponding to the test target, the test features including the basic rate value, the synchronous parallel value and the limit response value; The matching and screening module identifies the task attributes of the test tasks in the task library, matches the tasks to be verified from the test tasks, calculates the matching index of the tasks to be verified, and screens the target tasks according to the matching index; The scenario simulation module builds a basic scenario with a test station based on the target task, and simulates the basic scenario into a software test scenario with test trigger conditions based on the test characteristics; The software testing module collects comprehensive test parameters of the software testing scenario, intelligently identifies the test status of the software to be tested, which includes high-performance status and low-performance status, and determines the corresponding test results.

2. A computer software development test system according to claim 1, characterized in that: The update status includes updated and not updated. The identification method of updated and not updated is: Query the version information of the computer software system through the attribute management system, and extract the software version number from the version information and record it as the original version number; After a period corresponding to an update cycle, the version number of the version information in the computer software system is queried to obtain the real-time version number; When the original version number and the real-time version number are exactly the same, the update status is recorded as not updated; When the original version number and the live version number are not completely consistent, the update status is recorded as updated; The method for determining whether there is software to be tested is: When the update status of the computer software system is not updated, it is determined that there is no software to be tested; When the update status of the computer software system is updated, it is determined that there is software to be tested.

3. A computer software development test system according to claim 2, characterized in that: The test objectives include operational security, architectural stability, computational accuracy, and version compatibility. The identification methods for operational security, architectural stability, computational accuracy, and version compatibility are as follows: Receive and parse the input test request, parse the request data in the test request into the software part and the requirement part, and identify the key fields of the requirement part through natural language processing technology; When the key field is security, the test goal of the software to be tested is operational security; When the key field is stable, the test goal of the software to be tested is architectural stability; When the key field is accurate, the test goal of the software to be tested is calculation accuracy; When the key field is compatible, the test target of the software to be tested is version compatibility.

4. A computer software development test system according to claim 3, characterized in that: The basic rate value is extracted as follows: Parse the comments of all codes in the software part of the test request one by one, and record the codes annotated as programs, data and documents as valid codes; In an update cycle, the time when the valid code is first transmitted and the time when it is last transmitted are queried through the timestamp, and the number of valid codes at the time of the last transmission is counted to obtain the transmission amount value; Compare the transmission amount value with the duration between the first transmission time and the last transmission time to obtain a basic rate value; The expression for the basic rate value is: In the formula, JC sl is the basic rate value, CS lz is the transmission value, SC qz It is the duration between the first transmission and the last transmission.

5. A computer software development test system according to claim 4, characterized in that: Task attributes include irrelevant tasks and related tasks. The identification method of irrelevant tasks and related tasks is: Parse the task notes of all test tasks in the task library one by one, and mark the task text of the task notes; The test tasks whose task text is consistent with the test objectives of the task to be tested are recorded as marked tasks, and the task rate value, task parallel value and task response value in the marked tasks are extracted; The task rate value, task parallelism value and task response value of the marked task are compared with the basic rate value, synchronous parallelism value and limit response value of the task to be tested respectively, and the marked tasks whose task rate value is greater than the basic rate value, task parallelism value is greater than the synchronous parallelism value and task response value is less than the limit response value are recorded as tasks to be verified, and A tasks to be verified are obtained.

6. A computer software development test system according to claim 5, characterized in that: The calculation method of matching index is: Subtract the task rate values ​​of A tasks to be verified from the basic rate value of the task to be tested to obtain A rate difference values; Subtract the task parallel values ​​of A tasks to be verified from the synchronous parallel values ​​of the tasks to be tested to obtain A parallel difference values; Subtract the limit response value of the task to be tested from the task response values ​​of A tasks to be verified to obtain A response difference values; The rate difference, parallel difference and response difference of A tasks to be verified are respectively assigned corresponding weight factors and added together to obtain A matching indexes; Arrange the A tasks to be verified in order from large to small according to the matching index, and record the first task to be verified as the target task.

7. A computer software development test system according to claim 6, characterized in that: The method of building the basic scene is: Constructing two inner and outer combined closed contours on the test server, and recording the inner closed contour as the test contour, and recording the outer closed contour as the task contour; Create a remark box on the task outline, and import the task text of the target task into the remark box to generate a task outline with remark; Three independent test stations are established within the test profile, and two test units are set in each of the three test stations, which are respectively recorded as the first unit and the second unit; The task rate value, task parallel value and task response value of the target task are respectively imported into the first unit of the three test stations, and the three test stations are respectively converted into a half-rate station, a half-parallel station and a half-response station to construct a basic scenario.

8. A computer software development test system according to claim 7, characterized in that: The test triggering condition is: when there is no abnormal unit in the test station, the software test scenario is determined to be triggered.

9. A computer software development test system according to claim 8, characterized in that: The simulation method of software testing scenario is: Importing the basic rate value, synchronous parallel value and extreme response value of the software to be tested into the second unit of the half-rate station, the half-parallel station and the half-response station respectively, to generate a rate station, a parallel station and a response station; When there is a blank test unit in the rate station or the second unit is not the basic rate value, there is an abnormal unit in the rate station; When there is a blank test unit in the parallel station or the second unit is not a synchronous parallel value, there is an abnormal unit in the parallel station; When there is a blank test unit in the response station or the second unit is not at the limit response value, there is an abnormal unit in the response station; The basic scenarios are triggered and judged through the test trigger conditions, and the basic scenarios that meet the test trigger conditions are simulated as software test scenarios.

10. A computer software development test system according to claim 9, characterized in that: The test results include qualified software and unqualified software: The method for determining qualified software and unqualified software is: The collected unit throughput, resource usage, request error rate, minimum response time, and number of security vulnerabilities are synchronously input into the machine learning model to identify the test status of the software to be tested; When the test status is a high performance status, the test result of the software to be tested is determined as qualified software; When the test status is a low performance status, the test result of the software to be tested is determined as unqualified software.

Images