2012年七月月 发布的文章

绥中电厂海滩之旅

上周末,部门组织了一年一度的集体出游活动,这次的目的地是位于葫芦岛市附近的绥中电厂海滩。

 
周六(北京时间7月28号),恰逢伦敦奥运会举行开幕式,很遗憾不能完整的看完现场直播。在看完憨豆先生的精彩表演后,我就从家里出发了。本来这次旅游我是想带LP和果果一起去的,之前用一周时间已经做好了所有准备(吃的、穿的、玩的、用的),但人算不如天算,果果居然感冒了,早上起来一量体温:38度。唉,果果与大海第一次邂逅的时间只能推迟了。
 
天气预报也没有给我们带来什么好消息,受冷涡影响,周六、周日葫芦岛一带有各种雨:中雨、大雨以及雷阵雨。还好,大家也调低了对此次出游的期望:大不了就在住所打牌吗!大巴准时从沈阳出发了。
 
将近六个小时的行程让人有些疲惫,路上虽然顺利,但有些惊险:大巴刚到京沈高速锦州西出口时,老天就降起了瓢泼大雨,雨最大时能见度估计也就二三百米。司机降低了车速,我们到达的时间也延后了将近两个小时。老天也许是怜悯我们,当我们到达目的地时雨居然停了。
 
这次我们住在农家院,房间挺不错的,几乎每间屋都有电视和空调,4人以上房间还都有室内卫生间,可以洗热水澡。吃的也还行 – 只要不吃坏肚子,我都认为“不错”^_^ 。最大的不足就是离海边太远,步行要半个小时,这与之前几次到海边旅游的境况大相径庭 – 以前基本上出门就能看到海。
 
