SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 2345|回复: 4

[赏析] 流水先生新作《软件集成策略》赏析五

[复制链接]
发表于 2013-9-13 09:00:25 | 显示全部楼层 |阅读模式
20.英英的强烈反应

4 Z. N4 }4 c) l2 g8 Y" J9 x9 X0 [" S9 r! m& ]; O  _) f: R- Z, G
晓川觉得,现在工作中昀无聊的事情,就是处理程序员提交申请。每当收到一封提交申请信,晓川就去检查里面有没有写“已基于某某基线并成功构建”。如果没写就打回去,而如果写了呢,就去版本控制工具里,把信中提到的任务分支合并到集成分支上。当然,如果出现合并冲突呢,就去找写提交申请信的程序员来解决。
; C& U: }4 F$ }
岂止是无聊,晓川对这项工作简直是深恶痛绝。找个小学文化程度的就能做嘛。啥叫 IT民工,这就叫 IT民工!
; m9 O! _, `/ t1 O; @6 d) {# [3 s/ K" |
跟师父诉过苦,师父说,“叫你干什么你就干什么呗。拿人钱财,替人消灾。又不短你的钱。”当时晓川心想,就忍着吧,锻炼锻炼呗。可是自打看了持续集成那篇文章,晓川的心里就蠢蠢欲动,心里总想着,把这事儿给扳过来。
) t4 n9 o: E9 a! r4 O; }, M/ C
英英一向是自己的同盟。晓川先去跟英英说,没想到出师不利。那是在去往舞蹈培训教室的路上,在地铁里,晓川跟英英说了自己的想法。

8 k/ {, o6 V, R/ [9 b) J1 H5 `$ \( R$ L+ }: u1 l1 E+ I# b
英英反应强烈:“你怎么会有这样的想法?好不容易我们做的改进,让程序员基于昀新的基线并且通过构建后再提交,现在又要退回去了!”

3 b. N0 N9 R( D; z. s) r5 H! j晓川:“我不是这个意思啊,程序员仍然要基于昀新的基线并且通过构建后才能提交。”' j' B: W9 ^2 C- O: p4 a3 i

9 A& R7 m# O4 [* T% W# f4 T& O
英英:“可现在谁来控制他们啊,他们就算没做不也一样能提交啊。”

; x  W/ s( [  N3 p3 W. a2 }3 D2 J晓川:“流程在控制啊,流程这么规定了,当然就得这么做啊。就好像,红灯停,绿灯行,十字路口用不着总戳着个警察指挥交通。”
9 O7 B  T" I# {  m6 C" }" \* R* p( f% E3 X& j* p
英英:“好好好,照你说的,红灯停,绿灯行。可红灯的时候过马路的人还少吗?你刚才不也是?”刚才去地铁站的路上,两人聊天儿,晓川没看灯就要过马路,被英英给拽住了。
' S1 E3 b4 H6 D: J1 p/ K
晓川噎住了,半天没话说。半天才憋出一句:“可以事后检查啊。集成遇到问题,我可以反推,可以检查任务分支是不是基于昀新基线,是不是能通过构建。”
- N9 b0 I( d6 |. x
9 S5 c" c0 \& l" k$ s% n7 q
英英:“反正我觉得不行。我看你找这么多辙,其实根子里就是好逸恶劳,不负责任!”
: [8 o7 i$ m8 R' S; b. i4 v
英英声音有点儿大,地铁车厢里,附近的人民群众都往这边儿看。两个人都不吱声了。一路无话。
" f6 |! m( o; x7 k- ]( e  g, Q- a1 P! G
  W! Z* W1 ]' D! G/ G7 e/ _
到了舞蹈教室,更衣换鞋,音乐响起,晓川觉得英英好像换了个人。不是刚才声色俱厉的那个了,一下子变得沉静典雅。今天新学的动作叫月亮步。女生在男生的引带下,用足尖画出一道弯弯的弧线,就像画一个弯弯的月亮。
  |/ N1 W' I0 k# K9 _: k' ]
夜里,晓川做了一个梦,梦见山间谷地,小溪潺潺,虫儿间或振翅鸣响。月亮就在当空照着,照着地上的景物,也照亮了月亮周围像棉花糖一样的云朵。没有音乐,也不说话,晓川和英英在草地上跳舞。+ j3 v7 h9 \9 k" D/ Z$ M# k

