Server item testing method, electronic equipment and storage medium

Abstract

The invention discloses a server project testing method, electronic equipment and a storage medium, and relates to the technical field of server tests.The server project testing method comprises the steps that project data of a plurality of server projects are obtained, contrastive analysis is conducted, a demand difference matrix is established, undetermined test cases corresponding to projects with similar demand dimensions can be recognized, and the test efficiency is improved. The undetermined test cases with similar requirements are reused, so that repeated labor is reduced, and the test efficiency is improved; the demand difference matrix reflects the difference of different items in each demand dimension, and the test scheme determined based on the demand difference matrix not only multiplexes test cases with similar demands, but also can process the difference part in a targeted manner. Through project data comparison and demand difference matrix construction, the communication coordination cost and human errors are reduced, the problems of low efficiency, information lag and subjective judgment deviation of manual analysis in a large-scale project parallel scene are solved, and cross-project test case reuse and scheme formulation are more efficient and objective.

Description

Technical Field

[0001] The present application relates to the technical field of server testing, and in particular to a testing method, electronic device, and storage medium for a server project. Background Art

[0002] In the field of server project R&D and testing, as business expands and technology evolves, multiple projects often need to be advanced simultaneously. These parallel projects often share similar requirements, such as stability testing of basic functional modules and compatibility testing of specific protocols. However, current project management and testing methods have significant drawbacks. Traditional single-project requirements analysis and test design methods focus only on the local data of a single project, conducting requirements analysis and test plan development in isolation for each project, while neglecting to consider the overall product line.

[0003] To improve this situation, some practitioners have attempted to adopt manual cross-project requirements analysis. However, this method has exposed many problems in actual application. On the one hand, its efficiency is extremely low, and it relies heavily on manual operations to collect and compare massive amounts of multi-project requirements data. The communication and coordination costs are high, which not only consumes a lot of time, but also makes manual operations prone to errors. On the other hand, manual communication methods have inherent limitations. It is difficult to obtain complete data from all projects in real time. This makes the analysis results often lagging or one-sided, and cannot truly reflect the overall picture of the project. In addition, it is difficult for humans to conduct a systematic comparative analysis of the differences in the implementation of requirements of different projects from multiple dimensions, such as performance parameters, compatibility range, test depth and coverage, etc., resulting in a lack of sufficient data support for optimizing test plans, making it difficult to formulate scientific and reasonable plans. As the number of projects continues to increase, the complexity of manual analysis increases exponentially, and it is unable to adapt to the needs of the rapid development of product lines. Summary of the Invention

[0004] The present application provides a server project testing method, electronic device and storage medium to at least solve the problems of low efficiency, information lag and subjective judgment bias in related technical manual analysis in large-scale project parallel scenarios.

[0005] This application provides a server project testing method, including: Obtain project data for multiple server projects; perform comparative analysis on the project data and establish a demand difference matrix for multiple server projects; wherein, elements in the same row of the demand difference matrix represent project data for different server projects under the same demand dimension, and elements in the same column represent project data for the same server project under different demand dimensions; obtain pending test cases for multiple server projects based on the demand difference matrix and the project data, wherein the pending test cases are test cases corresponding to server projects with similar demand dimensions; determine a test plan for each server project based on the pending test cases; and test the server according to the test plan for each server project.

[0006] This application also provides a testing device for a server project, comprising: Project data acquisition module, used to obtain project data of multiple server projects; A cross-project multi-dimensional analysis module is used to compare and analyze project data and establish a demand difference matrix for multiple server projects. Elements in the same row of the demand difference matrix represent project data for different server projects under the same demand dimension, and elements in the same column represent project data for the same server project under different demand dimensions. A test case acquisition module is used to obtain pending test cases for multiple server projects based on the requirement difference matrix and project data. The pending test cases are test cases corresponding to server projects with similar requirement dimensions. The test plan generation module is used to determine the test plan for each server project based on the pending test cases; The test module is used to test the server according to the test plan of each server project.

[0007] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of the above-mentioned server project testing method when executing the computer program.

[0008] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of the testing method for the above-mentioned server project are implemented.

