RUP测试过程实践
1. 在计划测试时,如何确定测试工作的范围和如何整理测试需求;
g5g.Q3tA$S+V02. 设计测试用例时,应该如何把握测试用例的粒度;
X(~Y{,z5A03. 如何平衡测试用例的可用性和可维护性;51Testing软件测试网u*Z9ZL;s"RW6w2P0TS ]D
4. 如何通过逆向的测试数据分析方法来保证测试用例的有效性和减少测试工作中资源的浪费;51Testing软件测试网}p Z.b.L }^
5. 一个简单的但有实际意义的例子将展示如何将笔者的方法应用到测试过程中。51Testing软件测试网Oe o1E0e W
51Testing软件测试网]0P0D(Nh1CG4D2KC)x
如何确定测试工作的范围?51Testing软件测试网,x&ZBF&g'`,R
51Testing软件测试网W};v0m$N4L,C
对于一个存在生命周期的软件产品来说,它的开发和测试往往都不是一次性的,因为随着新的需求的出现,以及对原有版本的改进,新的版本会不断的发布(即使对于一些以客户定制方式运作的项目,在开发过程中以及发布后的维护期内,也会产生众多的内部版本)。随着版本的迭代,我们的测试工作也会一直继续下去。而在每一次迭代时,可能在整个工作阶段的开始就受到一些因素的影响,比如市场需求、既定的发布时间、并发的工作导致的资源紧张等等,使我们不得不考虑对软件质量要求的适度,最终使得我们在每个阶段的测试工作的要求或者说所涉及到的内容有可能是不同的。这种变化,最终将会影响到测试需求的确定。
3ty'eTVA5k~0那么到底该如何确定每次迭代是测试工作的范围呢?
4~AV5l&y;mn,V0在笔者的实践中,通常把测试工作范围的确定,等价的认为是软件需求的确定。51Testing软件测试网;BeL&o Ok
不过现在有一个很实际的问题是这样:软件需求在开发过程中不断发生变化,有时候到了后期还会有新的需求添加进来,还有些需求在交付内部测试版本之后又发现原来的需求本身就存在缺陷,之后再次返工,在软件最终发布之前,怎么可能确定的下来呢。啊,这些都是让我们的开发人员和测试人员极其头痛的事情。到底应该怎样在频繁变更的需求中确定哪些部分是我们在某个阶段要测试的内容呢?或者说通过什么样的方法可以改善我们上面提到的那些问题呢?51Testing软件测试网Y{w~m3v uz
一个实际的做法就是实现软件需求的版本化控制。51Testing软件测试网7\yA2B.J%C5@
既然说到了这里,就不免要说些题外话。笔者一直都认为软件需求是开发工作和测试工作在制定计划、开展工作时所共同参照的源头和依据,而我们只有在源头上控制好,才能保证下面工作的平稳开展。
])Hse{Q6|Z0如果希望某个阶段工作的进度和内容可以明确的定义下来,就必须要考虑软件需求的版本化控制。这里所提到的“软件需求的版本化控制”,是指在一个软件产品的生命周期中,当要进行一个新版本的迭代时,要尽早的确定这个版本中将要实现的需求,并同上个版本做出比较,哪些内容是新增的,哪些内容是被调整过的。在该阶段工作开始之初的工作会议上,明确的向所有需要了解软件需求的涉众传达这部分信息。而如果在该版本的开发过程中不断的出现需求变更的情况,则应该根据市场策略、已公布的发布时间、客户需求、实现的代价、难易程度以及对现有工作的影响等方面,对需求进行适度划分,严格定义当前版本中需要实现的需求,而其他部分,则作为未来版本的软件需求进行考虑。51Testing软件测试网B [UIu H
如果有的朋友认为上面的内容还是太理论化,需要一个更实际的、可操作的方法。那么只能说,对于需求的变更,以及因为需求变更而引起的设计的变更,必须要早发现,早讨论,早决定,早调整。这可能更多的要依靠一个团队中相关负责人员的主动工作来保证,而不是依靠一个明确的方法。51Testing软件测试网@ZHQ9BW?4F
注意,这里的一个关键是,对于软件需求,同样需要严格按照版本进行管理,或者说使51Testing软件测试网kZJ };n:eySG
用“基线”进行管理。51Testing软件测试网7S Hbk3GHO
P7I G'{w9lDK0
如何整理测试需求?51Testing软件测试网-v&M-A-Y2gRQmA m
51Testing软件测试网,Q'N6P"XI%\L4I0hU
一旦当前阶段测试工作的范围确定下来,我们就可以开始考虑测试需求的整理——也就51Testing软件测试网ot9yKA%Yr x7w2q I
是明确的定义现阶段要“测什么”。测试需求的确定将为我们制定进度时间表、分配资源以及如何确定某个阶段测试工作是否完成提供一个可供衡量的标准。当然,还有更重要的一点,已被确定的测试需求是我们进行测试用例设计和考虑测试覆盖的依据。
-z7R9l _L:o0`9m.s0整理测试需求的第一步,就是要“测试需求”。
YQ1kex&[0测试需求?对,不知道您是否想到,这里的“测试需求”中的“测试”是一个动词,指51Testing软件测试网.bK Y2u[7N
的是对软件需求本身的检查。
k gqu]"H)U-@?0啊?这不是已经超出了测试工作的范围了吗?测试人员不是应该只关心软件的实现同需求是否相符吗?这样对测试人员要求未免太高了。——这是笔者过去同一些朋友谈到测试人员必须对需求进行检查时听到的一些不同的声音。
@w$eV%E&]h9}!~0在这里,首先要明确一个问题,就是软件测试的工作到底做什么?51Testing软件测试网_~m1aFS
在《软件测试》( Ron Patton〔美〕,中文版由机械工业出版社出版,这本书是测试新手入门的经典教材)一书的第10页,有一个明确而简洁的定义:软件测试员的目标是找到软件缺陷,尽可能早一些,并确保其得以修复。51Testing软件测试网f:j,v [{!R kFd%L,x;u
瞧!这里说要“尽可能早”的“找到软件缺陷”。那这“尽可能早”要早到什么时候呢?
S#vuy^,J1x/w-h0不知道大家对《软件工程》这本书还有什么印象。至少在笔者看过的多个不同版本的软件工程方面的书中,对于软件缺陷都会有一段类似的描述:缺陷发现的越早,则修复这个缺陷的代价就越小,在需求、设计、编码、测试、发布等不同的阶段,发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍(参见下图)。这样看来,上面问题的答案自然就变成了“秃子头上的虱子”:从需求阶段开始!从“测试需求”开始!51Testing软件测试网rx+DH k!N.hu Eg
注意,笔者这里的观点并不是说可以取消团队中的“需求评审会议”,这里并不存在冲突。笔者所希望讲述的,是测试人员应该如何看待软件需求,而并不是把“需求评审会议”所承担的责任揽到自己身上。51Testing软件测试网/k ZZV a m1s.Xf
51Testing软件测试网,v
N,]3[XP:?K]4bj
在论坛上也偶尔看到有的朋友问:如何测试需求呢?每次看到这样的提问,笔者内心就禁不住的一阵激动,因为一直以来,讨论这方面问题的朋友的确少之又少。在笔者的实际工作中,对软件需求的检查包括两个方面的内容。51Testing软件测试网9Or3?uD!p G1^5V
一是对软件需求正确性的检查,也就是要保证需求文档中所描述的内容是真实可靠的。在进行这部分工作时,不要迷信所谓的“都是用户提出的真实的需求”,因为我们必须考虑,提出这些需求的涉众,是否真的可以正确的描述自己的需求?我们的需求人员是否真的可以正确的理解用户的需求?有没有一些被用户认为在业务处理上是理所当然、极其平常的事情,而没有作为需求提出来?有没有一些被用户认为他们过去使用的软件已经提供了相应的功能,所以认为我们也应当提供,而没有提出来的?关于这个问题,也曾经有朋友提过不同的看法,认为这样对测试人员的要求太高了——既要熟悉需求人员的工作,又要熟悉软件所涉及的行业的业务。但笔者还是固执的认为,作为测试人员,还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解——当然,这不是对一个刚刚入门的测试者的要求,但是如果想称为一个优秀的测试者,是难免要付出这部分努力的。51Testing软件测试网r3Z)d+gGS+l!n6E
二是要保证软件需求的可测试性。对于“可测试性”,笔者的概念是:对于一条软件需求或者一个需要实现的特性,必须存在一个可以明确预知的结果,并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证。说的具体一点,就是要保证所有的需要实现的需求都是可以用某种方法来明确的判断是否符合需求文档中的描述。如果对于某条需求或某个特性,无法通过一个明确的方法来进行验证,或者无法预知它的结果,那么就意味着这条需求的描述存在缺陷,应该请需求人员对需求文档进行修改或补充——我们有理由相信,如果作为测试人员对需求无法产生准确的理解,那么开发人员也同样无法对同一条需求产生准确的理解。对于一条确定的软件需求理解的二义性,是在不规范的开发过程中导致返工的一个主要原因。如果认为有必要,那应该在“需求评审会议”上确认所有涉众对需求的理解是一致的。
]n.D'K"J0当然,对于如何提高软件需求的质量,在网络上或者已经出版的书刊中都已经有了很多51Testing软件测试网Rt~IoUT%~/P$e
更加具体、实用的方法,如果有兴趣,大家也可以找来参考。不过,如果您是一位测试者,那么上面这部分内容对您仍然是非常有用的。相信您只要在工作中进行尝试,慢慢的体会,一定会发现这种方法给您带来的好处。
wM4QK5qZ0r:rv4@`BK#t kl0
现在当前的测试工作范围已经确定,相应版本的软件需求也通过了评审,我们就可以在
E(t/u.vtX|9I5@8k0这个已经确定的范围内进行测试需求的整理。我们手头上可以参考的东西,通常会有软件需求规约(以下简称SRS)和用例(以下简称UC)——当然,也可能是一份包含UC的SRS。通过对SRS和UC的阅读,我们可以从文档对特性和业务流程的描述中获得对软件所涉及的业务的一个基本的认识。比如用户在处理实际业务时都要作些什么,多个业务之间的先后顺序是怎样的,用户在处理业务是对于哪些地方有特别的要求,等等。这部分规则,将成为我们的测试需求中最基本的一部分。51Testing软件测试网V*P;UFlRDN
至于测试需求的表现形式,笔者认为大家都可以根据自己的需要进行设计,而没有必要把思路限制在到底使用表格方式还是使用文本方式,只要把握一个原则就行了:在一条测试需求中,用容易理解的自然语言,明确的描述一项需要测试的内容。对于多项测试内容,应尽可能的剥离开来,保证一条测试需求只包含一项测试内容。51Testing软件测试网O2?k3K!|o
另外,大家也可能注意到了,在软件开发过程的这个阶段,通常是没有用户界面(以下简称UI)可供参考的——虽然RUP中对于需求阶段的工作描述包括了UI设计的部分,但很多时候在这个阶段还是无法提供一个确定的UI的——也就是说我们这时获得的测试需求,将是完全基于业务的,而并不包括基于UI的那部分规则,是同软件的最终具体实现相独立的。
!b-g'JM%g}0o(X"X4BHsc0
随着开发工作的继续,开发部门的架构设计文档和详细设计文档也将陆续提交,这时候,我们可以根据设计文档来对已有的测试需求进行增补。注意,这里我们对于设计文档中提到的内容要有选择的采用,只有同SRS或UC中已经定义的部分相符的内容,才可以用来调整我们的测试需求。而同软件需求不相符的部分,则需要同设计人员和需求人员一起讨论,确定下以哪一方作为基准,决定是否需要调整软件需求,然后对测试需求进行相应的增补或者调整。比如对于一些算法,需要考虑设计文档中定义的,同系统实现相关的那些计算公式,是否同软件需求中描述的算法表达的是否是同一个意思?而对于一些约束或者业务规则,设计文档中描述的是否同需求中的相应部分一致?51Testing软件测试网Z6T2v[ o-p9Ca*O
呵呵,看完上面这部分内容,恐怕又有一部分朋友晕倒在地了,而没有晕倒的那部分朋友也要提出异议:啊?!你这不是又包含了对开发人员所作的设计工作的检查吗?!刚刚让我们检查需求,现在又让我们检查设计,真的把我们当成全才了!
!b"lAHjMg0没办法,为了让软件交到我们手上的时候只包含尽量少的缺陷,大家只能再辛苦一下了。我们的工作不应当仅仅限制在软件交付后尽力找到存在的缺陷,而更应该努力及早发现软件缺陷出现的苗头,尽量预防缺陷的出现。
Bm6VpW4ai4s0虽然并不是说在所有的团队中都应该由测试人员承担“测试需求”和“测试设计”的工作,但是测试人员对这些工作起到的作用,是其他团队中的其他角色所无法替代的。
Ux"D?n+G#z0.o.w`d8C;R0
开发部门完成编码实现工作,提交供内部测试的应用程序时,测试人员手头上应该已经准备好了绝大部分测试用例和测试数据,测试部门将开始执行测试。通常在我们执行测试的过程中,即使我们已经从“通过测试”和“失败测试”两个不同的角度准备了非常充分的测试用例和测试数据,但总是有些缺陷的出现是出乎我们意料的,或者说是已有的测试需求和测试用例未能覆盖的。那么,对于这部分缺陷,也应当添加到测试需求中,并设计相应的测试用例,以便于下次版本迭代时进行参考。51Testing软件测试网}jR/|,R ev
OK,相信说到这里,各位看客也应该可以理解我的观点了:对于一个长期发展的团队或者持续开发的产品,它的所有东西都是要不断积累的、不断迭代的。无论对于软件需求还是测试需求,不仅仅是在一个版本的开发过程中,在不同的阶段进行迭代,在产品的整个生命周期中的不同版本间,也是不断迭代和积累的。
Q cqSL'_$s0,V]7oe4w.K U x0
关于测试用例
_ vDL/p"st\Z `051Testing软件测试网XD&u;L.TK$V:C{w
什么时候开始设计测试用例?51Testing软件测试网FNDx1O
测试用例该怎么写?
\(K~l:G*N0什么时候算是完成了测试用例的设计工作?51Testing软件测试网k0~S yg5Q-W
/N0GlLw3z[0
上面几条可以算是网络上测试用例设计方面最热的问题,而且每隔一段时间就会被不同的人重新提起。提问的有刚刚进入测试行业的朋友,也有工作一段时间后重新陷入迷茫的“老手”。这几个问题看似简单,可是要想回答的让大家都感到满意,还真是不容易。这样的高难度,笔者也不敢有太多的奢望,还是把自己的经验写出来,希望对大家有些参考价值吧。
q l b4hb9pr&{0测试用例是为特定目标开发的测试输入、执行条件和预期结果的集合。这些特定目标可以是:验证一个特定的程序路径或核实是否符合特定需求。——这是RUP中关于测试用例的定义。而在实际工作中,对于测试用例的设计和选择,是考察一个测试人员工作能力和经验的最好方法。51Testing软件测试网 F4c-L)W1r0}o*M1o3F
如果您像笔者前面说的那样,已经在工作中开展了测试需求的整理工作,那么测试用例的设计工作就会变成一件自然而然的事情了。如果您在需求阶段就开始了对测试需求的整理,那么当这部分测试需求整理完后,就可以开始相应测试用例的设计了。而随着开发工作的继续,在测试需求被不断的增补、调整后,也应该添加或修改相应的测试用例,以保证测试用例的有效性。这里笔者要特别强调一点:测试用例的完成并非是一劳永逸的,因为测试用例是来源于测试需求,而测试需求的来源包括了软件需求、系统设计、详细设计,甚至包括了软件发布后,在软件产品生命周期结束前发现的所有软件缺陷。来源的多元化注定了测试需求是非常容易发生变化的。一旦测试需求发生变化,则测试用例必须重新维护。51Testing软件测试网`5E%y0R/kV
如果您对于软件开发的迭代方法比较熟悉,那么就可以对测试用例的设计采用同样的方法。而最终的结果,是您的团队将逐渐拥有越来越全面细致的测试需求和测试用例库,测试人员越来越多的精力,可以放到对测试过程的考虑和测试用例的选择方面。51Testing软件测试网Vj)x,v%Q
至少在笔者的实践中,这种方法虽然前期需要相对大量的投入,但随着时间的迁移,在没有使用自动化测试工具的情况下,同样大大提高了每个测试人员单位时间内测试工作的效率。
0C\h-f Uy#p)r8H`0~X"^Im:c/X)D-P5l0
关于设计测试用例的方法,无论是在已经出版的专业测试书籍还是网络上的专业测试论坛中,都已经有了很多非常好的文章来专门讲解,笔者也不打算占用太多篇幅重新引用,大家如果有这方面需要,通过网络都可以很容易的找到这些资料。在这里,笔者只是想简单的评论一下很多初学者对这些方法容易产生的误解。
h3Z.w@5^+y:I T/]C0相信对于任何一个测试人员来说,等价类划分法和边界分析法都是最早接触,也是最基本、最容易使用的测试用例设计方法。很多朋友也都知道先使用等价类划分法划分出等价类,然后使用边界分析法确定测试需要的边界值。但是很多朋友也提到,在工作了一段时间后,发现这两中方法所能应用的地方越来越少,难道这两种方法真的只能应用在检查编辑框输入类型和输入长度的时候吗?当然不是。对于一些刚刚接触测试工作的朋友提出的这个问题,笔者认为现在市面上的很多测试书籍都要承担很大的责任。比如很多书中,在讲到测试用例设计时,都不约而同的使用同一个例子——Windows计算器程序。通常是告诉你对于计算器有一个允许的输入范围(比如允许输入一个大于0小于等于100的整数),然后要求设计相应的包含合法数据和不合法数据的测试用例。当然,仅仅是这样一条简单的描述,我们已经可以设计出很多测试用例和测试数据了,比如对于输入范围的考虑,对于输入数据类型的考虑,对于输入长度的考虑等等。但是在我们的实际工作中,很多时候看到的并不是这样过于简单的软件需求描述,很多时候这些内容都是隐含在一些算法或业务规则中的。
2ou&NWb^0我们现在举个例子来看一下:
_PZdf{1Su0“双倍余额递减法是在不考虑固定资产残值的情况下,以平均年限法折旧率(不扣残值)的两倍作为折旧率,乘以每期期初固定资产折余价值求得每期折旧额的一种快速折旧的方法。
'i:SN)FH oUoANb0 年折旧率=2÷预计使用年限×100%
L%~.J"kEH9D0 月折旧率=年折旧率÷12
4dCB#X[%}yF@0 月折旧额=期初固定资产账面净值×月折旧率51Testing软件测试网.]q.m?K
r
K
为了保证固定资产使用年限终了时账面净值与预计净残值相等,在该固定资产折旧年限到期的前两年,将固定资产净值扣除预计净残值后的余额平均摊销。”
上面的内容是我国现行财务制度中关于固定资产折旧的一种方法——双倍余额递减法——的具体算法,大家可以在任何一本会计书中找到这部分内容以及一些相应的例子,不过我们这里并不关心固定资产的折旧到底是怎么一回事。笔者想知道的是大家在看完上面的描述后是否已经发现,我们在设计测试用例时,对于准备进行折旧的固定资产,至少应该包括预计折旧年限小于两年、等于两年和大于两年三种不同的类型。这也应该算是一个等价类划分法和边界分析法的应用吧。
/U7N.u7xc0实际上,制约我们更好的使用这些测试方法来进行测试用例设计的,并不是方法的应用范围不够宽广,而是因为如果我们不能对这些同实际业务相关的具体算法或业务规则进行深入的分析,就不可能挖掘出深层的测试需求,那么这两种方法的应用也就很有限了。这也是笔者在前面一再强调加深对软件需求了解的原因。51Testing软件测试网+{xkOd gZ_x_+b
对于网络上也有讨论的另外两种方法——错误推测法和因果图法,则分别因为可靠性较差和操作相对复杂而并没有得到广泛的应用。
!SMOsMa-@K8z f051Testing软件测试网R-Z j4T4nH9gq
如何划分测试用例的粒度?51Testing软件测试网(SoJ!z W
51Testing软件测试网DR*Jq:p
我们是不太可能在一个测试用例包含所有测试需求的,因为众多的功能以及不同的路径
!O'DUbNsK:FMn/V]0组合将使这样一个测试用例像巨无霸一般,完全不具有可操作性。——除非您的软件所包含的功能真的又少又简单,不过如果真的有这么一个软件,恐怕也没有测试和发布的必要了。51Testing软件测试网7ZYuG,sr!c/H
当然,这也并不是要您走向另一个极端,为需求中定义的每个特性或功能都提供一个甚至多个测试用例。这里的关键,是要寻找一个合适的度。
Pc9q'tV:f8p!i0笔者推荐的方法是:关注有效功能。
s|hb,| Y051Testing软件测试网ec P&U0V
有效功能:就是指在被测应用所涉及的实际业务中,当用户在手工状态下进行工作时,整个业务流程中对用户来说,具有实际意义那些功能。这个功能的特征是当我们把这个功能单独从计算机软件还原到用户的原始手工状态时,它的完成可以作为用户实际业务的一个阶段性结束的标志,而不是一旦从这个业务流程中独立出来就失去了意义。而该业务完成后,可以为其他用户或业务提供所需要的信息。51Testing软件测试网 H[cPt/aG,t-B
51Testing软件测试网(g&`1P[F-G
这里区分“有效功能”的关键有如下两个:51Testing软件测试网qgy9CFnprgi
1. 这个功能是可以还原到用户原始的手工业务流程中去的。我们的计算机和软件,都是为了帮助用户解决手工业务中一些烦琐和低效的问题,而提出的一些忠实于原始工作方法或略有变通的解决方案,并不是要改变用户全部的业务流程。所以,应该从用户实际业务的角度来判断功能是否有效。51Testing软件测试网W;R*QL@/n
2. 这个功能是否可以标志着用户实际业务的一个阶段性结束?并且这项业务完成之后,被完成的业务实体是否可以交付给其他用户或业务以供完成下面的工作?
u&DKnFmE0为了方便理解,我们可以先看一下下面的例子。51Testing软件测试网Z4`:n [7n A8J
拿我们常见的财务软件来说,当添加一张会计凭证时,通常是需要填写会计科目,在使用计算机完成工作时,我们可以利用软件的功能,从很多备选科目中选择一个自己需要的科目,或者通过科目代码来输入科目。这项功能很有可能会作为一个特性要求出现在软件需求规格说明书中,那么这个科目的选择或输入是不是一个有效功能呢?让我们试着用上面规则来衡量一下。51Testing软件测试网uuFYX*Y
首先,这个功能在用户手工业务处理过程中是存在的,不同的是这项功能是在用户填写凭证时,在自己的大脑中完成的——用户会根据需要,在自己记忆的科目中选择合适的填写上去,这项功能节省了用户在记忆大量会计科目时付出的额外劳动。我们可以认为这个功能是为用户原来的工作提供了一种简便的、变通的方法。
2c}A)D Xk,e![0那么这项功能的完成对于用户来说意味着什么呢?我们从上面的描述中可以看到,用户希望软件提供的是可以添加一张完整的凭证这样的功能,而不仅仅是方便填写会计科目。填写会计科目只是用户在添加凭证时的一个步骤,单独把这个功能提取出来对用户来说没有任何实际意义。对于业务流程下游的用户,需要的也不仅仅只是一个会计科目的信息,而是一张包含了会计科目以及其他会计信息的完整的会计凭证,否则就无法进行下面的工作。这样看来,这个功能并不是一个有效的功能,我们可以把它最为需要测试的特性在测试需求中进行描述,却不应该作为一个单独的测试用例出现在我们的测试用例集中。而我们在测试用例中真正关注的,应该是添加会计凭证这个具有实际意义的功能。
!dN\$Be0}in2I0另外,我们还需要关注如何将多个相互之间存在依赖关系的功能区分为单个的有效功能。例如,现在有A、B、C三个功能,其中B功能的开始必须依赖于A功能的完成,而且A功能如果出现不同的完成状态,B功能也会做出不同的反应;C功能对B功能的依赖也是如此。那么这时候,我们是否应当将三个相互依赖的功能包含在一个测试用例中呢?这样的做法也不是不可以,但是我们也可以先判断一下,这三个功能是否都是有效功能(您可以使用前面提到的方法来试着评判一下)?如果A、B、C都是独立的有效功能,那么我们可以从上面的描述中发现,它们之间存在的依赖性,可以理解为是一种状态或者说数据的依赖性。后一个功能关心的,是前一个功能最终提供给它的是什么样的“输入”,而不是前一个功能到底作了些什么。这样看来,我们完全可以将它们分别包含在几个独立的测试用例中,而在每个测试用例的开始,把不同的输入作为不同前置条件来描述。
k|a'jp'S051Testing软件测试网3y&E P"X0vmK
测试用例是否应该包含所有的细节?51Testing软件测试网JstGI!PX
p _ `+k+J k0
这是在网络上听到诉苦最多的又一个热点问题:公司要求按照一个严格的规范来开展测试工作,必须书写所有的测试用例文档,要求文档的书写一定要具体,并在执行测试时要参考测试用例文档来进行。如果测试用例文档写的过于简略,则会被领导斥为偷懒。但是,如果文档中的对操作步骤描述的过于具体,像下面这样:51Testing软件测试网 }mJP3Q"`
&TQ.bT L*p2k!k0
51Testing软件测试网N-^\uU6eZ
51Testing软件测试网
Rz!g)vK;lg
01. 在“用户名”项中输入“user”;
2P r[BZD002. 在“密码”项中输入“password”;
o9i(V qIg;XA003. 点击“确定”按钮。
Pgq)R?0\;GPw0这样的描述方式表面看起来可操作性似乎是增强了,任何人拿到这个文档都可以充当测51Testing软件测试网s)]O3lscO.u
试人员,检查一下这个功能是否存在缺陷。但是我们不要忘记,在开发过程中,变更的存在是必然的。一旦需求、设计或者应用程序中的某些细节发生了变化,比如“用户名”变成了“操作员”,“密码”变成了“口令”,“确定”变成了“登录”,或者输入项所接受的数据类型发生了变化,那么同这部分内容相关的所有的测试用例都需要修改。否则,我们凭什么可以保证这些描述不同的测试用例说的是同一样东西?如果我们只有这么一个测试用例,也许一切都不是问题,但是对于一个业务复杂、功能完整的系统,如果按照这样的方法描述测试用例,最终要么产生大量的测试用例文档,要么产生过长的单个文档。无论是那一种,如果发生了类似于上面说的变化,维护文档都将变成一次地狱式的体验。51Testing软件测试网:Uu)?y dD0L+Sc
这也是为什么在网络上频频出现的这个问题,而且每次出现都会受到测试同行们的关注的原因。那么这个问题应该任何解决呢?测试用例是不是把所有的流程写出来就可以了呢?如何在减少测试用例文档中包含过多琐碎的细节的同时保证测试用例的可操作性呢?又有什么方法可以提高我们维护测试用例文档的效率呢?
;c AxQN)SV&b0笔者的建议是:关注“测试思想”而不是关注操作步骤。
+N#}5[Q1}O,B*[ n0要理解这个问题,首先要弄明白测试用例的作用。
%U u |{o8l#k _n0就像用例一样,测试用例并不是用来描述具体的实现的,而是着重描述处理问题的思路——对于一项明确的测试内容进行测试的思路。作为测试用例的设计人员,如何理解基本流和备选流?如何深入分析并找到所有需要覆盖的路径和需要检查的特性?我们在测试用例中应该用容易理解的自然语言清晰的来描述我们将要如何进行测试,而不是简单的把在应用程序上如何操作的烦琐的步骤记录下来。把测试用例设计当成填写具体操作步骤的表格是人们对测试用例最大的误解。51Testing软件测试网x9v;U*F:XiMp h\
传统的测试用例文档编写有两种方式。51Testing软件测试网+sE5W2W Hm5[r
一种是填写操作步骤列表:将在软件上进行的操作步骤一步一步详细的记录下来,包括所有被操作的项目和相应的值。51Testing软件测试网G`*]@ ek
另一种是填写测试矩阵:将被操作项作为矩阵中的一个字段,而矩阵中的一条条记录,则是这些字段的值。51Testing软件测试网6Z6nG0g O0l8G
网络上对于这两种方式孰优孰劣的争论,将大家错误的引导向了两个极端:要么采用A,要么采用B。而大家却忽视了一点,对于工作方法的争论,本质上同工具的争论并不是一回事(例如曾经的VC、BCB之挣)。如果不同的方法各有优势,我们完全可以通过变通的方法,把优势的部分组合在一起来使用。51Testing软件测试网u)E dOV d"R0\
操作步骤列表的优势在于对基本流和备选流进行分析后,它可以清晰的描述您的测试思路。而测试矩阵则更适合于用来存放测试数据,特别是那些需要人工赋予一个确定的值的特性。51Testing软件测试网_\2Gya8wL&lBr
下面,我们来看一个例子,当然,这个例子同样是杜撰的。51Testing软件测试网1P)JQJk)i"LL |2mF
8Nu%G/I-Gi0
需求名称:用户登录安全验证
Hr"STZ0需求描述:用户登录安全验证是为了保证所有登录到系统中的用户,都是由系统管理员预先在系统中设定的。使用系统中不存在的用户名,或者用户名输入正确,但密码输入错误情况,都无法登录到系统中。当用户使用了不存在的用户名或错误的密码时,系统应分别给出适当的提示。如果用户连续三次无法使用正确的用户名和密码登录到系统,则系统应给出适当的提示,并退出当前程序。如果用户使用正确的用户名和密码登录到系统,则退出界面,转到系统主界面。对于用户登录界面和程序主界面,请参考相应的UI设计文档。51Testing软件测试网FBqR%j6},g8@#g
"?2S]^f.W8CRk(S0
测试需求:51Testing软件测试网k)Ed3`-PpNu(N
01. 检查能否使用正确的用户名和密码登录到系统;
~-O4rAa002. 检查能否使用错误的用户名或密码登录到系统;51Testing软件测试网T#Ygg1@g
03. 检查使用错误的用户名和密码登录失败超过三次,是否会自动退出当前程序。51Testing软件测试网\C'F7`u0A%`g5y
H7w)|{#k"F0
测试用例:
;p;Bb/J9[.hZ0序号
c!`MC
Ab*?G0 操作过程描述51Testing软件测试网j7i/D_$L{{~6h?
w{#ne1["{ }0151Testing软件测试网-zD4i'E&nx#nC H
输入用户名。51Testing软件测试网PX;~$kWz8d5_/z
51Testing软件测试网'dSA9d3K\
251Testing软件测试网}@
z4N@y1M
输入密码。
(h1F{,d7bME0
h:FMnOJm4k03
"K;rt'O eP0 确认登录。
4?)y0]g E/S"eez{0
51Testing软件测试网
|p^Au:U
51Testing软件测试网b_qt2ssM
序号51Testing软件测试网
}0|P6N3R
QDry
用户名51Testing软件测试网$_jPHb1y
密码
%@ XSTHB0k0 预期结果
]2Sy%x,N+y,Rc0
3o9k#Fp,l Vt01
(p"~t*T} |(tmi"U0 正确的用户名
#jX?wn6Hl0 正确的密码51Testing软件测试网4z0xMl,a'P
登录到系统并转到系统主界面51Testing软件测试网2GU
I-d S5C\
51Testing软件测试网)u;_"JU
|[3r&b