探索性测试--通过科学、创造力和直觉培养技能

104 阅读12分钟

QA测试人员必须不断学习和建立他们的测试技能。测试过程随着不断的速度释放压力而不断变化。问题是,无论花多少时间用正式的手动和自动测试脚本进行测试,缺陷都会出现在每个版本中。

传统的测试已经随着敏捷而改变,但敏捷测试在整体发布质量方面仍然需要改进。 测试人员如何才能快速、高效地在发布给客户之前找到bug?如何最好地持续发现bug并保护客户永远不会遇到哪怕是微小的、但令人讨厌的缺陷?在现代软件应用程序开发领域,客户体验是至关重要的。无论是严重的、轻微的、还是简单的、令人讨厌的缺陷,都是不能容忍的,因为客户几乎可以随意更换应用程序。那么,如何最好地利用创造力、科学和测试直觉来培养测试技能?

关键的收获。

  • 探索性测试需要什么?
  • 学习在探索性测试中富有成效和高效率所需的技能。
  • 它是简单的随机测试,还是有一个疯狂的方法?
  • 了解如何开始和使用什么技术。
  • 如何将科学与创造力和直觉相融合,以发现缺陷。
  • 使用探索性测试建立自动化和手动测试技能。

考虑通过接受探索性测试来提高质量和QA技能。使用探索性测试技术,QA测试人员使用他们的技术经验和对人类行为的理解来测试。探索性测试与敏捷开发以及其他方法论类型完美结合--勇敢地接受创造性测试。

探索性测试与敏捷开发配合得很好,因为一旦代码处于可测试的状态,测试就开始了。从设计、需求或验收标准审查开始,一直到开发周期的理论结束,探索性测试是持续有效的。

究竟什么是探索性测试?

探索性测试涉及到将计划、测试和执行结合到一组快速发生的同步事件中。探索性测试工作可以通过创建一个团队 "章程 "来计划。团队章程概述了哪些领域或功能要测试,由谁来测试。无论你是一个小的或大的测试团队的一部分,还是一个单独的测试人员,创建一个章程,它基本上定义了测试覆盖范围。章程为管理层和其他开发团队成员提供测试覆盖文件,或作为监管要求的发布测试文件或基本的发布跟踪。

章程还定义了测试的一般风格。例如,你是使用测试之旅,还是简单地采取每个主要功能,并创建测试 - 换句话说,作为一个新的用户探索应用程序,或一个经验丰富的用户希望尝试一个新功能。

探索性测试可以发展成书面脚本、检查表、即时完成,或根据设计、用户故事描述、需求或开发文档来执行。探索性测试的许多优点是灵活、快速、高效、有效,以及随心所欲的方法。

探索性测试需要有探索的意愿,从字面上看,是对一个应用程序的整体探索。唯一的要求是对应用程序和测试功能的访问。对应用程序的目的、设计和预期结果的理解是有帮助的,但不是必须的。测试人员只需要有冒险精神,愿意跳出脚本思考。

探索性测试 - 开始

测试人员的探索性测试技能来自于经验,对应用程序的理解,以及向开发人员提问的诀窍。我把它称为调查性测试。

测试人员通过以下方式调查设计和功能。

  • 与开发人员交谈,询问哪里的代码有变化。
  • 询问开发人员认为高风险或复杂的代码在哪里。
  • 早期积极参与,如果可行的话,参加设计评审、辩论和开发人员的代码评审。
  • 基本上,从开发者的角度尽可能多地了解代码设计和预期功能。
  • 与产品经理讨论需求或用户故事的接受标准,从客户和产品团队的角度充分了解预期的应用功能。

把握住调查的结果。接下来,绘制需要测试的应用功能图,牢记以下关键点。

  • 超越 "快乐的路径"--寻找通过应用程序的不快乐的路径。
  • 不要简单地确认应用程序的功能--测试要打破代码。
  • 审查你的测试地图。发现功能上的差距,也就是所谓的 "洞 "或不归点。

一旦你完成了调查并理解了应用程序的功能,就可以编辑测试地图或思维导图以保证其准确性。

心智图谱的应用功能有效地产生了一个关于测试地点的头脑风暴。你会发现后端程序,以及第三方应用程序、数据库连接和集成消息系统中经常被遗忘的漏洞。即使是最简单的应用程序,无论是移动还是网络,都会与另一个API或数据库连接。

如果思维导图看起来非技术性的,同样的信息可以用工作流程图有效地捕捉到。无论哪种工具有助于最好地可视化应用程序,使用它并将其与开发或产品团队的任何文件进行比较。发现任何差异吗?通常情况下,会出现差距以及矛盾。绘图或工作流程图使差距、矛盾和缺失的功能清晰可见,以便进行有效的测试。

给自己一点时间去挖掘并找到差距。分析应用程序在哪里以及如何拉动或推送数据到数据库,或其他连接的应用程序。检查页面数据刷新的时间和方式。如果应用程序允许用户在外部或内部生成电子邮件或短信,测试该功能是否按预期工作。与第三方消息系统的连接问题很多 - 看看你能找到多少没有记录的问题。

许多测试人员继续写出故事或通过应用程序功能的测试之旅。如果有时间,写出测试流程是可行的。我更喜欢节省时间,从我的思维导图或流程图上进行测试。重要的部分是确定单个用户以预期和意外的方式通过应用程序的功能的可变路径。

