技术学习：软件测试如何做到充分性测试？

做软件测试要想保质保量，就要做到测试充分，什么是测试充分，就是把所需要覆盖的场景都要覆盖到。
如何做到场景全面覆盖，特别是在时间紧任务重的时候？

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

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