扫码阅读
手机扫码阅读

聊聊什么是探索式测试

43 2024-01-31

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

本篇开始分享第三个主题系列文章-探索式测试

除了自动化测试建设这个众所周知的方向,另辟蹊径的敏捷测试方案层出不穷,在过去的实践中,鼎叔最希望着力推广的是三大敏捷测试利器(方案):探索式测试,众包测试,精准测试。三大利器自成体系,具备不断深度挖掘的价值,投入产出很可观,而且从不同方面阐述了敏捷价值观在测试领域应用的精髓。

  • 探索式测试,让创新测试方法趣味化,充分流通,鼓励人员交流和启发。

  • 众包测试,让更多的人低成本高效率地参与测试活动,贡献高ROI。

  • 精准测试,让测试用例尽量少,覆盖代码尽量准,回归更有信心,打破开发和测试的隔阂。

历经四个公司的亲身组织实践,我认为探索式测试是非常有趣的,任何人都可以从中获得适合自己的知识和经验。

我们先从一个笑话讲起

测试工程师走进酒吧,

要了一杯啤酒,

要了0杯啤酒,

要了999999999杯啤酒,

要了一只蜥蜴,

要了-1杯啤酒,

要了一个sfdeljknesv,

酒保从容应对,测试工程师很满意。

接下来,一名顾客来到了同一个酒吧,问厕所在哪?

酒吧顿时起了大火,然后整个建筑坍塌了。

这个笑话很生动地告诉我们,无论设计的测试数据多么周详,总有客户能发现测试工程师遗漏的严重问题场景,这个场景往往是出人意料的,也是经常能见到的。


探索式测试的由来

首先我们思考一个问题,人工测试,相对于自动化测试,有什么优势?

1) 人工测试,更容易发现不同业务逻辑的关联缺陷。

2) 人工测试,可以给出灵活多变的测试计划,灵活多变的测试用例,发挥人的想象力。

3) 人工测试,不只是看断言,还会随时查看各种异常:日志,UI,资源监控,动效,弹框,不一而足。

人工测试通常会有一个事前的测试计划,里面列明了详细的用例执行过程。

如果我们看重人的“灵活性”和“积极性”,逐步摆脱测试计划的束缚呢?

那就是我们要介绍的探索式测试。

有不少测试同学曾提到,第一次听说探索式测试理论,觉得很高大上,但是并没有真正深入了解。

实际上,探索式测试对于突破重复劳动的束缚,降低漏测率,提高测试交付效率,都会有明显的价值。测试人员工作更加自由自主,不需要被大量的测试用例所包围,不用花大量时间写非常细致的用例集。

测试专家Cem Kaner在1983年提出了探索式测试,并把它定义为一种软件测试风格,而不是一个具体的测试技术,如边界值分析方法,因果图等。探索式测试强调的,是测试人员应该持续的同步开展测试学习,测试设计,测试执行,测试评估等多种活动,不断闭环提升,而不是被事前的测试计划文档所牢牢束缚。

我经常看到有些团队会考核测试用例的缺陷相关性指标,评判测试用例的有效性。但在探索式测试的实践中,我们更鼓励从实时探索中发掘缺陷,而非依赖事前的用例挖掘。

探索式测试的发展阶段

通常理解,探索式测试(Exploratory Test,ET)有如下几个发展阶段。

  • 原始期:1.0阶段,自由测试(free test)时期。出现启发式探索方法,但是实践中没有很具体的指南和打法。

  • 发展期:1.5阶段,启发式探索方法形成打法,具备可管理的模式。

  • 成熟期:2.0阶段,探索测试(ET)+脚本测试(ST)取长补短的测试风格。

  • 持续进化期:3.0阶段,强调一切皆可探索,各类业务形态、各种场景、各种团队、各种新的测试理念,都能演化为本团队最适合的原创探索测试方法及其匹配流程。

一开始,鼎叔觉得3.0阶段是个很虚的口号,随着在多个知名公司深入实践和理解,我感受到探索式测试理念的常用常新,它可以更自由地在新业务中沉淀新理论,给人惊喜。基于以人为本的敏捷价值观,探索式测试广泛适用于各种业务场景,并能被工程师赋予更多的创意和乐趣。

对探索式测试的误解

我参加过不少技术峰会的测试专场,大多数都是讲测试工程效能实践的,而讲探索式测试实践的主题基本没有。

“高大上”显然并不是探索式测试流行的理由,以下是探索式测试实践可能带来的好处:

  • 被用例文档约束的重复劳动减少了,个人感觉更轻松愉悦;

  • 能发挥更多的独立自主性,学习效果更好了;

  • 缺陷遗漏数量下降了;

  • 测试效率提高,测试占用时间缩短了等。

