中国工商银行股份有限公司数据中心(北京) 原普雨 霍嘉

　　伴随着软件测试大集中发展的趋势，国内外大银行建立了自己专职的测试单位，如花旗银行、中国工商银行、中国银行、中国建设银行等。如何评估软件测试团队的生产能力，指导软件测试的组织管理，是银行需要研究的课题之一。笔者分析了研发和测试的协同工作方式、内部测试组织形式， 应用Work Breakdown Structure(WBS)评估方法对软件测试生产力进行了初步探索和研究，并提出了测试生产力的WBS模型。

　　一、银行软件测试的特点

　　因系统复杂性、业务安全性、测试持续性等特点，银行和其他行业的软件测试存在差异，表现在以下几方面。

　　(1)研发和测试环节相对独立。研发和测试工作由不同机构按计划组织实施，但作为软件产品生产的上下游，两者存在紧密的联系。为保障产品生产的正常运转，研发和测试期间需要大量的沟通协调。

　　(2)软件测试周期相对固定。研发和测试单位往往隶属于同一个金融机构， 为确保产品的持续生产，金融机构会有相对固定的版本管理周期。测试单位在接到研发单位交接的研发产品后，必须在规定的测试周期内完成测试并投产。

　　(3)软件测试具有持续性和长期性。研发和测试的周期是连续的，一个版本结束后会马上进入下一个版本，同时还存在版本的延续测试和生产补丁的验证测试等。

　　(4)测试对象比较复杂。通常情况下，因业务种类繁多、展现方式多样、安全要求强等原因，银行的应用系统比较庞大，并且耦合性较高，同时银行业务的专业性也提高了测试对象的复杂性。

　　在银行软件测试组织过程中，需要建立一个标准，精确评估测试单位可以承担的测试工作量，作为测试单位和研发单位沟通协调的依据，以及内部分工管理的参考。

　　WBS模型为度量银行软件测试的生产力提供了依据。

　　二、测试生产力的WBS评估方法

　　WBS评估方法是将评估项目分解成可交付成果或划分成更小的、更便于管理的组成部分，直到工作和可交付成果被定义到工作包的层次，然后按照统一的度量单位进行折算，对每个工作包按照重要程度分配权重，最终汇总为总度量值，具体步骤如下。

　　(1)将评估项目进行逐层分解，最终分解为不可再分的工作包;

　　(2)对各工作包按照统一的度量单位进行折算;

　　(3)对各工作包按照重要程度分配权重系数;

　　(4)按照分解路径，将工作包的计算结果按指定的权重逐层向上汇总;

　　(5)最终计算出总的项目评估值。

　　WBS评估法是项目管理活动的一个重要环节，是当前所有生产力评估方法中最精确的方法。应用这种方法，在完成生产力评估工作的同时还能够完成工作计划的编制，因此达到了一举两得的效果。测试生产力是评估测试人员或测试单位在单元测试周期内完成的测试工作量，包括工作量、资源投入、测试周期三个要素。

　　工作量指对测试工作开展的一系列计划、准备、实施及总结活动的计量指标。资源投入指为完成测试工作需要投入的人力、硬件及软件资源。测试周期指完成测试工作消耗的总时间成本。测试生产力公式可以表示为：

　　测试生产力=工作量/(测试人数×测试周期)

　　测试生产力的评估可按照WBS评估方法，将测试生产力各要素进行分解， 然后根据各分解项的重要程度设置权重系数， 最终折算出总的统计要素， 计算出总的测试生产力。

　　(1)工作量评估。工作量的评估是测试三要素评估的核心，是对测试活动内容的分解。按照测试活动内容的不同，测试工作通常可分解为测试计划、测试实施和测试总结三项基本活动，且这三项活动又可继续分解(如图1所示)。

　　(2)资源投入评估。软件测试投入的资源可分为测试人员、硬件、软件等，测试人员可根据熟练程度分为多个等级，硬件资源指测试场所、机器设备、网络等，软件资源指为完成测试引入的测试数据、测试工具、测试培训等各类测试软件(如图2所示)。

　　(3)测试周期评估。测试周期的评估有两种方式，一种是直接以测试活动的整体时间跨度作为测试周期，另一种是对测试过程进行分解，按照关键路径法，评估各项关键测试活动的时间消耗，计算总的测试周期。前者比较容易计算，但不便于对项目各项活动做精细分析， 无法为项目测试改进提供指导。后者需要结合实际测试活动进行分解，是测试评估过程中难度最大的环节。测试周期按照测试活动的关键路径法进行分解示例如图3所示。

　　三、测试生产力WBS模型的应用

　　测试生产力WBS模型的建立是根据实际的测试活动，对各种生产力要素进行分解后重新评估的过程。在建立WBS模型之后，可根据实际的测试工作，将模型应用于测试计划、测试评价等管理活动中。笔者以A银行软件测试为例，对测试生产力WBS模型的建立及应用进行分析研究。

　　1.A银行软件测试背景

　　A银行信息科技以一个整体和核心应用架构为基础，建立了集业务操作、经营管理、分析决策为一体的全功能银行系统，所有软件产品都基于此架构按版本展开研发和测试，版本研发和测试均采用研发功能点作为工作量的衡量指标。每个版本的测试都要安排一定的测试人员在特定的测试环境下完成测试计划、实施和总结三部分内容，经历测试准备、实施和收尾三个阶段。以下以S版本为例说明A银行测试生产力模型的估算过程。

