随着我国软件开发和测试能力的提高，以及人力成本相对低廉，越来越多的跨国企业在中国设立了研发中心，从而将部分项目从国外转移到中国的研发中心。这时候，摆在测试团队面前的，将是如何在已有项目的基础上进行有效的测试，即如何对中途接手项目开展有效的测试。
对于测试团队而言，测试中途接手的项目和产品，存在很多的风险和挑战。本文首先从测试的角度阐述中途接手项目测试可能存在的风险和挑战；然后根据笔者的经验和知识，提出测试方面的建议，以帮助测试人员更好的开展此类条件下的测试活动。
1 ）风险和挑战
（ 1 ）项目测试经验欠缺
对 于中途接手的项目，测试团队首先面临的一个挑战是缺少当前项目的测试经验，至少是不熟悉项目，例如：系统的整体设计架构、实现的主要功能、客户的关注重 点、系统的测试平台、系统使用的测试工具、系统配置和管理的命令、系统中主要的缺陷分布等。项目中这些信息和知识，都需要测试团队花费很多的时间进行学习 和理解。测试团队中尽管有的成员可能对系统功能有些经验和知识储备，但是对于该项目而言，测试经验方面肯定是欠缺的，或者是缺乏经验的。
（ 2 ）开发测试文档不全
中 途接手的项目，测试团队面临的第二个问题是：原有的需求文档和测试文档可能不全，甚至没有，例如：由于软件开发的成熟度低下，或者由于项目移交的时候没有 将相关的文档成功交接。而后续的测试工作需要详细了解以前项目版本的需求和相关的测试文档，从而可以深入学习和理解以前项目的基本功能。
对 开发团队而言，没有原始的需求文档也是一个非常大的挑战。首先，开发人员只能通过研究软件的代码来理解系统的功能和实现。而对系统各种可能的数据输入都进 行研究是不现实的，并且也很容易遗漏一些复杂的功能实现。其次，开发人员在面对特定输入情况下系统产生令人迷惑的输出，开发人员可能会想当然的认为系统就 是这样实现的。令情况更糟的是，开发人员在确定系统正确的输出和工作方式过程中，并没有进行相应的文档化，而是在这基础上直接进行代码设计，导致这种猜测 循环经常持续，从而使需求的收集和文档化更加困难。
而 对于测试团队来说，同样面临严峻的挑战。虽然从表面上看，在已有系统上进行测试，测试人员可以通过比较以前软件的输出和新的软件输出结果进行对比。但是， 基于不同版本输出结果进行判断并不总是安全的，例如：原来系统的输出就是错误的。基于这样的判断，测试人员就会遗漏系统中的一些缺陷。或者，原来系统实现 的功能是不正确的，而在新的系统中，由于增加或升级了软件修改了原来代码的缺陷，其输出是正确的。基于两者之间的比较，测试人员会认为新的系统由于代码的 修改引入了缺陷，而提交了不应该提交的缺陷报告。假如开发人员修改了本来是正确的代码，新的软件中又引入了新的缺陷。原本应该在需求阶段确定的预期结果的 判断，落到了测试人员头上。
（ 3 ）不稳定的测试对象
在 很多时候，项目在移交之前可能已经交付给客户使用了，后续的开发和测试会在用户版本的基础之上进行一些维护工作，例如：新功能的添加、缺陷的修改、系统架 构的更改、新技术代替老技术等。在这种情形下，整个系统看起来更象是移动的不稳定的实体，这样导致的结果是新的系统一直处于多种开发状态的混合体，它们会 经历不同的生命周期阶段，是个不稳定的测试对象。
（ 4 ）测试工作量的估算
由 于中途接手的项目经常处于不稳定的状态，导致测试工作量、测试进度、测试人员和资源的估算更加困难。测试工作量的估算只能是基于对系统功能的粗略理解，而 所谓的系统功能甚至可能是错误的，或者系统在维护过程中功能经常发生变更。对于测试估算而言，即使有详细的需求文档的情况下，也是一件非常困难的事情。因 此，对中途接手的项目，由于其不稳定的特点，进行测试工作量的估算，将是难上加难的事情。
（ 5 ）回归测试用例选择
对 于中途接手的项目，后续的开发和测试是基于前面的软件版本而展开的。针对开发活动而言，后续的开发主要是指软件版本新功能的增加、版本的升级、平台的升 级，以及前面版本中遗留的缺陷的修改等。而对于测试活动而言，后续的活动主要是验证新增功能是否符合系统的要求、确认是否满足客户的要求、确定缺陷是否已 经修复以及新增加的功能和缺陷修复没有在原来系统中引入新的缺陷。因此，对于中途接手的项目，测试团队的很多测试工作将关注在由于软件变更而进行的回归测 试。
在 中途接手的项目中，回归测试在整个测试活动中会占有很大的比重。因此如何选择每次测试的回归测试用例，对于测试团队而言，也是一个很大的挑战。由于前面提 到的测试项目经验欠缺和开发测试文档的不全，导致测试团队很难进行测试风险的估算，从而很难确定回归测试的重点和优先级，影响回归测试用例的选择。
（ 6 ）项目知识的转移
中 途接手的项目，还有一个很大的挑战是项目相关知识的转移，例如：系统、开发和测试相关知识的转移。项目是从一个研发中心转移到另外一个研发中心，由于语 言、文化和习惯的差异，在知识转移过程中，很难实现无缝的转移。由于测试团队中本身对项目的测试经验的不足，导致相关知识交流方面会更加困难。
2 ）经验和对策
从测试的角度，上面谈了中途接手项目中存在的 7 个主要风险和挑战。虽然存在比较多的困难和不确定因素，测试人员还是可以利用已有的测试经验和知识，采取一些合适的手段和方法来应对这些问题。
下 面根据笔者在中途接手测试项目方面的经验，对上面提到的这些问题提供一些参考的信息和建议。这些建议并不是肯定适合的，在进行具体项目的时候，还需要考虑 不同企业组织和不同项目的背景。同时，下面的经验并不是对应解决上面的每个风险和挑战，而是从整体上对如何进行中途接手项目的测试提供了一些实践。
（ 1 ）合适的测试经理或专家
对 于测试工作而言，测试经理应该是整个测试团队的灵魂，对于中途接手项目的测试中体现的尤为明显。中途接手项目中，测试团队的测试经验相对欠缺，因此测试工 作的计划、估算、执行以及控制等尤为重要，因此需要更加慎重的选择合适的测试经理来领导这样的项目。合适的测试经理，除了需要具备的一些能力和知识外，例 如：熟悉测试过程、具备测试管理能力等，针对中途接手的项目测试，测试经理具备下面几个方面的能力也非常重要：
ü???????? 测试经理应该对项目产品相关的功能、协议等有很深厚的经验和知识，能够从全局上把握软件产品的风险、测试的重点和优先级。在项目测试初期，最好能够在测试团队中能够起到知识方面的引路人；
ü???????? 测试经理应该有良好的沟通能力，包括对内沟通和对外沟通。由于项目是从国外研发中心转移过来，因此需要测试经理有很熟练的英语沟通能力。
对 于有的组织和项目而言，测试经理并不是技术方面的专家。那么，在面对中途接手的项目测试中，测试经理需要选择产品相关的测试技术专家（测试领域的专家，例 如：数据通信领域的专家）对整个测试过程中的技术进行把关。协助测试经理进行测试活动的计划、估算、协调和控制，同时帮助测试经理进行测试团队的构建和发 展，使得测试团队能够胜任中途接手项目的测试。
（ 2 ）合适的软件测试过程
选择了合适的测试经理或者测试专家，基本上可以保证测试团队对测试工作的适应性。测试质量中除了人的因素外，另外一个很重要的因素是过程的因素。测试质量的提高和保证，需要一个完善的测试过程来控制和保证。
当然，软件测试过程的选择，需要考虑企业组织的成熟度和测试项目的特性。一般来说，测试过程包含下面几个阶段：测试计划和控制、测试分析和设计、测试实现和执行、测试出口评估和报告以及测试结束活动。
测 试过程定义中，需要明确每个测试过程阶段的输入和输出、每个测试阶段的主要测试活动以及每个测试阶段中的质量检查点。明确定义软件测试过程以及相关的测试 活动和输出，可以从制度上保证测试工作的顺利进行，并且可以有针对性的进行测试活动的控制。软件开发的产品质量是通过整个开发过程的质量控制来保证的。同 样，测试质量也需要测试过程质量来保证。
（ 3 ）完善以前版本相关文档
收 集和整理项目以前版本的相关文档，包括开发文档和测试文档。从测试的角度来说，有两方面的内容：一是学习以前的相关软件需求和设计文档（可能是已有的，或 者通过开发团队收集和整理的文档），来了解软件的主要功能和实现方式；另一个是整理和收集测试相关的文档，比如每个版本的测试计划、概要测试用例、详细测 试用例以及以前版本的缺陷信息等。
假 如对每个功能进行全面的分析，需要花费巨大的人力和时间成本，这可能是不太现实的。我们的经验是和开发团队合作，召集各个领域和应用方面的技术专家，来对 以前系统进行需求方面的文档化，至少对每个功能特征进行部分的描述，同时对一些复杂的功能接口、用户接口等进行详细的需求分析，形成比较详尽的系统需求文 档。
针 对测试文档，根据前面得到的一些基本文档提供的信息，分析软件的主要功能和重要功能，提供一些测试用户场景以及它们的输出预期。也可以通过探测性测试，得 到软件的一些表现行为和结果输出。将这些用户场景和测试输出等进行文档化，作为后续项目测试的基础，也可以作为回归测试的输入和重点。
（ 4 ）软件新增功能的文档化
对 新增加和升级的功能特征进行文档化，从确定开发和测试的系统版本开始，我们需要对每个增加的功能、升级修改的功能进行详尽的需求文档化，作为后续开发测试 活动的参考和基线。这样，可以在后续的开发设计、测试设计等方面拥有共同的输入和参考点。这对于系统的研发非常重要，这个环节没有做好，项目的开发将一直 处于混乱状态，例如：系统需求不明确、开发条目不清晰、测试输出预期没有标准等，无法保证项目产品的质量。
（ 5 ）基线化一个测试版本
确定一个固定的系统版本作为进行后续开发和测试的基础。所有项目的利益相关者需要在这一点上达到共识：为什么产品的开发是基于已经存在的软件系统之上？然后选择已有系统的一个版本作为新开发的基础，并且它是唯一的进行后续开发测试的版本。
固 定后续开发和测试的版本，可以更加直观的来跟踪缺陷。通过对已有系统代码的升级或修改，可以判断在新的软件中某个现象是否是缺陷。在碰到输出结果存在异议 的时候，通过各个领域的专家来验证到底是新系统引入的新缺陷，还是旧系统中本来存在的问题。通过该策略，大家既可以对系统的输入和输出达成一致，也可以作 为对原有系统需求收集和文档化的手段之一。
（ 6 ）基于风险的回归测试
对于中途接手的项目测试，回归测试将是测试过程中的一个重要关注点。因此，如何选择回归测试用例，来提高测试的效率和有效性，是测试团队面临的一个重要问题。
通过前面提到的各种建议，可以对测试团队、测试过程和文档化方面进行改进，从而有利于回归测试用例的选择。回归测试用例的选择，基于测试风险而展开将是一个有效的手段。下面的实践经验可以作为一个参考：
ü???????? 分析软件中什么功能是客户最经常使用的？
ü???????? 什么功能对客户而言是最重要的？
ü???????? 什么功能在以前版本中发现的缺陷是最多的？
ü???????? 新增加的功能或者升级，对原来的什么功能和模块的影响是最大的？
在进行回归测试过程中，理解下面的建议将有助于回归测试的开展：
ü???????? 回归测试不是可有可无的，回归测试对于确认变更的正确性和验证没有引入新的缺陷方面有重要的意义和作用，同时可以提供对软件产品的信心。
ü???????? 回归测试不应该是流于形式的，应该制订严格的回归测试过程，包括软件变更分析、软件变更影响分析、定义回归测试策略、定义回归测试套件、执行回归测试套件，以及报告回归测试结果等。
ü???????? 回归测试的重点是保证软件基本功能的正确性，因此在回归测试过程中应该更多的关注在功能性，而不是非功能特性。
ü???????? 回归测试并不一定要覆盖所有的软件特征和功能，需要在测试风险、时间、成本和质量之间进行平衡。
ü???????? 回归测试用例需要不断进行维护和更新，而不是一成不变的。
（ 7 ）面对面的知识共享
项 目从一个研发中心转移到另一个研发中心，在项目知识的交接过程中，由于语言、文化和背景等方面的差异，可能会存在比较多的问题。我们的经验是，在成本允许 的情况下，尽量采用面对面的知识共享方式，即可以派测试方面的专家到另一个研发中心去接手这个项目，主要的关注点包括：
ü???????? 学习整个项目的演变过程，以前版本包含的基本功能、用户关注的主要功能、每个版本中存在的主要问题等。
ü???????? 尽量多的收集需求文档、开发文档和测试文档，包括原来测试团队在前面项目中测试的经验教训等。
ü???????? 熟悉软件环境的搭建和配置，包括测试仪表的使用、测试环境的基本配置等。
中途接手的项目测试，应该说存在多种多样的问题和挑战，并不是一件容易的事情。但是，通过上面的一些经验、建议、措施和步骤，可以帮助测试团队更好的组织、计划、估算、控制测试活动，从而达到测试成本、质量、时间、风险等方面的平衡。
相关文章
