每一个好的缺陷背后,都可能藏着一个更好的缺陷,在你确实了解缺陷的影响程度和破坏力之前永远不要停止探索。
探索性测试的目标
- 理解应用程序如何工作,他的接口看起来怎样,实现了什么功能
- 强迫软件展示其全部能力
- 找到缺陷
探索性测试的方法论
- 卖点测试法: 此方法鼓励测试人员观看销售部门给客户演示的Demo,理解从销售的角度来看哪些功能对客户来说是最大的卖点,他们未必就是核心功能,但值得测试人员把它们当核心功能来对待。同时,也许刁钻的客户会提出各种质疑,这些质疑和稀奇古怪的问题也可以纳入测试人员的设计中。
- 指南测试法: 城市的题图通常都会标注一些热门的旅游景点,测试这些热门的区域是非常重要的。不管在任何一次发布的过程中,核心功能是肯定要覆盖到的。指南测试要求测试人员严格按照用户手册的建议执行操作,找出那些手册描述不到位或者核心功能并不像宣传的那样好的地方。
- 地标测试法: 在旅游的时候,如果我们设计了要到访的地方,通常会在地图上插上旗子,这就是地标。但是没有人规定我们应该按照何种顺序去到访这些地标。不同的测试人员可能会选择不同的顺序,有经验的测试人员会基于对软件产品架构和技术层面的理解,采取一些古怪的路径但更可能发现缺陷。
- 极限测试法: 向软件提出难以回答的问题,比如最大可以发挥到什么程度,承受多少用户,承载多少数据。哪些特性或功能会把软件逼到极限运作,哪些输入和数据会消耗软件最多的计算能力?哪些输入可能绕过它的错误检测?
- 快递测试法: 快递运送的货物,就好比软件里的数据,结果不同的地点转接,拆包装包最终到底目的地。所以快递测试专注的是数据,跟随它们走遍整个软件。
- 深夜测试法: 城市灯火阑珊会在午夜过后逐渐安静下来,商场店铺纷纷打烊。但是软件不应该停止工作,软件测试人员有时应该刻意的关注在冷门时间段软件所做的附属工作,比如数据备份归档、维护监控任务的运行等等。
- 深巷测试法: 在每个城市,都有些地方并不吸引游客意味着不吸引人群,但作为测试人员来说,反而是这种最不可能被用到或者最不吸引用户的特性,容易潜藏着难以发现的Bug。
- 博物馆测试法: 这是针对软件的陈旧代码和历史缺陷进行的测试,历史总是应该被铭记的。历史遗留的代码,当初开发它们的时候,可能缺乏文档,但这并不意味着它们应该被忽略,而那些曾经出现过的BUG,更是值得我们反复观察它。
- 通宵测试法: 繁华的都市总会有通宵热闹的地方,比如夜总会KTV之类的,它们从不中断。那么应用程序是否也能坚持到最后呢?当它面临持续不断的调用、输入、重读重写之类的操作,如果运行时间足够长,就很可能会出问题,内存会需要回收、数据需要清空,永远不要关闭它,保持不间断的运行。(更多的时候会采用自动化或者机器人思想)
- 长路径测试法: 把那个在应用程序埋藏最深的界面当做测试目标(离起始点最远的那个界面),观察经过的每一个界面。
- 超模测试法: 针对UI的表面测试,衡量软件的展现能力,像T型台的超模那样,不去关注她们幕后的辛酸痛苦劳累,跳出产品专家或测试的头衔,以普通观众的角度,去关注那些能看到的界面展现,元素是否被正确绘制、是否难看、颜色风格是否一致、界面的切换变化是否表意清晰?
- 取消测试法: 此方法的思想是启动了立即停止,特别是一些运行流程比较耗时的功能如备份还原或者搜索,在启动之后,立即取消。发散一点还可以变成,启动一个耗时操作,不停止立即启动另外一个耗时操作,以此来检测应用程序的自我清除能力。
- 懒汉测试法: 选择尽可能少的输入,能不输入尽量不输入,能不修改尽量不修改,观察应用程序是否能响应得出正确结果。
- 反叛测试法: 你见过去酒吧不喝酒点果汁的么?反叛思想要求输入最不可能的数据,或者已知的而已输入,测试人员可以采用逆向思维、明知一些数据违反规则,却偏偏要采用这样的数据,或者不按照正确的顺序来输入。
- 强迫症测试法: 测试人员强迫软件一边又一边接受同样的数据,反复执行同样的操作,最重要的特点就是重复。此种思维方式,常常打破了开发人员设计代码的思路,他们预想着你会按步骤操作,却不曾考虑过你反复的执行第一步应该如何处理。
- 情景剧测试法: 将软件带入到现实生活中,想象一下用户使用产品时可能会出现的情景。采用该方法时测试人员需要抛弃掉所有的设计文档,把自己当做一个用户,思考用户使用软件过程中可能想要去解决的一些实际问题。该方法可以让测试人员规避自身惯性思维所导致的漏测,而这些漏测很有可能是用户常常需要使用的功能。
- 穿越测试法:
有一些软件,它们一旦安装,就需要在很长一段时间内都可以正常去使用它,因此,测试人员有必要去观察在未来的时间里,这些软件是否仍可以正常工作。穿越测试法需要测试人员手动修改系统时间,穿越到过去或未来,查看软件在异常的时间段中表现是否在可控范围内。