如何对依赖被无源码应用共享的数据库表的应用开展集成测试？

1. 搭建完全隔离的测试环境 #

不要在生产或共用测试环境开展测试，必须搭建独立环境：

• 复制生产环境中共享表的表结构、索引、约束，导入脱敏后的真实测试数据，确保数据结构与生产完全一致。
• 测试环境仅部署被测应用和模拟其他应用行为的脚本/工具，完全隔离外部真实应用的访问，避免测试操作影响其他系统。

2. 模拟无源码应用的数据库操作行为 #

通过生产环境的监控与日志分析目标应用的操作模式：

• 提取生产环境中其他应用对共享表的所有操作记录（如数据库审计日志、应用访问日志），整理操作类型（增/删/改/查）、触发频率、数据格式、关联业务场景。
• 用脚本（如Python+SQLAlchemy）或性能测试工具（如JMeter）模拟这些操作，测试过程中并行运行，还原真实的并发数据变更场景，比如其他应用定时更新共享表字段、批量插入数据等。

3. 明确测试边界与数据校验规则 #

• 梳理被测应用依赖共享表的具体范围：哪些字段、数据子集是核心依赖，制定校验规则，比如查询结果的完整性（是否返回所有符合条件的数据）、时效性（是否读取到最新变更数据）。
• 针对共享表的变更场景设计用例：比如模拟其他应用修改被测应用依赖的字段，验证被测应用的查询结果是否符合业务逻辑，是否出现脏读、数据不一致问题。

4. 用快照对比验证数据一致性 #

• 测试开始前，对共享表核心数据生成基准快照（比如执行SELECT * FROM shared_table WHERE condition INTO OUTFILE '/tmp/benchmark_data.csv'导出）。
• 测试过程中（尤其是模拟其他应用操作后），再次导出数据快照，与基准快照对比确认数据变更符合预期；同时验证被测应用的查询结果与快照数据是否匹配，避免共享表数据异常导致应用功能故障。

5. 聚焦增量测试与定期回归 #

• 每次测试仅针对被测应用的代码变更点设计用例，减少对共享表的不必要操作，降低测试复杂度。
• 当生产环境中其他应用有版本更新或操作逻辑变化时，及时更新模拟脚本，重新回归被测应用依赖共享表的核心场景，确保兼容性。

6. 开启审计日志辅助问题定位 #

• 在测试环境数据库中开启审计日志（比如MySQL开启general_log，PostgreSQL使用pgAudit），记录所有对共享表的操作请求。
• 测试出现异常时，通过审计日志快速定位是被测应用的查询语句问题，还是模拟的其他应用操作导致的数据异常，提升排查效率。

内容的提问来源于stack exchange，提问作者Nikola