快捷搜索:

RUP测试过程实践之测试需求与测试用例

关键词:

软件测试 历程实践 测试用例 RUP

RUP(Rational Unified Process ,Ratinaol 统一历程)是rational公司提出的一套软件开拓历程,今朝最新的版本是2003。RUP的最大年夜特征便是它供给了一套完备的软件开拓历程框架,任何人或组织都可以根据自己的必要来对这个历程进行裁剪,并根据自身必要进行调剂后使其成为个性化的历程。读者可以参考收集上传布的《RUP2000中文版》。

(Rational以及 Rational Unified Process 均系 Rational Software Corporation 在美国和其他国家的牌号或注册牌号。)

有句老话说:万事开首难。说的是在服务情的时刻,平日都是一开始感觉异常艰苦,然则只要上了道,入了门,就会越来越轻易、越来越顺了。写文章也是如斯。不过笔者这里说的开首难并不是不会写文章,而是专指不会写文章的开首部分。以前看到过的很多小说,无论是言情的或者武侠的,都邑拿很长的篇幅出来作为“引子”,或者叫“楔子”,用来交待一些同小说相关的信息。而一部小说是否能够吸引读者,这部分内容也起了很大年夜的感化。不过,笔者作为一个技巧事情者,写的大年夜多半都是技巧文章,一样平常来说文章的内容、布局都是一早就想明白的,唯独这个开首,其实不知若何写起。不过想想也罢,既然不长于这个,那就努力把内容写的具体、易懂一些,只管即便让读者不会有上当的感到吧。

软件测试作为一个自力的职位或者说行业,并不是软件业的新闹事物,但切实着实是跟着近来两年一些新的思惟注入海内软件行业(比如敏捷开拓历程、测试驱动开拓等),才得以红火起来的——这一点,从相关册本的出版和贩卖就可以看得出来,从事软件测试事情的人也垂垂多了起来。然则也由于是刚刚起步,同时海内大年夜多半软件公司都还处在中小型开拓团队以致作坊式开拓的层次,弗成能供给太多的测试职位,想找到一些高水平并且富有履历的测试职员更是难上加难。这终极也就导致了海内大年夜多半测试从业者都处在“低级阶段”这样一个结果。

笔者经久生动在海内的几个对照有名的测试论坛,发明大年夜家盼望评论争论的问题主要可以分为两种:一种是对付一些测试事情详细操作措施的提问,一种是对付测试对象应用的提问。总体看来,更多的问题集中在了后者。这彷佛已经成为了海内软件业的通病,无论是开拓回是测试,总盼望可以经由过程某个对象或者说话来一劳永逸的实现某个抱负。假如然的盼望对象可以改变统统,那么这种希望老是会掉?的。而前者,大年夜多是由于进入了一些刚刚开始注重软件测试的中小型软件公司,而公司的开拓团队中认真软件测试的可能只有一两个对软件测试一孔之见的新手,当公司必要开展某些方面的测试事情时,缺少这部分相关履历的同伙变选择了经由过程收集告急。

测试对象的利用,切实着实可以前进事情效率,而对付测试对象方面的提问,原先也是无可厚非的,然则在笔者的实践中,假如盼望前进一个团队的事情效率和改良事情效果,关注于历程和措施要远远好于关注对象。测试对象的进修、引入和应用,本身便是一个必要耗损大年夜量资本的历程,而且对付对象的选择和引入对象机会的选择也是异常关键的,假如认真这项事情的并不是一位在软件行业沉浸多年,有着富厚测试履历并熟知开拓历程的资深人士,那么开拓团队将为此承担伟大年夜的风险。纵然成功的引入了测试对象,对象本身可以带来的效率的前进也不是在短期内可以表现的。

在这里,笔者盼望刚刚或者正在筹备组建测试团队的软件公司在斟酌测试流程的搭建和测试对象引入时,不要给刚刚进入测试行业的同伙太多压力,由于这两项事情都不仅仅同软件测试本身相关,同时也会涉及到项目治理、开拓历程方面的内容。随意马虎的做出一个抉择只会对将来在团队中测试事情的开展带来晦气的影响。

在这篇文章中,笔者不盘算对测试对象方面的问题提出任何建议,而将对收集上大年夜家关注的测试历程和测试措施方面给出一些具有实际参考代价的履历。

测试事情应该什么时刻开始?

测试用例是不是必然要写?假如写,应该具体到什么程度才会对照好用又轻易掩护?

什么样的测试用例才是好的测试用例?

测试用例若何覆盖测试需求?测试需乞降测试用例的关系是什么?

怎么样包管测试需求的收拾和测试用例的设计不会挥霍太多的人力或其他资本?

……

这些问题可谓是旧调重弹了,在论坛上、MSN上,或者邮件中,也常常会有同伙问到笔者一些这方面的问题。信托不管是测试新手,照样从事测试事情有一段光阴的同伙,都邑在事情中不得不常常的要斟酌,这些问题到底有没有一个相对明确的谜底呢?

信托看到这里,已经有些同伙在想:这些问题也不是很难啊,在RUP对测试历程的描述中都已经说的很明白了啊。软件测试事情必须要经由过程计划测试、设计测试、实现测试、履行测试、评估测试几个阶段来完成。此上钩划测试阶段必要拟订测试计划、收拾测试需求;设计测试阶段要设计测试用例和测试历程,要包管测试用例完全覆盖测试需求;实现测试阶段要根据测试用例实现详细的自动化脚本或者手工的操作步骤;履行测试阶段则经由过程自动化测试对象或人手工来履行那些自动化或手工脚本;着末的评估阶段则要对软件的质量和测试事情自身的质量做出一个客不雅的评价。RUP中还有具体的事情指南和文档模板呢!

