上海架构师集结!4月25-26日,全球架构师峰会首次落地上海,吴翰清、汪源、叶绍志等大咖确认出席 了解详情
写点什么

书评 - 《展望敏捷软件测试》

2015 年 5 月 04 日

借 Selenium 诞生十周年庆典之机,来自于 ThoughtWorker 公司的几位专家共同推出了一本精选书,其中收录了他们在软件测试方法、工具和文化方面的一些文章。这本精选书以电子书的形式提供,书名为《展望敏捷软件测试》(Perspectives On Agile Software Testing),可以在ThoughtWorks 的网站上进行免费下载。

本书的篇幅虽然简短,但包含的信息量却相当丰富,其中提到了测试工具的演变、在敏捷环境中的测试、对移动设备进行测试、对移动应用使用BDD 及持续交付等等。本书中的某些部分很有看点,例如对不同工具的比较。虽然篇幅简短,但内容丰富,对移动设备的测试进行了深入的描述,包括持续集成与持续部署等概念。

Anand Bagmar 首先介绍了 Selenium 这一工具及它的使用方式。2004 年,Jason Huggins 在对 ThoughtWorks 的一个内部应用程序进行测试时,创建了 JavaScriptTestRunner 工具,正是它改变了对基于浏览器的测试进行自动化的方式。该工具随后演变成了“Selenium”,并最终实现了开源。

Alabe Duarte 和 Fabio Maia 介绍了移动测试方面的内容。在移动测试中常见的挑战包括测试内网延迟、3G/4G 连接、WiFi 以及与地理位置相关的特性。为了对 web 应用进行测试,并且保持单元测试的快速执行,他们会经常使用 Test Double(替身)。这种技术有助于避免代码与任何进程或无法控制的外部依赖进行通信。这方面一个非常有趣的例子是 Appium,它允许任何人为基于不同语言开发的移动应用编写测试。Appium 能够实现这一点的原因在于它实现了 Selenium 的 webdriver API,因此每种语言都可以通过 webdriver 与之进行连接。

Prateek Baheti 和 Vishnu karthik 接下来介绍了在移动应用中进行 BDD 风格测试的方法。在 BDD 风格测试中,通过一种中立的、并且非常特定于具体领域的语言表达出测试的规格。BDD 的实现需要工具的支持,通过工具将测试规格与底层的实现结合连接在一起。

作者举了一个例子,描述了某个消息发送应用的一个具体测试场景:

  • 我要以 foo@foo.com 帐号登录
  • 我对 user@user.com 发送了一条消息“Lorem ipsum dolor sit amet”(一段著名的用于测试排版的假文字)
  • “user@user.com”会收到一条通知,告诉他有新的消息来了

以上这个测试不会与底层的细节打交道,而是以自然语言、使用领域术语描述了这一测试场景。在这个测试用例中,收到一条通知就是一个领域术语,而它的具体实现在不同的平台上可能是完全不同的。

Gayathri Mohan 介绍了在移动应用中使用持续交付方面的内容。在这一章节中,她在对移动应用进行手动测试或自动化测试的上下文中对持续交付进行了阐述。她还对持续集成和跨平台自动测试框架进行了深入讲解。

InfoQ 有幸与本书的作者们进行了一次访谈,话题涉及了本书的内容,以及测试方面的最佳实践。

InfoQ:对于读者来说,阅读这本书能学到什么新东西?

本书收集了一系列优秀的文章,它们从不同的维度对测试进行了讲解,包括——

