移动App测试的22条军规之“确定设备和平台再动手”

(ThoughtWorks洞见网站 获人民邮电出版社和作者授权连载本书部分章节。任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。)

第一章

1军规:确定设备和平台再

在测试设计之初, 测试人员首先会考虑的是什么呢?没错,就是测试的环境,也就是确定app究竟需要运行在什么样的设备和平台上。

显然,在移动设备和平台碎片化的现实中,测试人员穷尽所有设备和操作系统的版本来实现全覆盖的测试是不可能的。那如何在有限的时间和精力投入下,从投入产出比的角度出发,达到尽可能多的测试覆盖呢?这里主要考虑以下几个方面:

  1. app的特性
    1. 如果app是针对心率监测,指纹识别,NFC(近场通信),红外线操控这些需要特殊传感器设计的,那对测试设备和平台的选择就相对少一些,只需要考虑那些拥有这些传感器的设备。 例如对于支持指纹识别的app,测试人员需要考虑的设备也就是iPhone 5siPhone 6iPhone 6PlusiPad Air2iPad mini3LG G3,三星Galaxy S5,三星Galaxy Note4HTC One Max,华为Mate7这些设备(不考虑市场占有率比较低的vivoOPPO的手机);而如果app支持心率监测, 测试人员就只能选择三星Galaxy S5Galaxy Note4了。

里推荐大家使用一个网站http://www.phonearena.com来做设备的查找工作。通过这个网站不仅可以查询到各种手机和平板设备的详细参数信息,还可以对它们进行横向对比,方便测试人员找到适合用来做测试的设备(如图1.1)。

样章-1

1.1 http://www.phonearena.com设备对比

    1. 如果app是针对某种平台所独有的功能设计的,或者是某种平台独占的,测试人员就只需要考虑相应平台下的设备。比如app是类似Android设备上层出不穷的“xx清理大师”,那在确定测试设备和平台时就不需要考虑iOS平台了;又比如之前Instagram选择只支持iOS平台,那作为Instagram的测试人员只需要关注与iOS设备就足够了。

或者,如果app选择不支持某种平台,相应地,测试人员也就不需要测试运行这些平台的设备了。比如WindowsPhone、黑莓BlackBerry以及塞班Symbian平台在市场上的占有率已经很低了(根据2014年第四季度的调查,详见图1.2),如果在开发时选择不支持这些平台,那在测试时测试人员就完全可以忽略相关的设备。

样章-2

1.2 2014年第四季度各操作系统市场占有率调查表数据来源: www.netmarketshare.com

    1. 如果app是面向大众的通用型app,测试人员就需要结合移动app的生命周期和测试设备的硬件参数来确定测试设备和平台了。
  1. app的生命周期
    1. 对于还处于开发阶段但准备不久之后投入市场的一款新app,鉴于并没有已经实际使用app 的用户,所以测试人员要“预测”真实的用户所使用的设备和平台。在这种情况下,首先需要了解使用app的主要用户是哪一类人群,比如说是发烧友,还是商务人士 。发烧友极有可能使用的是最新的设备和平台;商务人士更多使用的是成熟的平台,高端一些的设备;而如果用户是普通大众,就需要通过 AppleGoogle官方布的版本占有率数据来帮助测试人员进行有依据的“拍脑袋”了。