对,上面所说的这些都没有错,RUP中对付软件测试历程的描述要比笔者上面这段翰墨具体也活跃得多。然则,我们同时也可以看到,RUP中描述到的,更多的是关注于历程的治理,或者更准确的说,RUP是在为我们供给一个大年夜的偏向,是一个稳定的、具有指示感化的框架,而不是一些详细的、涉及到操作细节的措施。这也是为什么很多同伙通读了RUP中关于软件测试的部分,然则一旦实际利用仍旧找不准偏向的缘故原由。笔者本日盼望同大年夜家评论争论的,则恰好是这样一些在实践RUP测试历程时,从实际事情中总结出来的事情措施和履历。

对付测试历程方面的规范和一些基础观点,RUP中已经讲的很具体了,笔者在此也就不再赘述,有必要的读者请参照RUP中的相关部分。本文中所关注的内容包括:

1. 在计划测试时,若何确定测试事情的范围和若何收拾测试需求;

2. 设计测试用例时,应该若何把握测试用例的粒度;

3. 若何平衡测试用例的可用性和可掩护性;

4. 若何经由过程逆向的测试数据阐发措施来包管测试用例的有效性和削减测试事情中资本的挥霍;

5. 一个简单的但有实际意义的例子将展示若何将笔者的措施利用到测试历程中。

这里要事先声明一下,笔者事情三年来,不管是开拓回是测试,事情内容始终是环抱着信息治理系统相关营业展开的,而对付测试事情,也不停局限于在系统测试阶段经由过程手工措施和简单的使用一些测试对象特点进行黑盒测试。是以,在本文下面描述的内容中,难免受到客不雅情况和笔者小我履历的影响。也正由于如斯,笔者不包管本文中措施和不雅点得当于所有组织和小我的软件开拓历程。只是盼望能够借此为大年夜家供给一种思路,赞助更多人进行个性化的RUP测试历程实践,合营前进软件测试行业的水平。

别的,本文中应用到的例子,均为笔者的一些假设,假如损害到任何第三方组织或小我的利益,实属巧合,请经由过程E-Mail看护笔者,笔者将在往后再次宣布本文时做出响应的调剂。

若何确定测试事情的范围?

对付一个存在生命周期的软件产品来说,它的开拓和测试每每都不是一次性的,由于跟着新的需求的呈现,以及对原有版本的改进,新的版本会赓续的宣布(纵然对付一些以客户定制要领运作的项目,在开拓历程中以及宣布后的掩护期内,也会孕育发生浩繁的内部版本)。跟着版本的迭代,我们的测试事情也会不停继承下去。而在每一次迭代时,可能在全部事情阶段的开始就受到一些身分的影响,比如市场需求、既定的宣布光阴、并发的事情导致的资本首要等等,使我们不得不斟酌对软件质量要求的适度,终极使得我们在每个阶段的测试事情的要求或者说所涉及到的内容有可能是不合的。这种变更,终极将会影响到测试需求切实着实定。

那么到底该若何确定每次迭代是测试事情的范围呢?

在笔者的实践中,平日把测试事情范围切实着实定,等价的觉得是软件需求切实着实定。

不过现在有一个很实际的问题是这样:软件需求在开拓历程中赓续发生变更,无意偶尔候到了后期还会有新的需求添加进来,还有些需求在交付内部测试版本之后又发明原本的需求本身就存在缺陷,之后再次返工,在软件终极宣布之前,怎么可能确定的下来呢。啊,这些都是让我们的开拓职员和测试职员极其头痛的工作。到底应该如何在频繁变化的需求中确定哪些部分是我们在某个阶段要测试的内容呢?或者说经由过程什么样的措施可以改良我们上面提到的那些问题呢?

一个实际的做法便是实现软件需求的版本化节制。

既然说到了这里,就不免要说些题外话。笔者不停都觉得软件需求是开拓事情和测试事情在拟订计划、开展事情时所合营参照的泉源和依据,而我们只有在泉源上节制好,才能包管下面事情的平稳开展。

假如盼望某个阶段事情的进度和内容可以明确的定义下来,就必须要斟酌软件需求的版本化节制。这里所提到的“软件需求的版本化节制”,是指在一个软件产品的生命周期中,当要进行一个新版本的迭代时,要尽早切实着实定这个版本中将要实现的需求,并同上个版本做出对照,哪些内容是新增的,哪些内容是被调剂过的。在该阶段事情开始之初的事情会议上,明确的向所有必要懂得软件需求的涉众传达这部分信息。而假如在该版本的开拓历程中赓续的呈现需求变化的环境,则应该根据市场策略、已公布的宣布光阴、客户需求、实现的价值、难易程度以及对现有事情的影响等方面,对需求进行适度划分,严格定义当前版本中必要实现的需求,而其他部分,则作为未来版本的软件需求进行斟酌。

假如有的同伙觉得上面的内容照样太理论化,必要一个更实际的、可操作的措施。那么只能说,对付需求的变化,以及由于需求变化而引起的设计的变化,必须要早发明,早评论争论,早抉择,早调剂。这可能更多的要寄托一个团队中相关认真职员的主动事情来包管,而不是寄托一个明确的措施。

留意,这里的一个关键是,对付软件需求,同样必要严格按照版本进行治理,或者说使

用“基线”进行治理。