Anand Bagmar 在书中分析了 Selenium 是否已经成熟,使用 Selenium 实现自动化与测试自动化金字塔(Test Automation Pyramid)有怎样的关系。并且对这个时代的测试人员如何做好准备迎接未来的挑战提供了一些建议。

  1. Daniel Amorim 分析了在敏捷环境中进行测试的各种不同维度。
  2. 有大量的内容是关于移动测试的
  3. 对移动设备进行不同类型的测试(Alabe Durate 和 Fabio Maia),
  • 如何在移动应用中开展 BDD 风格的测试(Prateek Baheti 和 Vishnu Karthik),
  • Gayathri Mohan 将这一点更进一步,探讨了如何在应用程序中实现持续交付。
  • Vikrant Chauhan 和 Sushant Chaudhary 介绍了在移动测试中可能遇到的各种挑战。
  1. Nicholas Pufal 和 Juraci Vieira 为读者分析了对 BDD 的误解。
  2. Paul Hammant 介绍了如何聘用具备不同级别专业知识的 Selenium QA 人员。

InfoQ:你们在书中提到了测试金字塔反模式,能为我们详细解释一下吗?

自动化测试的目的在于为团队提供快速的反馈信息:最近的某次改动是否造成了原先能够正常运行的功能出现了故障?

Martin Fowler 在他的博客帖子中对测试自动化金字塔进行了解释。

在理想的测试金字塔中,发生在最接近于源代码的地方的自动化测试数量应当最大话,例如在单元测试这一层,而发生在金字塔顶层的测试的自测数量应当最小话,例如在功能性 UI(用户界面)层。此外,单元测试应当对产品代码中的细粒度的片段进行测试,而 UI 测试应当专注于对构建与部署后的产品进行业务功能方面的确认,例如对用户的访问过程和场景进行测试。不过,要实现并长期维持一个“良好”的金字塔,需要团队在流程和实践方面投入巨大的精力。

许多团队对于(各种类型的)自动化测试的投入依然有所不足。有些团队采取了某种快捷方式,在代码开发完成之后,设立一个独立的团队专门编写 UI 层的测试。而这种方式的结果是,团队对于金字塔底层的自动化测试方面的关注相当不足。而且,就如大家都意识到的一样,UI 自动化的实现和运行都相当缓慢,并且非常容易被破坏,对于 UI 任何一点微小的改动都有可能造成测试失败。因此,尽管许多团队已经在 UI 自动化方面投入了许多资源,但他们还是要将大部分的精力投入到对 UI 测试的缺陷修复、更新以及维护上,并且需要专门安排一组测试人员手动地进行重复式的回归测试。这就形式了一种蛋筒式反模式(Ice-Cream Cone)(即倒金字塔形状)。

有些情况下,测试团队是整个组织中的一个独立团队,或者有可能将测试任务交给第三方或合作伙伴完成。他们对于产品的测试方式无法达到开发者之间那样的合作能力。开发者与测试者之间也不会对于哪些测试要进行自动化,哪些不需要自动化等方面进行交流。其结果是可能会产生开发者与测试者之间的测试用例产生了重复。而更严重的问题在于,在自动化测试中有可能会遗漏许多测试用例或测试场景。这是一种双向测试金字塔反模式

Fabio Pereira 用另外一种有趣的方式对双向测试金字塔反模式进行了描述,并将其称为纸杯蛋糕反模式(Cupcake)。他也提出了某些技术,可以通过使用这些技术让团队远离这些反模式,而实现理想的测试金字塔。

InfoQ:书中提到,QA的角色正在变得越来越复杂,他们需要进行心态上的转变,同时在技术方向上也要需求突破。请对这种说法表达一下你们的意见。

当团队开始使用敏捷开发方法之后,团队中的每位成员都需要加快他们工作的脚步。下面这张图来自于 Agile QA Process ,它表现了 QA 人员在每个迭代中需要经历的一系列活动。

在短小的迭代中,这一流程会显得非常紧张。此外,QA 通常在这种工作方式中通常需要经历三个不同性质的阶段。

  • 过去 —— 对于之前迭代中完成的工作提供支持。
  • 现在——保证创建的特性是“正确”的,并且实现的方式也是“正确”的。
  • 将来——对于下一阶段的开发中可能到来的任务做好准备,并且开始考虑如何对其进行测试。

