Metrics for Testing and Quality Assurance: A Detailed Guide
测试和质量保证指南：详细指南

In the current scenario, quality control is the luring force behind the success and popularity of software products, which has drastically amplified the requisite of taking efficient measures for quality. Thus, software testers apply a solid drive to gauging their aims and efficacy, which is possible using various metrics for testing and Key Performance Indicators (KPIs).
在当前的情况下，质量控制是软件产品成功和流行背后的诱惑力，这大大增强了采取有效措施进行质量控制的必要性。因此，软件测试人员应用一种坚实的驱动力来衡量他们的目标和效率，这可以使用各种测试指标和关键性能指标（KPI）。

Software testing metrics are the quantifiable indexes of the testing procedure, quality, productivity, progress, and overall health. The purpose is to boost the effectiveness and conclusiveness of the software testing operation and support the fabrication of better resolutions for future testing by delivering precise data about the test proceedings. A metric expresses the grade to which a system or a process possesses a given criterion in numerical stints.
软件测试度量是测试过程、质量、生产率、进度和整体健康状况的可量化指标。其目的是通过提供有关测试过程的精确数据，提高软件测试操作的有效性和结论性，并为未来的测试提供更好的解决方案。一个度量表示一个系统或一个过程在数值上达到给定标准的程度。

The intent of collecting test metrics is to use the data to improve the test process. This includes finding tangible solutions to the following:
收集测试度量的目的是使用数据来改进测试过程。这包括为以下问题找到切实的解决办法：

• Time and expense required for the test
  测试所需的时间和费用
• Category of the bugs. The number of them found, fixed, reopened, closed, deferred, or unreported.
  bugs的种类已找到、修复、重新打开、关闭、延迟或未报告的事件的数量。
• Grade and caliber of the testing operation
  检测作业的等级和口径
• Adequacy of the test effort
  测试工作的准确性
• Testing bandwidth of the current release
  正在测试当前版本的带宽

Significance of Metrics in Testing
维生素C检测的意义

Metrics decide the software’s quality and performance. Developers may utilize the appropriate software testing standards to enrich their productivity. A few critical software testing standards are given below:
软件的质量和性能取决于软件的质量和性能。开发人员可以利用适当的软件测试标准来丰富他们的生产力。下面给出了一些关键的软件测试标准：

• Testing benchmarks assist in deciding what kinds of refinements are needed to generate a high-quality, flawless software product.
  测试基准有助于决定需要什么样的改进来生成高质量、完美的软件产品。
• Making reasonable jurisdictions regarding the various testing facets that succeed, like project scheduling, design plan, and expense estimations.
  对成功的各种测试方面做出合理的管辖权，如项目进度，设计计划和费用估算。
• Examining the prevailing technology or operation to determine if it demands further changes.
  检查当前的技术或操作，以确定是否需要进一步的更改。

Types of Software Testing Metrics
软件测试的类型

Software testing metrics are split into three groups.
软件测试度量分为三组。

• Process Metrics: The process metrics outline the characteristics and performance of a design. These features add to the SDLC (Software Development Life Cycle) procedure’s enhancement and conservation.
  过程度量：过程度量概述了设计的特征和性能。这些特性增加了SDLC（软件开发生命周期）过程的增强和保护。
• Product Metrics: A product’s design, size, quality, performance, and complexity are delineated by the product metrics. Developers can amend the caliber of their software development by employing these features.
  产品度量：产品的设计、规模、质量、性能和复杂性由产品度量描述。开发人员可以通过使用这些功能来修改他们的软件开发的口径。
• Project Metrics: Project metrics are employed to evaluate the generic quality of a project. It estimates the design resources and deliverables and decides productivity, cost, and possible flaws.
  项目度量：项目度量用于评估项目的一般质量。它评估设计资源和可交付成果，并决定生产率、成本和可能的缺陷。

