Software product quality testing method based on development process and related equipment thereof

Abstract

The invention belongs to the field of artificial intelligence and management, and relates to a software product quality testing method based on a development process, which comprises the following steps of: configuring a process relationship between process nodes of a development process of a software product based on development process information of a standard software product; binding a corresponding test plan for each process node, and obtaining a test line of the assembled software product according to the process relationship between the process nodes; obtaining each test node of the software product to be tested; and according to the test line, calling the corresponding test plan to test each test node to obtain a test result of each test node. The invention further provides a software product quality testing device based on the development process, computer equipment and a storage medium. According to the method, the testing efficiency of the software product is effectively improved, and the development quality of the software product is effectively guaranteed.

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence and management technology, and in particular to a software product quality testing method based on a development process and related equipment. Background Art

[0002] In today's era of rapid Internet development, the frequency of software iteration and update is accelerating, and the iteration and change of product requirements are frequent, complex and diverse. Under such a rapid development trend, it is undoubtedly a huge challenge for testers. Every software iteration means the readjustment and increase of testing tasks.

[0003] As the functions of software products continue to expand and the architecture becomes increasingly complex, the testing tasks they trigger have become extremely arduous. At present, in the field of software testing, the quality system construction for the overall product line process is still in a relatively scarce state. Although the existing technical means have improved the testing efficiency to a certain extent, most of them only focus on the automation of simple technical means, such as interface automation testing, which automatically calls and verifies the software interface by writing scripts; UI automation testing, which simulates user operations on the graphical interface for functional verification; performance testing, which evaluates the performance of the software under different loads, etc. However, these scattered testing methods are difficult to form a systematic and comprehensive overall quality system covering the entire product line. Therefore, the existing software development process lacks a set of standard and widely used tools, making it difficult to efficiently and comprehensively guarantee the development quality of software products when facing rapidly iterating software products and complex and changing product requirements. Summary of the invention

[0004] The purpose of the embodiments of the present application is to propose a software product quality testing method, device, computer equipment and storage medium based on the development process. Its main purpose is to systematically construct a complete process from process node configuration, test plan binding to test node acquisition and test execution, which can comprehensively cover the entire product line, adapt to the complex situation of rapid software iteration and changing product requirements, effectively improve the testing efficiency of software products, and effectively ensure the development quality of software products.

[0005] In order to solve the above technical problems, the embodiment of the present application provides a software product quality testing method based on the development process, comprising the following steps:

[0006] Based on the standard software product development process information, configure the process relationship between process nodes of the software product development process;

[0007] Bind a corresponding test plan to each of the process nodes, and obtain a test circuit for the assembled software product according to the process relationship between the process nodes; each of the test plans is composed of a plurality of preset software function test cases, and each of the software function test cases is configured to test a functional module of the corresponding software product;

[0008] Obtain each test node of the software product to be tested;

[0009] According to the test circuit, the corresponding test plan is called to test each of the test nodes to obtain the test result of each of the test nodes.

[0010] In order to solve the above technical problems, the embodiment of the present application further provides a software product quality testing device based on the development process, which adopts the following technical solution:

[0011] A configuration module is used to configure the process relationships between process nodes of the software product development process based on standard software product development process information;

[0012] A binding module, used to bind a corresponding test plan to each of the process nodes, and obtain a test circuit of the assembled software product according to the process relationship between the process nodes; each of the test plans is composed of a plurality of preset software function test cases, and each of the software function test cases is configured to test a functional module of the corresponding software product;

[0013] An acquisition module, used to acquire each test node of the software product to be tested;

[0014] The test module is used to call the corresponding test plan according to the test line to test each of the test nodes and obtain the test result of each of the test nodes.

[0015] In order to solve the above technical problems, the embodiment of the present application further provides a computer device, which adopts the following technical solution:

[0016] The method comprises a memory and a processor, wherein the memory stores computer-readable instructions, and the processor implements the steps of the software product quality testing method based on the development process as described above when executing the computer-readable instructions.

[0017] In order to solve the above technical problems, the embodiment of the present application further provides a computer-readable storage medium, which adopts the following technical solution:

[0018] The computer-readable storage medium stores computer-readable instructions, and when the computer-readable instructions are executed by a processor, the steps of the software product quality testing method based on the development process as described above are implemented.

[0019] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0020] This application systematically constructs a complete process from process node configuration, test plan binding to test node acquisition and test execution, which can comprehensively cover the entire product line, adapt to the complex situation of rapid software iteration and changing product requirements, effectively improve the testing efficiency of software products, and effectively ensure the development quality of software products. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the scheme in the present application, a brief introduction is given below to the drawings required for use in the description of the embodiments of the present application. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0022] Figure 1 is an exemplary system architecture diagram to which the present application may be applied;

[0023] Figure 2 A flowchart of an embodiment of a software product quality testing method based on a development process according to the present application;

[0024] Figure 3 It is a structural schematic diagram of an embodiment of a software product quality testing device based on a development process according to the present application;

[0025] Figure 4 It is a structural diagram of an embodiment of a computer device according to the present application. DETAILED DESCRIPTION

[0026] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0027] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0028] like Figure 1As shown, the system architecture 100 may include a terminal device 101, a network 102 and a server 103. The terminal device 101 may be a laptop 1011, a tablet computer 1012 or a mobile phone 1013. The network 102 is used to provide a medium for a communication link between the terminal device 101 and the server 103. The network 102 may include various connection types, such as wired, wireless communication links or optical fiber cables.

