SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 3354|回复: 2

[赏析] 4.8 狭义集成时发现问题以后

[复制链接]
发表于 2013-10-9 12:27:30 | 显示全部楼层 |阅读模式
4.8 狭义集成时发现问题以后
3 h9 ~! h7 K& T- p2 S1 `6 }- z6 E
以上是发现问题的方法。一旦发现问题,该如何解决昀有效?如果是一眼就能看明白,三下五除二就能改好的问题,那就立刻改了吧。如果问题有点棘手,需要程序员仔细研究,那么通常应该先把相关的提交从集成分支中剔出去。具体来说,用回退合并的方法①。如图 4-6所示。
* e$ t; X  x6 K3 v" V  ^; \7 |
当然,剔出去意味着,不仅把问题剔出去了,也把提交的改动剔出去了。这是个副作用,需要根据具体案例权衡。

" E/ }! T# y4 c. ^无论是集成工程师修改补救,还是要求程序员修改补救,又或是把有问题的提交剔出去,从源代码版本控制角度看,都是增加一个新的提交。与此同时,集成分支上还可能出现了程序员们正常的提交。它们可能混杂在一起。如何处理?
/ ]% B7 {, A- _6 h$ Z. F# i# r
; J, ~, Y3 U& k/ s- `
有多种方法。典型的有:
方法一,在集成工程师开始狭义集成之时,先把集成分支锁上,除非允许,禁止提交。如果集成过程中发现了问题,就由集成工程师或者特定的程序员在取得权限后,把修补提交到集成分支的末端。狭义集成完成,基线产生后,再解锁,允许程序员们正常地提交。