以下是Apple官方布的iOS版本占有率数据(如图1.3: https://developer.apple.com/support/appstore/ Google官方布的Android版本占有率数据(如图1.4: http://developer.android.com/about/dashboards/index.html

样章-3

1.3 - 截止201515日,iOS各版本所占比例

样章-4

1.4 - 截止201515日,Android各版本所占比例

    1. 对于已经发布并且有稳定用户群的app,测试人员可以使用在桌面应用开发时用到的工具,例如Google AnalyticsOmniture SiteCatalyst(现在Omniture Adobe收购了,工具也改名叫做Adobe Analytics )来统计的信息,从而确定app支持和需要测试的设备及平台。这里对于app有一点要求,就是app需要联网对后台的服务器发送请求,从而能获取到用户信息。

Google AnalyticsGoogle分析,http://www.google.com/analytics )是Google的一款免费的网站分析服务,使用范围也很广泛。Google Analytics功能非常强大,只要在网站的页面上加入一段代码,就可以提供的丰富详尽的图表式报告。Google Analytics的特点是简单易用,但是相应的缺点就是不可定制化。

样章-5

1.5 Google Analytics

Omniture SiteCatalystAdobe Analytics http://www.adobe.com/solutions/digital-analytics.html )是一个进行网站基本指标的搜集,报告和分析工具。由此通过这个软件可以得到网站和app的访问量,浏览量,跳出率,转化率,来源等诸多指标。只要在app中对不同事件以及发送请求都添加相应的Omniture追踪,然后再登陆Omniture的网页就可以进行用户数据分析。Omniture SiteCatalyst不同于Google Analytics的一个特点是,它可以对数据进行高级细分,也就是说,可以对用户的各种操作打上不同的标签,在服务器端搜集到信息后进行统一的筛选和分析。

样章-6

1.6 Omniture SiteCatalyst

    1. 对于上面两种情况,有一种特例需要考虑,就是在有新的操作系统版本将要发布的时候,需要参考以前操作系统版本升级时用户更新的进度。正如图1.31.4所示,在 iOS 8发布三个月之内有68%的用户进行了升级,而使用iOS 7之前版本的用户只有4%;而Android 4.4 Kitkat发布一年后,市场占有率才刚刚达到39.1%,有超过52.7%的用户使用的还是4.04.3版本的Android,甚至还有8.2%左右的用户还在使用着Android 2.x的设备。

根据这些数据,测试人员在iOS操作系统版本升级时需要及早适配新的app版本;而对于Android发布新的操作系统时,测试人员主要还得关注当前市场占有率高的那些老版本。

  1. 设备的硬件参数
    1. 屏幕尺寸:现在手机越出越大,连坚持自己风格的Apple也开始跟风发布大屏手机了。屏幕大小除了会影响显示效果外,还会影响到用户的使用习惯。一般用户手持6寸屏幕的设备时,会采取双手操作的方式,所以app如果同时支持横纵屏显示会带来更好的用户体验(如图1.7所示)。
    2. 样章-7

1.7 - 双手持握设备的方式

而对于45寸这种可以单手持握的设备,如果app无论横纵向显示,按钮都最好不要放在屏幕四个角,以免用户很难点击(如图1.8所示)。

样章-8

1.8 单手操作范围。

49%的单手操作用户采用的是以上两种姿势(左手用户相反)。绿色代表容易点击区域,黄色为拇指伸展可到点击区域,红色区域超出单手可点击范围

    1. 分辨率:分辨率的大小会决定显示内容的多少,这对显示图片和视频时会有一定的影响(如图1.9所示)。样章-9

1.9 - 不同分辨率下显示内容的大小以及显示比例

还需要注意的是,有些厂商(比如说魅族)虽然标注的屏幕尺寸和通用产品一致,但由于显示比例的不同,分辨率和通用产品也会有差别(如图1.10所示魅族MX4采用的是15:9的屏幕比例,而非标准的16:9的屏幕比例)。

样章-10

1.10 魅族MX4的的屏幕比例

    1. 像素密度:屏幕大小和分辨率决定了像素密度。不同的像素密度对于显示也会有差别:在retina的屏幕上显示非retina的图片会很模糊,反之则会显得失真(如图1.11和图1.12所示)。如果需要同时支持retina和非retina的设备,那测试人员需要测试是否对图片尤其是app的显示图片提供retina和非retina两个版本的图片。样章-11

1.11 retinaretina的文字显示

样章-12

1.12 -非retinaretina的图片显示

选取了操作系统版本和测试设备之后,就可以设计矩阵来配对操作系统版本和测试设备了。具体可以参考图1.13的表格。

样章-13

1.13 - 测试设备和操作系统版本对照表

设计测试设备和操作系统版本对照表的原则是:让不同分辨率,不同屏幕尺寸大小的设备尽可能多地涵盖各个操作系统版本,另外,对于市场占有率很高的重点操作系统版本,可以使用多个设备来测试。

可以看到,对于同一种设备(图1.13中的iPhone 5s),由于市场占有率大,而且支持多个操作系统版本,所以在iPhone 5s上需要测试iOS 7.18.1这两个版本;由于iPhone 5siPhone 6Plus分辨率、性能等都不一样,所以同样对于iOS 8.1,两者都需要测试。

在设计Android设备和操作系统的覆盖时,可以看到对于类似的设备(HTC One XL和三星Galaxy S3硬件水平很接近),并没有要在它们上分别都测试覆盖Android 4.14.2,而是在HTC One XL测试Android 4.1,在三星Galaxy S3上测试Android 4.2Sony Xperia Z不仅在CPU、内存、屏幕大小和分辨率上都和三星Galaxy S3不同,所以在这两部设备上都需要测试Android 4.2

设计表格的过程中,测试人员还需要注意两点:

  1. 操作系的小版本升一般只是修复缺陷,不会引入新的功能,例如iOS8.0.1升级到8.0.2,以及Android4.4.1升级到4.4.4。这时,如果不是app恰好被这些缺陷修复所影响,测试人员不需要考虑覆盖这些小版本。至于中间版本的升级,例如从iOS 8.0.2升级到8.1,以及Android4.1升级到4.4,这时需要考察变动对app的影响,决定是否测试覆盖相应版本。就拿Android 4.14.4来说,因为Android 4.44.1新增了ART运行环境,所以针对这一点,测试人员需要准备设备安装Android 4.4,而不是仅仅在安装有Android 4.1的设备上测试。至于操作系统大的版本升级,就必须要进行测试覆盖了。
  1. 随着操作系统升级,既有的设备可能无法流畅地运行新的操作系统时,测试人员就需要考虑是不是还继续在新的操作系统上测试这些设备。比如,iPhone 4在升级iOS 7之后运行速度变得很慢,各种操作的延迟都会很长,固然有一部分用户还是强忍着会继续使用,但是很多用户会放弃在新的操作系统上使用运行很慢的老旧设备。当新的操作系统升级时,甚至有些旧的设备就不会被支持了,例如iOS 8就不再支持iPhone 4 。这时候如果确定这些旧的设备上的操作系统占比很小的话,测试人员就可以果断放弃这些设备。

所以测试人员需要从设备角度出发决定要测试的操作系统,以及从操作系统出发决定要测试的设备这两方面来考虑测试设备和操作系统版本对照表的制定。

明确了测试设备和操作系统版本,下面我们就来了解下在设计测试场景和用例中可以运用哪些具体的军规。

购买本书请点击链接:http://item.jd.com/11730286.html

Share

技术人员如何写一本书?

我在过去的几年中,写了4本书。有传统意义上的两本实体书:《JavaScript核心概念及实践》《轻量级Web应用开发》,还有两本电子书《3周3页面》《函数式编程乐趣》。当然对我而言,主职工作是软件开发,写作是个副业。

在写作的过程中,有一些有趣的心得。

  • 写作本身是一个很好的学习过程(至少是一个驱动你学习的动力)
  • 写书非常枯燥,特别是校对的时候
  • 写作不会让你变得富有,但是有时候会让你开心(不总是)

写文章 vs 写书

写博客/文章和写书还是有很大差别的,一个明显的差异是写文章会比较随意,而且应该尽量保持精简。一篇文章提供一些信息即可,应该尽量远离细节(如果写一篇教程,则另当别论)。而写书则应该尽可能的深入细节,尽可能可以让读者依书自修。

投入与回报

首先要明白的一点是,不要指望用写书来赚钱,至少前4本是这样的。粗略的算一下:我的第一本书卖了3000册,每卖一本我可以得到4元RMB,一共就是12,000元RMB。而这本书我断断续续写了三年。那是很多个周末,很多个假期,很多个夜晚的付出换来的,如果真正要计算投入产出比的话(纯粹金钱上),这显然是一个毫不合算的事情。

作为一个参考,IBM developerWorks的投稿,千字200元,一般写5,000字以内,也就是800元RMB左右。而要写一篇这样的文章,我只需要一天(当然需要数周/数月的积累)。12,000元RMB需要写15篇文章,如果每周写一篇,不到4个月就可以写完,而且写文章比写书容易多了,毕竟篇幅比较短小,易于校对。而且对于大部分开发者来说,固定在一个主题上的难度要比15个独立的主题简单的多,因为无需特别深入。

所以根据经验,要抱着公益的情怀来写书。也就是说为了让知识更好的分享,让你学习到的先进科学技术来帮助更多的开发者,提高他们的开发效率,让他们可以在周末多休息一天。而至于翻译技术书籍,那基本上就是免费的了,完全是一个公益活动(耗时数月,斟酌字句,推敲表达方式,但是价格极为低廉:千字60元RMB),所以下次见了技术书籍的译者,就多少给他捐点吧,他们才是在为人民服务

知识的诅咒

“知识的诅咒”是指人们在获得了某种知识之后,就无法想象没有这种知识的情况了。这种现象随处可见,比如一个你到了一个从未去过的陌生城市,遇到以为当地人,然后向他问路。当地人觉得已经说的很清楚了,但是你还是不知道该怎么走。另一个例子是:假设你不认识泰文,然后你打开任何一本泰文写的小说,你只能依稀感觉到这是一种文字,除此之外你并不能从中获取任何的信息。但是当你学习了一段时间泰文之后,再来看这本小说,之前的那种感受就再也没有了。

curse-resized

写书的时候,你首先需要具备某种知识。但是写书的目的是将这些知识传递给那些不具备此知识的人,而根据“知识的诅咒”,你又无法确知那些初学者会遇到哪些问题!解决这个问题的方法就是找初学者来试读。而且为了保险起见,还应该找尽可能多的人来试读。

写作方式

一种方式是自下而上的,写一些独立的文章,最后发现可以串起来,然后形成一本书,另一种方式是自上而下,但是又会逐步调整。根据经验,不论是写一篇简单的博客,还是写一本书,都需要按照自上而下的方式。随心所欲的写下去,基本上都收不住,而且整个文章支离破碎,貌似有很多内容,但是不成章法,读者也无法轻松的获取知识。

先列出大的章节,然后逐步细化,但是未必是按照顺序来写。先编写自己最熟悉的部分,然后逐步完善。例子的选取需要精妙而恰当,最好有图例来说明。

配图制作

一般而言,我在书中会使用两种图:流程图和一些截屏。截屏通常使用Mac OSX自身的功能就已经足够,而流程图我会采用一些额外的工具如:

  • graphviz
  • keynote/sketch

cgi

用Graphviz画图的好处就是可以将图像代码一样放入版本库来管理。

除此之外,我还学习了一些设计软件的基本用法,事实上只需要用一些简单的元素就可以做出非常专业的配图:

  • 字形/字体(大小,粗细的变化)
  • 颜色(基本的配色理论就可以做出很舒服的配色)
  • 层次(尺寸,位置,颜色的深浅)
  • 阴影

mock-server-resized

代码格式

书中实例需要很多代码来说明,如果是制作电子书的话,可以使用Markdown预处理器自带的功能来高亮。另外如果需要RTF格式,可以使用这些工具:

  • highlight工具
  • intelij中的插件copy on steriod

这里有一篇博客来说明如何将你的代码带着格式拷贝到剪贴板中,拷贝之后,就可以将这些内容粘贴到Word或者Keynote中了。

jest.dontMock('../components/headline.jsx');

describe('Headline', function() {
  var React = require('react/addons');
  var Headline = require('../components/headline.jsx');
  var TestUtils = React.addons.TestUtils;

  it('#render', function() {
    var text = "this is a title";
    var headline = TestUtils.renderIntoDocument(<Headline title={text} />);
    var title = TestUtils.findRenderedDOMComponentWithTag(headline, 'h4');
    expect(headline.getDOMNode()).toBeDefined();
    expect(headline.getDOMNode().textContent).toEqual(text);
  });
});

一些潜在的坑

在写作的过程中,会有一些潜在的坑。这些所谓的坑是新人可能无法想到的。相对于言之无物,不知如何下笔,最痛苦的其实在于平淡。大部分时候,你可能很容易就能写出开头,但是很难坚持到最后。即使好不容易写完了第一版,后续的重读和修改,会让你苦不堪言。

内容写好之后,样式是下一个重要的问题,好的内容需要有与之匹配的排版。在中国,作者不但要负责内容,还要负责一些排版的事情。这一点非常奇葩,但是又是实情。这也是我更推荐电子版的原因(排版更加美观,选择更加多样,而且一旦有问题可以更容易的修改)。

另外一个问题是错别字检查!检查错别字对于作者来说,是一件非常困难的实情。而对于读者来说,则是一件很容易的事情。这跟知识的诅咒的道理一样。

typo

发布方式

实体书

传统的出版方式有一些明显的问题,这些问题已经和现代的知识传递方式产生了冲突:

  1. 时滞性(新技术的更新速度远远超过审批,印刷等流程的时间)
  2. 排版(如何低成本做到语法高亮,或者彩图)
  3. 更新频率(当技术更新之后,如何更新,是传统纸质书无法解决的问题)

传统的出版方式有点像传统的软件开发,一本书从开始写作到最终出版,要经过很多环节。忽略掉写作过程,从交稿到出版会经历很多次审核和校对,可能会历时4-8个月,着这个过程中,很多东西都可能发生了变化,一个典型的例子是《用AngularJS开发下一代Web应用》,原版为英文版,翻译成中文版再到出版之后,书中的很大一部分内容已经过时。读者拿到书之后,会发现书中的内容已经和当前的版本/文档不匹配了。这种现状随着技术的更新速度和频率还会再加剧。

第二点是排版。我听说国内有些出版社已经开始接受Markdown作为稿件的格式,但是大部分还采用Word或者WPS等格式,这样排版就变成了一个大问题。以我自己为例,我的原稿用Markdown写,但是写了几章之后不得不切换到Microsoft word上,而我自己的Mac OSX下的排版到编辑的Windows下就会变样,而且还会涉及字符集,字体,Word版本等等问题的影响,最后导致印刷出来和原始稿件出入很大。

最后一点是更新频率,如果发现了错别字或者错误的地方(即使之前检查过多次,仍然会有漏网之鱼),由于实体书的特殊性,一般需要等到再次印刷才能解决。这意味着先购买的读者会承担一些风险,更新后的版本又如何让读者看到呢?总不能又买一本吧。

但是这些问题都可以通过电子书来很好的解决。首先,电子书可以随时更新,最低限度的降低时滞性。排版上来说,作者可以使用Markdown来编写,而展现则可以应用一些预定义的模板来完成。最后,更新频率完全可以控制,对读者来说风险更低,因为电子版书籍的可以很容易的追踪交易记录,从而得到免费的更新过的版本。

电子书

目前已经有很多的渠道可以发布电子书,比如gitbook知笔墨。这些应用的出现,大大降低了发布书籍的成本,我的《函数式编程乐趣》,用了3天就完成了草稿,而发布只需要数秒。

另外一个问题是书籍的价格和作者的收入。一本书定价50元RMB,出版社给作者的版税是8%,也就是说,没卖出一本,作者可以得到4元,如果你的书非常畅销,这还是一个不错的价格。但是可能90%的书籍都不会是畅销书(就好比每个班级都会有优等生,但是他们仅占全班人数的10%一样)。这对作者是一种浪费:你需要耗时数月甚至数年来写一本书,然后市场的反馈又非常慢(毕竟你无法出版一本未完成的书)。

我在selfstore.io上有两本电子书:《3周3页面》《函数式编程乐趣》《3周3页面》定价为16元,每卖出一本,扣除掉交易费之后,我可以得到14.7元。

对我来说,这样可以得到更多的回报,对于读者则可以更加快速的得到更新,而且由于有预览版和一系列的其他信息,还可以在很大程度上降低读者的风险(更不用说快递费,等待时间等问题)。我在gitbook上的统计显示,《3周3页面》已经被累计下载了28,861次,实际的读者也将近5,000。而且没有任何的审核流程,也没有排版的时间浪费,我只需要关注内容即可。

Share

微服务——大企业是如何在实践微服务中成长的

我足够“高”了么?

Martin Fowler描述过当组织在考虑实现微服务架构时,必须要有的一组“能力基线”,但大企业通常有各种理由不太愿意去尝试和成长以达到这样的能力。有很多的文字都提到,在成长之路完成后便能收获微服务架构所能带来的各种好处。这篇文章将描述一个大企业为达到Martin Fowler的能力基线,所经历的挑战和决心。

01
Image by Fabio Pereira

开篇

在行业中,微服务有着众多不同的定义。某些定义认为它是一种和Unix编程风格类似,以构建很多能够专注于做好一件事情的、微小的、有自治进程的架构风格。某些定义认为它是第一个后DevOps革命的架构。它从DevOps和持续交付中吸取到所有的经验,并且对其进行了优化。

我们采用微服务的初衷是为了提供一种能够扩大团队规模的途径。我们从一个单体应用开始,康威定律启迪我们分解这个单体应用。经过这个过程,我们最终变成了很多小而优的团队来进行交付。

团队的结构影响着系统的架构并不是一个新鲜事了。Nygard总结得很到位——“团队的工作分配方式就是架构的初稿”。这种最初对团队伸缩性的需求是将一批最佳实践带入微服务和持续集成的催化剂。

团队的工作分配方式就是架构的初稿。

拆分单体应用

当我们拆分单体应用时,我们面临的第一个挑战是尝试找到系统的接缝或者界限上下文。这种尝试带来了一个非常有意思的副作用,即我们可以通过识别系统中那些比起其他地方更不容易变化的地方,来解耦我们的系统。这和重构代码以让你的代码更经得起时间的考验类似,只不过是在架构层次上罢了。

从单体应用中分割出多个服务是很不简单的。包括创建单独的代码仓库,构建管道和基础设施建设。这些都要消耗时间。因为很多企业都对频繁构建新服务持悲观的态度,我们经常会听到犹豫之声:“如果构建一个服务都用了这么多时间,我们怎么做其他的服务呢?”

我们是在每个迭代中逐步攻克这个问题的。我们改进我们的构建管道、工程的创建、环境设置和部署。这是从微服务架构中所获得的很大一部分益处——它不仅强制性的将质量和成熟度构建进你的软件,而且也包含了开发流程和实践。

步入云端

在改进DevOps最佳实践的路上,配置环境成了畔脚石。如果需要另一个部门花几周的时间,去配置好一个新的机器来托管你的新服务,你就有麻烦了。幸运的是我们已经准备好步入云端,并且已经在企业层面上准备好了支持云部署所必须的工具链。

即便有这些工具,开发人员也必须开始拥有他们的软件,包括生产环境的部署和支持。封闭的组织有一个趋势是将他们的开发人员与真实地生产环境隔离开。“谁构建,谁拥有”这个思想非常的重要,它能促进最佳实践地成熟。亦即,如果开发人员已经对生产环境的稳定性和支持有浓厚的兴趣,那么很有可能是他们构建了这个系统。

谁构建,谁拥有

消费者驱动的契约测试

我们已经拥有了很多已经部署到云端的RESTFul API,并且由团队自己维护这些API。这就意味着团队可以不借助其他人的力量进行独立的开发。不过,我们开始发现依赖的服务在逐渐改变我们的行为。测试和利益相关者开始抱怨系统不稳定——但当我们是单体应用时这根本不是问题。

我们使用集成测试来解决这个问题。服务提供者为其API的消费者维护一组测试,而不是消费者自己为契约写集成测试。这样做有很多的好处:首先,如果服务提供者破坏了契约,它会直接被告知;另外,如果消费者增加了新的测试场景,但这个场景破坏了契约,那么构建也同样会失败。这些考量驱动出更重要的事情,也即团队之间的交流以及尽快的开始这些对话。API始终可以进化,但它会有足够的约束来保证稳定性。

蝴蝶效应

解耦单体应用的另一个副作用是监控的工作量成倍增加。之前你可能在一个应用中只有一个终端(endpoint),而现在你有很多的服务。为了更好地保证应用正常工作,你必须要为支撑你的服务的基础设置上提供足够的监控。

在单体应用中,如果一个服务调用失败了,我们会清楚地知道哪里出错了。但在一个经常变化的解耦架构中不再成立。当一个服务失败了,真实的失败位置可能是在依赖树上的数个服务。这就意味着平均修复时间(MTTR)会受影响——我们必须要调查受影响的服务,也会调查这个服务所有的依赖。我们使用PRTG监控工具来解决这个问题。PRTG给我们提供了一个高级的仪表盘(dashboard)来图形化系统的不同的部件。

我们发现的另外一种必要地监控是分布式的日志收集。这允许我们从不同的服务器收集日志并且可以做联合查询。我们甚至可以引入相关性ID来改进它。这样分布式的日志允许我们跟踪一个请求的在系统的不同服务中的跳转过程。

展望

当然我们还有一些需要在未来解决的困难问题。包括一些棘手的组织变化,例如将交付与产品对齐而不是和工程对齐,并且使开发人员能够在DevOps的环境中工作。这也包含了更多的环境配置,包括更多的通过Ansible来进行基础设施自动化。尽管还有未来的挑战,我们已经开始收获一些引入微服务先决条件所带来的好处了。你的微服务的旅程是怎样的呢?

Share

敏捷中的QA

说到QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst),主要基于以下几个方面的原因:

  • 质量保证更偏向于工业说法,称参与软件测试的人员为质量分析师感觉更恰当;
  • 质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中的QA更多的是建议提供者而非看门人,把QA称为质量分析师更能体现敏捷中团队对质量负责的原则;
  • 质量分析师更重视业务价值,关注业务价值的分析。