最后,自动化测试对于保证团队取得成功是一项必不可少的要求,而为了让团队实现这一点,QA 在其中扮演了十分重要的角色。这不仅要求 QA 具有优秀的手工测试和探索性测试技术,并且要求 QA 对于测试中的产品在技术方面也要有相当程度的理解,从而保证确定了正确的测试,并且在测试金字塔的正确环节实现自动化。

由于 QA 在这一流程中需要经历大量的活动,并且经历这些不同的阶段,因此他(或她)需要对工作的方式进行优化,并且做到对下一阶段必须要做的事持续不断地对优先级进行适当的调整。因此,QA 这一角色变得更加复杂,为了取得成功,必须换一种不同的思考方式。

InfoQ**:你对 QA在三个不同维度中所扮演的角色:商业、技术与 DevOps进行了很好的诠释。QA**在这三个方面的不同角色有哪些相似之处和不同之处呢?

这三个维度的共同点在于,QA 对于产品的质量和自动化测试必须具有主人翁意识,他们需要让团队专注于交付高质量的产品,确保它易于维护和实现新的特性。

这三种类型的 QA 之间也有一些不同之处:

  • 在商业维度上的 QA 是由业务驱动的,并且需要很好的与客户交流的沟通技巧。他们将通过各种示例对产品规格有一个很好的了解,并且需要具有优秀的聆听技巧,以从客户那里获得所需的验收测试项目。
  • 在技术维度上的 QA 具有优秀的编程技术,并成为自动化测试方面的专家。他们对关注代码的可维护性,总是寻求各种优秀的实践,例如整洁的代码、最佳实践和设计模式等等。这些 QA 会与开发者结对工作,共同创建解决方案。
  • 在 DevOps 维度上的 QA 需要具备持续交付与对重复性任务进行自动化的知识。他们将帮助团队打造一个测试金字塔,以实现某种持续交付的周期。

InfoQ**:本书介绍了 Appium这门工具,它实现了 Selenium webdriver API,专门用于移动测试。那么这个工具与其它类型的移动测试工作有什么不同呢?使用它能为我带来怎样的好处?**

Appium 的社区非常活跃。由于它的开源本质,有许多贡献都是来自于社区,这也使它能够更快地实现新的特性和修复缺陷。并且如果你需要在云端环境中运行你的测试,以实现更大的规模,Saucelabs 服务同样也支持 Appium。

并且由于它实现了标准自动化规格,因此可以很容易地找到一种以你所熟悉的语言编写的 Selenium webdriver 的具体实现。比方说,QA 团队可以很容易地找到 Java 语言 (Android) 或 Objective-C 语言 (iOS) 以外的不同实现。

其它的好处还包括:

  • 如果你的移动应用是跨平台的,那么你也能够在每个平台上都使用相同的测试。
  • Appium 能够对接近生产版本的应用进行测试,更妙的是,即使是你打算提交到 marketplace 上的版本,Appium 同样可以进行测试。

InfoQ:对于持续集成和持续交付在移动应用开发中的重要性,你们是怎么看的?

在这个快节奏的社会中,作为商业组织,我们需要尽快地将产品和服务展现给用户,但是,如果产品本身质量不过关,那么仅仅做到快速推向市场也是不够的。持续集成(CI)持续交付(CD)这样的实践能够让团队在将产品交付给客户时充满信心。

这些实践适用于基于 Web 的产品,同样也适用于基于移动的产品。区别仅在于使用的工具不同,并且需要对这些实践的各个部分进行微调,以确保得到最佳的结果。

InfoQ:在移动开发中使用 BDD有什么好处呢?

BDD 最大的好处在于,团队之间可以用相同的领域术语和业务术语进行交流,最终可以消除在项目干系人和团队成员之间产生的所有理解的歧义。

如果能够正确地使用 BDD,那它就能够隐藏实现细节,并且帮助开发者专注于该特性或功能所试图解决的商业目标。

如果能够正确地使用 BDD,它就能够隐藏特定于平台的细节。

