假设项目组意识到完全覆盖方式的不合理，要求开发人员只能提交修改缺陷或变更对应的源码供测试。可是由于缺少工具的支撑，开发人员只能手工记录、追踪变更和缺陷对应修改的源码，这种方式一是记录和追踪的工作量大，二是很容易漏提交源码。由于开发人员漏提交源码，就很容易发生测试环境的缺陷在开发环境无法重现或者已经修复的缺陷又重现的情况。
公共参数 / 基础数据 / 配置文件未进行配置管理
一些项目组未将公共参数 / 基础数据 / 配置文件等全局文件纳入配置管理。由于没有将其纳入配置管理，所以这部分全局文件的变更也同样的未进行变更管理。当这些全局文件发生变更时，很容易出现测试环境、开发环境，甚至包括生产环境配置不一致的情况。一旦出现这种情况，那么即使发布程序在内部确认测试时测试通过，但是部署到生产环境后系统运行失效的情况就在所难免。这实际上是因配置项缺失而带来的问题。
很多人可能不认为公共参数或者基础数据应该作为配置项纳入配置管理，实际上这种想法是错误的。假设没有将这些公共参数等信息纳入配置管理，那么试想一下，假设有一天系统意外崩溃，我们拿什么去恢复生产环境?所以说，系统运行支撑的所有内容(包括基础数据、配置文件等)都需要纳入配置库进行配置管理。
文章来源于领测软件测试网 https://www.ltesting.net/