[0029] The user can use the terminal device 101 to interact with the server 103 through the network 102 to receive or send messages, etc. Various communication client applications can be installed on the terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0030] The terminal device 101 can be any electronic device with a display screen and supporting web browsing. In addition to a laptop computer 1011, a tablet computer 1012 or a mobile phone 1013, the terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 (Moving Picture Experts Group Audio Layer IV), a laptop computer, a desktop computer, etc.

[0031] The server 103 may be a server that provides various services, such as a background server that provides support for web pages displayed on the terminal device 101 .

[0032] It should be noted that the software product quality testing method based on the development process provided in the embodiment of the present application is generally executed by a server / terminal device, and accordingly, the software product quality testing device based on the development process is generally set in the server / terminal device.

[0033] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0034] Continue to refer Figure 2 , shows a flowchart of an embodiment of a method for software product quality testing based on development process according to the present application. The software product quality testing method based on development process comprises the following steps:

[0035] S10, configuring the process relationships between process nodes of the software product development process based on standard software product development process information;

[0036] S11, binding a corresponding test plan to each of the process nodes, and obtaining a test circuit of the assembled software product according to the process relationship between the process nodes; each of the test plans is composed of a plurality of preset software function test cases, and each of the software function test cases is configured to test a functional module of the corresponding software product;

[0037] S12, obtaining each test node of the software product to be tested;

[0038] S13, according to the test line, calling the corresponding test plan to test each of the test nodes, and obtaining the test result of each of the test nodes.

[0039] In this embodiment, the software product quality testing method based on the development process is run on the electronic device (for example Figure 1 Server / terminal device shown).

[0040] The embodiments of the present application mainly have the following beneficial effects:

[0041] First, according to the standard software product development process information, the various process nodes in the software product development process are sorted out, and the process relationships between process nodes are configured, so as to build a clear framework structure for the development of software products and clarify the logical connection between various links. Then, for each process node, the test plan that best matches its function and business logic is selected from the preset test plan library for binding. Each test plan consists of multiple pre-designed software function test cases, which are specially designed for different software product functional modules. In this way, it is ensured that each process node can receive targeted and comprehensive quality inspection during the software product testing process. At the same time, considering the process relationship between process nodes, these process nodes bound to the test plan are integrated to obtain the assembled software product test circuit, which provides a clear test process direction for subsequent test execution. Then, the various test nodes of the software product to be tested are obtained. Finally, according to the assembled test circuit, the corresponding test plan is automatically called to conduct a comprehensive test on each test node, so as to obtain the detailed test results of each test node.

[0042] To sum up the above analysis, this application can comprehensively cover the entire product line by systematically constructing a complete process from process node configuration, test plan binding to test node acquisition and test execution, adapt to the complex situation of rapid software iteration and changing product requirements, effectively improve the testing efficiency of software products, and effectively ensure the development quality of software products.

[0043] In some optional implementations of this embodiment, after step S11 and before step S12, the method further includes:

[0044] Conducting an inspection on the test circuit to obtain an inspection result of the product test circuit of the software product;

[0045] According to the inspection result of the product test circuit, the test circuit is adjusted and optimized.

[0046] In this embodiment, after the software product test circuit is assembled and before the test node is obtained, a patrol mechanism is introduced to check the test circuit to ensure the accuracy and reliability of the test circuit. When new requirements are launched or the product changes, patrol inspections are started. Regular patrol inspections are also performed at other times to ensure that there are no errors by spot-checking the links. This adds a dynamic guarantee mechanism to the software product quality test, which can adapt to product changes in a timely manner and improve the effectiveness and accuracy of the test.

[0047] Specifically, after binding the corresponding test plan to each process node and obtaining the assembled software product test line, the system immediately starts the inspection preparation state. First, establish an inspection task queue and store the current test line information in it. This queue will be sorted by priority, and inspection tasks triggered by new requirements or product changes will be given higher priority. When new requirements are launched or products change, the system will respond quickly. The specific steps are as follows:

[0048] Analyze the impact of new requirements on existing test circuits. By comparing the functional modules involved in the new requirements with the process nodes in the test circuit, determine the set of nodes that may be affected. For example, if the new requirement is to add a special insurance claim method, then the nodes related to the claim process may be affected.

[0049] Conduct in-depth inspections of the affected process nodes. The inspection contents include but are not limited to: whether the functions of the nodes match the new requirements, whether the connections with other nodes need to be adjusted, whether the bound test plan is still applicable, etc. For example, for newly added claims methods, it may be necessary to check whether the connections with underwriting nodes, financial settlement nodes, etc. are correct, and whether the corresponding test plan covers the new claims process.

[0050] Perform a comprehensive test on the links between the affected nodes. Send simulated data to be transmitted along the link to check the accuracy, completeness and timeliness of the data. For example, from the time a customer submits a claim application, simulate the data passing through each intermediate node until the final claim result is generated, and check whether the data transmission in each link is correct.

[0051] Generate a detailed inspection report based on the test results. The report will clearly indicate the specific location and nature of the problem. For example, if it is found that the data processing logic of a node is incompatible with the new requirements, the report will detail the specific functional problem of the node.

[0052] For regular inspections, the system will automatically perform the following steps at preset time intervals:

[0053] A certain percentage of the test line links are randomly selected for spot check. This percentage can be adjusted according to the complexity and importance of the software product. For example, for a complex insurance business software, 30% of the links can be sampled for inspection.