[0009] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned server project testing method when executed by a processor.

[0010] This application obtains the project data of multiple server projects and conducts comparative analysis to establish a demand difference matrix, which can identify the pending test cases corresponding to projects with similar demand dimensions. By reusing the pending test cases with similar demands, duplication of work is reduced, manpower, time and other resources are saved, and testing efficiency is improved. The demand difference matrix clearly presents the differences between different projects in various demand dimensions. The test plan determined based on this not only reuses the test cases with similar demands, but also can deal with the differences in a targeted manner. Through systematic project data comparison and demand difference matrix construction, the process of manual collection and comparison of data is replaced, communication and coordination costs and human errors are reduced, and the problems of low efficiency, information lag and subjective judgment bias of manual analysis in large-scale project parallel scenarios are solved, making cross-project test case reuse and plan formulation more efficient and objective. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0012] Figure 1 A schematic diagram of the system architecture on which the testing method for a server project provided in an embodiment of the present application relies; Figure 2 A flowchart of a server project testing method provided in an embodiment of the present application; Figure 3 A schematic diagram of the structure of a testing device for a server project provided in an embodiment of the present application; Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0013] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0014] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0015] In order to more clearly illustrate the embodiments of the present application, the following briefly introduces the technical terms used in the embodiments: Based on the distributed Spring Boot microservice architecture, the traditional monolithic application is split into multiple independent and autonomous microservices. The Spring Boot framework is used to achieve rapid service development, and distributed technology is used to achieve collaboration and communication between services.

[0016] Extract, transform, load (ETL) tools are core tools in the data integration field. They are used to extract data from multiple data sources, cleanse and transform it, and ultimately load it into a target data store (such as a data warehouse or data lake). Apache NiFi is a powerful open source ETL tool.

[0017] The MySQL database stores data based on a relational model (table structure), organizes information through rows and columns, supports SQL (Structured Query Language) for data operations, and ensures data consistency and integrity.

[0018] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0019] like Figure 1 As shown, Figure 1 This is a diagram of the specific system architecture that the server project's test method execution relies on. This system architecture can be based on a distributed Spring Boot microservice architecture, including: data collection module, difference analysis module, report generation module, use case selection module, solution development module, and test execution module.

[0020] Among them, the data collection module collects project data such as requirement descriptions, test cases, and defect records from multiple channels such as requirement documents, test reports, and defect systems, based on dimensions such as function, performance, and security.

[0021] The difference analysis module converts the collected data into feature vectors, calculates the cross-project demand differences using algorithms such as cosine similarity, and generates a demand difference matrix to quantify the degree of difference between different projects in various dimensions.

[0022] The report generation module is based on the difference matrix and outputs analysis reports containing content such as the proportion of similar demands and the impact of differences. It supports visualization formats such as PDF and heat maps.

[0023] The use case selection module calculates similarity using a difference matrix and matches and reuses historical test cases. If the similarity is high, the test cases are reused directly. If there are no reused test cases, new test cases are generated based on similar requirements. If multiple projects require high-concurrency testing, the use cases are designed uniformly.

[0024] The plan formulation module combines project priorities and test cases, allocates test resources, and generates sub-project test plans, including test steps, resource configuration, execution order, etc.

[0025] The test execution module automatically deploys the test environment, calls the automated test system execution plan, automatically runs the test script according to the use case, supports failure retry to avoid the impact of occasional environmental failures; and issues an alarm when the failure rate exceeds the preset failure rate threshold.

[0026] An embodiment of the present application provides a data skew assessment method, and the method is described in detail in conjunction with the execution process of a test method for a server project.

[0027] like Figure 2 As shown, the embodiment of the present application provides a method for testing a server project, which includes the following steps S201 to S205: S201. Obtain project data of multiple server projects.

[0028] The project data includes but is not limited to at least one of the following: project requirement documents, defect records, functional design documents, business process descriptions, technical implementation plans, and historical test cases.

