SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 3627|回复: 2

[赏析] 4.5 过程导向还是结果导向

[复制链接]
发表于 2013-10-9 11:50:49 | 显示全部楼层 |阅读模式
4.5过程导向还是结果导向

6 \" f) e, S. z/ x1 b+ m+ {) K
是应该注重过程,要求程序员在提交前必须完成规定的若干项检测工作,必须完成指定的测试用例集,还是应该注重结果,要求程序员的提交有足够质量?前者是过程导向的典型代表。后者是结果导向的典型代表。
( I' q7 q% O3 l
与查找和排除缺陷相比,很多程序员更喜欢开发新功能。更何况,在新功能开发方面,程序员常常受到很大的时间上压力。而能否在指定日期前提交新功能的代码,又是如此明显的事实,远比提交代码的质量容易被看到。所以,不少程序员都有不愿意提高代码提交质量的倾向。- J/ _+ b% i8 K6 c) \/ N

6 o5 B) S/ f8 \' w1 ^
为此,方法之一是,在获得管理层的支持后,自上而下地规定程序员在提交前必须完成的软件开发流程,特别是其中的检测工作。这样做的好处是,可以迅速地实现某个变革。这样做的弱点是,规定本身可能教条僵化,规范所要求的检测方法、步骤、范围,对于某个具体的待提交的改动,不一定是昀有效率的:只要待提交的改动涉及到这个模块,都要测试这个模块的总共128个测试用例?另一个弱点是,规范可能流于形式:要搞那个劳什子代码评审吗?那大家都来签个字好啦,我们就当评审过啦。

7 j9 P7 G, n0 m7 e# q8 [  c方法之二是,确定指标,然后进行衡量,看结果,看程序员的产出。程序员对提交的质量负责,他有权力根据本次提交的改动,自己选择要使用的检测方法、步骤、范围。在看到这样做的结果后,根据指标反馈,调整他自己日后使用的策略。这样做的好处是,对于水平高的程序员,他能够根据每个提交的实际情况,制定更适合的检测方案。这样做的弱点是,对于初级程序员,他可能需要较长时间摸索,找到合适的方法。另一个弱点是,对于不喜欢新方法、不喜欢改变的人,可能永远都不愿意尝试新方法。此外,有时难以确定合适的指标,或者指标的衡量本身成本高、准确度低。- y0 d% f' O) w

