做软件测试要想保质保量，就要做到测试充分，什么是测试充分，就是把所需要覆盖的场景都要覆盖到。如何做到场景全面覆盖，特别是在时间紧任务重的时候？我把我这些年来工作的一点经验总结一下分享给大家，希望对大家有点帮助：

1 提前介入测试

那么什么时候测试介入比较好？在需求明确下来进入开发之前，测试就可以介入了解需求的相关内容了。这块一般有两个阶段：
  第一个阶段是需求澄清阶段，这个阶段就是需求接口人向开发讲解需求的详细要求及实现功能，这个时候测试就可以参与进来一起听，听过之后我们就对这个需求有了一个大概的了解，知道了这个功能的是要做什么，输入输出是什么，为后期了解详细的实现方案做准备。
  第二个阶段是开发实现方案澄清阶段，这个阶段一般是相关的开发人员把需求的功能实现方案和详细逻辑跟需求提出人和接口人确认，我们这个时候参与进来，就可以根据开发讲的实现方案和逻辑了解相关的的内容：比如算法判断逻辑是啥，取值是啥，输入值的类型是啥，取的哪个表哪个字段的值，或者调取那个接口服务，异常输入又是如何处理的，结果体现在哪里等等。
  当然有些小公司是没有给这些阶段的时间的，拿到需求就可能是口头说一下开发就直接实现，不会再次的澄清，这个时候我们怎么办，只有自己主动找开发沟通，遇到与开发理解不一致的时候，还要找产品经理或需求拉口人再次确认，来避免需求不清晰导致的一些不必要的问题，也为我们后期的测试用例编写找到明确的答案。

2 测试分析，测试用例设计

根据前期的了解，接下来我们就是要把这些存在于我们脑海中的信息转化为文字形式列出来，并分析出我们的测试场景。
  为啥要把这些信息转化文字，不根据所想直接列测试场景，因为这些信息存在我们脑海中的很容易忘记，而且不是很清晰，只有通过有章法的梳理信息后，才能形成对我们有用的信息。不知道大家有没有这样的情景，一个需求你看文档或者听需求接口人和开发都讲过了，你也知道是啥了，感觉没啥问题了，可是当你下去写测试用例的时候，你还是会有些地方模糊不清楚。那么把我们了解的信息形成文字，就能很好的帮助我们解决这个问题。
  如何梳理这些信息呢，我一般是按照这样的顺序来的：
1）先分析需求的背景，业务要求。
  把之前了解的需求背景都写出来，遇到不明确的及时询问相关人员，直到明确。比如一个需求的背景是这样的：业务人员在一线作业的时候发现某个模块在一些国家是需要特殊型号的，而在系统订单中默认配置的是另外一个型号，他们希望配置这个国家订单的时候，系统能自动识别出来并把这个模块替换成指定的型号。那我们在写需求背景的时候不仅仅是写上面那段话了，就要把“一些国家”中的国家给明确写出来，就是这些国家是哪几个国家，国家名称是啥，代码是啥，同时模块型号也要明确写出来，替换前的模块是哪个？型号是啥？替换后的模块是啥，型号又是啥？
2)分析需求实现方案和逻辑
  这里就是把我们前期了解到的开发实现方案和逻辑一一罗列出来，有必要的可以用图画出来如开发的实现流程，逻辑判断流程，数据走向等等。就比如上面那个需求，开发的实现方案是应该包括这个国家是从订单哪个信息里面取出来的，需要更换模块型号的国家又是放在哪里的，是怎么取模块型号的，更换后的结果在哪里体现等等。那我们在这个分析模块就要把这些都列出来，并一一明确。
3）分析测试要点，测试要素
  根据前面两项的分析，我们应该很快的就理出我们的测试要点，重点关注项等内容。就说上面这个模块型号更换吧，我们知道了：国家，指定模块型号，更换后的模块型号体现在哪里，都是我们的关注对象，同时我们还应知道这个更换型号对于没有不在指定国家的范围内的，型号是不受影响的。那么这些就是我们的测试要点和要素了。
4）列出测试场景
  根据上面的分析，我们可以把我们所需要测试的场景以表格的形式写出来了。
5）把测试场景转化为测试用例
  到此，我们就可以输出测试用例了，那我们这个用例到底充分与否，结果输出是否正确，我们的理解是否到位呢？接下来我们就要请相关的人员对我们的文档和用例进行一个评审了。
3 测试用例评审

测试用例评审不仅仅评审的是测试用例，还有我们对这个需求的理解和我们的思路，所以在评审的时候我们应该先把我们的测试分析文档讲一下，然后再把我们的测试用例拿出来给大家讲一下，重点讲测试的输入和输出结果。
  这样下来在开发和系统设计人员的帮助下，我们就可以及早发现用例的不足以及我们忽略的测试点，及时补充测试用例，完善测试用例。这个在以前的公司测试用例评审是要求很严的，每个参于评审的人都必须要提出问题点，就是为了避免有些参于评审的人员只参于不评审，导致一些问题遗留到最后。
4 严格按照测试用例执行测试

这一点很重要，为什么这么说呢？因为你测试用例设计的再好，你不按照它来执行，你的测试就不可能做到充分。
  还记得有一次我做好了一个需求的测试用例，评审完去测试的时候，我觉得自己记得差不多了就按自己记的开始测试没有按测试用例一个个的执行，前面测试的很快，问题也不多。等后面回归测试的时候，我就突然发现多出好几个问题，原因就是我没按测试好的测试用例全面覆盖漏测了两个关联点，打此以后，我再也不敢脱离测试用例，自己凭记忆测试了。
5 分解需求

有些需求接到的晚或着手测试的晚，功能又复杂，又要求按时上线，这个时候怎么办？

把需求测试用例完成后，按功能分成几个小功能点，分配给多个组员测试（当然这个在给参与测试的人员之前要把需求功能详细的讲解一下），在测试的过程中要保持经常沟通，做到宁可交叉重复测试也不脱节测试。
  我记得当时有一个web系统的功能，前期的时候因为忙着应对其他紧急的需求，就把它放在一边了，后面提上日程的时候发现留给我的时间不多了，我一个人测试肯定测试不全，这时我就主动找主管沟通，多调两个同事来和我一起测试，然后在两个同事的协助下，才顺利完成了这个功能的测试。
6 交叉测试

对于大的需求或都功能复杂的需求要做到多人交叉测试，这种测试在系统测试的时候就可以进行，以前我所在公司的项目每到系统测试都会进行这样的安排，这样就可以避免到后期回归测试出现更多的问题。
7 重点功能要及时跟踪进行测试充分性分析

对于那些功能复杂，风险性高的项目，我们要在每进行完一轮测试，进行一次测试充分性分析以便及时做出调整。
  有一次我们有一个比较大的改动，而这个改动涉及到了我们这个软件流程中的一个核心点，也就是涉及到的内容比较多，然而留给测试的时间却不是很多只有两周，怎么办呢？组长首先把这个改动按影响到的功能点细化分了一下，分给了三个人进行测试，每天她都跟进统计测试进度，分析问题分布点，跟进问题修改情况，然后再根据这些及时调整测试策略，经过两周紧张的有序的测试，这个功能最终稳当的上线。