QA,质量分析师,显然与测试有关。敏捷中的QA,也就是与敏捷测试有关。敏捷测试就是在敏捷开发模式下对软件进行的测试,要求尽早测试、频繁测试,以及时提供反馈。敏捷测试要求团队对软件产品的质量负责,而不是某个带有QA头衔的特殊人员。敏捷中的QA可以是参与敏捷测试的所有团队人员,而并不一定是特定的专职的测试人员。

这听起来是不是有点特别?跟传统开发模式下的测试人员是不是有些不一样?别急,我们先来看看敏捷中的QA是如何进行日常工作的。

敏捷QA的日常活动

从迭代到发布,敏捷测试的生命周期各个阶段QA的活动主要有:测试分析,测试自动化策略分析、框架构建等,故事测试,迭代计划会议和客户演示,测试自动化的维护和执行等。如下图示:

1

QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的故事进行验收测试、探索性测试,和开发人员结对实现测试自动化;还要和业务人员结对分析下一个迭代的故事,编写验收标准和测试用例。

在单个迭代内部,伴随着故事生命周期,QA的活动有哪些呢?用户故事生命周期包括以下几个阶段:故事分析、故事计划、故事开发、故事验收、故事测试/探索性测试、系统测试和客户演示。QA参与故事的整个生命周期,在每个阶段都会发挥作用。