若何收拾测试需求?

一旦当前阶段测试事情的范围确定下来,我们就可以开始斟酌测试需求的收拾——也就

是明确的定义现阶段要“测什么”。测试需求切实着实定将为我们拟订进度光阴表、分配资本以及若何确定某个阶段测试事情是否完成供给一个可供衡量的标准。当然,还有更紧张的一点,已被确定的测试需求是我们进行测试用例设计和斟酌测试覆盖的依据。

收拾测试需求的第一步,便是要“测试需求”。

测试需求?对,不知道您是否想到,这里的“测试需求”中的“测试”是一个动词,指

的是对软件需求本身的反省。

啊?这不是已经越过了测试事情的范围了吗?测试职员不是应该只关心软件的实现同需求是否切合吗?这样对测试职员要求不免难免太高了。——这是笔者以前同一些同伙谈到测试职员必须对需求进行反省时听到的一些不合的声音。

在这里,首先要明确一个问题,便是软件测试的事情到底做什么?

在《软件测试》( Ron Patton〔美〕,中文版由机器工业出版社出版,这本书是测试新手入门的经典课本)一书的第10页,有一个明确而简洁的定义:软件测试员的目标是找到软件缺陷,尽可能早一些,并确保其得以修复。

瞧!这里说要“尽可能早”的“找到软件缺陷”。那这“尽可能早”要早到什么时刻呢?

不知道大年夜家对《软件工程》这本书还有什么印象。至少在笔者看过的多个不合版本的软件工程方面的书中,对付软件缺陷都邑有一段类似的描述:缺陷发明的越早,则修复这个缺陷的价值就越小,在需求、设计、编码、测试、宣布等不合的阶段,发明缺陷后修复的价值都邑比在前一个阶段修复的价值前进10倍(拜见下图)。这样看来,上面问题的谜底自然就变成了“秃子头上的虱子”:从需求阶段开始!从“测试需求”开始!

留意,笔者这里的不雅点并不是说可以取消团队中的“需求评审会议”,这里并不存在冲突。笔者所盼望讲述的,是测试职员应该若何看待软件需求,而并不是把“需求评审会议”所承担的责任揽到自己身上。

在论坛上也有时看到有的同伙问:若何测试需求呢?每次看到这样的提问,笔者心坎就禁不住的一阵激动,由于不停以来,评论争论这方面问题的同伙切实着实少之又少。在笔者的实际事情中,对软件需求的反省包括两个方面的内容。

一是对软件需求精确性的反省,也便是要包管需求文档中所描述的内容是真实靠得住的。在进行这部分事情时,不要迷信所谓的“都是用户提出的真实的需求”,由于我们必须斟酌,提出这些需求的涉众,是否真的可以精确的描述自己的需求?我们的需求职员是否真的可以精确的理解用户的需求?有没有一些被用户觉得在营业处置惩罚上是天经地义、极其寻常的工作,而没有作为需求提出来?有没有一些被用户觉得他们以前应用的软件已经供给了响应的功能,以是觉得我们也该当供给,而没有提出来的?关于这个问题,也曾经有同伙提过不合的见地,觉得这样对测试职员的要求太高了——既要认识需求职员的事情,又要认识软件所涉及的行业的营业。但笔者照样固执的觉得,作为测试职员,照样必要对软件产品所涉及的行业的营业有一个周全的、深入的懂得——当然,这不是对一个刚刚入门的测试者的要求,然则假如想称为一个优秀的测试者,是难免要付出这部分努力的。

二是要包管软件需求的可测试性。对付“可测试性”,笔者的观点是:对付一条软件需求或者一个必要实现的特点,必须存在一个可以明确预知的结果,并且可以经由过程设计一个可以重复的历程来对这个明确的结果进行验证。说的详细一点,便是要包管所有的必要实现的需求都是可以用某种措施来明确的判断是否相符需求文档中的描述。假如对付某条需求或某个特点,无法经由过程一个明确的措施来进行验证,或者无法预知它的结果,那么就意味着这条需求的描述存在缺陷,应该请需求职员对需求文档进行改动或弥补——我们有来由信托,假如作为测试职员对需求无法孕育发生准确的理解,那么开拓职员也同样无法对同一条需求孕育发生准确的理解。对付一条确定的软件需求理解的二义性,是在不规范的开拓历程中导致返工的一个主要缘故原由。假如觉得有需要,那应该在“需求评审会议”上确认所有涉众对需求的理解是同等的。

当然,对付若何前进软件需求的质量,在收集上或者已经出版的书刊中都已经有了很多

加倍详细、实用的措施,假如有兴趣,大年夜家也可以找来参考。不过,假如您是一位测试者,那么上面这部分内容对您仍旧是异常有用的。信托您只要在事情中进行考试测验,逐步的体会,必然会发明这种措施给您带来的好处。

现在当前的测试事情范围已经确定,响应版本的软件需求也经由过程了评审,我们就可以在

这个已经确定的范围内进行测试需求的收拾。我们手头上可以参考的器械,平日会有软件需求规约(以下简称SRS)和用例(以下简称UC)——当然,也可能是一份包孕UC的SRS。经由过程对SRS和UC的涉猎,我们可以从文档对特点和营业流程的描述中得到对软件所涉及的营业的一个基础的熟识。比如用户在处置惩罚实际营业时都要作些什么,多个营业之间的先后顺序是如何的,用户在处置惩罚营业是对付哪些地方有特其余要求,等等。这部分规则,将成为我们的测试需求中最基础的一部分。

