测试策略：同中有异的项目测试经验教训

我经常参与的一种项目交付类型是IT过渡项目。一个系统在运营中心A中全栈运行，但由于商业原因（通常是招标），所有者C选择将其过渡到供应商B。

有些人将这种操作称为“迁移”，因为解决方案（理想情况下）在没有任何变更的情况下被“迁移”。类似的棘手项目还包括拆分和并购。

然而，对于过渡项目来说，它是在查看相同的系统，没有代码变更，只是位于新的数据中心，并且有一个新的交付团队。

这包括供应商A向供应商B移交源代码、服务器规格和系统快照，以便供应商B构建、维护和确认。

我通常经历的是在新设置B中建立的一系列测试活动——这需要测试人员扩大被测系统的范围。它包括所有环境，通常至少有五个（生产环境、预生产环境、开发环境和测试环境）。

一些典型的测试活动包括：

- 基础设施建设测试，包括操作系统、网络等。

- 中间件、Web服务器、数据库、消息代理和集成解决方案。

- 前端应用程序：我们能否部署实际的Web应用程序和用户界面。

- 环境内的回归测试和功能测试。

- 与C的第三方和其他内部系统的集成。

- 渗透测试和安全测试。

- 压力测试、负载测试和性能测试。

- 数据迁移测试。

虽然在回归测试和功能测试中出现了经典的测试主题，但没有新功能或功能变更。重点不是这些功能是否能正常工作，它们在供应商A构建时可能已经可以正常工作了——而是这些功能在新位置如何工作。

同中有异的测试

这主要是在企业或组织层面。以前，这种测试主题可能是关于数据迁移的，但它有一个更重要的主题。这是公司发生结构性变化的地方。

一个例子可能是从本地Outlook迁移到云中的Office 365。它也可能是从一个维护成本高昂的旧自建应用程序迁移到一个更新的标准解决方案。同中有异。

测试活动的领导

• 能够迈出领导测试的第一步

• 了解测试发生的时间

• 了解可能发生的测试类型

• 理解测试领导角色中的交付物

学习经验1：

按环境进行切换

许多合同规定，解决方案的运行应由A在某个特定日期移交给B——切换日期。这包括在A处对整个系统进行快照，将其传输到B，启动它，移动所有集成并进行测试。

通常，生产环境的这一操作需要整个周末。我们通常可以在前一个周末对非生产环境进行操作。

但所有环境都是处于各自状态的活动系统。

生产环境有最近部署的版本R，但下一个版本R+1可能已经在预生产环境中准备就绪。或者至少在切换时，测试环境处于R+1状态。开发环境是R+2版本正在构建的地方。

每个环境都有各自的一组活动集成，而开发环境可能没有任何集成，预生产环境可能有——而且每个环境中的数据都是各种各样的。

我们不能将供应商B的生产环境快照传输到所有即将来临的环境中。

我们还需要考虑，供应商B的开发人员正在构建R+2版本，因为这是切换日期之后的版本。供应商B的测试人员正在测试R+1版本。

虽然生产环境和客户很重要，但即将到来的发布节奏也很重要。

我在一个过渡项目中成功地按环境进行了切换，这不仅减少了风险，还构建了迁移测试，并支持了正在进行的发布。

我们使用了按环境进行切换的方法。所以我知道这是可行的，并且是一个可行的选择。

在生产环境切换前两周且在白天，B站点的开发环境变成了“真实”/活动的开发环境。当这一操作完成后，我们转移了测试环境，A的测试人员完成了他们的测试，B团队开始了他们的工作。

在B开发环境中，B的开发人员正在构建B开发环境中的版本。预生产环境也是如此，尽管这是在一个周末进行的，以模拟生产环境。然后最后是生产环境，主迁移计划从前面的四次切换活动中吸取了经验教训。

学习经验2：

从基础开始逐步测试

我在上面提到了各种测试步骤。另一个陷阱是在功能测试和集成测试的范围上过于雄心勃勃。客户C通常希望在新的测试环境中看到端到端的业务流程能够正常工作。

供应商A应该确保正在迁移的版本处于功能正常且可工作的业务状态。虽然我理解测试完整业务流程的愿望，但这不是经典的功能测试。

这里的关键变化不是功能本身，而是围绕它的一切——数据中心、构建工具、团队。

欲速则不达。对供应商B来说，关键的测试首先是系统能否在B的测试环境中被迁移、构建和部署，并且在其自身是一致的。这就是使用桩（stubs）作为战略选择的地方。

测试桩作为战略选择

测试桩是您无法控制的外部系统的模拟器。即使在2025年，仍然有系统被设计成对外部控制的系统有太大依赖。构建桩使系统所有者能够做出更好的战略选择。

只有当系统在桩的情况下能够正常工作时，才应考虑外部集成，甚至是所有者C内部的其他集成。

我目前项目的一个部分就卡在这里，他们无法构建他们被移交给的东西。因此，所有的功能测试用例都只是被阻塞在那里。

可以到我的个人号：atstudy-js

这里有10W+ 热情踊跃的测试小伙伴们，一起交流行业热点、测试技术各种干货，一起共享面试经验、跳槽求职各种好用的。        

多行业测试学习交流群，内含直播课+实战+面试资料

AI测试、 车载测试、自动化测试、银行、金融、游戏、AIGC.

学习经验3：

所有环境中的集成

生产环境有一系列与A、B和C之外的第三方的活动集成：数据源、履行系统、支付网关等。

一些集成可能多年来没有变化，并且正在被废弃，而其他集成正在建立。

保持一个清晰的列表，列出哪些环境在生产环境切换的范围内——并如前面提到的，针对每个额外的环境。

开发环境可能没有任何外部集成，但测试环境和预生产环境可能有。我曾经参与过一个过渡项目，它有一个专门的“外部集成环境”，所有接口的变更通常都在那里进行测试。因此，我们的环境中又多了一个。

一个挑战是供应商B希望从他们的测试环境向外部方E的测试环境进行测试，而E的测试环境正在被供应商A作为“活动”环境使用。

而且从E的角度来看，很少能成功地有两个活跃的主机用于相同的目的。完整的阐述在这里：

外部方，尤其是银行，可能出于安全目的只有一个活跃的端点。因此，虽然C可能希望在所有环境中看到所有集成，但这根本不可行。

此外，还需要考虑（测试）数据需要与每个集成点对齐。

我们可以做的是进行分析，我们将所有环境和所有集成进行映射，并对它们的测试情况进行评分：不适用、桩、实时。

然后基于此进行测试，这可能会在生产环境切换期间留下一些需要特别处理的情况，但通常比提前把所有细节都处理好更容易管理。

需要与所有集成方进行积极的对话，让他们了解情况，并就他们如何将集成从A迁移到B提供意见：允许IP范围、更新证书和端口。

我首选的测试方法是先进行“连通性”测试，建立基本的网络、身份验证和端口连接。一个ping测试——只有一个ping，如果你明白我的意思的话。

只有这样，我们才能进行更功能性的测试和基于API的交互确认。