It is crucial to ascertain the befitting testing measures for the operation. Some of the points to keep in mind are the following:
确定合适的测试措施对操作至关重要。以下是需要牢记的几点：

• Choosing the target audiences precisely before creating the metrics.
  在创建指标之前准确选择目标受众。
• Outlining the objective for which the standards were developed.
  概述制定标准的目标。
• Formulating measures based on the project-specific necessities.
  根据项目具体需要制定措施。
• Estimating the financial gain chummed with every statistic.
  估计财务收益与每一个统计数据密切相关。
• Matching the measurements to the design life cycle for achieving the best results.
  使测量与设计生命周期相匹配，以获得最佳结果。

A substantial advantage of automated testing is that it allows testers to finalize more tests in less time while covering a large composition of variations that would be practically tough to compute manually.
自动化测试的一个重要优点是，它允许测试人员在更短的时间内完成更多的测试，同时覆盖大量的变化，这些变化实际上很坚韧手动计算。

You can read more about metrics in SDLC here: Metrics in SDLC: Let the Truth Prevail
你可以在这里阅读更多关于SDLC中的指标：SDLC中的测试：让真相占上风

Test Metrics Life Cycle 测试用例生命周期

The Test Metrics Life Cycle is gathering information, looking at it, and reporting on it to determine how successful a software project is. It starts by picking the right metrics that will show progress and what needs to be fixed. Then you collect data from logs, bug-tracking systems, and performance tests. After that, you review all the information you gathered and report on it to see how well the software works. Finally, with this knowledge, changes can be made to make the product or process better. By tracking test metrics throughout a project’s life cycle, companies can ensure their work is getting them closer to their goal.
测试用例生命周期收集信息，查看信息，并报告信息，以确定软件项目的成功程度。它首先选择正确的指标，以显示进度和需要修复的内容。然后从日志、错误跟踪系统和性能测试中收集数据。之后，您将检查收集到的所有信息，并报告这些信息，以了解软件的工作情况。最后，有了这些知识，可以做出改变，使产品或过程更好。通过在项目的整个生命周期中跟踪测试指标，公司可以确保他们的工作使他们更接近他们的目标。

Analysis: 分析：

• Recognizing the most appropriate metrics for testing.
  识别最合适的测试指标。
• Defining the adopted QA standards.
  定义采用的QA标准。

Communicate: 沟通：

• Training the software testing team on the data points to be collected for processing the recognized metrics.
  对软件测试团队进行数据点的培训，以处理公认的度量标准。
• Informing the testing team and the stakeholders of the requirements.
  通知测试团队和利益相关者需求。

Evaluation: 评价：

• Capturing and then verifying the data.
  获取并验证数据。
• Using the collected data for evaluating the value of the metric.
  使用收集的数据来评估指标的值。

Report: 报告：

• Creating a sound and compelling inference for the paper.
  为论文创造一个合理而令人信服的推论。
• Gathering potent inputs from the stakeholders and representatives based on the information. Distribution of these reports to the representatives and stakeholders.
  根据信息收集利益攸关方和代表的有力投入。向代表和利益攸关方分发这些报告。

Testing Metrics: What they are and how they work?
测试工具：它们是什么以及它们如何工作？

Testing metrics help gauge the success of software testing activities and processes. They can be divided into two categories: quantitative (looking at numerical data such as test coverage, defect density, pass/fail rates, and test execution time) and qualitative (looking at subjective data such as customer satisfaction surveys, usability studies, and user feedback). These metrics provide an objective measurement of how well a system performs against predetermined standards and insight into how users perceive the quality of the product. They can be used to identify areas for improvement and measure the success of a project.
测试度量有助于衡量软件测试活动和过程的成功。它们可以分为两类：定量（查看数值数据，如测试覆盖率，缺陷密度，通过/失败率和测试执行时间）和定性（查看主观数据，如客户满意度调查，可用性研究和用户反馈）。这些指标提供了一个客观的测量，衡量系统在预定标准下的表现，并深入了解用户如何感知产品的质量。它们可用于确定需要改进的领域，并衡量项目的成功。

