问:在功能实现之前,探索式测试是不是无用武之地?

  答:对于探索式测试有一个误解,那是探索式测试只通过运行测试以获得知识。实际上,探索式测试者能够也必须通过其他手段探索被测试软件。

  语境驱动测试认为:产品是一种解决方案,它必须解决现实世界中的问题。因此,探索式测试者必须从项目关系人(包括软件用户、项目投资人和开发团队等)的视角考察整个产品,研究显式规格说明和隐式规格说明,从而发现软件在概念、需求、设计、实现等层面上的缺陷。值得强调的是,测试人员应该主动探究隐式规格说明,从而拓宽探索的范围。以下是一些常见的隐式规格说明。

  竞争产品。竞争产品不一定是软件,例如笔记软件的竞争者包括纸质笔记本和铅笔。

  相关产品。软件套装(如Microsoft Office)中的软件往往相互补充、相互约束。

  同一软件的已发布版本。向前兼容可能是非常重要的约束。

  口头讨论、采访、闲聊。

  电子邮件、会议记录、采访记录。

  用户反馈:电话支持记录、论坛讨论、Beta测试反馈。

  技术反馈:软件提交的崩溃信息、错误消息。

  第三方评论:杂志文章、博客文章、社交网络反馈。

  技术标准。所有软件都建立在一系列技术标准之上,某些标准会对测试产生重要影响。

  法律法规。法律可能对软件有强制性约束。

  领域专著。测试财会软件需要学习相关著作,以掌握财会知识。

  测试人员经验。

  Cem Kaner拥有法律学位,对语言文字非常敏感。他认为积极阅读(Active Reading)是探索式测试者需要具备的技能。积极阅读是一个内涵丰富的主题,广受好评的经典书籍包括《如何阅读一本书》 、《探索需求》 和《你的灯亮着吗?》 。

  此外,在功能实现之前,可以通过小组讨论、头脑风暴等方式发掘测试策略和测试思路。针对一个开发中的功能,测试人员可以邀请几个同事,组织一个测试研讨会。在会议上,大家自由发言,提出自己的测试策略,通过脑力震荡相互启发,从而获得一批观点各异、视角不同的测试策略。会后,测试负责人对这些相对粗糙的测试思路进行整理,将完善后的结果写入测试计划。

  问:如何评估探索式测试的测试效果?

  答:评估探索式测试结果的前提是测试记录。

  探索式测试者常常在一个固定的时间窗口内(60~120分钟),根据预设的测试目标,对软件进行Z探索式测试。这样的测试活动被称为测程(Session)。

  测程类似于科学实验。一次科学实验大致可以分为以下三个阶段。

  (1)实验设计:确定实验目标。科学实验的常见目的是假设检验,那么此次的假设是什么?

  (2)实验记录:执行实验步骤,并记录实验所发现的点点滴滴。

  (3)实验分析:分析实验数据,总结实验结果,为下一次实验提供目标和假设。