就使得产品线的测试要比单独的产品测试要复杂得多。产品线测试的关键在于重用测试用例
和测试件（

Testwarc，指测试工作形成的产品），而不是将产品线中的每个软件作为一个

单独的产品来进行测试。

 

　　

2.1 软件产品线测试 

　　产品线测试关系到多个方面，包括回归测试、非完整性项目测试和有效使用可重用的测
试资产等等。回归测试是用来确认前期可正常工作的组件在面临某些修改时，是否还能正确
运行。产品线中的成员在共享许多共性特征的基础上又各自变化，因此回归测试适合于产品
线或重用情况。与单个系统开发项目不同，测试也是可以重用于大多数产品中的活动，它本
身产生可重用的核心资产。建立可重用的测试资产能使产品线测试拥有较高的成本效益比。

 

　　产品线测试也需要详细规划并给出一个明确定义的过程，把测试集成到过程的每个阶
段，以生产出高质量的产品。在产品线中组件被大量重用，有效的故障修复显得尤其重要。
领域工程中的缺陷使风险演变为问题，因为可重用资产中的缺陷蔓延到重用它的每个产品
中。然而在软件产品线方法中，测试不能很好地区分领域工程和应用工程任务。虽然根据

V

模型进行测试，但

ISAPS、CAF 和 SEI 提出的框架还是不能完全将 V 模型测试的各个阶段

集成到软件开发中去。在实践中，将测试过程集成到整个产品线过程中被证明是最棘手的问
题。

 

　　产品线测试的主要问题可以从两个方面来进行论述。在领域工程中测试核心资产时，测
试者试图减少应用测试，但却很难保证软件在不明确的用例情景下都正常运作；产品线中
的成员在共享许多共性特征的基础上又各自变化，测试者发现根据

V 模型进行集成和系统

测试并不可行。而在应用工程中，在核心资产和其它应用测试的基础上，测试者想使充分测
试特定产品的费用最小化，但很难确定哪些已有测试结果是可以利用的，哪些产品测试是
必须进行的。

 

　　

2.2 当前产品线测试状况 

　　目前产品线测试的工作重心主要放在验收和系统测试上。

 

　　但由于产品线中大量重用组件，因此它们的低级别测试（例如，单元级）也应该得到
保证。换而言之，当前的研究和实践主要集中在高级别的产品线测试上。假设传统的面向对
象的测试方法可以不做任何修改就用于产品线测试过程，那么这一假设存在许多疑点。例如，
目前尚不清楚将使用哪一种面向对象的测试方法以及如何将之用于产品线测试，更加不清
楚是否还需要新的、具体的产品线测试方法。

 

　　在基于框架的软件产品线测试方法中，应用框架是产品线的核心，在所有应用从它产
生之前就应该得到很好的测试。但是以框架为基础的产品线的实际测试中，往往没有使用产
品线的任何信息。例如，诺基亚的移动浏览器产品线是按照如下要求进行产品线测试的：
“产品线测试的复杂性要远大于单个软件产品的测试。必须测试在不同情景下的产品线。为了
控制测试的复杂性，应缩减单个产品的测试，取而代之的是对整个产品线的测试。这样才能
保证测试的简化以及产品质量

”。 　　2.3 软件产品线自动化测试及相关工具支持 

　　在软件产品线测试方法中，工具支持比在传统面向对象测试中更加重要。这是因为包含
数个相同体系结构的产品线测试规模要大于单个产品测试。当一个组织有几个产品线时，规
模的问题就更加突出。产品线的工具支持因使用可重用的测试资产可以减少费用，并且使复
杂的测试过程更易于管理。

 

　　现今有许多成熟的测试工具，但是产品线和框架测试缺乏有效的工具支持。通常这些工
具也能够应用于产品线的测试，但它们只适用于像单元测试这样低级别的测试。在产品线方
面，需要详细而精确的测试工具。测试工具应有效地管理可重用的测试资产。工具支持应从
测试执行和测试结果的分析扩展到集成产品线测试的整个过程。

 

　　目前赫尔辛基大学已经开发出

RITA 工具。RITA 是一个能覆盖所有领域的测试支持工