*:就像其它任何工具一样,你必须正确地使用 BDD,并且使用在适当的上下文中,这样才能够发挥出它的价值所在。

**:BDD 意味着你在你的开发环境中又多加了一层额外的代码(和工具)。无论你添加了哪种类型的工具或流程,它都伴随着相应的成本。在你决定在开发周期中使用任何工具、技术和流程之前,都应该全面地了解它的所有优点与缺点。

InfoQ:对于敏捷 QA来说,最关键的技术是什么?

除了必备的测试技能之外,以下技能(排名不分先后)对于 QA 在敏捷团队中获得成功也是相当重要的:

  • 能够对不同的测试活动排列优先级的能力。
  • 要将心态转变为:“帮助团队实现迭代中所包含的每个需求的‘完成定义(Definition of Done)’。”
  • 与业务分析师或产品负责人进行协商,以探讨当前阶段需求的真实价值,以确保在短时间之内创建出“正确”的产品。
  • 保持开放的心态 —— 这有助于你以一种更优的方式学习新的工作方法。
  • 尽可能帮助团队在测试金字塔的底部实现自动化。

InfoQ:你们是否打算在不久的将来,在新书中涵盖更多有关敏捷和测试的概念。

我们对于下一本书已经有了许多点子,它将基于这本书中已经涵盖的内容。不过,我们也乐于倾听读者的意见,我们会尽量在下一本书中加入他们在反馈和建议中所提到的内容!

关于本书作者

Anand Bagmar是一位动手能力很强并且注重结果的软件质量福音传道师,在 IT 领域已经具有 17 年以上的经验。他创建了各种与软件测试相关的开源工具,包括 WAAT(Web Analytics Automation Testing Framework)、TaaS(用于在不同系统间进行的集成测试进行自动化)以及 TTA(Test Trend Analyzer)。

Daniel Amorim在 ThoughtWorks 担任敏捷顾问 QA。他从 2007 年开始在 IT 领域开始工作,始终致力于提倡敏捷测试的最佳实践,并为开发团队作出贡献。

Alabê Duarte从 2007 年起在 ThoughtWorks 担任顾问开发者。

F****ábio Maia是 ThoughtWorks 的一位高级开发顾问。他对于由 Qt/C++ 或 C#编写的桌面应用程序特别感兴趣,他也是一位使用 C#/XNA 的游戏开发者。

Prateek Baheti是 ThoughtWorks 的一位应用程序开发者,他参与 Twist 项目已经有两年的时间了。

Vishnu Karthik是 ThoughtWorks 的一位开发者。他曾经参与过 Twist 和自动化测试的项目。

Gayathri Mohan是一位 ThoughtWorks 的高级质量分析师,在公司里有超过 5 年的经验了。她的工作经历包括多个领域,例如旅行、零售、电子商务,以及多种平台,例如.NET、Rails、Android 和 iOS。

Vikrant Chauhan是一位技术狂热分子。他密切地关注开源测试工具的发展,并且总是在任何可能的情况下使用它们。

Sushant Choudhary是一位充满热情的技术爱好者,也是一位体育迷。考虑到不断变化的技术方案和它对社会的影响,他总是时刻进行探索,并且在软件工程中应用新的开发技术。

Nicholas Pufal从少年时代开始就对编程产生了浓厚的兴趣,当时他已经开始尝试编写开源代码项目了。他对于设计模式、优秀的开发实践,以及改善敏捷团队的沟通技巧和交付质量的各种方式保持着很高的热情。

Juraci Vieira也是一位技术狂热者,他的职业生涯开始于测试人员的岗位。他被自动化所深深吸引,然后才明白质量本身就是由软件产生的,从那之后,他摇身一变成为了一名热情洋溢的开发人员。

Paul Hammant已经 40 多岁了,他从 2002 开始就在 ThoughtWorks 担任首席顾问,1989 年起就进行各种顾问工作。除了从客户那边赚钱之外,他也常常帮助 ThoughtWorks 进行各种开源活动。

