第3章软件质量管理的信任机制——确认

　　人们的日常生活往往离不开对各种各样的事情进行确认，例如：当使用信用卡的时候，服务员会要求顾客确认银联回执单上的金额，然后在上面签字；当顾客在银联回执单上签字后，服务员还要确认签字笔迹是否与信用卡上的相符；当一对恋人打算结婚的时候，他们都会去民政局进行婚姻登记，以在法律上确认他们的合法关系，当然在婚姻登记时也需要男女双方签字确认。

　　在软件研发过程中也离不开各种确认的工作，例如：甲乙双方签订合同时，要对合同上的金额、完工时间、项目范围等内容进行确认，确认后要双方签字、盖章；当需求人员在完成《软件需求说明书》后，为了减少需求的变更，往往也会给客户进行确认。

　　由此可见，确认是一种行为，该行为的方式有很多，既可以通过口头方式进行确认，也可以通过书面形式进行确认。确认的深层含义是承诺，换句话说一个人的承诺是通过确认的方式来体现的。例如：顾客不在银联回执单上签字，那么就代表顾客否定了本次交易，这是一种相反的承诺，那么银行就会按照顾客的这种承诺拒绝付款给商家；当一对恋人没有进行婚姻登记，那么在法律上也就没有给彼此一个共同生活的承诺，因此他们还有权力选择他人；在软件研发过程中如果客户没有对《软件需求说明书》的内容进行确认，也就是他没有给出承诺，那么再发生需求变更时他也不会感到愧疚。

3.1 软件确认管理的概述

　　确认（Validation）简称VAL，确认管理是软件工程体系中的一名新成员，它与配置管理、风险管理、度量管理等分支同等重要，是软件质量体系中不可或缺的环节。

　　确认是指对软件研发生命周期中某个过程所产出的工作产品进行的审查，这些工作产品可以是《软件需求说明书》、合同等文档，也可以是开发出来的组件或最终产品，甚至可以是对某个生命周期阶段进行的整体审查。

　　确认的目的就是确保某个过程或阶段“做对的工作产品”，并使它符合使用者的期望，并且只有通过审查后的工作产品才能交付给“使用者”使用。

　　在软件研发过程中有两个重要的确认过程是众所周知的，一个是“客户”对《软件需求说明书》的确认，另一个是项目组开发出来的最终产品要在客户现场进行验收测试，以确认该产品是否符合“客户”的需要。这两个确认都是针对客户方的，但是在确认管理过程中却是不使用“客户”两个字的，而用“使用者”来代替“客户”，这是为了避免广大软件从业人员对确认过程的误解。《软件需求说明书》是软件项目范围的依据，它用来描述软件产品的功能，软件产品的最终“使用者”就是“客户”；验收测试的目的就是确保产品达到“客户”也就是最终“使用者”的要求。但在软件确认管理中并不是只有“客户”才需要对项目的工作产品进行确认，项目组或公司内部同样需要对某些工作产品进行确认，而这种确认往往非常关键，但进行确认的人却不是合同的甲方，因此在软件确认管理中要用“使用者”这个名称来对它进行代替。

　　那么什么时候才会出现项目组内部的确认呢？很多人对这个事情都有疑问，这是可以理解的，因为在早期的软件工程中谈及确认管理的内容是非常少的。但项目组内的确认工作是天天都在进行的，例如：对《概要设计》文档进行评审并且合格通过后，与会人员都会在评审记录上签字。这个过程中就“包含”了确认的内容。但有人又会说同行评审是“验证”的过程，怎么会包含确认的内容呢？大家可以想想，首先确认的目的是承诺，那么签字就代表了与会人员对《概要设计》文档的正确性进行了承诺。其次参加本次评审的人员中一定会有软件开发人员，软件开发人员将是这份《概要设计》文档的“使用者”，只有“使用者”对该工作产品的质量进行确认后才能被使用。因此，在对《概要设计》文档进行评审时，这个过程除了对《概要设计》文档的内容进行验证，与会人员中的“使用者”还要对其内容是否符合要求并且是否可以指导软件开发人员的工作进行确认。

　　由此可见，在软件生命周期内凡是一个环节“输出”的工作成果都将成为后续环节的“输入”，那么上一个环节的生产者要承诺该工作产品是符合质量要求的，后续环节的“使用者”也要对其工作产品进行确认。这就好比“亲兄弟明算账”，通过这样的方式来建立相互间的信任关系。

（未完，精彩待续）

本文选自《51Testing软件测试作品系列》之六——《软件质量管理指南》。

本站经电子工业出版社和作者的授权，近期将进行部分章节的连载，敬请期待！

任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。

相关阅读：