在回答这个问题之前，我们首先理清思路，测试的质量首先就体现在缺陷的质量上面。就是发现了多少缺陷，缺陷的严重程度如何，缺陷发现的早晚，缺陷的分布等等，作为测试的结果直接向客户表明了测试的质量。然而测试的质量又由什么所决定呢？是测试用例，测试用例的覆盖率，测试用例的精细度、深度，直接决定了能发现缺陷的多少。所以，要在未发布之前预估缺陷的遗留情况，就要检查测试用例的覆盖情况。
1. 根据测试用例和SRS中功能点的一一对应关系，还有概要设计、详细设计中的对应关系，这个跟着矩阵，检查是否所有的功能点都被覆盖到了。
2. 覆盖到功能点包括起码几个方面，1是正面的用例，2是负面的测试用例，3是所有的分支路径和错误处理是否都做了。
3. 对于有些需求，比如性能需求可能没有在功能测试用例涉及到，而性能需求也没有专门的收集，这就需要专门的收集，并且细化测试。因为很可能所有的功能都满足了，但是性能并不满足。系统并发用户使用并没有测试。这是很容易遗漏的，在项目快收尾阶段仍然需要检查一下是否所有的非功能点都测试过了。
4. 通过以上分析，如果发现有没有覆盖到的，覆盖不足的就是可能有缺陷遗留的地方。
以上总体是为了保证：所有系统该实现的功能都得到实现了，同时系统没有去做任何不该做的事情。
然而，并非通过以上途径就可以确保能够发现所有该发现的缺陷了。我们还可以通过比较分析当前的缺陷数据和历史相关数据来检查：
1. 如果这个被测系统有之前的版本的测试数据，那我们可以比较以前的这个版本所有的缺陷，看看以前一共多少个模块，平均每个模块发现了多少缺陷，然后客户又发现了多少缺陷。而我们现在这些相应的模块发现了多少缺陷。为什么比以前多，为什么比以前少，等等，很多可以比较的地方。
2. 类比同类产品的测试，比如都是j2ee，同样类型的系统，平均每kloc代码一共发现多少缺陷？平均每kloc代码一共能写出多少测试用例？平均每个功能点能写出多少测试用例，发现多少bug？而我们目前写了多少测试用例，发现了多少bug？那些模块发现的多或者少？然后检查原因，到底是为什么？因为这些都是可能存在缺陷遗漏的地方。
3. 对于不同的测试人员，做数据的比较，看谁发现的多，谁发现的少，谁发现的某种类型的缺陷多，或者少？因为常常是某些测试人员之容易看到某类型的缺陷，而遗漏另外一些类型的缺陷。
4. 对本被测系统的缺陷库做分析统计，各种类型的缺陷比例各是多少？这个比例是否符合历史数据的比例？分析统计以前产品的遗留缺陷比例，然后对比当前的产品。
5. 分析本公司，或者本测试团队以前的所有的非测试用例找到的缺陷，还有产品发布后被客户提出的缺陷。这些缺陷往往是我们团队自身固有的问题导致的盲区，这些缺陷类型和特点需要在本次测试中专门关注。
6. 分析测试方案、测试用例、开发的详细设计、概要设计的评审文档，以及相应的评审数据，发现的缺陷比例是否合理，以此判断分析是否评审的到位，如果评审不到位，则测试用例可能质量不够高，有遗漏，则测试就可能会少发现缺陷，这些地方需要认真检查。
7.具体的缺陷遗留比例可以根据上面提到的各项数据对比分析来确定，比如同类型，同代码量的软件应该能写1000个测试用例，发现2000个bug，而我们发现了1800个bug，则可以怀疑我们还遗留200个缺陷，但是，这只是怀疑，还需要分析是否由于开发团队的成熟导致的确只有1800个bug。这都是需要进一步分析论证的。
以上通过各种方式和角度的数据统计和对比，学习以前的经验，借此发现系统可能存在的潜在问题。然而可能还会发现不全，我们有以下手段可以应对：
1. 找经验相对比较丰富的测试人员，或者非本项目的测试人员来对本系统做随机测试。虽说是随机，但是，其实因为都是有经验的人员，而且对相关的系统都很熟悉，测试目的还是非常强的，同时这个测试过程，需要有本系统的测试人员陪同讲解，类似于配对开发而言的配对测试一样。
2. 问开发人员，他们怀疑他们的系统什么地方可能会有缺陷，然后专门去测试这些地方。
3. 如果开发有单元测试，这时候我们可以分析单元测试的结果，看看单元测试的覆盖率，是语句覆盖还是判定覆盖，逻辑覆盖等等，如果某些重要的功能点的覆盖率不够，我们可以专门去从单元测试和集成测试外加系统测试的高度做相应的测试，力图将这几个重点模块的测试覆盖率达到最高。如果之前没有单元测试，这时候也可以分析代码，测试重要的判断点。
总结：基本上我能想到的就是以上这些从测试角度，不涉及开发而谈的方法，判断分析出系统潜在的有问题的地方，以及相应的补救措施。但是需要说明这些方法必须在整个测试过程中实施，而不是快要交付之前才开始检查，这是团队管理人员，在项目计划中必须预留相应的时间和人力贯彻执行的。
