3.3 软件确认过程中常见问题及案例分析
软件确认过程是以往软件工程中讲述不多的内容，但在软件研发过程中很多产品质量缺陷、项目进度偏差、项目成本偏差都是由于确认工作没有做好而导致的。以下通过几个案例来对它进行深入分析。
图3-4 软件确认的执行过程
3.3.1 为什么开发和测试之间总是反复
【案例】
最近某软件公司GIS项目组负责人小黎头痛不已，项目已经进展到系统测试阶段，软件开发人员提交给测试组的产品总是无法通过系统测试，甚至一天出现两三次产品内部的发布，软件开发和测试人员都被加班压得透不过气来。软件开发和测试人员之间的埋怨也越来越多，开发人员认为软件测试人员在挑他们的毛病。软件测试人员总是觉得产品质量实在太差，还没有怎么测试系统就不能使用，这样的产品就不应该发布。可是软件开发人员却认为他们做过了单元测试和集成测试，所以提交的产品质量是合格的。
项目负责人小黎觉得这个问题必须尽快解决，开发与测试之间的反复已经导致项目延期了一周的时间，以这样的情况发展下去还有可能恶化。更重要的一点是项目团队成员之间出现了矛盾，软件开发和测试人员之间已经越来越缺乏信任，这样下去将导致项目彻底崩溃。
【分析】
项目负责人小黎找到项目总监张经理，希望得到他的帮助。项目总监经过对项目组成员的访谈以及实际查看了项目的代码后，发现项目组发生的问题都是因为没有对工作产品进行确认而导致的。
本着“亲兄弟明算账”的原则，软件开发人员必须证明他们提交的工作产品已经符合了质量的要求，软件测试人员也要确认开发人员所讲的是否是真实的。公司已经规定了单元测试代码平均覆盖率至少为60%，集成测试用例代码平均覆盖率至少为45%，那么确认的准则已经存在，就应该按照此准则进行确认。
小黎按照张总的要求对项目组下达了对每次发布必须进行确认的任务，这下产品内部的发布戛然而止，原因是开发人员注意到他们的单元测试用例和系统测试用例很多都是重叠的，代码覆盖的比例达不到公司的要求，因此他们需要增加新的测试用例。在随后的日子中通过增加单元测试用例和集成测试用例又发现了很多产品质量的缺陷。
通过采取对工作产品进行确认后，产品只经过了两轮的反复就通过了系统测试，而且开发和测试人员之间的矛盾也大大降低了。
3.3.2 确认是对需求变更的约束
【案例】
某软件公司人力资源管理系统的项目经理小白非常开心，因为他的项目已经顺利通过验收。虽然项目过程中发生了一大一小两次需求的变更，但是项目的进度、成本并没有发生什么偏差。公司领导让小白对他的项目进行总结，并且将心得体会与其他项目组成员进行分享。小白在他的项目经验总结中就提到了一点：“需求的确认工作是对需求变更的约束”。
【分析】
小白在项目需求调研阶段就把《软件需求说明书》拿出来让客户进行了确认，客户通过对需求说明书的评审了解到他们所提出来的内容已经完全包含在《软件需求说明书》中，由于《软件需求说明书》的内容非常细致，因此客户对本次合作充满信心，所以很痛快地就进行了确认。但在设计和编码开发阶段分别发生了一次需求的变更，主要原因是客户方忽略了一些需要实现的功能而没有告诉项目组，但是客户又对《软件需求说明书》进行了确认。由于第一次变更的影响不大，小白决定免费为其进行修改，并且将变更后的《软件需求说明书》给客户进行再次确认，客户对小白的工作态度非常满意。
当在编码阶段发生再次需求变更时，小白将变更的影响告知了客户，并且提示客户方已经先后两次对需求进行了确认，希望可以对此次变更增加相应费用。客户方的代表也觉得自己有一定责任，所以就相应延长了项目的时间并增加了项目的费用，直到最后项目顺利交付。
因此小白在本次项目中最大的收获就是体会到软件确认管理给项目需求变更带来的好处。
3.4 小结
软件确认管理可以使软件研发“流水线”前、后环节中的操作人员增加彼此之间的信任感，而减少互相间推卸责任的理由。软件确认管理可以确保软件生命周期中的每个阶段都按部就班地开展工作，避免了外界或人为的因素而导致项目出现混乱，它是让项目“冷静”下来的重要手段。
3.5 思考题
1．软件确认的准备工作有哪些？
2．常用的确认方法有哪两大类？
3．确认是如何来提高团队合作信任感的？
（未完，精彩待续）
本文选自《51Testing软件测试作品系列》之六——《软件质量管理指南》。
本站经电子工业出版社和作者的授权，近期将进行部分章节的连载，敬请期待！
版权声明：51Testing软件测试网获电子工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
相关阅读：