Base Metrics 基础设施

Fundamental QA metrics, also known as base metrics, are a composition of absolute numbers collected by analysts throughout the development and execution process. Some of them are :
基本QA指标，也称为基本指标，是分析师在整个开发和执行过程中收集的绝对数字的组合。其中包括：

• Number of test cases
  数据组数
• Number of passed, failed, and blocked test cases
  通过、失败和阻塞的测试用例数
• Total number of defects and critical issues reported, accepted, rejected, and deferred
  报告、接受、拒绝和推迟的缺陷和关键问题总数
• Number of planned and actual test hours
  计划和实际测试小时数
• Number of bugs discovered after shipping
  发货后发现的bug数量

Derived Metrics 推导度量

Base metrics are the fundamental starting point, but only placing those values is not enough. Testers should also derive some useful benchmarks using mathematical computations.
基本指标是基本的出发点，但仅仅放置这些值是不够的。测试人员还应该使用数学计算得出一些有用的基准。

Only tabulating the absolute numbers collected by analysts and testers produces more confusion than solutions. Hence, we can dive deeper into solving the glitches and flaws in our software testing course using the derivative metrics.
仅仅将分析师和测试人员收集的绝对数字制成表格，会产生更多的混乱，而不是解决方案。因此，我们可以更深入地使用衍生度量来解决软件测试课程中的故障和缺陷。

Test Planning 测试计划

The following metrics are derived to facilitate test planning:
以下指标是为了方便测试计划而得出的：

• Passed test case percentage = Total number of passed test cases / Total number of test cases x 100%
  通过测试用例百分比=通过测试用例总数/测试用例总数x 100%
• Passed test case percentage = Total number of failed test cases / Total number of test cases x 100%
  通过测试用例百分比=失败测试用例总数/测试用例总数x 100%
• Blocked test case percentage = Total number of blocked test cases / Total number of test cases x 100%
  阻塞测试用例百分比=阻塞测试用例总数/测试用例总数x 100%
• Fixed defects percentage = Total number of defects fixed / Total number of defects reported x 100%
  修复缺陷百分比=修复缺陷总数/报告缺陷总数x 100%
• Accepted defects percentage = Total number of defects accepted as valid / Total number of defects reported x 100%
  接受的缺陷百分比=接受为有效的缺陷总数/报告的缺陷总数x 100%
• Defects rejected percentage = Total number of defects rejected as invalid / Total number of defects reported x 100%
  不合格百分比=因无效而不合格的缺陷总数/报告的缺陷总数x 100%
• Defects deferred percentage = Total number of defects deferred for future / Total number of defects reported x 100%
  延迟的缺陷百分比=延迟到未来的缺陷总数/报告的缺陷总数x 100%
• Critical defects percentage = Total number of critical defects / Total number of defects reported x 100%
  关键缺陷百分比=关键缺陷总数/报告缺陷总数x 100%
• Average time to repair defects = Total time taken for fixing the bugs / Total number of bugs found
  修复缺陷的平均时间=修复缺陷所用的总时间/发现的缺陷总数

Test Effort 测试工作

Testing effort standards will answer the question, “how long or how many or how much?” They are practiced to establish baselines for test planning. However, these metrics are mean values where 50% of the values fall over the mean and 50% under.
测试工作标准将回答这个问题，“多长时间、多少或多少？”它们被用来建立测试计划的基线。然而，这些指标是平均值，其中50%的值超过平均值，50%低于平均值。

Some of these specific metrics are:
其中一些具体指标是：

• Tests run per period = Total number of tests run / Total time taken
  每个周期运行的测试=运行的测试总数/所用的总时间
• Test design efficiency =  Total number of tests designed / Total time taken
  测试设计效率=设计的测试总数/所用的总时间
• Test review efficiency = Total number of tests reviewed / Total time taken
  测试评审效率=评审的测试总数/所用总时间