查看英文原文: Perspectives On Agile Software Testing - Book Review

2015 年 5 月 04 日 13:542613
用户头像

发布了 428 篇内容, 共 149.3 次阅读, 收获喜欢 20 次。

关注

评论

发布
暂无评论
  • 敏捷开发领跑传统测试

    这篇报道探讨了为什么敏捷开发跑到了传统测试的前面,原因是什么,以及最近有什么新的敏捷测试趋势。

  • 开篇词 | 把接口测试这件小事做深、做透

    接口测试不只能发现范围更广的Bug,也逐渐成为测试工程师一项必备的工作技能,在这个专栏我会带你深入学习这项技能。

    2020 年 2 月 3 日

  • 如何在 iOS 中进行面向测试驱动开发和面向行为驱动开发?

    在今天这篇文章中,我和你讨论的是,在iOS开发中,如何进行BDD和TDD。

    2019 年 5 月 16 日

  • 10 款好用的自动化测试工具

    我们都希望为我们的Web应用程序构建易维护的测试。作为这个目标的一部分,我们都希望能集中精力在测试本身,而尽量避免困在实施的具体细节中。

  • 实现 ATDD 的快速指南

    协作是敏捷方法的核心价值观之一。也就是说,您要留意如果敏捷团队中的开发人员、测试人员和业务人员之间缺乏协作,会发生什么? 本文提供了在您的项目中实现验收测试驱动开发(ATDD)的快速指南,以缓解由于缺乏协作而导致的问题。

  • .NET 里的行为驱动开发

    越来越多人把行为驱动开发看作实施测试驱动开发的另一种方式。SpecFlow和NSpec是.NET里比较流行的BDD框架。它们协助创建即使不是程序员也能读懂的测试规范,并允许软件的目的驱动它的开发。

  • 敏捷是怎样改变测试管理的

    敏捷方法中内建了许多传统的测试管理活动,随着人们对敏捷团队特性,例如自组织、角色的模糊化以及技能的多样性的期望,测试管理的性质也随之改变了。我们必须回答的问题是,在高效的敏捷组织中,测试经理这一角色是否还有存在的必要?这一角色一直以来所从事的这些活动又是如何被剥夺的呢?

  • 持续交付会如何影响测试

    如果要做持续交付,那我们必须关注我们写的代码的质量。不是所有团队都配备专门的测试人员,但如果有测试人员的话,他们会和开发人员紧密合作,编写在单元测试中无法覆盖的少数测试的自动化代码,并帮助开发人员搭建单元测试。

  • DevOps 中的工程师测试

    Clokie与 InfoQ进行了交流,讨论了她在测试领域看到的变化,以及拥抱DevOps原则对这一变化的进一步影响。

  • 敏捷方法在测试计划中的应用

    在 Agile Testing Days 2015大会上,Eddy Bruin和 Ray Oei解释了如何在不编写大型测试计划的情况下,满足干系人对测试用例、测试计划和其它测试工件的需求。InfoQ就测试计划在敏捷中的应用、如何让干系人意识到他们能够影响质量,以及他们推荐的敏捷测试实践问题对二人进行了采访。

  • 2020 年软件测试状态报告

    “2020年软件测试状态报告”在测试技术、测试实践、测试自动化的采用以及测试人员所面临的挑战方面提供了见解。

  • TDD 团队中的测试人员

    实施TDD(测试驱动开发)实践的团队不再需要测试人员进行手工测试。对于测试人员来说,这种改变意味着他们以往所熟悉的工作内容逐渐消失了。同时,现代化的测试解决方案包含了更多技术性内容,因此需要专家的参与。对于测试人员来说,这是一个非常有吸引力的机会,但他们必须掌握扎实的技能。

  • 浅析敏捷测试及其实践运用

    随着互联网技术的发展,产品的快速迭代且能适应市场需求已经成为各大公司的痛点。而传统的开发模式已经不再适用于快速迭代的产品,在这种情况下,敏捷开发模式因其高度迭代、频繁交付以及适应变化的特点,已经在各个领域得到广泛应用。

  • 大数据实战:测试工具领域应对海量数据的解决方案

    演讲嘉宾 孔祥云,京东高级测试开发工程师。 内容介绍 在进行测试工具开发的时候,如果碰到了海量数据,应该采用什么架构去处理。在实践过程中有些已经踩过的坑,将通过实战方式给大家讲述其中过程。 演讲大纲 接口的稳定性数据非常重要却对其利用程度有限,构建系统进行更加直观的展示; 稳定性监控系统直观展示多时间跨度、多场景下的应用的稳定性数据; 介绍稳定性监控系统在数据采集、Storm实时计算及数据存储的技术难点解决方案; 智能测试平台利用线上引流的数据进行推荐的方案介绍。

    2018 年 9 月 12 日

  • 发挥人的潜能:探索式测试

    通过今天这篇文章,我阐述了一个基本思想是:探索式测试是一种软件测试风格,而不是一种具体的软件测试技术。

    2018 年 10 月 5 日

  • 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?

    每个公司,都有自己的历史和文化,他们的文化又影响了各自的软件开发模式。

    2019 年 6 月 13 日

  • 手工服务部署和测试 (上)

    2019 年 8 月 13 日

  • 2017 测试行业状况报告

    2017测试行业状况报告提供了多方位视角来观察测试行业现状,包括测试技术、测试实践、测试自动化以及测试人员面临的挑战。这已经是测试行业状况的第四次调查。InfoQ对测试行业状况调查的组织者进行了一次采访。

