探索式测试4——局部探索、场景探索

2016-11-04  橙子 
局部探索式测试,是根据软件的各种属性,输入、状态、代码路径、用户数据、执行环境等进行的测试。

输入:
一个数据、一个动作;
一个时间,一个状态;
一个文件,一个指纹;
一个眼神,一个微笑。
只要能触发程序工作的,我认为都是输入。
我们经常测试输入的方法就是等价类和边界值,而且很多人都用在测试输入框的时候;
其实这两个方法不仅仅可以用在测试输入,他们还可以用在数据准备、测试分析中,总之,他们是一种测试思考分析的方法。
在测试一段程序或者一个页面,首先要判断他的输入类型都有哪些?输入的值都有哪些可能?然后就可以使用等价类划分的思想进行分析。尽可能分析出所有可能的输入。

输入,一般又分为单个输入和组合输入。单个输入我们一般会根据等价类划分为有效输入和无效输入。组合输入一般是需要根据业务要求和逻辑进行组合。排列的不同、组合的不同都有可能影响输入结果。单个输入里最有可能出问题的就是下面这一组
[""," ",null,"null"]
他们分别代表 [空字符串、空格字符串,空对象,null字符串],但是开发经常会很容易搞错 。

输出:
输出也有很多种类型,
有些输出用户可以看到,有些用户是看不到的。
有些对用户有用,有些是跟用户没有关系的。
有些输出是最终结果的输出,有些只是过程当中的一个记录。
输出可能是界面看到的提示,也可能是数据库数据的增删改查;
输出可能是接口的调用,也可能是日志的修改;
输出可能是文件的生成,也可能是对其他系统、中间件平台的调用。
总之,我们应该根据阅读开发的代码或与开发进行沟通,了解所有的输出,通过输出,我们还可以补充输入。

输出的类型:
  • 页面提示
  • 数据库的增删改查
  • 文件的增删改查
  • 接口调用
  • 中间件(JMQ、PAF、PDQ)的调用
  • 缓存的调用
  • 硬件设备的调用
状态:
状态一般是指数据在整个生命过程当中不同的表现。也就是从产生这条数据,程序处理过程中,一直到处理结束;处理的逻辑不同,数据的状态也会不同。所以要想要想验证数据不同状态的表现,一般需要准备多条数据,准备多种输入情况。所以通过状态的梳理和测试,也能起到对输入和输出的补充。

逻辑:
虽然我们对输入、输出、状态都进行了全面的收集、测试。但是为了保证每一条分支我们都能测到,我们还需要分析一下代码的逻辑;因为相同的输入,对应不同的数据状态,就可能走不同的分支;相同的数据状态,但是由于输入不同或操作不同也可能走不同的分支;也许输入、状态都相同,但是由于其他条件不同,比如时间或数据的其他字段值不同,都有可能导致逻辑分支不同;总之,一切皆有可能。

数据:
数据,我们尽量要保证数据的多样性和真实性;如果可以,最好是使用真实的线上数据,或者导一批真实数据到测试数据库。如果这些办不到,我们也一定要尽量去模拟真实数据,多了解真实数据是什么样的,然后照着真实进行编辑修改。另外还要保证数据的多样、充足。数据的数量少、种类少,很有可能会遗漏问题。造数据我们可以通过系统去生成,也可以通过数据库直接插入或修改。通过系统生成是最好的,但是如果通过数据库插入,一定要小心,一定要搞清楚你需要的测试数据应该是什么样的。比如我想要造一条数据,跟京东没有合作的供应商数据,在数据库中可能有多种表达方式:
  • 在表中就没有这条数据
  • 在表中有数据,但是状态显示没有合作
  • 在表中有数据,也有合作,但是已过期
  • 在表中有数据,也有合作,但是被逻辑删除了
不同的数据表达方式就会有不同的含义,所以自己必须搞清楚,自己要的数据在数据库中应该是怎么表现的,最好是跟开发沟通,查看对应的代码。



场景探索式测试

    内部探索:保证场景的完整性,通过上下游及本身,覆盖所有相关的场景。
  •         收集实现某个场景所有方式
  •         收集当前场景所有的状态
  •         收集当前场景所有的下一步所有分支
  •         收集当前场景所有的下一步操作

    外部探索:通修改正常流程,进行额外的其他操作,验证是否会对当前场景造成影响。
  •         插入场景之外的步骤
  •         重复场景中的一些步骤
  •         删除场景中的可选步骤
  •         替换场景中可被替换的步骤
  •         替换场景中的数据
  •         替换场景中所处的环境


<作者:张强(JD零售)   2016/11/04   如需转载,请注明作者及来源    > 


176°|1763 人阅读|0 条评论
登录 后发表评论