至于测试需求的体现形式,笔者觉得大年夜家都可以根据自己的必要进行设计,而没有需要把思路限定在到底应用表格要领照样应用文本要领,只要把握一个原则就行了:在一条测试需求中,用轻易理解的自然说话,明确的描述一项必要测试的内容。对付多项测试内容,应尽可能的剥脱离来,包管一条测试需求只包孕一项测试内容。

别的,大年夜家也可能留意到了,在软件开拓历程的这个阶段,平日是没有用户界面(以下简称UI)可供参考的——虽然RUP中对付需求阶段的事情描述包括了UI设计的部分,但很多时刻在这个阶段照样无法供给一个确定的UI的——也便是说我们这时得到的测试需求,将是完全基于营业的,而并不包括基于UI的那部分规则,是同软件的终极详细实现相自力的。

跟着开拓事情的继承,开拓部门的架构设计文档和具体设计文档也将陆续提交,这时刻,我们可以根据设计文档来对已有的测试需求进行补充。留意,这里我们对付设计文档中提到的内容要有选择的采纳,只有同SRS或UC中已经定义的部分切合的内容,才可以用来调剂我们的测试需求。而同软件需求不切合的部分,则必要同设计职员和需求职员一路评论争论,确定下以哪一方作为基准,抉择是否必要调剂软件需求,然后对测试需求进行响应的补充或者调剂。比如对付一些算法,必要斟酌设计文档中定义的,同系统实现相关的那些谋略公式,是否同软件需求中描述的算法表达的是否是同一个意思?而对付一些约束或者营业规则,设计文档中描述的是否同需求中的响应部分同等?

呵呵,看完上面这部分内容,生怕又有一部分同伙晕倒在地了,而没有晕倒的那部分同伙也要提出异议:啊?!你这不是又包孕了对开拓职员所作的设计事情的反省吗?!刚刚让我们反省需求,现在又让我们反省设计,真的把我们当玉成才了!

没法子,为了让软件交到我们手上的时刻只包孕只管即便少的缺陷,大年夜家只能再费力一下了。我们的事情不该当仅仅限定在软件交付后尽力找到存在的缺陷,而更应该努力赶早发明软件缺陷呈现的苗头,只管即便预防缺陷的呈现。

虽然并不是说在所有的团队中都应该由测试职员承担“测试需求”和“测试设计”的事情,然则测试职员对这些事情起到的感化,是其他团队中的其他角色所无法替代的。

开拓部门完成编码实现事情,提交供内部测试的利用法度榜样时,测试职员手头上应该已经筹备好了绝大年夜部分测试用例和测试数据,测试部门将开始履行测试。平日在我们履行测试的历程中,纵然我们已经从“经由过程测试”和“掉败测试”两个不合的角度筹备了异常充分的测试用例和测试数据,但老是有些缺陷的呈现是出乎我们料想的,或者说是已有的测试需乞降测试用例未能覆盖的。那么,对付这部分缺陷,也该当添加到测试需求中,并设计响应的测试用例,以便于下次版本迭代时进行参考。

OK,信托说到这里,各位看客也应该可以理解我的不雅点了:对付一个经久成长的团队或者持续开拓的产品,它的所有器械都是要赓续积累的、赓续迭代的。无论对付软件需求照样测试需求,不仅仅是在一个版本的开拓历程中,在不合的阶段进行迭代,在产品的全部生命周期中的不合版本间,也是赓续迭代和积累的。

关于测试用例

什么时刻开始设计测试用例?

测试用例该怎么写?

什么时刻算是完成了测试用例的设计事情?

上面几条可以算是收集上测试用例设计方面最热的问题,而且每隔一段光阴就会被不合的人从新提起。提问的有刚刚进入测试行业的同伙,也有事情一段光阴后从新陷出神茫的“熟手在行”。这几个问题看似简单,可是要想回答的让大年夜家都认为知足,还真是不轻易。这样的高难度,笔者也不敢有太多的奢望,照样把自己的履历写出来,盼望对大年夜家有些参考代价吧。

测试用例是为特定目标开拓的测试输入、履行前提和预期结果的聚拢。这些特定目标可所以:验证一个特定的法度榜样路径或核实是否相符特定需求。——这是RUP中关于测试用例的定义。而在实际事情中,对付测试用例的设计和选择,是考察一个测试职员事情能力和履历的最好措施。

假如您像笔者前面说的那样,已经在事情中开展了测试需求的收拾事情,那么测试用例的设计事情就会变成一件自然而然的工作了。假如您在需求阶段就开始了对测试需求的收拾,那么当这部分测试需求收拾完后,就可以开始响应测试用例的设计了。而跟着开拓事情的继承,在测试需求被赓续的补充、调剂后,也应该添加或改动响应的测试用例,以包管测试用例的有效性。这里笔者要分外强调一点:测试用例的完成并非是一劳永逸的,由于测试用例是滥觞于测试需求,而测试需求的滥觞包括了软件需求、系统设计、具体设计,以致包括了软件宣布后,在软件产品生命周期停止前发明的所有软件缺陷。滥觞的多元化注定了测试需求是异常轻易发生变更的。一旦测试需求发生变更,则测试用例必须从新掩护。

假如您对付软件开拓的迭代措施对照认识,那么就可以对测试用例的设计采纳同样的措施。而终极的结果,是您的团队将徐徐拥有越来越周全细致的测试需乞降测试用例库,测试职员越来越多的精力,可以放到对测试历程的斟酌和测试用例的选择方面。

