• 0
  • 2
分享
  • 测试你不能看到的地方:在覆盖模型里的风险盲区
  • 恬恬圈 2019-11-06 13:51:21 字数 2008 阅读 2130 收藏 2

摘要:

我们思考,什么需要测试覆盖是“完整的”的方式,影响了我们如何测试和创建的测试用例。毕竟,一般情况下你只会为发生在你身上的情况设计测试——正常来讲,你也只能测试那些看得到的东西。是时候该脱下眼罩了。下面介绍如何能在你的产品中找到发生bug的地方,接着调整你的策略来精确地定位到它们。

当我在一家保险公司工作时,我处理了大量的数据提取程序。在那段时间里,我从来没有见过一个需求文档来指明数据库关闭时应该做什么,即便大多数测试都是基于这些需求的。

任何专家都可以使用需求文档并创建一个地图、要点或电子表格来构建一个“覆概率模型”。整个软件公司都存在可视化这些模型,当测试“覆盖”到这些功能时,把它们设计成全部从空白闪烁到绿色。

然而,不可避免的是,当接口在运行而数据库关闭的时候,将会发生什么事情……不可预知。

到处都是盲点。我们就是看不到它们。


自动化测试

在类似于客户测试的世界中,今天对测试的主要思考方式是基于用户界面和工具。按住一个按钮,看着屏幕飞过(或基于云的客户端),然后一个小时后回来并得到结果。这是惊人的——几乎是神奇的。

我使用这些工具的经验是它们不能打印,或者说如果它们能,这些工具缺少检查生成的PDF文档是否呈现正确文本能力。它们当然不能检查结果是否正确。大多数工具甚至不能通过模拟的对比发现错误的地方。当一个人可以在一个复杂的表单上连续按十次tab键来检查tab顺序时,这项工作是如此难以编程,以至于大多数人都跳过了对tab顺序的任何自动检查。

工具变得越来越好。几年前,人们常常混淆屏幕,使按钮或链接不可见,因为它隐藏在其他东西下面,但是Selenium之类的工具可以单击它。今天,一些工具解决了这个问题。其他人添加了对屏幕的一部分进行用户界面比较的功能,以及用于快速审批的工作流。

不过,你还是明白我的意思。该工具使测试打印成为不可能。当我们不为打印创建自动化测试时,最终我们将停止测试打印。

我们认为测试的覆盖率是“完整的”,或者“测试是完整的”可能意味着什么,这将影响我们所做的事情。


功能测试

当我教授测试时,我早期的经验之一是关于失败模式的——也就是说,软件可能崩溃的方式。这包括两种常见的缺陷,比如程序员反复犯一些相同的错误. (“不管他们接触到什么,开发者似乎总是在破坏ALF组件”),以及平台常见的故障模式。如果我在用一个低成熟度的团队测试一个移动应用程序,我可能会尝试从拥有无线数据到没有覆盖,然后再回来。

对于具有复杂图形的web应用程序,我将大量调整窗口的大小。我将打开多个选项卡并在它们之间切换。我将在平板电脑上试用这个应用程序,然后把平板电脑翻转过来。我将发送一个链接到另一个需要登录的设备,并尝试在不登录的情况下访问链接。所有这些都是响应式设计的常见故障模式,但我从未在任何仪表板或正式的测试步骤中看到过它们,除非我的公司创建了这个列表。

也许资深人士“只知道”要根据经验来测试这种方法。资历较浅的人当然不会。测试方向变得越规定性,我们越专注于把事情写下来以便我们可以雇佣低技能的人,我们就越有可能得到这样的结果:人们完全按照测试说的去做,他们错过了所有的错误。

使用测试工具,这不是一个风险;它是保证。自动化工具只会按照您的要求去做。与此同时,评估调整窗口大小的结果是一项非常复杂的任务,非常难以编写。

因此,人们不需要记录自动化或构建逻辑来模拟这些行为。

也许,在某种程度上,这是可以的。另一位测试培训师詹姆斯·巴赫(James Bach)曾告诉我,有些人不想花钱买手工制作的木制家具。对他们来说,便宜的、自己组装的配件就足够了。制定计划,让电脑来做裁剪——够好,毕竟,足够好。

但是在软件中,廉价的、千篇一律的测试(和测试工具)意味着缺失bug,这可能是因为覆盖模型没有考虑它们。


新策略

这里有一种方法,可以让你在午餐时间和一天之间找出你错过了什么。

看看在过去的6个月里,程序员漏掉的所有bug。(如果你的敏捷团队没有跟踪这些,你可能想要开始,至少在短时间内。) 对于每一个人,不要把它与根本原因联系在一起,而是与他们将如何被看见——他们如何显现——联系在一起。

