摘要:
有些人认为探索性测试是一项低成本思维的任务,测试人员只是浏览应用程序,看看会出现什么。然而我们不应该忽视这样做,因为有时它确实揭示了一些有趣的错误,但是测试人员在探索应用程序时可以遵循一些技术和模式。让我们来看一个在探索性测试中使用的两步过程。
我认为软件工程中最被低估的测试类型是探索性测试。有些人认为这是一个不费力的任务,测试人员只是浏览应用程序,看看会出现什么。
我们都知道探索性测试不是临时测试,这意味着需要遵循一些技术和模式。当我对一个经历了变化的软件应用程序进行探索性测试时,我使用这样一个两步过程。
步骤1:在不知道发生了什么变化的情况下接近测试中的应用程序。
这将确保现有行为不受影响,关键路径功能不会改变。如果您的测试失败,它将揭示应用程序已经经历的变更,这可能是预期的行为,也可能是在实现变更时引入的潜在缺陷。
但是,为了做到这一点,需要有一个关键路径产品计划,这样我就可以在每次做出更改时参考它。并且这个产品计划需要由整个团队来更新和维护。
步骤2:在完全了解预期行为之后,接近被测试的应用程序。
这需要对用户需求文档进行彻底的分析。测试人员需要与工程和产品团队成员密切合作,以了解影响的领域,这反过来有助于发现边缘案例。这也需要完全理解端到端的产品行为,最重要的是集成点。
让我们看一个例子来更好地理解探索性测试的重要性以及上述两种技术是如何有益的。
假设我们有一个允许用户上传文档的软件应用程序,它是使用多层架构实现的:
表示层—帮助用户上传、替换、删除文档以及从服务器上的文件夹下载文档的GUI
应用层—运行业务逻辑,如验证文件类型、验证用户权限等。
数据层—存储上传的文件、审计条目等。
该应用程序目前仅允许具有特定角色A的用户上传pdf文件。产品团队要求的更改是不再允许具有角色A的用户下载文件,并将添加一个新角色,角色B,它可以上传jpg和png文件以及pdf文件。
在这个改变实现之后,就由测试人员来做探索性的测试了。在步骤1中,在不知道发生了什么变化(上传jpg或png文件的能力)的情况下,测试人员最初会尝试上传pdf文件,用另一个pdf文件替换它们,删除,并以角色a的用户身份下载上传的pdf文件。因此,当测试人员尝试下载pdf文件时,该测试会失败,因为该角色的这一更改会删除该能力。实现的变更不应该中断任何其他流程。
这种方法将确保现有的关键路径功能不受影响,并且还揭示了一个不允许测试人员前进的变更,提示他们前进到步骤2。
现在,测试人员浏览用户需求文档,并分析所需的更改。影响范围将包括架构的所有三层,因此将为每一层设计测试:
表示层——错误消息措辞、操作简便性等。
应用层—文件验证和与权限相关的测试
数据层—文件大小和审计条目
到现在为止,你可能认为这些是每个测试人员在测试应用程序时通常采取的步骤。探索性测试在哪里出现?
假设在执行上述步骤时,您拍摄了一个截图,该截图被保存为jpg格式,文件名中包含当前日期和时间戳。由于日期和时间格式的原因,它有特殊的字符和空格,当这个文件上传时,它将无法通过测试,因为文件名中的空格将被转换为“%20”,代码可能无法处理它。
这个事实不会在测试计划或验收标准中提及;只有从不同的角度探索应用程序,才能发现这个问题。
当你试图用自己的方式解决问题时,你会发现一个全新的视角。其他人可能已经用任何图像文件测试了这个过程,但是因为一个测试人员使用了一个截屏,它暴露了这个问题。
文件的可用性可能是下游应用程序的关键要求。这个问题也可能在集成测试过程中被发现,集成测试是进行探索性测试时要记住的另一个重要测试。确保记住所有的集成点,并从这些点提取或向这些点推送正确的数据是非常重要的。
在这种情况下可以完成的另一个测试是负载测试。应用程序还应该处理试图下载同一文件的并发用户。一个探索性的测试人员还应该有能力在真实的场景中描绘应用程序。
探索性测试是关于以不同的心态,作为不同的用户来思考,并且在考虑用例的所有可能性的同时检查应用程序的所有层。
有几个工具可以用来遵循这项技术。我一直热衷于制作思维导图来表示应用程序的端到端功能。它帮助我无缝地找到有影响的领域,避免因错综复杂而陷入困境,忽略大局。
此外,探索性测试并不总是与手动测试相关联。探索性测试的结果可以揭示需要自动化测试的领域。
为了有效地执行探索性测试,团队的每个成员都遵循一套测试过程是很重要的。每个人都需要兼任测试的职责,在软件开发生命周期的某个时刻进行探索性测试,从需求收集开始,一直到变更发布到生产。