[0054] Perform data transmission tests on the links that are randomly checked. Send different types of simulated data to check the stability and data processing capabilities of the links. For example, for the link from customer information entry to insurance policy generation, you can send customer information data in different formats to check whether the insurance policy generation link can correctly process this data.

[0055] Check the binding status of the test plan and the process node. Confirm whether the binding is still valid and whether the test cases in the test plan cover the functions of the current node. For example, check whether the test plan of a certain underwriting node includes the latest underwriting rule changes.

[0056] Perform statistical analysis on the inspection results. Generate a statistical report on the inspection results, including the number of links sampled, the proportion of links with problems, the distribution of problem types, etc. By analyzing this data, you can understand the overall health of the test line and provide a basis for further optimization.

[0057] If a problem is found during the inspection, the system will take different approaches depending on the severity of the problem. For minor problems, they can be recorded in the problem log and checked again during the next inspection; for medium problems, an alarm will be issued to notify technicians to conduct manual inspection and repair; for serious problems, the relevant test process will be suspended immediately to ensure that the problem is solved in a timely manner before continuing the test.

[0058] In some optional implementations of this embodiment, after step S13, the method further includes:

[0059] In response to detecting a change in a development process of a software product, locating a process node where the change occurred;

[0060] Update the test plan bound to the changed process node.

[0061] In this embodiment, after the software product completes the test of the test node according to the test line, when it is detected that the development process of the software product has changed, the changed process node can be quickly located, and the test plan bound to the node can be updated in time to ensure the accuracy and adaptability of the software test. Therefore, this embodiment establishes a dynamic test adjustment mechanism that can actively respond to changes in the development process and avoid test failures caused by process changes. Compared with traditional testing methods, this embodiment can adapt to the iteration and changes of software products more quickly and improve the efficiency and quality of testing.

[0062] Specifically, the specific working process of this embodiment is described in detail here:

[0063] After completing the test of the test node, the system starts the change monitoring module. This module continuously monitors the development process of the software product, mainly through the following methods:

[0064] Code difference analysis: Regularly compare and analyze the source code of the software to identify the additions, modifications, and deletions of the code. If the code is found to have changed, further analyze whether these changes affect the process nodes in the development process. For example, if new algorithms or logic adjustments are found in the code of the claims calculation module, it may mean that the claims process nodes have changed.

[0065] Version control information query: Interact with the version control system to obtain the software version change record. By analyzing the description and impact range of the version change, determine whether there are changes in the development process. For example, if the version control system records a major update of a functional module, you may need to check whether the process node corresponding to the module is affected.

[0066] Once a change in the development process is detected, the system immediately starts the change location module. This module uses the following technical means to locate the process node where the change occurred:

[0067] Dependency analysis: Analyze the dependencies between the various software modules to determine which process nodes may be affected by the change. For example, if the structure of a data storage module changes, it may affect multiple business process nodes related to it.

[0068] Log analysis: Query the software's running logs to find information related to the change. If an exception or error is found in a specific process node in the log, it may indicate that the node was affected by the development process change.

[0069] After determining the process node where the change occurred, the system enters the test plan update module. This module updates the test plan according to the specific circumstances of the change. The specific steps are as follows:

[0070] Change impact assessment: Analyze the impact of the change on the test plan. If the change is minor, you may only need to adjust the parameters or expected results of some test cases; if the change is major, you may need to add new test cases or redesign the test plan.

[0071] Test case adjustment: Adjust the test cases based on the type and scope of the change. For example, if the audit criteria in the claims process change, you may need to add new test cases to verify whether the claims results under different audit criteria are correct.

[0072] Test parameter update: Update the parameters in the test plan to adapt to changes in the development process. For example, if the performance requirements of the software have changed, the load parameters and time limits of the test may need to be adjusted.

[0073] Modify expected results: Modify the expected results of the test cases according to the changed development process. Ensure that the test can accurately determine whether the software runs normally under the new development process.

[0074] In some optional implementations of this embodiment, configuring the process relationship between process nodes of the development process of the software product based on the standard software product development process information includes:

[0075] Obtain standard software product development process information;

[0076] Sorting out each process node in the development process information and determining the logical relationship between each process node;

[0077] According to the logical relationship between each of the process nodes, the process connections between the process nodes of the development process of the software product are configured.

[0078] In this embodiment, by obtaining standard software product development process information, each process node therein is combed to determine the logical relationship, and then the process connection between nodes in the software product development process is configured according to these logical relationships. This embodiment provides a systematic and standardized method for constructing a software product development process. Traditional development processes may be more arbitrary and lack clear combing and configuration of the relationship between nodes. However, this embodiment can ensure the rationality and coherence of the development process and improve the quality and efficiency of software product development.

[0079] Specifically, first, the system widely obtains standard software product development process information through various channels. This may include consulting industry standard documents, studying the development process of similar successful software projects, consulting professional software development organizations or experts, etc. The information obtained should cover all stages and key links of software product development, including requirements analysis, design, coding, testing, deployment, etc.

[0080] Next, sort out each process node in the development process information one by one. For each node, analyze in detail its functional description, input data source, output data destination, and its position and role in the entire development process. For example, in insurance business software development, the function of the customer information entry node is to collect basic customer information. The input data may come from a form filled out by the customer or an external database, and the output data will be passed to the risk assessment and underwriting nodes.