3

  • 故事分析阶段:需求澄清,业务场景和验收测试的确认
  • 故事计划阶段:拆分测试任务,在每个故事开发估算基础上考虑测试的时间和估算
  • 故事开发阶段:和开发人员结对实现自动化测试,和团队沟通发现的问题和缺陷
  • 故事验收阶段:开发人员开发完故事后,QA和业务分析人员要在开发机器上进行验收,以提供快速的反馈;同时还要对测试覆盖率(单元测试、组件集成测试、功能测试)进行确认和提出反馈
  • 故事测试/探索性测试阶段:执行自动化验收测试,执行探索性测试,强调会阻碍故事发布的因素,和团队就测试覆盖率进行沟通,为发现的缺陷添加自动化测试
  • 系统测试和客户演示阶段:执行端到端的系统测试,执行业务或集成的用户测试场景,和团队及客户就功能特性的质量和稳定性进行沟通,参与给客户演示功能和特性

正如前面提到的,在每个阶段,QA除了要独立进行测试,通常还需要跟不同的角色结对,包括业务分析人员、开发人员、以及客户。

4

  • QA与业务分析人员结对:通常在业务分析师分析用户故事的时候,QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对,QA能够更好的理解领域知识,从而有利于定义合适的测试用例;QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。
  • QA与开发人员结对:QA和开发人员分别能给团队带来不同的技能集,认识到这一点很重要。作为一个团队,最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。通常在实现测试自动化的时候,QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高,有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分,而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。另一方面,QA通过与开发人员结对,编码能力也会相应有所提高,而开发人员通过与QA结对,测试意识也会增强,更有利于编写质量较高的产品代码,更有利于形成全功能团队。
  • QA与客户结对:客户是业务领域专家,通过与客户结对,QA能够更好的从终端用户的角度理解系统,从而定义或者增加更多的端到端的测试用例;一旦QA理解了领域知识和终端用户的观点,其业务价值分析能力会有所提高,在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段,QA通过与客户结对,帮助客户熟悉使用系统,在必要时可以帮助客户解决一些系统问题。

