码迷,mamicode.com
首页 > 其他好文 > 详细

【测试理论】如何做好探索性测试—基础篇

时间:2019-11-15 12:32:10      阅读:68      评论:0      收藏:0      [点我收藏+]

标签:期望   那是   资源   简单   工程   是你   src   测试工程   功能   

前不久国庆档上映的一部电影《登山者》,相信大家都已经看过了,在剧中,中国登山队那种不畏困难,勇于探索未知领域的精神着实让人敬佩,特别是最后一刻吴京饰演的方五洲带领队员,终于再次登顶。如果单纯的从事务的本质来看,探索未知区域(比如登山探险)和探索软件有非常多的共通点:

  • 有无数的惊喜和奇遇在等着你(比如发现惊天大bug)
  • 探索中,你可以借助于工具。
  • 探索有时候是欢乐之旅,有时候却艰苦跋涉,有时候你则是如履薄冰(很多时候,惊喜的bug总是在上线后才暴露出来)。
  • 若手上的地图和探索的未知区域不符时,应该相信未知地域(要相信自己发现的问题)。

顺着这个思路,计划写三篇关于探索性测试的文章(理论篇、深入篇、情景实践篇),在写文章的过程中,参考Elisabeth Hendrickson的一本书《探索吧,深入理解探索式软件测试》。文章理论知识偏多,所以看上去会比较枯燥,不过我会在文中加一些小案例,方便大家理解,现在让我们一起进入探索测试的世界吧。

常规测试和探索性测试的关系

所谓的常规测试,指的是我们常规思路的测试:尽可能的写测试用例、依照测试用例执行测试。而探索性测试指的是针对要测试的产品,选定一个模块/方面,选择很多可能变化的点(变量),然后深入进去,挖掘潜在的问题,举个例子:很多产品都有保存图片或文件的需求,这就牵扯到保存文件的路径,这里文件路径就是个变量,我们基于文件路径这一因素,可以提出很多可探索的点:

  • 选择的文件路径没有权限。
  • 选择的文件路径下有相同的文件。
  • 文件路径所在磁盘空间,是否够用。

我觉得所有的软件测试工程师,都有这样的经历,无论自己的测试用例写的多么完善,只要产品上线,就会有大大的惊喜在等待你。那是不是常规测试就不重要呢?换句话说,我们是不是应该更多的进行探索性测试来替代常规测试。其实不然,常规测试和探索性测试是相辅相成的关系,如下图所示:

技术图片

常规测试就如同上图中的网,而探索性测试则要覆盖网无法覆盖的区域(也就是网格),两者只有全部兼顾到,才能保证产品的质量。一个完善的测试策略应该能融合两种方式做到兼容并包:已测试=已检查+已探索。

探索性测试策略

与写测试用例一样,探索性测试也有对应的设计模板(姑且称之为探索性测试用例模板吧),其实写测试用例的思想(比如边界值、等价类)完全适用于探索性测试。但是需要注意的是,探索性测试的用例不会像一般测试用例那样具体,我们下面通过例子再来详细说明,通常来讲探索性测试的设计包含下面三要素:

  • 目标:你要探索何处?它可能是一个特性,一个需求或一个模板。
  • 资源:有什么资源是你可以用的?某个工具、数据集、技术、配置等。
  • 信息:你希望找到什么有用的信息/结果?可以说明系统的安全性、性能、稳定性等。

优质的探索性测试策略

先来看一个比较差的探索性测试策略:

目标:探索编辑姓名
资源:使用输入值 “xuan‘ke”
信息:为了发现【编辑姓名的功能】是否能处理名称里包含’的情况

大家对上面的策略熟悉吗?其实这就是一个比较具体的测试用例,只不过换了一种形式。接下来我们再来看一个比较正常的探索性测试策略:

目标:探索浏览器输入的地址
资源:使用javascript和sql注入式攻击
信息:为了发现系统的安全弱点信息

可以看到上面的测试策略并没有说明,需要具体使用什么javascript脚本或者什么sql语句注入,而是提供了某一个方向或者灵感,剩下的工作需要你自己去探索和尝试。

工作中应该如何挖掘探索性测试的点

为了大家能找到有价值的探索性测试点,这里帮大家归纳几个可以寻找测试点的思路。

需求评审

需求评审是挖掘探索性测试点的理想时机,下面举个例子(例子中人员角色:Alex是软件测试工程师、Pat是开发工程师、Binh是业务分析师):

技术图片

Alex针对上面的对话情况,制定了如下的测试策略:

目标:探索编辑档案
资源:使用非法用户名
信息:为了发现用户名限制规则未被触发的情况

所以之后的需求评审中,我们又多了一件可以做的事情,可以尝试去发现针对产品可探索性测试的点。