[0081] In the process of sorting out, a variety of analysis methods are used to determine the logical relationship between each process node. Tools such as flowchart drawing, data flow analysis, and dependency matrix can be used. For example, by drawing a flowchart, the sequence and parallel relationship between each node can be intuitively displayed; by analyzing the data flow, it can be determined which nodes have data transfer and dependency relationships.

[0082] For sequential relationships, determine which nodes must be completed before other nodes. For example, in the insurance business, customer information entry must be performed before risk assessment and underwriting, because risk assessment and underwriting require basic customer information as input. For parallel relationships, identify which nodes can be performed simultaneously to improve development efficiency. For example, in some cases, risk assessment and underwriting can be performed simultaneously to shorten the entire development cycle. For dependency relationships, clarify the impact of the output of one node on the input of another node. For example, the result of underwriting will directly affect the premium calculation, and the premium calculation node depends on the output of the underwriting node.

[0083] Finally, according to the determined logical relationship, the development process of the software product is precisely configured. The configuration content includes clarifying the data transmission method, trigger conditions, exception handling mechanism, etc. between nodes. For example, in the insurance business, when the customer information is entered, the risk assessment and underwriting process is automatically triggered, and data transmission can be achieved through message queues or event-driven methods. If the underwriting fails, the corresponding processing process needs to be clarified, such as notifying the customer to supplement the information or refusing to underwrite.

[0084] In some optional implementations of this embodiment, step S12 includes:

[0085] Obtaining node information of each of the process nodes;

[0086] Extracting a node feature of each of the process nodes from the node information of each of the process nodes;

[0087] Calculate the matching degree of the node feature of each process node with the process node feature pre-mapped to each test plan in a preset test plan library to obtain a matching degree calculation result;

[0088] If the matching degree calculation result is greater than a preset matching degree threshold, the process node is bound to the test plan corresponding to the feature of the process node; otherwise, no binding is performed;

[0089] The process nodes and the bound test plans are assembled according to the sequence of the process relationships to obtain the assembled test circuit of the software product.

[0090] In this embodiment, by obtaining process node information, extracting node features, calculating the matching degree with the test plan features in the preset test plan library, binding nodes with high matching degrees with the test plan, and finally assembling them into test lines according to the process relationship, an automated feature matching and binding method is adopted to improve the adaptability of the test plan and process nodes, and ensure the comprehensiveness and accuracy of the test. Compared with the traditional manual binding test plan, it is more efficient and accurate, and can better adapt to the changes in the development process of different software products.

[0091] Specifically, first of all, obtaining node information for each process node is a multi-dimensional data collection process. For each process node, the system collects information from multiple sources, including but not limited to the following:

[0092] Development Documentation: Consult the development documentation of the software product to understand the detailed information such as the function description, input and output parameters, business logic, etc. of the process node. For example, in insurance business software, the development documentation of the customer information entry node may clearly state that the node needs to collect the customer's name, age, gender, contact information, etc., as well as the format requirements and validation rules of this information.

[0093] Code analysis: Analyze the code related to the process node to determine its specific implementation method and data processing logic. Code analysis can help you understand the specific role of the node in the software system and how it interacts with other modules. For example, by analyzing the code of the customer information entry node, you can determine how the node receives user input, performs data verification and storage, and how it interacts with the database.

[0094] Database structure: Check the database table structure related to the process node to understand the data types and relationships stored. For example, the customer information entry node may store the collected customer information in a specific database table. By analyzing the structure of the table, you can understand the specific data fields and data types stored.

[0095] Extracting node features from the collected node information is a key step. Node features can be divided into the following categories:

[0096] Functional characteristics: describe the main functions and business areas of the process node. For example, the functional characteristics of the customer information entry node can be "personal information collection", "data input and verification", etc.

[0097] Data characteristics: including the type, format, range, etc. of input data, as well as the characteristics of output data. For example, the input data characteristics of a customer information entry node may be "name of string type", "age of integer type", "contact information in a specific format", etc., and the output data characteristics may be "verified customer information dataset".

[0098] Technical features: Involving the technologies and tools used by the node, as well as its technical implementation in the software system. For example, the customer information entry node may use a specific front-end framework and back-end database technology, and its technical features may be "front-end development using Vue.js", "interacting with MySQL database", etc.

[0099] Calculating the matching degree between the node characteristics of each process node and the pre-mapped process node characteristics of each test plan in the preset test plan library is a complex process. It can be achieved by using a variety of algorithms and techniques, such as:

[0100] Vector space model: Node features and test plan features are represented as vectors, and the matching degree is determined by calculating the similarity between the vectors. For example, the cosine similarity between the feature vector of the customer information entry node and the feature vector of each test plan is calculated to obtain the matching degree value.

[0101] Machine learning algorithms: Use machine learning algorithms, such as support vector machines and decision trees, to classify and match node features and test plan features. By training the model, the accuracy and efficiency of matching can be improved.

[0102] After obtaining the matching calculation result, it is compared with the preset matching threshold. If the matching calculation result is greater than the preset matching threshold, it means that the test plan is highly compatible with the process node, and the system binds the process node and the corresponding test plan. The binding method can be to establish an association in the database or record it through a configuration file.

[0103] Finally, assemble each process node and its bound test plan in the order of process relationship. This process needs to consider the dependencies between process nodes and the data transmission method. For example, in insurance business software, after the test plan of the customer information entry node is completed, its output data will be used as the input data of the risk assessment and underwriting nodes. Therefore, when assembling the test line, it is necessary to ensure that the test plans of these two nodes are executed in the correct order. The assembly of test lines can be achieved through flowchart drawing, task scheduling, etc.

