约 6 分钟5 张卡

测试环境

测试环境是执行测试时被测程序及其依赖、配置、数据和运行资源的集合。同一份代码在两个环境得到不同结果，可能来自数据库版本、功能开关、账号权限或资源限制，不能只比较应用提交号。

测试结论必须带着环境范围理解。在小数据、单实例和本地依赖下通过，可以证明这些条件下的行为；若要判断线上容量或跨实例一致性，还需要对应的环境证据。

1. 面试核心

先记住这几条，再读正文

环境描述应该回答“重新做一遍需要哪些条件”，而不只是给出一个可访问 URL。

依赖标签可能变化。例如镜像标签相同，背后对应的内容却已更新。需要精确重建时，应记录不可变制品标识或摘要；同时保留有计划的更新流程，不把固定版本理解成永远不更新。

秘密配置只记录引用、权限范围和必要版本信息，不把密码、令牌写入测试报告。排障需要知道使用了哪个测试凭证，不意味着需要公开它的明文。

制品构建和交付的通用机制见可重复交付。环境记录则补足该制品运行时实际使用的条件。

一次环境准备可以依次执行：分配资源、部署依赖、应用迁移、准备基线数据、启动应用、检查就绪，再执行测试。任意一步失败，都应保留阶段与证据，而不是让所有用例继续报业务失败。

就绪表示已经具备当前任务需要的服务能力。进程存在、端口可连接、健康接口返回成功，分别提供不同强度的证据：数据库端口已打开，不代表迁移已经完成；应用健康，也不一定说明测试账号权限正确。

例如 Docker Compose 只按照依赖顺序启动容器时，不能假设数据库已能接受业务查询。可以使用健康条件等待，再独立确认 schema 与必要功能。健康检查也应有总等待上限，失败时输出对应阶段。

销毁则按归属回收应用、数据和外部测试资源。构建失败后也可能已经分配部分资源，清理不能只放在“全部成功”的分支。环境到期回收需要避免误删仍在执行的任务，并保留未回收项。

临时环境是为一次变更或一轮测试建立、结束后回收的环境。它可以减少不同分支抢占同一部署的冲突，但隔离范围取决于实际资源设计。

两个环境即使拥有不同应用实例，如果连接同一数据库、同一个消息主题或同一外部账号，仍可能互相影响。运行标签必须传到需要隔离的资源，具体数据策略见测试数据管理。

临时环境还有成本和适用边界：复制整个复杂系统很昂贵；少量实例不代表线上扩展行为；外部服务可能不支持随时创建独立沙箱。可以按目标保留必要真实依赖，将其他部分替换，但要在结果里清楚记录。

服务虚拟化是用受控实现模拟外部服务的交互，让测试能够稳定获得正常、错误、延迟或特定数据响应。它适合构造真实依赖难以重复提供的条件。

例如测试支付失败提示时，可以让虚拟依赖固定返回某个失败码；验证真实认证和协议兼容时，则需要接入实际测试服务。替身的版本与响应约定也应维护，否则它可能一直模拟一个真实服务早已改变的接口。

不要把所有环境差异都消除到完全一样。目标是知道哪些差异会影响当前结论，并为重要差异安排补充验证：

环境中没有观察到问题时，报告应指向已验证条件。遇到仅某环境失败，则先比较实际制品、配置、数据和依赖，保留差异证据，再定位具体机制。