7 O; ]9 [% U; X% i- t: ~7 R
醒来,晓川心想,怎么会做这样的梦呢?嗯,那些自然景色,是大学时背着大背包装着帐篷睡袋跋山涉水野营时见到的。多年来,每每回忆起来,都觉得特别美好。而现在,英英加入到这个情景中,大概是因为英英在我心中也是特别美好的吧。
+ }& ]0 V) \' S* h+ m% |; _: N- i
 楼主| 发表于 2013-9-13 09:02:15 | 显示全部楼层
21.同时解决两个问题
! Z' q. x& M% O6 N
8 }- e; S# F0 C2 h
第二天,英英来找晓川。“我能再听你详细讲一讲,由程序员直接提交的好处吗?”

9 i) B6 g2 X7 x& {晓川:“从项目的角度看,现在由于我在流程里,那么当我忙其他事情的时候,比如开会之类,流程就要等我。并且,在随后的版本合并工作中,我并不能解决任何问题,或者增加任何价值,出现冲突只能找相应的程序员来解。那何必不由相应的程序员直接操作呢。”2 ^" P/ y0 G" W0 b; I2 x/ ^8 A

6 u" ?2 p5 ?( i6 e9 k/ n
英英:“所以,如果由程序员直接提交,你觉得会更有效率?”

4 A* Y" |; M4 ~7 u( c4 P6 D晓川:“就是这个意思。”. b# ~' p- v7 N' {: e8 {
3 `* `0 S- s2 n# I- A: ?3 i. g
英英:“而你也理解我的担心,我担心程序员可能会忘了用昀新基线更新任务分支,以及随后的编译构建这两个任务?”
  G) g3 E% [+ [/ N% O
晓川:“嗯,是的。”% q) D# E9 M& Z% Y6 ^
! u( B' E5 ~5 X; X' n/ l
英英:“你还要准备好,可能程序员那边要反对,因为他们会担心这增加了他们的工作量。过去只是发封信,现在要自己操作了。”
# q! |0 p2 J# Z# {" H) V6 d! Q
晓川:“没错,是这样。我也又想了想,或许写个脚本就能同时解决这两个问题。”
5 p3 Y8 M/ t1 L( [3 n) {8 i& V1 _& b1 P! c1 i
两天后,晓川写好了这个脚本。脚本是供程序员提交的时候用的。为解决前面说的第一个问题,脚本在开始时,会与程序员交互,询问程序员,待会儿是否需要自动执行更新任务分支这个步骤,以及随后做构建这个步骤。如果程序员已经手动更新过任务分支,并且手动启动过构建,那就告诉脚本,不需要。而如果程序员还没有做这两个步骤,就告诉脚本,一会儿要自动执行这两个步骤。在完成与程序员的交互后,脚本开始运行,一步一步地执行。在执行完或者没执行上述两个可选步骤后,脚本自动执行从任务分支合并到集成分支的一系列细节步骤,昀终完成。在刚才脚本自动执行的整个过程中,一旦遇到困难需要人干预,脚本就停下来,弹出对话框,通知程序员处理。当然,如果没有任何困难,顺利完成,脚本也会在完成后弹出对话框。

% D1 |: o( \/ o3 `晓川对自己的编程水平不是很有信心。所以在完成后反复检查,并自己进行各种情况的模拟测试。确实有一两个小问题。倒是好改。此后,晓川又找了两三个相熟的程序员,让他们提交的时候试试这个脚本,晓川就在旁边盯着。晓川根据程序员的反馈,修改了提示的文字,让它更符合程序员的说话习惯。随后,晓川又找到了一个研发小组的领导,让他们组全体都试用。这回没什么问题了,而且大家的反馈很好。昀后,整个项目的程序员们,都开始使用晓川的脚本做提交。3 ]% X+ _" Z; N) s
) W$ J) j5 g. p1 q  L! i
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-13 09:05:23 | 显示全部楼层
22.失败的改进
+ D, e' A2 _. \. T# `: y3 ]2 x
3 q5 d' _) }( q+ B/ l
在晓川使用的持续集成工具里,在做设置的时候,一直有一个空没有填,那就是关于自动测试的设置。晓川当初研究过,大体上,只要自动测试工具可以用一行命令启动一套自动测试工具集,那就能嵌入到持续集成工具里,在编译构建之后调用。至于具体用什么自动测试工具,怎么测试,晓川还没有深入研究。
" Y9 i$ C9 a- n) B' n: M" F9 V9 N/ H
现在,集成已经基本上自动化了,只是集成构建出问题的时候协调协调,所以晓川不太忙了。不太忙了,就开始琢磨有没有什么可以继续改进的地方。而在构建之后自动测试,或许是个值得做的改进。这个事情跟质量之类的关系挺大,先找英英问问吧。& {2 B) o0 u; K
  m6 s& X& e6 y* U! Z6 @2 `, I
晓川来到英英的工位,在她的笔记本电脑上打开持续集成工具的设置页面,跟她说可以添上自动测试。没成想,不光是英英挺关心,质量保证部的其他好几位同事也都围过来,一群女人喳喳喳喳问个不停。
7 H9 f; I7 ?; u% }( W# k8 J2 J5 Y
晓川问她们,怎么这么感兴趣啊。她们说,其实她们部门时不时的收到来自程序员和测试团队的抱怨,抱怨说基线的质量太差,经常刚启动就死机。严重干扰后续开发,也让测试团队很无奈。其实QA部门以前内部也讨论过,要不要在集成的过程中,不仅要保证编译构建通过,还要通过若干测试,才能出基线。但是在以前,光是构建,还要加班加点,几天出不来基线呢,要是再加上测试,更成了研发的瓶颈了。所以一直就没有推进这件事。
' |4 N0 a3 r0 U( g+ [4 P& O- F. }2 x+ R
英英的老大也在一边看,没怎么说话。昀后她说,这件事情很好,要推进。自动测试在技术上具体怎么弄,应该是测试部门负责。她回头会跟测试部门的老大打个招呼。
5 G! f" l7 N  `' t, h& X
这之后,测试部门有同事来向晓川和英英了解情况。后来成立了一个攻关小组,包括测试部门的两名同事,当然也包括晓川和英英。初步的研究表明,自动测试是很有希望的,只是需要一些时间进一步研究,先研究一两个月看看吧。
0 L0 a) i0 d& D" {2 F8 }5 x! ~2 Q$ t# _. l
有测试部门的同事在,晓川不用深入研究自动测试的细节。所以其实在攻关小组里,也没有什么实际事情做。这不就又闲下来了。晓川是个闲不住的人。他在网上东搜搜西看看,偶然间看到,有一种叫静态程序分析的自动检测技术,并不是在程序运行的时候测试,而是通过分析程序的源代码,来发现(潜在的)错误。这种技术,有现成的软件支持,而且是免费的!
$ u" P( Q' j& s2 G1 Y
晓川跟攻关小组的成员们商量,把攻关小组的目标扩大一些,不仅是自动测试,也包括静态程序分析,总之是自动检测技术。晓川自己现在比较清闲,那就先多看看静态程序分析这方面的内容。大家都没什么意见。晓川就写了封信给各位相关领导,算是知会。7 _5 H# V3 C6 R" c4 l

5 J1 i; Y+ N" X" o/ D6 X8 g  J
晓川研究静态程序分析工具,倒是挺顺利。没几天的功夫,就调通了。就是跑一遍有点慢,比编译构建慢多了,要六七个小时。因为这个静态程序分析工具,要分析就得分析全部源代码,不能只分析指定的模块或指定的改动。不过,虽说慢点儿,这工具可真管用,跑一遍,显示出几千个问题。晓川拿着工具的分析报告去找相熟的资深程序员看。程序员说,这些分析很有价值。这些发现,大都意味着程序写得不够规范,不够优雅。尽管不一定会表现为程序运行时的问题,但确实是应该可以写得更好的。
( @+ b# _( O" C& ]! }: k
晓川拿着分析报告,叫上攻关小组,又叫上老刘,一起开会。晓川提议停下项目当前所有的事情,先集中精力处理静态程序分析工具发现的所有问题。老刘听了,皱了皱眉。老刘提出建议,对于已经存在的历史遗留问题,订个计划,用两个月的时间处理掉。这期间,项目还继续进行。对于新产生的问题,发现一个,纠正一个。英英说,这样比较可行。晓川本来想说不同意,觉得这事儿不能拖。但是看英英表态了,也就不说什么了,同意了这个方案。1 Q+ ]6 S8 P- ^3 W+ d7 Q9 b: O4 i- ?

; T% j" }% S. \% Y( j$ o' V
在接下来的项目例会上,大家对在集成过程中加上这么一步,多有疑虑。大家觉得,好不容易提高了的集成频率,这回怕是要降下来了。但晓川很坚持。讨论的结果是,那就试一试吧。
4 w9 h: ^! B& h4 x+ B; p
星期三一早,晓川把静态程序分析这个步骤加到集成中去,马上就遇到了麻烦。在运行了六七个小时后,工具报告说,跟上次运行相比,新发现了15个待处理条目。晓川马上联系相关程序员们研究并修改。相关程序员们提交了修改后,再次运行静态程序分析,15个待处理条目,解决了 12个,有 3个仍然存在。这还不是大问题,大问题是,由于在上次运行该工具期间,程序员又有新的提交,所以,这次又新发现10个待处理条目……就这样,一直到周五下班,还是没出来基线。晓川急了,加班,连带上相关的程序员一起加班。终于,周日的下午,基线出来了。+ G9 l1 i) i" f+ ~+ Y

! ~; u: ^. L, s
周一早晨,项目经理老刘打电话给晓川、英英和他们的老大,召开紧急会议。会议室都提前预定满了,没有空会议室了,几个人就在茶水间开会。老刘让晓川简述了上周试运行的情况。随后,老刘提出,立刻停止这项试验。

( t7 A% a9 w4 I3 ^1 Z; f晓川马上反对:“改进总会有困难,有困难就要克服。这件事情的关键是,程序员在提交之前没有做静态程序分析。我们应当马上要求程序员也做静态程序分析!”
0 L" w3 @1 I, _$ c0 v8 }  V7 v( l; V; Q9 Q$ F( d! [
老刘:“你让程序员在提交前也运行你那个静态程序分析工具?程序员的计算机可远不及你那台构建服务器,你还得转个六七个小时,他们不得转一天?要是报错了,再转一天?提交前更新任务分支,然后再转一天?你知不知道这要耽误项目多少时间?”

) a" o0 ?6 W4 f2 y“耽误多少时间也值!我们必须提高程序质量!”晓川不由自主提高了音量,加快了语速。晓川心想,QA她们肯定会支持我。! j8 f( Y# Z$ d5 L
- E, |0 h% ?2 e# r& _
“老刘,英英,这个静态程序分析,对质量有多大的帮助?”英英的老大不紧不慢地问。

5 C( t7 X4 {$ M. Q英英的声音有点小:“静态程序分析确实能发现一些潜在的问题……”1 ~4 A* h8 g0 A# r( k
6 z/ [: R5 |# X- W& V
老刘接过话:“有什么用,我给你们看看有什么用。”老刘说着,在笔记本上运行昀新基线对应的程序。程序的一个主要功能,刚运行,程序就死机了。“你们看看,我等了五天,就等出这个东西来。晓川,你说你那个东西有用吗?”
4 |9 b! q; ?; s3 ?  |5 F  U
晓川:“这个,大概是以前发现的问题导致的。我早就说过,要把所有的问题都解决了,项目再继续。是你偏不听。”
9 l9 T5 T6 X( q0 Z) |
老刘:“以前发现的问题导致的?那上一版怎么这个功能好好的?你这是狡辩!”老刘声音也越来越大。( n( F/ w7 t) S

1 X6 p. c+ ?0 C, a+ r6 A
“咱们谈工作,大家都心平气和的。”晓川的老大说,“晓川,要不这样吧,我们先停一下吧,恢复原先的集成步骤。之后我们再慢慢讨论怎么弄。大家看怎么样?”

/ A+ Z# l2 h6 o7 `众人纷纷点头同意。晓川急了,“老大,不能这样啊。改革遇到的困难,只有通过深化改革来解决!”晓川忘了在哪儿听过这句话了,随手就拿来用。
5 }7 Q* B% {' T: t6 I8 C/ D+ o$ V" X+ G
晓川的老大听了,沉着脸,一字一字的跟晓川说:“晓川,现在我以你的行政主管的身份要求你,执行管理层的决定,立刻恢复原先的集成步骤。”

) Z% P  z% I* r! {  E众人无话。晓川的脸憋得通红。散会。
5 U8 y$ q, d1 i7 A) [2 w% W9 z
' C: p8 V7 U. d# `* c
中午的时候,食堂,晓川和英英坐一起。晓川闷头吃饭,不说话。英英主动说起来:“晓川,这之前我们的各项改进工作,实在是太顺利太成功了。你知道,要是太顺利了,人就容易骄傲。”

) ?6 Z; i: K* W% m: @英英的话点醒了晓川。反省一下自己,可不是么,有点得意忘形了。岂止是得意忘形,还有点儿独断专行……; }' ~4 y/ R5 T) y# W6 Q
9 X4 Q. x3 F0 V9 n3 i
后来,晓川主动去找老大,检讨自己态度上的问题。老大听了,说他认识到自己的问题,这很好。接着,又说了不少勉励他的话。而关于静态程序分析这个事儿,老大说,不是要一棒子打死。建议他想一想,是不是流程里有更合适的时机来运行静态程序分析。

5 b/ }% U3 k0 i5 D" L6 n) \晓川昀后跟大家讨论的结果是,在基线出来之后再运行静态程序分析。大致上每天晚上运行一次,正好那时候构建服务器不忙。而对于工具发现的条目,相关的程序员需要在一周内处理完毕。当然,历史遗留的几千个条目,要分期分批的处理。由质量保证部来做相关的协调监督工作。; @7 i- K. M4 ^* a5 |) n& q' g
这回执行得很顺利。
" o+ t5 A, n- h6 l# C
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-13 09:09:46 | 显示全部楼层
23.自动冒烟测试
7 ^: z2 P: T, b+ \+ g' x( j
4 a5 i  ?, s# U& j! s3 k* N/ l& e% o
晓川时不时地思考引入静态程序分析时发生的故事。今后当然要戒骄戒躁,除此之外,还有什么学到的呢?嗯,对集成工作本身,有了更多认识。集成,目的是为后续的开发和测试提供一个有一定质量的基础。所以,集成的过程,就是排除问题,提高质量的过程。但是,集成不能一味地贪图质量,特别是一些细枝末节的事。因为集成容易成为卡脖子的事情。集成的效率特别重要。也就是说,要在较短的时间里,发现那些真正严重阻碍后续开发,严重阻碍后续测试的事情。
8 r0 z; ^' p# u
显然,当初在集成中仅进行编译构建,就基本遵循了这个原则。如果编译构建都不通过,那么接下来啥都别玩儿了。而后来,我主张加上耗时几个小时的静态程序分析,就破坏了这个原则:花了很多时间,却没抓住重点,抓住那些真正会严重干扰后续开发和测试的问题。

; Q- [( C7 S% ]/ h3 b那么,在集成的过程中,在排除了编译构建的错误之后,如何能够继续抓重点,抓那些破坏力大的问题呢?看来还是要靠测试啊。) T' K" ~' _6 w, |) o" G0 @& [6 T

# H: o9 W. W+ l& \
攻关小组在讨论集成中将要添加的自动测试的测试用例集。测试部门的同事拿来了他们平常做人工测试时使用的数千个的测试用例,供大家讨论挑选。晓川现身说法,提醒大家不要再犯自己曾经犯的错误,在集成时加入太多检测内容。昀后打趣道,要是咱们把这些测试用例都用上,怕是又要麻烦刘经理开紧急会议了。大家也觉得太多了。但是留哪些呢?留多少呢?还有没有没包括进来的呢?

: }7 x; i# J7 u晓川试探着说,既然我们的目标是防范低质量基线对后续工作的严重干扰,那可以先考虑一下,哪些问题是昀严重的,是要防范的。然后再看从什么样的测试用例,能够把这些问题发现出来。
9 I# b4 I/ ^* `( |
- T5 M/ n: a) _
大家都同意。晓川接着说:“咱们这个小组里面,我对测试昀不懂。那我就说个昀简单的吧,程序无法启动。这个也是昀严重的问题,因为它让后续所有工作都无法开展。”