[0104] As an example, the process of building a test plan and test cases is as follows:

[0105] Insurance business software usually includes multiple functional modules, such as customer information management, insurance product display and recommendation, insurance application, underwriting, claims, etc. Each functional module corresponds to one or more test plans, and each test plan consists of multiple preset software function test cases.

[0106] Taking the insurance application function module as an example, a test plan may include multiple test cases such as "normal insurance process test", "abnormal data input test", "insurance test under network interruption", etc. Each test case is composed of multiple different interfaces, which have upstream and downstream relationships and jointly complete the test of a small functional module. For example, the "normal insurance process test" case may involve the customer information input interface, insurance product selection interface, premium calculation interface, insurance confirmation interface, etc. The interfaces are called in sequence according to the business process to ensure the normal operation of the insurance application function.

[0107] Among them, the initial test case is generated as follows:

[0108] Code burial point:

[0109] Code tracking is performed on each key page and operation link of the insurance business software. For example, on the customer information entry page, when the user enters information such as name, age, occupation, etc. and clicks the "Next" button, the code tracking will record the triggered event and the called interface, which may be the interface that submits the customer information to the server.

[0110] On the insurance product selection page, when the user selects different insurance products, views product details and clicks the "Insure" button, the code tracking will record the calls to the product selection interface and the insurance request interface.

[0111] On the premium calculation page, when the system calculates the premium based on the insurance product selected by the user and customer information, the code tracking point will record the call of the premium calculation interface.

[0112] User operation process record:

[0113] When a user applies for insurance in the insurance business software, the system will automatically record the interfaces involved in the entire process. For example, the user starts from opening the software, and then goes through the steps of customer information entry, insurance product selection, premium calculation, insurance confirmation, etc. Each step will trigger the corresponding interface call, and these interfaces will be recorded.

[0114] If the user encounters abnormal situations such as network interruption, input error information, etc. during the operation, the code tracking point will also record the corresponding interface call and system response for subsequent abnormal situation testing.

[0115] Interface extraction and case generation:

[0116] Extract the interfaces involved from the recorded user operation process, and these interfaces can be turned into a test case. For example, the customer information input interface, insurance product selection interface, premium calculation interface, insurance confirmation interface, etc. extracted from a complete insurance application process can form a "normal insurance process test" case.

[0117] If a network interruption occurs during user operation, the recorded interfaces can form an "insurance test under network interruption" case to test the system's handling capabilities under abnormal circumstances.

[0118] In some optional implementations of this embodiment, step S12 includes:

[0119] According to the preset test node scanning rules, the software product to be tested is deeply detected and analyzed to identify each test node of the software product to be tested.

[0120] In this embodiment, the software product is deeply detected and analyzed through the preset test node scanning rules to accurately and efficiently identify each test node to be tested. This embodiment provides a systematic and standardized test node acquisition method, which avoids omissions and inaccuracies that may occur in traditional methods. In this way, by scanning with pre-set rules, various functions and characteristics of the software product can be more comprehensively covered, thereby improving the integrity and effectiveness of the test.

[0121] Specifically, first, conduct an in-depth analysis of the software product's architecture, functional modules, business processes, etc. to establish test node scanning rules. Test node scanning rules can be divided into multiple levels and categories, including but not limited to the following aspects:

[0122] Code structure rules: Analyze the source code structure of the software. For example, check the naming conventions, parameter types, return value types, etc. of the function. For object-oriented programming languages, you can also check the inheritance relationship of the class, the access rights of member variables, etc. By analyzing the code structure, you can preliminarily determine potential test nodes, such as key functions, important class methods, etc.

[0123] Data flow rules: Pay attention to the data flow in the software. This includes the source of input data, data conversion during processing, and the destination of output data. By tracking the data flow, you can identify key nodes of data processing, such as data verification functions, data storage processes, etc. For example, in insurance business software, the insurance application data entered by the customer is transmitted from the front-end interface to the back-end server, and it goes through multiple data processing links. Each link can be used as a test node for focus.

[0124] Functional module rules: Divide the software according to its functional modules. For each functional module, formulate specific scanning rules. For example, in insurance business software, the underwriting module may have specific rules, such as checking the accuracy of underwriting rules and the completeness of underwriting processes. The premium calculation module may focus on the rate calculation method and discount rules of different insurance products. Through the functional module rules, the key test nodes in each module can be identified in a targeted manner.

[0125] User interaction rules: Consider the interaction process between the user and the software. This includes user interface elements, operation processes, feedback mechanisms, etc. For example, check whether the button click response is correct, whether the form input verification prompt is clear, whether the menu selection function is normal, etc. Through user interaction rules, you can identify test nodes related to user experience.

[0126] Next, the software product to be tested is probed in depth according to these rules. This can be done by combining a variety of technical means:

[0127] Static analysis: By analyzing static resources such as the software source code and configuration files, potential problems and test nodes can be discovered without running the software program. Static analysis tools can check syntax errors, potential security vulnerabilities, unused variables, etc. in the code. At the same time, by analyzing the control flow and data flow of the code, key execution paths and data processing nodes can be determined.

[0128] Dynamic execution tracking: During the software running process, the software behavior is monitored in real time by tracking the execution path and data flow of the program. Debugging tools, performance analysis tools, etc. can be used for dynamic execution tracking. For example, in insurance business software, the execution process of the underwriting process can be tracked by setting breakpoints and observing changes in variable values, and key calculation nodes and decision points can be determined.