[0029] In some embodiments, after acquiring project data, the project data is first categorized and organized. Specifically, the project data is categorized and organized according to multiple requirement dimensions, including but not limited to functional requirements, performance requirements, and security requirements. The functional requirements dimension focuses on the technical implementation details of the same functions across different server projects; the performance requirements dimension compares the operational efficiency differences between different server projects through quantitative indicators; and the security requirements dimension focuses on the differences in security levels between different server projects.

[0030] For example, project data in the functional requirements dimension includes input and output parameters, interface call processes, etc. For input and output parameters, Project A requires the user's ID number as input, while Project B requires the user's mobile phone number. For interface call processes, Project A requires login verification before calling the interface, while Project B can call the interface directly.

[0031] Project data in the performance requirement dimension includes throughput, response time, and resource utilization. Regarding throughput, Project A requires processing greater than or equal to 500 requests per second, while Project B requires processing greater than or equal to 800 requests per second. Regarding response time, Project A requires an average response time of less than or equal to 200 milliseconds, while Project B requires an average time of less than or equal to 500 milliseconds. Regarding resource utilization, Project A requires a central processing unit (CPU) utilization of less than or equal to 30%, while Project B requires a CPU utilization of less than or equal to 60%.

[0032] Project data related to security requirements includes authentication methods, encryption algorithms, and permission control policies. Regarding authentication methods, Project A requires a combination of passwords and verification codes, while Project B requires fingerprint authentication. Regarding encryption algorithms, Project A requires the Advanced Encryption Standard (AES) algorithm, while Project B requires the Data Encryption Standard (DES) algorithm. Regarding permission control policies, Project A requires administrator authorization, while Project B does not.

[0033] The above-mentioned implementation systematically acquires project data and organizes it by required dimensions, replacing the manual process of collecting and comparing massive amounts of data. This reduces duplication of effort and human error, and improves analysis efficiency. Categorizing by dimensions such as function, performance, and security provides a structured framework for systematic comparison, eliminating the limitations of manual multi-dimensional analysis and providing sufficient data support for subsequent optimization solutions.

[0034] Demand dimensions can also include resource requirements, cost requirements, business requirements, and price requirements. Resource requirements include server quantity, specifications, network bandwidth, and storage capacity; cost requirements include hardware procurement costs, operation and maintenance costs, energy costs, and cloud resource fees; business requirements include project scale, rollout cycle, number of failures, and recovery time; and price requirements include technology stacks, deployment models, and cluster architecture.

[0035] In some embodiments, source data is collected from project management systems, document storage systems, and test management systems using ETL tools. For example, requirement documents and defect records are collected from the project management system, functional design documents and technical solutions are collected from the document storage system, and historical test cases are collected from the test management system.

[0036] Preprocess the classified project data, including but not limited to deduplication, formatting, and standardization. Optionally, based on the server project ID and timestamp, remove redundant data from repeated collections; fill missing fields with default values ​​or historical averages; and unify the units of project data. Associate the classified project data using the server project ID.

[0037] For example, for project data from different server projects, standardize the indicator names, calculation calibers, and units. For example, unify "interface response speed" to "average response time" and use a unified unit of "milliseconds." Use structured descriptions for "function implementation methods."

[0038] Automated pre-processing operations such as deduplication and formatting replace the tedious process of manual data screening and organization, reducing duplication of effort and human error, and improving data processing efficiency. Standardization eliminates differences in data formats and statistical calibers across projects, facilitating systematic, multi-dimensional comparisons across projects and avoiding analytical biases caused by inconsistent data standards during manual comparisons.

[0039] Preprocessed source data can be used as project data, including the server project ID, requirement dimensions, and project metrics. Project metrics include response time, throughput, and more. A data archive is created for each project, linking specific metrics for each requirement dimension to form a standardized dataset, which is stored in a MySQL table. Examples include project_requirement and performance_index.

[0040] S202: Compare and analyze project data to establish a demand difference matrix for multiple server projects.

[0041] Elements in the same row of the demand variance matrix represent project data for different server projects under the same demand dimension, and elements in the same column identify project data for the same server project under different demand dimensions. The demand variance matrix can be a three-dimensional matrix, representing the correspondence between server projects, demand dimensions, and variance values. For example, the demand variance matrix [500, 800] has the meaning shown in Table 1. In the table, TPS stands for transactions per second, indicating the number of transactions the system can complete per unit time.