用你自己的经验来测试快乐路径以外的内容

探索性测试者通过使用他们自己的应用经验来发现缺陷。我们都在银行、零售和游戏应用中发现过缺陷。你是怎么找到它们的?你通过尝试以未预料到的方式执行一个功能来发现它们。在测试应用程序时,利用把应用程序搞乱的能力来发挥你的优势,寻找类似的缺陷。

例如,根据我的经验,我发现许多文档软件的处理子弹头和编号的列表的能力很差。我在编辑列表方面的挣扎比任何其他功能都多。通常情况下,抹掉列表,保存文档,然后放进一个新的列表,比尝试编辑现有的列表要容易。通常情况下,文本以某种方式离开了一行,一个回车或空格会使整个列表无法编辑。

另一个例子是,登录到一个银行应用程序,勾选 "记住我 "或 "记住这个设备30天 "旁边的方框。出于安全原因,这些登录选项是个坏主意,而且即使启用了cookies,这些功能大多也不会记住任何东西。我使用的几个银行和人力资源应用程序根本就不记得我,即使在我清除缓存和cookies之前或之后。
收集使用其他应用程序时发现的缺陷,并通过在被测试的应用程序中测试它们来利用知识。如果朋友或家人提出了应用程序中的缺陷,也要尝试这些。每个人对应用程序的负面经验都代表了探索性测试信息的金矿。

建立测试技能

作为QA测试员,对应用程序的整个深度和广度的探索越多,测试技能和本能的提高就越快。探索性测试的科学围绕着学习、探索和无畏地干扰所有可以访问的代码方面。

随着时间的推移,测试人员学习探索性测试方法,帮助他们直观地看到缺失的功能,功能上的差距或发现应用程序设计上的缺陷。通过不断的探索,QA测试人员发现了表面的缺陷和那些深埋在应用程序所依赖的后端处理代码中的持久性缺陷。

到目前为止,重点是探索性测试的手动测试方法。那么在探索性测试的同时培养测试自动化的技能呢?没有理由不利用测试自动化工具进行探索性测试。例如,无代码的自动化工具不需要编程知识,对创建自动化测试套件很有用。

人们可以利用他们的思维导图、流程图或应用功能的书面描述,用它们来创建自动化测试。测试自动化在小型功能组或模块式测试中效果最好。然而,人们可以简单地将可视化工具分解成功能模块,并对每个模块进行自动化。

为测试执行中的频繁失败做好准备。当使用自动化进行探索性测试时,预期会有频繁的失败和重做。记住探索性测试的目的是为了找到缺陷。而不是手动走一遍测试,使用自动化工具和记录模块化测试,并在测试完成后反复执行。

如果游览或较长的工作流程被用于探索性测试,那么尝试通过功能实现完整的端到端路径的自动化。看看自动化工具在整个工作流程中能走多远。最好的情况是,结果是一个自动化测试套件涵盖了某些工作流程的路径。这样的测试对于烟雾测试的执行或添加到针对每个版本或代码构建执行的自动化测试套件是很方便的。

在建立测试技术中加入科学、创造力和直觉

测试执行的创造性是一个被低估的QA测试员技能,但在任何类型的测试中都是非常有价值的。对于探索性测试的成功,创造性测试变得至关重要。测试人员如何利用创造力、科学和直觉来建立探索性测试技能?

正如之前所讨论的,不要无视使用个人的应用经验,并将其收集起来作为测试选项。在探索性测试应用程序时,一个恼人的应用程序、登录缺陷或个人使用的失败功能会成为信息的金矿。无畏地在预期之外进行测试,或者说是快乐的路径,创造创造性的测试方案。创造性测试的好处是不必重复执行相同的测试。创造性的测试会发现更多客户不需要经历的缺陷。

那么科学呢?使用心理学来分析开发人员和产品团队的优势和劣势。分析团队成员,了解共同的行为。当与一个开发团队长期合作时,了解团队成员容易犯的错误。有些人可能工作得很快,并得到了很多代码的检查,但他们有没有测试它?有单元测试吗?在测试他们的代码时,测试中发现类似类型的缺陷的频率是多少?开发人员如果不测试他们的代码,或者在合并到主代码分支后,会产生在本地环境中看不到的缺陷。与开发人员打交道的经验使测试人员能够使用探索性测试来快速发现缺陷,而不需要深入挖掘。

也要分析一下自己。你是否倾向于快速测试?还是你测试得太多了?了解个人的倾向、优势和劣势有助于发现缺陷。

例如,开发团队经常遇到沟通问题,特别是当应用程序代码在集成应用系统之间延伸的时候。当一个团队在后台改变一个功能时,会破坏另一个团队的代码。使用探索性方法的集成测试产生了频繁的缺陷。在另一个例子中,一个团队改变了API代码,而应用程序在另一个团队的领域中失败了。集成问题是通过探索UI和后端处理来寻找缺陷的福音。
探索性测试方法依赖于无畏的测试人员的创造力。一个探索性的测试者会找到替代的答案,走错路,不正确地执行功能,向后走,并重复点击按钮。探索性测试在框外进行测试,并在其他未测试的领域发现问题。要无所畏惧,就像终端用户一样,不知道有什么界限,也不看说明,而只是去完成他们的工作。