[0129] Simulate user operations: Use automated testing tools to simulate various user operations on the software. You can simulate different types of user input, operation sequence, error conditions, etc. to trigger different functional modules and interaction scenarios of the software. For example, in insurance business software, you can simulate operations such as customers filling out insurance application forms, submitting applications, and checking policy status to identify corresponding test nodes.

[0130] During the detection process, it is necessary to continuously analyze whether the identified nodes meet the test requirements. This includes the following aspects:

[0131] Screening and classification: Screen and classify the identified nodes according to preset rules. Remove duplicate nodes, irrelevant nodes or low-priority nodes. Classify nodes according to functional modules, business processes, etc. to facilitate subsequent test plan formulation and execution.

[0132] Verification and confirmation: Verify and confirm each identified node. The accuracy and importance of the node can be ensured through manual testing, automated testing, or communication with developers. For example, for key business logic nodes, detailed functional testing and boundary testing can be performed to verify their correctness and stability.

[0133] Prioritization: Test nodes are prioritized based on factors such as the importance of the node, the degree of risk, etc. High-priority nodes can be tested first to ensure that the key functions and high-risk areas of the software are fully tested.

[0134] In some optional implementations of this embodiment, step S13 includes:

[0135] Determine, according to the test line, a first node to be tested as a current test node;

[0136] According to the binding identifier of the current test node, using the index of the preset data structure, searching for the test plan corresponding thereto;

[0137] Execute each software functional test case included in the test plan one by one;

[0138] Collect the execution result of each of the test cases to obtain the test result of each of the test nodes;

[0139] A test report for the software product to be tested is generated according to the test result of each of the test nodes.

[0140] In this embodiment, the current test node is determined along the test line, the corresponding test plan is quickly found by using the preset data structure index through the binding identifier of the node, each software function test case in the test plan is executed and the results are collected, and finally a test report of the software product is generated. It can be seen that this embodiment uses an efficient data structure index to find the test plan to ensure the accuracy and efficiency of the test. At the same time, a comprehensive test report is generated by collecting the results of each test case, providing a detailed basis for software quality assessment.

[0141] Specifically, first, when determining the first node to be tested as the current test node, the system will select a node with starting characteristics from a large number of nodes according to the test line planning. This node may be the entry point of the software product, such as the login page, main menu, etc., or it may be the first key node determined according to a specific business process. After determining the current test node, the system will obtain the binding identifier of the node. This binding identifier is a unique identifier used for indexing and searching in a preset data structure.

[0142] Next, use the index of the preset data structure to search. This data structure can be an efficient data structure such as a hash table, a binary search tree, or a B-tree. Taking a hash table as an example, the system will calculate the hash value based on the binding identifier, and then quickly locate the corresponding storage location in the hash table to find the corresponding test plan. If a data structure such as a binary search tree or a B-tree is used, comparisons and searches will be performed based on the size of the binding identifier or specific attributes, gradually narrowing the search range and eventually finding the corresponding test plan.

[0143] After finding the test plan, start executing the software function test cases contained therein one by one. Each test case is designed for a specific software function, with a clear test purpose and expected results. For example, in insurance business software, if the current test node is the customer information entry page, the test case may include entering the customer name, ID number, contact information and other data in the correct format to check whether the system can correctly verify and store it; entering data in the wrong format to check whether the system can give a clear error prompt; simulating abnormal situations such as network interruption to check the system's fault tolerance, etc.

[0144] When executing each test case, the system will record the detailed execution process and results. This includes information such as input data, executed operations, system response time, and output results. For some complex test cases, you may also need to use logging, screenshots, and other methods to record key steps and abnormal situations. After executing a test case, the system will compare and judge the actual results based on the expected results to determine whether the test case passes. If it fails, the specific error information and reasons will be recorded.

[0145] After executing all test cases, collect the execution results of each test case. These results can be stored in the form of data structures, such as lists, arrays, dictionaries, etc. The collected results include whether the test case passes or fails, response time, error information, etc. For test cases that fail, the type and severity of the error will be further analyzed so that they can be highlighted when generating the test report.

[0146] Finally, based on the test results of each test node, a test report for the software product to be tested is generated. The test report can be generated in a templated manner, and the test results are filled in the corresponding positions according to the preset format and content requirements. The test report can include information such as an overview of the test nodes, the execution of the test cases, the problems found and suggestions, the time and environment of the test, etc. For insurance business software, the test report can also be classified and summarized according to different business modules, such as customer information management module, insurance product sales module, claims management module, etc., so that developers and managers can quickly understand the quality status of various aspects of the software.

[0147] The embodiments of the present application can acquire and process relevant data based on artificial intelligence technology. Among them, artificial intelligence (AI) is the theory, method, technology and application system that uses digital computers or machines controlled by digital computers to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use knowledge to obtain the best results.

[0148] AI basic technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing technology, operation / interaction systems, mechatronics, etc. AI software technologies mainly include computer vision technology, robotics technology, biometrics technology, speech processing technology, natural language processing technology, and machine learning / deep learning.

[0149] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through computer-readable instructions, and the computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the aforementioned storage medium can be a non-volatile storage medium such as a disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0150] It should be understood that, although the steps in the flowchart of the accompanying drawings are displayed in sequence as indicated by the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least a part of the steps in the flowchart of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a part of the sub-steps or stages of other steps.