• Defects per test hour = Total number of defects / Total number of test hours
  每测试小时的缺陷数=缺陷总数/总测试小时数
• Bugs per test = Total number of bugs found / Total number of tests
  每次测试的bug数=发现的bug总数/测试总数
• Time to test a bug = Total time taken between defect fix to retest for all defects / Total number of bugs found
  测试bug的时间=从修复缺陷到重新测试所有缺陷所用的总时间/发现的bug总数

Test Effectiveness 测试效率

Test effectiveness finds a solution to “how good are the tests?” It evaluates the bug-finding quality and ability of a test set. Test effectiveness measures generally express the difference between the total number of defects reported by the QA team and the overall defects found in terms of percentage.
测试有效性找到了一个解决方案，“测试有多好？”它评估测试集的缺陷发现质量和能力。测试有效性度量通常表示QA团队报告的缺陷总数与发现的总体缺陷之间的差异（以百分比表示）。

• Test effectiveness using defect containment efficiency: The higher the test effectiveness, the better the test set and the lesser the long-term maintenance effort will be. For instance, if the test effectiveness is 70%, it concludes that 20% of the defects are removed from the testing operation.
  使用缺陷遏制效率的测试有效性：测试有效性越高，测试集就越好，长期维护工作就越少。例如，如果测试有效性是70%，那么它得出的结论是20%的缺陷从测试操作中被删除。
• Context-based test effectiveness using team assessment: Defect containment efficiency metrics do not come in handy in the following cases:
  使用团队评估的基于上下文的测试有效性：缺陷遏制效率度量在以下情况下不会派上用场：

1. Already mature product 已经成熟的产品
2. Buggy and unstable product
   缺陷和不稳定的产品
3. Lacking enough tests due to constraints of time or resource
   由于时间或资源的限制，缺乏足够的测试

In such cases, another way to estimate test set effectiveness is using a context-based approach.
在这种情况下，估计测试集有效性的另一种方法是使用基于上下文的方法。

For instance, in a particular context, the QA team decides that a befitting test set needs to cover high-risk demands adequately.
例如，在一个特定的环境中，QA团队决定一个合适的测试集需要充分覆盖高风险的需求。

Read this blog to understand why quality assurance is of paramount importance: Why The World Doesn’t Need QA Engineers (But still requires quality assurance)
阅读这篇博客，了解为什么质量保证至关重要：为什么世界不需要QA工程师（但仍然需要质量保证）

Test Coverage 测试覆盖

Software quality metrics estimate the fitness of the application under the testing process. The following core block of standards that need to be analyzed revolves around the testing coverage. Test coverage benchmarks gauge the test exertion and help determine the operations’ significance.
软件质量度量是对软件在测试过程中的适应性进行评估。下面需要分析的核心标准块围绕着测试覆盖率。测试覆盖率基准衡量测试工作并帮助确定操作的重要性。

Given below are some crucial test coverage benchmarks.
下面给出了一些关键的测试覆盖基准。

Test execution coverage: 测试执行覆盖范围：

This provides a model of the comprehensive tests administered compared to the unsettled test runs. It is typically expressed as a percentage.
这提供了一个与未确定的测试运行相比较的综合测试模型。它通常以百分比表示。

Test requirements coverage:
测试要求覆盖范围：

The number of demands covered by the total amount of scoped needs for a release, design, sprint, or project must be divided and analyzed to achieve a high-level prospect of the requisites having test coverage.
发布、设计、sprint或项目的范围需求总量所涵盖的需求数量必须被划分和分析，以实现具有测试覆盖率的测试的高级前景。

Test Economics Metrics 考试经济学

Infrastructure and tools contribute to the expense of testing. Testing systems do not have fathomless financial resources to spend. Thus, estimating how much you can spend and how much you indeed wrap up spending is eventful.
基础设施和工具增加了测试费用。测试系统并没有无限制的财政资源可供花费。因此，估计你能花多少钱以及你实际上花了多少钱是很重要的。

