WO2020186810A1 - 回归测试用例确定方法、装置、计算机设备及存储介质 - Google Patents

回归测试用例确定方法、装置、计算机设备及存储介质 Download PDF

Info

Publication number
WO2020186810A1
WO2020186810A1 PCT/CN2019/120596 CN2019120596W WO2020186810A1 WO 2020186810 A1 WO2020186810 A1 WO 2020186810A1 CN 2019120596 W CN2019120596 W CN 2019120596W WO 2020186810 A1 WO2020186810 A1 WO 2020186810A1
Authority
WO
WIPO (PCT)
Prior art keywords
code
defect
version
tested
hot zone
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2019/120596
Other languages
English (en)
French (fr)
Inventor
张美苑
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OneConnect Smart Technology Co Ltd
Original Assignee
OneConnect Smart Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by OneConnect Smart Technology Co Ltd filed Critical OneConnect Smart Technology Co Ltd
Publication of WO2020186810A1 publication Critical patent/WO2020186810A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites

Definitions

  • This application relates to the technical field of software testing, and in particular to a method, device, computer equipment, and storage medium for determining regression test cases.
  • Software testing refers to the evaluation process of operating software programs under specific conditions to find software program errors and measure whether the software quality can meet the design requirements.
  • a set of standard testing strategies and testing plans are adopted for different testing stages to ensure the smooth progress of software testing.
  • multiple regression tests are required in the software development process.
  • the regression test refers to the process of modifying the old code and re-testing to confirm that the modification does not introduce new errors or cause errors in other codes.
  • the main purpose is to perform full-featured regression testing or subjective fuzzy judgment of the regression testing scope, which leads to redundant work and unnecessary manpower waste, or the omission of important test cases makes the software program specific The quality of the code module cannot be guaranteed.
  • the embodiments of the present application provide a method, a device, a computer device, and a storage medium for determining a regression test case to solve the problem of redundancy of regression test workload or inability to guarantee quality.
  • a method for determining regression test cases including:
  • test analysis request includes the ID of the version to be tested
  • the analytic hierarchy process is used to analyze the code modification hot zone and the code defect distribution hot zone to obtain target test cases.
  • a regression test case determination device including:
  • a test analysis request obtaining module configured to obtain a test analysis request, where the test analysis request includes the ID of the version to be tested;
  • the version code obtaining module to be tested is configured to obtain the version code to be tested corresponding to the version ID to be tested from the code warehouse based on the version ID to be tested;
  • the code change hot zone acquisition module is used to use the version control tool to perform code analysis on the version code to be tested and obtain the code change hot zone;
  • the code defect distribution hot zone acquisition module is used to filter the code defects of the code modification hot zone and obtain the code defect distribution hot zone;
  • the target test case acquisition module is used to analyze the code modification hot zone and the code defect distribution hot zone by using the analytic hierarchy process to obtain the target test case.
  • a computer device includes a memory, a processor, and computer-readable instructions stored in the memory and capable of running on the processor, and the processor implements the following steps when the processor executes the computer-readable instructions:
  • test analysis request includes the ID of the version to be tested
  • the analytic hierarchy process is used to analyze the code modification hot zone and the code defect distribution hot zone to obtain target test cases.
  • One or more readable storage media storing computer readable instructions
  • the computer readable storage medium storing computer readable instructions
  • the one Or multiple processors perform the following steps:
  • test analysis request includes the ID of the version to be tested
  • the analytic hierarchy process is used to analyze the code modification hot zone and the code defect distribution hot zone to obtain target test cases.
  • FIG. 1 is a schematic diagram of an application environment of the method for determining regression test cases in an embodiment of the present application
  • FIG. 2 is a flowchart of a method for determining regression test cases in an embodiment of the present application
  • FIG. 3 is another flowchart of the method for determining regression test cases in an embodiment of the present application.
  • FIG. 5 is another flowchart of a method for determining regression test cases in an embodiment of the present application.
  • FIG. 6 is another flowchart of the method for determining regression test cases in an embodiment of the present application.
  • FIG. 7 is another flowchart of the method for determining regression test cases in an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a regression test case determination device in an embodiment of the present application.
  • Fig. 9 is a schematic diagram of a computer device in an embodiment of the present application.
  • the regression test case determination method provided by the embodiment of the present application can be applied to the application environment as shown in FIG. 1.
  • the method for determining regression test cases is applied in a software test system.
  • the software test system includes a client and a server as shown in Figure 1.
  • the client and server communicate through a network for regression test analysis to determine Target test cases, so that in the process of regression testing based on the target test cases, both the quality of regression testing and the efficiency of regression testing can be guaranteed.
  • the client is also called the client, which refers to the program that corresponds to the server and provides local services to the client.
  • the client can be installed on, but not limited to, various personal computers, laptops, smart phones, tablet computers, and portable wearable devices.
  • the server can be implemented as an independent server or a server cluster composed of multiple servers.
  • a method for determining a regression test case is provided.
  • the method is applied to the server in FIG. 1 as an example for description, including the following steps:
  • test analysis request includes the ID of the version to be tested.
  • the test analysis request is a request used to trigger the server to perform regression test analysis to determine the test case required for this regression test.
  • the version ID to be tested is used to uniquely identify the specific version of the software program to be tested for defect analysis.
  • Each version ID to be tested corresponds to a specific version of the software program that needs to be tested for defect analysis, such as WeChat V6.6.7.
  • the code warehouse is a database used to store the codes of all versions of a specific software program.
  • the version code to be tested refers to the version code that needs regression testing after the last code modification.
  • Each version code ID to be tested corresponds to a version code to be tested.
  • a version code to be tested corresponding to the version ID to be tested is stored in the code warehouse, so as to perform subsequent analysis based on the version code to be tested.
  • the server is connected to a test result database.
  • the test result database stores at least one historical version test data that is homologous to the version code to be tested.
  • the historical version test data refers to the version code formed before the last code modification. Data formed during the testing process.
  • S203 Use a version control tool to perform code analysis on the code of the version to be tested, and obtain code change hot spots.
  • the version control tool is used to provide a complete version management function, a tool for storing and tracking the modification history of directories (folders) and files. It is a necessary tool for software developers and an infrastructure for software companies.
  • the highest goal of version control software is to support the configuration management activities of software companies, track the development and maintenance activities of multiple versions, and release software in a timely manner.
  • the version control tool used by the server is specifically a distributed version control system (Distributed Version Control System, referred to as DVCS).
  • DVCS distributed Version Control System
  • the client does not only extract the latest version of the file snapshot, but completes the code repository. Mirror it down. In this way, if any server used for collaborative work fails, any mirrored local warehouse can be used to restore afterwards.
  • the current version control tools that use DVCS include but are not limited to tools such as Git, Mercurial, Bazaar and Darcs.
  • the server uses Git, a version control tool, to perform code analysis on the code of the version to be tested and its corresponding historical version test data to determine hot spots for code changes.
  • the version control tool Git has the following technical advantages: 1) Suitable for distributed development, emphasizing individuals; 2) Public server pressure and data volume will not be too large; 3) Fast and flexible; 4) Between any two developers Conflicts can be resolved easily; 5) Work offline.
  • Code change hot zone refers to the frequently changed code area obtained by comparing and analyzing the code of the version to be tested and the corresponding historical version test data using version control tools. Understandably, the code change hot zone refers to the code area that is frequently changed.
  • the frequent changes are determined by the two indicators of the number of code changes and the number of code changes. The reason for the code changes may be due to the complexity of the code. Too high or the code coupling is too strong, resulting in new functions that need to change these codes, or it may just be because there are problems in the code implementation process that require frequent changes to fix code defects.
  • the server uses the version control tool Git to perform code analysis on the code of the version to be tested and all historical version test data that is homologous to the code of the version to be tested to obtain the corresponding number of lines of code changes and the number of code changes, and make changes according to the code. Analyze the number of lines and the number of code changes to obtain the corresponding code change hot spots.
  • S204 Perform code defect filtering on the code change hot zone, and obtain the code defect distribution hot zone.
  • the code change hot zone is a code area that is frequently changed after a comprehensive evaluation based on the two dimensions of the number of code changes and the number of lines of code changes, the reason for frequent changes may or may not be based on code defects.
  • the code change hot zone may correspond to a high-risk code module, that is, a functional module with more code defects. Therefore, in the regression test stage, in addition to paying attention to the number of code changes and the number of lines of code changes to determine the code hotspots, it is also necessary to identify and judge whether there are high-risk code modules in the code change hotspots to filter out high risks.
  • Code module to determine the hot spots of code defect distribution That is, by adding code defect filtering in the code change hot zone to determine the code defect distribution hot zone formed by the code defect change.
  • a regular expression for matching code defects is preset in the server. After determining the code change hot zone, the regular expression is used to match the code file of the code change hot zone, and the code corresponding to the successfully matched code file is obtained.
  • the area is a hot zone for code defect distribution.
  • the filtering method used by the server in the code defect filtering process of the code change hot zone the filter is judged by the regular expression corresponding to the name of the code file (code files formed after the code defect repair is generally marked with repair XXX.bug) , In order to achieve the purpose of determining the hot zone of code defect distribution.
  • S205 Analyze the code change hot zone and code defect distribution hot zone using the analytic hierarchy process to obtain target test cases.
  • Analytic Hierarchy Process refers to a decision-making method that decomposes elements that are always related to decision-making into goals, guidelines, and plans, and then conducts qualitative and quantitative analysis on this basis.
  • the target layer, the criterion layer and the scheme layer are configured from top to bottom.
  • the target layer is the purpose of decision-making and the problem to be solved.
  • the target layer outputs target test cases that ultimately need to be regression tested.
  • the solution layer refers to the alternative solution during decision-making.
  • the solution layer inputs at least one original test case pre-configured during the software version testing process, for example, original test case 1, original test case 2...original test case Z, where Z refers to the last original test case.
  • the criterion layer is the middle layer, which refers to the factors considered in the decision-making process and the decision-making criterion, that is, the measures and schemes adopted to achieve the purpose of decision-making.
  • the code obtained in step S203 is changed to the hot zone and step The code defect analysis hot zone obtained in S204 is used as a criterion-level factor.
  • At least one original test case pre-configured in the software version test process is used as the input of the solution layer in the AHP, and the criterion layer is formed based on the code modification hot zone and the code defect analysis hot zone, and the specific algorithm of the AHP is executed to Get the target test case output by the target layer.
  • the target test case is to use the AHP algorithm to analyze the code change hot zone and the code defect analysis hot zone, and determine the test cases that can be used in the next regression test process. Understandably, the target test case comprehensively considers at least one original test case pre-configured for the version code to be tested, the corresponding code change hot zone and code defect distribution hot zone and other information for comprehensive analysis, to select the following The test case of a regression test (ie the target test case). Understandably, the determination of the target test case can effectively reduce the redundancy of the workload when the subsequent regression test is performed based on the target test case, reduce unnecessary manpower waste, and ensure the software quality of the regression test.
  • the corresponding code change hot zone can be quickly obtained, and the code change hot zone reflects the frequency of software code changes; Code defect filtering in code change hotspots to obtain code defect distribution hotspots to determine the code areas corresponding to high-risk code modules; then use analytic hierarchy process to analyze code change hotspots and code defect distribution hotspots to obtain target tests Use cases, so that subsequent regression testing based on target test cases can effectively reduce the repetitive redundancy of the workload, reduce unnecessary manpower waste, and ensure the software quality of regression testing.
  • using a version control tool to perform code analysis on the code of the version to be tested to obtain hot spots for code changes includes the following steps:
  • S301 Use the version control tool to execute the log query command to obtain historical version test data corresponding to the version code to be tested.
  • the log query command is a command used to query the log formed during the testing of the software program.
  • the log query command is specifically used to query the test log with the test time within a preset time period in a specific storage directory, and obtain based on the test log Historical version test data.
  • the user can input the corresponding log query command to the version control tool Git through the client to obtain the historical version test data corresponding to the version code to be tested.
  • the obtaining process is simple and quick.
  • log is a log query command to obtain the corresponding test log, and obtain historical version test data based on the change information and the change file recorded in the test log.
  • the change information specifically reflects the information of the code change, such as the number of deleted code lines and the number of newly added code lines when the code was last modified.
  • the modified file refers to the file formed based on the modified code corresponding to the modified information.
  • S302 Use the version control tool to analyze the code of the test version and the test data of the historical version, and obtain the code change hot zone.
  • Git is provided with a functional module that can detect the number of code changes and the number of lines of code changes.
  • the code to be tested and the historical version test data are analyzed by executing the corresponding functional module.
  • the code module is a combination of codes that can implement a certain function in the version code to be tested.
  • the log query command is first executed to obtain historical version test data, and then the functional module in the version control tool is used to analyze the test version code and historical version test data, which can be quickly obtained Code change hotspot, through the code change hotspot to understand the changes of each code module in the version code to be tested, so that the subsequent comprehensive analysis can determine the target test case to be collected for the next regression test, and the corresponding code change hotspot Code modules are tested to avoid omissions in the regression test process to test the code modules corresponding to the code change hot zone.
  • using a version control tool to analyze the code to be tested and historical version test data to obtain hot spots for code changes includes the following steps:
  • S401 Use the Code Maat tool to analyze the to-be-tested version code and historical version test data, and obtain the number of code changes corresponding to each code module in the to-be-tested version code.
  • the Code Maat tool is a functional module written in Clojure for mining and analyzing the number of code changes in the version code to be tested.
  • the Code Maat tool is set in the version control tool Git.
  • the server uses Code Maat in the Git log file react_evo.log redirected by the user to obtain the number of code changes corresponding to each code module.
  • the number of code changes reflects the number of times a certain code module has been changed before the last test.
  • step S401 specifically includes the following steps: (1) You can first execute "java-jar code-maat/target/code-maat-1.1-SNAPSHOT-standalone.jar-l react_evo.log” in the version control tool. -c git-a summary” command line to obtain summary data corresponding to the version code to be tested and its previous version code. This summary data can feed back the number of submissions of the version code to be tested and its previous version code, and the specific code files involved Situation and developer information, etc.
  • S402 Use the Cloc tool to analyze the test version code and historical version test data, and obtain the number of code changes corresponding to each code module in the test version code.
  • Cloc is a code statistics tool Cloc configured in the version control tool Git.
  • Cloc is an open source code statistics tool developed in Perl. It supports multi-platform use, multi-language recognition, and can calculate specified target files or folders.
  • the number of code changes is another dimension indicator for judging the hot zone of code changes. Specifically, it refers to the number of changed lines of the code to be tested relative to the previous version.
  • the number of code changes includes the number of deleted code lines and new Increase the number of lines of code.
  • the dimension of the number of lines of code changes is simple and rude, and has two advantages.
  • Cloc tool is used as a tool for analyzing the number of lines of code changes. It is written in Perl and can obtain very intuitive output for programming language, files, spaces, comments and the code itself.
  • S403 Perform standardization and weighting processing on the number of code changes and the number of lines of code changes corresponding to each code module, and obtain a comprehensive evaluation index corresponding to each code module.
  • standardizing the number of code changes and the number of code changes for each code module refers to the non-dimensional quantification of the number of code changes and the number of code changes for each code module to make them comparable and comparable. Perform subsequent weighting processing.
  • the server pre-stores a standardized data conversion table.
  • the standardized data conversion table stores the number of standardized scores corresponding to the number of code changes, and stores the number of standardized scores corresponding to the number of code changes.
  • the server queries the standardized data conversion table to obtain the corresponding number of standardized scores and line number standardized scores.
  • the server pre-stores weights corresponding to the number of code changes and the number of lines of code changes. The server weights the number of code changes and the number of lines of code changes for each code module, which means that the standardized scores of the times and the number of lines of each code module and their corresponding weights are weighted to obtain the corresponding comprehensive Evaluation indicators.
  • Comprehensive evaluation index is the comprehensive evaluation index.
  • the code change hot zone can be determined according to the comprehensive evaluation index.
  • obtaining the code change hot zone based on the comprehensive evaluation index corresponding to each code module specifically includes the following steps: comparing the comprehensive evaluation index of each code module with a preset index threshold, and if the comprehensive evaluation index is greater than the preset index threshold , The area formed by the code module corresponding to the comprehensive evaluation index is determined to be a code change hot zone; conversely, if the comprehensive evaluation index is not greater than the preset index threshold, it is determined that the area formed by the code module corresponding to the comprehensive evaluation index is not Code change hot zone.
  • the preset index threshold refers to a preset threshold used to evaluate the index corresponding to the code change hot zone.
  • the number of code changes and the number of lines of code changes for each code module are integrated through comprehensive evaluation indicators to form a new In order to make the code change hot zone determined based on the comprehensive evaluation index more objective and reasonable.
  • the server may also use Circle Packing or other graphic conversion tools to display the code modification hot spots, so that the user can intuitively query the information of the code modification hot spots.
  • Circle Packing the larger the diameter of each circle, the more lines of code changes corresponding to the circle; the darker the color of each circle, the more code changes the circle represents , The more frequent the changes; the comprehensive evaluation index can be determined based on the number of code changes and the number of lines of code changes corresponding to each code module, and the code modules corresponding to the comprehensive evaluation index greater than the preset index threshold will be highlighted to make users understand the The area where the code module is located is the hot zone for code changes.
  • the Code Maat tool and the Cloc tool are used to analyze the test version code and the historical version test data respectively, and obtain the number of code changes and the number of lines of code changes respectively, and the acquisition process is simple and convenient; Standardize and weight the number of code changes and lines of code changes for each code module to obtain a comprehensive evaluation index that can comprehensively reflect the code changes; finally, based on the comparison result of the comprehensive evaluation index and the preset index threshold, it can be quickly Obtain the corresponding code change hot zone to make the obtained code change hot zone more objective.
  • the regression test case determination method further includes the following steps:
  • S501 Query the test result database based on the ID of the version to be tested, and obtain at least one code defect data corresponding to the ID of the version to be tested.
  • the test result database is a database used to store the test results of the specific version of the software program corresponding to the version ID to be tested.
  • the test result includes two results: test success and test failure.
  • the data formed based on the software code whose test result is the test failure is code defect data. That is, the code defect data is the data that the code has defects in the test process of a specific version of the software program.
  • the code defect data refers to the data corresponding to all defective codes that appear in the testing process of the software program corresponding to the version ID to be tested.
  • S502 Perform defect measurement analysis on the code defect data, and obtain the defect measurement value of the code defect data.
  • the defect measurement value is determined by comprehensively evaluating the code defect data according to a preset measurement value evaluation rule.
  • the defect measurement value can objectively reflect the severity of the defect of each code defect data.
  • the larger the defect measurement value the more serious the defect; conversely, the smaller the defect measurement value, the less serious the defect.
  • performing defect measurement analysis on code defect data refers to comprehensively evaluating code defect data according to multiple preset evaluation dimensions, so that the defect measurement value corresponding to the obtained code defect data can comprehensively reflect the code defect data.
  • the severity of the defect is a rule for comprehensive evaluation based on multiple evaluation dimensions that affect the severity of code defects.
  • the evaluation dimensions include, but are not limited to, functional core degree, page usage frequency, page access step length, recurrence probability, maintainability index and stability coefficient.
  • S503 Obtain the defect priority corresponding to the code defect data according to the defect measurement value of the code defect data, and configure a regular expression corresponding to each code defect data.
  • each defect measurement value can reflect the severity of the code defect data, and this severity can be embodied as the defect priority.
  • the larger the defect metric the higher the priority of the corresponding defect.
  • obtaining the defect priority corresponding to the code defect data according to the defect measurement value of the code defect data specifically includes the following steps: the server can query the risk level conversion table based on the defect measurement value of the code defect data to determine its corresponding defect Risk level, based on the defect risk level to determine the corresponding defect priority.
  • the risk level conversion table can divide the value range of the defect measurement value into a number of risk level ranges, and each risk level range corresponds to a defect risk level, and the server can determine its belonging according to the defect measurement value corresponding to the code defect data
  • the defect risk level corresponding to the risk level range to which it belongs is determined as the defect risk level corresponding to the defect measurement value.
  • the defect risk level can include types such as emergency risk level, high-level risk level, general risk level, and low-level risk level, and can also be set to other types.
  • the higher the value of the defect metric the higher the defect risk level, and accordingly, the higher the defect priority.
  • configuring the regular expression corresponding to each code defect data refers to configuring a regular expression that can match the corresponding code defect.
  • step S204 code defect filtering is performed on the code change hot zone to obtain the code defect distribution hot zone, which specifically includes the following steps: according to the defect priority corresponding to the code defect data, the regular expression corresponding to the code defect data is used to Change the hot zone for code defect filtering, and obtain the hot zone for code defect distribution.
  • the server will sequentially adopt the regular expressions corresponding to the code defect data corresponding to the emergency risk level, the high risk level, the general risk level, and the low risk level according to the defect priority corresponding to each code defect data, and make changes to the code change hot spots.
  • the code module corresponding to the code defect data with the defect priority is not the hot zone for code defect distribution, and the code module corresponding to the code defect data with the defect priority is also not the hot zone for the code defect distribution.
  • the defect metric value of each code defect data of the version code to be tested is obtained to determine its defect priority. Since the determination of the defect metric value is determined with reference to multiple evaluation dimensions, Makes the finalized defect priority more objective. Then, according to the order of defect priority, the regular expression corresponding to the code defect data is used to filter the code defect hotspots in order to quickly obtain the code defect distribution hotspots and improve the efficiency of obtaining the code defect distribution hotspots.
  • step S502 performing defect measurement analysis on the code defect data to obtain the defect measurement value of the code defect data includes the following steps:
  • S601 Perform a syntax tree analysis on the code defect data based on the abstract syntax tree corresponding to the ID of the version to be tested, and obtain the functional core degree corresponding to the code defect data.
  • the abstract syntax tree (abstract syntax code, AST) is a tree-like representation of the abstract syntax structure of the source code. Each node on the tree represents a structure in the source code. The reason why it is said to be abstract is because of the abstraction.
  • the grammar tree does not show every detail of the actual grammar (for example, nested parentheses are hidden in the structure of the tree and are not presented in the form of nodes).
  • the server may use the javascript Parser source code parser in advance to transform the software program corresponding to the ID of the version to be tested edited in JAVA language to convert it into an abstract syntax tree corresponding to the ID of the version to be tested. It is further transformed into bytecode or directly generated machine code for subsequent program analysis.
  • the server uses the emma code analysis tool to analyze the running flow of the code defect data on the abstract syntax tree corresponding to the version ID to be tested, and determine the position of the code defect data in the abstract syntax tree, and according to its location To determine its corresponding functional core degree, it can be represented by R.
  • the code defect data is in the main position of the abstract syntax tree, its functional core degree is the highest, which is determined to be R0; if the code defect data is in the secondary main position in the abstract syntax tree, its functional core degree is second , Determined as R1 level; if the code defect data is in the secondary position in the abstract syntax tree, its function core level is lower, and it is determined as R2 level...and so on, determine the position of the code defect data in the abstract syntax tree , So as to determine its corresponding functional core degree.
  • the code defect data is analyzed by syntax tree analysis on the code defect data through the pre-created abstract syntax tree corresponding to the ID of the version to be tested, and the function core degree corresponding to the code defect data can be quickly obtained, which can reflect that the code defect data is in the whole to be tested.
  • the degree of importance in the software program corresponding to the test version ID so that the core degree of the function can be used as an evaluation factor to evaluate the corresponding defect measurement value, and the defect measurement value corresponding to the code defect data can be comprehensively evaluated to treat the test version Comprehensive analysis of the software program corresponding to the ID.
  • S602 Query the embedded point database corresponding to the ID of the version to be tested based on the code defect data, and obtain the page usage frequency and the page access step length corresponding to the code defect data.
  • the buried point refers to the key code implantation in the software program to realize the data statistics function code.
  • the setting of buried points is mainly used to track user behaviors, so as to count the use of key codes for data analysis.
  • the buried point database is a database used to store the buried point data uploaded by the buried point, and each buried point data can reflect the triggering or operation of the key code corresponding to the buried point.
  • the embedded point database corresponding to the version ID to be tested is used to store all the embedded point data formed when the embedded point of the software program corresponding to the version ID to be tested is triggered during the test, so as to be based on the embedded point data Perform data analysis.
  • the frequency of use of the page corresponding to the code defect data refers to the number of clicks on the functional page corresponding to the code defect data through the statistics of buried points, and the corresponding page use frequency is determined according to the number of clicks.
  • the process of determining the usage frequency of the page corresponding to the code defect data includes the following steps: based on the code defect data query the buried point database corresponding to the version ID to be tested, and obtain the software code corresponding to the code defect data triggered during the test cycle
  • the embedded point data according to the embedded point data, determine the click volume of the function page corresponding to the code defect data, query the preset frequency conversion information table based on the click volume, and obtain the page usage frequency corresponding to the click volume.
  • the test cycle refers to the cycle of testing the software program corresponding to the version ID to be tested.
  • the frequency conversion information table is an information table used to define the conversion relationship between the click volume and the corresponding frequency.
  • the frequency conversion information table is queried based on the click volume to obtain the page access frequency corresponding to the version ID to be tested.
  • the page usage frequency corresponding to the code defect data includes three types: V0, V1, and V2, which respectively correspond to the three situations of high frequency, normal, and low frequency.
  • V0, V1, and V2 which respectively correspond to the three situations of high frequency, normal, and low frequency.
  • the higher the usage frequency of the page corresponding to the code defect data the more frequently the corresponding software code is triggered, and the more important it is in the software program corresponding to the version ID to be tested.
  • the page access step length corresponding to the code defect data refers to the length of the operation step for determining the function page corresponding to the code defect data through the statistics of buried points.
  • the process of determining the page access step size corresponding to the code defect data includes the following steps: query the embedded point database corresponding to the version ID to be tested based on the code defect data, obtain the embedded point data triggered by the code defect data, and according to the embedded point data Determine the corresponding page visit step. Specifically, in the process of setting the embedding points of the software program corresponding to the version to be analyzed, the position of the function page corresponding to each embedding point is recorded in advance through the page information table.
  • the server can determine the corresponding functional page according to the embedded point data triggered by the embedded point, and determine the operation steps of the functional page according to the page information table recorded during the software program development process to obtain the page corresponding to the code defect data Visit step size.
  • the page information table corresponding to the WeChat Moments brush function is recorded.
  • the operation steps include: Step1: Click Discover to enter the discovery page; Step2: Click Moments to enter the Moments page. Check Moments information; if the embedded point data triggered by the software code corresponding to the code defect data determines that the location of the defect is viewing the Moments page, then the page access step D of the WeChat check function for Moments is 2.
  • the page access step size corresponding to the code defect data includes three types: D0, D1, and D2, corresponding to the three situations of 1-2 steps, 3-4 steps, and more than 5 steps, respectively.
  • the shorter the page access step length corresponding to the code defect data the more frequently the corresponding function page is triggered, which is also important in the software program corresponding to the version ID to be tested.
  • S603 Perform repeated tests on the code defect data to obtain a recurrence probability corresponding to the code defect data.
  • the recurrence probability corresponding to the code defect data refers to the probability that the software code corresponding to the code defect data repeatedly fails the test during the software testing process.
  • the recurrence probability corresponding to the code defect data can be set to be inevitable event, high probability event and low probability event respectively. For 100% probability, there will be a defect, and 50%-100% will have a defect. Defects will occur with probability below 50%, which are represented by G0, G1 and G2 respectively.
  • the server may perform repeated tests on the software code corresponding to the code defect data to determine the probability of recurring the code defect data, thereby determining the recurrence probability corresponding to the code defect data.
  • step S603 specifically includes the following steps: (1) Repeat testing the software code corresponding to the code defect data, and obtain the test result corresponding to each repeated test and the number of repeated testing.
  • the test result includes two results: test success and test failure.
  • the number of repeated tests is the number of repeated tests determined by the server during the code defect analysis process.
  • the statistical test result is the number of test defects that failed the test.
  • (3) Use the probability calculation formula to calculate the number of repeated tests and the number of test defects to obtain the defect probability.
  • the probability threshold is a threshold preset by the server for evaluating different recurrence probabilities.
  • the probability threshold includes 100% and 50%, and can also be set to other values. Specifically, if the defect probability of the code defect data is 100%, the recurrence probability corresponding to the code defect data is an inevitable event, which can be represented by G0; if the defect probability of the code defect data is between 50% and 100%, Then the recurrence probability corresponding to the code defect data is a high probability event, which can be represented by G1; if the defect probability of the code defect data is below 50%, the recurrence probability corresponding to the code defect data is a low probability event, which can be used G2 to represent.
  • S604 Use a code scanning tool to scan and analyze the code defect data to obtain maintainability corresponding to the code defect data.
  • the maintainability corresponding to the code defect data refers to an evaluation index obtained by analyzing the maintainability index corresponding to the code defect data and the index threshold preset by the server.
  • the maintainability index refers to the maintainability index, which ranges from 0 to 100 and is used to indicate the maintainability of all classes, members, namespaces, or projects.
  • the less maintainability corresponding to the code defect data the more repetitive the corresponding software code, the more priority it needs to be repaired, so as to avoid the software code corresponding to the code defect data from affecting the entire ID of the version to be tested. The development progress of the software program.
  • Step S304 specifically includes the following content: (1) Scanning and analyzing the code defect data using a code scanning tool, and obtaining evaluation parameters corresponding to the code defect data.
  • the evaluation parameters include Halstead quantity, cyclomatic complexity and the number of code lines. .
  • Halstead quantity (Halstead) is a measure of the computational complexity of the code.
  • Cyclomatic Complexity is the logical complexity of the code. Each possible execution branch (if, while, for, etc.) of the program contributes 1 point to this indicator. Generally speaking, the recommended range of cyclomatic complexity is ⁇ 10, and the maximum is not more than 20.
  • the number of code lines refers to the number of code lines of the software program corresponding to the version ID to be tested.
  • the evaluation parameters corresponding to the code defect data For example, using Code Metrics, a code scanning tool, to scan and analyze code defect data, you can quickly obtain the evaluation parameters corresponding to the code defect data. For example, select "Calculate Code Metrics" on the operation interface of Code Metrics. A corresponding evaluation parameter is obtained in the result window, and these evaluation parameters include Halstead quantity, cyclomatic complexity and the number of code lines. (2) Use the maintainable index formula to calculate the Halstead volume, cyclomatic complexity and the number of code lines, and obtain the maintainable index corresponding to the code defect data. (3) Obtain the maintainability corresponding to the code defect data based on the maintainability index corresponding to the code defect data and the preset index threshold. Among them, the index threshold is a threshold preset by the server for evaluating different maintainability.
  • the server determines that it falls within a value range defined by at least two index thresholds based on the maintainability index corresponding to the code defect data, and determines the corresponding maintainability according to the weight range.
  • the value range of the maintainable index calculated in step S402 is 0-100. If the index threshold is 10 and 20, the two index thresholds can divide the maintainable index into [0, 10], ( 10, 20] and (20, 100] are three value ranges, and each value range corresponds to a maintainability, which is represented by F0, F1 and F2 respectively.
  • the code scanning tool to scan the code defect data to quickly obtain the evaluation parameters, and then use the maintainability index formula to calculate the evaluation parameters, the corresponding maintainability index can be quickly obtained, so that the maintenance index can be obtained
  • the process is simple and fast; then, based on the maintainability index and the preset index threshold, the maintainability corresponding to the code defect data can be quickly determined, so that the quality of the code defect data can be evaluated based on the maintainability.
  • S605 Query the code version information table based on the ID of the version to be tested, and obtain the stability coefficient corresponding to the code defect data.
  • the code version information table is a data table stored in the server and used to record all version information corresponding to the software program corresponding to the version ID to be tested.
  • the stability factor is an index used to evaluate whether the software program corresponding to the version ID to be tested is stable.
  • a brand-new software program or a brand-new functional module in a software program is easier to find its code defects. Conversely, the higher the software version of the software program, the more stable its code performance, and the harder it is to find its code defects.
  • the server can query the code version information table through the version ID to be tested to obtain the number of released versions corresponding to the version ID to be tested, and determine the stability coefficient corresponding to the code defect data according to the number of released versions, so as to compare the code based on the stability coefficient.
  • step S604 specifically includes the following steps: (1) Query the code version information table based on the version ID to be tested, obtain the historical version corresponding to the version ID to be tested, and determine the number of released versions according to the historical version. (2) Query the stability coefficient conversion table based on the number of released versions, and obtain the stability coefficient corresponding to the code defect data.
  • the server queries the code version information table based on the version ID to be tested, and can obtain the relevant information of the version to be analyzed corresponding to the version ID to be tested from the code version information table, and can also obtain the correlation of at least one historical version of the same source as the version to be analyzed information. Then, the number of released versions is determined according to the number of at least one historical version corresponding to the version ID to be tested.
  • the number of released versions can be specifically limited to the number of released versions corresponding to the historical version where the code defect data is located.
  • the stability coefficient conversion table is a data table used to store the conversion relationship between the number of released versions and the stability coefficient.
  • the server may query the stability coefficient conversion table based on the number of released versions, obtain the stability coefficient corresponding to the number of released versions, and determine the stability coefficient as the stability coefficient corresponding to the code defect data. Understandably, in the software program corresponding to the version ID to be tested, there are more code defects in the new functional module, and it is easier to find the code defects. Therefore, the lower the stability coefficient; accordingly, if the version of a certain functional module The higher, the more stable, the higher the stability coefficient.
  • the stability coefficients corresponding to the code defect data include three types of W0, W1, and W2, and the corresponding number of versions is more than 10, between 4-10, and less than 4, respectively.
  • S606 Perform a weighted analysis on the functional core degree, page usage frequency, page access step length, recurrence probability, maintainability index, and stability coefficient corresponding to the same code defect data, and obtain defect measurement values corresponding to the code defect data.
  • the code version information table is a data table stored in the server and used to record all version information corresponding to the software program corresponding to the version ID to be tested.
  • the stability factor is an index used to evaluate whether the software program corresponding to the version ID to be tested is stable.
  • a brand-new software program or a brand-new functional module in a software program is easier to find its code defects. Conversely, the higher the software version of the software program, the more stable its code performance, and the harder it is to find its code defects.
  • the server can query the code version information table through the version ID to be tested to obtain the number of released versions corresponding to the version ID to be tested, and determine the stability coefficient corresponding to the code defect data according to the number of released versions, so as to compare the code based on the stability coefficient.
  • step S606 the function core degree, page usage frequency, page access step size, recurrence probability, maintainability index, and stability coefficient corresponding to the same code defect data are weighted and analyzed to obtain data corresponding to the code defect data.
  • the corresponding defect measurement value includes the following steps:
  • the weight score data table is a data table preset in the server for recording the evaluation score and the evaluation weight corresponding to each evaluation factor.
  • the evaluation score is a score corresponding to each evaluation factor set in advance, and the evaluation weight is a weight corresponding to each evaluation factor set in advance.
  • the server queries the pre-set weight score data table based on the six evaluation factors of function core degree, page usage frequency, page access step size, recurrence probability, maintainability index, and stability coefficient corresponding to the same code defect data. , Obtain the evaluation score and evaluation weight corresponding to each evaluation factor, so as to subsequently comprehensively calculate its corresponding defect measurement value based on the evaluation score and evaluation weight.
  • defect measurement value formula Use the defect measurement value formula to weight the evaluation score and the evaluation weight to obtain the defect measurement value corresponding to the code defect data;
  • the evaluation weights of different evaluation factors can be determined according to the degree of repetition of the evaluation factors on the software program.
  • the evaluation weight of the core degree of the function can be set to 30%, and the page usage frequency and page access step size are 20%.
  • the recurrence probability, maintainability and stability coefficient is 10%
  • the value range of the defect measurement value calculated according to the defect measurement value formula is [1, 2], which can intuitively and objectively reflect the importance of the code defect data, that is, the larger the value, the code defect The more the data is repeated, the more it needs to be repaired first to ensure the development progress of the software program.
  • the functional core degree, page usage frequency, page access step length, recurrence probability, maintainability index, and stability coefficient corresponding to the code defect data are sequentially obtained, and the evaluation factors
  • the evaluation factor is weighted and calculated, and the corresponding defect measurement value can be quickly obtained.
  • the defect measurement value integrates multiple evaluation factors of the importance of the software code corresponding to the code defect data, and can objectively reflect the importance of the software code to be based on The defect measurement value reasonably arranges defect repair work to improve the efficiency of defect repair.
  • step S205 the analytic hierarchy process is used to analyze the code modification hot zone and the code defect distribution hot zone to obtain the target test case, which specifically includes the following steps:
  • the hierarchical structure model includes a target layer, a criterion layer and a scheme layer configured from top to bottom.
  • the scheme layer contains at least two original test cases, and the criterion layer includes Code change hot zone and code defect distribution hot zone.
  • a hierarchical structure model is constructed based on the code modification hot zone and the code defect distribution hot zone, and the hierarchical structure model includes a target layer A, a criterion layer C, and a solution layer P.
  • the code change hot zone and code defect distribution hot zone are the criterion layer factors C 1 and C 2 in this criterion level C.
  • the code change hot zone is comprehensively obtained based on the number of code changes and the number of lines of code changes.
  • Level C can also use the number of code changes and the number of lines of code changes as the new criterion level factors C 3 and C 4 .
  • the solution layer P uses at least one original test case pre-configured in the software version testing process as solution factors P 1 , P 2 ... P n , corresponding to original test case 1, original test case 2 ... original test case Z, respectively.
  • S702 Construct a judgment matrix based on the priority of the criterion-level factors in the hierarchical structure model.
  • the judgment matrix is a quantitative expression of the relative importance of each criterion-level factor in this level for a certain criterion-level factor of the previous level. This is a process of transforming qualitative judgment into a quantitative expression. Assuming that the factor C k of the criterion layer is related to the factors P 1 , P 2 ... P n of the scheme layer P, the judgment matrix B is constructed as follows:
  • obtaining the level order of the lower level factors relative to the upper level refers to calculating the weight of the order of importance of the factors related to this level relative to a factor of the upper level according to the judgment matrix.
  • the single-level ranking includes the single-level ranking of criteria-level factors relative to the target level, and the single-level ranking of program-level factors relative to the criterion level.
  • Step S703 specifically includes the following steps: (1) Standardize each column in the judgment matrix to obtain a column standardization matrix. Specifically, the server divides each item in the judgment matrix B by the sum of each item in the column where the item is located. , Get the standardized matrix, namely The standardization process can maintain the consistency of the matrix. (2) Sum each row of the column standardized matrix to obtain the row weight, namely (3) Standardize the row weights of the column standardization matrix to obtain the feature vector of the judgment matrix. Specifically, using Perform normalization processing on the row weights in the column normalization matrix to obtain the eigenvalues W i of the judgment matrix. (4) Judgment matrix eigenvalue W i , obtain the largest matrix eigenvalue ⁇ max of the judgment matrix, where,
  • the consistency index formula is used to calculate the maximum matrix characteristic root ⁇ max of the judgment matrix to obtain the target consistency index, and the random consistency ratio is calculated based on the target consistency index and the average random consistency index. If the random consistency ratio is less than Or equal to 0.1, the matrix has satisfactory consistency.
  • the consistency index formula is Among them, ⁇ max is the maximum matrix characteristic root of the judgment matrix, and RI is the average random consistency index, which can be obtained by looking up the table according to the order of the judgment matrix. according to Calculate the random consistency ratio, where CR is the random consistency ratio.
  • the consistency check of the single-level ranking means that the value of CR is less than or equal to 0.1. Understandably, if the consistency check of the level single sorting is passed, the result of the level single sorting of the judgment matrix is W[W, W 2 ,...W n ] T.
  • obtaining the total ranking of the hierarchy based on the single ranking of the hierarchy refers to using the single ranking of the hierarchy to comprehensively calculate the combined weight of the importance order of the plan layer relative to the target layer, and the total ranking of the hierarchy is performed from top to bottom.
  • the matrix formed by P n is C 1 -P matrix, C 2 -P matrix...C m -P matrix. Then according to the criterion scheme matrix, comprehensively calculate the scheme level elements P 1 , P 2 ... P n to rank the total order of the target layer.
  • the scheme weight of each scheme layer factor in the total order is
  • the consistency index formula is When CR ⁇ 0.1, the overall ranking of levels is determined to have satisfactory consistency, and the result can be used as a reference for decision-makers.
  • the plan weight of the original test case in the plan layer can be determined according to the total ranking of the hierarchy, and the target test case can be determined.
  • the analytic hierarchy process is used to construct the judgment matrix for the code change hot zone and code defect distribution hot zone, And through analysis and calculation to obtain the hierarchical single order and the hierarchical total order, when the consistency check is passed, the target test case is determined based on the hierarchical total order, so that the determined target test case can effectively guarantee the test quality and effectively avoid the omission of code changes Hot zone and code defect distribution hot zone code corresponding to test cases for testing; and, testing according to target test cases can avoid the inefficiency problem of using all original test cases for comprehensive testing.
  • a regression test case determination device is provided, and the regression test case determination device corresponds to the regression test case determination method in the foregoing embodiment one-to-one.
  • the regression test case determination device includes a test analysis request acquisition module 801, a version code acquisition module 802 to be tested, a code modification hot zone acquisition module 803, a code defect distribution hot zone acquisition module 804, and a target test case acquisition module 805.
  • the detailed description of each functional module is as follows:
  • the test analysis request obtaining module 801 is configured to obtain a test analysis request, and the test analysis request includes the ID of the version to be tested.
  • the to-be-tested version code obtaining module 802 is configured to obtain the to-be-tested version code corresponding to the to-be-tested version ID from the code warehouse based on the to-be-tested version ID.
  • the code change hot zone acquisition module 803 is used to use the version control tool to perform code analysis on the version code to be tested and obtain the code change hot zone.
  • the code defect distribution hot area acquisition module 804 is used to filter the code defect distribution hot areas to obtain the code defect distribution hot areas.
  • the target test case acquisition module 805 is used to analyze the code change hot zone and the code defect distribution hot zone by using the analytic hierarchy process to obtain the target test case.
  • the code modification hot zone acquisition module 803 includes a historical version data acquisition sub-module and a code modification hot zone acquisition sub-module.
  • the historical version data acquisition sub-module is used to use the version control tool to execute log query commands to obtain historical version test data corresponding to the version code to be tested.
  • the code change hot zone acquisition submodule is used to use the version control tool to analyze the test version code and historical version test data to obtain the code change hot zone.
  • the code modification hot zone acquisition submodule includes a code modification frequency acquisition unit, a code modification line number acquisition unit, a comprehensive evaluation index acquisition unit, and a code modification hot zone acquisition unit.
  • the code change frequency obtaining unit is used to analyze the code to be tested and the historical version test data using the CodeMaat tool, and obtain the code change frequency corresponding to each code module in the code to be tested.
  • the code change line number acquisition unit is used to analyze the test version code and historical version test data using the Cloc tool, and obtain the number of code change lines corresponding to each code module in the test version code.
  • the comprehensive evaluation index acquisition unit is used to standardize and weight the number of code changes and the number of lines of code changes corresponding to each code module, and obtain the comprehensive evaluation index corresponding to each code module.
  • the code change hot zone acquisition unit is used to obtain the code change hot zone based on the comprehensive evaluation index corresponding to each code module.
  • the regression test case determination device further includes:
  • the code defect data acquisition module is used to query the test result database based on the version ID to be tested, and obtain at least one code defect data corresponding to the version ID to be tested.
  • the defect measurement value acquisition module is used to perform defect measurement analysis on the code defect data and obtain the defect measurement value of the code defect data.
  • the defect priority obtaining module is used to obtain the defect priority corresponding to the code defect data according to the defect measurement value of the code defect data, and configure the regular expression corresponding to each code defect data.
  • the code defect distribution hotspot acquisition module 804 is also used to filter the code modification hotspots by using regular expressions corresponding to the code defect data according to the defect priority corresponding to the code defect data to obtain the code defect distributions hotspot.
  • the defect measurement value acquisition module includes a function core degree acquisition submodule, a page frequency step acquisition submodule, a recurrence probability acquisition submodule, a maintainability acquisition submodule, a stability coefficient acquisition submodule, and a defect measurement value acquisition submodule Module
  • the functional core degree acquisition sub-module is used to perform syntax tree analysis on the code defect data based on the abstract syntax tree corresponding to the version ID to be tested, and obtain the functional core degree corresponding to the code defect data.
  • the page frequency step acquisition sub-module is used to query the embedded database corresponding to the version ID to be tested based on the code defect data, and obtain the page usage frequency and page access step corresponding to the code defect data.
  • the recurrence probability acquisition sub-module is used to repeatedly test the code defect data and obtain the recurrence probability corresponding to the code defect data.
  • the maintainability acquisition sub-module is used to scan and analyze the code defect data with the code scanning tool, and obtain the maintainability corresponding to the code defect data.
  • the stability coefficient obtaining sub-module is used to query the code version information table based on the ID of the version to be tested, and obtain the stability coefficient corresponding to the code defect data.
  • Defect measurement value acquisition sub-module used to perform weighted analysis on the functional core degree, page usage frequency, page access step size, recurrence probability, maintainability index and stability coefficient corresponding to the same code defect data, and obtain the corresponding code defect data Defect metrics for
  • the defect metric value obtaining sub-module includes an evaluation score weight obtaining unit and a defect metric value obtaining unit.
  • the evaluation score weight acquisition unit is used to query the pre-set weight score data table based on the function core degree corresponding to the same code defect data, page use frequency, page access step length, recurrence probability, maintainability index and stability coefficient, and obtain The corresponding evaluation score and evaluation weight.
  • the defect measurement value obtaining unit is used for weighted calculation of the evaluation score and the evaluation weight by using the defect measurement value formula to obtain the defect measurement value corresponding to the code defect data.
  • the target test case acquisition module 805 includes a hierarchical structure model building unit, a judgment matrix building unit, a hierarchical ordering acquisition unit, and a target test case acquisition unit.
  • the hierarchical model building unit is used to build a hierarchical structure model based on the code change hot zone and the code defect distribution hot zone.
  • the hierarchical model includes the target layer, the criterion layer and the scheme layer configured from top to bottom.
  • the scheme layer contains at least two originals
  • the criterion layer includes code change hot spots and code defect distribution hot spots.
  • the judgment matrix construction unit is used to construct the judgment matrix based on the priority of the criterion-level factors in the hierarchical structure model.
  • the level list order acquisition unit is used to acquire the level list order of lower factors relative to the upper level based on the judgment matrix.
  • the hierarchical total sorting obtaining unit is used to obtain the hierarchical total sorting based on the hierarchical single sorting if the consistency check is passed through the single-level sorting.
  • the target test case acquisition unit is used to determine the plan weight of the original test case in the plan layer according to the total ranking of the hierarchy if the consistency check is passed to determine the target test case.
  • Each module in the above regression test case determination device can be implemented in whole or in part by software, hardware and a combination thereof.
  • the foregoing modules may be embedded in the form of hardware or independent of the processor in the computer device, or may be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the foregoing modules.
  • a computer device is provided.
  • the computer device may be a server, and its internal structure diagram may be as shown in FIG. 9.
  • the computer equipment includes a processor, a memory, a network interface and a database connected through a system bus. Among them, the processor of the computer device is used to provide calculation and control capabilities.
  • the memory of the computer device includes a non-volatile storage medium and an internal memory.
  • the non-volatile storage medium stores an operating system, computer readable instructions, and a database.
  • the internal memory provides an environment for the operation of the operating system and computer-readable instructions in the non-volatile storage medium.
  • the database of the computer equipment is used to store the data used or acquired in the process of executing the regression test case determination method.
  • the network interface of the computer device is used to communicate with an external terminal through a network connection.
  • the computer-readable instruction is executed by the processor to realize a regression test case determination method.
  • a computer device including a memory, a processor, and computer-readable instructions stored in the memory and capable of running on the processor.
  • the processor executes the computer-readable instructions, the regression in the foregoing embodiment is implemented.
  • the steps of the test case determination method such as steps S201-S205 shown in FIG. 2, or the steps shown in FIG. 3 to FIG. 7, are not repeated here to avoid repetition.
  • the functions of the modules/units in the embodiment of the regression test case determination device are realized, for example, the test analysis request acquisition module 801, the version code acquisition module 802,
  • the functions of the code modification hot zone acquisition module 803, the code defect distribution hot zone acquisition module 804, and the target test case acquisition module 805 are not repeated here to avoid repetition.
  • one or more readable storage media storing computer readable instructions are provided.
  • the computer readable storage medium stores computer readable instructions, and the computer readable instructions are executed by one or more processors.
  • the one or more processors are executed to implement the steps of the regression test case determination method in the foregoing embodiment, such as steps S201-S205 shown in FIG. 2, or the steps shown in FIGS. 3 to 7, To avoid repetition, I won’t repeat them here.
  • the computer-readable instruction is executed by the processor, the function of each module/unit in the embodiment of the above-mentioned regression test case determination device is realized, for example, the test analysis request acquisition module 801 shown in FIG.
  • the functions of the module 802, the code modification hot zone acquisition module 803, the code defect distribution hot zone acquisition module 804, and the target test case acquisition module 805 are not repeated here to avoid repetition.
  • the readable storage medium in this embodiment includes a nonvolatile readable storage medium and a volatile readable storage medium.
  • Non-volatile memory may include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory.
  • Volatile memory may include random access memory (RAM) or external cache memory.
  • RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous chain Channel (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

一种回归测试用例确定方法、装置、计算机设备及存储介质。该方法包括：获取测试分析请求，所述测试分析请求包括待测试版本ID（S201）；基于所述待测试版本ID，从代码仓库中获取与所述待测试版本ID相对应的待测试版本代码（S202）；采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区（S203）；对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区（S204）；采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例（S205）。该方法可使后续基于目标测试用例进行回归测试时，可有效减少工作量的重复冗余，也减少不必要的人力浪费，并且保障回归测试的软件质量。

Description

回归测试用例确定方法、装置、计算机设备及存储介质
本申请以2019年3月19日提交的申请号为201910207525.5，名称为“回归测试用例确定方法、装置、计算机设备及存储介质”的中国发明申请为基础，并要求其优先权。
技术领域
本申请涉及软件测试技术领域，尤其涉及一种回归测试用例确定方法、装置、计算机设备及存储介质。
背景技术
软件测试是指在特定条件下对软件程序进行操作，以发现软件程序错误，衡量软件质量是否能满足设计要求的评估过程。当前软件测试过程中，会对不同测试阶段采用一套标准的测试策略和测试计划，以保证软件测试的顺利进行。为了保障软件程序的质量，需在软件开发过程中进行多次回归测试，该回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的过程。当前软件程序的回归测试过程中，主要进行全功能的回归测试或者主观模糊判断回归测试范围，导致工作量重复冗余且造成不必要的人力浪费，或者导致遗漏重要的测试用例使得软件程序中特定的代码模块的质量无法得到保障。
发明内容
本申请实施例提供一种回归测试用例确定方法、装置、计算机设备及存储介质，以解决回归测试工作量冗余或者质量无法保障的问题。
一种回归测试用例确定方法，包括：
获取测试分析请求，所述测试分析请求包括待测试版本ID；
基于所述待测试版本ID，从代码仓库中获取与所述待测试版本ID相对应的待测试版本代码；
采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区；
对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区；
采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例。
一种回归测试用例确定装置，包括：
测试分析请求获取模块，用于获取测试分析请求，所述测试分析请求包括待测试版本ID；
待测试版本代码获取模块，用于基于所述待测试版本ID，从代码仓库中获取与所述待测试版本ID相对应的待测试版本代码；
代码改动热区获取模块，用于采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区；
代码缺陷分布热区获取模块，用于对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区；
目标测试用例获取模块，用于采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例。
一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时实现如下步骤：
获取测试分析请求，所述测试分析请求包括待测试版本ID；
基于所述待测试版本ID，从代码仓库中获取与所述待测试版本ID相对应的待测试版本代码；
采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区；
对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区；
采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例。
一个或多个存储有计算机可读指令的可读存储介质，所述计算机可读存储介质存储有计算机可读指 令，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行如下步骤：
获取测试分析请求，所述测试分析请求包括待测试版本ID；
基于所述待测试版本ID，从代码仓库中获取与所述待测试版本ID相对应的待测试版本代码；
采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区；
对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区；
采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例。
本申请的一个或多个实施例的细节在下面的附图及描述中提出。本申请的其他特征和优点将从说明书、附图以及权利要求书变得明显。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本申请一实施例中回归测试用例确定方法的一应用环境示意图；
图2是本申请一实施例中回归测试用例确定方法的一流程图；
图3是本申请一实施例中回归测试用例确定方法的另一流程图；
图4是本申请一实施例中回归测试用例确定方法的另一流程图；
图5是本申请一实施例中回归测试用例确定方法的另一流程图；
图6是本申请一实施例中回归测试用例确定方法的另一流程图；
图7是本申请一实施例中回归测试用例确定方法的另一流程图；
图8是本申请一实施例中回归测试用例确定装置的一示意图；
图9是本申请一实施例中计算机设备的一示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请实施例提供的回归测试用例确定方法，该回归测试用例确定方法可应用如图1所示的应用环境中。具体地，该回归测试用例确定方法应用在软件测试系统中，该软件测试系统包括如图1所示的客户端和服务器，客户端与服务器通过网络进行通信，用于进行回归测试分析，以确定目标测试用例，以便基于该目标测试用例进行回归测试过程中，既可保障回归测试质量又可保障回归测试效率。其中，客户端又称为用户端，是指与服务器相对应,为客户提供本地服务的程序。客户端可安装在但不限于各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备上。服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
在一实施例中，如图2所示，提供一种回归测试用例确定方法，以该方法应用在图1中的服务器为例进行说明，包括如下步骤：
S201：获取测试分析请求，测试分析请求包括待测试版本ID。
其中，测试分析请求是用于触发服务器进行回归测试分析，以确定本次回归测试所需采用的测试用例的请求。待测试版本ID是用于唯一识别所要进行测试缺陷分析的特定版本的软件程序的标识。每一待测试版本ID对应一个需要进行测试缺陷分析的特定版本的软件程序，例如微信V6.6.7。
S202：基于待测试版本ID，从代码仓库中获取与待测试版本ID相对应的待测试版本代码。
其中，代码仓库是用于存储特定软件程序所有版本的代码的数据库。待测试版本代码是指最后一次代码修改之后，需要进行回归测试的版本代码。每一待测试版本代码ID对应一待测试版本代码。可以理解地，代码仓库中存储有与待测试版本ID相对应的待测试版本代码，以便基于该待测试版本代码进行后续分析。具体地，服务器与测试结果数据库相连，该测试结果数据库中存储有与待测试版本代码同 源的至少一个历史版本测试数据，该历史版本测试数据是指在最后一次代码修改之前所形成的版本代码在测试过程中形成的数据。
S203：采用版本控制工具对待测试版本代码进行代码分析，获取代码改动热区。
其中，版本控制工具是用于提供完备的版本管理功能，用于存储、追踪目录(文件夹)和文件的修改历史的工具，是软件开发者的必备工具，是软件公司的基础设施。版本控制软件的最高目标，是支持软件公司的配置管理活动，追踪多个版本的开发和维护活动，及时发布软件。本实施例中，服务器所采用的版本控制工具具体为分布式版本控制系统(Distributed Version Control System，简称DVCS)，在DVCS中客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复，其原因在于每一次的提取操作，实际上都是一次对代码仓库的完整备份。当前应用DVCS的版本控制工具包括但不限于Git，Mercurial，Bazaar以及Darcs等工具。进一步地，服务器采用Git这一版本控制工具对待测试版本代码以及其对应的历史版本测试数据进行代码分析，以确定代码改动热区。该版本控制工具Git具有如下技术优点：1)适合分布式开发，强调个体；2)公共服务器压力和数据量都不会太大；3)速度快、灵活；4)任意两个开发者之间可以很容易的解决冲突；5)离线工作。
代码改动热区是指采用版本控制工具对待测试版本代码和对应的历史版本测试数据进行对比分析，获取到的被频繁改动的代码区域。可以理解地，该代码改动热区是指被频繁改动的代码区域，此处的频繁改动通过代码改动行数和代码改动次数这两个指标来确定，而代码改动的原因有可能是因为代码复杂度过高或者代码耦合性太强而造成新增功能需要改动这些代码，也有可能仅仅是因为代码实现过程中有问题需要频繁改动来修复代码缺陷。具体地，服务器采用版本控制工具Git对待测试版本代码以及与该待测试版本代码同源的所有历史版本测试数据进行代码分析，以获取相应的代码改动行数和代码改动次数，并根据该代码改动行数和代码改动次数进行分析，获取相应的代码改动热区。
S204：对代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区。
由于代码改动热区是基于代码改动次数和代码改动行数这两个维度进行综合评估后确定的被频繁改动的代码区域，而频繁改动的原因可能是基于代码缺陷也可能不是基于代码缺陷，在代码改动的原因是基于代码缺陷时，则该代码改动热区可能对应于高风险代码模块，即存在较多代码缺陷的功能模块。因此，在回归测试阶段，除了关注代码改动次数和代码改动行数，以确定改动代码热区之外，还需对代码改动热区中是否存在高风险代码模块进行识别判断，以过滤出高风险代码模块，从而确定代码缺陷分布热区。即通过在代码改动热区中，加入代码缺陷过滤来确定由于代码缺陷改动所形成的代码缺陷分布热区。
具体地，服务器中预先设置有用于匹配代码缺陷的正则表达式，在确定代码改动热区之后，采用该正则表达式对代码改动热区的代码文件进行匹配，获取匹配成功的代码文件对应的代码区域为代码缺陷分布热区。例如，服务器对代码改动热区进行代码缺陷过滤过程所采用的过滤方式：通过代码文件的名称(基于代码缺陷修复后形成的代码文件一般都会标记修复XXX.bug)对应的正则表达式来判断过滤，以达到确定代码缺陷分布热区的目的。
S205：采用层次分析法对代码改动热区和代码缺陷分布热区进行分析，获取目标测试用例。
层次分析法(Analytic Hierarchy Process，简称AHP)，是指将与决策总是有关的元素分解成目标、准则、方案等层次，在此基础之上进行定性和定量分析的决策方法。在层次分析法中，从上到下配置有目标层、准则层和方案层。其中，目标层是决策的目的、要解决的问题，于本实施例中，目标层输出最终需要进行回归测试的目标测试用例。方案层是指决策时的备选方案，于本实施例中，方案层输入软件版本测试过程中预先配置的至少一个原始测试用例，例如，原始测试用例1、原始测试用例2……原始测试用例Z，其中，Z指代最后一个原始测试用例。准则层是中间层，是指决策过程中考虑的因素、决策的准则，即为实现决策的目的所采用的措施和方案，于本实施例中，将步骤S203所获取的代码改动热区和步骤S204所获取的代码缺陷分析热区作为准则层因素。
本实施例中，将软件版本测试过程中预先配置的至少一个原始测试用例作为AHP中方案层的输入，基于代码改动热区和代码缺陷分析热区形成准则层，通过执行AHP的具体算法，以获取目标层输出的目 标测试用例。该目标测试用例是采用AHP算法对代码改动热区和代码缺陷分析热区进行分析，所确定的在下一次回归测试过程中可采用的测试用例。可以理解地，该目标测试用例综合考虑该待测试版本代码预先配置的至少一个原始测试用例中，其对应的代码改动热区和代码缺陷分布热区等信息进行综合分析，以挑选出可作为下一次回归测试的测试用例(即目标测试用例)。可以理解地，目标测试用例的确定，以使后续基于目标测试用例进行回归测试时，可有效减少工作量的重复冗余，也减少不必要的人力浪费，并且保障回归测试的软件质量。
本实施例所提供的回归测试用例确定方法中，通过采用版本控制工具对待测试版本代码进行分析，可快速获取对应的代码改动热区，该代码改动热区反映软件代码被改动的频率；在对代码改动热区进行代码缺陷过滤，以获取代码缺陷分布热区，以确定高风险代码模块对应的代码区域；再采用层次分析法对代码改动热区和代码缺陷分布热区进行分析，获取目标测试用例，以使后续基于目标测试用例进行回归测试时，可有效减少工作量的重复冗余，也减少不必要的人力浪费，并且保障回归测试的软件质量。
在一实施例中，如图3所示，采用版本控制工具对待测试版本代码进行代码分析，获取代码改动热区，具体包括如下步骤：
S301：采用版本控制工具执行日志查询命令，获取与待测试版本代码相对应的历史版本测试数据。
其中，日志查询命令是用于查询软件程序测试过程中所形成的日志的命令，该日志查询命令具体用于查询特定存储目录中测试时间在预设时间段内的测试日志，基于该测试日志获取历史版本测试数据。具体地，用户可通过客户端向版本控制工具Git输入相应的日志查询命令，以获取与待测试版本代码相对应的历史版本测试数据，获取过程简单快捷。例如，版本控制工具可执行“git log–prettyformat:’[％h]％an％ad％s’–date＝short–numstat–before＝yy-mm-dd–after＝yy-mm-dd&gt；react_evo.log”这一日志查询命令，获取相应的测试日志，基于该测试日志中记录的改动信息和改动文件获取历史版本测试数据。其中，改动信息具体反映代码改动情况的信息，如最近一次修改代码时，删除代码行数和新增代码行数等信息。改动文件是指基于改动信息对应的改动代码所形成的文件。
进一步地，为了保证时间的一致性，还可在日志查询命令中将时间切换到系统当前时间，例如，系统当前时间为2018年8月27日，则可在日志查询命令中加入“git checkout`git rev-list-n1--before＝"2018-08-27"master”，以获取在2018年8月27日之前，待测试版本代码对应的改动信息和改动文件，从而获取历史版本测试数据。
S302：采用版本控制工具对待测试版本代码和历史版本测试数据进行分析，获取代码改动热区。
由于本实施例中采用的版本控制工具为Git，Git中设置有可实现检测代码改动次数和代码改动行数的功能模块，通过执行相应的功能模块对待测试版本代码和历史版本测试数据进行分析，以获取待测试版本代码中每一代码模块对应的代码改动次数和代码改动行数，再对代码改动次数和代码改动行数进行综合分析，以确定相代码改动热区。其中，代码模块是待测试版本代码中可实现某一功能的代码的组合。
本实施例所提供的回归测试用例确定方法中，先执行日志查询命令，以获取历史版本测试数据，再采用版本控制工具中的功能模块对待测试版本代码和历史版本测试数据进行分析，可快速获取代码改动热区，通过该代码改动热区了解待测试版本代码中每一代码模块的改动情况，以便后续综合分析确定下一次回归测试所需采集的目标测试用例，可对代码改动热区对应的代码模块进行测试，以避免回归测试过程中遗漏对代码改动热区对应的代码模块进行测试。
在一实施例中，如图4所示，采用版本控制工具对待测试版本代码和历史版本测试数据进行分析，获取代码改动热区，具体包括如下步骤：
S401：采用Code Maat工具对待测试版本代码和历史版本测试数据进行分析，获取待测试版本代码中每一代码模块对应的代码改动次数。
具体地，Code Maat工具是采用Clojure编写，用于挖掘和分析待测试版本代码中的代码改动次数的功能模块，该Code Maat工具设置在版本控制工具Git中。具体地，服务器在用户自己重定向的Git的日志文件react_evo.log中，采用Code Maat去获取每一代码模块对应的代码改动次数。该代码改动次数反映某一代码模块在最后一次测试之前被改动过的次数。
本实施例中，步骤S401具体包括如下步骤：(1)可先通过在版本控制工具中执行“java-jar code-maat/target/code-maat-1.1-SNAPSHOT-standalone.jar-l react_evo.log-c git-a summary”这一命令行，获取待测试版本代码与其之前的版本代码对应的汇总数据，该汇总数据可反馈待测试版本代码与其之前的版本代码的提交次数、涉及代码文件的具体情况和开发人员的信息等。(2)再执行“java-jar../../code-maat/target/code-maat-1.1-SNAPSHOT-standalone.jar-l react_evo.log-c git-a revisions&gt；react_freqs.csv”这一命令行，获取待测试版本代码中每一代码模块对应的代码改动行数。
S402：采用Cloc工具对待测试版本代码和历史版本测试数据进行分析，获取待测试版本代码中每一代码模块对应的代码改动行数。
具体地，Cloc工具是在版控制工具Git中配置的代码统计工具Cloc，Cloc是一款使用Perl语言开发的开源代码统计工具，支持多平台使用、多语言识别，能够计算指定目标文件或文件夹中的文件数(files)、空白行数(blank)、注释行数(comment)和代码行数(code)。其中，代码改动行数是判断代码改动热区的另一维度指标，具体是指该待测试版本代码相对于上一版本版本代码的改动行数，该代码改动行数包括删除代码行数和新增代码行数。代码改动行数这个维度简单粗暴，并且有两个好处，其一是能够查找方便快速；其二是对于不同编程语言，它是中立的指标。本实施例中，采用Cloc工具作为对代码改动行数进行分析的工具，它使用Perl编写，并且能够得到针对编程语言、文件、空格、注释和代码本身的很直观的输出。
S403：对每一代码模块对应的代码改动次数和代码改动行数进行标准化和加权处理，获取每一代码模块对应的综合评估指标。
具体地，对每一代码模块的代码改动次数和代码改动行数进行标准化处理，是指将每一代码模块的代码改动次数和代码改动行数进行无纲量化处理，使其具有可比性，可进行后续的加权处理。
本实施例中，服务器预先存储有标准化数据转换表，该标准化数据转换表中存储有代码改动次数对应的次数标准化分值，并存储有代码改动行数对应的行数标准化分值。服务器在获取到每一代码模块的代码改动次数和代码改动行数之后，查询该标准化数据转换表，获取相对应的次数标准化分值和行数标准化分值。并且，服务器预先存储有代码改动次数和代码改动行数对应的权重。服务器对每一代码模块的代码改动次数和代码改动行数进行加权处理，是指将每一代码模块的次数标准化分值和行数标准化分值与其相应的权重进行加权计算，获取到相应的综合评估指标。该加权计算公式为X＝∑x ih i，其中，X为综合评估指标，x i分别是指次数标准化分值或行数标准化分值，h i分别是指代码改动次数对应的权重或代码改动行数对应的权重。依据测试经验可知，代码改动次数比代码改动行数对代码改动热区的认定更为重要，因此，可设置代码改动次数要比代码改动行数拥有更多的权重，以获取每一代码模块的综合评估指标。
本实施例中，若代码改动次数越多，其次数标准化分值越大；若代码改动行数越多，其行数标准化分值越大，则若计算出的综合评估指标越大，反映了该代码模块对应的代码改动次数较多和/或代码改动行数较多，因此，可根据该综合评估指标确定其代码改动热区。
S404：基于每一代码模块对应的综合评估指标，获取代码改动热区。
具体地，基于每一代码模块对应的综合评估指标获取代码改动热区具体包括如下步骤：将每一代码模块的综合评估指标与预设指标阈值进行比较，若该综合评估指标大于预设指标阈值，则认定该综合评估指标对应的代码模块所形成的区域为代码改动热区；反之，若综合评估指标不大于预设指标阈值，则认定该综合评估指标对应的代码模块所形成的区域不为代码改动热区。其中，预设指标阈值是指预先设置的用于评估代码改动热区对应的指标的阈值。
由于代码改动次数和代码改动行数这两个单一维度不足以说明某个代码模块为代码改动热区，通过综合评估指标将每一代码模块的代码改动次数和代码改动行数进行整合，形成新的综合维度，以使基于综合评估指标确定的代码改动热区更客观和合理。
进一步地，服务器还可以采用Circle Packing或者其他图形转换工具将代码修改热区展示出来，以使用户可直观地查询代码改动热区的信息。例如，在采用Circle Packing所展示的图像中，每个圆的直径越大，代表这个圆对应的代码改动行数越多；而每一圆的颜色越深，代表这个圆的代码改动次数越多，改动越频繁；可基于每一代码模块对应的代码改动次数和代码改动行数确定其综合评估指标，将大于预设指标阈值的综合评估指标对应的代码模块进行突出显示，以使用户了解该代码模块所在区域为代码改动热区。
本实施例所提供的回归测试用例确定方法中，采用Code Maat工具和Cloc工具分别对待测试版本代码和历史版本测试数据进行分析，分别获取代码改动次数和代码改动行数，获取过程简单方便；再对每一代码模块的代码改动次数和代码改动行数进行标准化和加权处理，可获取可综合反映代码改动情况的综合评估指标；最后，基于综合评估指标和预设指标阈值的比较结果，可快速获取相应的代码改动热区，以使所获取的代码改动热区更具有客观性。
在一实施例中，如图5中，在对代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区的步骤之前，回归测试用例确定方法还包括如下步骤：
S501：基于待测试版本ID查询测试结果数据库，获取与待测试版本ID相对应的至少一个代码缺陷数据。
其中，测试结果数据库是用于存储在该待测试版本ID对应的特定版本的软件程序的测试结果的数据库。该测试结果包括测试成功和测试失败两种结果，其中，基于测试结果为测试失败的软件代码所形成的数据为代码缺陷数据。即代码缺陷数据是在特定版本的软件程序在测试过程中代码存在缺陷的数据。本实施例中，代码缺陷数据是指在该待测试版本ID对应的软件程序在测试过程中出现的所有存在缺陷的代码对应的数据。
S502：对代码缺陷数据进行缺陷度量分析，获取代码缺陷数据的缺陷度量值。
其中，缺陷度量值是依据预先设置的度量值评估规则对代码缺陷数据进行综合评估之后确定度量值。该缺陷度量值可客观反映每一代码缺陷数据的缺陷严重程度，一般来说，缺陷度量值越大，其缺陷越严重；反之，缺陷度量值越小，其缺陷越不严重。具体地，对代码缺陷数据进行缺陷度量分析是指依据预先设置的多个评估维度对代码缺陷数据进行综合评估，以使获取到的代码缺陷数据对应的缺陷度量值可综合反映该代码缺陷数据的缺陷严重程度。本实施例中，预先设置的度量值评估规则是依据影响代码缺陷严重程度的多个评估维度进行综合评估的规则。该评估维度具体包括但不限于功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数和稳定系数。
S503：依据代码缺陷数据的缺陷度量值，获取代码缺陷数据对应的缺陷优先级，并配置每一代码缺陷数据对应的正则表达式。
由于缺陷度量值是依据多个评估维度对代码缺陷数据进行综合评估后确定的度量值，每一缺陷度量值可反映该代码缺陷数据的严重程度，这个严重程度可体现为缺陷优先级。一般来说，缺陷度量值越大，其对应的缺陷优先级越优先。
本实施例中，依据代码缺陷数据的缺陷度量值，获取代码缺陷数据对应的缺陷优先级具体包括如下步骤：服务器可基于代码缺陷数据的缺陷度量值查询风险等级转换表，以确定其对应的缺陷风险等级，基于该缺陷风险等级确定相应的缺陷优先级。风险等级转换表中可将缺陷度量值的取值范围划分成若干个风险等级范围，每一风险等级范围对应的一缺陷风险等级，则服务器可根据该代码缺陷数据对应的缺陷度量值确定其所属的风险等级范围，将其所属的风险等级范围对应的缺陷风险等级确定为该缺陷度量值对应的缺陷风险等级。该缺陷风险等级可以包括紧急风险等级、高级风险等级、一般风险等级和低级风险等级等类型，也可以设置成其他类型。一般来说，缺陷度量值的取值越高，其缺陷风险等级越高，相应地，缺陷优先级越高。具体地，配置每一代码缺陷数据对应的正则表达式是指配置可匹配出相应的代码缺陷的正则表达式。
相应地，步骤S204中，对代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区，具体包括如下步骤：依据代码缺陷数据对应的缺陷优先级，采用代码缺陷数据对应的正则表达式对代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区。具体地，服务器会依据每一代码缺陷数据对应的缺陷优先级， 依次采用紧急风险等级、高级风险等级、一般风险等级和低级风险等级对应的代码缺陷数据对应的正则表达式，对代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区，以便快速获取到高风险代码模块对应的代码缺陷分布热区，提高代码缺陷分布热区的获取效率。一般来说，缺陷优先级在先的代码缺陷数据对应的代码模块不为代码缺陷分布热区，则缺陷优先级在后的代码缺陷数据对应的代码模块同样不为代码缺陷分布热区，无需进行后续处理，以节省处理时间，提高处理效率。
本实施例所提供的回归测试用例确定方法中，通过获取待测试版本代码的每一代码缺陷数据的缺陷度量值，以确定其缺陷优先级，由于缺陷度量值的确定参考多个评估维度确定，使得最终确定的缺陷优先级具有较高的客观性。然后，依据缺陷优先级的顺序，采用代码缺陷数据对应的正则表达式对代码改动热区进行代码缺陷过滤，以便快速获取代码缺陷分布热区，提高代码缺陷分布热区的获取效率。
在一实施例中，如图6所示，步骤S502中，对代码缺陷数据进行缺陷度量分析，获取代码缺陷数据的缺陷度量值，具体包括如下步骤：
S601：基于与待测试版本ID相对应的抽象语法树对代码缺陷数据进行语法树分析，获取与代码缺陷数据相对应的功能核心程度。
其中，抽象语法树(abstract syntax code，AST)是源代码的抽象语法结构的树状表示，树上的每个节点都表示源代码中的一种结构，之所以说是抽象的，是因为抽象语法树并不会表示出真实语法出现的每一个细节(如嵌套括号被隐含在树的结构中，并没有以节点的形式呈现)。具体地，服务器可预先采用javascript Parser这一源码解析器，对采用JAVA语言编辑的与待测试版本ID相对应的软件程序进行转化处理，以转化成与待测试版本ID相对应的抽象语法树，再进一步转化为字节码或直接生成机器码，以便后续进行程序分析。
本实施例中，服务器采用emma代码分析工具分析代码缺陷数据在与待测试版本ID相对应的抽象语法树上的运行流向，确定代码缺陷数据在抽象语法树中的位置，并根据其所在的位置确定其对应的功能核心程度，可采用R来表示。例如，若该代码缺陷数据处于抽象语法树中的主干位置，则其功能核心程度最高，确定为R0级别；若该代码缺陷数据处于抽象语法树中的次主干位置，则其功能核心程度次之，确定为R1级别；若该代码缺陷数据处于抽象语法树中的次干位置，则其功能核心程度更低，确定为R2级别……依此类推，确定代码缺陷数据在抽象语法树中的位置，从而确定其对应的功能核心程度。
可以理解地，通过预先创建的与待测试版本ID相对应的抽象语法树对代码缺陷数据进行语法树分析，可快速获取该代码缺陷数据对应的功能核心程度，可反映该代码缺陷数据在整个待测试版本ID对应的软件程序中的重要程度，以使后续可将该功能核心程度作为评估其对应的缺陷度量值的一个评估因素，综合评估该代码缺陷数据对应的缺陷度量值，以便对待测试版本ID对应的软件程序进行综合分析。
S602：基于代码缺陷数据查询与待测试版本ID相对应的埋点数据库，获取与代码缺陷数据相对应的页面使用频率和页面访问步长。
其中，埋点是指在软件程序的关键代码植入用于实现数据统计功能的代码。埋点的设置，主要用于追踪用户行为，从而统计关键代码的使用程度，以便进行数据分析。埋点数据库是用于存储埋点上传的埋点数据的数据库，每一埋点数据可反映该埋点对应的关键代码被触发或操作的情况。相应地，与待测试版本ID相对应的埋点数据库，用于存储与待测试版本ID相对应的软件程序在测试过程中埋点被触发所形成的所有埋点数据，以便基于该埋点数据进行数据分析。
与代码缺陷数据相对应的页面使用频率是指通过埋点统计确定代码缺陷数据对应的功能页面的点击量，并根据点击量确定其对应的页面使用频率。与代码缺陷数据相对应的页面使用频率的确定过程包括如下步骤：基于代码缺陷数据查询与待测试版本ID相对应的埋点数据库，获取与代码缺陷数据相对应的软件代码在测试周期内所触发的埋点数据；根据埋点数据确定代码缺陷数据相对应的功能页面的点击量，基于点击量查询预先设置的频率转换信息表，获取与点击量相对应的页面使用频率。其中，测试周期是指对该待测试版本ID对应的软件程序进行测试的周期。频率转换信息表是用于限定点击量与对应的频率之间的转换关系的信息表。在待测试版本ID对应的软件程序的测试周期内，每次访问该代码缺陷数据对应的功能页面，则该代码缺陷数据的软件代码中内置的埋点会触发一埋点数据，使得其功能页面的点击量被记录1次；在对同一功能页面的多次访问，其点击量累计，因此，可通过该代码缺陷数 据对应的软件代码在测试周期内所触发的埋点数据，确定其对应的功能页面的点击量。然后，基于该点击量查询频率转换信息表，以获取与待测试版本ID相对应的页面访问频率。本实施例中，代码缺陷数据对应的页面使用频率包括V0、V1和V2三种，分别对应高频、一般和低频三种情况。一种来说，代码缺陷数据对应的页面使用频率越高，说明其对应的软件代码被触发的频率越大，在待测试版本ID相对应的软件程序中越重要。
与代码缺陷数据对应的页面访问步长是指通过埋点统计确定该代码缺陷数据对应的功能页面的操作步骤长度。与代码缺陷数据相对应的页面访问步长的确定过程包括如下步骤：基于代码缺陷数据查询与待测试版本ID相对应的埋点数据库，获取代码缺陷数据所触发的埋点数据，根据埋点数据确定其对应的页面访问步长。具体地，在待分析版本对应的软件程序的埋点设置过程中，通过页面信息表预先记录每一埋点对应的功能页面的位置。服务器根据该埋点所触发的埋点数据可确定其对应的功能页面，根据软件程序开发过程中记录的页面信息表，可确定该功能页面的操作步骤，以获取与代码缺陷数据相对应的页面访问步长。例如，在微信这一软件程序开发过程中记录有微信刷朋友圈功能对应的页面信息表，其操作步骤包括：Step1：点击发现，进入发现页面；Step2：点击朋友圈，进入朋友圈页面，可查看朋友圈信息；若代码缺陷数据对应的软件代码所触发的埋点数据中确定出现缺陷的位置在查看朋友圈这个页面，则查看朋友圈这个功能在微信中的页面访问步长D就是2。本实施例中，代码缺陷数据对应的页面访问步长包括D0、D1和D2三种，分别对应1-2步、3-4步和5步以上这三种情况。一种来说，与代码缺陷数据相对应的页面访问步长越短，说明其对应的功能页面越经常触发，在待测试版本ID对应的软件程序中也重要。
S603：对代码缺陷数据进行重复测试，获取与代码缺陷数据相对应的复现概率。
其中，与代码缺陷数据相对应的复现概率是指在软件测试过程中，该代码缺陷数据对应的软件代码重复出现测试失败的概率。本实施例中，可设置代码缺陷数据对应的复现概率分别必然事件、高概率事件和低概率事件这三种，分别对于100％的概率会出现缺陷、50％-100％的概率会出现缺陷和50％以下的概率会出现缺陷这三种情况，分别用G0、G1和G2来表示。具体地，服务器在获取代码缺陷数据之后，可对该代码缺陷数据对应的软件代码进行重复测试，以确定重复出现该代码缺陷数据的概率，从而确定其代码缺陷数据对应的复现概率。一般来说，与代码缺陷数据相对应的复现概率越大，则说明该代码缺陷数据对应的软件代码出现缺陷的概率越大，为了保证待测试版本ID对应的软件程序的质量，越需要尽早修复。
具体地，步骤S603具体包括如下步骤：(1)对代码缺陷数据对应的软件代码进行重复测试，获取每次重复测试对应的测试结果和重复测试次数。该测试结果包括测试成功和测试失败两种结果。该重复测试次数是服务器在代码缺陷分析过程中确定的重复测试的次数。(2)统计测试结果为测试失败的测试缺陷数量。(3)采用概率计算公式对重复测试次数和测试缺陷数量进行计算，获取缺陷概率，概率计算公式为L＝U/Y，其中，L为缺陷概率，U为测试缺陷数量，Y为重复测试次数；(4)基于缺陷概率和预先设置的概率阈值，获取与代码缺陷数据相对应的复现概率。其中，概率阈值是服务器预先设置的用于评估不同复现概率的阈值。本实施例中，概率阈值包括100％和50％两个，也可以设置为其他数值。具体地，若代码缺陷数据的缺陷概率为100％，则与代码缺陷数据相对应的复现概率为必然事件，可用G0来表示；若代码缺陷数据的缺陷概率在50％-100％之间，则与代码缺陷数据相对应的复现概率为高概率事件，可用G1来表示；若代码缺陷数据的缺陷概率在50％以下，则与代码缺陷数据相对应的复现概率为低概率事件，可用G2来表示。
S604：采用代码扫描工具对代码缺陷数据进行扫描分析，获取与代码缺陷数据相对应的可维护性。
其中，与代码缺陷数据相对应的的可维护性是指基于代码缺陷数据对应的可维护指数与服务器预先设置的指数阈值进行分析所获取的评估指标。其中，可维护指数是指可维护指标(Maintainability Index)，其范围是0到100之间的值，用来指示所有类、成员、命名空间或项目的可维护性。一般来说，代码缺陷数据对应的可维护性越小，其对应的软件代码越重复，越需要优先进行修复，以避免因代码缺陷数据对应的软件代码存在缺陷而影响整个待测试版本ID对应的软件程序的开发进度。
本实施例中，服务器预先配置有可维护指数公式，该可维护指数公式具体为可维护指数＝MAX(0， (171-5.2*ln(霍尔斯特德量)-0.23*(圈复杂度)-16.2*ln(代码行数))*100/171)。步骤S304具体包括如下内容：(1)采用代码扫描工具对代码缺陷数据进行扫描分析，获取与代码缺陷数据相对应的评估参数，评估参数包括霍尔斯特德量、圈复杂度和代码行数。霍尔斯特德量(Halstead)是测量代码计算复杂度。具体上，如果一个程序有N个操作数和运算符，N个不同的的操作数和运算符，那么halstead＝N*Log2(n)，总之程序中的运算符和操作数越少越利于提高其霍尔斯特德量。圈复杂度(Cyclomatic Complexity)是代码的逻辑复杂度，程序的每个可能的执行分支(if，while，for等)都为该指标贡献1个点。一般来说，圈复杂度的建议范围<10，最多不超过20。代码行数(Lines of code)是指待测试版本ID对应的软件程序的代码行数。例如，采用Code Metrics这一代码扫描工具对代码缺陷数据进行扫描分析，可快速获取与代码缺陷数据相对应的评估参数，如在Code Metrics的操作界面上选择“Calculate Code Metrics”，即可在其结果窗口中获取对应一评估参数，这些评估参数包括霍尔斯特德量、圈复杂度和代码行数。(2)采用可维护指数公式对霍尔斯特德量、圈复杂度和代码行数进行计算，获取与代码缺陷数据相对应的可维护指数。(3)基于与代码缺陷数据相对应的可维护指数和预先设置的指数阈值，获取与代码缺陷数据相对应的可维护性。其中，其中，指数阈值是服务器预先设置的用于评估不同可维护性的阈值。具体地，服务器基于与代码缺陷数据相对应的可维护指数，根据该可维护指数确定其落入由至少两个指数阈值所界定的取值范围，根据该权值范围确定对应的可维护性。本实施例中，步骤S402计算出的可维护指数的取值范围为0-100，若指数阈值为10和20，则这两个指数阈值可将可维护指数划分成[0，10]、(10，20]和(20，100]三个取值范围，每个取值范围对应一可维护性，分别采用F0、F1和F2来表示。
可以理解地，通过采用代码扫描工具对代码缺陷数据进行扫描，以快速获取评估参数，再采用可维护指数公式对评估参数进行计算，可快速获取其对应的可维护指数，使得可维护指数的获取过程简单快速；然后，基于可维护指数和预设的指数阈值，可快速确定代码缺陷数据对应的可维护性，以便依据该可维护性对代码缺陷数据进行质量评估。
S605：基于待测试版本ID查询代码版本信息表，获取与代码缺陷数据相对应的稳定系数。
其中，代码版本信息表是存储在服务器中的用于记录待测试版本ID对应的软件程序对应的所有版本信息的数据表。稳定系数是用于评估待测试版本ID对应的软件程序是否稳定的指标。一般来说，全新的软件程序或者软件程序中的全新功能模块，其代码缺陷越容易发现，反之，软件程序的软件版本越高，其代码性能越稳定，其代码缺陷越难发现。具体地，服务器可通过待测试版本ID查询代码版本信息表，以获取与待测试版本ID对应的推出版本数量，根据该推出版本数量确定代码缺陷数据对应的稳定系数，以便基于该稳定系数对代码缺陷数据进行综合评估。
具体地，步骤S604具体包括如下步骤：(1)基于待测试版本ID查询代码版本信息表，获取与待测试版本ID对应的历史版本，根据历史版本确定推出版本数量。(2)基于推出版本数量查询稳定系数转换表，获取与代码缺陷数据相对应的稳定系数。服务器基于待测试版本ID查询代码版本信息表，可从该代码版本信息表中获取待测试版本ID对应的待分析版本的相关信息，也可以获取与待分析版本同源的至少一个历史版本的相关信息。然后，根据该待测试版本ID对应的至少一个历史版本的数量，确定推出版本数量。该推出版本数量可以具体限定为代码缺陷数据所在的历史版本对应的推出版本数量。其中，稳定系数转换表是用于存储推出版本数量和稳定系数之间的转换关系的数据表。具体地，服务器可基于推出版本数量查询稳定系数转换表，获取与该推出版本数量相对应的稳定系数，将该稳定系数确定为代码缺陷数据对应的稳定系数。可以理解地，待测试版本ID对应的软件程序中，全新功能模块中出现的代码缺陷比较多，其发现代码缺陷比较容易，因此，其稳定系数越低；相应地，若某一功能模块的版本越高，越稳定，其稳定系数越高。本实施例中，代码缺陷数据对应的稳定系数包括W0、W1和W2这三种，其对应的推出版本次数分别是10个以上、4-10之间和4个以下。
S606：对同一代码缺陷数据对应的功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数和稳定系数进行加权分析，获取与代码缺陷数据相对应的缺陷度量值。
其中，代码版本信息表是存储在服务器中的用于记录待测试版本ID对应的软件程序对应的所有版本信息的数据表。稳定系数是用于评估待测试版本ID对应的软件程序是否稳定的指标。一般来说， 全新的软件程序或者软件程序中的全新功能模块，其代码缺陷越容易发现，反之，软件程序的软件版本越高，其代码性能越稳定，其代码缺陷越难发现。具体地，服务器可通过待测试版本ID查询代码版本信息表，以获取与待测试版本ID对应的推出版本数量，根据该推出版本数量确定代码缺陷数据对应的稳定系数，以便基于该稳定系数对代码缺陷数据进行综合评估。
本实施例中，步骤S606中，即对同一代码缺陷数据对应的功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数和稳定系数进行加权分析，获取与代码缺陷数据相对应的缺陷度量值，具体包括如下步骤：
(1)基于同一代码缺陷数据对应的功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数和稳定系数查询预先设置的权重分值数据表(如下表一所示)，获取对应的评估分值和评估权重。其中，权重分值数据表是服务器中预先设置的用于记录每一评估因素对应的评估分值和评估权重的数据表。评估分值是预先设置每一种评估因素对应的分值，评估权重是预先设置的每一评估因素对应的权重。本实施例中，服务器基于同一代码缺陷数据对应的功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数和稳定系数这六个评估因素查询预先设置的权重分值数据表，获取每一评估因素对应的评估分值和评估权重，以便后续基于该评估分值和评估权重进行综合计算其对应的缺陷度量值。
表一权重分值数据表
Figure PCTCN2019120596-appb-000001
(2)采用缺陷度量值公式对评估分值和评估权重进行加权计算，获取代码缺陷数据对应的缺陷度量值；其中，缺陷度量值公式为Q＝∑S iK i，Q为缺陷度量值，i为功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数或稳定系数，S i为功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数或稳定系数对应的评估分值，K i为功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数或稳定系数对应的评估权重。
具体地，不同评估因素的评估权重可根据评估因素对软件程序的重复程度确定，如表一所示，可设置功能核心程度的评估权重为30％，页面使用频率和页面访问步长为20％，复现概率、可维护性和稳定系数为10％，则上述缺陷度量值公式具体为Q＝R*30％+V*20％+D*20％+G*10％+F*10％+W*10％，依据该缺陷度量值公式计算出的缺陷度量值的取值范围为[1，2]，可直观且客观反映代码缺陷数据的重要程度，即 其取值越大，则代码缺陷数据越重复，越需要优先修复，以保证软件程序的开发进度。
本实施例所提供的回归测试用例确定方法中，依次获取该代码缺陷数据对应的功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数和稳定系数等评估因素，通过对该评估因素进行加权计算，可快速获取对应的缺陷度量值，该缺陷度量值综合代码缺陷数据对应的软件代码的重要程度的多个评估因素，可客观地反映该软件代码的重要程度，以便基于该缺陷度量值合理安排缺陷修复工作，提高缺陷修复的效率。
在一实施例中，如图7所示，步骤S205中，采用层次分析法对代码改动热区和代码缺陷分布热区进行分析，获取目标测试用例，具体包括如下步骤：
S701：基于代码改动热区和代码缺陷分布热区构建层次结构模型，层次结构模型包括从上到下配置的目标层、准则层和方案层，方案层包含至少两个原始测试用例，准则层包括代码改动热区和代码缺陷分布热区。
具体地，基于代码改动热区和代码缺陷分布热区构建层次结构模型，该层次结构模型包括目标层A、准则层C和方案层P。该准则层C以代码改动热区和代码缺陷分布热区为准则层因素C 1和C 2，进一步地，该代码改动热区是依据代码改动次数和代码改动行数进行综合获取的，该准则层C还可将代码改动次数和代码改动行数作为新的准则层因素C 3和C 4。方案层P以软件版本测试过程中预先配置的至少一个原始测试用例为方案因素P 1、P 2……P n，分别对应原始测试用例1、原始测试用例2……原始测试用例Z。
S702：基于层次结构模型中的准则层因素的优先级，构建判断矩阵。
其中，判断矩阵是针对上一层次某一准则层因素而言，本层次中各准则层因素之间的相对重要性的数量表示，这是将定性判断转变为定量表示的一个过程。设准则层的因素C k与方案层P中的因素P 1、P 2……P n有关，其构建判断矩阵B如下所示：
Figure PCTCN2019120596-appb-000002
上述判断矩阵B中，B i,j通常取为1，3，5，7，9及其倒数，其含义为：B i,j＝1，表示P i和P j一样重要；B i,j＝3，表示P i比P j重要一点(稍微重要)；B i,j＝5，表示P i比P j明显重要；B i,j＝7，表示P i比P j重要得多；B i,j＝9，表示P i比P j极端重要。
S703：基于判断矩阵，获取下层因素相对上一层次的层次单排序；
其中，基于判断矩阵，获取下层因素相对上一层次的层次单排序是指根据判断矩阵，计算相对上一层次某因素而言，本层次与之有关的因素的重要性次序的权值。该层次单排序包括准则层因素相对于目标层的层次单排序，也包括方案层因素相对于准则层的层次单排序。层次单排序可归结为计算判断矩阵的特征根和特征向量的过程。具体地，对于判断矩阵B，计算满足BW＝λ maxW的特征根和特征向量，W的各个分量W i为相应准则层因素的层次单排序的权值。
步骤S703具体包括如下步骤：(1)对判断矩阵中每一列进行标准化处理，获取列标准化矩阵具体地，服务器将判断矩阵B中的每一项除以该项所在列中的每一项的和，得到标准化矩阵，即
Figure PCTCN2019120596-appb-000003
标准化处理的过程可保持矩阵的一致性。(2)对列标准化矩阵的每一行进行求和，获取行权重，即
Figure PCTCN2019120596-appb-000004
(3)对列标准化矩阵的行权重进行标准化处理，获取判断矩阵的特征向量。具体地，采用
Figure PCTCN2019120596-appb-000005
对列标准化矩阵中的行权重进行标准化处理，获取判断矩阵的特征值W i。(4)判断矩阵的特征值W i，获取判断矩阵的最大矩阵特征根λ max，其中，
Figure PCTCN2019120596-appb-000006
S704：若层次单排序进行一致性校验通过，则基于层次单排序获取层次总排序。
具体地，采用一致性指标公式对判断矩阵的最大矩阵特征根λ max进行计算，获取目标一致性指标，基于目标一致性指标与平均随机一致性指标计算随机一致性比例，若随机一致性比例小于或等于0.1，则该矩阵具有满意的一致性。一致性指标公式为
Figure PCTCN2019120596-appb-000007
其中，λ max为判断矩阵的最大矩阵特征根，RI是平均随机一致性指标，可根据判断矩阵的阶数查表获知。根据
Figure PCTCN2019120596-appb-000008
计算随机一致性比例，其中，CR为随机一致性比例。具体地，层次单排序进行一致性校验通过是指CR的取值小于或等于0.1。可以理解地，若层次单排序进行一致性校验通过，则判断矩阵的层次单排序的结果为W[W,W 2,...W n] T。
具体地，基于层次单排序获取层次总排序，是指利用层次单排序，综合计算方案层相对目标层重要性顺序的结合权值，层次总排序从上到下进行。例如，准则层因素C 1、C 2……C m对目标层的层次单排序为c 1、c 2……c m，构建方案层元素P 1、P 2……P n对c 1、c 2……c m所形成的单列矩阵构的矩阵，即准则方案矩阵，该准则方案矩阵具体为每一准则层因素C 1、C 2……C m对方案层元素P 1、P 2……P n所形成的矩阵，即C 1-P矩阵，C 2-P矩阵……C m-P矩阵。再根据准则方案矩阵，综合计算方案层元素P 1、P 2……P n对目标层的层次总排序，该层次总排序中每一方案层因素的方案权重为
Figure PCTCN2019120596-appb-000009
S705：若层次总排序进行一致性校验通过，则根据层次总排序确定方案层中的原始测试用例的方案权重，确定目标测试用例。
具体地，为了评价层次总排序的计算结果的一致性，需要计算与层次单排序类似的一致性校验量，在层次总排序中，一致性指标公式为
Figure PCTCN2019120596-appb-000010
当CR≤0.1时，认定层次总排序具有满意的一致性，其结果可供决策者参考。此时，可根据层次总排序确定方案层中的原始测试用例的方案权重，确定目标测试用例。
本实施例所提供的回归测试用例确定方法中，根据回归测试决策过程中，无法兼顾测试效率和测试质量的问题，采用层次分析法对代码改动热区和代码缺陷分布热区进行判断矩阵构建，并通过分析计算获取层次单排序和层次总排序，在一致性校验通过时，基于层次总排序确定目标测试用例，以使其确定的目标测试用例可有效保障测试质量，可有效避免遗漏代码改动热区和代码缺陷分布热区对应的代码进行测试的测试用例；并且，根据目标测试用例进行测试，可避免采用所有原始测试用例进行全面测试所存在的效率不足的问题。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
在一实施例中，提供一种回归测试用例确定装置，该回归测试用例确定装置与上述实施例中回归测试用例确定方法一一对应。如图8所示，该回归测试用例确定装置包括测试分析请求获取模块801、待测试版本代码获取模块802、代码改动热区获取模块803、代码缺陷分布热区获取模块804和目标测试用例获取模块805。各功能模块详细说明如下：
测试分析请求获取模块801，用于获取测试分析请求，测试分析请求包括待测试版本ID。
待测试版本代码获取模块802，用于基于待测试版本ID，从代码仓库中获取与待测试版本ID相对应的待测试版本代码。
代码改动热区获取模块803，用于采用版本控制工具对待测试版本代码进行代码分析，获取代码改动热区。
代码缺陷分布热区获取模块804，用于对代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区。
目标测试用例获取模块805，用于采用层次分析法对代码改动热区和代码缺陷分布热区进行分析，获取目标测试用例。
优选地，代码改动热区获取模块803包括历史版本数据获取子模块和代码改动热区获取子模块。
历史版本数据获取子模块，用于采用版本控制工具执行日志查询命令，获取与待测试版本代码相对应的历史版本测试数据。
代码改动热区获取子模块，用于采用版本控制工具对待测试版本代码和历史版本测试数据进行分析，获取代码改动热区。
优选地，代码改动热区获取子模块包括代码改动次数获取单元、代码改动行数获取单元、综合评估指标获取单元和代码改动热区获取单元。
代码改动次数获取单元，用于采用Code Maat工具对待测试版本代码和历史版本测试数据进行分析，获取待测试版本代码中每一代码模块对应的代码改动次数。
代码改动行数获取单元，用于采用Cloc工具对待测试版本代码和历史版本测试数据进行分析，获取待测试版本代码中每一代码模块对应的代码改动行数。
综合评估指标获取单元，用于对每一代码模块对应的代码改动次数和代码改动行数进行标准化和加权处理，获取每一代码模块对应的综合评估指标。
代码改动热区获取单元，用于基于每一代码模块对应的综合评估指标，获取代码改动热区。
优选地，在代码缺陷分布热区获取模块804之前，回归测试用例确定装置还包括：
代码缺陷数据获取模块，用于基于待测试版本ID查询测试结果数据库，获取与待测试版本ID相对应的至少一个代码缺陷数据。
缺陷度量值获取模块，用于对代码缺陷数据进行缺陷度量分析，获取代码缺陷数据的缺陷度量值。
缺陷优先级获取模块，用于依据代码缺陷数据的缺陷度量值，获取代码缺陷数据对应的缺陷优先级，并配置每一代码缺陷数据对应的正则表达式。
代码缺陷分布热区获取模块804，还用于依据代码缺陷数据对应的缺陷优先级，采用代码缺陷数据对应的正则表达式对代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区。
优选地，对缺陷度量值获取模块包括功能核心程度获取子模块、页面频率步长获取子模块、复现概率获取子模块、可维护性获取子模块、稳定系数获取子模块和缺陷度量值获取子模块
功能核心程度获取子模块，用于基于与待测试版本ID相对应的抽象语法树对代码缺陷数据进行语 法树分析，获取与代码缺陷数据相对应的功能核心程度。
页面频率步长获取子模块，用于基于代码缺陷数据查询与待测试版本ID相对应的埋点数据库，获取与代码缺陷数据相对应的页面使用频率和页面访问步长。
复现概率获取子模块，用于对代码缺陷数据进行重复测试，获取与代码缺陷数据相对应的复现概率。
可维护性获取子模块，用于采用代码扫描工具对代码缺陷数据进行扫描分析，获取与代码缺陷数据相对应的可维护性。
稳定系数获取子模块，用于基于待测试版本ID查询代码版本信息表，获取与代码缺陷数据相对应的稳定系数。
缺陷度量值获取子模块，用于对同一代码缺陷数据对应的功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数和稳定系数进行加权分析，获取与代码缺陷数据相对应的缺陷度量值。
优选地，缺陷度量值获取子模块包括评估分值权重获取单元和缺陷度量值获取单元。
评估分值权重获取单元，用于基于同一代码缺陷数据对应的功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数和稳定系数查询预先设置的权重分值数据表，获取对应的评估分值和评估权重。
缺陷度量值获取单元，用于采用缺陷度量值公式对评估分值和评估权重进行加权计算，获取代码缺陷数据对应的缺陷度量值。
其中，缺陷度量值公式为Q＝∑S iK i，Q为缺陷度量值，i为功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数或稳定系数，S i为功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数或稳定系数对应的评估分值，K i为功能核心程度、页面使用频率、页面访问步长、复现概率、可维护指数或稳定系数对应的评估权重。
优选地，目标测试用例获取模块805包括层次结构模型构建单元、判断矩阵构建单元、层次单排序获取单元和目标测试用例获取单元。
层次结构模型构建单元，用于基于代码改动热区和代码缺陷分布热区构建层次结构模型，层次结构模型包括从上到下配置的目标层、准则层和方案层，方案层包含至少两个原始测试用例，准则层包括代码改动热区和代码缺陷分布热区。
判断矩阵构建单元，用于基于层次结构模型中的准则层因素的优先级，构建判断矩阵。
层次单排序获取单元，用于基于判断矩阵，获取下层因素相对上一层次的层次单排序。
层次总排序获取单元，用于若层次单排序进行一致性校验通过，则基于层次单排序获取层次总排序。
目标测试用例获取单元，用于若层次总排序进行一致性校验通过，则根据层次总排序确定方案层中的原始测试用例的方案权重，确定目标测试用例。
关于回归测试用例确定装置的具体限定可以参见上文中对于回归测试用例确定方法的限定，在此不再赘述。上述回归测试用例确定装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图9所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机可读指令和数据库。该内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。该计算机设备的数据库用于存储执行回归测试用例确定方法过程中采用或者获取的数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机可读指令被处理器执行时以实现一种回归测试用例确定方法。
在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上 运行的计算机可读指令，处理器执行计算机可读指令时实现上述实施例中回归测试用例确定方法的步骤，例如图2所示的步骤S201-S205，或者图3至图7中所示的步骤，为避免重复，这里不再赘述。或者，处理器执行计算机可读指令时实现回归测试用例确定装置这一实施例中的各模块/单元的功能，例如图8所示的测试分析请求获取模块801、待测试版本代码获取模块802、代码改动热区获取模块803、代码缺陷分布热区获取模块804和目标测试用例获取模块805的功能，为避免重复，这里不再赘述。
在一实施例中，提供一个或多个存储有计算机可读指令的可读存储介质，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行时实现上述实施例中回归测试用例确定方法的步骤，例如图2所示的步骤S201-S205，或者图3至图7中所示的步骤，为避免重复，这里不再赘述。或者，该计算机可读指令被处理器执行时实现上述回归测试用例确定装置这一实施例中的各模块/单元的功能，例如图8所示的测试分析请求获取模块801、待测试版本代码获取模块802、代码改动热区获取模块803、代码缺陷分布热区获取模块804和目标测试用例获取模块805的功能，为避免重复，这里不再赘述。本实施例中的可读存储介质包括非易失性可读存储介质和易失性可读存储介质。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，该计算机可读指令可存储于一非易失性可读存储介质也可以存储在易失性可读存储介质中，该计算机可读指令在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。
以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (20)

  1. 一种回归测试用例确定方法，其特征在于，包括：
    获取测试分析请求，所述测试分析请求包括待测试版本ID；
    基于所述待测试版本ID，从代码仓库中获取与所述待测试版本ID相对应的待测试版本代码；
    采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区；
    对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区；
    采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例。
  2. 如权利要求1所述的回归测试用例确定方法，其特征在于，所述采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区，包括：
    采用版本控制工具执行日志查询命令，获取与所述待测试版本代码相对应的历史版本测试数据；
    采用版本控制工具对所述待测试版本代码和所述历史版本测试数据进行分析，获取代码改动热区。
  3. 如权利要求2所述的回归测试用例确定方法，其特征在于，所述采用版本控制工具对所述待测试版本代码和历史版本测试数据进行分析，获取代码改动热区，包括：
    采用Code Maat工具对所述待测试版本代码和历史版本测试数据进行分析，获取所述待测试版本代码中每一代码模块对应的代码改动次数；
    采用Cloc工具对所述待测试版本代码和历史版本测试数据进行分析，获取所述待测试版本代码中每一代码模块对应的代码改动行数；
    对每一代码模块对应的代码改动次数和代码改动行数进行标准化和加权处理，获取每一所述代码模块对应的综合评估指标；
    基于每一所述代码模块对应的综合评估指标，获取代码改动热区。
  4. 如权利要求1所述的回归测试用例确定方法，其特征在于，在所述对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区的步骤之前，所述回归测试用例确定方法还包括：
    基于所述待测试版本ID查询测试结果数据库，获取与所述待测试版本ID相对应的至少一个代码缺陷数据；
    对所述代码缺陷数据进行缺陷度量分析，获取所述代码缺陷数据的缺陷度量值；
    依据所述代码缺陷数据的缺陷度量值，获取所述代码缺陷数据对应的缺陷优先级，并配置每一所述代码缺陷数据对应的正则表达式；
    所述对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区，包括：依据所述代码缺陷数据对应的缺陷优先级，采用所述代码缺陷数据对应的正则表达式对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区。
  5. 如权利要求4所述的回归测试用例确定方法，其特征在于，对所述代码缺陷数据进行缺陷度量分析，获取所述代码缺陷数据的缺陷度量值，包括：
    基于与所述待测试版本ID相对应的抽象语法树对所述代码缺陷数据进行语法树分析，获取与所述代码缺陷数据相对应的功能核心程度；
    基于所述代码缺陷数据查询与所述待测试版本ID相对应的埋点数据库，获取与所述代码缺陷数据相对应的页面使用频率和页面访问步长；
    对所述代码缺陷数据进行重复测试，获取与所述代码缺陷数据相对应的复现概率；
    采用代码扫描工具对所述代码缺陷数据进行扫描分析，获取与所述代码缺陷数据相对应的可维护性；
    基于所述待测试版本ID查询代码版本信息表，获取与所述代码缺陷数据相对应的稳定系数；
    对同一所述代码缺陷数据对应的所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数和所述稳定系数进行加权分析，获取与所述代码缺陷数据相对应的缺陷度量值。
  6. 如权利要求5所述的回归测试用例确定方法，其特征在于，所述对同一所述代码缺陷数据对应 的所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数和所述稳定系数进行加权分析，获取与所述代码缺陷数据相对应的缺陷度量值，包括：
    基于同一所述代码缺陷数据对应的所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数和所述稳定系数查询预先设置的权重分值数据表，获取对应的评估分值和评估权重；
    采用缺陷度量值公式对所述评估分值和所述评估权重进行加权计算，获取所述代码缺陷数据对应的缺陷度量值；
    其中，所述缺陷度量值公式为Q＝∑S iK i，Q为缺陷度量值，i为所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数或所述稳定系数，S i为所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数或所述稳定系数对应的评估分值，K i为所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数或所述稳定系数对应的评估权重。
  7. 如权利要求1所述的回归测试用例确定方法，其特征在于，所述采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例，包括：
    基于所述代码改动热区和代码缺陷分布热区构建层次结构模型，所述层次结构模型包括从上到下配置的目标层、准则层和方案层，所述方案层包含至少两个原始测试用例，所述准则层包括所述代码改动热区和所述代码缺陷分布热区；
    基于所述层次结构模型中的准则层因素的优先级，构建判断矩阵；
    基于所述判断矩阵，获取下层因素相对上一层次的层次单排序；
    若所述层次单排序进行一致性校验通过，则基于所述层次单排序获取层次总排序；
    若层次总排序进行一致性校验通过，则根据层次总排序确定方案层中的原始测试用例的方案权重，确定目标测试用例。
  8. 一种回归测试用例确定装置，其特征在于，包括：
    测试分析请求获取模块，用于获取测试分析请求，所述测试分析请求包括待测试版本ID；
    待测试版本代码获取模块，用于基于所述待测试版本ID，从代码仓库中获取与所述待测试版本ID相对应的待测试版本代码；
    代码改动热区获取模块，用于采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区；
    代码缺陷分布热区获取模块，用于对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区；
    目标测试用例获取模块，用于采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例。
  9. 一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，其特征在于，所述处理器执行所述计算机可读指令时实现如下步骤：
    获取测试分析请求，所述测试分析请求包括待测试版本ID；
    基于所述待测试版本ID，从代码仓库中获取与所述待测试版本ID相对应的待测试版本代码；
    采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区；
    对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区；
    采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例。
  10. 如权利要求9所述的计算机设备，其特征在于，所述采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区，包括：
    采用版本控制工具执行日志查询命令，获取与所述待测试版本代码相对应的历史版本测试数据；
    采用版本控制工具对所述待测试版本代码和所述历史版本测试数据进行分析，获取代码改动热区。
  11. 如权利要求9所述的计算机设备，其特征在于，在所述对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区的步骤之前，所述处理器执行所述计算机可读指令时还实现如下步骤：
    基于所述待测试版本ID查询测试结果数据库，获取与所述待测试版本ID相对应的至少一个代码缺陷数据；
    对所述代码缺陷数据进行缺陷度量分析，获取所述代码缺陷数据的缺陷度量值；
    依据所述代码缺陷数据的缺陷度量值，获取所述代码缺陷数据对应的缺陷优先级，并配置每一所述代码缺陷数据对应的正则表达式；
    所述对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区，包括：依据所述代码缺陷数据对应的缺陷优先级，采用所述代码缺陷数据对应的正则表达式对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区。
  12. 如权利要求11所述的计算机设备，其特征在于，对所述代码缺陷数据进行缺陷度量分析，获取所述代码缺陷数据的缺陷度量值，包括：
    基于与所述待测试版本ID相对应的抽象语法树对所述代码缺陷数据进行语法树分析，获取与所述代码缺陷数据相对应的功能核心程度；
    基于所述代码缺陷数据查询与所述待测试版本ID相对应的埋点数据库，获取与所述代码缺陷数据相对应的页面使用频率和页面访问步长；
    对所述代码缺陷数据进行重复测试，获取与所述代码缺陷数据相对应的复现概率；
    采用代码扫描工具对所述代码缺陷数据进行扫描分析，获取与所述代码缺陷数据相对应的可维护性；
    基于所述待测试版本ID查询代码版本信息表，获取与所述代码缺陷数据相对应的稳定系数；
    对同一所述代码缺陷数据对应的所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数和所述稳定系数进行加权分析，获取与所述代码缺陷数据相对应的缺陷度量值。
  13. 如权利要求12所述的计算机设备，其特征在于，所述对同一所述代码缺陷数据对应的所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数和所述稳定系数进行加权分析，获取与所述代码缺陷数据相对应的缺陷度量值，包括：
    基于同一所述代码缺陷数据对应的所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数和所述稳定系数查询预先设置的权重分值数据表，获取对应的评估分值和评估权重；
    采用缺陷度量值公式对所述评估分值和所述评估权重进行加权计算，获取所述代码缺陷数据对应的缺陷度量值；
    其中，所述缺陷度量值公式为Q＝∑S iK i，Q为缺陷度量值，i为所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数或所述稳定系数，S i为所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数或所述稳定系数对应的评估分值，K i为所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数或所述稳定系数对应的评估权重。
  14. 如权利要求9所述的计算机设备，其特征在于，所述采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例，包括：
    基于所述代码改动热区和代码缺陷分布热区构建层次结构模型，所述层次结构模型包括从上到下配置的目标层、准则层和方案层，所述方案层包含至少两个原始测试用例，所述准则层包括所述代码改动热区和所述代码缺陷分布热区；
    基于所述层次结构模型中的准则层因素的优先级，构建判断矩阵；
    基于所述判断矩阵，获取下层因素相对上一层次的层次单排序；
    若所述层次单排序进行一致性校验通过，则基于所述层次单排序获取层次总排序；
    若层次总排序进行一致性校验通过，则根据层次总排序确定方案层中的原始测试用例的方案权重，确定目标测试用例。
  15. 一个或多个存储有计算机可读指令的可读存储介质，所述计算机可读存储介质存储有计算机可读指令，其特征在于，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行如下步骤：
    获取测试分析请求，所述测试分析请求包括待测试版本ID；
    基于所述待测试版本ID，从代码仓库中获取与所述待测试版本ID相对应的待测试版本代码；
    采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区；
    对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区；
    采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例。
  16. 如权利要求15所述的可读存储介质，其特征在于，所述采用版本控制工具对所述待测试版本代码进行代码分析，获取代码改动热区，包括：
    采用版本控制工具执行日志查询命令，获取与所述待测试版本代码相对应的历史版本测试数据；
    采用版本控制工具对所述待测试版本代码和所述历史版本测试数据进行分析，获取代码改动热区。
  17. 如权利要求15所述的可读存储介质，其特征在于，在所述对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区的步骤之前，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行如下步骤：
    基于所述待测试版本ID查询测试结果数据库，获取与所述待测试版本ID相对应的至少一个代码缺陷数据；
    对所述代码缺陷数据进行缺陷度量分析，获取所述代码缺陷数据的缺陷度量值；
    依据所述代码缺陷数据的缺陷度量值，获取所述代码缺陷数据对应的缺陷优先级，并配置每一所述代码缺陷数据对应的正则表达式；
    所述对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区，包括：依据所述代码缺陷数据对应的缺陷优先级，采用所述代码缺陷数据对应的正则表达式对所述代码改动热区进行代码缺陷过滤，获取代码缺陷分布热区。
  18. 如权利要求17所述的可读存储介质，其特征在于，对所述代码缺陷数据进行缺陷度量分析，获取所述代码缺陷数据的缺陷度量值，包括：
    基于与所述待测试版本ID相对应的抽象语法树对所述代码缺陷数据进行语法树分析，获取与所述代码缺陷数据相对应的功能核心程度；
    基于所述代码缺陷数据查询与所述待测试版本ID相对应的埋点数据库，获取与所述代码缺陷数据相对应的页面使用频率和页面访问步长；
    对所述代码缺陷数据进行重复测试，获取与所述代码缺陷数据相对应的复现概率；
    采用代码扫描工具对所述代码缺陷数据进行扫描分析，获取与所述代码缺陷数据相对应的可维护性；
    基于所述待测试版本ID查询代码版本信息表，获取与所述代码缺陷数据相对应的稳定系数；
    对同一所述代码缺陷数据对应的所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数和所述稳定系数进行加权分析，获取与所述代码缺陷数据相对应的缺陷度量值。
  19. 如权利要求18所述的可读存储介质，其特征在于，所述对同一所述代码缺陷数据对应的所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数和所述稳定系数进行加权分析，获取与所述代码缺陷数据相对应的缺陷度量值，包括：
    基于同一所述代码缺陷数据对应的所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数和所述稳定系数查询预先设置的权重分值数据表，获取对应的评估分值和 评估权重；
    采用缺陷度量值公式对所述评估分值和所述评估权重进行加权计算，获取所述代码缺陷数据对应的缺陷度量值；
    其中，所述缺陷度量值公式为Q＝∑S iK i，Q为缺陷度量值，i为所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数或所述稳定系数，S i为所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数或所述稳定系数对应的评估分值，K i为所述功能核心程度、所述页面使用频率、所述页面访问步长、所述复现概率、所述可维护指数或所述稳定系数对应的评估权重。
  20. 如权利要求15所述的可读存储介质，其特征在于，所述采用层次分析法对所述代码改动热区和所述代码缺陷分布热区进行分析，获取目标测试用例，包括：
    基于所述代码改动热区和代码缺陷分布热区构建层次结构模型，所述层次结构模型包括从上到下配置的目标层、准则层和方案层，所述方案层包含至少两个原始测试用例，所述准则层包括所述代码改动热区和所述代码缺陷分布热区；
    基于所述层次结构模型中的准则层因素的优先级，构建判断矩阵；
    基于所述判断矩阵，获取下层因素相对上一层次的层次单排序；
    若所述层次单排序进行一致性校验通过，则基于所述层次单排序获取层次总排序；
    若层次总排序进行一致性校验通过，则根据层次总排序确定方案层中的原始测试用例的方案权重，确定目标测试用例。
PCT/CN2019/120596 2019-03-19 2019-11-25 回归测试用例确定方法、装置、计算机设备及存储介质 Ceased WO2020186810A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910207525.5A CN110109820A (zh) 2019-03-19 2019-03-19 回归测试用例确定方法、装置、计算机设备及存储介质
CN201910207525.5 2019-03-19

Publications (1)

Publication Number Publication Date
WO2020186810A1 true WO2020186810A1 (zh) 2020-09-24

Family

ID=67484368

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/120596 Ceased WO2020186810A1 (zh) 2019-03-19 2019-11-25 回归测试用例确定方法、装置、计算机设备及存储介质

Country Status (2)

Country Link
CN (1) CN110109820A (zh)
WO (1) WO2020186810A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN121144214A (zh) * 2025-11-19 2025-12-16 北京羽乐创新科技有限公司 一种基于Java调用链路评估测试覆盖率的方法及系统

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110109820A (zh) * 2019-03-19 2019-08-09 深圳壹账通智能科技有限公司 回归测试用例确定方法、装置、计算机设备及存储介质
CN110825620B (zh) * 2019-10-16 2021-06-15 四川大学 回归测试中测试用例优先级计算方法
CN110928770B (zh) * 2019-10-29 2023-11-28 航天信息股份有限公司 软件测试的方法、装置、系统、存储介质和电子设备
CN110825650B (zh) * 2019-11-29 2023-04-11 北京网聘咨询有限公司 单元测试覆盖精度检测方法及装置
CN111008148B (zh) * 2019-12-20 2024-02-02 广州品唯软件有限公司 代码的测试方法、装置及计算机可读存储介质
CN113010406A (zh) * 2019-12-20 2021-06-22 华为技术有限公司 一种代码分析工具的管理方法、装置、设备及介质
CN113094251B (zh) * 2019-12-23 2024-02-23 深圳奇迹智慧网络有限公司 嵌入式系统测试方法、装置、计算机设备和存储介质
CN111240959B (zh) * 2019-12-27 2021-01-15 广东睿江云计算股份有限公司 一种回归测试范围的规划方法
CN111381995A (zh) * 2020-03-13 2020-07-07 青岛海尔科技有限公司 用于还原用户操作的方法及装置、计算机
CN111813681B (zh) * 2020-07-13 2022-09-09 兴业证券股份有限公司 一种动态用例优先级排序方法和装置
CN111949532A (zh) * 2020-08-10 2020-11-17 上海熙菱信息技术有限公司 一种基于契约测试下的风险应对的测试策略
CN112181482B (zh) * 2020-09-29 2023-03-21 平安科技（深圳）有限公司 版本验证方法、装置、电子设备及存储介质
CN113176997B (zh) * 2021-04-30 2024-05-03 深圳市共进电子股份有限公司 测试用例加载方法、装置、计算机设备和可读存储介质
CN114138634B (zh) * 2021-11-15 2024-01-12 苏州浪潮智能科技有限公司 测试用例的选取方法、装置、计算机设备和存储介质
CN115391217A (zh) * 2022-09-06 2022-11-25 平安银行股份有限公司 流量录制方法及其系统、流量回放方法及计算机设备
CN115757181B (zh) * 2022-12-05 2023-05-16 飞狐信息技术（天津）有限公司 一种代码检测方法、装置、设备及可读存储介质
CN120780609B (zh) * 2025-09-04 2025-11-04 四川互慧软件有限公司 基于热区识别与缺陷预测的测试用例动态排序方法与系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101329652B (zh) * 2008-07-30 2010-12-08 中兴通讯股份有限公司 一种回归测试自动化系统及方法
CN102184137A (zh) * 2011-05-16 2011-09-14 浪潮集团山东通用软件有限公司 一种无人值守的智能的自动化回归测试方法
US20170139685A1 (en) * 2014-06-25 2017-05-18 Chengdu Puzhong Software Limted Company Visual software modeling method to construct software views based on a software meta view
CN110109820A (zh) * 2019-03-19 2019-08-09 深圳壹账通智能科技有限公司 回归测试用例确定方法、装置、计算机设备及存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107193739B (zh) * 2017-05-23 2020-06-05 张泽祎 一种黑盒回归测试方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101329652B (zh) * 2008-07-30 2010-12-08 中兴通讯股份有限公司 一种回归测试自动化系统及方法
CN102184137A (zh) * 2011-05-16 2011-09-14 浪潮集团山东通用软件有限公司 一种无人值守的智能的自动化回归测试方法
US20170139685A1 (en) * 2014-06-25 2017-05-18 Chengdu Puzhong Software Limted Company Visual software modeling method to construct software views based on a software meta view
CN110109820A (zh) * 2019-03-19 2019-08-09 深圳壹账通智能科技有限公司 回归测试用例确定方法、装置、计算机设备及存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN121144214A (zh) * 2025-11-19 2025-12-16 北京羽乐创新科技有限公司 一种基于Java调用链路评估测试覆盖率的方法及系统

Also Published As

Publication number Publication date
CN110109820A (zh) 2019-08-09

Similar Documents

Publication Publication Date Title
WO2020186810A1 (zh) 回归测试用例确定方法、装置、计算机设备及存储介质
CN110083514B (zh) 软件测试缺陷评估方法、装置、计算机设备及存储介质
CN112005259A (zh) 用于商品测试的测试脚本的智能选择
CN109800147B (zh) 一种测试案例生成方法及终端设备
CN109473149B (zh) 数据质量评估方法、装置、电子设备及计算机可读介质
CN118132448B (zh) 测试用例处理方法、装置、计算机设备和存储介质
CN119201682A (zh) 回归测试方法、系统、计算机设备及存储介质
Polaczek et al. Exploring the software repositories of embedded systems: An industrial experience
CN117609278A (zh) 基于深度度量学习的多模态电力数据管理方法与系统
TW202328996A (zh) 超極端類別不平衡或資源約束下的代碼品質預測
CN119668681B (zh) 代码克隆风险评估方法、装置、设备及介质
KR102721798B1 (ko) 주택 리스크 진단 방법, 장치, 및 컴퓨터 프로그램
CN120197614A (zh) 质量评估方法、电子设备及计算机程序产品
CN120085835A (zh) 生成式架构解耦功能和业务逻辑方法、系统、设备及介质
CN119669034A (zh) 代码评审模型的训练和代码评审方法、装置和设备
JP2003345626A (ja) プロダクト・ナレッジ管理のためのナレッジ・オートメーション・エンジン
CN114490590A (zh) 数据仓库质量评价方法、装置、电子设备及存储介质
CN114741260A (zh) 接口兼容性检测方法、装置、电子设备及存储介质
CN117149872B (zh) 数据血缘分析方法、介质、装置及计算设备
CN121478270B (zh) 一种面向模型卡片示例代码的自动化程序修复方法
CN119512658B (zh) 大数据的管理方法、装置、设备及产品
US20260037996A1 (en) Modelled questionnaire generation
CN119473873A (zh) 基于开发流程的软件产品质量测试方法及其相关设备
CN119988195A (zh) 基于融合特征的Java开源软件版本间不兼容Bug数量预测方法
CN119149359A (zh) 数据处理方法及相关装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19919664

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 21.01.2022)

122 Ep: pct application non-entry in european phase

Ref document number: 19919664

Country of ref document: EP

Kind code of ref document: A1