至少在笔者的实践中,这种措施虽然前期必要相对大年夜量的投入,但跟着光阴的迁移,在没有应用自动化测试对象的环境下,同样大年夜大年夜前进了每个测试职员单位光阴内测试事情的效率。

关于设计测试用例的措施,无论是在已经出版的专业测试册本照样收集上的专业测试论坛中,都已经有了很多异常好的文章来专门解说,笔者也不盘算占用太多篇幅从新引用,大年夜家假如有这方面必要,经由过程收集都可以很轻易的找到这些资料。在这里,笔者只是想简单的评论一下很多初学者对这些措施轻易孕育发生的误解。

信托对付任何一个测试职员来说,等价类划分法和界限阐发法都是最早打仗,也是最基础、最轻易应用的测试用例设计措施。很多同伙也都知道先应用等价类划分法划分出等价类,然后应用界限阐发法确定测试必要的界限值。然则很多同伙也提到,在事情了一段光阴后,发明这两中措施所能利用的地方越来越少,难道这两种措施真的只能利用在反省编辑框输入类型和输入长度的时刻吗?当然不是。对付一些刚刚打仗测试事情的同伙提出的这个问题,笔者觉得现在市道市面上的很多测试册本都要承担很大年夜的责任。比如许多书中,在讲到测试用例设计时,都不约而合的应用同一个例子——Windows谋略器法度榜样。平日是奉告你对付谋略器有一个容许的输入范围(比如容许输入一个大年夜于0小于即是100的整数),然后要求设计响应的包孕合法数据和分歧法数据的测试用例。当然,仅仅是这样一条简单的描述,我们已经可以设计出很多测试用例和测试数据了,比如对付输入范围的斟酌,对付输入数据类型的斟酌,对付输入长度的斟酌等等。然则在我们的实际事情中,很多时刻看到的并不是这样过于简单的软件需求描述,很多时刻这些内容都是隐含在一些算法或营业规则中的。

我们现在举个例子来看一下:

“双倍余额递减法是在不斟酌固定资产残值的环境下,以匀称年限法折旧率(不扣残值)的两倍作为折旧率,乘以每期期初固定资产折余代价求得每期折旧额的一种快速折旧的措施。

年折旧率=2÷估计应用年限×100%

月折旧率=年折旧率÷12

月折旧额=期初固定资产账面净值×月折旧率

为了包管固定资产应用年限终了时账面净值与估计净残值相等,在该固定资产折旧年限到期的前两年,将固定资产净值扣除估计净残值后的余额匀称摊销。”

上面的内容是我国现行财务轨制中关于固定资产折旧的一种措施——双倍余额递减法——的详细算法,大年夜家可以在任何一本管帐书中找到这部分内容以及一些响应的例子,不过我们这里并不关心固定资产的折旧到底是怎么一回事。笔者想知道的是大年夜家在看完上面的描述后是否已经发明,我们在设计测试用例时,对付筹备进行折旧的固定资产,至少应该包括估计折旧年限小于两年、即是两年和大年夜于两年三种不合的类型。这也应该算是一个等价类划分法和界限阐发法的利用吧。

实际上,制约我们更好的应用这些测试措施来进行测试用例设计的,并不是措施的利用范围不敷宽广,而是由于假如我们不能对这些同实际营业相关的详细算法或营业规则进行深入的阐发,就弗成能掘客出深层的测试需求,那么这两种措施的利用也就很有限了。这也是笔者在前面频频强调加深对软件需求懂得的缘故原由。

对付收集上也有评论争论的别的两种措施——差错推设法主见和因果图法,则分手由于靠得住性较差和操作相对繁杂而并没有获得广泛的利用。

若何划分测试用例的粒度?

我们是不太可能在一个测试用例包孕所有测试需求的,由于浩繁的功能以及不合的路径

组合将使这样一个测试用例像巨无霸一样平常,完全不具有可操作性。——除非您的软件所包孕的功能真的又少又简单,不过假如然的有这么一个软件,生怕也没有测试和宣布的需要了。

当然,这也并不是要您走向另一个极度,为需求中定义的每个特点或功能都供给一个以致多个测试用例。这里的关键,是要探求一个相宜的度。

笔者保举的措施是:关注有效功能。

有效功能:便是指在被测利用所涉及的实际营业中,当用户在手工状态下进行事情时,全部营业流程中对用户来说,具有实际意义那些功能。这个功能的特性是当我们把这个功能零丁从谋略机软件还原到用户的原始手工状态时,它的完成可以作为用户实际营业的一个阶段性停止的标志,而不是一旦从这个营业流程中自力出来就掉去了意义。而该营业完成后,可以为其他用户或营业供给所必要的信息。

这里区分“有效功能”的关键有如下两个:

1. 这个功能是可以还原到用户原始的手工营业流程中去的。我们的谋略机和软件,都是为了赞助用户办理手工营业中一些啰嗦和低效的问题,而提出的一些忠厚于原始事情措施或略有变通的办理规划,并不是要改变用户整个的营业流程。以是,应该从用户实际营业的角度来判断功能是否有效。

2. 这个功能是否可以标志着用户实际营业的一个阶段性停止?并且这项营业完成之后,被完成的营业实体是否可以交付给其他用户或营业以供完成下面的事情?

为了方便理解,我们可以先看一下下面的例子。

拿我们常见的财务软件来说,当添加一张管帐凭据时,平日是必要填写管帐科目,在应用谋略机完成事情时,我们可以使用软件的功能,从很多备选科目中选择一个自己必要的科目,或者经由过程科目代码来输入科目。这项功能很有可能会作为一个特点要求呈现在软件需求规格阐明书中,那么这个科目的选择或输入是不是一个有效功能呢?让我们试着用上面规则来衡量一下。