Here are a few test economics measures that can provide insight into budget planning:
以下是一些测试经济学指标，可以为预算规划提供洞察力：

Total allocated costs for testing:
测试的总分配成本：

It refers to the amount that QA directors and CIOs have calculated for all testing exercises and resources for single dev projects for the entire year.
它指的是QA总监和CIO为单个开发项目全年的所有测试活动和资源计算的数量。

The actual cost of testing:
测试的实际成本：

It refers to the real money that went into the testing operation.
它指的是进入测试操作的真实的钱。

It is assumed that all testing sets are equal in complexity. For illustration, if the budget is $1000 and includes testing 100 necessities, the cost of trying a requisite is $10. These values are substantial as they help estimate future projects and systems budgets.
假设所有测试集的复杂度相等。举例来说，如果预算是1000美元，包括测试100种必需品，那么尝试一种必需品的成本是10美元。这些值非常重要，因为它们有助于估计未来的项目和系统预算。

Budget variance: 预算差异：

The variance between the actual and planned costs is referred to as budget variance.
实际成本和计划成本之间的差异称为预算差异。

Schedule variance: 进度差异：

It is the difference between the actual time taken to complete tests and the planned time.
它是完成测试的实际时间和计划时间之间的差异。

Cost per bug fix: 每次bug修复的成本：

It refers to the amount of effort spent on a defect per developer.
它指的是每个开发人员花费在缺陷上的工作量。

However, the cost of a bug fix is 10 * $60 = $600; if a developer spends 10 hours fixing a defect, their hourly rate is $60.
但是，修复一个bug的成本是10 * 60美元= 600美元;如果一个开发人员花了10个小时修复一个缺陷，那么他们的小时费率是60美元。

Cost of not testing: 不测试的成本：

All the finances that went towards the rework equate to the cost of not testing If a block of new features went into production but claimed rework. The expense of not testing can also be silhouetted to a more subjective value, similar to a person’s perspective.
所有用于返工的资金相当于不测试的成本，如果一个新功能块进入生产，但声称返工。不进行测试的费用也可以被描绘成一个更主观的价值，类似于一个人的观点。

Some examples of a subjective cost of not testing are as follows.
不进行测试的主观成本的一些例子如下。

1. More client care calls and service requests.
   更多的客户服务电话和服务请求。
2. Productive outages 生产中断
3. Loss of user/ client trust
   失去用户/客户的信任
4. Loss of client fidelity 客户忠诚度的丧失
5. Poor brand awareness 品牌知名度低

Test Team Metrics 测试团队

These can be exploited to deduce if work allotment is uniform for each test squad member and to check if anyone needs added process/ project knowledge expositions. These criteria should never be used as an erudition to attribute fault.
这些可以被用来推断每个测试小组成员的工作分配是否一致，并检查是否有人需要增加过程/项目知识。这些标准绝不应被用作归咎过错的博学之词。

• Distribution of defects returned per team member
  每个团队成员返回的缺陷分布
• Distribution of open defects for retest per test team member
  按测试团队成员分配待重新测试的未决缺陷
• Test cases allotted per test team member
  每个测试团队成员分配的测试用例
• Test cases executed by test team member
  测试团队成员执行的测试用例

Usually, histograms or pie charts are created to get a quick snap of the job assignment. It allows the testing manager to determine the cause and take remedial actions if demanded.
通常，创建直方图或饼图是为了快速了解作业分配情况。它允许测试经理确定原因并在需要时采取补救措施。

Test Execution Status 测试执行状态

The test execution snap chart shows the complete implementations disposed of as passed, failed, blocked, incomplete, and unexecuted for easy engrossment of the test sprint status.
测试执行快照图表显示了完整的实现，它们被划分为通过、失败、阻塞、未完成和未执行，以便于记录测试冲刺状态。