[0042] Table 1

[0043] In some embodiments, during step S202, the project data is first converted into feature vectors, and then a first similarity of the feature vectors under any demand dimension is calculated, and then a demand difference matrix is ​​established based on the similarity. Here, the similarity between projects on different servers is calculated using the cosine similarity calculation method.

[0044] Specifically, all project data for multiple server projects is converted into feature vectors, with each feature vector corresponding to each server project. For example, textual project data, such as functional descriptions, is converted into feature vectors. Feature vectors are constructed for quantitative metrics, such as throughput. The first similarity between any two feature vectors under the same requirement dimension is then calculated, representing the similarity between different server projects under the same requirement dimension. Based on this first similarity, a requirement difference matrix is ​​constructed to record the specific differences between different server projects.

[0045] Optionally, the first similarity of the feature vector in any required dimension is calculated according to the following formula (1): (1) in, Indicates that the project data Pi is in the demand dimension D k The eigenvectors on , Indicates that the project data Pj is in the demand dimension D k The closer the similarity is to 1, the better the demand dimension D is. k The more similar project i and project j are, the closer the similarity is to 0, indicating that they are in the demand dimension D. k The greater the difference between item i and item j.

[0046] For example, in terms of functional requirements, we can compare the specific implementation methods and input and output requirements of the same functions in different server projects. In terms of performance requirements, we can compare the differences in indicators such as response time and throughput among different server projects. In terms of security requirements, we can compare the differences in authentication methods, encryption algorithms, and permission control strategies among different server projects.

[0047] Perform cross-project, multi-dimensional comparative analysis of project data from multiple server projects. This includes horizontally comparing multiple project data within the same requirement dimension and performing cross-dimensional analysis of the same project data across multiple requirement dimensions. By calculating the similarity of different project data across pre-set requirement dimensions, a requirement difference matrix is ​​constructed. This structured matrix presents the differences across various requirement dimensions for the same server project.

[0048] The above embodiment converts project data into feature vectors and calculates similarity through the cosine similarity formula, replacing manual subjective comparison of multi-project data with automated mathematical calculations, greatly reducing the amount of manual operation and errors caused by subjective judgment, and significantly improving analysis efficiency. Through feature vector conversion, various types of project data are unified into a computable mathematical form, combined with a mechanism for calculating the first similarity according to the demand dimension, a systematic quantitative comparison of multiple dimensions is achieved, which makes up for the limitation that manual multi-dimensional analysis is difficult to fully cover. The demand difference matrix constructed based on feature vectors and cosine similarity objectively records project differences with quantitative similarity, provides an accurate data basis for analysis conclusions, and avoids the problem that conclusions in manual analysis rely on empirical judgment and lack empirical support.

[0049] In some embodiments, for any requirement dimension, difference information between different project data is extracted. For example, in the performance requirement dimension, assuming that Project A requires a response time of 200ms or less, and Project B requires a response time of 150ms or less, the extracted difference information indicates a threshold difference. The elements of the requirement difference matrix record this difference information. For quantitative indicators, the matrix elements are specific values ​​and the magnitude of the difference; for qualitative descriptions, the matrix elements can use structured text to describe the differences between the different project data.

[0050] In some embodiments, the similarities of all demand dimensions are combined to obtain the overall similarity between different server projects through weighted calculation. The weights in the calculation process can be dynamically adjusted according to the business priority. Optionally, the calculation is performed according to the following formula (2): (2) In formula (2), Sim ij represents the overall similarity between server project i and server project j, m is the total number of requirement dimensions, and k is the kth requirement dimension among the m requirements.

[0051] The above embodiment uses a weighted calculation to integrate similarities across all dimensions, converting the results of multi-dimensional difference analysis into an overall similarity between projects. This replaces the subjective weighing of differences across dimensions with standardized mathematical calculations, avoiding biased conclusions caused by empirical bias in manual analysis and making the overall assessment of project differences more objective. By integrating all demand dimensions, the analysis ensures comprehensive coverage of these dimensions, overcoming the limitations of manual analysis in fully integrating multi-dimensional information and enabling a more systematic and complete assessment of overall differences between projects.