[0151] Further references Figure 4 , as a response to the above Figure 2 The present application provides an embodiment of a software product quality testing device based on a development process. Figure 2 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0152] like Figure 4 As shown, the software product quality testing device based on the development process described in this embodiment includes: a configuration module 401, a binding module 402, an acquisition module 403 and a testing module 404. Among them:

[0153] Configuration module 401, configured to configure the process nodes and process relationships between the process nodes of the software product development process based on standard software product development process information;

[0154] The binding module 402 is used to bind the corresponding test plan to each of the process nodes, and obtain the test circuit of the assembled software product according to the process relationship between the process nodes; each of the test plans is composed of a plurality of preset software function test cases, and each of the software function test cases is configured to test the function module of the corresponding software product;

[0155] The acquisition module 403 is used to acquire each test node of the software product to be tested;

[0156] The testing module 404 is used to call the corresponding test plan according to the test line to test each of the test nodes and obtain the test result of each of the test nodes.

[0157] The embodiments of the present application mainly have the following beneficial effects:

[0158] This application systematically constructs a complete process from process node configuration, test plan binding to test node acquisition and test execution, which can comprehensively cover the entire product line, adapt to the complex situation of rapid software iteration and changing product requirements, effectively improve the testing efficiency of software products, and effectively ensure the development quality of software products.

[0159] In some optional implementations of this embodiment, the software product quality testing device based on the development process further includes:

[0160] An inspection module, used to inspect the test circuit and obtain an inspection result of the product test circuit of the software product;

[0161] The optimization module is used to adjust and optimize the test circuit according to the inspection result of the product test circuit.

[0162] In some optional implementations of this embodiment, the software product quality testing device based on the development process further includes:

[0163] A positioning module, for locating a changed process node in response to detecting a change in the development process of a software product;

[0164] The update module is used to update the test plan bound to the changed process node.

[0165] In some optional implementations of this embodiment, the configuration module 401 includes:

[0166] A development process information acquisition unit, used to acquire standard software product development process information;

[0167] A combing unit, used to comb each process node in the development process information and determine the logical relationship between each of the process nodes;

[0168] The process connection configuration unit is used to configure the process connections between process nodes of the development process of the software product according to the logical relationship between each of the process nodes.

[0169] In some optional implementations of this embodiment, the binding module 402 is specifically used to:

[0170] Obtaining node information of each of the process nodes;

[0171] Extracting a node feature of each of the process nodes from the node information of each of the process nodes;

[0172] Calculate the matching degree of the node feature of each process node with the process node feature pre-mapped to each test plan in a preset test plan library to obtain a matching degree calculation result;

[0173] If the matching degree calculation result is greater than a preset matching degree threshold, the process node is bound to a test plan corresponding to the feature of the process node;

[0174] The process nodes and the bound test plans are assembled according to the sequence of the process relationships to obtain the assembled test circuit of the software product.

[0175] In some optional implementations of this embodiment, the acquisition module 403 is specifically used to:

[0176] According to the preset test node scanning rules, the software product to be tested is deeply detected and analyzed to identify each test node of the software product to be tested.

[0177] In some optional implementations of this embodiment, the testing module 404 is specifically used for:

[0178] Determine, according to the test line, a first node to be tested as a current test node;

[0179] According to the binding identifier of the current test node, using the index of the preset data structure, searching for the test plan corresponding thereto;

[0180] Execute each software functional test case included in the test plan one by one;

[0181] Collect the execution result of each of the test cases to obtain the test result of each of the test nodes;

[0182] A test report for the software product to be tested is generated according to the test result of each of the test nodes.

[0183] To solve the above technical problems, the present application also provides a computer device. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0184] The computer device 6 includes a memory 61, a processor 62, and a network interface 63 that are interconnected and communicated through a system bus. It should be noted that the figure only shows a computer device 6 with a memory 61, a processor 62, and a network interface 63, but it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented instead. Among them, those skilled in the art can understand that the computer device here is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to microprocessors, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable gate arrays (Field-Programmable Gate Array, FPGA), digital processors (Digital Signal Processor, DSP), embedded devices, etc.

[0185] The computer device may be a computing device such as a desktop computer, a notebook, a PDA, a cloud server, etc. The computer device may interact with a user through a keyboard, a mouse, a remote controller, a touch pad, or a voice control device.

[0186] The memory 61 includes at least one type of readable storage medium, and the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc. In some embodiments, the memory 61 can be an internal storage unit of the computer device 6, such as a hard disk or memory of the computer device 6. In other embodiments, the memory 61 can also be an external storage device of the computer device 6, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (FlashCard), etc. equipped on the computer device 6. Of course, the memory 61 can also include both the internal storage unit of the computer device 6 and its external storage device. In this embodiment, the memory 61 is generally used to store the operating system and various application software installed on the computer device 6, such as computer-readable instructions of a software product quality testing method based on a development process, etc. In addition, the memory 61 can also be used to temporarily store various types of data that have been output or are to be output.

[0187] The processor 62 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chips in some embodiments. The processor 62 is generally used to control the overall operation of the computer device 6. In this embodiment, the processor 62 is used to run the computer-readable instructions stored in the memory 61 or process data, such as running the computer-readable instructions of the software product quality testing method based on the development process.

[0188] The network interface 63 may include a wireless network interface or a wired network interface. The network interface 63 is generally used to establish a communication connection between the computer device 6 and other electronic devices.

[0189] The embodiments of the present application mainly have the following beneficial effects:

