移动 app 云测试平台的对比与分析

文章作者/配图来自ThoughtWorks:黄勇,未经允许,谢绝转载。

我们都知道在测试移动app时最耗时的是在各种测试设备进行测试, 因为不论是安卓还是iOS都已经碎片化了。而云测试看似是解决这一问题的有效途径。因此选择哪种云测试平台来协助测试人员进行各种测试就成为首要问题。

我们先来看看云测试平台通常都提供哪些功能和服务。

主流的云测试平台都支持对原生native,混合hybrid和Web app的测试,这些测试包括:

  1. 兼容测试。通过在多种测试设备上安装/卸载和运行被测app,遍历app的每个界面,主要检查app是否会报错或者崩溃。有些云测试平台还会对每个页面进行截图并进行对比。
  2. 脚本测试通过运行云测试平台工具进行录制的或者使用自动化测试框架编写的自动化脚本,实现模拟用户操作的目的,并且减少手动测试时间。
  3. 性能监控和分析利用Android SDK提供的借口,云测试平台可以检测移动app的耗电量,CPU等资源占用率,使用的流量等信息。有些云测试平台还提供自己的SDK,整合在app中可以提供更为准确的性能指标和信息,包括线上app的性能信息以及崩溃信息等。
  4. 手动测试和人工测试云测试平台的手动测试是指租用云测试平台的特定设备,测试人员手动登录设备进行测试。

    而人工测试则是将测试需求告知云测试平台的专业测试人员,雇佣他们临时作为自己的测试人员进行测试。

  5. 持续集成不少提供脚本测试的云测试平台都同时提供对持续集成(Continuous Integration)环境的支持。

此外不少国内云测试平台还提供以下功能:

  • 安全测试
  • 内测托管分发
  • 众包测试

我们再来看看各种云测试平台对于上述功能和服务的支持情况。

由于国内外的云测试平台使用环境等因素的不同,我们分别对国内外主流的几个云测试平台进行对比。