[0052] S203: Obtain pending test cases for multiple server projects based on the requirement difference matrix and project data.

[0053] Among them, the pending test cases are test cases corresponding to server projects with similar requirement dimensions.

[0054] In some embodiments, historical test cases are obtained from a historical test case library (test_case_library), and the historical requirement dimensions corresponding to the historical test cases are determined. A second similarity is then calculated between the historical requirement dimensions and the requirement dimensions of the project data. If the second similarity is greater than or equal to a similarity threshold, the historical test cases are adjusted according to a requirement difference matrix to obtain pending test cases. The similarity threshold is preset and may be 60%.

[0055] Specifically, any historical test case is retrieved from the historical test case library, and its requirement dimension is determined. A second similarity is then calculated between the requirement dimension of the historical test case and the requirement dimension corresponding to any server project. The second similarity is compared with a set similarity threshold. If the second similarity is greater than or equal to the similarity threshold, it indicates that the requirements of the historical test case are similar to those of the current server project. The historical test case is then adjusted based on the requirement difference matrix, and the test parameters in the historical test case are adjusted to obtain a pending test case, so that the test case is more closely aligned with the requirements of the server project.

[0056] The above embodiment automatically matches test cases with similar requirements from the historical use case library, replacing the process of manually building test cases from scratch, reducing duplication of work; at the same time, the test parameters are automatically adjusted according to the demand difference matrix, greatly improving the efficiency of test case adaptation to new projects, avoiding the tediousness of manual modification one by one. Standardized similarity calculation is used instead of manual subjective judgment to screen reusable historical use cases, and the quantitative difference information in the matrix is ​​used to guide parameter adjustment, reducing errors caused by lack of experience or negligence during manual matching and modification, and improving the accuracy of test cases. Based on the similarity between the demand dimension of the historical use case and the demand dimension of the current project, the use case adjustment is performed in combination with the specific difference data in the demand difference matrix, so that the generation and optimization of test cases have clear data support, avoiding the problem of relying on subjective experience and lack of objective basis when manually designing use cases. In addition, the test case generation of new projects can be batch processed through an automated process. When the number of projects increases, it is only necessary to expand the historical use case library and the demand difference matrix, avoiding the problem of manual processing complexity increasing exponentially with the number of projects, supporting the rapid iteration of product lines.

[0057] Based on the above embodiment, if the second similarity is less than the similarity threshold, similar requirement dimensions of multiple server projects are determined according to the requirement difference matrix, and then pending test cases for multiple server projects are designed based on the similar requirement dimensions and project data of the multiple server projects.

[0058] It can be understood that if the second similarity is less than the similarity threshold, it indicates that there are no reusable historical test cases in the historical test case library, and new test cases need to be designed. During the design process, the similar requirement dimensions of multiple server projects are first determined based on the previously constructed requirement difference matrix of multiple server projects. Then, based on these similar requirement dimensions and the project data of multiple server projects, the pending test cases for each server project are designed. This can remind test engineers to collaborate on the design.

[0059] When there are no historical test cases to reuse, the above-mentioned embodiment automatically locates similar demand dimensions of multiple projects based on the demand difference matrix, and then generates new test cases in combination with project data, replacing the process of manually designing one by one from scratch, reducing duplication of work, and greatly improving the efficiency of test case generation. Use cases are designed based on the similar dimensions quantified in the demand difference matrix to ensure that new test cases cover common project requirements, avoid omissions or deviations in use cases due to limited perspectives or subjective judgments during manual design, and improve the comprehensiveness and objectivity of use cases. By clarifying similar demand dimensions through the difference matrix, the design of new test cases is based on the comparison of multi-project data, solving the problem of lack of system data support and reliance on experience judgment when manually designing use cases, and making test cases more in line with the actual needs of the project. The matrix-based similarity dimension extraction and use case design logic can be applied to new projects in batches. When the number of projects increases, it is only necessary to expand the matrix analysis range to avoid the problem of manual design complexity increasing exponentially with the number of projects, and support the rapid expansion of product lines.