首先,这个功能在用户手工营业处置惩罚历程中是存在的,不合的是这项功能是在用户填写凭据时,在自己的大年夜脑中完成的——用户会根据必要,在自己影象的科目中选择相宜的填写上去,这项功能节省了用户在影象大年夜量管帐科目时付出的额外劳动。我们可以觉得这个功能是为用户原本的事情供给了一种简便的、变通的措施。

那么这项功能的完成对付用户来说意味着什么呢?我们从上面的描述中可以看到,用户盼望软件供给的是可以添加一张完备的凭据这样的功能,而不仅仅是方便填写管帐科目。填写管帐科目只是用户在添加凭据时的一个步骤,零丁把这个功能提掏出来对用户来说没有任何实际意义。对付营业流程下流的用户,必要的也不仅仅只是一个管帐科目的信息,而是一张包孕了管帐科目以及其他管帐信息的完备的管帐凭据,否则就无法进行下面的事情。这样看来,这个功能并不是一个有效的功能,我们可以把它最为必要测试的特点在测试需求中进行描述,却不应该作为一个零丁的测试用例呈现在我们的测试用例集中。而我们在测试用例中真正关注的,应该是添加管帐凭据这个具有实际意义的功能。

别的,我们还必要关注若何将多个互相之间存在依附关系的功能区分为单个的有效功能。例如,现在有A、B、C三个功能,此中B功能的开始必须依附于A功能的完成,而且A功能假如呈现不合的完成状态,B功能也会做出不合的反映;C功能对B功能的依附也是如斯。那么这时刻,我们是否该当将三个互相依附的功能包孕在一个测试用例中呢?这样的做法也不是弗成以,然则我们也可以先判断一下,这三个功能是否都是有效功能(您可以应用前面提到的措施来试着评判一下)?假如A、B、C都是自力的有效功能,那么我们可以从上面的描述中发明,它们之间存在的依附性,可以理解为是一种状态或者说数据的依附性。后一个功能关心的,是前一个功能终极供给给它的是什么样的“输入”,而不是前一个功能到底作了些什么。这样看来,我们完全可以将它们分手包孕在几个自力的测试用例中,而在每个测试用例的开始,把不合的输入作为不合前置前提来描述。

测试用例是否应该包孕所有的细节?

这是在收集上听到抱怨最多的又一个热点问题:公司要求按照一个严格的规范来开展测试事情,必须书写所有的测试用例文档,要求文档的书写必然要详细,并在履行测试时要参考测试用例文档来进行。假如测试用例文档写的过于大略,则会被引导斥为偷懒。然则,假如文档中的对操作步骤描述的过于详细,像下面这样:

01. 在“用户名”项中输入“user”;

02. 在“密码”项中输入“password”;

03. 点击“确定”按钮。

这样的描述要领外面看起来可操作性彷佛是增强了,任何人拿到这个文档都可以充当测

试职员,反省一下这个功能是否存在缺陷。然则我们不要忘怀,在开拓历程中,变化的存在是一定的。一旦需求、设计或者利用法度榜样中的某些细节发生了变更,比如“用户名”变成了“操作员”,“密码”变成了“口令”,“确定”变成了“登录”,或者输入项所吸收的数据类型发生了变更,那么同这部分内容相关的所有的测试用例都必要改动。否则,我们凭什么可以包管这些描述不合的测试用例说的是同一样器械?假如我们只有这么一个测试用例,大概统统都不是问题,然则对付一个营业繁杂、功能完备的系统,假如按照这样的措施描述测试用例,终极要么孕育发生大年夜量的测试用例文档,要么孕育发生过长的单个文档。无论是那一种,假如发生了类似于上面说的变更,掩护文档都将变成一次地狱式的体验。

这也是为什么在收集上几回再三呈现的这个问题,而且每次呈现都邑受到测试同业们的关注的缘故原由。那么这个问题应该任何办理呢?测试用例是不是把所有的流程写出来就可以了呢?若何在削减测试用例文档中包孕过多啰唆的细节的同时包管测试用例的可操作性呢?又有什么措施可以前进我们掩护测试用例文档的效率呢?

笔者的建议是:关注“测试思惟”而不是关注操作步骤。

要理解这个问题,首先要弄明白测试用例的感化。

就像用例一样,测试用例并不是用来描述详细的实现的,而是着重描述处置惩罚问题的思路——对付一项明确的测试内容进行测试的思路。作为测试用例的设计职员,若何理解基础流和备选流?若何深入阐发并找到所有必要覆盖的路径和必要反省的特点?我们在测试用例中应该用轻易理解的自然说话清晰的来描述我们将要若何进行测试,而不是简单的把在利用法度榜样上若何操作的啰嗦的步骤记录下来。把测试用例设计当成填写详细操作步骤的表格是人们对测试用例最大年夜的误解。

传统的测试用例文档编写有两种要领。

一种是填写操作步骤列表:将在软件长进行的操作步骤一步一步具体的记录下来,包括所有被操作的项目和响应的值。

另一种是填写测试矩阵:将被操作项作为矩阵中的一个字段,而矩阵中的一条笔记录,则是这些字段的值。

