软件测试过程中的配置管理[2]

         软件测试过程中的配置管理[2]   软件测试

　　曾经有这样一个案例：某审批系统的公司组织机构信息是通过数据库进行维护的。项目组在处理某个需求变更时，需要相应修改公司组织机构信息，但是项目组未将组织机构的修改作为一个变更单独提出，测试组也不知道有这个潜在变更的存在。系统测试通过后如期部署上线，但是上线后发生审批流程节点出错的问题。假如项目组将这个组织机构信息作为配置项纳入配置库，它的变更也经过变更管理，那么怎么可能发生这种情况呢?

　　上线的源码版本组合为未经测试的版本组合

　　在项目已定义的发布流程中，可能因为一些看似合理的步骤，导致系统部署到生产环境后出现系统运行失效的情况。

　　在图一中，假设 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.ltesting.net