[0060] In some embodiments, an analysis report is generated based on the requirement difference matrix and the project data, and then test cases matching the project requirements are obtained based on the analysis report.

[0061] The analysis report includes project requirements, the percentage of similar requirements, and the impact of different requirements on project development and testing. For example, the analysis report may include: differences in performance requirements may require additional stress testing for concurrent testing of the project. The analysis report also includes the number of projects and the percentage of similar requirements.

[0062] The analysis report can visualize the demand variance matrix using a heat map. Darker heat map colors indicate greater differences between the same project data across different demand dimensions. To improve matrix readability, color-coded differences can be used, such as red for significant differences and yellow for minor differences. This transforms complex matrix data into easily understandable graphical information, replacing the ambiguity of manual text descriptions and reducing bias in information interpretation. Analysis reports can be formatted as PDF documents or JSON structured data, facilitating rapid communication and review, eliminating information lags caused by manual communication.

[0063] Based on the analysis report, identify similar requirements across multiple project data and select or design test cases for these requirements. When selecting or designing test cases, fully consider the differences between similar requirements across projects to ensure that the test cases fully cover the similar requirements in each project.

[0064] The above embodiment automatically generates an analysis report based on the demand difference matrix and project data, replacing the tedious process of manually collating and summarizing the analysis results of multiple projects; all conclusions in the report are derived based on the demand difference matrix and project data, avoiding the problem that the conclusions in manual analysis rely on experience and judgment and lack empirical support, and providing a clear basis for decision-making.

[0065] S204: Determine the test plan for each server project based on the pending test cases.

[0066] In some embodiments, a resource allocation strategy for the test cases is determined based on the pending test cases and the priorities of multiple server projects, and then a test plan for each server project is generated based on the resource allocation strategy and the pending test cases.

[0067] The above embodiment automatically determines the resource allocation strategy based on the pending test cases and project priorities, replacing the process of manually allocating test resources based on experience, avoiding the inefficiency caused by manually weighing the priorities of multiple projects, quickly matching the test requirements and resource supply of each project, and improving the overall test plan generation efficiency. Standardized priority rules rather than manual subjective judgment are used to guide resource allocation to ensure the rationality of resource inclination towards high-priority projects; at the same time, test plans are generated based on the specific content of the pending test cases to reduce resource mismatches or plan omissions caused by inadequate consideration during manual allocation. The resource allocation strategy will be based on the pending test cases of historical case adjustments or similar demand designs, as well as project priorities as data, so that the formulation of the test plan has a clear objective basis, avoiding the problem of relying on experience and lack of empirical support when manually designing plans, and improving the scientific nature of the plans.

[0068] In some embodiments, the test plan includes a resource allocation strategy, a test sequence, a test plan, a resource scheduling strategy, and a risk plan. The resource allocation strategy allocates resources to the test plan of each server project according to the priority of the server project. For example, the core business has a higher priority, and more test equipment will be allocated. The test plan contains each time node and the relevant responsible persons. The resource scheduling strategy includes the address information and configuration information of the test server. Assuming that a server project fails the performance test, the risk plan is to start a backup stress testing cluster.

[0069] Based on the pending test cases and incorporating the characteristics and requirements of each server project, we develop and optimize test plans for each server project. We also optimize the test plan from a holistic perspective, such as by rationally allocating test resources and adjusting test sequences, to achieve optimal test results and ultimately formulate a final test plan.

[0070] S205: Test the server according to the test plan of each server project.

[0071] In some embodiments, a test environment is first deployed according to the test plan of each server project; and an automated testing system is called in the test environment to execute the corresponding test plan.

[0072] In some embodiments, pending test cases are grouped according to the requirement dimension, and pending test cases with similar requirement dimensions are divided into the same group. They are executed in groups, and the test plans of the server projects in each project group are executed separately, reducing the cost of environment switching.