隐性期待

产品经理和开发工程师思考问题的角度是不一样的,所以必然会存在这样的状况:每个人从自己的角度考虑,觉得某些事情或需求点太简单了,不需要再提。但往往是这些隐性期待,造成了沟通障碍,等到最终产品将要上线时,才发现大家对需求的理解都不一样。

举个例子,比如:在开发某一款app时,产品经理期望能打开app就使用某个特别高大上的功能,它的隐性期待是加这个功能不会影响app的启动速度、包的大小等。但是等到开发完成时发现加上这个功能后,app启动速度慢了将近10s,这显然是不能够接受的。虽然产品经理需求文档中并未提及对app的启动速度影响,但是你得尝试发现这些值得探索的隐性期待,将它们加入我们探索测试的策略中。

有意义的变量

在一个软件/系统中,会存在很多变量,而这些变量是可以作为我们探索的点,下面列出需要注意的变量:

  • 可计数的东西:这个很好理解,比如:用户登录次数、操作次数、存储文件的数量等,通常可以用一些特别的数字作为探索点:0,1,多,过多,过少。
  • 相对位置:位置有“开头—中间—结尾”的纬度,比如:在一个列表中,操作最后一条可能有问题、操作中间某一条和操作第一条都不会有问题。
  • 文件和存储:文件存储牵扯到了路径,比如:将你的某个文件保存到不同的目录(权限问题等)就可能会出现问题。
  • 地理位置:地理位置包含一些逻辑上的位置,比如:时区、海拔、邮政编码等。
  • 格式:在程序中的很多东西都有格式,比如:日期、邮寄地址、文件路径、URL、文件内容、信息等等。而这些格式都可以被改变,来进行探索。
  • 大小:在程序中文件是有大小的,比如:图片、配置文件、上传的各种文件。
  • 深度:在程序中任何带有层级的东西都有深度,比较常见的有XML配置文件、带括号的运算操作、程序中的循环。
  • 时间点、频率和持续时间:在程序中频率和持续时间,是比较容易发现问题的变量因素,比如:你用monkey对某个app做稳定性压力测试、快速的滑动某个页面有可能造成crash,或者你可以试试,让你的程序运行一晚上或者更长时间来验证问题。
  • 输入和导航: 比如:你在输入的时候可以复制粘贴,也可以直接输入;在关闭弹窗时,你可以点击屏幕上的按钮,也可以使用快捷键,这些都是变量。

上面提到的这么多变量,你可以结合自己的产品特性来选择变量作为自己探索测试的策略。

源代码

如果你还没有源代码的权限,一定要问开发要一个“测试”的代码权限。看代码的注释是特别欢乐的事情,而这些注释也能帮我们发现探索测试点,比如以下注释:

  • 我也不知道为什么这么做行得通,但是它就是可以了,千万别动它。
  • 也不知道哪个龟儿子写的代码,看不懂,修改了下,先用着吧。
  • 这是xxx领导让加的定制化需求。

如果看到代码中有类似的注释,那么说不定这就是值得我们探索的点。

用户反馈

不管我们再怎么努力的测试,软件到用户手上,还是会出现各种各样的问题,原因很多:软件安装的环境不同、用户的操作和使用习惯千差万别、软件运行的环境(比如网络状况)不同。所以多查看用户反馈的平台,也可以帮我们挖掘出探索测试的点,将他们记录下来。

目标一致性

上面提到了几种探索性测试策略的发现的点,但是也需要注意,你找到的可探索测试的点,需要和开发工程师、产品经理保持目标一致,否则会浪费你的时间。举个例子:你将切换程序所在的时区作为一个探索点,花费大量时间在验证切换时区之后的影响,但是最后产品经理告诉你,我们的程序只可能在中国使用。

所以在需求评审时、或者常规的用例评审时,可以将制定的探索性测试策略拿出来,和大家同步下,从而让大家对测试策略的认知达成一致,同时你也可以丰富自己的探索性测试策略。

总结

本文主要介绍了探索性测试的基础内容,可以帮你初步的了解到探索性测试是怎么设计的。其实我觉得在平时的测试工作中,大家已经有意无意的在用探索性测试的理论了,只是目前还是以常规的测试为主,还没有达到和探索性测试相辅相成的效果。希望我能通过【如何做好探索性测试】的这三篇文章,帮助大家优化自己的测试知识体系,同时对我自己来说也是个升级。下一篇文章会更深入的来认识探索性测试。

技术图片

【测试理论】如何做好探索性测试—基础篇

标签:期望   那是   资源   简单   工程   是你   src   测试工程   功能   

原文地址:https://www.cnblogs.com/zhouliweiblog/p/11865290.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!