在嵌入式软件开发过程中应用验证与确认（上）


 每个产品都会有缺陷，在开发过程中应争取尽早发现缺陷，开发的时候提高软件质量要远比开发完成后再进行测试更为有效。验证和确认技术可用于整个产品开发周期中，能确保所制造的是正确的产品，同时产品是在按正确的方法制造。本文介绍验证和确认基本原理和技术，并讨论如何成功地将这类技术应用于高质量嵌入式软件开发过程中。 

对软件开发而言，一般所谓的“质量保证”是指在产品完成后对其进行测试和检查，但实际上这能“保证”什么呢？当然，在适当授权下可以确保不让不合格产品出厂，然而这样能够保证最初制造的产品就是一个合格产品吗？恐怕不行。 

更进一步的问题是：能将质量测试融入产品中去吗？当然只需要让所构建的测试标准非常严格，就能有效控制不合格产品(幸好还能构造这样一个测试标准)，即可有系统地拒收任何未能通过测试的产品。这一做法背后的理论是开发人员最终会懂得应该开发合格的产品，并将改变他们的工作方法。其实这不仅是改进软件流程所独有的现象，也是目前软件开发公司共同面临的问题。 

如果制作的软件是用于嵌入式系统则情况更为严重。当你将控制软件烧录到ROM并放入器件中，然后装运到成千上万的用户手中时，你肯定希望对这个软件本身的质量有一个深入的了解；当宇航员登上发射台，将他们的生命寄托在控制宇宙飞船计算机的软件上时，更是要求软件一开始使用就能正常工作。 

是的，测试是需要的，但测试的产品在最初制造时就必需达到一定的质量水平，特别当产品是某种嵌入式系统时更是如此。Boris Beizer在1984年出版的一本有关测试的书《软件系统的测试与质量保证》中非常有趣或者说恰如其分地表达了这个概念。他说：“要想得到高质量软件，你所能做的最重要的一件事就是将质量设计到软件中。这比如何设置质量保证部门、向谁进行报告、什么是独立测试、需要进行什么样的评审等事情重要得多，它比本书全部内容、整个软件测试技术以及将来出版的十本有关软件质量保证的书都更重要。” 

我们完全同意质量必需设计在软件中这一观点，但如何判定质量在最初是否融入到设计中了呢？一个重要的思路就是要在整个产品开发周期中始终注重质量，从提出要求直到第一个产品发运的整个过程。 

要想在软件开发的每个阶段都注重质量需要有一个流程进行管理，大多数软件流程改进模型(像CMM和ISO 9000)都认为有效和正确的流程必然会导致生产出高质量软件。 

Ian Sommerville在1995年出版的《软件工程学》第5版中写道：“关于质量管理有一个潜在假设，即开发流程的质量将直接影响出厂产品的质量，该假设来源于产品质量与生产工艺流程直接相关的制造系统。” 

虽然对生产软件和制造钢铁是否类似这一点存在争论，但假如有两种方法，一种是可重复的常用流程，并从一开始就注意质量，而另一种随便用一些编程人员制造产品，然后进行测试直至其可以工作为止，显然前者更有可能制造出高质量的软件。正如Peter Coffee所讲，“质量不是一种能添加到已有产品中的特性，质量是一种流程，它从产品设计开始一直延续到产品卖出为止。” 

我们相信有效的流程肯定能制作出一开始就能正常工作的高质量软件。下面先介绍缺陷管理的基本原理，然后讨论软件在产品开发周期中的验证和确认，特别是验证和确认所采用的评审、检测和测试技术。 

缺陷管理 

软件中一般会有问题和缺陷，其实这都是一些由开发人员造成的软件错误，这些缺陷实际上在开发过程从提出要求到进行维护的任一阶段都可能造成。假如适当条件永远不发生而没有触发执行有问题代码的话，缺陷就将隐藏下去，否则它们会暴露出来而造成失效。失效的严重程度不尽相同，最坏情况下失效可使系统崩溃或者系统功能不正常，而轻微时失效仅仅使用户感到不方便或不满意而已(如响应时间太慢或者接口使用困难等)。 

