这是鼎叔的第五十二篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。

欢迎关注本公众号《敏捷测试转型》,大量原创思考文章陆续推出。

探索式测试在敏捷测试象限中处于右上角,即面向业务且评价产品,这篇补充一下探索式测试在项目测试中体现出的敏捷价值观,分享国外专家在探索式测试实践的观点。

注:所谓评价产品,就是在测试中使用系统并尽量重现最终用户的实际体验,这也是探索式测试为什么对用户体验评测至关重要的原因。

客户的参与,场景的创建

要创建准确的用户场景,真实生活中的领域知识是关键,因此应该端到端地测试完整系统,这时,聊聊角色扮演探索式测试与肥皂剧模型 就非常适合。通过这些场景活动,能帮助成员理解更复杂的业务问题,并充分考虑用户使用产品的动机。

让客户尽可能多地参与迭代项目的效果演示,越能获得客户的即时反馈。有的团队会在演示后让利益干系人(包括客户)做一些探索式测试,可以帮助团队把功能考虑得更加细致,并基于刚发布的功能马上思考将来要做的用户故事。

大师对于探索式测试的定义

Cem Kaner 很早就给探索式测试下了个人定义,它是一种让所有测试人员全身心投入工作时使用的方法,即同时进行测试的设计、执行和学习;也是一种强调测试人员的自由和责任的测试,是持续贯穿项目的平行活动。

这个定义说明,探索式测试不是草率的,可能需要广泛而精细化的准备。其中最厉害的准备,就是测试人员多年积累的知识和技能。探索式测试不是一种技术,也不是指南,它让测试活动具备探索性的原因,是测试人员的认知投入,能够学习如何应对持续变化的情况。

探索式测试人员的不同

探索式测试人员记录产品预期行为的想法,并不会列出太多细节,不需要太多清楚的指示。他的注意力会转移到产品界面呈现的新问题或新风险上去。在测试执行过程中,他会快速考虑这个问题是否干扰用户工作流的顺畅,并评估其严重程度。

当探索式测试人员收到新的构建版本时,往往倾向于不再重复之前的测试,而是着重于变化,以图发现过时的旧测试遗漏了什么,这种方法很有成效(考虑到底层自动化回归测试已经覆盖了重复性的各种测试场景)。

探索式测试的特点,就是测试人员自己要掌控测试程度,基于上一步的测试结果,对自己下一步该做什么能自然地给出明智的选择。

没有一个有思想的人,执行活动时是完全照着原稿进行。人可以快速学习新的信息,并研究其根源和影响。但机器代码只认识它被编程的内容,当奇怪的测试结果发生时,代码就可能忽略、崩溃,甚至毁坏数据。

从客户角度出发的测试活动确实不会是完全探索型的,探索式测试人员也要从测试目标驱动,目标一定程度上由客户在项目早期设定。探索式测试的任务也会参考检查清单,模型,覆盖要求和风险清单,但是如果被这些观点控制(而不仅仅是被指导),那测试活动更有可能变成” 计划好的传统测试 “。应该通过变化来驱动对问题的积极搜索,而不是局限于计划好的用例,这些用例往往只证实我们已经知道的东西。

因此,优秀的探索式测试人员应该不断地研究产品,和其他角色合作,而不是遵循程序结构化的方式埋头执行。这也是和敏捷宣言-” 个人和交互,大于过程和工具 “,” 强调客户协作,而不是合同谈判 “,不谋而合。探索式测试包含了和敏捷研发同样的价值观。

测试中的好嗅觉

没有刻意练习的黑盒测试人员,可能并不知道如何进行探索式测试。来自探索过程中的记录,也可以帮助人员能重现问题,以便于进一步研究。

怎样修炼测试过程中的好嗅觉?

基于对系统的理解,结合批判性思维,定义好测程,可以在短时间内运行的实验性测试,最后给出过程中的反馈。
分析风险,即用户认为什么是错误的,让人不高兴的。
对应的,用户心里强烈希望功能行为是什么样子的,并测试它。
基于过去经验,思考相似系统是如何失败/成功的,并探索它。
和开发交谈,发现什么是对我们很重要的。

让自动化回归测试套件做它擅长的重复性任务,让敏捷的人类做擅长的思考和处理各种意料之外吧!

基于测程(会话)的测试管理

探索式测试是在 “上下文驱动测试流派” 出现后才流行起来的。基于 session 的测试管理才能保障探索式测试可监督,可度量,也让探索式测试变成一种可以高度训练的习得性能力,而不是一个低门槛的自由测试。

Session,有些书里翻译成测程,有些翻译成会话,鼎叔的专题里默认用第一种翻译。