& [" z( t) q) V1 r1 m$ B方法二,在集成工程师开始狭义集成之时,把集成分支锁上。如果集成过程中有程序员要做提交,就开辟临时分支,让程序员提交到那里。将来集成完成后,再把该分支上的内容合并回集成分支,并解锁集成分支。
1 T" o2 a: s4 |) U8 X8 g  Z5 U+ _; J6 c+ _" A: B
方法三,集成工程师始终不锁集成分支。当集成遇到问题时,如果集成分支上已经有新的正常提交,就为本次集成拉出临时分支,把为本次集成所做的修补工作提交到那里,并在那条分支上出基线。此后,再把基线合并回集成分支。
" y8 y6 h& o) U1 W! z$ M! L
方法四,集成工程师始终不锁集成分支。当集成遇到问题时,即便集成分支上已经有新的正常提交,也把为本次集成所做的修补工作提交到那里。也就是说,集成工程师再次编译构建时,不仅包括了为本次集成所做的修补工作,也包括了新的正常提交。当集成成功后,在集成分支上出基线。
/ H6 C! {# v' R7 b$ b# |# R1 t0 @2 \; L/ |1 D3 Z
方法五,集成工程师开始狭义集成之时,不锁集成分支。但是一旦集成出现了问题,就把集成分支锁上,阻止不可控的更多的提交。至于在本轮集成开始之后、发现问题之前新提交的改动,就接受了吧。把集成分支锁上后,集成工程师把权限开放给自己,以便剔除有问题的提交,或者把权限开放给修复问题的程序员,通常就是有问题的提交对应的程序员,让他提交为修复问题所做的改动。这之后,再次执行集成的一系列操作,如果成功了,就解锁。

: s5 x# d! T1 J3 R3 |* n. ?  O方法一是昀保守的方法。它的主要弱点是导致程序员提交的停滞。不同的改动无法尽早合并到一起。作为使用者的程序员无法从版本库中得到作为贡献者的其他程序员刚刚完成的改动,因为现在没法提交。而作为贡献者的程序员,需要留意版本库中锁的情况,并且将来可能要停下正在进行的工作,补上前面被阻滞的提交工作,这将打扰正在进行的工作。
4 K& ^9 a, @  r% G! T  o; ^# U& J
" C7 K, {: n" G. n  f% O! _: [. {+ T
方法二和方法三本质上是一种方法,即,让程序员的正常提交与集成工程师的本次狭义集成工作这两条线索并行,互不干扰。等基线产生后再合并。这种方法还有其他表现形式,比如两条长期并行的分支,互相配合工作。在此不做详细介绍①。这在原理上是昀好的一类方法。但在具体的源代码版本控制工具中,需要考察其实现是否复杂,是否明显增加了集成工程师或程序员们的操作步骤,是否容易出错,是否容易自动化。

+ V4 y; T8 _- J  f* {
方法四引入了一些风险,但是其实现是昀简单的。
7 b$ b' M$ q* V  ?
方法五与方法四相比,能使风险可控:当察觉到问题时,问题的数量不会无限增加,就那么多,能在较短的时间解决完。当然,代价是,当出现问题时,会像方法一那样导致程序员提交的停滞。好在,仅在出现问题时,会出现这种情况。
4 n; n7 [) |- Y: ]  S+ N' ^, N# p
5 E( Z/ t+ b- Y! g. b# B8 ^' Z4 d如果在实践中,方法四或五已经运行得不错,不常出现集成反复被不断出现的新的提交中的严重缺陷所打断这种情况,那么采用方法四或五就挺好。如果不是这样,可考虑方法二和三所代表的模式,但前提是,在具体环境中它不会引入太多操作的复杂性。通常不采用方法一,因为它形成了阻塞,没有尽可能并行工作。但如果在具体项目环境中,方法二和三很麻烦,方法四或五又应付不过来,那就要考虑方法一了。
. O, E- e. _* c3 B
; O( C: r1 A" H- T
①第6.2节将讲解回退合并。注意不是每种版本控制工具都对回退合并支持得很好。另外,即便是改动已经进入了基线,也有可能使用回退合并的方法剔除。

" e- ^1 B$ r& C4 ~7 M% b①在附录中介绍的《未雨绸缪——理解软件配置管理》一书中,有专门的一节介绍双分支结构。
! _1 v* v; `0 M

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
 楼主| 发表于 2013-10-9 12:29:52 | 显示全部楼层
4.9 狭义集成后检测类型和力度
1 c* N! j2 M, @, P6 q! S: x: P
总的来说,集成的第三阶段,要对系统进行全面深入的检测,并修复发现的问题。

1 f0 B$ ?% [: x) I与前两个阶段相比,一般来说,这一阶段里各项工作的时间压力相对要小,但作为最后的把关,要尽力消除程序中的问题,使之至少达到用户能够接受的质量。要让将来发布的软件中,存在的问题少,严重程度轻微。
9 o% L1 m$ ^' a$ e# Z9 j4 A
5 |5 I5 u% l0 W& ]
所有存在的问题,包括发现了但(还)没有修复的问题,和根本就(还)没有发现的问题。为此,我们首先要保证检测的覆盖面,让检测未能发现的问题的数量足够的低,且基本都是轻微的缺陷。这就决定了第三阶段检测的力度:全面并且细致。

2 d: j( S6 I  `- f/ @* d第三阶段的检测,不止这一类全面的测试。下面介绍第二类,根据改动所做的增量的测试。我们知道,每个基线新携带的缺陷分布在什么地方,与本次基线包含了哪些功能的改动密切相关。改动程序的不同地方,会让缺陷在程序中的密度分布不同。因此,与全面的测试相比,考察上次测试以来新发生的若干改动,来确定本轮测试的覆盖范围,能够让检测工作更有效率。根据新近完成的改动而确定检测覆盖范围,这一点类似于程序员提交前的检测工作,但这回是由更专业的人员,即测试人员,来进行复查。& P5 d3 z8 S  T. L% R- G# T, m1 {! h* j
: Y" ^, ]7 s! ~& s
为什么测试人员常常是在此时复查,而在提交前复查则不太常见呢?其实在提交前复查也不错,沟通容易,反馈快。而在第三阶段来做,常常是因为下面一些原因:
) P7 ?7 [/ I  |4 S2 v$ ?! x& I" i. H& F
首先,把涉及同一模块、同一组件、同一子系统的改动适当攒一攒,放在一起测试,能够提高测试工作的效率。
9 M3 \5 s( Y+ @" S- _( C- `% M* P* c: F- t! n. u
其次,与程序员检测每次提交的内容相比,测试人员做检测,会更关注一个功能的外在表现。这是测试人员擅长的事情。也就是说,只有当一个或几个程序员的一个或一系列改动,在一起产生了程序运行时所能表现出来的变化时,测试人员才会为此做测试,验证该功能的完成情况。测试人员有针对性地验证每个新增功能的完成情况,有针对性地验证每个缺陷修复的完成情况,并有针对性地探测为完成新增功能或完成缺陷修复,可能给相关功能引入的缺陷。

' _9 M& N' Z- |$ _6 I* D: B$ |7 d2 V此外,如果提交前的检测工作过于细致,而这个改动又在关键路径上或者比较容易跑到关键路径上,那么在提交前耗费较长时间的话,对项目时长的影响就比较大。而在第三阶段检测和修复,是可以与开发新功能并行完成的。
0 y( W( J% Q& `8 Y) Y2 u+ ^" Q7 x: k4 E
最后,根据基线来测,便于测试团队的管理者安排测试任务,掌握测试进度,督导测试工作。总之,管理者认为这样更便于利用测试资源,更便于管理。
( u$ q& U3 T& r- s
以上是第一类,全面细致的检测,和第二类,增量检测。它们都是主要以提高将来发布的质量为目标的。下面将第三类检测则是针对那些对软件开发过程产生干扰的问题。- @- K; h" d& B; A* K, N

8 e" o" N5 Q7 s" M9 G! j/ |
我们知道,第二阶段的集成工作,就是要尽力排除这类问题。然而,大家都在等着第二阶段的集成结果,第二阶段时间压力比较大,因此难以排除所有影响软件开发过程的比较严重的问题,只能挑最严重的那些处理。因此通常要在第三阶段继续进行这样的工作。由于这些问题对软件开发过程的干扰,与其存在的时间密切相关,因此我们要在较短的时间内发现并排除那些软件开发过程产生较多干扰的问题。这样看来,这是一个比第二阶段所用的测试集更大的测试集,以发现更多问题;但是远小于前面讲的第一类测试的覆盖范围。
6 X, K; \' c2 P
对第三阶段检测工作的大致分类,以及每类检测的力度,如图 4-7所示。另一方面,不同类型的检测,显然其频率也是不同的,比如第三类要比第一类频繁得多。具体内容在第7.10节介绍。
3 k, k) @+ t( z- F, G9 g/ B! I' U

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-10-9 12:34:30 | 显示全部楼层
4.10 狭义集成后具体检测方法
0 A7 O3 H9 p7 u! e* D( b( b
下面我们还是按照检测的四大类方法分析。! h# D% ~9 D& I* w: V5 v& {) J

- y  N. K: U, N! c4 L
第一类,代码合并,与本阶段无关。

, ^  g* k; j* w, @6 Q第二类,源代码检查。这一类中,代码自查、同行评审和结对编程是针对某一个提交的,一般已在第一阶段完成①。在第三阶段,无需再做一遍。双倍投入,增加的收益很少。对于由计算机完成的静态代码检查,如果因为时间过长等原因,没有在第一阶段使用,那么在第三阶段使用就是个好主意。第三阶段,多个提交一起检测,检测效率高,而时间又相对宽松。
6 x( h9 G! j  a' i5 D, Z7 Z) Y% x/ V( a. t. ?6 A
第三类,编译构建,也与本阶段无关,因为可以使用集成的第二阶段的构建成果②。

" V& B( }; c. [. h第四大类,程序运行时的测试,是集成的第三阶段昀重要的方法。- \6 t' u! x" y$ r

* a) \( d: K! {6 B5 ~9 K" G, b- q" r
此时的测试,不论是全面深入的,还是针对某个功能、某个缺陷的,又或是针对较严重问题的,大都是以测试程序整体的外在表现为主的系统测试。以组件、模块为对象,验证其输出的单元测试不常见。详尽的单元测试通常已经在第一阶段完成,不值得再做一遍。
( ?7 f  x: C: i- ~9 Y* o! K
当然,如果单元测试是完全自动化的,且在较短的时间内就可以全部再做一遍,那就另当别论。因为就像我们在第4.6节所分析的,有些问题会“不可避免”地漏到集成分支上,进而混进基线里。这些问题中也包括靠单元测试能发现的问题。前面说“不值得再做一遍”,这暗含着一个意思,那就是每做一遍,都需要付出很大的代价,而再做一遍时,收益却相对很少。如果付出的代价也明显变小,那么就有可能值得再做,甚至反复地做,经常地做。毕竟,每一次都有可能发现新的问题。如果测试是自动化的,那么再做一遍需要付出的代价就很小。因此,当单元测试是自动化时,可以考虑在集成的第三阶段来运行,以发现一些由于合并集成等原因而带来的新缺陷。
, R6 l' l9 _' E8 j; T7 K$ s( L/ i. u
如果因为要尽力缩短开发新功能的关键路径等原因,没有在第一阶段进行足够详尽的单元测试,那么可以考虑现在补上。此时,对实施测试的人员的要求就比较高,需要对源代码层面有较多了解。如果测试团队有困难,可考虑由程序员完成类似测试。从资源和成本来看,由其他程序员而非改动者本人来完成单元测试,不方便,效率不高。但若项目时长是特别追求的目标,且程序员资源充沛,那么就值得考虑。- u1 l# P% v- h
. b6 h; h# d# M. |# O9 A: }3 x
除了以上四大类检测方法外,还可以考虑在集成的第三阶段自动生成一系列的信息,比如根据源代码中的注释自动生成文档,根据源代码自动生成UML图,分析自动测试的测试覆盖率,等等。这里不展开介绍。把这些工作放在集成的第三阶段完成,通常要比放在“卡脖子”的第二阶段要好。
; \; q4 s$ H3 \" {
①如果同行评审在第一阶段没有完全完成就提交到集成分支了(详见第 4.4节),那么余下的部分某种意义上可以算作第三阶段的工作。
②当同一条集成分支上,存在多个产品或多个变体时,在集成的第二阶段不一定会构建所有的产品和变体。这样的话,第三阶段就需要构建其余的产品和变体了。
+ l' v2 w$ D0 w8 f1 ^
回复 支持 反对

使用道具 举报

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

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

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

GMT+8, 2018-7-22 01:42 , Processed in 0.062760 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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