然后查看每种减少缺陷的机制,从代码评审到人工探索再到工具。如果可以的话,问一问你现有的正式流程是否已经发现问题,而且如果确实是已经发现了也需要问一下。

接下来做两件事。分别从人员和流程两方面着手,以防止整个类别的缺陷,并消除盲目性。找到bug所在,并调整测试策略来找到它们。考虑一个覆盖模型,它是关于缺陷类型的,以及您使用测试、检查、观察和走读来“覆盖”它们的所有方法。

我们有理由为盲人辩护;他们帮助马直走。它们也阻止了探险。

谁想要?


版权声明:本文出自51Testing会员投稿,51Testing软件测试网及相关内容提供者拥有内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •  一、API调试常用解决方案1、Postman + Swagger + Mock + JMeter作为一个后端开发,我做的大部分项目一般都是基于 Swagger 来管理 API 文档,基于 Postman 来做接口调试,基于 JMeter 来做接口性能测试,基于 RAP 等工具 Mock API 数据。2、存在的问题(1)多系统数据不互通API设计者、前端开发、后端开发、测试人员大量重复工作。(2)效率低可视化程度低、操作不友好。(3)无法团队协作单机离线使用为主,成员之间无法实时同步数据,无法协作。(4)学习成本高初学者难以入手,需要大量的学习成本、培训成本。(5)数据一致性困难每...
            0 0 839
            分享
          •   敏捷  敏捷是什么?  区别于传统的模型,敏捷是一个迭代式的研发模型。  敏捷开发的最大特点:高度迭代,有周期性,并且能够及时、持续地响应客户的频繁反馈。有时候讲究所有人集中所有精力快速完成一件事情。  敏捷测试(Agile testing)  测试的一种, 主张尽早开始测试,重点关注持续迭代地测试新开发的功能.。敏捷的测试团队还要保证整个软件开发过程是正确的是符合用户需求的。  遵循:  1、强调从客户的角度,即从使用系统的用户角度,来测试系统。  2、重点关注持续迭代地测试新开发的功能,而不再强调传统测试过程中严格的测试阶段。  3、建议尽早开始测试,一旦系统某个层面可测,比如提供了模...
            0 0 681
            分享
          • 1、基于webdriver的分层自动化框架及平台搭建,目前刚好在做这一块的工作,对于分层次和平台搭建,想问下大神有什么好的建议?我们拿数据驱动框架来举个例子。下面是我做的一个简单的框架样式:这样一个结构,分为base层(公共用例),element(元素层),properties(UI map层--properties文件),resource(资源层),task(存储suite的testng文件),testcase(case层),util(底层,方法层)。用这样一个结构来更容易理解,更便于维护我们的框架。当然,这是一个基本demo哈,可以根据自己的实际情况扩展。总之,没有最好的,只有最适合的,哈...
            0 1 2302
            分享
          •   很多小伙伴工作在功能测试行业工作了2、3年后,发现自己已经把功能测试做的非常好了,已经到职业发展和薪资发展的瓶颈期了,就想着学点东西,提提升一下技能。  而对于功能测试升级来说,一般有这么3个主流的发展方向:一是性能测试,一是接口测试,一是自动化测试。当然啦,还有很多可发展的方向,但是最热门的应该就是这3个了。尤其是自动化测试,更是成为了很多小伙伴的主要目标(毕竟大厂招聘比较多)。所以,接下来,我们就一起来聊聊自动化测试的内容。  1、什么是自动化测试?  根据百度的解释,自动化测试就是指:软件测试就是在预设条件下,运行系统或应用程序,评估运行结果。预先条件应包括正常条件和异常条件。自动化...
            0 0 945
            分享
          • 一、重新理解测试用例今天,我们进入本次课程的第一个模块,重新理解测试用例。理解测试用例的定义对测试工程师这个职业,我们接触的第一个专业名词,大概就是测试用例了。那么,我们有没有仔细想过,什么是测试用例,测试用例的作用和意义是什么。我们先来看一下百度百科里怎么定义测试用例的:>测试用例是为某个特殊/定目标而编制的一组测试输入、执行条件以及预期结果,用于核实是否满足某个特定软件需求。这个定义有些过于书面化,我们尝试换一种表达方式来帮助大家理解:>测试用例指的是对需求功能每一个功能路径的输入输出结果的预期设定,用以检查程序编程设计是否符合产品需求定义。这里面有两个部分,首先,用例是一种预...
            0 0 70
            分享
      • 51testing软件测试圈微信