9 Y: x; p( k, W# D: ^守、破、离①。对于经验不多的程序员,对于新加入某个组织某个项目的程序员,可以多要求他按照规范来做。对于经验老道的程序员,宜提供更多的灵活性。当然,所有人都要衡量指标。- ?9 W4 C: y, z% k9 O6 s
" |+ f) y% Y7 N5 ?
对于新工具、新方法,可在实施初期强制要求,在大家熟悉它掌握它之后,再由各人自主决定在具体情境中是否使用,如何使用。在大范围强制推行前,可在小范围试点,看指标的变化,评估该工具或方法是否有效。在大范围强制推行的过程中,也始终衡量指标,观察指标变化,以事实说服大家使用。而每个程序员,也不断获得反馈和经验,应该在何种条件下,以何种方式使用该工具、以何种程度使用该方法。

3 J2 C% ?- p  a$ `& r从过程导向转变为结果导向,不仅对程序员的要求有了很大的不同,这对负责质量保证、过程管理、流程改进等工作的人员来说,也是一个很大的转变。在过程导向的环境下,容易形成对立局面,一方拼命加强控制,而程序员们甚至是程序员的领导们作为另一方,拼命抵抗,或者暗地里偷工减料。在结果导向的环境下,过去“统治者”如今有了更多服务者的含义:收集数据,向程序员们报告他们的完成质量,使他们获得及时和有效的反馈,以便他们调整策略和行为;引导他们找到昀适合的检测方法、力度、频率;向程序员们提供工具和方法的支持,便于他们使用。4 p0 {/ k- [# y! u

" {: W, d5 R& C
那么,对于程序员提交代码的质量,用什么指标衡量比较好呢?比较好,意味着比较能够反应项目对程序员的要求:既要开发新功能以创造价值,又要具有一定的质量。比较好,还意味着数据比较容易获得,比较容易统计。
# T( q5 H5 ^+ M' h/ A9 p! y
千行代码缺陷率,或者更准确地讲,千行代码问题率,是一个能反映对程序员的期待,同时又简便易行的指标。它是指程序员每提交一千行代码的改动时,夹杂着提交了多少问题。注意,这里的问题是加权的,因为不同性质的问题对后续工作的影响不同。对于主要影响软件发布的问题,可设权重为1,因为毕竟可以放到集成的第三阶段慢慢查、慢慢改。而对于严重影响软件开发过程本身的问题,比如编译不通过或者主要功能不能启动,可设权重为10甚至 100,因为它们会带给第二阶段集成很大的压力,而若从第二阶段遗漏过去,又会给开发和测试带来很大的烦扰。
8 u& D0 U  R0 o+ u' @' P6 v/ z: k* P) s4 b8 x2 S( Q: i% g5 h) s8 E
一个简单的算例,若程序员甲昀近提交了 2000行代码改动,含 1个权重为20的问题和 5个权重为 1的问题,那么其千行代码问题率为(20X1+1X5) / (2000 / 1000)=12.5。
" b9 X8 i' k1 C6 p; c0 y: H
上述指标假定程序员的贡献与代码改动量成正比,这是比较粗糙的计算。这可能引起程序员片面追求代码改动量,而非程序的功能本身。如果开发团队是使用功能点等更为准确的方法来计算程序员的贡献,那么在上述指标的计算中,可使用这样的方法来代替对代码改动量的统计。比如从统计千行代码问题率改为统计每功能点问题率。: z$ X0 X  J7 q4 Y( C

. B* o# H+ Q' L
要进行问题率的统计,就首先要知道某个问题是谁引入的。事实上,即使不是为了问题率的统计,知道某个问题是谁引入的,也是很有价值的。把这样的信息告诉当事人,至少可以增长当事人的经验,以后避免犯类似错误。当代源代码版本控制工具能够方便地找到某行代码的改动是谁在哪次提交引入的①,也支持二分查找②,这些功能对回答某个问题是谁引入的有很大帮助。
  p( H7 F$ j2 V! P5 \& D% ~" ~( x
要使用类似千行代码问题率这样的指标,可先统计当前这样的指标的平均值,作为初步的参考。对于严重低于平均值的程序员,进行沟通,予以帮助。对于明显高于平均值的程序员,可以交流讨论,看看有什么提高发现和解决问题的效率的经验和技巧可以分享。当然,如果此项指标很高的程序员,其在功能开发上的效率很低,贡献很少,是靠拼时间、拼成本,把过多的时间和精力放在发现和解决问题上来提高该指标的,那并不是大家要学习的。  e& U  {& }% e! K# Y. a
& n( X' C+ h' O1 f6 x
当前该指标的平均值,并不意味着是该指标的合理值。如果应用本章前几节的分析方法,得出结论要适当加强提交前的质量保证工作,适当提高提交质量,那就适当提高该指标的期待值。这样,告诉程序员们一个明确的信号,本项目或者当前项目阶段,要提高提交质量。反之,如果得到的结论是,在提交前已经耗费了过多的时间进行质量保证工作,那么就可以适当降低该指标的期待值。

$ p, T7 O/ K2 W/ t/ R0 J除了改变该指标的期待值外,也可以考虑随项目阶段的变化,或者不同的项目,改变统计时使用的权重。比如,在项目中期,一般性问题的权重是1,严重问题的权重是 10。而在项目末期,一般性问题的权重变为 5,严重问题的权重上升为 50。与改变指标的期待值相比,改变权重的好处是,便于统计在较长时间段内,一名程序员满足期待的情况,少受统计时间过短时的偶然性的干扰。假定发布前的那3天严重问题的权重为 100,这之前的两周严重问题的权重为 50,再往前是20,那么如果只看大家在发布前那 3天的指标,则其中的偶然性因素很大。而如果看整个项目中甚至是跨项目的每个人的累计的表现,就能在很大程度上消除统计的涨落。
) n1 s$ f7 K& u
$ j1 x' J) J$ N' N  Z+ ?/ Z; o
昀后要提及的是,一个严重问题对软件开发过程的影响,跟其存在时间有密切关系。严重的问题必须尽快修复。此外,后面的第7.11节会讲到,即便是一般性的问题,也应该尽早修复。而上述指标不包含对修复及时与否的度量。因此需要其他管理手段,督促发现问题的及时解决,特别是严重问题的优先解决。也可以考虑在指标的统计中,引入问题存在时长这个因素。即,从统计每千行代码中问题乘权重的累积,变为统计每千行代码中问题乘权重乘存在时长的累积。

- ^/ V1 q0 ~6 N( }5 p①守、破、离(Shu Ha Ri)是日本剑道的哲学。守是指模仿和遵循。破是指突破和改变。而到了离这个境界,就是无招胜有招了。总之,从完全遵守开始,到逐步掌握规律和本质,灵活应用。$ `( |8 D  f) Q' S8 \2 z
①例如 Git和 Subversion中的 blame命令。
②二分查找( binary search algorithm,bisection method),在这里是指,已知历史上某个版本 A没有问题,而其后一段时间的某个版本 B有问题,然后通过不断的对半查找,找到在 A和 B之间,是从哪个版本开始有问题的。例如 Git的 bisect命令。
$ B( {& s3 B) ]8 F1 j3 N' R+ c. A
 楼主| 发表于 2013-10-9 11:57:37 | 显示全部楼层
4.6   狭义集成时检测力度

% g* i/ T' x: h# U# [' s! e
你收到一个提议,要在集成的第二阶段,也就是集成工程师做狭义集成以出基线的过程中,再加上 10条测试用例。这是不是一个好的提议?为此,我们先看一看集成的第二阶段存在的意义。

, `( T. S7 L: @% j1 J从本章前面几节的分析我们了解到,从为了昀终对外发布而发现和消灭问题这个角度看,大致上,如果问题容易发现,那就在第一阶段发现并解决。因为早解决,解决成本低。如果问题不容易发现,那就在第三阶段发现并解决。因为多攒些改动一起检测,每个问题的发现成本低。
5 A" t: X  k2 I0 s6 ~( |. O+ B5 g; B% M9 ^8 u  h4 R5 `
顺着这个思路,我们是不是能为集成的第二阶段找点空间,找点合适的事情做呢?难。论发现问题的成本,它比不上集成的第三阶段,还没攒那么多问题。论解决问题的成本,它比不上集成的第一阶段,流程比在第一阶段解决要复杂。两头不靠。
" |" j) V4 }. w* _% F
更严重的事情是,集成的第二阶段是个卡脖子的地方。在集成的第三阶段,若为了发现和解决问题耽误些功夫,那可能根本不影响项目的关键路径。在集成的第一阶段,若为了发现和解决问题耽误些功夫,那顶多影响将来依赖于这个改动的测试工作和其他开发工作。而在集成的第二阶段,若卡住了就不是卡住了一个改动,而是若干改动。于是会影响所有的依赖于这些改动的测试工作和其他开发工作。
4 w2 Y/ H" b- @. x2 H9 s
! x$ Q9 G/ ^1 \- z7 Y8 N这么看来,在第二阶段发现和解决问题,一无是处,根本就该取消第二阶段?* f9 X, Z) g, q2 A8 P
# \' X- u. c* ?5 y# g/ ?
注意,前面的分析,只考虑了软件中存在问题,对发布的影响。因此要或早或晚,选择昀有效率的时机,消灭问题。而软件中存在问题,除了对发布有影响,还对软件开发过程本身有影响。问题越严重,扩散到的人数越多,影响就越大。因此我们要严防严重问题跑到基线里面去,烦扰广大程序员和测试人员。这才是集成的第二阶段存在的意义。
6 _' m: \) w/ b' D
在集成的第一阶段,就严厉打击此类问题,不就成了?让这类问题根本就不要被提交到集成分支上去。不够,这还不够。因为总会有漏掉的:& N' I& M' s( P: {* J* U0 H* y
+ \2 o. H# ^' I) k# g9 M0 g/ r  k
首先,合并集成带来的问题,没法在第一阶段完全暴露出来。即便是做了一次从集成分支到工作区的更新,等到经过一段时间的检测,要提交到集成分支的时候,集成分支上可能又有了别人的新的改动。这些新的改动与本次提交的改动之间,就可能有新的合并集成问题,成为漏网之鱼。其中的一些问题,可能还挺严重。如图4-4所示。' j. P7 e# \6 r$ W" h
* D; D% d4 S$ J
: w7 `5 C7 ?% n! S, h+ G
其次,错误的操作和设置带来的问题,也就是我们在第 1.6节归纳的第四类问题。比如程序员忘了把一个新文件添加到版本控制之下,比如这名程序员的计算机上的构建环境跟别人的不一样,等等。程序员在提交前没有察觉、没有发现,造成这类问题流入到集成分支。这类问题常常性质严重,导致构建不通过,或运行时严重的缺陷,传播开来,危害很大。
还有,有些程序员因为疏忽等各种各样的原因,没有在提交前做足够的检测,有严重的问题暴露了出来。如图4-5所示。
. x/ s# C; ]2 X3 V& w2 ~: R

3 M) Q: s+ Q, s* b
主要是这三个因素,导致问题“不可避免”地跑到集成分支上来。而这些问题里,还有一些挺严重的。宁可付出一些代价,我们也要在第二阶段干掉那些严重问题,不然遗漏下去危害很大。
7 C! o7 r' `# v0 A8 j* ~" ]
具体要干掉哪些严重问题呢?简单地进行选择,可以把所有可能出现的严重问题,按照严重程度,也就是阻碍后续功能的多少,来大致排个序。在有限的时间里,先去探测排在前面的问题是否存在。或者说,要把程序“必须”要具备的基本功能,“必须”要通过的测试用例列出来。这些是昀紧要的。. A1 I$ ?8 }; R" J& a! @" [- g
, U% N* H! \$ [" r; |7 u/ L- D
如果想进一步精细优化,可以在排序时,把两个因素都考虑进去:一个是一旦有问题将带来的危害,另一个是存在问题的可能性。两个因素是相乘的关系。例如,问题A的严重程度是 3,问题 B的严重程度是2,而按照该企业内部的定义,严重程度每升高 1个单位,其修复价值为下一级的 5倍。那么,问题A的修复价值就是问题 B的大约 5倍。如果从历史数据来看,或根据分析推测,问题A虽然严重,但鲜少出现,其出现的可能性,还不到问题 B的 1/5,那么问题 B应该排在前面。反之,如果问题 B和问题A出现的可能性没差那么多,则更为严重的问题 A应该排在前面。
% |+ s! p# W& E4 g+ o; Y( ^, @5 `
当然,还可以把不同问题发现成本不同这一点考虑进去。不过这样考虑起来怕是有点太复杂太麻烦了。反正通常来讲,严重的问题,阻碍后续功能多的问题,也就是刚点两下鼠标就能看到的问题,也就是发现成本低的问题。
* Y9 p: Y) C0 B- G& b1 o) D0 w8 h" z! V! f6 w
而解决问题的成本一般难以考虑进来。因为这里所说的一个严重问题,是指程序所表现出来的严重问题。而程序代码的不同错误都可能导致相同的表象。因此难以预计,不同的表象,其解决起来到底孰难孰易。
+ R% n, ]: g7 d8 g6 Y* L- {
现在我们知道了如何排序。那么,应该在队列的哪个位置拦腰切下一刀,只检测前面的问题,不检测后面的问题呢?' z4 p) M& q, `6 h- ^* k
  S  M0 Y1 E4 L* d
要检测的内容不能太多。检测的内容太多,检测的时间就变长。更何况,卡得太严的话,就不容易过关。不论是剔除有问题的提交,还是直接修复问题,反正要做相应的处理,花费时间。在提交质量不变的情况下,卡得越严,每天集成工程师要处理的问题就越多。太多了,就可能处理不过来了。更何况,在处理的过程中,在还没有出基线的时候,可能又有新的“不可接受”的问题涌入集成分支。这可能会导致基线“永远”也出不来。此时,狭义集成阶段,变成了软件研发中的卡脖子路段,经常有大量待集成的提交淤积在这里,经常有大量的活动在等待未集成的提交。这是要特别注意避免的。
+ n; S- C( Z8 x- `  d! N
如果在你的项目中,这种情况经常发生,那么应该考虑适当减少检测的内容。当然,也有提高提交质量,提高狭义集成的检测效率和问题处理效率①等其他方法备选。
3 [! n9 e0 ~& ?! ~  }' t- j* h+ b# ~: t2 o. f. d1 J
前面讲的淤积,是一个硬性的约束。但即使没有达到淤积的程度,也并不意味着就肯定应该继续增加检测的内容。增加检测的内容,意味着占用更多资源,产生更多成本。而往往更重要的是,它将导致检测时间的增加,进而放慢了狭义集成的频率。频率变慢将导致因为开发活动间依赖而引起的等待增多,影响项目时长;并将导致合并问题的总量增加。为什么会这样,到底有多大影响,我们将在第7.7节详细分析。

) k' G& ?' }' M$ T2 R/ ~4 n' ^/ s回到本节开始时提出的问题,是否应该增加那 10条测试用例?首先要考察,打算增加的 10条测试用例,是否能够有效检测出严重问题。它们的检测出问题的效率,应该是高于、相当于,或略逊于当前已有的检测方法。如果它们的效率很低,那与其考虑增加它们,不如考虑增加更好的检测方法。而如果它们检出的问题与当前所用方法有很大的重复性,那就看谁更高效。保留高效的,代替低效的。
: b1 X- A/ j' k. Y4 a" }" P' `* S  K7 K. x) v  s! a. r
然后考察,增加了检测力度之后,是否将导致淤积。如果当前狭义集成已经压力很大,那就不应该继续增加检测力度。
0 a* e% v( V# r8 u% e2 [3 s
最后考察,增加了检测力度之后,所减少的对开发和测试的打扰,是否值得为此而多付出资源、成本和项目时长,是否值得为此而增加合并问题数量。
% w! ]' b) g3 J, N, x, x$ N; ?4 N* |: ?  C" y9 ]/ `
例如,假定有一个项目,其项目时长很关键,需要尽量优化缩短,而资源、成本等因素相对来说不重要。当前项目时长主要由活动间依赖关系决定。此外,合并带来的问题,当前不是问题的主要来源,因此做粗略的估算时可以忽略。调查表明,当前因程序质量不好而使程序员完成开发任务的时间延长了10%。而这 10个自动测试用例,可以覆盖住当前常见严重问题的 50%。因此作为粗略的估算,大概能加快程序员完成每个开发任务的时间是 5%。而在集成工程师一侧,它将增加工作量,使集成频率放慢 10%。也就是说,每个开发任务提交后,平均要多等 10%的时间,才能进入基线。当前程序员大概2天一提交。由于在集成的第二阶段使用了持续集成工具,集成很频繁,因此在统计上,提交后再等上 1小时,就能进入基线,被另外一个程序员所取用。也就是说,关键路径上,(2 X 8) / (2 X 8+1)=16/17的部分,将缩短 5%,而 1 / (2 X 8+1)=1/17的部分,将延长 10%。显然,这是一桩好买卖。
9 k7 x# h; E8 ~
, b) @$ e  i: u9 ]①具体有哪些提高效率的方法,请参见第 8.7节。