收集上对付这两种要领孰优孰劣的争辩,将大年夜家差错的向导向了两个极度:要么采纳A,要么采纳B。而大年夜家却漠视了一点,对付事情措施的争辩,本色上同对象的争辩并不是一回事(例如曾经的VC、BCB之挣)。假如不合的措施各有上风,我们完全可以经由过程变通的措施,把上风的部分组合在一路来应用。

操作步骤列表的上风在于对基础流和备选流进行阐发后,它可以清晰的描述您的测试思路。而测试矩阵则更得当于用来寄放测试数据,分外是那些必要人工付与一个确定的值的特点。

下面,我们来看一个例子,当然,这个例子同样是诬捏的。

需求名称:用户登录安然验证

需求描述:用户登录安然验证是为了包管所有登录到系统中的用户,都是由系统治理员预先在系统中设定的。应用系统中不存在的用户名,或者用户名输入精确,但密码输入差错环境,都无法登录到系统中。当用户应用了不存在的用户名或差错的密码时,系统应分手给出适当的提示。假如用户继续三次无法应用精确的用户名和密码登录到系统,则系统应给出适当的提示,并退出当前法度榜样。假如用户应用精确的用户名和密码登录到系统,则退出界面,转到系统主界面。对付用户登录界面和法度榜样主界面,请参考响应的UI设计文档。

测试需求:

01. 反省能否应用精确的用户名和密码登录到系统;

02. 反省能否应用差错的用户名或密码登录到系统;

03. 反省应用差错的用户名和密码登录掉败跨越三次,是否会自动退出当前法度榜样。

测试用例:

序号

操作历程描述

1

输入用户名。

2 输入密码。

3 确认登录。

序号 用户名 密码 预期结果

1 精确的用户名 精确的密码 登录到系统并转到系统主界面

2 精确的用户名 差错的密码 无法登录到系统并提示密码差错

3 差错的用户名 精确的密码 无法登录到系统并提示用户名差错

4 差错的用户名 差错的密码 无法登录到系统并退出当前法度榜样

5 空用户名 …… ……

这个例子并不是按照RUP供给的标准模板编写的,它的目的只是要为大年夜家展示,用前面所讲的措施,收拾出来的测试需乞降设计完成的测试用例到底是个什么样子。以是省略了很多细节,不过大年夜家在实际编写测试用例文档的时刻,可以根据自己的必要把响应的内容添加上去。同时,也可以在用户名和密码两个字段中填写筹备应用的详细数据。

信托大年夜家已经看到,在我们的例子中,测试需求同测试用例之间并非是逐一对应的关系由于一条测试需求未必是明确的对应到一个有效功能的(着实测试需求本身同软件需乞降用例之间也未必是逐一对应的)。而我们的测试用例所关注的,应该是一个有效功能。不过您不用担心,这种环境并不会增添您治理测试需乞降测试用例的资源,现在市道市面上供给的测试对象中已经有些是专门用来掩护软件需求、测试需求同测试用例之间的关系的,并且它们供给的强大年夜的视图功能还可以让您很轻易的查看到测试用例对测试需求的覆盖环境。

对付例子中的测试用例文档,已经被分成了两个部分,一部分是描述了测试用例履行者所应遵照的操作历程,一部分则是在操作中必要应用到的测试数据。这样做的缘故原由是在我们的实际事情中,尤其是在进行功能测试时,很多时刻都是应用雷同的操作历程和不合的测试数据来进行的。而应用上面的措施,可以不用再对蓝本在多个用例中重复呈现的操作历程再次描述,而可以把更多的精力放到测试数据的设计和筹备上。这样作带来的副产品,便是前进了测试用例的可掩护性。

怎么?还有人对笔者的不雅点持狐疑立场?那好吧,那么我们来考试测验着证实一下。

我们的邮递员要在5个城市内驱驰,并且每个城市都有些邮件必要送达,他必要找到可以一次走遍5个城市的所有路线。这听起来彷佛并不是太繁杂,使用我们已有的数学常识,很轻易就可以获得谜底。然则对付我们要测试的内容,平日都邑包孕更多繁杂的规则。

例如,我们有三个文本框,每个文本框每次都只能输入一个英文大年夜写字母,容许输入的值只包括:A、B、C三个字母,当三个文本框输入不合的值的时刻,我们不知道会发生什么,也不知道它们之间是否会相互影响,以是必要您来设计可以覆盖所有输入环境的测试用例来测试它。

瞧,这很简单不是吗?假如我们盼望每个测试用例在履行时一旦呈现缺陷都可以很快的找到导致缺陷的缘故原由,那么最好的法子便是每个测试用例只包括一个同其他测试用例不合的输入值。那么可供我们输入的值都有哪些呢?嗯,对付每个文本框,都至少有A、B、C三种已经声明的不合的值,别的,我们还要斟酌当文本框为空、输入空格、输入非英翰墨符以及输入A、B、C之外的英翰墨符的环境。那么按照上面的措施,我们会有若干测试用例呢?谜底是343个。这只是一个很简单的例子,我们事情中碰到的软件的营业规则和特点决不会比这少的,那会有若干个测试用例呢?God knows. 不过至少有一点可以肯定,我们无法在原有营业规则发生变更时高效的、完好点的掩护完343个测试用例。

然则假如应用我们前面所描述的措施,对付操作历程的改变,您只必要从新掩护一次,而对测试数据的掩护,也同样是异常简单的,而且并不会由于继续大年夜量改动时呈现的差错导致测试用例本身呈现歧意。

在将主要精力从“设计”操作步骤转移到设计测试数据之后,我们还将从这种措施中得到更大年夜的益处——经由过程“逆向测试数据阐发”来前进测试事情的整体效率。

