（5）基线化一个测试版本

　　确定一个固定的系统版本作为进行后续开发和测试的基础。所有项目的利益相关者需要在这一点上达到共识：为什么产品的开发是基于已经存在的软件系统之上？然后选择已有系统的一个版本作为新开发的基础，并且它是的进行后续开发测试的版本。

　　固定后续开发和测试的版本，可以更加直观的来跟踪缺陷。通过对已有系统代码的升级或修改，可以判断在新的软件中某个现象是否是缺陷。在碰到输出结果存在异议的时候，通过各个领域的专家来验证到底是新系统引入的新缺陷，还是旧系统中本来存在的问题。通过该策略，大家既可以对系统的输入和输出达成一致，也可以作为对原有系统需求收集和文档化的手段之一。

　　（6）基于风险的回归测试

　　对于中途接手的项目测试，回归测试将是测试过程中的一个重要关注点。因此，如何选择回归测试用例，来提高测试的效率和有效性，是测试团队面临的一个重要问题。

　　通过前面提到的各种建议，可以对测试团队、测试过程和文档化方面进行改进，从而有利于回归测试用例的选择。回归测试用例的选择，基于测试风险而展开将是一个有效的手段。下面的实践经验可以作为一个参考：

　　分析软件中什么功能是客户经常使用的？

　　什么功能对客户而言是重要的？

　　什么功能在以前版本中发现的缺陷是多的？

　　新增加的功能或者升级，对原来的什么功能和模块的影响是大的？

　　在进行回归测试过程中，理解下面的建议将有助于回归测试的开展：

　　回归测试不是可有可无的，回归测试对于确认变更的正确性和验证没有引入新的缺陷方面有重要的意义和作用，同时可以提供对软件产品的信心。

　　回归测试不应该是流于形式的，应该制订严格的回归测试过程，包括软件变更分析、软件变更影响分析、定义回归测试策略、定义回归测试套件、执行回归测试套件，以及报告回归测试结果等。

　　回归测试的重点是保证软件基本功能的正确性，因此在回归测试过程中应该更多的关注在功能性，而不是非功能特性。

　　回归测试并不一定要覆盖所有的软件特征和功能，需要在测试风险、时间、成本和质量之间进行平衡。

　　回归测试用例需要不断进行维护和更新，而不是一成不变的。

　　（7）面对面的知识共享

　　项目从一个研发中心转移到另一个研发中心，在项目知识的交接过程中，由于语言、文化和背景等方面的差异，可能会存在比较多的问题。我们的经验是，在成本允许的情况下，尽量采用面对面的知识共享方式，即可以派测试方面的专家到另一个研发中心去接手这个项目，主要的关注点包括：

　　学习整个项目的演变过程，以前版本包含的基本功能、用户关注的主要功能、每个版本中存在的主要问题等。

　　尽量多的收集需求文档、开发文档和测试文档，包括原来测试团队在前面项目中测试的经验教训等。

　　熟悉软件环境的搭建和配置，包括测试仪表的使用、测试环境的基本配置等。

　　中途接手的项目测试，应该说存在多种多样的问题和挑战，并不是一件容易的事情。但是，通过上面的一些经验、建议、措施和步骤，可以帮助测试团队更好的组织、计划、估算、控制测试活动，从而达到测试成本、质量、时间、风险等方面的平衡。