在测程结束后,我们会分析测程中的三类任务的耗时,以便知道哪个环节花费了更多时间:测试设计&执行,缺陷分析报告,创建章程。

探索式测试和自动化测试的结合

一个理念(来自 Jonathan Kohl),是用交互式的自动化测试来辅助探索式测试,比如自动化地创建测试,产生数据,完成重复性任务,将工作流程自动推进到探索式测试想开始的地方。基于自动化防护的成果之上,再探索更多隐蔽的遗漏缺陷。

我们还可以不断修改自动化测试套件,观察它的执行结果会发生什么不同(这类似于变异测试)。

优秀探索式测试人员的品质

能系统地追踪软件的坏味道。
通过使用预言(基于问题的原则和机制)来认知问题。
善于在时间盒内经常支线漫游探索-side trip
思考专家用户和新手用户会如何使用产品
和业务领域专家,或者技术领域专家一起探索,还可以邀请可用性(用户交互)专家一起来探索
检查有竞争关系的软件,获得启发(竞品软件启发探索法)

角色扮演测试法的启发

从角色扮演测试高手那学到的一些高级做法:

想象用户的一天(这个方法也可以用于用户故事地图的脑爆会,这个将来会介绍)
使用虚构的历史名人或社会名人,想象他们如何使用我们的软件
想象一个想方设法作弊的角色,或者黑客角色
想象购买服务的公司老板角色

用户图形界面以外的探索

不要只依赖于用户界面测试,也可以在其他方向进行整个系统的探索测试,比如:

探索 API 测试:当多个参数一起发生作用时,提供许多可能的变化(模型),有时参数是可选的。另一种场景是改变 API 调用的顺序,从而可能导致结果的改变,暴露用户界面上无法发现的问题。还有一个好处,API 接口可以在软件生命周期的早期进行开发,这意味着对它的探索可以在早期进行。为此,我们可以和开发人员合作实现易用的 API 测试套件。

WEB 服务的探索:在测试计划中预留对用户的服务 SLA 的探索式测试(SLA 即服务水平协议),模仿用户在访问 Web 服务的各种可能方式。

文档质量的探索:从之前的缺陷大扫除活动来看,很多开发及测试人员对于要交付给用户的文档缺乏足够的检查,很容易探索出显而易见的问题。因为文档内容的主观成分很多,自动化完成相关测试是很困难的。我们鼓励结对合作探索其他人员负责的文档,也注意要检查帮助文字的链接结果。

最终文档的质量对于用户体验是很有价值的。

报告的探索:有一类特殊文档,就是报告,对于客户也许很重要。因为报告功能经常放到最后实现,往往质量糟糕。基于用户评价的视角,报告检查应该满足简单、可读、易于理解的质量要求。对于报告的测试,最大的难点不是格式,而是获取正确的数据,有时建议使用生产数据来测试不同的报告版本结果。

探索式测试的辅助工具

短迭代意味着很难有时间进行充分的探索式测试,我们看看有哪些辅助工具能简化探索式测试步骤,并为其他重要的视觉测试留出宝贵时间。

测试设置工具:我们通常发现最耗时间的测试任务就是各种设置,以及正确的初始化。这种操作要进行多次,是使用自动化的好机会。这种工具要能接受不同的输入,一遍遍运行测试场景。通过模仿终端用户的使用方式驱动界面的工具,能让测试结果更有信心。

生成测试数据:这个也不用说,我们探索各种类型的输入数据测试时,这种工具太重要了,可以节约大量成本。

监控工具:把探索式测试中无法在屏幕上展示的错误信息,能够单独告警展示出来,并能够分析具体错误来源,让开发也能直接快速处理。

模拟器:为系统生成具有关键特征行为/类似真实数据的工具,还可以不停得往系统中输入数据,用于探索正常情况下难以出现的极端错误条件,同时缩短这种边界测试的人工准备时间。

仿真器:即复制一个与被测系统的行为完全一致的虚拟新系统,主要用在被测系统和外部系统有大量接口联调的项目,有过这种经历的人都懂。

仿真器可以保持测试和编码一致性,让测试和开发保持进度的一致,避免互相频繁等待对方的更新。仿真器还可以帮助客户深入了解要交付的系统,以便更好地合作,持续改进项目。

最后一句总结:

即使在测试驱动开发实践上非常先进的团队,也无法避免期望的软件行为和其他系统交互时的测试遗漏,强大的面向业务的探索式测试活动能够更好地评价产品,为产品注入价值。


↙↙↙阅读原文可查看相关链接,并与作者交流