匆匆午饭后,我们就乘车来到了海边。外面的天很阴沉,没有太阳,也就没那么晒,至少省防晒霜了。不过这里的海却不那么吸引人 – 水质黄浊,风浪巨大。不知道是不是这里的泥成分较大,海水发黄,十分浑浊,与之前我在网上看到的网友的评价出入很大啊。另外当天风浪很大,初步目测了一下,浪高在0.8-1米左右,即使会游泳的人也不敢贸然向远处游,绝大多数人是套在泳圈里在岸边接受“海浪”冲扶:(。海滩也很窄,没走几步就延伸到海中了,坡度也陡,难觅平缓;沙子较粗,同事开玩笑的说:这不就是建筑工地用的那种沙子么^_^。
 
 
水太脏,索性也就不下海了。沿着海岸走了一周,无趣。于是和同事一起到岸边组织踢沙滩足球。估计与我有同感的同事有不少,不一会儿就聚集了好多要踢球的同事。沙滩上踢球是很累的,踢了几个回合下来就已经全身透汗了。另外由于沙子较粗,一不小心脚内测磨掉了一小块皮。于是下场用清水冲洗伤处,坐下休息。
 
沙滩的配套设施也不那么完善,淡水淋浴房中出的水十分浑浊,看到进去洗澡的同事都扫兴而出。玩得不尽幸,索性也就早点回了驻地(没等旅行社的车)。
 
晚饭后,有些人回屋以电视消遣,有些人(包括我)则开始打牌消磨时间。这时外面居然下起雨来,而且是雷雨 – 电闪雷鸣的。突然听到一个极响的雷,然后农家院所有的电视信号就都没有了。估计是小镇的电视信号设备被雷搞坏了。那些看电视的同事无所事事,也就陆续卧床休息了。我们继续打牌,一直打到快11点了,雨停了。年轻的同事提议去外面吃烧烤,考虑到外面道路泥泞,还没有路灯,再加上我也不喜欢海鲜烧烤,因此我也回屋休息了。还别说,一天下来还真的挺累,很快就进入了梦想。半夜时分,外面似乎又下起了暴雨,且伴有雷电,翻了个身,继续在梦中旅游^_^。
 
第二天起来时,雨早已停了,外面有些凉,但空气不错,天气有转晴的迹象。按照导游的计划,今天我们去另外一片小海滩 – 那里游客不多。早饭后乘车来到这片海滩,的确不大,人也的确很少,但海水与昨天的海滩没有大分别,浪似乎更大了。大家基本没有下水的。海滩上有一个简易排球场地,我们租了个排球,继续海滩运动之旅。好久没打排球了,不过高中的排球底子还在,感觉还行 –  技术动作还是蛮规范的^_^。大家玩得还是蛮欢乐的,打了近两个小时,全身透汗,不过时间到了,该乘车返回了。
 
两天的绥中电厂海滩之旅就这样不温不火地结束了,中午十分,天已大晴,太阳出来了,瞬间大家就感觉到了热量。午饭后,大家赶紧钻进已开空调的大巴车中,等待回程。一路无雨,行车速度自然也就快了许多,4个半小时多点,我们就回到了沈阳。
 
乘地铁回家,看到果果病已痊愈,虽疲劳,但还是蛮高兴的。

buildc 0.1.9版本发布

随着buildc使用的深入,越来越多的新需求暴露了出来。为了满足这些需求,我们组的小兄弟又对buildc进行了一些改造,这些变化如下:

1、支持将多个子工程打包到一个安装包中

最初buildc的设计思想是为每个子工程单独制作安装包,这样具有很强的灵活性。但在对现有N个工程进行构建脚本改造的过程中发现,有些工程间存在严重 依赖,比如工程A是一个业务级公共库工程,工程B和工程C都依赖工程A构建后生成的静态共享库。而工程A又无法被当成第三方库处理,这给我们的安装包构建 制造了难题。我们的解决方法就是改造安装包工程的setup.cfg文件,让其支持多source。从正规语义上来讲,我们这么做将使得buildc支持 将多个子工程打包到一个安装包中,而间接的作用则是解决了上述有依赖关系的工程安装包制作的问题,虽然看起来不那么美。

修改后,setup.cfg中配置就变成下面这种情况了:

source = [
  {
     "trunk"          : "svn://10.10.15.56:4444/cn/trunk/A",
     "binary_prefix"  : "fooA"
  },

  {
    "trunk"          : "svn://10.10.15.56:4444/cn/trunk/B",
    "binary_prefix"  : "fooB"
  }
]

不过问题并没有彻底解决。A工程的构建结果是一个.a文件,按照原buildc处理流程,该.a文件会被放入安装包中的app目录下,但这不是我们想要 的,.a文件是不应该放入安装包的。与此同时,一些子工程的输出是.so文件,按照最初的规划,这些.so文件应该被放入deps目录,而原buildc 默认都是放在app目录下。为了解决这个问题,我们给source做了"属性扩容" – 增加了一个可选的pack_path字段。

source = [
  {
     "trunk"          : "svn://10.10.15.56:4444/cn/trunk/A",
     "binary_prefix"  : "fooA"
     "pack_path" : ""
  },

  {
    "trunk"          : "svn://10.10.15.56:4444/cn/trunk/B",
    "binary_prefix"  : "fooB"
  },

  {
    "trunk"          : "svn://10.10.15.56:4444/cn/trunk/C",
    "binary_prefix"  : "fooC"
    "pack_path" : "deps"
  }
]

这个示例中,A工程pack_path的值为"",buildc将忽略A工程的输出文件,B工程没有配置pack_path,则buildc默认将B工程 的输出文件放入app目录;而C工程明确为pack_path赋了值,buildc会将C工程输出文件放入deps目录。

buildc原本支持在命令行输入工程源码库地址(–tag=YOUR_SOURCE_TAG),现在依旧支持。一旦命令行指定了工程地 址,buildc将不会理睬setup.cfg中source中配置的各个源码库路径,将从命令行指定的工程地址处取得最新源码,但暂无法指定 pack_path,默认会将构建结果放入app目录。

2、打包时自动生成VERSION文件

buildc在执行pack build后,自动在安装包中生成一个VERSION文件。该文件中包含与安装包匹配的平台信息(包括CPU体系、OS类型等)以及构建时的一些版本信 息。该文件除了便于安装包使用人员查看安装包相关版本信息之外,还可以用作安装包在目标平台进行约束检测的依据。如果你的安装包是for x86-64 linux的,那么宕操作人员误将该安装包部署到Solaris 10 for sparc平台时,安装包中的deps_check.py脚本会比对当前平台信息与VERSION文件中携带的信息,发现不匹配,则报错并停止程序的安 装。

3、其他

该版本buildc还提供了一些脚本的详细示例,如env_gen.py、deps_check.py。另外从Make.rules.in模板中去除了硬编码的-D_DEBUG定义。

读《How Google Tests Software》

一直对Google这个牛X公司的内部开发过程很是感兴趣,毕竟像Google Search EngineGoogle云计算平台这些伟大产品都是在这个开发过程下缔造出来的。但也许是Google保密工作做的很好,或许人家不是刻意保密,只是 因为工作太忙或人员太低调,没空派人出来宣讲罢了。外界对Google内部的开发流程知之甚少;知道一些,诸如20%项目,也只是皮毛。

终于有一天,Google的三位工程师冒了出来,为我们带来的了一本名为《How Google Tests Software》的小书。我断断续续用了不到一周时间粗略地浏览了一遍这本书,算是对神秘的Google内部开发过程有了初步的了解了。其中有一些思路 还真是值得我后续深入思考,这里仅列出一些让我心有所触的"点",与大家共享。

书是从Test角度展开的,但Google的Test与我们所熟知的Test还有不同,包括这个过程的角色设置与职责等。下面是从书中摘录的一些语句(有些地方是我总结后的)和观点,再加上我的一些体会。

1、在Google,Software Testing被称作"Engineering Productivity(工程效率)",既负责开发和测试工具的开发、发布工程,还负责从单元测试(unit level)到探索性测试(exploratory testing)的全过程。
     
      — 在国内,多数公司的Testers只负责测试过程,而且多从功能测试开始,Unit test是开发人员的责任。大部分公司的开发与测试工具都是开发人员设计和实现的,但也有少部分先进的公司有专职的测试工具开发岗。总体来 说,Google内部的"测试人员"角色是与众不同的。

2、"Quality is a development issue, not a testing issue"、
     "At Google, this is exactly our goal: to merge development and testing so that you cannot do one without the other. Build a little and then test it. Build some more and test some more. "  、
     "The reason Google can get by with so few dedicated testers is because developers own quality.If a product breaks in the field, the first point of escalation is the developer who created the problem, not the tester who didn't catch it."
     "Testing must be an unavoidable aspect of development, and the marriage of development and testing is where quality is achieved."

     — 可以看出Google信奉:"Developer是质量的owner,是第一责任人;质量应该由开发人员把关;测试是开发过程必不可少的一方面;将开发与 测试融合在一起以获取更高的质量;开发一些,测试一些(迭代的思想)"。而国内多数组织依旧信奉着测试是软件质量的最后保证这一信条,将开发和测试隔离的 很开。
 
3、Google内部开发测试过程的三个角色:software engineer (SWE) 、software engineer in test (SET)和 test engineer (TE),Google SWEs are feature developers. Google SETs are test developers. Google TEs are user developers.

    — 在Google,似乎没有纯粹的传统意义上的Testers,按照书中所讲,SWE肯定是开发工程师,负责实现产品功能(feature),而SET,其 实也是开发工程师,用于编写产品的测试Feature,关于测试Feature这个概念很独特,Google认为,产品应该有两种Feature属性,一 种是function feature,一种则是产品的test feature,而SWE和SET则分别focus这两点。SWE和SET共享同一代码库,是开发过程中的Partner。与SWE关注功能 feature不同,SET更加关注产品的可测试性、如何通过测试提升产品质量以及提升测试覆盖率以及产品性能。他们为产品的feature编写测试代 码,从单元测试到后续的各种测试,编写各种工具,并尽量的将测试自动化,提升测试效率。

       而TE这个角色则有些类似传统的Testers,但在Google也有不同。在Google,TE更多是从user角度去探索产品,有的TE会编写大量脚 本代码,模拟user使用产品的各种场景;按照书中的说法:"TEs are product experts, quality advisers, and analyzers of risk"。

4、One of the key ways Google achieves good results with fewer testers than many companies is that we rarely attempt to ship a large set of features at once.

    — 显然Google也倾向于增量的迭代开发,这种模式符合Google内部的role设置,同时,这种role设置也更好地促进了增量迭代开发的顺利高效开展。

5、Build the core of a product and release it the moment it is useful to as large a crowd as feasible, and then get their feedback and iterate. This is what we did with Gmail, a product that kept its beta tag for four years.

     Google often builds the minimum useful product as an initial version and then quickly iterates successive versions allowing for internal and user feedback and careful consideration of quality with every small step. Products proceed through canary, development, testing, beta, and release channels before making it to users.

   — 这似乎就是Google著名的"Beta"模式,目前很多互联网企业(特别是startup)均效仿之。

6、Instead of distinguishing between code, integration, and system testing, Google uses the language of small, medium, and large tests, emphasizing scope over form.

    Small tests cover a single unit of code in a completely faked environment. Medium tests cover multiple and interacting units of code in a faked or real environment. Large tests cover any number of units of code in the actual production environment with real and not faked resources.

    The general rule of thumb is to start with a rule of 70/20/10: 70 percent of tests should be small, 20 percent medium,
and 10 percent large.

   — Google内部的测试不是按照代码单元测试、集成测试以及系统测试这些典型的阶段划分的,而是用"small、medium、large、 enormous"这些词汇来描述测试的各个环节,这些词汇也是Google内部的"共同语言"。如何界定这些测试的scope呢?Google内部有一 套共享的测试执行系统,它通过test size来界定不同的test类型。比如:对small tests的要求是每方法(method)的测试执行时间不能超过100ms,如果1分钟仍然执行不完,则将被kill掉。

7、Keeping it simple and uniform is a specific goal of the Google platform: a common Linux distribution for engineering workstations and production deployment machines; a centrally managed set of common, core libraries; a common source,
build, and test infrastructure; a single compiler for each core programming language; language independent, common build specification; and a culture that respects and rewards the maintenance of these shared resources.

   — 在Google内部一切都是"整齐划一"的,大大降低了各种人员在熟悉、学习和使用过程中的工作量。可以看出,Google为了提升内部开发效率,真是无 所不用其极啊。另外Google内部这套完整的强大的基础设施工具、库、语言以及流程支撑想必也让大家垂涎三尺吧。

8、There is no set rule at Google for when SETs engage in a project, as there are no set rules for establishing when projects become “real.” A common scenario for new project creation is that some informal 20 percent effort takes a life of its own as an actual Google-branded product. Gmail and Chrome OS are both projects that started out as ideas that were not formally sanctioned by Google but overtime grew into shipping products with teams of developers and testers working on them.

No project gets testing resources as some right of its existence. The onus is on the development teams to solicit help from testers and convince them that their project is exciting and full of potential.

  — 这两段话既描述了SETs进入项目的时机,同时也从侧面反映出了Google内部产品的初期形成机制。在这种机制下,一些著名产品诸如Gmail、 Chrome等诞生了。个人很是认同这种自底向上的产品"产生机制",有利于员工创造力的充分展现。其实退一步来说,我们不一定非要公司明确规定设置 20%个人时间,只是我们在平时工作中主动去发现、去分析、思考和总结,我们一样可以"创造"出一些用于改善我们工作和生活的工具或产品,这些"成果"在 我们的日常工作中使用,逐渐被大家所接受,甚至于发展演化成熟,形成一个可盈利的产品或是贡献给开源社区,不是一样很好么。感觉国内的很多互联网公司里面 的一些同行正在做这些事情。

9、This is the convention at Google: Make the common case fast.

  — 这显然已经上升到了哲学的层次,不仅对开发测试过程的效率改进有着指导意义,对软件自身的调优也是一样富有价值。甚至于对我们的日常生活也是有帮助的。

10、Designs that seek to automate everything end-to-end all in one master test suite are generally a mistake. The larger an automation effort is, the harder it is to maintain and the more brittle it becomes as the system evolves. It’s the smaller, more special purpose automation that creates useful infrastructure and that attracts the most SWEs to write tests.

        Overinvesting in end-to-end automation often ties you to a product’s specific design.

  –  这又是Google内部对自动化测试的一种中肯的实用的理解。我们要自动化,但要掌握方法,不要大而全,要小且精,吸引SWE自己去写测试代码。过分追求全闭环的自动化测试会将你与一个产品的细节间建立依赖。

11、Google centers its development process around code reviews. There is far more fanfare about reviewing code than there is about writing it.
      
       These pre-submit rules cover simple things such as adherence to the Google coding style guide and more involved things such as ensuring that every existing test associated with the CL has been executed (the rule is that all tests must pass).

  — Google打造了一个以代码评审为中心的开发过程,建立了一套完整的日常开发流程以及评审流程。并通过一套完整的工具平台在代码提交评审前对代码进行各种自动化检查,让评审过程更加focus关键业务逻辑,而不是语法之类的细节。

12、Test Runtime Requirements
   – Each test must be independent from other tests so that tests can be executed in any order.
   – Tests must not have any persistent side effects. They must leave their environment exactly in the state when it started.

  — 这里点明测试执行的原则:测试case间无依赖,可任意顺序执行;测试执行应遵循"童子军"纪律:测试执行结束后,将环境恢复到测试起始状态。

13、带认证的测试(Test Certified)

  — Google内部建立了类似竞赛似的规则,对每个项目的测试水平进行认证,分为几个级别:从TC level1到TC level5。对于每个级别都有明确的指标,甚至是明确的达标数字,比如总测试覆盖率,各种类型(比如small)测试的覆盖率等。在每个项目的首页都会 看到该项目的认证级别。这种规则将促使项目SWE和SET不断地改善测试,来提升测试认证水平,间接地提升了产品的质量。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多