如何在单元测试中使用敏感数据且避免将其写入源码提交到GitHub

实现无源码存储敏感数据的常用方案 #

不需要把登录信息硬编码在测试代码中，可通过以下方式实现测试逻辑与敏感数据分离：

• 本地忽略配置文件：在项目根目录新建存储敏感值的配置文件（如.env、test_config.local.json），将该文件路径加入.gitignore防止被提交；项目中仅保留不带真实值的模板文件（如.env.example），开发者拉取代码后自行在本地填充真实敏感值，测试代码直接读取本地配置文件的对应字段即可。
• 环境变量注入：本地运行测试前可临时在终端导出对应环境变量，CI/CD流水线（如GitHub Actions）可直接配置平台加密的敏感变量，测试运行时自动注入到环境中，代码中直接读取对应环境变量即可，示例代码（Python）：login_pwd = os.getenv("TEST_LOGIN_PWD")。
• 团队密钥管理服务：多人协作场景可使用本地部署的密钥管理系统，测试运行时通过身份鉴权拉取敏感数据，本地不需要留存任何明文敏感信息。

三类存储方式的安全性对比 #

• 环境变量：安全性中等。优势是不会落盘到项目目录，几乎不会出现误提交到代码仓库的问题；风险点为若主机被入侵，运行进程的环境变量可被直接读取，若测试脚本存在打印环境变量的调试逻辑也易发生泄露，适合存储低密级的测试账号信息。
• 本地文件：安全性由文件权限决定。给配置文件设置仅当前用户可读权限（Linux下执行命令chmod 600 .env）后，安全性高于未做权限管控的环境变量；风险点为若忘记将配置文件加入.gitignore极易被误提交，设备丢失后如果磁盘未加密也存在泄露风险。
• 数据库：安全性低，不推荐使用。无论是本地还是远程数据库，都需要额外维护数据库的访问账号，反而增加了敏感点，远程数据库还需要依赖网络可用性，传输过程未加密还存在被拦截的风险，没必要为存储测试账号单独使用数据库。

敏感信息加解密的最优实现 #

如果确实需要将加密后的敏感数据提交到代码仓库（如团队共享通用测试账号的场景），不要自研加解密逻辑，优先使用经过工业界验证的成熟方案：

• 首选非对称加密方案：使用团队成员的公钥加密敏感数据，只有持有对应私钥的成员可以解密得到明文，加密后的密文可直接提交到仓库，不会出现明文泄露问题。
• 次选对称加密配合密钥分离：使用AES-256-GCM等成熟的对称加密算法加密敏感数据，加密密钥单独通过线下渠道分发，不要存入代码仓库，测试运行时通过环境变量传入密钥完成解密。

注意：绝对不要将加密密钥硬编码在项目代码中，否则加密逻辑完全无效。

如果是CI/CD运行测试的场景，直接使用平台自带的敏感变量存储功能即可，不需要额外做加解密，平台会自动对存储的敏感变量做静态加密，仅在运行时注入到测试环境中。

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