- 开发人员漏提交待测试的源码
假设项目组意识到完全覆盖方式的不合理，要求开发人员只能提交修改缺陷或变更对应的源码供测试。可是由于缺少工具的支撑，开发人员只能手工记录、追踪变更和缺陷对应修改的源码，这种方式一是记录和追踪的工作量大，二是很容易漏提交源码。由于开发人员漏提交源码，就很容易发生测试环境的缺陷在开发环境无法重现或者已经修复的缺陷又重现的情况。
- 公共参数 / 基础数据 / 配置文件未进行配置管理
一些项目组未将公共参数 / 基础数据 / 配置文件等全局文件纳入配置管理。由于没有将其纳入配置管理，所以这部分全局文件的变更也同样的未进行变更管理。当这些全局文件发生变更时，很容易出现测试环境、开发环境，甚至包括生产环境配置不一致的情况。一旦出现这种情况，那么即使发布程序在内部确认测试时测试通过，但是部署到生产环境后系统运行失效的情况就在所难免。这实际上是因配置项缺失而带来的问题。
很多人可能不认为公共参数或者基础数据应该作为配置项纳入配置管理，实际上这种想法是错误的。假设没有将这些公共参数等信息纳入配置管理，那么试想一下，假设有一天系统意外崩溃，我们拿什么去恢复生产环境？所以说，系统运行支撑的所有内容（包括基础数据、配置文件等）都需要纳入配置库进行配置管理。
曾经有这样一个案例：某审批系统的公司组织机构信息是通过数据库进行维护的。项目组在处理某个需求变更时，需要相应修改公司组织机构信息，但是项目组未将组织机构的修改作为一个变更单独提出，测试组也不知道有这个潜在变更的存在。系统测试通过后如期部署上线，但是上线后发生审批流程节点出错的问题。假如项目组将这个组织机构信息作为配置项纳入配置库，它的变更也经过变更管理，那么怎么可能发生这种情况呢？
- 上线的源码版本组合为未经测试的版本组合
在项目已定义的发布流程中，可能因为一些看似合理的步骤，导致系统部署到生产环境后出现系统运行失效的情况。
在图一中，假设 F1 和文件 F2 在修改之前的版本都是 1，在实现了需求 1 和缺陷 1 后，版本均变为版本 2，表示为 F1（v2），F2（v2）。在测试环境测试时，测试的源码版本均为 F1 和 F2 的版本 2，但是需求 1 没有通过测试，最后只部署了缺陷 1 这个活动对应的源码到生产环境。那么部署到生产系统的版本将是 F1（v1）和 F2（v2）。F1（v1）是原来生产系统的版本，F2（v2）是包含了缺陷 1 所对应的版本。但是，和 F1（v1）匹配的版本组合应该是 F2（v1），和 F2（v2）匹配的版本组合应是 F1（v2）。这时上线带来的结果是在生产系统上运行的是未经测试的版本组合。这潜在的质量陷阱可能导致发布时系统运行失效的情况。
图一：未经测试的版本组合示意图
文章来源于领测软件测试网 https://www.ltesting.net/