敏捷QA的这些日常活动,的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。下面为大家来详细介绍一下两者的不同,以及敏捷测试对QA的要求有哪些。

敏捷QA与传统测试人员有何不同

我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面,来看看敏捷QA与传统测试人员有哪些不同:

传统测试人员 敏捷QA
单独的测试团队 多角色开发团队的一员
在开发流程后期才开始测试 测试贯穿于整个开发流中
通常是独立工作 QA和不同角色进行结对
被当作最后也是唯一的质量保证 关注并强调风险
缺乏与业务人员的直接沟通 和业务人员直接沟通
没有机会参与发布计划制定 参与发布计划的制定

从上表的对比可以看到,敏捷QA是特殊的,主要体现在:

  • 敏捷QA是提出建议者而非看门人,需要在参与的每个阶段提出自己的建议,而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求,还要发现需求是否能真正体现业务价值,分析是否有不恰当或缺失的需求。比如说,敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求,在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。
  • 发现风险,并将风险与团队及客户沟通。QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的,因此也更容易看到系统存在的风险。
  • 及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。
  • 在制定产品和版本的发布计划的时候,QA可以根据自己对产品质量的了解,从测试人员独有的视角提出一些关键的建议。
  • QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来。比如:在故事验收阶段对测试覆盖率的确认。