除了个人直观感受到的优点,还有一些在全员实践团队中可见到的收益:

  • 整个团队更重视用户体验问题了,每个角色对于质量的重视度都有明显增加;

  • 大家更团结了,更愿意互相探讨容易遗漏的测试场景;

  • 不同测试人员之间,不同岗位之间,更积极地分享找Bug的“独门绝技”。

尽管行业有不少成功的实践例子,但是坚持实践探索式测试的团队还是少之又少。究其原因,还是因为人们对探索式测试有以下各种误解。

误解一:探索式测试是自由测试、随机测试(random test),不利于能力提升。

探索式测试并非那么自由,有目的和策略的探索式测试才能更容易达成收益目标,高效引导方法也不断推陈出新。掌握它看似没有学到“硬本事”,其实能领悟更深刻的测试理论,吸收不少敏捷工程的精髓思想。

误解二:探索式测试不需要写文档。

探索式测试确实不需要写繁重格式的测试计划文档,但探索式测试可以产出原创的,有趣的,多种风格的,有价值的文档。

探索式测试需要的文档,可以是记下事前的牵引想法,事中的启发和变化记录,事后的风险判断,以及下一次的抓虫策略。

误解三:探索式测试是黑盒测试,技术门槛低。

探索式测试普及门槛低,任何人都可以快速掌握,可以快速进行黑盒探索。但这不意味着探索式测试只适用于黑盒。白盒测试和性能测试,同样可以引入启发,原创出探索式测试方法,能让问题挖掘事半功倍。记住,探索式测试是一种工作风格,不是一类特定技术,不限制具体技术的应用。

误解四: 探索式测试依赖员工的项目经验。

事实数据证明并非如此,并非在项目待很久的老手才能玩转探索式测试。很多新手员工探索问题的效率很高,甚至有自己独特的探索诀窍。而且非测试岗位员工,也可能在探索式测试活动中发现大量缺陷。

误解五: 探索式测试不借助任何工具。

探索式测试可以不借助工具,但也可以利用工具完成更多维度的探索。比如录屏/输入监听软件,接口工具,日志/调试工具,都可以是探索过程中的好帮手。

误解六:探索式测试通常在项目测试后期进行,那时已经测不出太多问题,发现问题也来不及解决了。

实际上,探索式测试可以在任何时期进行,初期探索可以尽快暴露更多问题,减少测试人员进入集成测试的负担。后期的探索测试可以多轮进行,通过探索的结果梳理对发布的信心。结合集体探索活动能在发布前又锁定一批遗留的风险问题。

总之,探索式测试不是漫无目的的测试,需要科学有效的指导方法

探索式测试与计划式测试

探索式测试天然适合周期短的敏捷研发,它与敏捷原则更加契合。这是计划式测试所不具备的。

在挖掘软件缺陷成本很高的年代,测试工具平台也不成熟,软件一旦发布后,出问题的代价很大,因此计划驱动的测试模式自然成为主流。但随着探索试错的成本不断下降,实时探索缺陷越来越成为软件研发团队的偏好,可以基于风险更加灵活地探索软件。

芬兰赫尔辛基科技大学做过一个实验,让79位软件工程专业学生执行测试,测试对象是包含真实植入错误的开源软件,每个学生分别用探索式测试和计划式测试,各做了两个90分钟的测程,从下面图中的数据,我们可以得到一个结论:除了性能测试和技术架构测试,其他测试种类在探索式测试风格下,都取得了更好的效果。

敏捷原则告诉我们,过度的前期设计必然产生大量浪费,而传统的测试计划也是在前期做了大量的设计考虑,往往力图通过事无巨细的用例覆盖,为后面的执行扫除风险,期待一劳永逸。因此这种依赖事前设计的计划用例,必然产生相当大的浪费,导致后面测试执行的盲目和低价值。这也是因为团队成员在质量风险评审上,通常不愿节外生枝,往往只做加法不做减法,担心减少用例导致严重漏测的话会被指责。

通常而言,测试活动光有探索,没有计划,或者光有计划,毫无探索,都不是最佳做法。需要团队不断寻找最佳的平衡比例。

计划式测试就像事先绘制好的地图,而探索式测试确实给地图的探险带来令人期待的变化,进而能补充更多高质量的测试脚本(用例)。

高水平实践的团队,可以看到计划式测试和探索式测试的价值是非常互补的,让总的缺陷挖掘水平保持高位。在测试的初期,计划测试可以发现较多的基础问题,对探索式测试投入精力就比较少,但在测试后期,计划测试发现的Bug越来越有限,自动化测试很难发现新缺陷,这时探索式测试会更有惊喜。

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483943&idx=1&sn=18546dc32de6ba632462b9e66d5a5e34&chksm=c24fb745f5383e5396d83da0cd9f7be004ed9471aa35302e8ba0ba9993189dfb133f03a95606#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 5366
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线