国外主流的云测试平台:
  • Xamarin Test Cloud (https://xamarin.com/test-cloud/)
  • TestDroid (http://testdroid.com/)
  • Sauce Labs (https://saucelabs.com/mobile/)
  • Google Cloud Test Cloud (https://developers.google.com/cloud-test-lab/)
  • AWS Device Farm (https://aws.amazon.com/device-farm/)

TestCloud-Foreign图1 - 国外主流的云测试平台对比

从上图我们可以看到一些特点:

  1. 在测试设备的数量上,Xamarin Test Cloud和Sauce Labs都是非常有优势的,虽然Xamarin Test Cloud统计的是测试设备的数量,而Sauce Labs是平台的数量;
  2. 亚马逊自己的FireOS只被自己的云测试平台支持,在国内我们也能看到类似的例子;
  3. 所有的云测试平台都支持app测试,但是只有TestDroid支持游戏测试;
  4. 对于国内云测试平台提供的人工测试,安全测试,内测分发和众包测试,国外这些云测试平台都是不支持的,需要结合别的工具和框架进行使用。不过对于手动测试,Sauce Labs和Perfecto这两个云测试平台支持租用测试设备进行手动测试;
  5. 对于云测试基础功能的兼容测试,以及脚本测试,崩溃分析和持续集成,这些云测试平台都是支持的;
  6. 只有Xamarin Test Cloud,TestDroid和AWS Device Farm支持性能监控;
  7. 对于脚本测试所使用的移动app自动化测试框架,每个平台都不甚相同:
    • Xamarin Test Cloud支持Calabash(iOS和Android)和自己的Xamarin.UITest;
    • TestDroid支持很多框架,包括支持iOS的Calabash,appium,UI Automation和 Jasmine,以及支持Android的Calabash,appium,Espresso,Robotium和uiautomator;
    • Sauce Labs支持自己的开源框架appium;
    • Google Cloud Test Lab则支持Espresso,Robotium和Robo test;
    • AWS Device Farm也支持很多框架,包括支持iOS的Calabash,appium,UIAutomation和XCTest,以及支持Android的Calabash,appium,JUnit,Espresso,Robotium和uiautomator。
  8. Xamarin Test Cloud,TestDroid和Sauce Labs都有自己的移动app测试脚本录制工具,分别是:Xamarin Test Recorder,TestDroid Recorder和appium inspector。

综合来看,对于国外的云测试平台,如果侧重的是测试设备的覆盖程度,选择Xamarin Test Cloud和Sauce Labs会更合适;如果需要测试FireOS设备,那就选择AWS Device Farm;如果侧重的是脚本测试中支持的语言和框架,那就可以选择TestDroid和AWS Device Farm;如果是进行游戏测试,只能选择TestDroid;如果要远程连接测试设备进行手动测试,那就需要选择Sauce Labs和Perfecto;如果在测试过程中需要同步监测性能,就不能选择Sauce Labs和Google Cloud Test Lab。

国内主流的云测试平台:
  • Testin云测 (http://www.testin.cn/)
  • 百度MTC (http://mtc.baidu.com/)
  • 腾讯优测 (http://utest.qq.com/)
  • 阿里MQC (http://mqc.aliyun.com/)

TestCloud-Domastic图2 - 国内主流的云测试平台对比

从上图我们也可以看到一些特点:

  1. Testin云测支持的测试设备数量最多,达到了600部Android和70部iOS终端的数量;但是和Xamarin Test Cloud以及Sauce Labs支持的设备数量还是有不少差距的;
  2. 和亚马逊类似,阿里的YunOS也只有阿里MQC才能支持;
  3. 和国外的云测试平台很类似,这四个国内云测试平台也都支持app的云测试,而不支持游戏测试;只有Testin云测支持游戏测试;
  4. 对于云测试基础功能的兼容测试,国内主流云测试平台都是支持的;
  5. 这四个国内云测试平台也都支持崩溃分析,不过对于性能监控,却只有百度MTC支持,而且百度MTC的深度性能测试中还可以做竞品app的性能对比;
  6. Testin云测和百度MTC不支持手动测试;
  7. 只有阿里MQC不支持人工测试;
  8. 只有Testin云测不支持安全测试;对于支持安全测试的云测试平台,也没有公布是如何进行安全测试的;
  9. Testin云测支持内测分发和众包测试,阿里MQC支持众包测试,其它两个云测试平台对于内测分发和众包测试都不支持;
  10. 对于脚本测试,只有腾讯优测不支持;而对于测试工具和框架,各个平台的支持也不相同:
    • Testin云测支持Robotium,JUnit,淘宝的Athrun和Testin SDK,其中只有Testin SDK支持iOS和Android,其他框架都只支持Android;
    • 百度MTC只支持通过自己的测试脚本录制工具录制的脚本;
    • 阿里MQC支持Robotium和增强后的appium,其中appium可以支持iOS和Android;
  11. Testin云测,百度MTC和阿里MQC都提供了自己的测试脚本录制工具,分别是itestin录制回放工具,百度MTC录制回放工具和易测;
  12. 国内云测试平台都没有提及持续集成,不过从笔者的了解看来,Testin云测和阿里MQC应该是都支持的。

对于国内云测试平台,如果需要覆盖更多的测试设备或者需要测试游戏亦或需要内测分发,只能选择Testin云测;如果需要测试YunOS设备,那就需要选择阿里MQC;如果需要进行性能监控和竞品对比,那就选择百度MTC;如果要远程连接测试设备进行手动测试,那就需要选择腾讯优测和阿里MQC;如果需要雇佣云测试平台的专业测试人员,就不能选择阿里MQC;如果需要进行安全测试,就不能选择Testin云测;如果需要进行众包测试,那就选择Testin云测和阿里MQC;如果要进行脚本测试,就不能选择腾讯优测,对于百度MTC也不推荐。

相信通过对比这些云测试平台提供的功能和服务,以及它们各自的特点,读者在选用云测试平台时有了更多的依据。希望大家在使用这些信息作为依据时,综合考虑这些云测试平台的特点,同时可以使用它们提供的免费试用进行尝试,以便验证是否真的适合自己的app。

P.S.以上云测试平台提供的功能及服务,截止于2016年3月20日。

Share

容器化时代对测试的机遇

对于工作在复杂系统上的测试工程师,我们眼前浮现的都是这些人的屏幕上开着N个远程桌面,N个虚拟机,他们在每个交付迭代周期内都疲于奔命,顾此失彼地应付着各种不同的环境、浏览器和操作系统。在我曾经工作过的A公司和D公司,测试和开发人员的比例几乎是1:1甚至更高。

过去的几年里,测试的工作似乎变得完善和高效,成熟的敏捷实践使很多测试工作得以自动化,这无疑降低了企业成本,也使得测试本身变得更有趣,人们有时间去做一些创造性的工作,而把重复的、了无生趣的工作交给了机器和脚本。

但是,虽然我们做了很多改变,但就目前的情况而言,依然不是很乐观,我们还是会碰到诸如此类的问题:“我的环境没发现这个defect,你来帮我重现一下”,当我们信心满满去尝试重现的时候,却可能再也无法发现这个defect,然后不得不花费几个人几个小时甚至几天的时间去定位和解决它。

再有,很多敏捷团队都会做每日构建,构建成功的前提是所有的测试都要通过,我们为了减少构建时间、测试反馈时间,花了大力气去优化和重构,使用了mock技术等等,但对测试时间的影响依然是杯水车薪。

上述问题仅仅是我们平时工作里遇见的一小部分,对于这几个问题,我们归结了两点:

  1. 测试环境不够干净
  2. 测试执行效率需要大幅提升

我们带着这两个问题,来看近年来火爆的轻量级虚拟化——容器技术,它提供了能够独立运行的轻量级虚拟化解决方案,并且也提供了一种在安全、可重复的环境中自动部署软件的方式。

传统的硬件化虚拟占用的资源比一个容器要多不止10倍。我们不敢想象在一个物理机上开上百个虚拟机是什么效果,但是要实现同样数量的容器是很正常的。容器为我们提供了隔离的运行空间,每个容器又包含了完整的用户环境。不但如此,我们还可以通过诸如ansiblepuppet、chef这样的自动化运维工具对不同的容器空间进行批量化操作等等。

从一个测试人员的角度来讲,这恰恰为我们运行测试脚本提供了丰富的土壤,我们不必担心一些依赖包悄悄地破坏我们的环境,也不再担心多人在相同的虚拟机或者硬件环境中的操作污染了环境,使defect无法重现,同时,多操作系统版本、多尺寸的移动端自动化测试也将从容器化技术中受益更多。

那么另一个问题解决起来也不算难,主流的开源自动化测试工具Selenium多年前就提供了Selenium Grid,hub/remote的机制可以很好地帮助我们设计分布式测试环境:

grid

我们可以把这样分布式的环境与自定义的容器化空间结合在一起,利用提供各种语言支持的并发工具包,让我们在安全、可重复、可移植的环境基础下,指数级提升测试运行效率,减少反馈时间:

grid2

 

大部分测试人员对日新月异的技术并不是很敏感,很多时候,我们可能会认为,这些技术的发展,并不会也并不想知道这些技术能对日常的测试工作带来多少影响,但其实很多时候看似孤立的领域,碰撞在一起会有意想不到的火花。

乔布斯曾经说,创新就是把各种事物整合在一起。当你问有创意的人是如何创新的,他们可能会感到些许愧疚,因为他们根本没有创造什么。他们只是看到了一些东西。我们对于日常工作了解得更深更广,我们就会做得越出色。

Share

软件测试新趋势

2015年11月,ThoughtWorks发布了新一期的技术雷达。技术雷达是以独特的形式记录ThoughtWorks技术顾问委员会对行业产生重大影响的技术趋势讨论的结果,为从CIO到开发人员在内的各方利益相关者提供价值。这期雷达的技术趋势主要体现在:受到热捧的微服务相关技术,逐步成熟的以Docker为典型的容器化生态系统,备受企业和用户关注的信息安全问题。本文就从这几个新趋势来分析一下给软件测试带来了哪些影响。

自动化测试是王道

在这个快速变化发展的时代,任何一款产品想要在市场具备竞争力,必须能够快速适应和应对变化,要求产品开发过程具备快速持续的高质量交付能力。而要做到快速持续的高质量交付,自动化测试将必不可少。同时,自动化测试也不是用代码或者工具替代手工测试那么简单,有了新的特点和趋势:针对不同的产品开发技术框架有着不同的自动化技术支持,针对不同的业务模式需要不同的自动化测试方案,从而使得自动化测试有着更好的可读性、更低的实现成本、更高的运行效率和更有效的覆盖率。来自技术雷达的下列主题分别体现了自动化测试的这些特点:

  • 针对微服务的消费端驱动的契约测试(Consumer-driven contract testing),有助于解决随着服务增多带来集成测试效率低和不稳定的问题。消费端驱动的契约测试是成熟的微服务测试策略中核心的组成部分。
  • 专门用于测试和验证RESTful服务的工具REST-assured,它是一个Java DSL,使得为基于HTTP的RESTful服务编写测试变得更加简单。REST-assured支持不同类型的REST请求,并且可以验证请求从API返回的结果。它同时提供了JSON校验机制,用于验证返回的JSON数据是符合预期的。
  • 安卓系统功能测试工具Espresso,其微小的内核API隐藏了复杂的实现细节,并帮助我们写出更简洁、快速、可靠的测试。
  • ThoughtWorks开源的轻量级跨平台测试自动化工具Gauge,支持用业务语言描述测试用例,支持不同的编程语言,支持所支持平台的并行执行。
  • 用于针对UI的自动化测试构建页面描述对象的Ruby库Pageify,该工具关注于更快的执行测试以及代码的可读性,并可以很好的配合Webdriver或是Capybara使用。
  • 专门用于iOS应用开发的开源行为驱动开发测试框架Quick,支持Swift、Objective-C,它和用来做测试验证的Nimble捆绑发布。Quick主要用于Swift和Objective-C程序行为的验证。它和 RSpec和Jasmine具有相同的语法风格,基础环境很容易建立。Quick良好的结构和类型断言使得测试异步程序更加容易。Quick拥有现成的Swift和Objective-C规范文件模板,开发者只需简单几步,即可对应用进行快速测试。

工具很重要,设计不可少!自动化测试工具云集,但做自动化也不要冲动,需要重视以下几点:

  1. 综合考虑项目技术栈和人员能力,采用合适的框架来实现自动化;
  2. 结合测试金字塔和项目具体情况,考虑合适的测试分层,如果能够在底层测试覆盖的功能点一定不要放到上层的端到端测试来覆盖;
  3. 自动化测试用例设计需要考虑业务价值,尽量从用户真实使用的业务流程/业务场景来设计测试用例,让自动化优先覆盖到最关键的用户场景;
  4. 同等看待测试代码和开发代码,让其作为产品不可分割的一部分。

1221-测试-automation

云技术、容器化和开源工具使得测试成本下降

测试环境的准备在过去是一个比较麻烦和昂贵的事情,很多组织由于没有条件准备多个测试环境,导致测试只能在有限的环境进行,从而可能遗漏一些非常重要的缺陷,测试的成本和代价很高。随着云技术的发展,多个测试环境不再需要大量昂贵的硬件设备来支持,加上以Docker为典范的容器技术生态系统也在逐步成长和成熟,创建和复制测试环境变得简单多了,成本大大的降低。技术雷达推荐的凤凰环境(Phoenix Environment),它使用凤凰服务器(Phoenix Server)的模式,能够以自动化的方式支持测试、开发、UAT和灾难恢复所需的新环境准备。这一技术由上期的评估环上升到了采用环,表明它已经得到了验证和认可,是可以放心使用的技术。

另一方面是大量开源工具的出现,这些工具往往都是轻量级的、简单易用,相对于那些重量级的昂贵的测试工具更容易被人们接受。测试工作有了这些开源工具的帮助,将更加全面、真实的覆盖到要测试的平台、环境和数据,将会加快测试速度、降低测试成本;更重要的一点,有了这些工具,让测试人员能够腾出更多的时间来做测试设计和探索性测试等更有意思的事情,使得测试工作变得更加有趣。新技术雷达提到的开源工具有:MountebankPostmanBrowsersyncHammsGorievms等。

  • 在企业级应用中,对组件进行良好的测试至关重要,尤其是对于服务的分离和自动化部署这两个关系到微服务架构 是否成功的关键因素,我们更需要更合适的工具对其进行测试。Mountebank就是一个用于组件测试的轻量级测试工具,可以被用于对 HTTP、HTTPS、SMTP和TCP进行模拟(Mock)和打桩(Stub)。
  • Postman是一个在Chrome中使用的REST客户端插件,通过Postman,你可以创建请求并且分析服务器端返回的信息。这个工具在开发新的API或者实现对于已有API的客户端访问代码时非常有用。Postman支持OAuth1和OAuth2,并且对于返回的JSON和XML数据都会进行排版。通过使用Postman,你可以查看你通过Postman之前发起过的请求,并且可以非常友好的编辑测试数据去测试API在不同请求下的返回。同时,虽然我们不鼓励录屏式的测试方法,但是Postman提供了一系列的拓展允许我们将它作为跑测试的工具。
  • 随着网站应用所支持设备的增多, 花在跨设备测试上的代价也在不断增大。Browsersync能够通过同步多个移动设备或桌面浏览器上的手工浏览器测试来极大的降低跨浏览器测试的代价。通过提供命令行工具以及UI界面,Browsersync对CI构建非常友好,并且能够自动化像填写表单这样的重复任务。
  • 在软件开发领域,盲目地假设网络总是可靠,服务器总是能够快速并正确的响应导致了许多失败的案例。Hamms可以模拟一个行为损坏的HTTP服务器,触发一系列的失败,包括连接失败,或者响应缓慢,或者畸形的响应,从而帮助我们更优雅的测试软件在处理异常时的反应。
  • Gor可以实时捕获线上HTTP请求,并在测试环境中重放这些HTTP请求,以帮助我们使用到这些产品环境数据来持续测试我们的系统。 使用它之后可以大大提高我们在产品部署,配置修改或者基础架构变化时的信心。
  • 尽管IE浏览器的使用量日益萎缩,但对很多产品而言IE浏览器的用户群依然不可忽视,浏览器兼容性仍然需要测试。这对于喜欢使用基于Unix的操作系统进行开发的人来说还是件麻烦事。为了帮助解决这个难题,ievms提供了实用的脚本来自动设置不同的Windows虚拟机镜像来测试从IE6到Microsoft Edge的各种版本浏览器。

1221-测试-Cost+of+testing

安全测试贯穿整个生命周期

“安全是每一个人的问题”!互联网安全漏洞频繁爆发,安全问题已经成为每个产品迫切需要关注和解决的问题,安全测试将需要贯穿于软件开发的整个生命周期。同时,给软件测试人员带来了更多的机遇和挑战,要求具备更多的安全相关知识(其中还包括更多的计算机基础知识),掌握已有的安全测试相关技术,从而在软件开发的各个阶段做好安全相关的分析和测试工作。尽管有些团队已经将安全跟整个开发实践结合起来,但培养每个人在每个阶段的安全意识还相当的重要,探索新的安全测试技术、方法还有很多空间。

1221-测试-Security

技术雷达上列出的安全测试相关的技术和工具有:Bug bounties威胁建模(Threat Modelling)ZAPSleepy Puppy

  • Bug bounties是一个安全漏洞举报奖励制度,越来越多的组织开始通过Bug bounties鼓励记录常见的安全相关的Bugs,帮助提高软件质量。
  • 威胁建模(Thread modeling)是一组技术,主要从防御的角度出发,帮助理解和识别潜在的威胁。当把用户故事变为“邪恶用户故事”时,这样的做法可给予团队一个可控且高效的方法使他们的系统更加安全。
  • ZED Attack Proxy (ZAP)是一个OWASP的项目,允许你以自动化的方式探测已有站点的安全漏洞。可以用来做定期的安全测试,或者集成到CD的Pipleline中提供一个持续的常规安全漏洞检测。使用ZAP这样的工具并不能替换掉对安全的仔细思考或者其他的系统测试,但是作为一个保证我们的系统更安全的工具,还是很值得添加到你的工具集里。
  • Sleepy Puppy是Netflix公司近期开源的一款盲打XSS收集框架。当攻击者试图入侵第二层系统时,这个框架可用于测试目标程序的XSS漏洞。XSS是OWASP的Top10的安全威胁,Sleepy Puppy可以用来同时为几个应用完成自动安全扫描。它可以自定义盲打方式,简化了捕获、管理和跟踪XSS漏洞的过程。Sleepy Puppy还提供了API供ZAP之类的漏洞扫描工具集成,从而支持自动化安全扫描。

优化业务价值

大多数软件都是做项目的模式,在不同的档期内进行计划、实现和交付。敏捷开发极大的挑战了这种模式,通过在开发过程中各个阶段进行的分析和测试工作,持续的发现新的需求,使得需求更趋于合理化,更能体现业务价值。精益创业的技术,如观察需求的A/B测试,进一步削弱了这种心态。技术雷达推荐“产品优于项目(Product over project)”,认为大多数的软件开发工作应该遵循精益企业的引领,将自己定义为构建支持业务流程的产品。这样的产品并没有所谓的最终交付,更多的是一个探索如何更好的支持和优化业务流程的过程,只要业务依然有价值就会不断持续下去。

作为软件开发中的关键角色、负责软件测试的QA人员,通过从用户角度对软件的测试,结合自身对软件产品的了解,对优化业务价值将会起到举足轻重的作用。软件测试不仅是检验软件是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程,还需要有意识的对需求进行持续的验证和优化,对业务的趋势和风险进行分析。如果能在开发过程中结合使用BDD(行为驱动开发)的思想,统一团队对需求的认识,利用团队的力量来优化业务将会达到事半功倍的效果。

传统方式下,QA角色主要专注于保证软件产品在类产品环境下的质量。随着持续交付的出现,QA角色逐渐转变到需要分析软件产品在产品环境下的质量。产品环境下的QA(QA in production),就是要求QA角色在做好产品上线前的质量保证工作前提下,做好软件产品在产品环境下的质量分析。具体做法有:

(一)引入产品系统的监控, 制定检测条件,找出产品环境下使用的质量度量。比如,利用网站分析工具收集用户使用应用程序的数据,分析数据量需求、产品的性能趋势、用户的地域特征、用户的行为习惯和产品在同类型产品市场的占有率等。

(二)收集产品环境下最终用户的反馈,对反馈进行分类分析。这些反馈可能有:

  • 缺陷:需要进行优先级划分,确定是否需要修复;并且对这些缺陷进行根源分析,在以后的开发过程中尽量避免同类型的缺陷再次出现。
  • 抱怨:对于抱怨需要分析其背后的原因,可能正是能够帮助我们改进和优化业务价值的好机会。
  • 建议:一般用户可能难以提出高质量的建议,需要我们在收集反馈的时候下点功夫,有针对性的去收集。一旦收集到了建议,将是对业务价值优化非常有利的。

1221-测试-QA+Practice

通过对产品环境下的软件质量进行分析,将有利于协助“产品优于项目”实践,帮助优化业务价值,做好企业产品的创新工作。需要注意的是,产品环境下的QA可能会导致有些组织走的太远而忽视产品上线前的质量保证,它只对那些已经执行并有一定程度持续交付实践的组织有价值。

总结

软件测试是一项技术工作,但软件测试领域的问题不仅仅是技术问题。随着自动化程度越来越高,不断有人怀疑QA存在的必要性,从前面的分析可以看到,新趋势给QA提出了更高的要求,带来了更多的机遇和挑战,相信好的QA是不可能简单的被取代的。

Share

软件测试反模式——杯型蛋糕

要想帮助团队制定测试策略,编写出可靠可伸缩的测试,测试金字塔是最好的方式之一。 根据我多次的使用经验来看,它真的非常有用

同时,我也经常会看到有的团队在尝试实践测试策略时掉进各种陷阱里。正如Alister Scott指出的,一个常见的陷阱就是冰淇淋甜筒状的反模式(anti-pattern)。这种模型形容在没有足够多的底层测试(单元测试、集成测试和组件测试)的情况下,创建了太多GUI(图像用户界面)测试,甚至更多的手动测试。

得益于自动化测试在软件开发界的普及,这种反模式现象正在减少。并且,加上TDD(测试驱动开发)和BDD(行为驱动开发)这些实践的大力推广和应用,我已经有很长一段时间没看到团队担心过底层测试(单元测试、集成测试、组件测试)了。

然而,与此同时我还观察到一些团队跌进了另一个非常危险的陷阱。这个新的反模式陷阱有如下非常明显的特征:

  • 不同的团队写不同层次的测试。
  • 一般由如下三类团队来写不同的测试:
    • 开发人员写单元测试,集成测试和组件测试
    • 另外一个团队通过界面来做黑盒测试
    • 手动测试员进行一系列手动测试来测试功能
  • 通常这些团队各自独立工作,合作甚少。
  • 整个项目的工作流程流水式进行,并没有同步工作。首先是开发人员写出代码和对应的测试,然后测试人员手动地测试功能,之后GUI测试人员才编写他们的测试。这一流程看起来像什么?一个小型瀑布。
  • 这三个团队在某场景是否应该被测试,或自动化测试的级别上,无法达成一致。这就导致了重复——相同的场景在不同级别上都进行了自动化测试。

在和同事PatrickTarso讨论此事时,我们对比了一下这个新的陷阱和之前提到的冰淇淋甜筒模型,然后开始思考这个新的反模式像什么。大致说来,它应该有个庞大的底部,宽阔的中部和一个巨型的顶部。Tarso灵光一闪,突然说道:“这不就是个杯型蛋糕(Cupcake)吗!” 他说得简直太对了。

 

fabiocupcakenew1_0_04444aff9e8be210d16a68f29a20fe7a

 

下面介绍一下软件测试中的杯型蛋糕反模式:

这里有一些小贴士可以助你避开这个杯型蛋糕,甚至很有希望将其“扭转”回理想的测试金字塔模型:

  • 合作:允许团队之间进行合作,然后讨论在哪一层写特定的测试才是最好的。以下是一些实用手段:
    • 同步工作:当开发一个功能时,鼓励不同的团队之间同步工作,而不是线性工作,各自为政,像一个迷你小型瀑布一样
    • 跨角色结对:支持跨角色结对。比如,在一个Story快完结时,一个开发者可以和一个测试人员结对,决定在哪儿执行自动测试
    • Story Kickoff:这里有很多方法可以采用,比如三驾马车(The Three Amigos),或者有些人称之为story kickoff,目的都是为了帮助团队分享对需求的理解,减少沟通隔阂
  • 从最底层开始测试:在条件允许的情况下,从最靠近代码的地方开始测试一个功能,降低测试的深度
  • 如果可能,尽可能合并团队:有时你并不需要不同的团队,你所需要的只是在不同职位上的不同的人。比如说一个开发者可以成为某个功能的界面测试人员,即使如果他(她)并没有参与过开发这项功能
  • 在目标上达成一致:确保每个人都有相同的目标。比如,整个团队要对什么是“完成”达成一致意见,而不是一起工作“完成开发”或者是“完成测试”
  • 同时要达成一致的,还有衡量测试工作的方式。而一旦合适的衡量方式确立了,就要避免只能应用于某一特定层次的“横向衡量”,比如靠自动化测试的用例数目来衡量界面测试的质量。更合适的衡量方式应该是“纵向”的,这样就能把所有层次都囊括进来。就用上面的例子来讲,衡量方式应该改成这样——每个story不管在哪一层(UI测试、单元测试等)都至少需要有90%的自动化测试覆盖率。如此一来,衡量方法就被共享了,达到了双赢的效果

 

fabiocupcakenew4_49b01336bfc161b4e720e3e0aee6696b

 

当一个由开发者、手动测试人员和界面测试人员组成的团队,为了达成同一目标,齐心协力相互帮助的时候,我确信这个团队能够完成更好的测试策略,更好地确保软件质量。

最后,你有什么想法?

Share

我和敏捷团队的五个约定

我——作为一名测试人员——有一个与众不同的习惯:每当要加入一个新项目的时候,我总会找到项目中的同伴,真诚而亲切地说:“为了更好地合作,我有5个约定,希望大家能尽量遵守”。

约定1. 业务分析师们,我们其实是同一个角色的两种面孔,请叫上我们参加客户需求会议

我们的团队需要让客户频繁的得到可用的软件,客户的不断反馈会给软件的未来做出最正确的方向指引。

如果我们交付的软件有很多质量的问题,存在大量的缺陷,客户会被这些缺陷的奇怪行为干扰,没有办法把注意力放在软件本身的价值是否符合他们的真正需求上, 不能给出最有价值的反馈。所以,我们只有频繁的做测试,在每次交付之前都把质量问题找出来告诉我们的团队,问题才能及时的得到改正。

而我坚信“prevention is better than cure”(预防胜于治疗),我会要把工作的重点放在预防缺陷上,这样可以节省Dev们很多修复缺陷的时间与精力。

为了达到这个目的,我需要跟你一起参加客户需求会议,尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候,我也基本完成了测试用例的准备。

我们可以赶在开发人员们写代码之前就告诉他们我要测什么,让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况,减少缺陷的发生。这是我测试的一项重要任务。

如果你们在大部分需求都整理好了再交给我们,我会浪费掉等待的时间。更重要的是,开发好的软件里面已经有很多本来可以不存在的缺陷在里面了,开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。

所以,请让我尽早了解需求,请不要让我到项目后期才能开始测试。

约定2. 开发人员们,虽然你们是编写自动化测试的专家,但请听听我们意见

我知道,对于你们,自动化测试不过是利用junit, rspec, selenium,watir,uiautomation等等写出的“另一段程序”而已。而对于80%的QA来说,编写自动化测试并不是一件简单的事情。

不过我仍然相信,有测试人员介入的自动化测试更有价值。

你们用单元测试,集成测试来保证代码的质量。然而你们的这些日常测试离代码更近,离最终用户还点远。很多测试都不是在测软件功能。

你们可以把功能测试写的又快又多,而我们可以指出什么功能测试最有必要加到自动化测试中。

你们平时大部分精力都在编码上,没有太多时间去查都有什么缺陷。而我们可以指出什么地方缺陷可能会出现的比较频繁,建议在这些脆弱的地方加自动化测试。

所以请听听我们的意见,我们可以给你们提供这些信息。

约定3. 项目经理们,请不要要求我们测试软件的所有路径

软件测试是一个永无止尽的任务。基本上没有什么软件简单到我们能够尝试完它的每一个可能的路径的。就连一个看似简单的微软计算器都有无穷尽的路径,无止尽的输入,更何况比这个更复杂的商用软件。

如果你们担心没有尝试过全部的路径不可靠,疑惑我们怎么敢说这个软件质量是好的还是坏,都有什么风险。请你们先注意,我们是跟业务分析师一样,都了解软件的价值的。价值可以帮我们做出判断,什么时候可以停止测试并对客户说我们的软件已经满足您的要求了,请放心使用。

因为我们了解价值,我们可以肯定的说哪些软件的使用方式是至关重要的,哪些是不太可能出现的。我们会在全面测试了软件以后,把主要精力放在价值高的功能点上。合理的利用项目有限的时间。

因为我们了解价值,我们可以正确的把发现的问题分类。我们可以帮助dev们把精力放在重要的缺陷上,避免把时间放在对于客户微不足道却不得不花费大量精力才能修正的问题上。

所以,请不要要求我们无止尽的测试一个软件。我们了解价值,请相信我们的判断。

约定4. 迭代经理们,如果对于交付风险有任何疑问,请来询问我

BA和Dev们都是关注一个软件在什么情况是可以良好的工作。而我们除了验证这些情况以外,大量的时候都用在寻找什么样的情况软件不能正常的运行。所以除 了针对定义好的软件行为进行测试,我们还会做很多探索性测试。我们通常可以通过这样的测试发现一些没有定义的、不曾预期的行为。这些行为往往将会构成软件 交付的风险。

我们会告诉你们现在都发生了什么问题,分别分布在哪里。

我们会告诉你们,在什么情况下软件可能会有异常行为,是不是会牵连到其他的部分,是否可以绕过去。

我们会告诉你们,哪些部分功能比较不稳定,需要更多的留意。

约定5. 测试人员们,那些敏捷实践对于我们也是有用的。

结对不是dev们的专利。我不希望总见到你们独自坐在自己的位置上冥思苦想。走出去,跟其他队友多多交流!

多跟测试队友交流,pair看看设计的测试用例是不是够全面,独自一个人想到的未必足够好。他们会给你诚恳的意见的。对他们,也请一样认真对待。

如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们,design for testability(提高你们设计的可测性)。

如果你发现业务分析师写的需求无法验证,定义的客户行为不够具体,一个用户故事中包含太多了功能点,等等,那么也请大声地告诉他,INVEST(独立,可协商,价值,可估算,短小,可测)。

也请你们多跟开发人员结对写自动化测试,既可以帮助你们学习怎样更好的编写自动化测试,也能帮助开发人员们结对更多的了解用户行为。

这就是我的五个约定,它们是我在团队中顺利展开工作的基础。


作者:覃其慧,ThoughtWorks敏捷咨询师。她参与了大量的敏捷软件开发的实践和敏捷咨询。目前主要关注以价值为驱动的敏捷测试。


本文原文发表于InfoQ:http://www.infoq.com/cn/articles/thoughtworks-practice-parti

Share