[0073] Execute the test plan corresponding to each project data according to the test plan and provide feedback on the test results. Test results include test logs, functional requirement coverage, performance requirement compliance, etc. If the test plan fails, retry until it succeeds or reaches a preset number of retries. Failure rates can also be calculated, and an alarm is triggered if the failure rate exceeds a preset failure rate threshold. For example, when the failure rate exceeds 30%, the test engineer is notified via email.

[0074] The above-mentioned embodiment replaces the tedious process of manually setting up the environment and executing tests case by case by automating the deployment of the test environment and invoking the automated testing system to execute the solution, thus reducing repetitive operations. An automatic retry mechanism is also implemented to avoid the time lost by manual intervention to resolve temporary failures, significantly improving the efficiency of multi-project testing. Real-time feedback of test logs, failure rate statistics, and an alert mechanism replaces the passive mode of periodic manual testing progress checks, ensuring that problems are promptly identified and addressed, avoiding the delays in fault response caused by manual communication.

[0075] In summary, the embodiment of the present application provides a testing method for server projects, which clarifies the scope of project data and classifies and organizes it according to demand dimensions such as function, performance, and security, replacing manual collection and subjective classification, reducing duplication of work and human errors; converting project data into feature vectors, using the cosine similarity formula to quantify multi-dimensional differences and generate a demand difference matrix, replacing manual subjective comparison, greatly reducing the amount of operations and errors; reusing historical test cases through similarity matching, and automatically adjusting test parameters based on the demand difference matrix; when there are no reused cases, batch generating new cases based on similar demand dimensions, avoiding the inefficiency of manual design from scratch. The similarity calculation logic can be flexibly expanded as the number of projects increases, and only the feature vector and matrix dimensions need to be expanded, avoiding the exponential increase in the complexity of manual analysis.

[0076] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0077] like Figure 3 As shown, an embodiment of the present application further provides a testing device for a server project, the device comprising: The project data acquisition module 301 is used to acquire project data of multiple server projects; Cross-project multi-dimensional analysis module 302 is used to compare and analyze project data and establish a demand difference matrix for multiple server projects. Elements in the same row of the demand difference matrix represent project data for different server projects under the same demand dimension, and elements in the same column represent project data for the same server project under different demand dimensions. The test case acquisition module 303 is used to acquire pending test cases for multiple server projects based on the requirement difference matrix and project data. The pending test cases are test cases corresponding to server projects with similar requirement dimensions. A test plan generating module 304 is used to determine the test plan for each server project based on the pending test cases; The testing module 305 is used to test the server according to the testing plan of each server project.

[0078] As an optional implementation provided in an embodiment of the present application, the cross-project multi-dimensional analysis module 302 is specifically used to: convert project data into feature vectors; calculate the first similarity of the feature vectors under any demand dimension; and establish a demand difference matrix based on the first similarity.

[0079] As an optional implementation provided in an embodiment of the present application, the test case acquisition module 303 is specifically used to: obtain historical test cases from a historical case library and determine the historical requirement dimensions corresponding to the historical test cases; calculate the second similarity between the historical requirement dimensions and the requirement dimensions of the project data; and when the second similarity is greater than or equal to the similarity threshold, adjust the historical test cases according to the requirement difference matrix to obtain pending test cases.

[0080] As an optional implementation provided in an embodiment of the present application, the test case acquisition module 303 is also used to: when the second similarity is less than the similarity threshold, determine the similar demand dimensions of multiple server projects based on the demand difference matrix; and design pending test cases for multiple server projects based on the similar demand dimensions and project data.

[0081] As an optional implementation provided in an embodiment of the present application, the test module 305 is specifically used to divide the server projects into multiple project groups according to the demand dimensions corresponding to the server projects; and execute the test plans of the server projects in each project group respectively in units of project groups.

[0082] As an optional implementation method provided in an embodiment of the present application, the test plan generation module 304 is specifically used to determine the resource allocation strategy of the pending test cases based on the priorities of the pending test cases and multiple server projects; and generate a test plan for each server project based on the resource allocation strategy and the pending test cases.

[0083] As an optional implementation provided in an embodiment of the present application, the project data acquisition module 301 is specifically used to: collect source data from a project management system, a document storage system, and a test management system through extraction, conversion, and loading tools; preprocess the source data to obtain project data; wherein the preprocessing includes at least one of deduplication, formatting, and standardization.

