全国咨询热线：136-9172-9932
本阶段的关键过程域主要包括两个方面：一是评估本次软件测试的质量;二是完成软件测试报告。测试报告完成后，还需要对测试报告进行评审，才能决定产品是否可以发布。
一、评估软件质量
测试执行完成后，需要对软件质量进行评估，评估的目的是确定被测试系统是否可以发布。通常评估的指标主要包括以下几个方面。
(1)验证所有需求都被实现
所以有需求都必须被实现，并且所有的需求应该都有相应的测试用例覆盖，即我们通常所说的需求100%覆盖。当然在实际测试过程中我们很难对所有需求进行100%覆盖，因为这涉及到两个问题：一是在整理需求时，我们很难将所有的需求都整理出来，也就是说，其实任何一份需求说明书都有一些隐性需求的存在;二是每个需求其实都有一个覆盖粒度的问题，也就是覆盖的粒度大小会决定需求验证的全面性。由于这两个原因的存在，在实际测试过程中我们很难保证需求100%覆盖。
(2)致命和严重问题都已解决
在测试执行结束时需要对未解决的问题进行评审，评审未解决问题的目的主要包括两个维度：一是评审未解决问题的风险，确定系统是否带着这些问题发布;二是系统不能遗留致命和严重问题发布，即致命和严重问题都必须解决。之所以不能带着致命和严重问题发布，是因为发布后系统可能存在着很大的风险，这样后期面临着巨大的市场压力。
(3)测试用例通过率超过97%
在执行测试时我们会记录下所有用例执行的结果，在统计测试用例执行结果时，必须确定测试用例通过率超过97%。之所以对测试用例通过率有要求，原因很简单，如果我们不能确定绝大多数用例执行结果都是通过的，那么意味着我们的功能存在很多缺陷，而一个存在很多缺陷的产品被发布，后期的风险可想而知。
(4)三级操作以内的缺陷都已经修复
在定义缺陷时，一般将三级操作以内的缺陷定义为严重或致命的问题，所以不允许遗留三级操作以内的缺陷与不能遗留严重或致命问题是一样的道理。
(5)缺陷修复率超过95%
在分析缺陷的时候，还有一个指标是遗留缺陷率，通常缺陷修复率应该超过95%，即遗留缺陷不能超过5%，虽然遗留缺陷中不能有严重或致命的缺陷，但同时也需要注意，缺陷遗留率不能超过5%。因为如果遗留的缺陷数太多，这样系统发布出去后，系统失效的风险会变得很大。
(6)核心业务和基本业务的基本事件流和备选事件流都正确，不存在缺陷
关于这个维度其实和遗留问题中不能包含致命和严重问题是一致的，因为核心业务和基本业务的基本流和备选流如果出现问题，一般都是严重问题，如果这些问题遗留出去后，势必都会带来严重的影响。
(7)分析缺陷变化趋势，确定系统处于稳定状态
评估系统能不能发布，还有一个很重要的因素，就是评估系统是否达到稳定状态。如果系统未处于稳定状态，说明系统是不可以发布的，比如华为现在最常用的方法就是使用四象限的方法对缺陷进行分析。
关于缺陷分析方法，在缺陷管理与分析章节中会详细地介绍。
二、完成测试报告
测试报告是整个测试过程的一个总结，主要包括以下几个方面的内容：
(1)测试内容记录
在测试报告中必须记录整个执行过程中用例执行的结果，执行测试时一般会有好多次迭代过程，每次迭代时所执行的用例可能有一些不同的地方，所以在记录测试结果时应该记录每轮迭代的结果，每轮迭代中每条用例执行的情况必须详细记录。当然如果公司有专业的用例管理工具，那么这些测试的结果都会自动记录在这个用例管理工具中，这样只要将测试结果导出来就可以。
(2)测试度量
在测试报告中需要对缺陷进行一些度量，通过这些度量指标可以更好地确定系统是否可以发布。测试度量的主要目的如下：
判断测试的有效性;
判断测试的完整性;
判断工作产品的质量;
分析和改进测试过程。
通常需要度量的指标包括以下几个方面：
第一：千行代码缺陷率。
千行代码缺陷率=缺陷总数/代码总数，千行代码缺陷率是衡量软件开发质量的一个常用指标。在CMMI 级别中，其实不同的CMMI 级别与缺陷的发生率也是有关系的。
CMMI 级别 千行代码缺陷率
CMMI1 11.95‰
CMMI 2 5.52‰
CMMI 3 2.39‰
CMMI 4 0.92‰
CMMI 5 0.32‰
但千行代码缺陷率的高低并不能完全衡量软件质量，因为随着开发能力的不断进步，我们更希望少写些代码来实现软件功能，这样可能千行代码缺陷率较高，但研发能力并不一定就很差。
第二：用例粒度。
用例粒度=用例总数/代码总数，这个指标主要是衡量测试用例粒度的，用例粒度侧面反应了测试的完面性，从某种情况来说，用例粒度值越大说明测试越全面，但在实际的测试工作中，不能单纯地只统计整个系统的用例粒度，这是不正确的。因为不同的需求在实际测试中用例粒度要求是完全不同的。所以在分析用例粒度时，通常需要按需求的优先级来划分，即对于基本功能和核心功能
其用例粒度一定会更大，同样对于一些用得比较少的功能，其粒度也就可以小一些。现在很少有公司具体去定义这个用例粒度的值，目前来说并没有具体的计算公式，这个值只能通过对以往的历史项目进行分析得到。
通常在实际的测试过程中，如果需要得到准确的用例粒度，需要分析以下几类功能的用例粒度：核心功能、基本功能、一般功能、镀金功能。
第三：用例探测率。
用例探测率=缺陷总数/用例总数。用例探测率是侧面衡量用例质量的一个指标，通常情况下如果用例探测率的值越大，说明设计用例的质量越高;反之则说明用例设计的质量可能比较低。当然在企业中如何希望更全面地控制测试质量，测试设计是很重要的一个环节，需要注意的是我们说的是测试设计而非用例设计。准确地说，用例设计是测试设计里面的一个环节，而非全部的测试设计，关于测试设计模型在第6 章中将会详细介绍。
(3)测试结果分析
测试结果分析是指对测试结果的数据进行分析，当然分析的对象首先就是缺陷，通过对这些缺陷的分析来确定系统是否处于稳定状态，这是最核心的，否则无法确定系统是否可以发布，或者说无法确定系统发布后存在的风险。
对测试结果进行分析，通常要分析以下数据：
遗留缺陷分析，按严重等级分析未解决的BUG 分布情况。这个主要是分析遗留问题中是否存在严重或致命问题，如果存在这两类问题未解决，那么系统可能不允许发布。
分析所有缺陷，按严重等级分析所有发现的BUG 分布情况。这主要是分析缺陷分布的情况，同时也可以分析开发质量。通常情况下发现的缺陷中，严重和致命问题不能超过某个百分比，如果超过就说明开发质量还存在很大的问题，并且增加了系统发布的风险。
分析累积缺陷分布的情况。这主要是分析后期缺陷是否处于一个稳定状态，关于分析方法在第8 章中会详细地介绍。
以每个版本或每周为单位分析每个版本或每周发现缺陷数。这主要是分析缺陷的趋势，分析缺陷是否收敛、缺陷是否服从韦伯分布，关于分析方法在第8 章中会详细地介绍。
分析每个版本修复缺陷数。这主要是分析每个版本修复缺陷的情况，当然这个图需要与每个版本所发现缺陷一起分析，目的是分析缺陷收复成本，分析是否有一些缺陷重复修改多次。
按核心模块来分析所有发现缺陷的数目。这主要是分析核心模板缺陷情况，分析这类数据有两个目的：一是这类数据以后可以成为其他类似系统参考的数据;二是可以确定核心模块测试的充分性。
按缺陷引入方式来分析缺陷分布情况，如需求、设计、代码等。这类分析主要是用于持续改进研发流程，因为通过这个图的分析可以更好地确定缺陷分布的情况，这也是我们常说的正交缺陷分析方法。关于正交缺陷分析法，在第8 章中会详细地介绍。
按测试类型(如功能、易用性等)分析BUG 的分布情况，这类分析也是典型的正交缺陷分析方法，在第8章中会详细地介绍。四象限。四象限主要是分析系统是否到达稳定状态，具体的使用方法在第8 章中会详细地介绍。
(4)测试结论
就上面分析的数据对测试结果进行说明，主要是描述被测试对象是否达到发布的要求，是否可以发布，所以关于测试结论主要是从系统功能、性能、易用性等角度来确定系统是否可以发布，当然还有一个重要的维度是从缺陷的角度来说明系统是否处于稳定状态，是否可以发布。
(5)可能风险
就目前的测试数据进行分析，系统发布后可能存在的风险，列出所有可能的风险点，主要包括以下方面的内容：
系统的可靠性风险;
系统稳定性风险;
核心功能稳定性风险;
系统雪崩的风险。
三、阶段度量指标
评估与报告阶段度量的指标主要包括以下几个方面：
完成评估所需要的所有数据;
对缺陷进行详细的分析，确定系统是否达到稳定状态;
产品发布风险确定;
完成测试报告。
四、能力评价
能力评价主要包括以下几个方面：
具备对产品评估的能力;
掌握常用的评估数据;
掌握常用缺陷分析方法，可以对缺陷进行较详细的分析;
可以确定产品发布的风险。
本章节主要介绍了关于“软件测试—关键过程域”的内容，大家觉得有用的话记得每天来这里和小编一起学习涨薪技能哦。