本帖子中包含更多资源

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

x
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-10-9 12:12:08 | 显示全部楼层
4.7 狭义集成时检测方法
6 K6 f! B8 Q. `6 |7 b/ K! a
由于第二阶段去除问题的高成本,通常我们只在第二阶段对程序的整体功能进行粗略的检测,以低成本检测出那些严重的问题,去掉它们。更多的细小琐碎的问题,还是留待第三阶段发现和解决。让我们先从发现问题的角度,看看四大类方法,有哪个或者哪些适用于集成的第二阶段的检测。
( [: l' p  `( p# e( |
一般来说,版本合并是由程序员在提交时完成,让其提交的改动基于集成分支上已有的昀新的内容。具体到操作上,一些版本控制工具是靠让程序员在提交前进行更新,来进行版本合并的。
( D" X& |+ M! A; e7 |& r/ b) \* w/ @/ v' {* Z! ]
作为提交的结果,集成分支又向前演进了一小步。版本合并由程序员完成,一般不需要集成工程师将程序员的改动合并到一起。

+ a0 e' f+ n2 _这样做的主要原因是,对于合并操作中出现的冲突,应该由熟悉代码的程序员,而非集成工程师来酌情处理。如果集成工程师在合并时遇到冲突,就不得不联系程序员解决,沟通配合,一来二去,很多时间就过去了。处理提交时的合并,关键要熟悉代码改动,而一般不需要对复杂操作步骤的掌握,或者高深的关于版本控制的本领。因此,让改动了代码的程序员去做,一般是最合适的人选。
# `8 p# G% Z; F0 R6 Y# a
; Y; n- M5 K! j" N; X: g在少数情况下,确实不是由改动代码的程序员本人来完成这样的版本合并工作的。比如,开源项目中,由于贡献者的水平参差不齐,想法各异,难以约束,而由于是地理上分布的开发,沟通不便,所以容易出现协作上的问题。于是,在一些开源项目中,项目的核心成员(们)不允许广大贡献者随意提交改动到集成分支,只允许他们把改动做成补丁包用电子邮件发过来。那么,在把补丁包里的改动塞到集成分支上的时候,就可能有版本合并冲突,需要由核心成员解决或协调解决。( `4 H1 K+ g( ~. u5 j& Z2 }* j: x
& j6 Z6 P0 e2 u, q
再如,各个子团队,分别提交所负责的程序模块的改动后的版本,然后由集成工程师进行搭配组合。出现这种情况的原因很多,而提交二进制组件而非其源代码,是典型的原因。在这种情况下,尽管集成工程师仍然做合并集成工作,看看大家新近的改动能不能放在一起工作,但此时不存在源代码合并的冲突。
* Q! r% h" t% U# B1 x. a1 y3 S
第二类方法,源代码检查。这类方法通常不在集成的第二阶段使用。代码自查和同行评审针对某个改动进行,应当放到集成的第一阶段。如果放在第二阶段,它所耗费的时间就显得太长了。若此时使用它,除了发现严重问题,还会发现零零散散各种问题,这些问题没必要占用第二阶段的时间来发现和解决。所以在第二阶段使用代码自查和同行评审很浪费。结对编程与同行评审类似,且它需要在编程时进行,无法在集成的第二阶段使用。
( B3 Q& }& z% O4 T. H" i
2 W5 _2 q, u) z$ n* z
静态代码检查视其检查范围和检查耗时,放到第一阶段或者第三阶段。针对本次改动、耗时短时,放在第一阶段。通篇检查、耗时长时,放到第三阶段。在第二阶段,它不能代替粗略测试,因为大量严重问题检测不出来。而粗略测试却可以代替它,因为粗略测试已经可以很有效率地揪出那些昀严重的问题了。
" m4 Z/ a& Y5 Y7 \* {
第三类方法,构建以发现问题。有全量构建和增量构建两种方法可供选择。如果增量构建足够稳定,出现问题的概率足够小,那么应该选择增量构建,否则就只能采用全量构建。当然,这只是权宜之计,作为解决根本问题的办法,应该找对构建有深入理解的人才,努力提高增量构建的稳定性。
$ p0 y$ h$ Y) L
  C- |( s; F9 `. }3 a
此外,对于格外重要的版本,比如即将进行重要测试的版本,或要发布的版本,应多考虑全量构建,以防万一程序因构建的问题而与源代码不一致时,引发的巨大损失。此时,若要加快速度,可考虑一边进行增量构建和随后的粗略测试,以便及早排除代码本身问题导致的错误,一边进行全量构建和随后的粗略测试,以保证不会因构建而引入问题。此后把全量构建的结果送交测试等部门。

/ S8 M; _% z& r5 q! {* z! y+ ^! M第四类检查,运行时的测试。第二阶段的目标是在有限的时间内,把昀明显昀要命的问题干掉。那么,对程序进行涵盖系统主要功能的粗略测试就特别适用。这样的测试,检测时间很短,却能发现那些很重要的,将严重影响后续工作的缺陷。这样的测试,通常称作冒烟测试(smoke test)或健壮性检查(sanity check)。0 H2 X  V' T  k/ |' H
! B9 G# T! m% u/ W
由于这样的测试要反复地做,所以昀好能把它自动化,降低成本,也有利于更频繁的集成,持续集成。

& q/ b# n! x* m! y- I此时的粗略测试,其测试用例集一旦确定,在一段时间内通常是不会改变的。也就是说,并不会根据每次集成的改动所牵涉功能的不同而调整本次集成的测试范围。这主要是因为,调整本身就是一件需要收集数据、分析思考,需要付出时间的事情。而粗略测试一般来讲很快就可以完成。所以还不如就一成不变地执行同一套测试用例集。如果粗略测试是完全自动化的,甚至狭义集成本身都是因为使用了持续集成工具而变成自动化的,那么每次集成时调整就变得更困难。当然,如果在具体项目中,如果找到并且实现了一套算法,能够根据提交的改动,自动增加或减少特定的测试用例,使测试覆盖更接近昀优,那是最好不过的事情
% v' V$ ^/ r1 o
回复 支持 反对

使用道具 举报

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

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

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

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

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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