第9章 黎明之前最后的冲刺：成品测试
项目结尾时是小艾最能感受到成就感时，总结一段时间以来的项目经验，总会有很多收获。小艾非常享受这种学习与收获的过程。但是，明明测试和开发已经完成了，距离计划发布日还有一段时间，这段时间要做什么呢？
9.1 产品包装成金蛋，手握光碟抓虫子
这两天小艾明显感觉到项目团队的气氛紧张。项目经理凯文和各团队主要负责人每天都神色凝重地在会议室激烈地讨论着什么。这又勾起了小艾的好奇心。
9.1.1 成品测试全体总动员
他问身旁的凯文：“现在我们的各方面测试都基本完成了，不是应该松口气庆祝了吗？怎么领导们看着比以前还紧张，是出什么问题了吗？”
凯文拍了一下小艾的肩膀答道：“知道什么是黎明前的黑暗吗？这就马上到最后的冲刺--GMV测试阶段啦。”
小艾一头雾水地问：“什么是GMV？”
凯文看小艾很迷惑，就放下手头工作，给小艾认真讲解起来。
凯文的话：
GMV是Golden Master Verification Test的简称，也就是我们通常说的成品测试或介质测试。它的测试目的是保证客户拿到的成品没有质量问题。从软件发布的角度来说，就是保障客户顺利安装并使用产品生产部门提供的光盘（CD或DVD）或网上下载的应用程序。
在GMV阶段构建团队会向测试团队提供DVD ISO文件和DVD光盘作为驱动，测试团队则使用这些介质来进行测试。GMV的另外一个测试目的是保证产品在前期缺陷修复过程中不会因为代码改动而产生新问题。
因为GMV测试的重要性及其在进度上的紧迫性，GMV测试阶段需要各个测试团队在已有的测试案例里有针对性地选择重要案例进行重新测试，以保证之前的代码改动不会为最终成品带来新的质量问题。切记不要在此阶段运行新的测试案例，以保证GMV能在合理时间内完成（一般2～4周）并成功交付给客户或投放市场。
小艾听了凯文的简单介绍，对GMV有了初步认识，但是对GMV具体计划和测试策略要点仍旧不甚了解。到底GMV需要怎么进行？而我们应该在GMV中做些什么呢？
小艾星期四刚到公司就接到项目经理发的通知，要求下午2点项目全体人员参加重要会议。
会议准时开始，凯文站在会议室前方扫视了下面一张张熟悉的面孔说：“这个时间召开此次会议的目的，我想在座的老员工都能猜出来吧？”
“不错，经过大约一年各团队的努力，我们已经到了最后的冲刺阶段。前两天和各团队负责人一起详细讨论了目前项目的进展情况。我很高兴地宣布明天将构建第一个成品候选介质！”
随后凯文站在放映机前，详细汇报了各测试团队到目前为止的测试结果。总体来讲，除了性能测试还有一些少量收尾工作，其他测试类别像功能测试、安装测试、产品迁移测试、多国语言测试等都已顺利完成，测试用例都已100%完成，通过率都达到甚至超过质量计划里所保证的百分比。失败的测试案例目前都有了解决方案，并在现有测试驱动上通过了补丁测试，按照计划，第二天下午4点前就能完成所有源代码改动。
会议最后，凯文凝重地说：“接下来两周的成品测试将是关键的一场战役，就像足球场上的临门一脚，关系着我们整个产品发布的成败。希望大家鼓足干劲坚持到最后的胜利！”
9.1.2 协同作战--成品测试特性
小艾听完凯文的讲话，对即将到来的成品测试充满了期待。但他还不是很清楚自己具体应该做些什么。会议结束后凯文找到小艾给他分配测试案例。小艾看了一眼测试案例，不解地问：“以往我们功能测试都是在已装好产品的机器上直接进行测试，这次为什么让我们自己安装产品呢？安装测试不是应该安装团队负责吗？”
凯文回答说：“你这个问题问得很好。由于成品测试的特性，成品测试有其独特的测试策略。它要求各团队协同作战，才能在较短时间完成所有测试任务。”于是凯文给小艾详细讲述了成品测试的特点。
项目经理凯文的话：
成品测试的一个主要目的是测试最终介质和包装有无缺陷，以保障客户拿到最终产品时能顺利安装并使用我们提供的光盘（CD或DVD）或网上下载的应用程序。对于不同操作系统平台或数据库，调用的安装程序和启动的包装有可能不同。这就要求在成品测试阶段，尽可能涵盖所有系统平台和数据库，以保障客户在不同系统上的正常应用。
对于数目繁多的操作系统平台（Window，AIX，Solaris，xLinux，pLinux，zLinux，iLinux等）和数据库类型（DB2，Oracle，Cloudscape等），安装团队是不可能在短时间内涵盖所有的，这就要求各团队协同合作。一般来讲，功能测试团队、构建团队、产品迁移测试团队和多国语言测试团队会用DVD或DVD ISO文件在较常见的操作系统平台上简单安装产品，并进一步进行功能或多国语言测试。安装团队会在此阶段着重测试一些复杂的安装路径和操作系统平台。
小艾听完凯文的解释，明白了成品测试阶段各团队协同作战的必要性。脱口而出道：“是不是人人都要手握光碟来抓虫子啊？”
凯文笑道：“比喻很形象，但我们除了传统物流方式销售给客户CD或DVD光碟，还允许客户通过网络下载我们的应用程序。一般会把DVD ISO文件经过压缩放到网络上供客户直接下载。所以除了测试真正的物理光碟，我们还要测试放到网上的可供客户下载的DVD ISO文件，即常说的电子版光碟。”
小艾点头说：“哦，我明白了。凯文，成品测试阶段测试范围是如何规定的？还有，它的测试策略又都有哪些呢？”
凯文说：“我很高兴看到你对成品测试的求知欲，我现在还要去构建团队安排一下工作。这样吧，我把各测试团队成品测试的计划发给你，那里面详细描述了各测试团队的测试范围和策略。你仔细看一下，有什么问题可以问我。”
9.1.3 取舍之间--测试范围和策略
小艾系统地阅读了凯文发给他的成品测试计划，并且根据各团队计划对成品测试阶段的测试范围和策略做了总体归纳总结。
成品测试范围及策略归纳总结：
成品测试的测试案例必须是以前测试阶段测试过的案例，不应该有新测试案例或对新系统平台设置的测试。
所被挑选的回归测试案例要尽量能够涵盖程序的主要功能，以确保程序的主框架没有由于前期代码改动而产生缺陷。
对于前期测试中发现较多问题并改动代码较多的功能部分，应多挑选一些回归测试案例进行回归测试。
性能测试一般选择最被广泛使用或者大型客户常用的平台。测试用例选择最简单的分支，但是尽量扩大分支覆盖的范围，一般选用可靠性测试（关于可靠性
测试的定义见6.2.4节），测试时间一般在24～72小时。
所有测试都应基于DVD或DVD ISO文件安装的应用程序，严禁再用构建测试环境来安装应用程序并进行测试。
安装应尽量涵盖应用程序支持的所有系统平台（Window，AIX，Solaris，xLinux，pLinux，zLinux，iLinux等），数据库类型（DB2，Oracle，Cloudscape等）和安 装模式（快捷安装，定制安装等）。
由于时间限制，成品测试案例大约占前期测试阶段所有测试案例的5%～10%。
除了各测试团队详细的测试计划，在凯文所提供的材料中，还有一份在测试中要求各测试团队统一检查的清单列表。清单列表里主要需要检查下列内容。
a、DVD布局
应按照产品构建团队提供的DVD布局文件里所列信息核对所测DVD光碟或电子光碟，布局一般包括：
不同系统平台的安装设置文件：setup.exe，setup_aix等。
不同支持语言的说明文件（readme）。
自动调用文件（AutoRun）：autorun.exe，autorun.inf等。
产品版本文件等一些和产品有关的文件。
除了核对布局里应存在的文件名外，还应该核对文件大小以保证文件没有损坏和缺失。整体DVD内容大小也是需要核对的一个数据。
b、产品安装
根据安装说明书和安装测试模式要求进行产品安装。
c、产品许可同意书
在安装过程中，检查产品许可同意书是否正确显示，并阅读上面所列内容是否正确。最重要的是要检查产品许可同意书里产品名称和版本号是否正确。
d、产品主要页面
安装成功后，根据测试的不同产品特性，浏览一下主要网页是否能够正确显示。
e、产品数据核心文件
产品中有些是产品信息核心文件，文件中的数据会被多个子程序引用。例如Product.xml中产品名称及版本号等。应检查这些文件是否安装在正确文件夹里，并打开文件，根据产品情况检查文件里面所列的信息是否正确。
f、产品构建号码
最终提供给客户的产品中一定要有产品构建号码并存储在一个产品文件中，以方便以后查询。这个产品构建号码一般以构建日期来命名。安装成功后，需要打开文件检查产品构建号码是否正确，以确定所测试的驱动版本是正确的。
g、数据库核心数据
一般产品都会有些核心数据存储在数据库里。可以根据情况列一些数据库查询语句在清单列表里，并要求各团队进行查询，以确保核心数据在安装过程中被正确引入到数据库中。
h、产品文档文件
对于每个产品来讲都会有文档文件，其中包括产品使用说明，产品问题帮助等。安装成功后，应检查一下这些文件是否被安装在正确文件夹里以确保能够被程序正确调用。
i、产品卸载
所有测试都结束后，应按照产品卸载说明书卸载产品。
9.1.4 争分夺秒--成品测试周期
GMV测试开始当天小艾很早便来到公司，看到各团队负责人都已在办公室里。凯文递给他一张DVD光碟，说：“这是构建团队周末烧刻的产品光碟，里面是上星期五的驱动。你今天的任务就是用DVD安装产品并完成上星期四分配给你的相应功能测试案例。所有测试必须在第二天下午4点之前完成，有什么问题吗？”
小艾问道：“如果没有发现任何新缺陷，明天上午就应能完成所有案例测试。如果真是这样，我是否就再也不用在新驱动上测试了？”
凯文说：“这需要视情况而定。就像我以前讲的，成品测试是各团队协同作战。一个团队的完成并不代表整体的完成。成品测试一般需要1～2周时间，对于每个驱动，大约需要2天完成。根据以往成品测试经验，大约需要构建3～5个驱动才能最终完成。对不同的驱动，由于周期短，时间有限，每个测试团队根据情况有自己的测试策略。并不是每个驱动都要重新测试所有案例。”
小艾稍后收到凯文的邮件，上面是各测试团队对不同成品测试候选驱动的测试安排。
功能测试：
在第一个成品测试候选驱动上2天内完成所有被选定的成品功能测试案例。
在接下来的成品测试候选驱动上，只运行功能测试可接受性案例和由于修正程序缺陷而可能受到影响的测试案例。
在最终项目组宣布的成品候选驱动上，重新运行所有被选定的成品功能测试案例。
安装测试：
在所有成品测试候选驱动上2天内完成所有被选定的成品安装测试案例（集群环境安装测试案例除外）。
在第一个成品测试候选驱动上，3天内完成集群环境安装测试案例。在以后的成品测试候选驱动上如果没有和集群环境相关的代码改动，就无须重新运行集群环境安装测试案例。
构建测试：
在第一个成品测试候选驱动上2天内完成所有被选定的成品构建测试案例。
在接下来的成品测试候选驱动上，如果无Java代码改动，则无须重新运行java API扫描。但需重新运行源代码扫描案例、版权扫描案例及SAR扫描案例。
性能测试：
在第一个成品测试候选驱动上3天内完成所有被选定的成品性能测试案例。
在接下来的成品测试候选驱动上，如果无性能相关的代码改动，则无须重新运行性能测试案例。
在倒数第二个成品测试候选驱动上，重新运行所有被选定的成品性能测试案例。
迁移测试：
在第一个成品测试候选驱动上3天内完成所有被选定的成品迁移测试案例。
在接下来的成品测试候选驱动上，如果无迁移相关的代码改动，则无须重新运行迁移测试案例。
多国语言测试：
在第一个成品测试候选驱动上2天内完成所有被选定的成品多国语言测试案例。
在接下来的成品测试候选驱动上，只运行多国语言测试接受案例和由于修正程序缺陷而可能受到影响的测试案例。
在最终项目组宣布的成品候选驱动上，重新运行所有被选定的成品多国语言测试案例。
定制测试：
在第一个成品测试候选驱动上2天内完成所有被选定的成品定制测试案例。
在接下来的成品测试候选驱动上，只运行由于修正程序缺陷而可能受到影响的测试案例。
在最终项目组宣布的成品候选驱动上，重新运行所有被选定的定制测试案例。
小艾看后挠挠头说：“这么复杂啊，每个测试团队对不同的成品测试候选驱动的安排都不太一样，完成时间也不尽相同，怪不得你要作为总调度来统筹安排。”
凯文笑了笑说：“各个团队对不同成品测试候选驱动的安排是基于测试类别的不同特性，其实解读起来不外乎以下几点。”
凯文对不同成品测试候选驱动测试策略的解读：
各团队必须完全测试第一个驱动，以后的驱动需要审时度势，看编码改动情况来决定测试范围。
由于每个驱动都需要重新构建打包，因此每个驱动都需要进行必要的安装测试和构建测试，以保障没有重要文件的缺失。
项目组决定的最终成品候选驱动，将会是客户最终拿到的产品。各测试团队尽可能在此驱动上重新完成重要测试案例，以防功亏一篑。
迁移测试和个别安装测试（例如集群安装）案例测试周期长，极少受由于其他类别测试缺陷而修改代码的影响。因此在整个成品测试周期一般只需要测试一遍。
由于大部分测试都会在两天内完成，为了有效缩短整个成品测试周期，第二个成品测试候选驱动会在两天后开始构建，而不必等待迁移测试和个别安装测试（如集群安装）案例测试结束。
小艾听了凯文的解读，觉得很有收获，深刻认识到成品测试周期的紧迫性，感觉各团队都是在争分夺秒来完成最后冲刺。于是他匆匆和凯文告辞，拿着DVD赶快到实验室开始执行分配给他的成品测试案例。
（未完待续）
相关链接：
一个软件测试工程师的成长日记（连载一）
一个软件测试工程师的成长日记（连载二）
一个软件测试工程师的成长日记（连载三）
一个软件测试工程师的成长日记（连载四）