1）先分析需求的背景，业务要求。

　　把之前了解的需求背景都写出来，遇到不明确的及时询问相关人员，直到明确。

　　比如一个需求的背景是这样的：业务人员在作业的时候发现某个模块在一些是需要特殊型号的，而在系统订单中默认配置的是另外一个型号，他们希望配置这个订单的时候，系统能自动识别出来并把这个模块替换成指定的型号。

　　那我们在写需求背景的时候不仅仅是写上面那段话了，就要把"一些"中的给明确写出来，就是这些是哪几个，名称是啥，代码是啥，同时模块型号也要明确写出来，替换前的模块是哪个？型号是啥？替换后的模块是啥，型号又是啥？

　　2)分析需求实现方案和逻辑

　　这里就是把我们前期了解到的开发实现方案和逻辑一一罗列出来，有必要的可以用图画出来如开发的实现流程，逻辑判断流程，数据走向等等。

　　就比如上面那个需求，开发的实现方案是应该包括这个是从订单哪个信息里面取出来的，需要更换模块型号的又是放在哪里的，是怎么取模块型号的，更换后的结果在哪里体现等等

　　那我们在这个分析模块就要把这些都列出来，并一一明确。

　　3）分析测试要点，测试要素

　　根据前面两项的分析，我们应该很快地梳理出我们的测试要点，重点关注项等内容

　　就说上面这个模块型号更换吧，我们知道了：，指定模块型号，更换后的模块型号体现在哪里，都是我们的关注对象，同时我们还应知道这个更换型号对于没有不在指定的范围内的，型号是不受影响的。那么这些就是我们的测试要点和要素了。

　　4）列出测试场景

　　根据上面的分析，我们可以把我们所需要测试的场景以表格的形式写出来了

　　5）把测试场景转化为测试用例

　　到此，我们就可以输出测试用例了，那我们这个用例到底充分与否，结果输出是否正确，我们的理解是否到位呢？

　　接下来我们就要请相关的人员对我们的文档和用例进行一个评审了。

　　测试用例评审

　　测试用例评审不仅仅评审的是测试用例，还有我们对这个需求的理解和我们的思路，所以在评审的时候我们应该先把我们的测试分析文档讲一下，然后再把我们的测试用例拿出来给大家讲一下，重点讲测试的输入和输出结果。

　　这样下来在开发和系统设计人员的帮助下，我们就可以及早发现用例的不足以及我们忽略的测试点，及时补充测试用例，完善测试用例。

　　这个在以前的公司测试用例评审是要求很严的，每个参于评审的人都必须要提出问题点，就是为了避免有些参于评审的人员只参于不评审，导致一些问题遗留到较后。

　　严格按照测试用例执行测试

　　这一点很重要，为什么这么说呢？因为你测试用例设计得再好，你不按照它来执行，你的测试就不可能做到充分。

　　还记得有一次我做好了一个需求的测试用例，评审完去测试的时候，我觉得自己记得差不多了就按自己记的开始测试没有按测试用例一个个的执行，前面测试的很快，问题也不多。

　　等后面回归测试的时候，我就突然发现多出好几个问题，原因就是我没按测试好的测试用例全面覆盖漏测了两个关联点，打此以后，我再也不敢脱离测试用例，自己凭记忆测试了。

　　分解需求

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

　　把需求测试用例完成后，按功能分成几个小功能点，分配给多个组员测试（当然这个在给参于测试的人员之前要把需求功能详细的讲解一下），在测试的过程中要保持经常沟通，做到宁可交叉重复测试也不脱节测试。

　　我记得当时有一个web系统的功能，前期的时候因为忙着应对其他紧急的需求，就把它放在一边了，后面提上日程的时候发现留给我的时间不多了，我一个人测试肯定测试不全，这时我就主动找主管沟通，多调两个同事来和我一起测试，然后在两个同事的协助下，才顺利完成了这个功能的测试。

　　交叉测试

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

　　重点功能要及时跟踪进行测试充分性分析

　　对于那些功能复杂，风险性高的项目，我们要在每进行完一轮测试，进行一次测试充分性分析以便及时做出调整。

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

尊重原创文章，转载请注明出处与链接：http://www.soxsok.com/wnews760711.html 违者必究！ 以上就是关于“郑州发布软件测试如何做到充分性测试”的全部内容了，想了解更多相关知识请持续关注本站。