当然还是应该尽量避免缺陷，关于缺陷管理有两个指导性原则。首先，在最初阶段就要避免造成缺陷，可以通过在产品开发周期每个步骤都使用正确技术做到这一点。例如许多缺陷实际上在提出要求时就产生了，然而几乎没有软件工程师接受过关于这一重要阶段的任何正式培训。有效提出要求可以避免出现大量缺陷，同样原则也可以应用在产品开发周期的其它阶段。 

我们知道，即使尽最大努力产品总还是会有缺陷，所以第二个原则就是在流程中尽可能早地检测出缺陷，一旦检测到就要从源头处把它消除掉。这就是说如果缺陷是在低层设计中造成的，就应在此时把它消除，最好在编码开始前；如果缺陷是在提出要求时造成的，则应在这里消除，最好在高层设计开始之前。 

时间拖得越久，消除和修复缺陷的费用就越高。研究指出，缺陷在产品开发周期晚期发现其消除的费用将会急剧上升。为避免缺陷，需要针对软件开发每一阶段的特殊技术进行培训。 

验证和确认的焦点是缺陷形成后尽早检测出来并从源头处把它消灭掉，这样做不仅去除缺陷的费用更少，而且能为我们提供充足的信心，使我们相信质量已被制造在产品中，而不是直到装运前才将高质量产品筛选出来。 

验证和确认 

验证和确认(一般又简称为V&V)可以回答两个根本的问题，即是否是在制造正确的产品以及是否在按正确的方法制造产品。大体来讲，确认与制造正确的产品有关，验证则与按正确的方法制造产品有关。 

下面一些释义清楚地表明了所谓制造正确的产品和按正确的方法制造产品两者的含义，之后我们将对验证和确认的定义作一个小结。 

◆释义1 确认是“根据用户要求判断所开发的最终程序或软件的正确性，一般通过对软件开发周期每个阶段进行验证完成”。验证则是“软件开发周期各阶段中以及各阶段之间软件的一致性、完整性和正确性情况。”(《Computing Surveys》杂志1982年第六期p159～192) 

上述释义指出，确认主要关心最终产品是否满足要求，而验证关心的则是开发各阶段与它相关阶段之间的变换和跟踪性能。另言之，它表明设计可以显示出对要求理解的正确性，该解释还认为确认一般通过对每个阶段进行验证而得到。 

◆释义2 “验证就是在每一阶段对软件进行评估，以保证它符合前一阶段所提出的要求；而确认则是在开发工作完成时对软件及其技术指标规范进行测试，以保证软件符合总体要求。虽然‘验证’和‘确认’有不同的含意，但将两者结合起来看作一个整体有很多好处。”(《IEEE Software》杂志1989年第五期) 

该释义认为确认在本质上就是我们一般所谓的“系统测试”，用来评定最终产品是否符合最初的要求，然后再进一步将这两项“结合”起来形成V&V。我们觉得这种方法仅仅是因为两者都以字母V开头而方便地合在一起，这样做会失去二者内在的许多区别。 

◆释义3 “软件测试是一个大题目的一个组成部分，通常称为验证和确认。验证就是为保证软件正确执行某一特定功能所进行的工作，而确认是保证所开发的软件符合用户要求。”(Roger S Pressman《软件工程学》第四版p488) 

最后的这个释义来源于大学教科书，所以比前两个要简单一些。关于确认的定义还勉强可以，但验证的定义太过简单，验证的内容比正确执行功能还应该多一些。 

