在提交bug的模板当中，有一项必填项是该bug的发现阶段。如果是当前测试的迭代版本发现的问题，我们可以认定是新引入的，或许是开发修改其他问题把这块改坏了，或许是环境有所变化导致；如果这个问题在上一个迭代就已经存在，但是上一个迭代没有提交这个问题，那么就认定为遗留问题。新引入问题和遗留问题的判断大抵如此，但是，并不是所有遗留问题都是测试原因，很有可能上个版本因为某些问题阻塞，导致部分模块不能测试，这种遗留问题就不是人为能决定的了。

版本测试或者系统测试期间，对于测试人员的最终考核有一项重要指标，就是bug遗留率。有时为了确认bug是否遗留，甚至会安排版本回退，安装上一个迭代版本的包来验证这个问题。

从上面这些衡量标准来看，bug遗留一般只考察出现概率为100%的问题，按照同样的操作步骤，在安排了测试的那个版本就该发现的问题，却遗留到了这个版本。（int的问题因为原因众多暂时无法考察遗留情况）

遗留的问题如果不算严重，修改之后回归也不需要消耗太多精力，不需要执行太多用例，也不耽误上线时间。

但是如果这个问题发现的太晚，开发改动比较大，那之前相关功能都需要重新测试了。bug遗留和需求变动对于开发尾声的版本来说都是致命的。

所以执行版本测试之前，最好先整体过一下，看下有没有阻塞的严重问题，不要遗留到下一个版本。

当然，测试人员能确认是遗留问题还是新引入问题也可以帮助开发定位原因，是改出来的还是一直就有的问题。对于双方来说都有很大的帮助。