软件测试中CMM与软件评价及测试
在CMM的发展进程中，曾经提议将软件评价与测试（Evaluation and Test）作为CMM的一个KPA加入到CMM中，虽然这一提议最终未获通过，但通过对这一提议的讨论，我们可以得到很多与软件测试相关的一些有益的东西。
一、软件评价与测试在整个软件生命周期中的作用
评价是对软件开发过程中产生的各种系统规格和模型进行的验证活动。测试则是一种基于机器的对代码执行、确认的活动。大部分组织对评价和测试的定义都相对狭义，一般是指对代码执行物理测试用例的活动。事实上，很多公司甚至直到编码已经开始时才指定或安排测试人员。更有甚者，他们将这一活动的范围仅仅限于功能测试，也许有时做一下性能测试。这种观点在目前的CMM有关评价与测试的描述中被进一步强调，这就是SPE，软件产品工程KPA。在SPE KPA活动中，活动5、6、7，仅仅用了基于代码的测试作为例子，只明确地提到了功能测试。其他类型的测试只是用一句非常含糊的话来指代：“保证软件满足软件需求 ”。
另一方面，建造摩天大厦的人们，则远在砌第一块砖之前就将评价和测试集成到了开发过程之中。通过建模来验证稳定性、防水性、照明布置以及电源的需求等等，从而实施评价。而目前，组织所使用软件评价和测试方法就像是设计师一直等到大楼已经建成才进行测试，而此时的测试只是能保证给水和照明可以工作而已。
CMM只是进一步将评价和测试的部分思想进行融合，用一个特殊的评价技术来代替，这个技术就是CMM中的一个KPA，同行评审。这也意味着，在提交代码之前，唯一可干的评价就是同行评审，且已经足够了。事实上，对于一件事情的评价和测试的步骤包括：(1)定义成功准则；(2)涉及覆盖这些准则的用例；(3)执行用例；(4)验证结果，验证所有的内容都已覆盖。同行评审只是提供了一个基于纸面的测试机制。它既不能从根本上提供成功准则，也不能提供任何正式的机制以支持用例定义以用于同行评审中。同行评审本质是主观的，因此，基于误解使程序员将缺陷引入产品，而到同行评审时，基于同样的误解，也使得人们无法发现这些缺陷。
评价和测试的一个相对坚固的内涵范围必须包括项目在开发周期每一个阶段的每一个交付产品。它也必须考虑每个交付产品的每一个预期特性。而且必须包括每一个评价/测试步骤。下面我们看两个例子：评价需求和对一个设计的评价。
一个需求文档必须是完备的、一致的、正确的和清晰的。那么第一步就是基于项目/产品目标（即为什么要做这个项目的说明）对需求进行确认。这能够保证我们定义了正确的功能集。下一步评价就是遍历use-case脚本走查各功能规则，如果可能的话，最好用一些原型工具（screen prototype）作为辅助工具。第三步评价是有领域专家进行的对文档的同行评审。第四步是由非领域专家进行的正式的含糊性评审（他们无法读懂文档里的功能知识，这将帮助确保各种规则是明确定义的，而不是隐含定义）。第五步评价是将需求转换为布尔逻辑图。这可以鉴别规则之间的顺序问题，同时也能发现漏掉的用例(cases)。第五步评价是在CASE工具的辅助下进行的逻辑一致性检查。第七步评价是由领域专家进行的对测试脚本的评审，这些脚本是从需求导出来的。
对设计的评价一样可以进行一系列补救。一个是对照需求对设计文档进行走查。另一评价是构建一个模型来验证设计的完整性（例如构造一个操作系统的资源分配模式来保证不会发生死锁）。第三种评价是建立模型来验证性能特征。第四种是将形成的设计与其他公司的现成系统进行对比，以确保所设计的配置能够处理预期的处理规模和数据规模。
上面的评价只有一部分可以用同行评审来完成，没有一个是基于代码的。而且上边的例子中没有一个评价是穷尽的，必要时我们可以进行的其他评价。关键是我们输出一个交付产品（如需求文档），在我们能够正式称它是完备的并可被下一开发步骤使用之前，我们必须基于预期的特征对之进行评价。而进行这些评价需要比进行同行评审更加复杂的技术。
这就是评价和测试的关键所在。一个特征的预定义集合，尽可能被明确定义，用来对一个交付产品来进行确认。例如，当你在学校，进行了数学测验，老师会拿你的回答与预期答案相对比。老师不会仅仅说他们看上去也是合理的，或者他们更加准确。答案是9.87652，要么它对，要么不对。同时，老师也不会等到学期结束才将在课程早期交上来的进行判卷，在他们做出来之际就得到了测试。目前我们软件开发承担更加大风险，难道我们还可以有任何的不严格和不及时吗？
这些应当进行评价和测试的交付产品应当包括需求规格说明书，设计规格说明书、数据转换规格和数据转换代码、数据库设计说明书、培训资料、硬件/软件安装规格、用户手册和应用程序代码等等。当然这并不是一个完整的列表。问题的关键是，在你的项目生命周期中的每一个交付产品都必须被测试。
对于一个给定交付产品的评价和测试可能会延续项目生命周期的多个阶段。越来越多的软件组织开始从瀑布式模型向迭代式模型转变。例如，设计规格可能会经过三个迭代才能产生。第一个迭代定义体系结构—它是人工的还是自动的，是集中的还是分散的，是在线的还是批命令式的，是直接文件存储还是通过关系性数据库等等。第二个迭代则可能继续推动设计，来鉴别所有的模块和模块间的数据交换机制。第三个迭代则定义模块内部的伪代码。每个迭代都应当基于适当的特性来进行评价与测试。
评价和测试的类型必须是鲁棒的、坚固的。这包括对功能、性能、可靠性-可用性/实用性-可服务性、易用性、可移植性、可维护性和可扩展性等的验证，但绝不仅限于此。
总之，每个阶段的每个交付产品必须通过正式的、训练有素的技术来对适当的属性进行评价和测试。
二、在CMM中为什么要加入这个独立的KPA
由五个重要方面能说明必须有一个独立的软件评价与测试的KPA，即：
(1)评价和测试在促进向有纪律的软件工程过程过程的文化转变中的作用；
(2)评价和测试在项目跟踪中所起的作用；
(3)整个开发和维护在评价和测试部分的预算；
(4)评价和测试训练对软件交付时间和成本方面的影响；
(5)评价和测试对软件残余缺陷的影响。
将软件工业从一种手工(艺)匠方法向真正的训练有素的工程层次迈进实在是一种文化的转折、跃变。CMM的首要的而且也是最重要的目标是，建立一种机制来推进向软件工程的文化改变。但是一个文化不可能发生激烈的改变，除非你深刻理解改变的重要性。必须全面理解向新的文化改变所能给我们解决的问题。最后这一点，将使我们引导我们来讨论测试在这一加速向训练有素的文化改变中所起的作用。
在1960年代后期，IBM是第一批开始应用正式软件工程技术的组织之一。一开始使用的是Dijkstra支持的技术。具有讽刺意味的是，并不是由软件开发人员发起这项努力的，而是软件测试人员。这一创始性工作是在Poughkeepsie实验室进行的，属于Philip Carol领导的面向测试的设计项目。
Phil是软件测试技术工作组(SW Test Technology Group)的一个系统测试工程师。这个工作组主要负责定义软件测试技术和工具以用于整个公司。大概在30年以前，他们就开始意识到你不可能通过测试将质量注于代码中。你需要像考虑测试过程一样也得考虑分析、设计和编码过程。作为测试人员，由于测试需要接触软件开发的所有方面，他们对问题有更加彻底深入的理解。
正是这一对问题的深入认识并将这一问题明确有力地向开发人员指出推动了软件开发文化的迅速改变。随着改进的开发和测试技术的应用，IBM的OS操作系统的缺陷率在下一个发布降低了1/10。这确实是在短时间内产生的重要的文化变革，特别是这涉及到了分布在不同地域的近千名软件开发人员。
这种变化的加速除了对问题的重视的直接推动外，另一个推动因素是与测试有关的一些因素，即在测试过程和开发过程集成中的反馈环。随着开发过程的不断改进，评价和测试过程并行地改进以反映新的成功准则。随着开发不断使用新技术，他们直接从测试人员那里得到及时的反馈即他们究竟做的怎么样，因为测试人员就是专门基于新的尺度对交付产品进行确认的。
一个具体的例子是需求撰写改进技术的应用，需求必须是明确的、确定的、逻辑上是一致的、完备的、正确的。有关结构化分析方法和面向对象的方法的培训课教系统分析员如何来写一个好的需求。如果在他们刚刚写完第一个功能描述时就进行模糊性评审，那么他们写的下一个功能就会更加清晰明确。这种紧凑的反馈环—写一个功能、评价一个功能，有效地加速了其学习曲线。这样的话，过程从缺陷检测到缺陷预防转移的相当快速----他们正在写着清晰、不模糊的规格。
将这些经验与我们的整个软件工业做一个对比，结构化设计技术和面向对象的技术已经在25年前就可以应用了(是的，OO确实已经那么老了)，然而我们的时间的情况却远远落后于这些方法的最新技术发展水平。问题是除非组织理解了正在解决的问题，否则它不会全面接受或者全面理解一个解决方案（如：软件工程方法和技术），而集成的评价和测试正是问题理解的杠杆和关键。这里“集成评价和测试”被定义为将测试集成到软件过程的每一步中，它也是为掌握一个技术所需的必要的反馈环的关键部分。任何没有紧密反馈环的过程是具有致命缺陷的过程，因此评价和测量是加速文化改变的关键。
一个项目计划一般包含任务、关联、资源、进度、预算和假设等等。每个任务都应当输出一个良好定义的交付，且必须对交付产品进行验证以证明该交付产品是确实是完备的。如果你对任务输出的完备性进行评价和测试，那么你不可能准确地跟踪项目的真实的状态。
在决定一项实践应不应当是独立的KPA时，一个重要的实效因素是它在软件开发活动的预算和人员投入中所占的比重。如果在这方面越显著，那么它应当受到的关注应当越多。而软件测试在整个软件开发中所占的比重在一半左右。
集成评价和测试可以支持更多的活动并发从而进一步缩短进度。如果需求没有得到正式评价，就常会导致设计和编码活动产生对早期提交的功能范围和定义的大量修改。正是基于这一原因，用户手册和培训手册等工作直到对代码的测试都差不多了的时候才能开始。到那时，几乎没有人会对早期的系统定义有什么信任。
同样，没有很好定义的需求也不能提供足够的信息来支持测试脚本的设计，因此测试用例的设计和构建也只能等到编码做得差不多的时候才能开始。
根据这两种情况，可以得出目前开发过程是线性的：先需求、然后是设计、编码、接着是测试、编写用户手册。如果写的需求规格能够达到一个确定级的详程度(即：给定一个输入集和一个系统初始状态，你应当能够按照规格中的规则准确地确定输出和新系统的状态)，那么测试用例的设计以及用户手册的编写就可以和系统设计并行执行。这样同时也就缩短了系统交付时间。关键是要对规格需求进行正式的评价活动。
从中我们看到在CMM中加入这个独立的KPA是很有必要的。
三、结束语
通过以上的论述我们看到，评价是对软件开发过程中所产生的各种系统规格和模型的集成性进行保证的活动，测试则是基于机器的对代码进行测试的活动。软件评价和测试的目的是确认(即：判断这是我们所要的吗？)和验证(即：这是不是正确？)每一个软件项目交付产品，并及时发现这些产品中的任何缺陷。
软件评价和测试包括识别需进行评价和测试的交付产品；确定需要执行的评价和测试类型；定义每个评价和测试的成功准则；设计、构建、执行所需的评价和测试；验证评价和测试结果；验证测试集全面覆盖既定的评价和测试准则；创建和执行回归库以用于在交付产品发生修改后进行重新验证；登记、汇报、跟踪发现的缺陷。
最开始进行评价的交付产品是软件需求，随后，大部分评价和测试是基于被确认的软件需求。
文章来源于领测软件测试网 https://www.ltesting.net/