这种“逆向测试数据阐发”的措施,是假设软件中存在多个相互依附的功能,而且这些功能中包孕在“依附链”最末尾,并且不再被其他功能依附的功能。

在我们筹备测试数据时,首先从这个“依附链”最末尾的功能开始,阐发这个功能会对不合的输入孕育发生哪些不合的结果。然后将所有的输入进行收拾,分清哪些输入是滥觞于其前一个功能的输出。之后,对该功能的上一个功能进行同样的阐发,收拾出所有的输入和输出,然则这个功能的输出至少应该包孕“依附链”最末尾功能接管到的整个输入。

继承按照这样的思路轮回向上,直达到到“依附链”开始真个功能。

不知道您在事情中有没有碰到这样的环境:在对那些“依附链”上的功能进行测试时,一开始并没有严格的规范测试数据的应用,结果前一个功能测试时孕育发生的数据根本无法鄙人面的事情中被很好的使用起来,反而由于大年夜量无效数据增添了后面功能的测试难度。终极不得纰谬每一个功能从新筹备测试数据。大年夜量的光阴,挥霍在了这些重复而低效的劳动上。

当然,假如盼望可以进一步前进某个阶段测试事情的效率,还可以斟酌利用“设计测试历程”的措施。这里所说的测试历程,指的是我们在履行测试时所设定的履行测试用例的先后顺序。之以是这样作,是由于可以充分的使用不合功能之间的耦合性,只管即便经由过程一次操作来反省只管即便多的内容,从而低落已完成事情的无效性或低效性,终极前进某个阶段的整体事情效率。不过,这项事情同样要求操作者必须对被测的系统所涉及的所有营业以及这些营业之间的关系都异常认识才行。

假如您正被测试事情的低效问题所困扰,那么建议您考试测验一下上面的措施,盼望会对您的事情有所赞助。

若何评价测试用例的短长?

这部分内容的呈现,完全是由于不久前同几个同伙的一次评论争论。当时大年夜家都觉得对付一个测试用例短长的评价,无外乎两个标准:是否可以发明尚未发明的软件缺陷?是否可以覆盖整个的测试需求?然则后来发明这两个标准对付一些问题是处置惩罚不了的。例如,对付一个质量异常好的软件产品,存在的软件缺陷异乎平常的少,测试用例设计职员筹备了大年夜量的测试用例,已经完全覆盖了测试需求,然则只有很少一部分测试用例在履行时发清楚明了缺陷,而其他用例都顺利经由过程了。那么是否就可以觉得顺利经由过程的那部分测试用例不好呢?

对付这个问题,笔者觉得不管是测试用例是否可以发明尚未发明的缺陷,照样测试用例对测试需求的覆盖度,都是用来评估测试设计职员事情能力和履历的标准,而对付若何评价测试用例的好坏,应该还有其他标准。当然,在不合的团队中可能存在不合的标准,但下面两条应该是得当于任何团队的。

1.易用性。对付一个即认识测试事情,又认识被测利用的测试职员,该当可以花费

很少的光阴就可以理解测试用例中表达的测试思路,并可以很快的履行完这个测试用例。

2.易掩护性。当开拓历程中的某些身分影响了测试需求,测试用例的作者或其他测试设

计职员,应该可以花费很少的光阴就完成定位并掩护所有相关测试用例的事情。

一些题外话

曾经有同伙问:假如测试用例同软件的详细实现相互自力,怎么包管测试用例的可操作性呢?怎么包管任何一小我都可以一拿到测试用例就可以直接上机履行测试呢?笔者的回答是:只管即便不要让这种工作发生。

首先,笔者不停不附和那种让“任何人”都可以充当测试职员,按照手中测试用例履行测试的做法。由于对付被测利用的周全懂得和认识,是作为一个测试职员最基础的要求——在前面的翰墨中对付软件需求的认识也多次被强调。我们无法预知让一个对软件以及软件所涉及的实际营业不敷认识的人,寄托一份他同样不认识的操作步骤列表来履行测试会有什么样的结果。然则有一点可以明确,这就似乎让一个没有医学背景的人,仅仅寄托一本七年制本硕连读的《内科学》课原本为患者反省是否患有心脏病,最遣散果是患者承担了整个的风险。

其次,测试用例的原先目的是为了描述我们的“测试思惟”——也便是“如何测”,而是否可以纯熟的操作被测利用,并不是在测试用例这个“工具”中所要斟酌和包管的,该当剥离出来,作为自力的部分进行处置惩罚。而问题的关键,在于若何包管拿到测试用例的人有足够的能力和履历来履行测试,这完全可以经由过程公司内部对软件及软件所涉及的实际营业的培训,或者软件的操作手册。总之,照样只管即便不要随意的加入“任何人”到测试事情中吧。

作者简介

收集ID :jackei,经久生动于“测试期间”、“中国软件测试社区”、“51testing”、“51CMM”、“CSDN”等测试网站和测试论坛。《测试期间期刊》杂志责任编辑及撰稿人。

学院派测试职员,坚信“实践是查验真理的独一标准”。否决学术腐烂、造假。坚信做一个好的测试职员,首先要为人端正、诚笃、严谨、耐心、乐于助人。现供职于广州某软件公司,从事软件测试事情,致力于测试历程改进和测试根基理论方面的钻研。

对付本文中已经包孕的以及还未包孕的内容,假如必要评论争论,您都可以应用E-Mail:jackei_chan@hotmail.com 同笔者联系。

您可能还会对下面的文章感兴趣: