首先对这类缺陷进行分析：
(1)有些问题在开发环境下没有重现，而开发人员迫于进度压力，往往会把它标记为已经修改。这种条件下测试人员应该和开发人员进行直接沟通;
(2)有些问题测试人员没有描述清楚，开发人员认为问题不存在也可能把问题标记为已经修改(正确的作法是标记问题为商讨或者不可再现状态)。测试人员应该清晰的描述问题，减少这类问题的发生，尤其要描述清楚运行的环境以及缺陷的重现步骤;
(3)第三类情况纯属个人行为：迫于进度压力，开发人员来不及修改问题，会故意把一些问题标记为修改，这样就可以在下次测试后进行修改。解决这种问题的方法就是统计缺陷的修改次数，分析出哪些反复修改的缺陷归属于哪些开发人员，然后告知项目经理;(由可能和绩效考核结合起来。)测试人员遇到这种情况，需要重新打开哪些未被修改而状态为修改标记的缺陷。
决这种问题的根本方法就是加强项目管理，提高项目执行能力，一旦资源较充裕时，测试人员和开发人员就会更加投入的一起解决缺陷，共同来提高软件质量。这就需要在制定项目计划时尽量要合理。
5、 产品测试完成后产品由谁来发布?
很多时候产品经过最后一次测试后由开发人员来发布，或由质量管理部来发布，这样做都是不合适的。
开发人员发布产品常常会导致缺陷解决不彻底。一种较常见的现象是最后一次回归测试后，开发人员修改完成最后几个缺陷直接从开发环境发布产品，这种条件下实际是缺陷一次测试，因为修改缺陷通常会引入新的缺陷，甚至是严重的缺陷。
测试人员发布产品也不符合流程的，测试人员的职责是报告软件质量情况。而且测试人员发布产品容易带来版本管理混乱。
正确的做法是产品经过最后一次测试后，把产品和缺陷修改情况存入产品基线库，形成一个可以发布的版本。这样发布产品的一个前提是每次产品提交测试前都要有一个预备发布版本，测试或者回归测试后如果有问题需要修改解决，开发人员对该预备版本进行修改。如此反复多次后，直到最后一次测试，所有缺陷都得到修改或者审核，同时开发人员此次测试后没有对产品经过任何修改，我们就可以把这个最后一个预备发布版本存入基线库。
进行了上面正确的版本控制后，我们可以通过配置管理库进行产品发布管理。对外部发布产品时，直接从配置管理库中提取就可以了。
文章来源于领测软件测试网 https://www.ltesting.net/
