分析十：

　　作者：ppent

　　分析内容：

　　个人认为本案例的焦点是如何控制开发人员提交代码、打包版本的质量，而与测试人员何时介入项目是没有很大的联系的，还有楼上说的通过入口标准、检查后再测试，那是事后的补救办法，但还是可以减少测试人员不必要的资源投入。我的看法：

　　1、记录每个提交代码、编译打包版本的质量情况，每月/季度进行发布。让大家清楚的看到本阶段的各个版本中谁犯了了“没有更新新的代码、打包错误、bug没有改好、bug改这个错那个”的错误。有了这样的统计结果，相信以后不管是开发人员还是打包人员都会更加小心的。

　　2、如果有必要，可以根据上面的结果建立奖惩制度。

　　3、采用配置管理工具，进行良好的版本管理，防止代码更新遗漏、错误的情况。

　　4、如果是接近发布的版本，慎重起见为了防止改bug而带来的新的bug，需要评估每个bug修改的难度、优先级、风险等，是否有良好的解决办法，或者在下个发布版本中修改。

　　分析十一：

　　作者：小胖子

　　分析内容：

　　前面几位的方法在实际的工作中都是使用过的，但是制度是理想的，实施起来不是很理想。我遇到一个开发人员写的程序，基本上是无法使用没有一点是根据需求规格说明书写的。但是我还是耽误了两周的时间，后我在例会上向项目经理提出了正式的交涉，才引起公司的注意。终那个开发人员因为工作能力问题离开了公司。

　　分析十二：

　　作者：自得其乐

　　分析内容：

　　我们公司现在的做法是在提交测试之前由开发人员先做VT，测试人员拿到新版本后也是先做快速测试，没有大的功能性问题才接受该版本，如果随便点一个功能报底层的错误，说明开发VT没有做好，可以打回该版本，由测试员提交delay报告，说明这个版本延迟提交的原因。由管理中心进入来跟踪查找原因，所以长期这样开发人员一般对于提交的版本还是比较谨慎的。

　　分析十三：

　　作者：chimi

　　分析内容：

　　在我单位，具体操作是这样的：

　　1、BUG 的跟踪要抓紧，必须有一个BUG的跟踪系统来管理BUG。

　　2、版本的发布和测试版本的管理，要以BUG 管理系统为依据。

　　3、新加功能的跟踪也可以用BUG 管理系统那里实现。

　　4、每次开发人员修改了BUG 或者是 完成了新添加的功能，都必须在BUG 管理系统那里作说明。

　　5、每天安排一个指定时间来获取新版本的程序来做测试，当然之前要确认他们都更新了代码，编译服务器也要准时、成功的编译好测试的版本，确认他们对自己的工作都作了记录（记录到BUG 的管理系统）。

　　6、开始测试新版本的程序。只要其中一环还没有完成，那部分的内容不作为测试考虑。

　　分析十四：

　　作者：nio

　　分析内容：

　　其实作为测试来讲，没有必要关注这个问题。

　　测试的主要目的是发现问题，至于版本问题，以及BUG有没有修好，那不是我们测试人员要关注的。我们要做得是如实的反应问题。

　　这个问题的出现根源在于测试人员有太多的意见（牢骚），出现这样的问题，我们要做的是告诉开发人员，在这个版本中有些BUG并没有修好，至于为何会出现这样那样的问题，则和测试一点关系也没有。