- 開發人員漏提交待測試的源碼
假設項目組意識到完全覆蓋方式的不合理，要求開發人員只能提交修改缺陷或變更對應的源碼供測試�？墒怯捎谌鄙俟ぞ叩闹�，開發人員只能手工記錄、追蹤變更和缺陷對應修改的源碼，這種方式一是記錄和追蹤的工作量大，二是很容易漏提交源碼。由于開發人員漏提交源碼，就很容易發生測試環境的缺陷在開發環境無法重現或者已經修復的缺陷又重現的情況。
- 公共參數 / 基礎數據 / 配置文件未進行配置管理
一些項目組未將公共參數 / 基礎數據 / 配置文件等全局文件納入配置管理。由于沒有將其納入配置管理，所以這部分全局文件的變更也同樣的未進行變更管理。當這些全局文件發生變更時，很容易出現測試環境、開發環境，甚至包括生產環境配置不一致的情況。一旦出現這種情況，那么即使發布程序在內部確認測試時測試通過，但是部署到生產環境后系統運行失效的情況就在所難免。這實際上是因配置項缺失而帶來的問題。
很多人可能不認為公共參數或者基礎數據應該作為配置項納入配置管理，實際上這種想法是錯誤的。假設沒有將這些公共參數等信息納入配置管理，那么試想一下，假設有一天系統意外崩潰，我們拿什么去恢復生產環境？所以說，系統運行支撐的所有內容（包括基礎數據、配置文件等）都需要納入配置庫進行配置管理。
曾經有這樣一個案例：某審批系統的公司組織機構信息是通過數據庫進行維護的。項目組在處理某個需求變更時，需要相應修改公司組織機構信息，但是項目組未將組織機構的修改作為一個變更單獨提出，測試組也不知道有這個潛在變更的存在。系統測試通過后如期部署上線，但是上線后發生審批流程節點出錯的問題。假如項目組將這個組織機構信息作為配置項納入配置庫，它的變更也經過變更管理，那么怎么可能發生這種情況呢？
- 上線的源碼版本組合為未經測試的版本組合
在項目已定義的發布流程中，可能因為一些看似合理的步驟，導致系統部署到生產環境后出現系統運行失效的情況。
在圖一中，假設 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）。這時上線帶來的結果是在生產系統上運行的是未經測試的版本組合。這潛在的質量陷阱可能導致發布時系統運行失效的情況。
圖一：未經測試的版本組合示意圖
文章來源于領測軟件測試網 http://www.kjueaiud.com/
