开场白
Yvette Nameth (Google)
开场主旨演讲
Jürgen Allgayer (Google)
Uber 对跨应用/跨设备测试的挑战
Apple Chow (Uber) 和 Bian Jiang (Uber)
2015 年 3 月加入 Uber 后,我们很快便完成了一项 Uber 独特挑战,他们正在研究我们的移动应用的界面测试工具。我们的许多健全性测试都需要我们的乘客应用和驱动程序应用相互通信/协调,以便完成端到端测试场景。在本演讲中,我们将介绍与平台无关的解决方案 Octopus,并讨论它如何协调在不同设备上运行的不同应用之间的通信。任何需要跨不同应用或设备进行协调/通信的测试(例如多用户游戏、多用户消息传递/通信应用等)都可以采用此解决方案。
机器人辅助测试自动化
Hans Kuosmanen (OptoFidelity) 和 Natalia Leinonen (OptoFidelity)
OptoFidelity 是一家芬兰的高科技公司,拥有 10 年开发和提供研发测试自动化解决方案的经验。本次演讲将包括我们在移动设备界面性能测试中使用的无干扰测试方法的经验和未来展望。您知道吗?Chrome 操作系统团队还使用 OptoFidelity 的机器人解决方案来衡量 Android 和 ChromeOS 设备的端到端延迟时间。
如何玩转娱乐行业,实现利润最大化:通过移动平台跨平台集成测试的经验教训
Dan Giovannelli (Google)
开发移动游戏并非易事。构建测试基础架构并非易事。跨平台工作并非易事。 三者合二为一,备战灾难。在该演讲中,Dan Giovannelli 将会分享他在跨平台移动测试基础架构项目方面的经验。他将讨论哪些方面做得不错,哪些地方做得非常糟糕,以及他最开始希望了解些什么。 欢迎前来探索如何为非移动工程师设计移动工具,继续探索“The Matrix”是什么,以及如何在它的游戏中打败它。
使用真实设备实现移动游戏测试自动化
Jouko Kaasila (Bitbar/Testdroid)
移动游戏是当今应用商店中创收最高的类别,因此对于任何游戏开发者来说,确保每个游戏的每个版本都可以在任何用户的设备上运行是首要任务。尽管有必要验证这一点,但很少有游戏或框架可以自动执行移动游戏测试,迫使游戏开发者不得不采用手动测试方法,而且这种做法无法扩展到游戏市场覆盖其全球市场的程度。一个主要原因是游戏作为移动应用的独特性,因为它们会直接访问屏幕,绕过操作系统提供的所有界面服务,使大多数测试自动化框架毫无用处,因为传统对象不会公开。
幸运的是,可以通过使用一些创意和公开发布的库来使用标准移动测试自动化框架,在真实的移动设备上推动测试自动化。在他的演讲中,Testdroid 的 Jouko Kaasila 将通过真实示例和一些示例代码讨论三种不同的方法。
如何分汤汤盘
Toni Chang (Google)
花费太多时间稳定不稳定测试的用户会同意我们需要分解测试。但是,有些人发现很难,而且不确定如何应对;另外一些人可能认为其他团队成员需要接受 E2E 测试来验证所有场景。有时,您可能不习惯于在组件中查看产品时难以理解这一概念,因此我会使用汤类抽象示例来演示如何将看似不可或缺的部分分解到各个组件上,并对它们应用测试。
我将带领您踏上一段有趣的旅程,将 E2E 测试转化为组件测试,这将让您对最终产品充满信心。希望这可以帮助您从自己的角度审视自己的产品。
Chromecast 测试自动化
Brian Gogan (Google)
物联网导致了各种设备的连接。验证各种互操作设备上的行为是一项重大的测试挑战。为了测试 Chromecast,我们采取了几种方法。我们简要介绍了为使用产品生成可靠的质量信号而开发的测试框架、实验室基础架构和测试工具。我们详细介绍了测试在嘈杂网络环境中运行的产品所面临的挑战。我们提议,Chromecast 等设备的测试工具尚处于早期阶段,并提供了在软件测试工程方面创新的机会。
使用机器人进行 Android 应用测试
Shauvik Roy Choudhary 博士(乔治亚州理工学院/Checkdroid)
使用软件机器人(例如 Monkey)无需大量手动操作即可测试 Android 应用。 学术界中提出了多种此类工具,其目标是自动生成测试输入来驱动 Android 应用。在本演讲中,我将介绍一组具有代表性的测试输入生成工具,并进行比较研究来着重说明它们各自的优势和局限性。您将了解这些工具的内部构件以及如何使用它们来测试您的应用。 有关此研究的详细信息以及虚拟机工具设置,请访问:http://bear.cc.gatech.edu/~shauvik/androtest/
您的测试不会不稳定
Alister Scott (Automattic)
不稳定的测试是任何自动化测试工程师的错误。正如有人(很可能是阿利斯特)曾经说过:“疯狂反复执行相同的测试并获得不同的结果”。不稳定的测试不会造成绝望,但可能不存在不稳定或不稳定的测试,或许我们需要通过不同的视角研究此问题。我们应该将更多时间用于构建更具确定性、更易测试的系统,而不是花时间构建弹性和持久性测试。 Alister 将分享一些测试不稳定问题应用于系统背后的实际问题的示例,以及通过构建更好的系统如何解决测试不稳定的问题。
大规模自动化视觉测试
Adam Carmi (Applitools)
自动化视觉测试是开发 / 测试社区的一个主要新兴趋势。在本演讲中,您将了解什么是视觉测试,以及为什么自动化测试。我们将深入了解视觉测试自动化方面的一些技术难题,并展示现代工具如何解决这些问题。我们将演示能够运行跨浏览器和跨设备视觉测试的先进技术,并提供在大规模视觉测试中取得成功的关键提示。
手动进行回归测试
Karin Lundberg (Twitter) 和 Puneet Khanduri (Twitter)
您的团队最近完成了一项重大服务重构,并且所有单元测试和集成测试都通过了。 非常棒!但还没有大功告成。现在,您需要额外确保没有破坏任何内容,并且没有尚未发现的任何隐藏 bug。是时候让 Diffy 发挥作用了。
与确保代码是正确的工具(如单元测试或集成测试)不同,Diffy 会将新服务和旧服务的实例并排放置,将示例请求路由到每个服务,比较响应,并反映这些比较中表现出的任何回归,从而对修改后的服务的行为进行比较。
此外,我们刚刚开放了工具的源代码,很快便成为 Twitter 开源项目中最热门的工具之一。
针对 Android 应用的自动化无障碍功能测试
Casey Burkhardt(Google)
这场演讲将介绍 Android 平台上的核心无障碍功能,并说明与无障碍功能相关的一些常见开发者误区。您将了解新的 Android 无障碍功能测试框架及其与 Espresso 和 Robolectric 测试框架的集成。最后,您将了解到,向现有 Android 项目测试添加自动无障碍功能检查是多么轻松。
统计数据抽样
Celal Ziftci(Google)和 Ben Greenberg(麻省理工学院研究生)
常见做法是在测试中使用生产数据样本。例如:
- 健全性测试:将生产数据样本馈送到您的系统中,看看是否有问题失败。
- A/B 测试:获取大量生产数据,通过系统的当前版本和新版本运行数据,并比较输出以进行检查。
为了获取生产数据样本,团队通常使用临时解决方案,例如:
- 手动查看特定字段(例如数字字段)的分布情况、
- 选择完全随机的样本
但是,这些方法有一个严重的缺点:它们可能会错过罕见事件(例如极端情况),这增加了生产环境中未捕获 bug 的风险。为了降低这种风险,团队选择非常大的样本。不过,对于这样的大型样本,会有更多弊端:
- 罕见事件可能仍会被忽略,
- 测试时间会大幅增加,
- 差异太大,让人难以理解,而且有很多重复。
在本演讲中,我们提出了一种新的统计数据采样技术,用于“smartly”从生产数据中选择“良好”样本,该样本必须符合以下条件:
- 保证不会出现罕见的事件,
- 消除重复样本,最大限度地减小所选样本的大小。
我们的方法能够捕获罕见/边界的情况,将样本大小保持在最低限度,并且隐式降低了在开发者处查看测试输出/差异的手动负担。它还支持并行执行(例如 MapReduce),以便在短时间范围内处理大量数据以选择样本。
Nest 自动化基础架构
Usman Abdullah(Nest)、Giulia Guidi(Nest)和 Sam Gordon(Nest)
Nest 的思想之家需要智能互联的智能设备,让您的住宅更安全、更节能、更有意识。本次演讲将重点介绍为帮助实现这一愿景而构建的自动化基础架构和测试工具。Nest 中的各个团队一直致力于跨平台和设备/功能方面的系统,以实现自动回归测试和分析。通过真实产品测试的具体示例,我们将介绍循环测试基础架构中的跨产品硬件、电源回归分析工具以及相机和移动侦测专用工具集。
事件生成器
Roussi Roussev (Splunk)
本演讲将介绍我们在 Splunk 上开发和使用软件事件生成器的经验。 受粒子物理学启发,事件生成器在没有运行大型实验性机器的情况下必不可少地了解现实世界,因此通过日志生成器改进了我们测试与现代和旧版第三方软件的大量集成的方式。该讲座介绍了生成实际日志的基本功能和挑战。
多线程测试合成
Murali Krishna Ramanathan(印度班加罗尔科学院)
由于同步不正确或同步不足而导致多线程库中出现的细微并发错误通常难以只使用静态技术进行精确定位。另一方面,动态检测器的效果严重依赖于多线程测试套件,多套件测试套件的执行可用于识别和触发并发 bug,包括数据争用、死锁和原子违规行为。通常,此类多线程测试需要对涉及到调用中涉及的对象调用特定的方法组合来公开 bug。如果没有事先了解错误,构建此类测试可能会比较困难。
在本演讲中,我将介绍一种可伸缩的轻量级技术,用于合成检测线程安全违规行为的测试。给定多线程库和顺序测试套件,我将描述一种完全自动化的分析,该分析会检查连续的执行轨迹,并生成一个并发客户端程序,该程序通过库方法调用推动共享对象,而这些状态有助于触发并发 bug。各种经过充分测试的 Java 库的实验结果表明了我们的方法在发现许多复杂 bug 时的有效性。
在 Netflix 上启用流式实验
Minal Mishra (Netflix)
超过 6900 万用户的直播体验对 Netflix 来说至关重要。为了迅速改进,我们将自适应流式传输算法移至 JavaScript 层。这给经常发布客户端 JavaScript 软件带来了独特的挑战,使其直接影响了消费者的流式传输体验。借鉴了广泛且已成功应用于服务应用的持续交付模式,我们使用该模式在检查生命周期内消除了风险,并经常提供更新。在本演讲中,我们将介绍实现软件更新的一种范式关键组成部分。我们将深入介绍 JavaScript 客户端和工具的发布过程,以准确对比健康状况与当前版本。我们还将介绍在此过程中面临的挑战。
模拟互联网
Yabin Kang (LinkedIn)
模拟互联网,讨论 Linkedin 中用于模拟所有出站流量的新的模拟系统,用于进行服务等级集成测试,此外还将简要介绍 Linkedin 模拟策略。与所有人分享知识和经验。
GPS 监测站接收器有效测试
Andrew Knodt (Lockheed Martin)
空军所使用的现有 GPS 监测站很难维护,正在努力将其替换为 GPU 加速软件定义无线电 (SDR) 方法。我们将简要介绍此专用 GPS 接收器所面临的独特测试挑战,并介绍几种测试方法。这些测试方法虽然侧重于 GPS 应用,但也能够轻松用于其他生产级 SDR 工作。
在穿戴式设备上实现自动化
Anurag Routroy (Intel)
由于可穿戴技术在个人和商业用途中的使用率越来越高,因此在 Android 市场中具有坚实空间的所有公司都已转而专注于这项即将推出的技术。因此,他们在支持穿戴式设备的情况下开发了应用,也增加了在穿戴式设备上测试应用的难度。因此,穿戴式设备上的自动化功能对于减少测试工作和提高效率至关重要。
统一的基础架构和 CI 集成测试 (Docker/Vagrant)
Maxim Guenis(超音速)
开发者每天都在努力为开发、调试和完成后续集成周期做好准备,能够正常运行的本地开发环境。我们可以通过集成 Docker 和 vagrant 以与 CI 工具搭配使用,来解决此问题。这样,您就可以在开发机器上的堆栈级别控制应用,同时在集成测试中使用相同的堆栈。 在本演讲中,我们将讨论以下内容:
- 在持续集成集成测试中使用 Docker
- 控制堆栈,而不是单个 Docker 或应用。
- 对开发和测试环境进行版本控制,使用 Git 和 Docker 工具轻松进行分发。
- 为在 Mac 和 Windows 上运行 Docker 提供无缝支持。
消除无用的测试位
帕特里克·拉姆(滑铁卢大学)
对测试套件进行静态分析分析法的专门研究,取得了喜人成效。我们之前已经了解到,大多数测试都是简单的直线代码,即一系列设置语句,后跟由断言组成的载荷。我们展示了静态分析如何识别无用的设置语句,使开发者能够简化和加速其测试用例。
覆盖率与测试套件的效果没有密切关联
Laura Inozemtseva(滑铁卢大学)
测试套件的覆盖率通常用作其检测故障的能力的代理。不过,之前对代码覆盖率和测试套件有效性之间的相关性的研究未能就这些测试套件特性的性质和强度达成共识。此外,许多研究都是使用小型程序或合成程序完成的,因此不清楚其结果是否泛化到较大的程序,一些研究并未考虑测试套件大小的令人混淆的影响。我们通过评估测试套件规模、覆盖率和现实 Java 程序的效果之间的关系来扩展了这些研究;我们的研究是迄今为止最大的文献。我们衡量了这些套件的声明覆盖率、决策覆盖率和修改后的条件覆盖率,并使用突变测试来评估其故障检测有效性。我们发现,当套件中的测试用例数在可控范围内时,覆盖率与有效性之间是有较低或中等的相关性。此外,我们还发现,在此基础上提供的更全面关注度无法让您更深入地了解该套件的效果。
使用 RpcReplay 模拟后端
Matt Garrett (Google)
保持快速稳定的测试至关重要。当服务器依赖于许多后端时,这可能很难。开发者必须在冗长和不稳定的测试之间,或者编写和维护虚假实现之间进行选择。而是可以使用来自这些后端的已记录流量运行测试。这样兼具两者的优势,可让开发者快速针对实际后端进行测试。
Chrome 操作系统测试自动化实验室
Simran Basi (Google) 和 Chris Sosa (Google)
ChromeOS 目前提供了 60 多种搭载不同软件的 Chromebook/盒。在现场,客户每 6 周会获得一次新的系统。如果没有强大的 200 名开发者对系统进行审查,这不可能实现。在本演讲中,我们将介绍整个架构,特别关注我们的自动化测试实验室。此外,我们还讨论了 Moblab(移动(测试实验室)的简称),这是我们在同一个 chromebox 上运行的整个测试自动化基础架构。我们的许多合作伙伴都在使用以下系统,以便他们也能像我们一样运行测试。