These charts are great optical apprentices for the daily status huddle because raw figures have a high chance of sagging through people’s brains. The rising and contracting bars captivate attention and impart advancement and speed much more effectively.
这些图表是很好的视觉学徒，因为原始数据很有可能在人们的大脑中下垂。上升和收缩的酒吧吸引注意力，并赋予进步和速度更有效。

• Status Chart 状态图表
• Defect Find Rate Tracking
  缺陷发现率跟踪
• Tracking and Defect Find Rate Tracking
  跟踪和缺陷发现率跟踪

The theoretical curve is plotted using these cumulative test execution rates and defect counts. Compared to the raw figures, these charts shall signal early that the testing course needs to be changed if the targets need to be reached.
使用这些累积测试执行率和缺陷计数绘制理论曲线。与原始数据相比，如果需要达到目标，这些图表将提前发出信号，表明需要改变测试过程。

Effectiveness of Change Metrics
变革的有效性

Software undergoes a handful of frequent changes. Changes typically invoke new deformities, catalyze timelines to sag, reduce operation robustness, and endanger quality. Embodied modifications must be watched precisely to conclude their concussion on the robustness and stability of the existing product.
软件经历了一些频繁的变化。变更通常会引起新的缺陷，加速时间线的下降，降低操作的稳健性，并危及质量。必须精确地观察这些修改，以得出它们对现有产品的鲁棒性和稳定性的冲击。

The following benchmarks can help in a better understanding of concussions.
以下基准可以帮助更好地理解脑震荡。

Effect of Testing Changes:
测试变更的影响：

It numerically refers to the total number of defects that can be put down to changes. This could denote ensuring defects have been affected and fixing visions attached when they are reported to the development team.
它在数字上指的是可以归因于更改的缺陷总数。这可能意味着确保缺陷已经受到影响，并在向开发团队报告时附加修复愿景。

Final Thoughts 最后的想法

Software testing metrics and crucial performance indexes enrich the course of software testing. From securing the precision of the multiple tests carried out by the testers to authenticating the class of the product, these benchmarks play a pivotal purpose in the software development lifecycle.
软件测试度量和关键的性能指标丰富了软件测试的内容。从确保测试人员执行的多个测试的精度到验证产品的类别，这些基准测试在软件开发生命周期中起着关键的作用。

Hence, by enforcing and executing these testing standards and performance pointers, the effectiveness and accuracy of the testing efforts can be exponentially increased to get a phenomenal grade for software products.
因此，通过强制执行这些测试标准和性能指标，测试工作的有效性和准确性可以成倍增加，以获得软件产品的惊人成绩。

Frequently Asked Questions:
常见问题解答：

What are metrics in QA?
什么是QA中的Metrics？

Metrics in QA s are measurements that software developers use to ensure their products are up to scratch. They involve testing the product to check for any possible problems or issues. These tests help identify any weaknesses in the product so they can be fixed before it’s released.
软件质量保证是软件开发人员用来确保他们的产品达到标准的度量。它们涉及测试产品以检查任何可能的问题或问题。这些测试有助于识别产品中的任何弱点，以便在发布之前进行修复。

Why are test metrics important?
为什么测试指标很重要？

Test metrics are essential for figuring out how well the software works and how it performs. Developers can use them to help them be more efficient. Test metrics show what changes need to be made so that the software is perfect and of good quality.
测试度量对于确定软件的工作情况和性能至关重要。开发人员可以使用它们来帮助他们提高效率。测试度量显示了需要进行哪些更改，以使软件完美且具有良好的质量。

Suggested Reading 建议阅读

Software Testing Strategy
软件测试策略

Top Software Testing Trends
热门软件测试趋势

Software Testing Interview Questions
软件测试面试问题

Different Software Testing Types
不同的软件测试类型

Software Inspection Vs Software Testing
软件检查VS软件测试

Defect leakage in Software Testing
软件测试中的缺陷泄漏

KPIs of Software Testing
软件测试的KPI

Sign-up here for free trials with Testsigma.