[0190] This application systematically constructs a complete process from process node configuration, test plan binding to test node acquisition and test execution, which can comprehensively cover the entire product line, adapt to the complex situation of rapid software iteration and changing product requirements, effectively improve the testing efficiency of software products, and effectively ensure the development quality of software products.

[0191] The present application also provides another implementation, namely, providing a computer-readable storage medium, wherein the computer-readable storage medium stores computer-readable instructions, and the computer-readable instructions can be executed by at least one processor to enable the at least one processor to perform the steps of the software product quality testing method based on the development process as described above.

[0192] The embodiments of the present application mainly have the following beneficial effects:

[0193] This application systematically constructs a complete process from process node configuration, test plan binding to test node acquisition and test execution, which can comprehensively cover the entire product line, adapt to the complex situation of rapid software iteration and changing product requirements, effectively improve the testing efficiency of software products, and effectively ensure the development quality of software products.

[0194] The non-Company software tools or components appearing in the embodiments of this application are merely examples and do not represent actual use.

[0195] Obviously, the embodiments described above are only some embodiments of the present application, not all embodiments. The preferred embodiments of the present application are given in the accompanying drawings, but they do not limit the patent scope of the present application. The present application can be implemented in many different forms. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present application more thorough and comprehensive. Any equivalent structure made by using the contents of the specification and drawings of this application, directly or indirectly used in other related technical fields, is also within the scope of patent protection of this application.

Claims

1. A software product quality testing method based on development process, characterized in that: The following steps are involved: Based on the standard software product development process information, configure the process relationship between process nodes of the software product development process; Bind a corresponding test plan to each of the process nodes, and obtain a test circuit for the assembled software product according to the process relationship between the process nodes; each of the test plans is composed of a plurality of preset software function test cases, and each of the software function test cases is configured to test a functional module of the corresponding software product; Obtain each test node of the software product to be tested; According to the test circuit, the corresponding test plan is called to test each of the test nodes to obtain the test result of each of the test nodes.

2. The software product quality testing method based on development process according to claim 1 is characterized in that: After the step of binding a corresponding test plan to each of the process nodes and obtaining a test circuit of the assembled software product according to the process relationship between the process nodes, and before the step of obtaining each test node of the software product to be tested, the method further includes: Conducting an inspection on the test circuit to obtain an inspection result of the product test circuit of the software product; According to the inspection result of the product test circuit, the test circuit is adjusted and optimized.

3. The software product quality testing method based on development process according to claim 1 is characterized in that: After testing each of the test nodes by calling a corresponding test plan according to the test line and obtaining a test result of each of the test nodes, the method further includes: In response to detecting a change in a development process of a software product, locating a process node where the change occurred; Update the test plan bound to the changed process node.

4. The software product quality testing method based on development process according to claim 1 is characterized in that: The standard-based software product development process information configures the process relationships between process nodes of the software product development process, including: Obtain standard software product development process information; Sorting out each process node in the development process information and determining the logical relationship between each process node; According to the logical relationship between each of the process nodes, the process connections between the process nodes of the development process of the software product are configured.

5. The software product quality testing method based on development process according to claim 1 is characterized in that: Binding a corresponding test plan to each of the process nodes, and obtaining a test circuit for the assembled software product according to the process relationship between the process nodes, includes: Obtaining node information of each of the process nodes; Extracting a node feature of each of the process nodes from the node information of each of the process nodes; Calculate the matching degree of the node feature of each process node with the process node feature pre-mapped to each test plan in a preset test plan library to obtain a matching degree calculation result; If the matching degree calculation result is greater than a preset matching degree threshold, the process node is bound to a test plan corresponding to the feature of the process node; The process nodes and the bound test plans are assembled according to the sequence of the process relationships to obtain the assembled test circuit of the software product.

6. The software product quality testing method based on development process according to claim 1 is characterized in that: The step of obtaining each test node of the software product to be tested includes: According to the preset test node scanning rules, the software product to be tested is deeply detected and analyzed to identify each test node of the software product to be tested.

7. The software product quality testing method based on development process according to claim 5 is characterized in that: The step of calling a corresponding test plan to test each of the test nodes according to the test line to obtain a test result of each of the test nodes includes: Determine, according to the test line, a first node to be tested as a current test node; According to the binding identifier of the current test node, using the index of the preset data structure, searching for the test plan corresponding thereto; Execute each software functional test case included in the test plan one by one; Collect the execution result of each of the test cases to obtain the test result of each of the test nodes; A test report for the software product to be tested is generated according to the test result of each of the test nodes.

8. A software product quality testing device based on development process, characterized in that: include: A configuration module is used to configure the process relationships between process nodes of the software product development process based on standard software product development process information; A binding module, used to bind a corresponding test plan to each of the process nodes, and obtain a test circuit of the assembled software product according to the process relationship between the process nodes; each of the test plans is composed of a plurality of preset software function test cases, and each of the software function test cases is configured to test a functional module of the corresponding software product; An acquisition module, used to acquire each test node of the software product to be tested; The test module is used to call the corresponding test plan according to the test line to test each of the test nodes and obtain the test result of each of the test nodes.

9. A computer device, characterized in that: The method comprises a memory and a processor, wherein the memory stores computer-readable instructions, and the processor implements the steps of the software product quality testing method based on the development process as claimed in any one of claims 1 to 7 when executing the computer-readable instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the software product quality testing method based on the development process as claimed in any one of claims 1 to 7.

Images