这些特殊性对敏捷QA也提出了更高的要求,需要做到:

  • 具有丰富的产品知识和对用户业务目标的准确了解
  • 对不同系统和数据库所用到的技术知识的了解
  • 和不同角色以及客户进行有效沟通
  • 主动验证质量目标并及时说出自己的想法
  • 编写测试计划,列出需要执行的活动并进行估算
  • 自动化测试的能力和对测试工具的基本了解
  • 在团队内部进行知识分享,协助整个团队参与到测试活动中来
  • 持续提供并获取反馈

本文转载自:http://www.infoq.com/cn/articles/agility-of-qa

Share

闲谈集群管理模式

docker很火很红,简直到了没有道理的地步了。docker为什么这么红?因为它是一种可以用来掀桌子的技术。在部署自动化这条产业上的工人和机床制造商们,看家护院的 cmdb,分布式脚本执行等所谓核心技术即便不会变成明日黄花,也会沦为二流技术。仅仅把 docker 当成一个轻量级 vmware 来使用,是没法看穿其实质的。要理解 docker 的意义,不能从 docker 是什么,能够干什么说起。让我们先来回忆一下集群管理模式的发展历程,以及这些落后的模式的种种弊端。

手工管理时代

IP地址是放在 excel 表里的。管理是靠登陆跳板机,用 SSH 连接服务器。手工执行命令做新的服务器部署,已有服务器的程序版本升级,以及各种配置刷新修改的工作。
弊端不言而喻,主要有这么几点:

  • 缺乏一致性,因为是手工操作所以服务器之间总是有一些差异
  • 效率低下,一个人可以管理的服务器数量非常有限

自动化大跃进时代

