介绍
   KPA：Key Process Area。本文共有三部分：第一部分界定评估和测试内涵的范围。第二部分则解释为什么要开发这个独立的KPA。第三部分给出该KPA提案，包括概念、目标，执行承诺、执行能力、执行活动、度量和分析以及实施验证。最后将考虑如何与其他KPA集成，这包括确定该KPA的级别，以及对现有KPA的重新调整。
注意：关于“验证”和“确认”在ISO9000中有严格的定义。
 验证：通过检查和提供客观证据，表明规定要求已经满足的认可。“验证”强调的是“规定规格要求”
 确认：通过检查和提供客观证据，表明一些针对某一特定预期用途的要求已经满足的认可。“确认”强调的是“预期用途的要求”。
 验证的目的是证实设计阶段输出是否确保设计阶段输入要求；
 确认的目的是通过产品确认设计是否满足使用要求。
   验证的对象是设计输出文件，计算书或样品等；
 确认的对象是最终产品（样品）。
 验证的参与人员通常是设计部门；
 确认的参与人员必须包括使用者或能代表使用要求的人员。
 验证的时机是设计适当阶段，一般是设计阶段输出形成结果时；
 确认的时机是成功的设计验证后，一般针对最终产品，也可分阶段确认。

第一部分：

     测试与评价的定义（Definition of Evaluation and Testing）
     评价是对软件开发过程中产生的各种系统规格和模型进行的验证活动。测试则是一种基于机器的、对代码执行测试、确认测试的活动(Testing is the machine based activity of executing and validating tests against the code)。大部分组织对评价和测试的定义都相对狭义，一般是指对代码执行物理测试用例的活动(the activity of executing physical test cases)。事实上，很多公司甚至直到编码已经开始时才指定/安排测试人员。更有甚者，他们将这一活动的范围仅仅限于功能测试，也许有时做一下性能测试。
    在目前的CMM有关evaluation and test的描述中强调了这个观点，那就是软件的评价和测试要成为SPE KPA的一部分。在SPE KPA活动中，活动5、6、7，仅仅用了基于代码的测试作为例子，且只明确地提到了功能测试。其他类型的测试只是用一句非常含糊的话来指代： “…..保证软件满足软件需求 ”。
    另一方面，建造摩天大厦的人们，则远在砌第一块砖之前将评价和测试集成到了开发过程之中。通过建模来验证稳定性、防水性、照明布置以及电源的需求等等从而实施评价。而目前，组织所使用软件评价和测试方法就像是设计师一直等到大楼已经建成才进行测试，而此时的测试只是能确认给水和照明是否可以工作而已。
    CMM只是进一步将评价和测试的部分思想进行融合，采用一个特殊的评价技术来，这个技术就是CMM中的一个KPA：同行评审。这种做法意味着，在提交代码之前，唯一可干的评价就是同行评审，且已经足够了。事实上，对于一件事情的评价和测试的步骤包括：(1)定义完成/成功的标准；(2)涉及覆盖这些准则的用例并构造这些用例；(3)执行用例；(4)验证结果，包括验证所有的内容都已覆盖。同行评审只是提供了一个基于文档的测试机制。它既不能从根本上提供成功准则，也不能提供任何正式的手段来支持用例定义以用于同行评审中。同行评审本质上是主观的，因此，由于误解使程序员将缺陷引入产品，而到同行评审时，可能基于同样的误解，也使得人们无法发现这些缺陷。
    评价和测试必须贯彻在项目开发周期每一阶段的每一个交付产品的始终(A robust scope for evaluation and test must emcompass project delivable at each phase in the developement life cycle) 。它也必须考虑每个交付产品的每一个预期特性。而且必须包括每一个评价/测试步骤。下面我们看两个例子：评价需求和对一个设计的评价。
一个需求文档必须是完备的、一致的、正确的和清晰的。那么第一步就是基于项目/产品目标（即为什么要做这个项目的说明）对需求进行确认。这能够保证我们定义了正确的功能集。下一步评价就是遍历use-case场景走查各功能规则，如果可能的话，最好用screen prototype（可视原型、屏幕原型？）来作为辅助工具。第三步评价是有领域专家进行的对文档的同行评审。第四步是由非领域专家进行的正式的模糊性评审（他们无法读懂文档里的功能知识，这将帮助确保各种规则是明确定义的，而不是隐含定义）。第五步评价是将需求转换为布尔逻辑图。这可以鉴别规则之间的顺序问题，同时也能发现漏掉的用例(cases)。第六步评价是在CASE工具的辅助下进行的逻辑一致性检查。第七步评价是由领域专家进行的对测试脚本的评审，这些脚本是从需求导出来的。这种“?ite-size”（原英文不清楚）般的对规则的评审经常能够发现在需求评审中漏掉的功能缺陷。

    对设计的评价一样可以进行一系列补救。第一种评价是走查来自于需求的测试(One is walking tests derived from requirements through the design document)。另一评价是构建一个模型来验证设计的完整性（例如构造一个操作系统的资源分配模型来保证不会发生死锁）。第三种评价是建立模型来验证性能特征。第四种是将形成的设计与其他公司的现成系统进行对比，以确保在设计时进行的配置能够应付预期的处理规模和数据规模。
上面的评价只有一部分可以用同行评审来完成，没有一个是基于代码的。而且上边的例子中没有一个评价是穷尽的，必要时我们可以进行的其他评价。核心关键是我们生产一个交付产品（如需求文档），在我们能够正式称它是完备并可被下一开发步骤使用之前，我们必须基于预期/期望的特征对之进行评价。而进行这些评价需要比进行同行评审更加复杂的技术。
    这就是评价和测试的核心关键。一个特征的预定义集合，尽可能被明确定义，并能够根据一个可交付产品对其进行验证。例如，当你在学校，进行了数学测验，老师会拿你的回答与预期答案相对比。老师不会说你的答案看上去是合理的，或者他们比较准确。答案是9.87652，要么它对，要么不对。同时，老师也不会等到学期结束才对在课程早期交上来试卷的进行判卷，而在他们做出来之际就进行了测试。目前我们软件开发承担更加生死攸关的风险，而我们却是如此的不严格和不及时！
    这些应进行评价和测试的交付产品应包括需求规格，设计规格、数据转换规格和数据转换代码、培训规格和培训资料、硬件/软件安装规格、设备/工具安装规格、问题管理支持系统规格、产品发布支持系统规格、用户手册和应用程序代码等等。当然这并不是一个完整的列表。问题是你的项目生命周期中的每一个交付产品都必须被测试。
对于一个给定交付产品的评价和测试可能会延续项目生命周期的多个阶段。越来越多的软件组织开始从瀑布式模型向迭代式模型转变。例如，设计规格可能会经过三个迭代才能产生。第一个迭代定义体系结构—它是人工的还是自动的，是集中的还是分散的，是在线的还是批处理式的，是直接文件存储还是通过关系性数据库等等。第二个迭代则可能继续推动设计，来鉴别所有的模块和模块间的数据交换机制。第三个迭代则定义模块内部的伪代码。每个迭代都应当基于适当的特性来进行评价。
    评价和测试的类型必须是鲁棒的、坚固的。这包括对功能、性能、可靠性-可用性/实用性-可服务性、易用性、可移植性、可维护性和可扩展型的验证，但绝不仅限于此。
总之，每个阶段的每个交付产品必须通过正式的、训练有素的技术来对适当的属性进行评价和测试。

                                                           （To be continued）