1、概述

　　测试是衡量产品质量的一把尺子，《TPI Next》中对测试的理解是“Testing is a process that provides insight into， and advice on， quality and the related risks.”

　　测试结束后总是要给出对产品质量的一个评价，供利益相关人做相应的决策。（关于测试是提供对产品质量的信息，而不是产品发布的决策者这一点之前在这篇blog中已经阐述。）当然，测试对质量给出评价的形式可能有很多种，可以陈述具体的问题和风险，也可以同时给出你对被测系统的评级，下表是一个简单评价形式。


特性  质量评估（A/B/C/D）  质量评估说明  测试投入充分性  关键遗留问题和风险  后续测试策略 
被测特性XXX  C  在XX的情况下，XX业务失败  不充分  问题1：XXX
问题2：XXX  开展XXX等测试 


　　本文重点讨论表中第二列的质量评级（A/B/C/D）如何更准确地给出。

　　2、问题：测试人员如何准确的评价产品质量？

　　2.1 问题描述

　　我们先来审视一下传统测试过程的输入-需求。当然，不同企业拿到用户需求后的处理流程是不一样的（比如Agile or V model），开发和测试的组织结构也是不一样的（比如是按照模块划分team还是按照特性划分team；开发team和测试team是一一对应还是有所交叉等等），下图表现的是只是其中一种可能的、简化的、典型的过程。

　　如上图所示，需求（Requirements）是测试的重要输入，通常我们用DR（设计需求），因为OR（原始需求）比较粗，too general。经常的做法是，将这些DR按大类划分到几个Test Feature中，每一个Test Feature可能同时由不同的测试小组负责测试设计和测试执行，当然，各个测试小组的侧重点是不一样的。每到一个测试里程碑点，各个测试组都会根据各自的测试情况（问题发现、测试用例执行率等）对所负责的Test Feature给出测试的评价，A/B/C/D，以及相应的陈述。当然，每个组织应该定义一套统一的A/B/C/D的标准供大家参考。

　　问题是，每个特性的A/B/C/D的结论是否准确？所有特性的A/B/C/D的结论加一起又如何判别整个系统的质量？是否所有特性的都是A或B，版本可以对外发布？测试人员给出的A/B/C/D有多大成分是基于一种feeling给出的？

　　2.2 问题分析

　　这个问题其实比较大，和很多方面都有关系，我在另外一篇blog里谈到的通过Incremental Analysis & Traceability的方法确保测试的有效性，从而可以进行较为准确的质量评估，本文试图从另外一个角度探讨这个问题。

　　对于任何一条DR，开发人员的任务是比较明确的，实现它可以，无论是由一个项目组实现，还是多个项目组配合实现。但是，对于测试人员，考虑的事情复杂一些。我们除了要验证DR本身的功能实现是否正确，还要验证该DR和其它功能之间的交互，还要考虑客户可能使用的各种场景（Scenario），可能一个测试特性，涉及到多种组网场景、各种参数配置、兼容多种外部平台等。如果把测试场景和测试特性交互起来，测试endless了，并且也没有必要在每一种测试场景下，都验证被测特性的基本功能、异常功能、与其它功能的交互、非功能属性等各方面。如何设计更有效的、有限数目的用例尽量做到大的测试覆盖，这属于另外一个话题，本文先不探讨（其实关于这个问题，有多种思路，比如Richard Bender提出的基于需求的测试、比如我提出的MFQ&PPDCS也是一种）。测试设计人员基于测试经验，同时考虑外部商用信息等，尽量的考虑到他/她认为应该考虑的场景和功能交互，从而设计用例。测试执行人员为了尽可能的测试全面，经常变换组网环境、参数配置，试图尽大程度的减少漏测，这可能是很多测试团队的现状。

　　某一个阶段的测试结束时，测试人员如何评价这个特性的测试质量呢？毫无疑问，尽管测试设计人员和测试执行人员精疲力尽的试图覆盖所有的场景，测试人员仍然只覆盖了一小部分的场景下的该特性的部分测试用例，如果没有Fatal的遗留问题，是否可以评价为A或B，并且认为可以对外发布了呢？这个问题经常困扰着很多测试人员。我们不知道针对这个被测特性的“测试全景图”，从而评判出我们的测试已经覆盖了X%；即使知道了这个数据，也不清楚这样的测试覆盖和测试结果是否可以达到“对外发布”的标准。