在推进GJB5000的过程中，经常会有人向我请教各种各样的问题。有些问题答案很明确，但有些问题可能有不只一个答案。
像某些活动实践，你可以做得简单一些，也可以做得复杂一些，这本身没有对错，关键是你想要借此达成什么目标，你的资源和成本是否允许。
比如，下面这三个问题：
已经进入系统测试阶段发生代码更改，那么还需要做单元测试吗？
测试过程中产生的测试记录需要入受控库吗？
开发工具需要入受控库吗？
对于第一个问题，大多数实施GJB5000的组织都没有做单元测试，只会通过系统测试的回归测试来验证代码更改是正确的，并且没有引入新的缺陷。而站在软件工程的角度，代码发生更改了，那么代码块所在单元曾经进行的单元测试就已经失效了，通过单元测试的回归测试来验证这部分单元是正确的，并且后续在重新做与这个单元有关的集成测试的回归测试也都是合理的。但是，这样做将会增加很多开发成本，需要投入更多的时间和资源（如果已经实现自动化测试和构建，确实不存在问题），在系统测试阶段要不要做单元测试就需要综合考虑各个利益相关方的期望来做决策。
对于第二个问题，大多数实施GJB5000的组织不会把测试记录识别为配置项，而是作为过程数据放入开发库管理，当测试完成后编写测试报告时，会将其放入测试报告中，随着测试报告纳入受控库管理。而从配置项的定义来说，数据当然可以作为配置项纳入受控库管理，但是这会增加很多出入库、变更的流程，给测试人员、管理人员增加很多工作量。如果你想要强化测试结果的管理，并且愿意承担为此付出的代价，你可以把测试记录放入受控库管理；否则，你也可以按照大多数组织的做法放入开发库，直到测试完成再并入测试报告中。
对于第三个问题，大多数实施GJB5000的组织只会把专用工具放入受控库管理，通用的开发工具不会放入受控库。而从配置项的定义来说，工具当然是受控配置项之一。但是，那些通用的开发工具即便不放入受控库，但是组织也会有文件服务器或组织资产库等方式存储它，而且也不会给软件的开发和维护带来任何阻碍，那么把通用的开发工具纳入受控库就只是满足了标准要求，为开发/维护这个软件获取工具带来了一点点方便，却要付出增加管理工作量的代价，如果你任务这样做是值得的，那么可以放入受控库。
总之，在实施GJB5000过程中，有些实践究竟如何实施并没有唯一答案，如何选择在于你想要达成的目标，结合成本收益比来作出决策。
这正是：
实践做法不唯一，如何选择在于你
清楚做法利与弊，考虑成本绩效比
联系客服
