CN111538674A - Distributed software testing method, system, device and medium - Google Patents
Distributed software testing method, system, device and medium Download PDFInfo
- Publication number
- CN111538674A CN111538674A CN202010512528.2A CN202010512528A CN111538674A CN 111538674 A CN111538674 A CN 111538674A CN 202010512528 A CN202010512528 A CN 202010512528A CN 111538674 A CN111538674 A CN 111538674A
- Authority
- CN
- China
- Prior art keywords
- module
- complexity
- testing
- test
- modules
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 29
- 238000013522 software testing Methods 0.000 title claims abstract description 25
- 238000012360 testing method Methods 0.000 claims abstract description 116
- 238000000691 measurement method Methods 0.000 claims description 19
- 238000004590 computer program Methods 0.000 claims description 9
- 238000004364 calculation method Methods 0.000 claims description 7
- 238000010998 test method Methods 0.000 claims 2
- 230000007547 defect Effects 0.000 description 5
- 238000005259 measurement Methods 0.000 description 4
- 230000015556 catabolic process Effects 0.000 description 3
- 238000006731 degradation reaction Methods 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 238000013468 resource allocation Methods 0.000 description 2
- 238000012502 risk assessment Methods 0.000 description 2
- 238000004088 simulation Methods 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
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
The present disclosure provides a distributed software testing method, system, device and storage medium, the method comprising: dividing the software engineering into a plurality of modules according to the preset minimum test quantity; acquiring the test task quantity T of each module; and arranging test resources for each module according to the test task amount T of each module. The method and the system can calculate the testing task quantity of each module to be tested according to the complexity coefficient and the complexity of each module, and reasonably arrange the testing task quantity of the whole software engineering, thereby improving the efficiency of distributed testing.
Description
Technical Field
The present disclosure belongs to the technical field of software engineering, and in particular, relates to a distributed software testing method, a distributed software testing system, a computer device, and a computer-readable storage medium.
Background
The software complexity measurement is used as an important component of software engineering, and can provide support for the control and degradation of software, the resource allocation of software testing and the development of high-quality software.
Generally, the higher the complexity of a code file, the greater the amount of tasks to detect defects. With the higher complexity of software engineering, the more and more huge software engineering, and the most basic characteristics of the huge engineering code quantity and the high complexity.
However, the existing code complexity measuring methods such as the LOC measuring method and the McCabe measuring method are single complexity measuring methods, only a small number of measuring elements are relied on or the super-parameter weight of each measuring element is set manually, the workload is large, and the accuracy is difficult to guarantee. The codes cannot be evaluated comprehensively and testing resources cannot be reasonably distributed during testing, so that the efficiency is low; this makes management and risk assessment of software inadequate.
Disclosure of Invention
The present disclosure provides a distributed software testing method, system, device and computer readable storage medium, which can measure the task amount of distributed modules to reasonably allocate resources and improve the efficiency of distributed testing.
In a first aspect, an embodiment of the present disclosure provides a distributed software testing method, including:
dividing the software engineering into a plurality of modules according to a preset minimum test quantity;
acquiring the test task quantity T of each module; and the number of the first and second groups,
and arranging test resources for each module according to the test task quantity T of each module.
Further, the obtaining the test task amount T of each module includes:
calculating the complexity C of each module;
acquiring a complexity coefficient lambda of software engineering; and the number of the first and second groups,
and calculating the testing task quantity T of each module according to the complexity C of each module and the complexity coefficient lambda of the software engineering.
Further, the obtaining of the complexity coefficient λ of the software engineering includes:
selecting a preset number of modules from the plurality of modules as modules to be tested;
acquiring a memory D consumed by testing each module to be tested; and the number of the first and second groups,
and calculating the complexity coefficient lambda of the software engineering according to the complexity C of each module to be tested and the memory D consumed by testing the module to be tested.
Further, the complexity C of each module is calculated by the following formula:
Ci＝ω1LOC(i)+ω2McCabe(i)，ω1+ω2＝1
wherein, CiComplexity of the i-th module, 1<i is less than or equal to m, m is the total number of modules divided by the software engineering, LOC (i) is the single complexity of the ith module calculated by the LOC measurement method, McCabe (i) is the single complexity of the ith module calculated by the McCabe measurement method, omega1The weight, ω, of relative importance of the LOC metric2Is the weight of relative importance of the McCabe measurement method.
Further, the complexity coefficient λ of the software engineering is calculated according to the complexity C of each module to be tested and the memory D consumed by testing the module to be tested, and the formula adopted is as follows:
wherein Cov (C, D) is covariance, and the calculation formula is:
wherein n is the total number of the modules to be tested, CiComplexity of the ith module under test, DiTo test the memory consumed by the ith module under test,
represents the average of the complexity of all the modules under test,
the average value of memory consumed by testing all the modules to be tested is shown.
Further, the test task quantity T of each module is calculated according to the complexity C of the module and the complexity coefficient λ of the software engineering, and the formula is as follows:
Ti＝λ*Ci,λ＞0
wherein, TiTest task volume for the ith module, CiComplexity of the i-th module, 1<N is less than or equal to i, n is the total number of the modules to be tested, and lambda is the complexity coefficient of the software engineering.
In a second aspect, an embodiment of the present disclosure provides a distributed software testing system, including: the device comprises a dividing unit, a calculating unit and a distributing unit;
the dividing unit is set to divide the software engineering into a plurality of modules according to the preset minimum test quantity;
the computing unit is set to obtain the testing task quantity T of each module;
the allocation unit is arranged to arrange test resources for the respective modules according to the test task volume T of each module.
In a third aspect, embodiments of the present disclosure further provide a computer device, including a memory and a processor, where the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes the distributed software testing method according to any one of the first aspect.
In a fourth aspect, an embodiment of the present disclosure provides a computer-readable storage medium, including: a computer program which, when run on a computer, causes the computer to perform a distributed software testing method as claimed in any one of the first aspects.
Has the advantages that:
the distributed software testing method, system, device and technical machine-readable storage medium provided by the present disclosure divide a software project into a plurality of modules; acquiring the test task quantity T of each module; and arranging test resources for each module according to the test task quantity T of each module. Therefore, the reasonable allocation of resources is carried out by measuring the task amount of the distributed modules, and the efficiency of the distributed test is improved.
Drawings
Fig. 1 is a flowchart of a distributed software testing method according to an embodiment of the present disclosure;
fig. 2 is an architecture diagram of a distributed software testing system according to a second embodiment of the present disclosure.
Detailed Description
In order to make the technical solutions of the present disclosure better understood by those skilled in the art, the present disclosure is further described in detail below with reference to the accompanying drawings and examples.
In which the terminology used in the embodiments of the disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used in the disclosed embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.
In the following, some terms in the present disclosure are explained to facilitate understanding by those skilled in the art:
the LOC (Line of Code) metric is a measure of the software scale, which represents the number of lines of source Code. Is a common code complexity measuring method at present.
The McCabe measurement method is a complexity measurement method based on program control flow. The McCabe complexity metric is also known as a loop metric. It considers that the complexity of a program depends largely on the complexity of the program diagram. The single sequence structure is the simplest, and the more loops are formed by loops and selection, the more complicated the procedure. The method uses graph theory as a tool, firstly draws a program graph, and then uses the loop number of the graph as a measure value of program complexity.
Covariance, Covariance (Covariance), is used in probability theory and statistics to measure the overall error of two variables. Variance is a special case of covariance, i.e. when two variables are the same. Covariance represents the error of the sum of the two variables. In covariance, define
Is the (Pearson) correlation coefficient of the random variables X and Y.
The software complexity measurement is used as an important component of software engineering, and can provide support for the control and degradation of software, the resource allocation of software testing and the development of high-quality software. The software complexity measurement is used as an important branch of the software measurement, and the complexity of a software product can be effectively evaluated. The complexity of the software is pre-warned through complexity measurement, so that people can be helped to objectively analyze and evaluate the complexity conditions of different stages of the software life cycle, and certain complexity control and degradation measures are taken to reduce the software defect rate and improve the software quality, but the convenience of quantitatively analyzing the complexity of the open source software is basically a single complexity measurement method at present, so that the codes cannot be comprehensively evaluated and the test task quantity cannot be estimated, and the test resources cannot be reasonably distributed during testing, so that the efficiency is low; this makes management and risk assessment of software inadequate.
The following describes the technical solutions of the present disclosure and how to solve the above technical problems in specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments.
Fig. 1 is a distributed software testing method provided in an embodiment of the present disclosure, including:
step S101: dividing the software engineering into a plurality of modules according to a preset minimum test quantity;
step S102: acquiring the test task quantity T of each module; and the number of the first and second groups,
step S103: and arranging test resources for each module according to the test task quantity T of each module.
The disclosed embodiments propose a concept of integration complexity, so-called integration complexity, i.e. the minimum number of tests that must be tested at the time of testing. Firstly, module division is carried out on the whole project, and then the testing task quantity of each module is calculated, wherein the testing task quantity not only comprises the complexity of software, but also needs to consider the requirements of the software project and the resources during actual testing. Therefore, the reasonable allocation of resources is carried out by measuring the task amount of the distributed modules, and the efficiency of the distributed test is improved.
Further, the obtaining the test task amount T of each module includes:
calculating the complexity C of each module;
acquiring a complexity coefficient lambda of software engineering; and the number of the first and second groups,
and calculating the testing task quantity T of each module according to the complexity C of each module and the complexity coefficient lambda of the software engineering.
Because the same test tool has the same test cost for testing different files, the calculation of the complexity coefficient is obtained by testing open source engineering simulation in advance. The workload generated during defect analysis is obtained by judging the engineering complexity of the code to be detected, and is matched with the available resources of the system, so that the test resources of the distributed defect detection system are utilized to the maximum extent.
Further, the obtaining of the complexity coefficient λ of the software engineering includes:
selecting a preset number of modules from the plurality of modules as modules to be tested;
acquiring a memory D consumed by testing each module to be tested; and the number of the first and second groups,
and calculating the complexity coefficient lambda of the software engineering according to the complexity C of each module to be tested and the memory D consumed by testing the module to be tested.
With the increasing complexity of software engineering, the software engineering is increasingly huge, and the huge amount and high complexity of large engineering codes are the most basic characteristics, so that the preprocessing of the codes to generate intermediate information has higher requirements on the internal memory, and the higher the complexity of the codes is, the larger the memory occupied by the codes is. Therefore, when large-scale software is subjected to distributed computation, not only the complexity of software engineering itself but also the requirement on a memory during actual testing are considered. Dividing the software engineering into a plurality of modules; selecting a preset number of modules to be tested; calculating a complexity coefficient according to the complexity of each module to be tested and the memory consumed by testing the module; and calculating the test task quantity of each module to be tested according to the complexity coefficient and the complexity of each module, and reasonably arranging the test task quantity of the whole software engineering. The efficiency of distributed software testing is improved, and the codes are comprehensively evaluated from multiple angles, so that the distributed software testing system is more comprehensive.
Further, the preset number of the modules to be tested is more than or equal to 3.
The complexity coefficient can be calculated by performing simulation test on open source engineering in advance, and can also be tested in real time, and in order to improve the accuracy of the complexity coefficient, enough samples are required during testing, so that the preset number of the modules to be tested is generally 3-10.
Further, the complexity C of each module is calculated by the following formula:
Ci＝ω1LOC(i)+ω2McCabe(i)，ω1+ω2＝1
wherein, CiComplexity of the i-th module, 1<i is less than or equal to m, m is the total number of modules divided by the software engineering, LOC (i) is the single complexity of the ith module calculated by the LOC measurement method, McCabe (i) is the single complexity of the ith module calculated by the McCabe measurement method, omega1The weight, ω, of relative importance of the LOC metric2Is the weight of relative importance of the McCabe measurement method.
In order to improve the credibility of the integration complexity, a credibility evaluation index is defined, respective single complexity is obtained by calculation from the two aspects of the LOC measurement method and the McCabe measurement method, and the comprehensive complexity of the LOC measurement method and the McCabe measurement method is obtained according to the weight of relative importance.
Further, the complexity coefficient λ of the software engineering is calculated according to the complexity C of each module to be tested and the memory D consumed by testing the module to be tested, and the formula adopted is as follows:
wherein Cov (C, D) is covariance, and the calculation formula is:
wherein n is the total number of the modules to be tested, CiComplexity of the ith module under test, DiTo test the memory consumed by the ith module under test,
represents the average of the complexity of all the modules under test,
the average value of memory consumed by testing all the modules to be tested is shown.
D (c) and d (d) represent the complexity and variance of the consumed memory, respectively. The variance is a mature calculation method used for describing the degree of correlation between two variables, if the degrees of deviation of the two variables from the mean are more consistent, the numerical value is larger, and through the relationship between the complexity C and the two dependent variables of the memory D consumed during testing, the complexity coefficient, namely the (Pearson) correlation coefficient of the complexity and the consumed memory can be obtained.
Further, the test task quantity T of each module is calculated according to the complexity C of the module and the complexity coefficient λ of the software engineering, and the formula is as follows:
Ti＝λ*Ci,λ＞0
wherein, TiTest task volume for the ith module, CiComplexity of the i-th module, 1<N is less than or equal to i, n is the total number of the modules to be tested, and lambda is the complexity coefficient of the software engineering.
The complexity coefficient is a positive number because the larger the general software complexity value is, the higher the memory consumed during testing will be. The execution strategy of the distributed defect detection method of the test task can be given through the obtained test task amount of all the modules, and the modules with large task amount are distributed to the nodes with sufficient resources for testing so as to reasonably promote the execution of the test task.
Fig. 2 is a distributed software testing system provided in the second embodiment of the present disclosure, including: a dividing unit 1, a calculating unit 2 and an allocating unit 3;
the dividing unit is set to divide the software engineering into a plurality of modules according to the preset minimum test quantity;
the computing unit 2 is set to obtain the testing task quantity T of each module;
the allocation unit sets 3 to arrange test resources for each module according to the test task amount T of each module.
Further, the acquiring, by the computing unit 2, the test task amount T of each module includes:
calculating the complexity C of each module;
acquiring a complexity coefficient lambda of software engineering; and the number of the first and second groups,
and calculating the testing task quantity T of each module according to the complexity C of each module and the complexity coefficient lambda of the software engineering.
Further, the calculating unit 2 obtains a complexity coefficient λ of the software engineering, including:
selecting a preset number of modules from the plurality of modules as modules to be tested;
acquiring a memory D consumed by testing each module to be tested; and the number of the first and second groups,
and calculating the complexity coefficient lambda of the software engineering according to the complexity C of each module to be tested and the memory D consumed by testing the module to be tested.
Further, the calculating unit 2 calculates the complexity C of each module by using the following formula:
Ci＝ω1LOC(i)+ω2McCabe(i)，ω1+ω2＝1
wherein, CiComplexity of the i-th module, 1<i is less than or equal to m, m is the total number of modules divided by the software engineering, LOC (i) is the single complexity of the ith module calculated by the LOC measurement method, McCabe (i) is the single complexity of the ith module calculated by the McCabe measurement method, omega1The weight, ω, of relative importance of the LOC metric2Is the weight of relative importance of the McCabe measurement method.
Further, the calculating unit 2 calculates the complexity coefficient λ of the software engineering according to the complexity C of each module to be tested and the memory D consumed by testing the module to be tested, and the formula is as follows:
wherein Cov (C, D) is covariance, and the calculation formula is:
wherein n is the total number of the modules to be tested, CiComplexity of the ith module under test, DiTo test the memory consumed by the ith module under test,
represents the average of the complexity of all the modules under test,
the average value of memory consumed by testing all the modules to be tested is shown.
Further, the calculating unit 2 calculates the test task amount T of each module according to the complexity C of the module and the complexity coefficient λ of the software engineering, and the formula is as follows:
Ti＝λ*Ci,λ＞0
wherein, TiTest task volume for the ith module, CiComplexity of the i-th module, 1<N is less than or equal to i, n is the total number of the modules to be tested, and lambda is the complexity coefficient of the software engineering.
Since the distributed software testing system of this embodiment is used to implement the distributed software testing method in the first embodiment, the description is simple, and specific reference may be made to the related description in the first embodiment of the method, which is not described herein again.
Furthermore, the embodiments of the present disclosure also provide a computer device, which includes a memory and a processor, where the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes the above-mentioned various possible methods.
In addition, the embodiments of the present disclosure also provide a computer-readable storage medium, in which computer-executable instructions are stored, and when at least one processor of the user equipment executes the computer-executable instructions, the user equipment executes the above-mentioned various possible methods.
Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. Of course, the storage medium may also be integral to the processor. The processor and the storage medium may reside in an ASIC (Application Specific Integrated Circuit). Additionally, the ASIC may reside in user equipment. Of course, the processor and the storage medium may reside as discrete components in a communication device.
It is to be understood that the above embodiments are merely exemplary embodiments that are employed to illustrate the principles of the present disclosure, and that the present disclosure is not limited thereto. It will be apparent to those skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope of the disclosure, and these are to be considered as the scope of the disclosure.
Claims (9)
1. A distributed software testing method, comprising:
dividing the software engineering into a plurality of modules according to a preset minimum test quantity;
acquiring the test task quantity T of each module; and the number of the first and second groups,
and arranging test resources for each module according to the test task quantity T of each module.
2. The method according to claim 1, wherein the obtaining the testing task amount T of each module comprises:
calculating the complexity C of each module;
acquiring a complexity coefficient lambda of software engineering; and the number of the first and second groups,
and calculating the testing task quantity T of each module according to the complexity C of each module and the complexity coefficient lambda of the software engineering.
3. The testing method according to claim 2, wherein the obtaining of the complexity coefficient λ of the software engineering comprises:
selecting a preset number of modules from the plurality of modules as modules to be tested;
acquiring a memory D consumed by testing each module to be tested; and the number of the first and second groups,
and calculating the complexity coefficient lambda of the software engineering according to the complexity C of each module to be tested and the memory D consumed by testing the module to be tested.
4. The test method according to claim 2, wherein the complexity C of each module is calculated using the following formula:
Ci＝ω1LOC(i)+ω2McCabe(i)，ω1+ω2＝1
wherein, CiComplexity of the i-th module, 1<i is less than or equal to m, m is the total number of modules divided by the software engineering, LOC (i) is the single complexity of the ith module calculated by the LOC measurement method, McCabe (i) is the single complexity of the ith module calculated by the McCabe measurement method, omega1The weight, ω, of relative importance of the LOC metric2Is the weight of relative importance of the McCabe measurement method.
5. The testing method according to claim 3, wherein the complexity coefficient λ of the software engineering is calculated according to the complexity C of each module under test and the memory D consumed for testing the module under test, and the formula adopted is as follows:
wherein Cov (C, D) is covariance, and the calculation formula is:
wherein n is the total number of the modules to be tested, CiComplexity of the ith module under test, DiTo test the memory consumed by the ith module under test,
represents the average of the complexity of all the modules under test,
the average value of memory consumed by testing all the modules to be tested is shown.
6. The test method according to claim 2, wherein the test task quantity T of each module is calculated according to the complexity C of the module and the complexity coefficient λ of the software engineering, and the formula is as follows:
Ti＝λ*Ci,λ＞0
wherein, TiTest task volume for the ith module, CiComplexity of the i-th module, 1<N is less than or equal to i, n is the total number of the modules to be tested, and lambda is the complexity coefficient of the software engineering.
7. A distributed software testing system, comprising: the device comprises a dividing unit, a calculating unit and a distributing unit;
the dividing unit is set to divide the software engineering into a plurality of modules according to the preset minimum test quantity;
the computing unit is set to obtain the testing task quantity T of each module;
the allocation unit is arranged to arrange test resources for the respective modules according to the test task volume T of each module.
8. A computer device comprising a memory and a processor, the memory having a computer program stored therein, the processor performing the distributed software testing method of any one of claims 1-6 when the processor executes the computer program stored in the memory.
9. A computer-readable storage medium, comprising: computer program which, when run on a computer, causes the computer to perform the distributed software testing method of any one of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010512528.2A CN111538674A (en) | 2020-06-08 | 2020-06-08 | Distributed software testing method, system, device and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010512528.2A CN111538674A (en) | 2020-06-08 | 2020-06-08 | Distributed software testing method, system, device and medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111538674A true CN111538674A (en) | 2020-08-14 |
Family
ID=71976229
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010512528.2A Pending CN111538674A (en) | 2020-06-08 | 2020-06-08 | Distributed software testing method, system, device and medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111538674A (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120030679A1 (en) * | 2010-07-31 | 2012-02-02 | International Business Machines Corporation | Resource Allocator With Knowledge-Based Optimization |
| CN104516815A (en) * | 2013-09-30 | 2015-04-15 | 西门子公司 | Method and device used for supporting test based on risks |
| CN107066384A (en) * | 2017-03-28 | 2017-08-18 | 东南大学 | Software Evolution appraisal procedure based on Halstead complexity metrics |
| CN107807878A (en) * | 2016-09-09 | 2018-03-16 | 北京航空航天大学 | Automatic test engine based on keyword |
| CN109254905A (en) * | 2017-07-13 | 2019-01-22 | 北京航空航天大学 | Distributed parallel automatization test system based on workflow |
| CN110297766A (en) * | 2019-06-03 | 2019-10-01 | 合肥移瑞通信技术有限公司 | Method for testing software and software testing system based on distributed test node cluster |
| CN110908911A (en) * | 2019-11-26 | 2020-03-24 | 京东数字科技控股有限公司 | Software testing method and device, electronic equipment and computer readable medium |
| CN111008148A (en) * | 2019-12-20 | 2020-04-14 | 广州品唯软件有限公司 | Code testing method and device and computer readable storage medium |
-
2020
- 2020-06-08 CN CN202010512528.2A patent/CN111538674A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120030679A1 (en) * | 2010-07-31 | 2012-02-02 | International Business Machines Corporation | Resource Allocator With Knowledge-Based Optimization |
| CN104516815A (en) * | 2013-09-30 | 2015-04-15 | 西门子公司 | Method and device used for supporting test based on risks |
| CN107807878A (en) * | 2016-09-09 | 2018-03-16 | 北京航空航天大学 | Automatic test engine based on keyword |
| CN107066384A (en) * | 2017-03-28 | 2017-08-18 | 东南大学 | Software Evolution appraisal procedure based on Halstead complexity metrics |
| CN109254905A (en) * | 2017-07-13 | 2019-01-22 | 北京航空航天大学 | Distributed parallel automatization test system based on workflow |
| CN110297766A (en) * | 2019-06-03 | 2019-10-01 | 合肥移瑞通信技术有限公司 | Method for testing software and software testing system based on distributed test node cluster |
| CN110908911A (en) * | 2019-11-26 | 2020-03-24 | 京东数字科技控股有限公司 | Software testing method and device, electronic equipment and computer readable medium |
| CN111008148A (en) * | 2019-12-20 | 2020-04-14 | 广州品唯软件有限公司 | Code testing method and device and computer readable storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 周铭男: "高效的分布式缺陷检测方法及应用", 《中国优秀硕士学位论文全文数据库信息科技辑》 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2017157203A1 (en) | Reference test method and device for supervised learning algorithm in distributed environment | |
| US9389668B2 (en) | Power optimization for distributed computing system | |
| US20070250630A1 (en) | Method and a system of generating and evaluating potential resource allocations for an application | |
| CN101650685A (en) | Method and device for determining energy efficiency of equipment | |
| CN109409628A (en) | Acquisition terminal production firm evaluation method based on metering big data Clustering Model | |
| CN113537797A (en) | Method and device for intelligent test workload assessment based on historical data analysis, terminal equipment and storage medium | |
| Cremonesi et al. | Indirect estimation of service demands in the presence of structural changes | |
| CN109271319A (en) | A kind of prediction technique of the software fault based on panel Data Analyses | |
| CN115841046A (en) | Accelerated degradation test data processing method and device based on wiener process | |
| CN114355094B (en) | Product reliability weak link comprehensive evaluation method and device based on multi-source information | |
| Singh et al. | Improving the quality of software by quantifying the code change metric and predicting the bugs | |
| US20240249160A1 (en) | Prediction apparatus, prediction method and prediction program | |
| CN113158435B (en) | Complex system simulation running time prediction method and device based on ensemble learning | |
| CN112784435B (en) | GPU real-time power modeling method based on performance event counting and temperature | |
| CN101976222A (en) | Framework-based real-time embedded software testability measuring method | |
| Liu et al. | Change point software belief reliability growth model considering epistemic uncertainties | |
| US8065256B2 (en) | System and method for detecting system relationships by correlating system workload activity levels | |
| CN110928750B (en) | Data processing method, device and equipment | |
| CN111538674A (en) | Distributed software testing method, system, device and medium | |
| Aaziz et al. | Modeling expected application runtime for characterizing and assessing job performance | |
| Rattagan et al. | Clustering and symbolic regression for power consumption estimation on smartphone hardware subsystems | |
| CN111598390B (en) | Method, device, equipment and readable storage medium for evaluating high availability of server | |
| Lee et al. | Software reliability prediction for open source software adoption systems based on early lifecycle measurements | |
| CN107491576B (en) | Missile component reliability analysis method based on performance degradation data | |
| CN112231156B (en) | SPEC CPU2017 test result estimation method, system, device and medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200814 |