[0084] As an optional implementation provided in an embodiment of the present application, the cross-project multi-dimensional analysis module 302 is also used to: classify and organize project data of multiple server projects according to multiple demand dimensions; wherein the multiple demand dimensions include at least two of the functional demand dimension, performance demand dimension, security demand dimension, resource demand dimension, cost demand dimension, business demand dimension and price demand dimension.

[0085] For the description of the features in the embodiment corresponding to the testing device of the server project, please refer to the relevant description of the embodiment corresponding to the testing method of the server project, which will not be repeated here.

[0086] like Figure 4As shown, an embodiment of the present application further provides an electronic device, including a memory 401 and a processor 402, wherein the memory 401 stores a computer program, and the processor 402 is configured to run the computer program to execute the steps in any of the above-mentioned server project test method embodiments.

[0087] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned server project test method embodiments when running.

[0088] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0089] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned server project testing method embodiments are implemented.

[0090] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps in any of the above-mentioned server project test method embodiments.

[0091] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0092] The above is a detailed introduction to the testing method, electronic device and storage medium for a server project provided by this application. This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core ideas of this application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A server project testing method, characterized in that: include: Get project data for multiple server projects; Comparatively analyzing the project data to establish a demand difference matrix for the multiple server projects; wherein elements in the same row of the demand difference matrix represent project data for different server projects under the same demand dimension, and elements in the same column represent project data for the same server project under different demand dimensions; Obtaining pending test cases for the plurality of server projects according to the requirement difference matrix and the project data, wherein the pending test cases are test cases corresponding to server projects having similar requirement dimensions; Determine the test plan for each server project based on the pending test cases; Test the servers according to the test plan of each server project.

2. The method according to claim 1, characterized in that The comparative analysis of the project data to establish a demand difference matrix for the multiple server projects includes: converting the project data into a feature vector; Calculating a first similarity of the feature vector under any required dimension; The demand difference matrix is ​​established according to the first similarity.

3. The method according to claim 1, characterized in that The step of obtaining pending test cases for the plurality of server projects according to the requirement difference matrix and the project data includes: Obtain historical test cases from a historical test case library, and determine historical requirement dimensions corresponding to the historical test cases; calculating a second similarity between the historical demand dimension and the demand dimension of the project data; When the second similarity is greater than or equal to a similarity threshold, the historical test cases are adjusted according to the requirement difference matrix to obtain the pending test cases.

4. The method according to claim 3, characterized in that The method further comprises: When the second similarity is less than the similarity threshold, determining similar demand dimensions of the plurality of server projects according to the demand difference matrix; Design pending test cases for the multiple server projects based on the similar requirement dimensions and the project data.

5. The method according to claim 1, wherein The server is tested according to the test plan of each server project, including: According to the demand dimensions corresponding to each server project, multiple project groups are obtained; Taking project groups as units, execute the test plans of server projects in each project group separately.

6. The method according to claim 1, characterized in that Determining the test plan for each server project based on the pending test case includes: Determining a resource allocation strategy for the pending test case according to the pending test case and the priorities of the plurality of server projects; Generate a test plan for each server project based on the resource allocation strategy and the pending test cases.

7. The method according to claim 1, characterized in that The obtaining of project data of multiple server projects includes: Collect source data from project management systems, document storage systems, and test management systems through extraction, transformation, and loading tools; The source data is preprocessed to obtain the project data; wherein the preprocessing includes at least one of deduplication, formatting, and standardization.

8. The method according to claim 1, characterized in that Before performing comparative analysis on the project data and establishing a demand difference matrix for the multiple server projects, the method further includes: Classify and organize project data of the multiple server projects according to multiple demand dimensions; The multiple demand dimensions include at least two of a functional demand dimension, a performance demand dimension, a security demand dimension, a resource demand dimension, a cost demand dimension, a business demand dimension and a price demand dimension.

9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the server project testing method according to any one of claims 1 to 8 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the server project testing method according to any one of claims 1 to 8 are implemented.

Images