在本文中，我们用“确认”表示那些判定产品是否满足用户要求所做的工作。它包括可用性测试或其它类型用户反馈，也包括对要求文件的检查以及评定什么样的要求已被有效执行，还可以包括根据最初用户要求对最终系统进行测试看这些要求是否已被满足。因此，确认能有助于得知我们是在制造正确的产品。我们用“验证”表示在产品设计周期每一步所进行的转换工作，换句话说，即从用户要求的技术规范完成高层设计。设计文件完成后，可根据要求进行“验证”，这时可以发现缺陷并予以纠正，然后用高层设计验证其下的低层设计文件。这一验证过程可用在开发过程的每一阶段，从根本上来讲包括每一个文件或其中间产品，除了已谈到的文件外还包括源代码、内部文件、用户文件、测试方案和测试技术规范等。 

对系统进行确认的最常用方法是测试，其它几乎没有什么选择。此外，如果你有一个精确的要求文件和一个功能性系统，那么按步骤运行系统看它是否符合给定要求非常有效。但如何评定文件的质量呢？这就没那么直接了，最容易的办法是阅读并进行讨论，看它是否能追踪至由此引出的文件，这个过程很大程度上属于评审和检测的范畴。 

评审和检查 

有人说技术工作需要进行评审就如同铅笔需要橡皮擦一样，因为人总是要犯错误的。只要每个阶段都有文件，就可以在开发过程的各个阶段进行评审，如果软件开发时没有定出精确要求，则根本不可能通过评审或其它方法验证设计是否准确，因为此时设计不是根据要求做出而是孤立的，任何对缺陷的判定最终都是个人观点。因此评审和检查首先假设软件开发过程已有严格的要求。评审每个开发阶段的中间产品有两个基本作用。首先，我们能在早期检查出缺陷并在修改费用较低时将其消除掉；其次，这一点可能更重要，我们能够在公司内部改变流程，在软件开发最初阶段就提出大量的严格要求。如果管理层在评审上投机取巧，则到时候可以清楚地看到没有好的要求(或者好的设计)评审就不会带来什么价值。 

评审一般由一个小组的人员共同观察同样的产品或开发对象。为什么要有不同的人员参加呢？这和一个作家在一篇文章会漏过多处打印错误，而一个审稿编辑却很容易看出来的道理一样，我们所有人都有盲点。虽然人们能发现一些他们自已的错误，但我们还是需要做技术评审，因为大的错误很容易从原开发人员眼里漏过而不容易从其他人手中放过。 

尽管有很多优点，这种评审还是面临一些困难，有一些来自于社会。对于有的人来讲，将一个一直在私人领域的工作产品拿出来由其他人评审这种做法难以接受。有鉴于此，这类会议的范围应仅限于少数人员，并且所有参加人员都应该经过培训，从而避免产生负面影响。 

评审功能可作为质量过滤的一种形式用于软件开发各阶段，其目的是尽早发现错误以使产品更加完善。评审主要想得到如下结果：·指出产品中需要改进之处 ·确认好的部分 ·使产品在编码方式、文件样式、设计方法等方面更加一致，以便技术工作能更好地进行管理 ·改进软件开发过程。 

评审有很多形式，有非常正式的也有极其不正式的。在最正式的情况下，有许多人参加(尽管大家都很清楚参加的人太多将会降低效率)，此时要耗费大量公司资源，需要复印很多文件使每个人掌握的资料都一致。另外一个极端是非常不正式的聚会，但还是在进行评审，只有一两个人在一个小房间中进行，就像是简单地请一个工程师来帮助另一个一样。 

我们一般把不太正式的会议称为“排演”，由一组人来评审产品，在这类非正式会议中很少有什么规定，经常会偏离正题，常常跳到问题解决模式中去。这种聚会在正确的环境下也能起到很大作用。 

我们将很正式的会议称为检测，这时参加的人员都有指定的角色，会议有特别的规定，而且要求很严格，特别在涉及一个产品对其前期产品的追溯性时更是如此。(待续） 

作者: Charles D. Knutson博士 
助理教授 
杨百翰大学 
Email：knutson@cs.byu.edu 

Sam Carmichael 
验证工程师 
Micro Systems Engineering 
Email：carmicha@biotronik.com

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。