分析四：

　　作者：小颖

　　分析内容：

　　开发项目组在建立时，本身应该包括测试人员，测试人员应作为项目组的成员参加一切关于开发工作的会议，交流及讨论，有利于了解开发的方法及开发的各项信息。

　　对于版本管理，理想状态应存在一名配置管理员，作为测试人员与开发人员的交接点对程序版本进行管理，测试完成版本返回配置管理员，开发修改完成版本也给配置管理员，由配置管理员再交给测试人员；但一般公司不会设立这个岗位，而有即便是设了，也不能充分的发挥作用（我们公司这样）我认为的解决方法：

　　1、测试人员接收程序后，在存放时以程序名称和时间作为标识，并且每一次提交的程序一直到项目结束后再删除

　　2、开发人员提取修改后程序时，不要直接测试，先查看一下上一次程序错误的位置是否修改（与机器中保留的上一次提交版本核对）。

　　3、检查后，再开始动手测试，如果真的有没有修改的地方，那再算一次错误，不能总是替他们想的。

　　分析五：

　　作者：flygold

　　分析内容：

　　规定deadline，如每日12：00以后，不允许版本更新。

　　分析六：

　　作者：cissy

　　分析内容：

　　小颖所说的方法与我们公司现在进行的方法比较一致。但个人感觉确实没有很好地得到贯彻实施~~

　　我们公司现在在项目的立项阶段后由测试部派谴了质保员进行跟踪，但由于级别的不一致，引不起项目组的重视，有时只能是很浅地介入项目组的开发进程，应有的作用没有得到发挥。幸好本部门的部长比较重视，一直在维护质保员的重要性、权威性，希望以后这种情况能得到改善。

　　确实现在这种状态很普遍，也没有什么很好地解决办法。要想真正地有效地体现测试的价值，只有从上头做工作，让高层真正地支持你，给开发人员一定的压力，才能让测试工作真正有效地进行。

　　分析七：

　　作者：akchenyanjun

　　分析内容：执行CVS

　　分析八：

　　作者：rosemei

　　分析内容：

　　个人认为 ：开发人员提交测试需代单时，把需要测试的目的描述清楚，其中包括其代码更新部分需要接受验证的内容描述，测试人员根据测试需求单，首先验证其版本更新后的内容，是否通过，以更新内容为接入点，决定是否能够尽快尽早的打回给开发人员。

　　至于其修改后又引发其他地方的错误，这是个无法控制的，只能看开发人员修改BUG的严谨性了，通过奖惩激励的办法，提高开发人员的开发技能是关键。

　　分析九：

　　作者：spring_post

　　分析内容：

　　项目开始的时候，测试部门是要参与的（原因不用多说了），但是一旦项目处于实现过程时，理想的做法是测试部门定期对成果进行测试（通常是一周一次，由RE将现有成果建立一个BUILD交给测试部门）此时开发和测试是并行的，可用CVS管理各个版本（很好用的噢~）至于BUG的提交、确认、修改也都是同时进行的~当然开发人员有责任对所开发的模块做相应的组件测试~RE在此过程中的作用是相当大的~