软件配置管理、变更管理与测试的关系

　　软件配置管理、变更管理与测试的关系  软件测试　

   　在实际的操作过程中，配置管理中，各人员的权限控制非常重要，所谓建立统一的配置管理入口，我个人认为配置管理中的基线管理与人员权限管理的结合即可实现。一旦某一个基线建立之后，责任人对变更有读写权限，而其他人只有读的权限;如果是多人共同修改一个任务包，那可以通过控制任务包的粒度或者控制修改的顺序可以保证任务包的唯一性(不会出现多个版本)。所谓统一的出口，指定责任人(配置管理员或者项目负责人)从配置管理库中提取并且分配任务包即可。注意：任务包中不仅仅包含代码，必须包含相关的文档，在每次变更代码时，保证文档同步更新。需求的变更管理，首先保证变更的需求必须经过评审、入基线;然后要保证需求、设计、代码、测试的系统管理和可跟踪性;如果单独把需求变更管理拿出来单独管理，很难保证其他基线的同步变更和可跟踪性，这是我坚持需求变更不能用TD管理的主要原因。所谓保证测试的独立性，并不是指不能与需求变更一起去管理;而是相对的独立，最起码，要保证人员和人员管理是独立的;至于用例以及bug的管理，在不同的阶段涉及到各类权限以及方方面面人员的参与，但是其主导的仍旧是测试人员和项目的负责人，这就是相对独立性的局限性，毕竟bug的最终确认需要测试人员和项目负责人协商确定。但是因此就把需求变更的流程放到TD中去，似乎更加乱了。如果td单独管理bug，是可以通过状态来控制流程，甚至是可逆的;但是需求变更呢?一旦评审不通过，我们将如何处理?显然，流程在TD中是走不下去的。

　　这个问题，不仅仅涉及到需求变更与测试中对应的bug之间的可跟踪关系;还有变更后的设计呢，编码呢?怎么保证他们都经过评审，并且用一条线把变更的需求、设计、编码、测试用例、bug管理都串起来?实现他们的可跟踪性，我想这不仅仅是某个工具能够解决的问题，凌驾于工具之上的是建立统一的过程管理，当然，凌驾于过程之上的，是参与其中的人怎么去执行的问题。

原文转自：http://www.ltesting.net