发现更多内容

【架构师训练营 1 期】大作业一

诺乐

大作业

solike

价值 - 什么是有价值的事?(3)

石云升

读书笔记 28天写作 价值

架构师训练营 4 期 第2周

引花眠

架构师训练营 4 期

Java并发编程总结

topsion

Java 并发编程 多线程

架构师训练营大作业(一)

月殇

「架构师训练营第 1 期」

架构训练营第十二周作业

一期一会

hdfs hive 大数据MapReduce

给我结果

三只猫

28天写作

架构师训练营 week12 学习笔记

花果山

大作业1

软件架构总结图

dll

一个技术主管的年终管理心得

陆陆通通

程序员 技术管理 28天写作

十一周作业

架构师训练营大作业(二)

月殇

架构师训练营第 1 期 - 大作业 (一)

wgl

架构师训练营第 1 期

架构师训练营大作业二

一马行千里

架构师训练营第 1 期

大作业2

技术人小故事-团队愿景篇-第3段

Ian哥

28天写作

python 变量

老赵

Python 28天写作

精选算法面试-栈

李孟

算法 堆栈 28天写作

记一次缓存服务器迁移史,心塞!

冰河

高并发 高性能 分布式缓存 数据同步 服务器迁移

28 天带你玩转 Kubernetes-- 第三天(K8s 安装)

Java全栈封神

Kubernetes k8s 28天写作 k8s安装

十二、数据应用(一)

Geek_28b526

第 12 周 系统架构总结

心在那片海

架构师训练营第十二周作业1

韩儿

第 12 周 系统架构作业

心在那片海

算法:罗马数字转换为整数,RxSwift的好处,git pull问题解决error: cannot lock ref,产品经理新人如何落地 John 易筋 ARTS 打卡 Week 34

John(易筋)

ARTS 打卡计划 算法:罗马数字转换为整数 RxSwift的好处 git pull cannot lock ref 产品经理新人如何落地

架构师设计大作业一

小诗

「架构师训练营第 1 期」

【薪火计划】10 - 目标计划管理

brave heart

管理 28天写作

SpringMVC学习!

程序员的时光

程序员 28天写作

架构师训练营第 1 期 - 大作业 (二)

wgl

架构师训练营第 1 期

OCR技术的未来发展与演进

OCR技术的未来发展与演进

书评 - 《展望敏捷软件测试》-InfoQ