曾經有這樣一個案例：某審批系統的公司組織機構信息是通過數據庫進行維護的。項目組在處理某個需求變更時，需要相應修改公司組織機構信息，但是項目組未將組織機構的修改作為一個變更單獨提出，測試組也不知道有這個潛在變更的存在。系統測試通過后如期部署上線，但是上線后發生審批流程節點出錯的問題。假如項目組將這個組織機構信息作為配置項納入配置庫，它的變更也經過變更管理，那么怎么可能發生這種情況呢?
上線的源碼版本組合為未經測試的版本組合
在項目已定義的發布流程中，可能因為一些看似合理的步驟，導致系統部署到生產環境后出現系統運行失效的情況。
在圖一中，假設 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)。這時上線帶來的結果是在生產系統上運行的是未經測試的版本組合。這潛在的質量陷阱可能導致發布時系統運行失效的情況。
圖一：未經測試的版本組合示意圖
上線的源碼版本為未經測試的版本
除了上線的源碼版本組合是未經測試的版本組合這種質量陷阱外，在發布流程中，還可能存在另一種質量陷阱。
在圖二中，假設文件 F1 和文件 F2 在修改之前的版本都是 1，在實現了需求 1 后 F1 的版本變成了 2，F2 的版本為 3。開發任務 1 在需求 1 修改的基礎上進行了開發，生成 F2(v4)。在測試環境測試的源碼版本為 F1(v2)和 F2(v4)。但是開發任務 1 沒有通過測試，最后部署到生產系統的版本將是 F1(v2)和 F2(v3)，F1(v2)和 F2(v3)是包含了需求 1 所對應的版本。但是，F2(v3)是未經過測試的版本，這潛在的質量陷阱也可能導致發布時系統運行失效的情況。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