业务数量的增长,很快使得机器的数量超过手工操作维护的极限。无论再烂的团队,只要业务长到这个份上了,必然会出现大量的自动化工具用脚本自动化执行的方式快速地支撑业务。这个时代是一个黄金时代,运维真正长脸的时代。因为没有自动化的运维技术,业务就会遇到瓶颈。自动化技术的引入,切实地体现成了业务的收益。
这时代的特征是两个关键的系统

  • 把本地 excel 表格里的 IP 地址用数据库的方式管理起来,称之为 CMDB
  • 基于 ssh 或者 agent 的分布式脚本执行平台

效率低下了不再是主要问题,主要的弊端变为了:

  • 大量的脚本,杂乱无章,内容重复,质量难以保证,最终给故障留下隐患
  • 没有对现网预期状态的定义和管理,所有的现网状态都是脚本日积月累的产物,导致服务器状态漂移,产生雪花服务器(每个机器都不一样),进而给业务稳定性留下隐患

这些弊端短期对业务来说并没有立竿见影的伤害,属于内伤型的。而且很多隐患即便暴露了也会流于强调纪律,强调运维意识云云。很少会有人去追究背后的运维理念的问题。结果就是大部分公司都停留在这个阶段了。毕竟运维是一个足够用即可的支撑领域。运维搞得再高科技,特高可用,未必和创业公司的成功有多少直接联系。

开发闹革命时代

伴随 devops 同时出现的是 infrastructure as code 的提法。简单来说就是一帮开发杀到运维领域之后,看见这些运维居然是这样去管理现网状态的。于是他们把写代码的经验带过来,将现网状态建立成模型(所谓 code),把预期的状态提交到版本控制中。就像写代码一样,去管理服务器配置。
很多后台开发主导的小创业公司直接跳过了上个时代,运维自动化体系从一开始就是基于 puppet 和 chef 来搞的。平心而论,用 puppet 的更多是缺少历史包袱,而不是因为运维问题有多复杂。很多管理的机器数量不超过十台,却在如何使用 puppet/chef 上浪费大把时间的团队也是有的。相反很多大公司因为有沉重的历史包袱,和庞大的传统运维团队,这种开发闹革命的路反而走不通。
这种做法主要是解决了脚本的管理问题,而且因为直接定义了现网状态,服务器之间的一致性也会好很多。但是光鲜亮丽的模型背后本质上还是一堆脚本来驱动的。上个时代的弊端只是经过了包装和改良,并没有办法根除

  • 应用预期状态到现网依靠的还是跑脚本。而且与之前不同,现在更多的是跑别人写的cookbook了,质量也是良莠不齐的
  • 虽然定义了预期的现网状态,但是起点不同(比如从a=>c, b=>c)需要做的升级操作可能完全是不同的。要编写一个面面俱到的升级脚本其实非常困难。

还有哪些问题?