6 X/ o5 F! S7 d/ n0 ?; X* n英英说:“那么次严重的问题,就是程序的某个主要功能无法启动喽。”
! P6 ~7 b% y0 D6 G6 r( W6 E+ ?; [0 P0 @6 z  Z/ h; I1 e- X
顺着这个思路,大家开始热烈讨论。昀后整理出了一个列表,而且标上了严重等级。来自测试部门的同事看了看,说,这些如果要手工测试的话,大概需要两个小时。但是自动测试的话,半个小时的时间大概就够啦。晓川担心时间还是有点儿太长了,问大家能不能先转个五分钟十分钟的看看。于是大家讨论后,在列表上划了一道线,上面相对而言严重的,这回就测。下面相对而言不那么严重的,等以后考虑添加。

+ M+ V/ R( ~5 t眼看就要散会了,英英忽然让大家等等。她犹豫了一下,还是决定说出来:“从风险管理的角度看,一件事情有多大的风险,要看它发生了之后有多大危害,还要看它发生的可能性有多大。如果用类似的思路,那么会不会存在这样一种情况,两个问题,问题A比问题 B严重,照我们的排法,测 A不测 B。但是实际情况是,问题 B远比问题 A容易发生,所以按理说,应该测 B不测 A?”% `; u- i" g* d
* V% o2 y0 g  m0 s5 T
晓川对英英有了新的认识,心想,以前小看这小女娃娃了啊。嗯,其实是自己的知识面不够广啊。风险管理是QA们的必修课,所以英英才这么敏感。而我其实也应该学习的。看来以后还是要加强学习啊,不能局限在自己的小圈子里。至少是为了能跟英英这样的QA顺畅交流。

3 d8 N8 ~; i# V+ B晓川沉思的时候,其他的同事已经在热烈讨论。昀后讨论的结果是,这个想法很好,在道理上是这样的。但是为此需要统计每个问题发生的频率,这需要历史数据,而现在又没有。只能从现在开始积累,供日后使用。哦,该如何记录这些数据呢,这又是个麻烦事儿。所以,暂且先只按照问题严重程度这一个方面来选择测试用例集吧。关于问题出现频率,待以后慢慢研究,再据此调整测试用例集。9 \0 B: G4 G. J3 V8 f! O) d- p
( q/ L2 z4 Q! @2 S, _
在实现自动测试的过程中,攻关小组遇到了一点儿小困难。由于技术上的原因,他们确定的测试用例集中,有几个测试没办法实现自动化。倒不是说软件不能被自动运行,而是自动测试软件无法侦测出,运行的过程和结果是否正确。看来一时半会儿的,这几个测试用例没法自动化了。

, y/ k$ M: `, A% Z0 D! L' o+ ]$ B这个不好的消息,像一块儿石头一样堵在攻关小组成员的胸口,而且看起来要堵上很长一段时间。如何挪开这块石头呢?! d$ n, |2 e9 J, [  [, [
' y3 n: O' j  e" O4 \, S. E
晓川提议:“这样吧,我来。舍得一身剐,也要把测试拉上马。那几个没法自动化的测试,由我来代替。每轮集成,做自动测试的时候,我就做人工测试,自动测试完了,我也测试完了,再出基线。我估计我比自动测试快,因为我没多少东西要测。”

$ p$ Q# T; k% Y: I/ q) q“哎呦,你行嘛你,让你成天干这简单劳动。 ”英英说。晓川心想,英英还挺了解我的,戳中了。1 a4 d3 L5 _) {7 U. u& a
9 ^2 D. [( |9 @  v
英英接着说:“再说了,你也不是整天都在工位上,也不是随时都有时间,说不定这集成会时不时卡在你这儿。”
大家又仔细分析了一下这几个不能自动化的测试用例。其实也都不是特别重要的测试用例。“要么这样吧,出基线就别等这几个测试用例了。”英英提议,“不过还是要勤测着点儿,出了问题赶快找补。 ”

9 O8 ]3 X  M! ?8 E' E. Y; [. J3 H. ]看大家都不反对,英英跟测试部的同事说,“我们一会儿去你们部门找个人,每天一上班先用当时的昀新基线把这几个测试用例测一下吧。然后有问题马上跟一下。”
; p5 x& y8 Q1 e+ y2 Q; W4 n9 n% M3 M& u2 o
自动测试成功加入到集成过程中的一周后,英英来问晓川,打算什么时候把剩下20分钟的自动测试用例加进去。晓川回答说,可以,但是程序员提交前也必须运行这些自动测试用例,否则的话,根据他的估测,集成恐怕会经常出问题了,而且是修复了上次测试的,新提交中就又带进来问题了。这样的话,基线就可能迟迟出不来。那次贸然加入静态程序分析的教训,给晓川的印象太深刻了。晓川总免不了有这样的担心。

, {7 H! K1 T: i' }5 a9 W& X7 E" o6 v而英英则担心老刘不同意,程序员们不同意。因为这会推迟他们提交的时间。晓川见英英吃不准,就建议说,不如先找几个程序员私下聊聊,了解情况。
9 q$ v' k! w2 ?" E4 J
. U9 l3 K( R; V; u" s1 r% v/ y
他俩去找程序员聊天儿。程序员倒是没那么不情愿。英英猜测,大概是因为他们常受基线质量不高之苦。英英问程序员是不是这个原因,程序员没有否认,但是他们更强调的是,反正是自动运行的测试,让它跑着呗,反正也没多久。再说这期间,可以去干点儿别的,两不耽误。晓川暗想,看来程序员也跟我一样,讨厌简单重复的工作。

; h4 m+ \* u0 x9 T: I. b8 A! _他们再去找老刘和其他几位领导。老刘说这个不错,可以接受,但是能不能更好一点:“让程序员有选择性,能够根据自己的改动,挑选测试用例。毕竟对于特定的一个改动,整个测试集中,会有很多测试用例,毫无相关性,几乎没有可能因而出错。”/ {4 Q- [6 G( j0 O, }$ V

3 r6 p& Z/ a( W2 R+ {  |# b
英英担心道:“这个在理。但是另一方面,一个测试用例、一个测试用例地做选择,这本身也要耗费时间。自动测试是比较快的。说不定这样做选择的时候,都能测出来了。”
/ F, W2 o# w! O* P! P7 V' F
晓川说:“我们回去再想一想吧。”
4 h: c; H! s/ X1 I
7 r- v4 e" d5 h' m4 |
晓川想出来的方法是,把测试用例按照大的功能分成若干组,这样程序员如果觉得按默认全部用例都测试确实没有必要,就可以挑选只和本次改动相关的组。当然,有一组是昀昀基本的测试用例,无论如何都会被自动选上。
8 R  w; G0 E  s0 Q9 K
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-13 09:13:03 | 显示全部楼层
24.不可靠的自动测试
* x- L0 J' L4 K' L6 K$ \

. a, [" P2 F7 J$ q6 h
已经是第 N次了。自动测试程序又一次误报了测试结果。自动测试程序说,这一次有 8个测试用例没有通过。这可吓了晓川一跳,一个就已经少见了,这回一来就来 8个。赶紧手动启动程序,复现相关的测试。没有问题呀。难道是测试程序有问题?这两天,赶巧测试部门那两名懂自动测试的同事还都不在,因为他们所在的测试小组,组织大家出去玩儿了,每年一次的公费旅游。

/ k+ O7 J! ^( \+ h: Z- o9 f晓川回想起以前有一次测试误报的情形。是因为程序界面改了,而相应的测试用例脚本没有改。晓川猜测,这回估计也是这么回事儿。所以晓川调出上一个基线对应的程序,跟这一版的程序对照着运行。嗨,可不是吗,因为换了个图标的图片,很多界面的布局都有了少许变化。而晓川他们用的自动测试程序,是根据程序界面表现出来的样子来判断运行正确与否的。因此改了个小小的图标,就导致一堆误报。
. w  U' o1 }- b6 o; l( j/ d; s. S* y
晓川处理完这个紧急情况,忽然想起来,他应当不是第一个遇到这个问题的人啊。应该是相关的程序员先遇到啊。估计是他们没按规定运行自动测试集,或者误以为无需运行那几个主要功能对应的自动测试用例。这可不应该。反正我也不太忙,我来追一下吧。

& ~+ R+ _4 X9 O: y' D晓川追查到提交图标修改的程序员。接着,询问他是否运行了那些自动测试用例。出乎晓川意料,程序员说,运行了那些自动测试用例,并且发现了问题,还因此咨询了负责自动测试的那两名同事,并且改了自动测试用例脚本。现在应该能运行通过了。
& _& m7 E1 a, a# D6 W$ X3 C- j
1 F3 ?5 E+ N0 t2 v. P' u, F: O& r
晓川将信将疑。程序员就给他演示了一下。确实没问题了,能通过。晓川又回到自己的工位,在构建服务器上重新试验,这回没通过。晓川打电话给那两位测试同事,一个没人接,一个好像在瀑布附近,水声很大,需要喊。喊了一通,晓川得知,测试同事是不敢更新放在共享文件夹里的自动测试用例脚本,只在那名程序员的本地修改了相应的测试脚本。
! B4 @( T6 l, j( K. n5 c
为什么会这样呢?因为如果测试同事当时就更新共享文件夹里的测试脚本,那么几乎所有的人都会立刻取得新的测试脚本。而当时,除去那名程序员外,几乎所有的人自己编译构建出来的程序里,都还用的是老图标。当老图标遇到新的脚本,那就跟新图标遇上老的脚本一样,还是不匹配。所以测试同事想着,等快要集成的时候告诉晓川。这不,一忙给忘了。6 U1 K7 C! d  V7 {; m  A
. G1 U0 v. d- i0 }8 d
真相大白。但是晓川并不满足,总觉得这事儿什么地方有点儿拧巴。

* n/ C0 S. B$ x, l, a" e; a晚上去学跳舞,晓川和英英一起乘地铁。地铁里,现在添了个新科技,隧道的墙上,嵌上了长长的屏幕。车开过来的时候,就在墙上放映点儿广告。通过一些同步追踪技术,广告移动的速度,与列车行驶的速度几乎相同,以方便乘客观看。当然了,这种同步追踪技术做得还不是很好,画面总是在前前后后晃呀晃,晃呀晃。晓川觉得,就像是在山野中行进时,小昆虫们追着人,在眼前在耳边晃呀晃,晃呀晃……4 ^0 o: M9 o& `% a+ Y5 h  |
7 O& A' d+ N& B0 F: N
“唉,你说为什么不能从车厢上投影到隧道墙上呢?那多稳定啊。已经和列车绑定在一起了,就不用再不停地跟踪。就不会再前前后后晃呀晃,晃呀晃。”晓川随口跟英英说。
0 a7 N2 B* n& w' d6 \0 D
“有道理哈。”其实英英关心的重点是广告的内容。
1 T* M- V) ]4 J: x6 u1 f4 `" t
/ J3 R* D; U1 `. _$ D! g( x
“我明白了,自动测试脚本应该绑定到车厢上!”晓川说。
( K$ d: I; B: l; p' k$ o( B
“你说什么?!”英英一头雾水。
; y2 t) s# \+ z" D0 y' R
7 ^3 r; u3 ~9 w9 W2 q
“你看,可以把投影设备绑定到车厢上,让它随车厢的运动而运动,这样就不用特费劲儿地不停地跟踪不停地校正还费力不讨好。对吧?同样的道理,把对自动测试的修改,与对程序本身的修改,牢牢地绑定在一起。我是说,让程序员同时提交这两部分修改。这样,这两部分修改将总是同时流转,同时进基线。我的意思是,要把自动测试脚本也放到版本控制工具的版本库里,跟源代码放到一起。”
* [! G9 m1 R# d: S0 R5 o1 t/ U
英英愣了半天,昀后终于听明白了。“你这个工作狂!”英英说,“真不知道你跟我跳舞的时候是不是也在想工作上的事儿!”$ q8 E2 l9 D& S* O) m0 P- D' O- K
( D2 K" _* T3 i6 a# N$ k
晓川做无辜状:“不会,那是肯定不会的!”

1 k  B6 s5 p+ V' x) t事实上,在接下去的两个星期里,晓川不仅把自动测试脚本放到了车厢上,还把编译构建脚本放到了车厢上。这倒不是说,编译程序、链接程序等工具都已经放到了版本库里,而是将调用它们的脚本,放到了版本库里。在脚本运行的时候,会去检查各个构建工具的版本,只有各工具符合要求,才会构建,否则报错。这样的方法,虽然不够完美,但是已经能尽早发现工具与环境的问题啦。
# f, H- |+ ]; z7 `( h: r
  v7 [$ {' I% I4 I; R) t
一些在尝试自动单元测试甚至 TDD(测试驱动开发)的研发小组,看到晓川这么做,就来询问,是不是可以把自动单元测试的测试脚本也放在版本库里。“为什么不呢?”晓川反问。

% }: i3 ]- \# F9 K* s" J: D
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

SCMLife推荐上一条 /5 下一条

QQ|小黑屋|手机版|无图版|SCMLife.com ( 京ICP备06056490号-1 )

GMT+8, 2020-2-28 12:03 , Processed in 0.075499 second(s), 8 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

快速回复 返回顶部 返回列表