　　假设S版本的整体测试日期为2011年5月1日至2011年6月30日，版本分解为5个测试项目展开测试，各测试项目的工作量、资源投入、测试周期不完全一致。

　　(1)工作量。为保障和研发单位采用相同的工作量度量， 项目工作量直接取自项目的研发功能点(Function Points，fps)，版本工作量为各测试项目工作量之和6900fps，项目平均工作量1380fps(如表1所示)。

　　(2)资源投入。A银行测试生产力评估时的资源投入仅考虑人力投入，测试人员的技能水平可分为一级、二级、三级三个层级，整体资源投入将各层次人员按照1.5、1、0.8的折算系数折算为统一的有效测试人员。项目总投入有效测试人员45.6人，项目平均投入有效测试人员9.12人(如表2所示)。

　　(3)测试周期。尽管版本下的项目都在版本测试周期内展开，但因为测试内容、环境准备、项目沟通、补丁交付等各种原因，各个项目的测试周期也不尽相同。各项目测试并行执行，平均有效测试周期为46.6天(如表3所示)。

　　A银行根据实际需要建立了两种生产力模型：版本测试生产力模型和项目平均测试生产力模型。前者为生产力简易模型，生产力和测试周期相对固定，仅将资源人员投入情况按照一定的系数进行折算，该模型从宏观上对版本测试给予指导。后者为各个项目生产力的平均值， 作为项目计划和后评估的参考。

　　2.测试生产力模型

　　(1)测试生产力计算

　　软件测试生产力的计算是通过评估版本测试工作量、有效测试人数、有效测试周期，然后按照测试生产力公式计算：

　　版本测试生产力=版本测试工作量/(有效测试人数×有效测试周期)

　　S版本测试工作量为5个项目工作量的总和，共6900fps;测试周期为61个自然日;5个项目存在人员复用的情况(如表4所示)。

　　由此可知A银行S版本测试生产力为6900 / (36.2×61) = 3.12fps/人天。

　　(2)软件测试生产力的应用

　　软件测试生产力模型是对整个测试单位测试能力的评估，可以用来辅助版本风险评估、资源配置指导、测试单位考核等，为测试管理提供更科学的支持。

　　①版本风险评估。在一定时间内，测试单位的有效测试人员是一定的，若版本测试需要的生产力偏高，会造成测试不充分影响投产质量的风险。在版本规划初期，测试单位可根据自身生产力，对版本测试内容进行工作量上限的限制。

　　②资源配置指导。对于部分版本测试，由于工作量有限，测试单位可根据生产力模型，预估出需要参与到该版本测试的人员， 将闲置人员安排到下一个版本的测试准备工作中去， 既保障了当前版本的测试， 又降低了下一个版本的难度。

　　③测试单位绩效度量。因研发和测试的上下游关系，研发和测试的协调发展尤为重要。软件测试生产力作为对整个测试单位测试能力的评估，可以作为测试单位发展的一项考核指标，确保测试和研发的平衡发展。

　　3.项目平均测试生产力模型

　　(1)项目平均测试生产力计算项目平均测试生产力是通过核算版本下各项目的平均工作量，平均有效测试人数，以及项目的平均测试周期，然后按照公式计算：

　　项目平均生产力=项目平均工作量/(项目平均有效测试人数×项目平均有效测试周期)

　　S 版本5 个项目的平均工作量为1380fps，平均有效测试人员9.12人，项目平均测试周期为48.6天。由此可知S版本下项目平均生产力为1380 / (9.12×46.6) = 3.25fps/人天。

　　(2)项目平均测试生产力模型的应用

　　因项目平均测试生产力考虑了人员复用的情况， 是对项目维度的生产力评估，可用以指导项目准备、评价项目质量等，辅助测试项目管理。

　　①指导项目准备。项目测试在计划阶段需要根据测试内容和工作量完成测试团队建设和测试里程碑的制定。项目负责人可参考项目平均测试生产力，合理配置测试项目测试里程碑和项目成员，以提高项目的计划质量。

　　②度量项目质量。在测试工作总结过程中，可以将每个项目的测试生产力和平均测试生产力进行对比，以此判断项目测试管理工作是否合理。

　　四、模型应用注意事项

　　测试生产力WBS模型的建立需要充足的数据支持，且测试活动分解规则复杂，因此需要特别注意以下事项。

　　(1)立足测试实际。测试生产力WBS模型服务于测试管理，若脱离实际，WBS模型将事倍功半，甚至对测试管理造成负面影响。

　　(2)根据需要确定评估粒度。应根据测试需要，确定测试生产力的评估对象，若对象不明确或不合理，往往会造成概念混淆，导致建模失败。

　　(3)工作分解要合理。要根据需要和测试单位的实际情况完成工作的分解，避免将不必要分解的要素强行分解，也要注意工作分解是否会给评估带来工作量的剧增。

　　(4)参数设置要合理。在各要素统一计算过程中，参数设置需要根据实际情况确定，参数的误差会造成计算结果极大的偏离。

　　(5)在实践中滚动更新。测试单位各类生产力要素是不断发展的，而生产力要素也应及时更新测试活动分类、模型参数，在测试的不间断进行中完成模型和测试生产力指标的更新。