一致性和稳定性是最大的问题。服务器开机之后,常年是不重装系统的。无数人在上面跑过脚本,执行过命令,定位过问题。服务器实际的状态是没有办法精确管控的。infrastructure as code 是一种改良,但是仍未根除这个问题。每一次在服务器上跑脚本其实就是一种赌博,因为没有两台服务器是完全一样的。在本地测试可行的脚本,未必在另外一台上不会引起问题。这不是强调一下代码里不能 rm * ,而要 rm path/* 就可以解决的问题。

版本管理其实一直是没有的。做过开发的人,可能还会用 git/svn 来作为部署的基线,基本的版本都会提交到仓库里。更多的一线运维用的还是 rsync 的模式。rsync 的意思就是要安装一个新服务器,需要找一台“与之最像”的服务器。然后把文件拷贝到新服务器上,把配置修改一下,启动完事。携程出事了,我个人猜测应该与版本管理混乱有关系。

故障替换是非常困难的。先不说故障替换,就是故障机剔除就是一个头疼的事情。比如 zookeeper。各个客户端都硬编码三个 ip 地址。一旦其中一个 ip 挂掉了。zookeepr按照高可用协议可以保持正常,但是长期来说这个挂掉的ip还是要从各个使用方里剔除的。这个就且改了。一旦业务的高可用做得不好,需要运维来搞一些接告警之后替换故障机的事情,那就是各种脚本折腾各种配置文件的节奏了。

Docker 是如何掀桌子的

两点神论,进入到 Docker 时代之后

  • CMDB 不再至关重要了。CMDB 连同IP,以及服务器资源变成底层蓝领工人关心的问题了。上层的后台开发和业务运维不再需要也无法再以 IP 为中心的 CMDB 来管理配置。
  • 分布式脚本执行平台从核心作业系统退居二线。很简单,服务器不再需要变更了,常规的上新服务器,发布新版本都不再依赖脚本在一个已有的服务器上执行去修改状态。而是创建一个新的容器。

Docker的实质是一个真正的版本管理工具。在 Docker 之前版本管理是各种拼凑的解决方案。什么是版本,服务器是由三部分组成:版本、配置、数据。所谓版本就是操作系统,以及操作系统的配置。各种第三方包,开发给的可执行文件,和一部分配置文件。这些的集合是一个版本,其实就是一个完整的可执行环境。除此之外一般就是一个数据库,里面放了两部分内容,一部分是管理员可以从页面上修改的配置,一部分是业务数据。在 puppet 时代的版本,是一个申明文件。这个申明文件执行的时候,需要先从某个 ISO 安装出一个操作系统,然后用 apt-get/yum 从某个镜像源安装一堆系统的包,然后用 pip/bundle 安装一堆 python/ruby 语言层面的包,最后才是开发给你的 git/svn/某个不知名的tar.gz。你以为这些东西每次拼装出来的东西都是同样的版本么?其实未必。想当年某墙干掉 github 的时候,不知道多少人无法做发布了。Docker 打包出的连系统在一起的镜像,其实是对版本的最好阐述。

使用 Docker 之后不再需要修改现网的 container 了。一个 container 如果需要升级,那么就把它干掉,再把预先做好的新的镜像发布成一个新的 container 替换上去。分布式脚本执行,变成了分布式容器替换了。当然这种标准化的操作,用 mesos + marathon 已经完美解决了。

使用 Docker 之后,无法再基于 IP 做管理了。倒不是给每个 container 分配一个 IP 分配不过来,而是 IP 代表的静态模型无法跟上时代了。基于 IP 管理,就意味你会基于 SSH 登陆这个 IP 来管理。这种思想从骨子里就是落后的了。进程,进程组,模块,set 这些才是管理的粒度。至于进程是跑在哪个 IP 上的哪个容器里,不再重要了。一图可以说明这个问题:

1

 

上面这个扩容的按钮点完之后有让你填 IP 吗?没有!你只需要告诉marathon,我要32个进程实例。它就会去找这些资源运行这 32 个实例。业务最终需要的是 32 个进程,而不是 32 个 IP。IP只是运行进程需要的资源而已。实际运行的时候进程可能是在一个IP上启动了32个端口,也可能是随机分配了5个IP,每个各跑了一些端口。当然这些分配都是可以通过“约束”的方式表达的。而不是让你去搞32个IP来,再跑个脚本去这些IP上部署这些进程。

The Missing Piece

拼图游戏就差最后这一块了。Docker 做为一个版本工具是绝对合格的。Marathon 以 Docker 的方式托管所有进程也是靠谱的。但是还不完整:

  • Docker镜像作为版本发布到现网之后是无法运行的,因为任何一个应用起码都有好几个服务要互相访问。这些硬编码在镜像里的 IP 地址换了一个环境是无法执行的。一个版本里任何配置都可以硬编码,就是 IP 地址和端口是没硬编码的。
  • 扩容缩容可以很容易创建和销毁容器,但是引用了这个容器的服务器的其他容器怎么办呢?
  • 发布,故障替换都是同样的问题

解决方案可以看这两张图:

2

3

方案其实非常简单。把 app1 => app2 的网络访问关系,改成 app1 =local=> haproxy =network=> haproxy =local=> app2。通过在容器本地部署 haproxy “托管所有的端口”,也就是用 haproxy 在进程之间做联线,而不是每个进程自己去负责连接网络上的其他进程。

试想一下之前是在配置文件里硬编码 10.0.0.1:3306 是某台数据库。硬编码是不对的,是要打屁股的。所以我们把硬编码的 ip 地址改成 127.0.0.1:10010。这一次我们不再硬编码任何 IP 了,我们只硬编码一个特殊的端口号。每个进程都有一堆特殊的本地端口号用于访问自己需要的上下游服务。这个端口号背后的进程到底在哪个 IP,哪个 端口,哪个 container 里执行。做为使用方不需要修改任何代码(比如兼容什么 zookeeper/etcd 神马的),也不用关心。甚至这个端口后面是多个远程的IP构成一个基于客户端的高可用。代理甚至还可以做一些出错换一个后端再重试的事情。

有了这种神器之后,扩容所容,发布变更,故障替换都很轻松了。容器随便新增,随便删除。网络结构变化了之后,刷新各个地方的 haproxy 配置就是了。各种灰度,各种零停机替换方案都可以搞起。

名字服务与网络

类似的方案有很多。最底层的方案是 SDN/IP 漂移,以及网络的bonding。这种方案的特点是保持 IP 地址作为最传统的名字服务,妄图延续其生命。
上层一点的方案是 DNS。再上层一些的方案是 Zookeeper。
各种方案争的就是服务如何注册自己,如何彼此发现这个点。各种方案的优缺点可以自己去读:

http://nerds.airbnb.com/smartstack-service-discovery-cloud/
https://blog.docker.com/tag/smartstack/

btw,airbnb 在 13 年就把这套方案投入生产了。

最有意思的是把这种 haproxy 的方案与基于 SDN 的 IP 漂移方案做对比。haproxy 的就是替网络做应用层进程之间联线的事情,通过引入 haproxy 让这种联线更具有灵活性。 而 SDN 的方案是说,你现在的业务进程之间是通过 IP 之间静态链接的,这种连接不够灵活没关系,路由器帮你整。一个 IP 挂掉了,可以把IP漂移到另外一台机器上去继续使用。其实就是在一个场景下实现两个进程的重新联线,突破两 IP 之间静态互访的限制,给基于 IP 的部署方案续命。

两者底层的技术是相通的。所谓 IP 漂移最后靠的是现代牛逼的CPU,和软件路由技术。最后玩的都是用户态转发,dpdk神马的。所以 haproxy 慢,转发效率有问题神马的,长期来看都不会是问题。用软件来联线,是趋势。连路由器都开始这么玩了,连硬件厂商都开始卖软件了。

The Final Battle

集群管理纯粹变成进程管理,IP不再重要,状态不再重要。CMDB会变得越来越边缘化。
发布变更不再是去修改服务器,而是新建销毁容器,以及更新进程间网络联线关系。分布式作业系统会越来越少用,跳板机就更加不允许使用了。

记住“immutable servers”这个提法吧,它终将会得到历史的认可。

经原文作者同意转载,文章转自:http://segmentfault.com/a/1190000002882567

Share