软件测试实践手册

测试作业指导书

基础篇...........................................................错误!未定义书签。

001.什么是软件缺陷(BUG).........................................................................错误!未定义书签。

002.影响软件质量的原因........................................错误!未定义书签。

003.提高软件质量11勺措施........................................错误!未定义书签。

004.软件测试的)目的I与定义.....................................错误!未定义书签。

005.软件测试中的原则..........................................错误!未定义书签。

006.怎样成为一种好的软件测试员...............................错误!未定义书签。

007.软件测试时阶段划分........................................错误!未定义书签。

008.测试用例的设计措施........................................错误!未定义书签。

01.测试用例的特性：.........................................错误!未定义书签。

02.测试用例的设计原则......................................错误!未定义书签。

03.等价类划分措施...........................................错误!未定义书签。

04.边界值分析措施...........................................错误!未定义书签。

05.因果图措施..............................................错误!未定义书签。

06.鉴定表驱动分析措施......................................错误!未定义书签。

07.功能图分析措施...........................................错误!未定义书签。

08.场景设计措施.............................................错误!未定义书签。

09.测试用例设计综合方略....................................错误!未定义书签。

10.测试用例的设计环节......................................错误!未定义书签。

009.软件测试欧I基本方式........................................错误!未定义书签。

01.黑盒测试................................................错误!未定义书签。

02.白盒测试................................................错误!未定义书签。

03.静态测试................................................错误!未定义书签。

04.动态测试................................................错误!未定义书签。

010.软件测试的基本措施........................................错误!未定义书签。

01.过测试和失败测试.........................................错误!未定义书签。

02.等价类划分..............................................错误!未定义书签。

03.数据测试................................................错误!未定义书签。

04.状态测试................................................错误!未定义书签。

05.其他黑盒测试措施.........................................错误!未定义书签。

实践篇...........................................................错误!未定义书签。

001.测试流程图...............................................错误!未定义书签。

002.测试准备.................................................错误!未定义书签。

003.怎样做好式样理解..........................................错误!未定义书签。

004.有关测试用例口勺设计........................................错误!未定义书签。

005.测试数据的准备............................................错误!未定义书签。

006.测试时实行...............................................错误!未定义书签。

007.测试过程中口勺变更管理.....................................错误!未定义书签。

008.怎样填写QA票和BUG票....................................错误!未定义书签。

009.文档管理工具(CVS)的使用..................................错误!未定义书签。

010.BUG管理工具(QAMS)的使用................................错误!未定义书签。

基础篇

001.什么是软件缺陷（bug）

1.软件未到达产品阐明书表明H勺功能

计算器日勺产品阐明书也许声称它可以精确无误日勺进行加、减、乘、除运算。假如按下加号

（+）键，成果什么反应也没有，根据该条规则，这就是个软件缺陷。假如得到错误的答

案，根据规则，同样是软件缺陷

2.软件出现了产品阐明书指明不会出现的错误

产品阐明书也许声称计算机永远不会瓦解、锁死或者停止反应。假如狂敲键盘会使计算器

停止接受输入，根据本条规则，这是一种软件缺陷

3.软件功能超过产品阐明书指明范围

假如我们发现除了加减乘除之外计算器还可以求品方根，而这一功能哪儿都没提。干劲十

足的程序员加入这项功能也许由于觉得这是一项创举，根据本条规则，这是软件缺陷。

4.软件未到达产品阐明书虽未指出但应到达的目H勺

这条规则也许让人感觉有些矛盾和奇怪，不过这样是为了抓住产品阐明书上遗漏之处。在

测试计算器时，会发现电池没电会导致计算机不对"勺。没有人会考虑应怎样应付这种状况,

使计算机反应正常，而盲目认为电池永远充足了电。测试要持续进行到电池完全没电，是

少要看到电力局限性的迹象。产品阐明书指出电力局限性无法对的计算，但未指出会怎样,

根据本条规则，这是软件缺陷。

5.软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终顾客认为不好。

本条规则是全面的。软件测试人员是第1个真正使用软件的人。假如发现某些地方不对劲,

无论什么原因，都要认定为软件缺陷。对于计算器来说，也许觉得按键太小；也许等号（=）

键的位置放得不好按；也许显示屏在亮光下很难以看清，根据本条规则，这些都是碳陷。

注意：每•种使用过某些软件日勺人都会对怎样改善有某些规定和意见。要编写令所有顾客都

喜欢的软件是不也许的。作为软件测试人员，在运用第5条测试规则时应记住这一点。最佳

能全面地客观评价，做到合情合理。

002.影响软件质量的原因

影响软件质量II勺原因诸多，详细地说，重要有如下几点：

1.顾客原因

需求不清；二义性

2.产品阐明书

没有产品阐明书；阐明书不够全面、常常更改

3.设计方案

与产品阐明书是同样的，片面、易变

4.交流不够、交流上有误解或者主线不进行交流

在应用应当做什么或不应当做什么的细节（应用日勺需求）不清晰R勺状况下进行开发

5.软件复杂性

图形顾客界面（GUI）,客户/服务器构造，分布式应用，数据通信，超大型关系型数据库

以及庞大H勺系统规模，使得软件及系统的复杂性呈指数增长，没有现代化开发经验的人很

难理解它。

6.程序设计错误

跟所有日勺人同样，程序员也会出错

7.时间压力

软件项目的日程表很难做到精确，诸多时候需要估计和猜测。当最终期限迫近和关键时刻

到来之际，错误也就跟着来了。

8.自负

自负的人更喜欢说：“没问题”；“这件事很轻易”；“几种小时我就能拿出来”，太多不切

实际的“没问题”成果只能是引入错误。

9.代码文档贫乏

贫乏或者差劲H勺文档使得代码维护和修变化的异常艰苦，其成果是带来许多错误。事实

上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和

轻易理解，相反他们认为少写文档可以更快的J进行编码，无法理解的代码更易于工作的

保密（“写H勺艰难必然读的痛苦”）

10.软件开发工具

可视化工具，类库，编译器，脚本工具，等等，他们常常会将自身的错误带到应用软件中。

就像我们所懂得的，没有良好的工程化作为基础，使用面向对象“勺技术只会使项目变得更

复杂。

003.提高软件质量的措施

1.软件工程化

2.CMM能力成熟度模型CapabilityMaturityModelforSoftware

3.软件测试

004.软件测试的目的与定义

软件测试的目日勺决定了怎样去组织测试，在项目的1不一样阶段，测试时目H勺也不相似。

1.在UT(Unitl^st)阶段，测试日勺目H勺是为了尽量多地找出错误，那么UT阶段测试就应当直

接针对软件比较复杂的部分或是此前出错比较多的位置。在此阶段，可以引用GrcnfordJ.

Myers在《TheArtofSoftwareTesting》一书中的观点:

>软件测试是为了发现错误而执行程序的过程；

>测试是为了证明程序有错，而不是证明程序无错误。

>好的测试方案是极也许发现迄今为止尚未发现日勺错误日勺测试方案；

>成功的测试是发现了至今为止尚未发现的错误的I测试。

这种观点可以提醒人们测试要以杳找错误为中心，而不是为了演示软件的对的功能。不过

仅凭字面意思理解这一观点也许会产生误导，认为发现错误是软件测试H勺唯一目的，查找不

出错误的测试就是没有价值的，事实并非如此。

首先，测试并不仅仅是为了要找出错误。通过度析错误产生的原因和错误的分布特性，

可以协助项目管理者发现目前所采用的软件过程I内缺陷，以便改善。同步，这种分析也能协

助我们设计出有针对性地检测措施，改善测试的有效性。

另一方面，没有发现错误的测试也是有价值的，完整的测试是评估测试质量的一种措施。

详细而严谨II勺可靠性增长模型可以证明这一点。

2.SI测试阶段的目的是为了给最终顾客提供具有一定可信度的质量评价，那么测试就应当直

接针对在实际应用中会常常用到H勺商业假设。

在这一阶段不仅要验证UT测试的成果，检测出软件自身的缺陷，更重要的是要站在用

户的角度找出我们在软件开发过程中的不合理的地方，最终的FI的是让顾客满意。

对•于软件产品小J不一样角色来说，他们日勺测试目的也是不一样的J。

顾客：通过测试来暴露错误

开发者：通过测试来证明自己开发H勺产品不存在错误

测试人员：找出软件缺陷，尽量早某些，并保证其得以修复

测试从狭义上说，就是：凭借测试用例TestCase一运行程序一发现错误H勺过程。

005.软件测试中的原则

1.完全测试程序是不也许的

在软件测试H勺过程中，想要进行完全测试，找出所有软件缺陷，并使软件臻于完美，实际

上这是不也许日勺，虽然最简朴的程序也不行，重要有如下4个原因：

•输入量太大

•输出成果太多

•软件实现途径太多

•软件阐明书没有客观原则。从不一样的角度看，软件缺陷的原则不一样。

2.软件测试是有风险的行为

正由于完全测试程序是不也许的J,那么在测试的过程中必然会对某些你认为是反发的J

或者没必要的或者为了节省时间，而将其提出，假如决定不去测试所有的状况，这就是选

择了风险。既然不也许做完全测试，那么这种风险就是无法防止的了。软件测试员要学会

的一种重要原则就是怎样把无边无际的也许减少到可以控制的范围，以及怎样针对风险制

定做出明智抉择，去粗存精。

3.测试无法显示潜伏的软件缺陷

软件测试工作与防疫员的工作极为相似，可以汇报已发现的软件缺陷，却无法汇报潜

伏的软件缺陷。你可以进行测试，查找并汇报软件缺陷，不过不能保证软件缺陷所有找到。

唯一的措施是继续测试，也许还会找到某些。

4.找到的软件缺陷越多，就阐明软件缺陷越多

一般，软件测试员在没有找到软件缺陷之前拼命地揣摩。找到一种之后，就会接二连

三地找到更多。其中的原因是：

•程序员怠倦。和我们大家同样，程序员也要休假。编写一天代码还不错，第二天就

会烦躁不安了。•种软件缺陷很也许是泄露附近有更多软件缺陷日勺信号。

•程序员往往犯同样的J错误。每个人均有偏好。一种程序员总是反复犯下自己轻易犯

的错误。

•某些软件缺陷实际上是大劫难的征兆。软件的设计或者体系常常会出现基础问题。

软件测试员也许会发现某些软件缺陷开始似乎弟无关联的，不过最终才懂得它们是

由一种极其严重的原因导致的。

不过，假如无论怎样也找不出软件缺陷，那么乜有也许是软件通过精心编制，确实

存在很少软件缺陷

5.反更使用相似的J测试会使软件具有抵御力

在测试过程中你会发现通过几种回合的测试之后，该发现的软件缺陷都被发现了，在测试

下去也不会有新的J发现了。这时，软件测试员，需要采用其他新的措施，对程序的不一样

部分进行测试，以找出更多软件缺陷。

6.并非所有H勺软件缺陷都能修复

这规定软件测试员能过进行良好H勺判断，弄清晰在什么状况下不能追求完美。项目小组需

要对每一种软件缺陷进行取舍，根据风险决定哪些需要修复，哪些不要。

不需要修复软件缺陷的重要原因有：

•没有足够的时间。在任何一种项目中，一般是软件功能较多，而代码编写人员和软件

测试人员较少，并且在项目进度中没有为编制和则试留出足够的空间。常常会在不可

更改日勺交付期限内，必须准时完毕软件。

・不算真正的软件缺陷。在某些特殊场所，错误理解、测试错误或者阐明书变更会把软

件缺陷当作附加功能来看待。

•修复的风险太大。修复一种软件缺陷也许导致其他软件缺陷出现；在紧迫的产品公布

进度压力之外，修改软件将冒很大的风险。不去理会未知软件缺陷，以防止出现未知

新缺陷的做法也许是安全之道。

•不值得修复。不常出现的软件缺陷和在不常用功能中出现的软件缺陷可以放过；可以

躲过和顾客有措施防止或防止的软件缺陷一般不用修复。这些都要归结为商业风险决

策。

7.要尽早、不停地进行测试

测试是无穷近日勺，而测试W、J时间又是有限的，因此我们要尽早地开始测试，尽快地找出软

件缺陷，以便减少修复成木。在几种【口I合的测试后来，没有再检测出BIG,不能说程序没

有错误，只能说还没有找到错误，没有人可以找出程序中所有的错误，没有任何软件产品

是完美无错H勺，我们能做H勺只是不停地进行测试.

8.测试用例可以协助我们有效地进行测试

“好H勺测试用例是极也许发现迄今为止尚未发现H勺错误的测试用例”，可见测试用例对在

软件测试中占有很重要的地位，它可以弥补软件测试员在测试时的遗漏、偏差以及经验上

的局限性，给我们的测试提供根据。同步测试用例也是作为向顾客提供的质量保证的重要

根据之一。

9.程序员应防止测试自己的程序

“自负”是影响程序质量的原因之一，程序员测试的目口勺是证明程序的无错，基于这种心

理，程序员是很难测试自己程序中价JBUG的。另首先，程序员在理解式样的时候难免会有

偏差，假如测试自己的程序是很难找出这些偏差H勺。

10.对附和错误U勺测试

软件测试员测试的目的是要找出软件潜在的错误和缺陷，这里的错误和缺陷不仅指软件

自身的错误，还要检测软件对错误的处理能力，因此我们在测试的时候既要准备对的的

数据也要准备错误的数据，一般来说测试错误口勺CASE比对曰勺口勺CASE要多诸多。

11.群集现象

在测试口勺过程中，会发现某些画面BUG尤其多，某些功能会出现BUG群集的现象，因此

要重视这些群集现象，并且及时H勺采用对策。

12.杜绝随意性

软件测试时一定要有测试根据Fl勺，测试人员不能按照自己的想法凭空想象来评判对错。

软件测试员是客户H勺眼睛，是第一次看到软件口勺人，代表客户说话，应力争完美。但力

争完美的同步，最佳能全面地客观评价，做到合情合理。

006.怎样成为一种好日勺软件测试员

目前，大多数企业把软件测试视为技术T.程专业工作。他们意识到在项目组中培训软件测试

员，并在开发过程中初期投入工作可以制造出质量更优的软件。

下面是大多数软件测试员应具有U勺素质：

•沟通能力。--名理想的测试者必须可以同测试波及到的所有人进行沟通，具有与技

术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和顾客谈得

来，又能同开发人员说得上话，不幸日勺是这两类人没有共同语言。和顾客谈话H勺重

点必须放在系统可以对的地处理什么和不可以处理什么上。而和开发者谈相似的信

息时，就必须将这些活重新组织以另一种方式体现出来，测试小组的组员必须可以

同等地同顾客和开发者沟通。

•技术能力。就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试

小组日勺某个组员作出了一种错误0日勺断定，那么他们日勺可信度就会立即被传扬了出

去。一种测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要

做到这一点需要有几年以上的编程经验，前期时开发经验可以协助对•软件开发过程

有较深入时理解，从开发人员口勺角度对口勺啊评价测试者，简化自动测试工具编程时

学习曲线。

•自信心。开发者指责测试者出了错是常有的事，测试者必须对自己的观点有后够时

自信心。假如容许他人对自己指东指西，就不能完毕什么更多的事情了。由于开发

和测试的立场不一样，面对问题的时候测试人员要有自信坚持自己的观点，而不能

轻信开发人员的说法。

•外交能力。当你告诉某人他出了错时，就必须使用某些外交措施。机智老练和外交

手法有助于维护与开发人员的协作关系，测试者在告诉开发者他口勺软件有错误时，

也同样需要一定的外交手腕。假如采用日勺措施过于强硬，对测试者来说，在后来和

开发部门口勺合作方面就相称于“赢了战争却输了战役”。

•风趣感。在碰到狡辩的状况下，一种风趣的批评将是很有协助H勺。

•很强的记忆力。一种理想的测试者应当有能力将此前曾经碰到过的类似的错误从记

忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。由于许多新“现时

问题和我们已经发现的问题相差无几。

•耐心。某些质量俣证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、

识别和分派一种错误。这个工作是那些坐不住的人无法完毕日勺。

•怀疑精神。可以预料，开发者会尽他们最大的努力将所有口勺错误解释过去。测式者

必须听每个人的阐明，但他必须保持怀疑直到他自己看过后来.

•自我督促。干测试工作很轻易使你变得懒散。只有那些具有自我督促能力的人才可

以使自己每天正常地工作。

•洞察力。一种好的测试工程师具有“测试是为了破坏”口勺观点，捕捉顾客观点的能

力,强烈FI勺质量追求，对细节FI勺关注能力。应月的高风险区的判断能力以便将有限

的测试针对重点环节。

•不懈努力。软件测试员总是不停尝试。他们也许会碰到瞬间即逝或者难以重建口勺软

件缺陷。他们不会心存侥幸，而是尽一切也许去寻找。

•发明性。测试显而易见口勺事实，那不是软件测试员。他们口勺工作是相处富有创意甚

至超常H勺手段来寻找软件缺陷。

•追求完美.他们力争完美，不过懂得某些无法企及时，不去苛求，而是竭力靠近目

的。

•判断精确。软件测试员要决定测试内容、测试时间，以及看到的问题与否算作真正

的缺陷。

•说服力。软件测试员找出的软件缺陷有是被人认为不重要，不用修复。测试员要善

于体现观点，表明软件缺陷为何须须修爱，并通过实际演示力陈观点。

软件测试员的一种基本素质是打破砂锅问究竟。他们喜欢找出那些深藏不露日勺系统冲突。

他们乐于处理最复杂口勺问题。他们外表上热衷于来回奔忙，追求尽善尽美。

软件测试员的任务是检查和批评同事的工作，挑毛病，公布发现的问题。这样难免与项

目组中的其他人员会产生摩擦，下面是保持小组组员和睦的提议:

•早点找出软件缺陷。这是软件测试员口勺当然任务，不过不轻易做到。在三个月之前

而不是在产品即将公布前夕找出严重H勺软件缺陷，会产生更小的影响，更轻易让人

接受。

•控制情绪。诚然，软件测试员真心爱慕自己的工作，当发现严重的软件缺陷时乐不

自胜。不过，假如兴冲冲地闯入程序员同事口勺房间告诉他程序中存在不可救药口勺软

件缺陷，他不会快乐的。

不要总是汇报坏消息。假如意外发现某些代码没有软件缺陷，就大声宣扬。花某些时间找程

序员聊聊天。假如总是汇报坏消息，他人就会惟恐避之不及。

007.软件测试的阶段划分

1.单体测试

单元测试的对象是软件设干的最小单位一一模块。单元测试的根据是详细设描述，单元测试

应对模块内所有重要的I控制途径设计测试用例，以便发现模块内部的错误。单元测试时，系统

内多种模块可以并行地进行测试。在这个测试阶段所发现日勺往往是编码和详细设计的J错误。

2.结合测试

也可以称作“集成测试”，是组装软件的系统测试技术，按设计规定把通过单元测试的各个

模块组装在一起之后，进行综合测试以便发现与接口有关的多种错误。

3.系统测试

系统测试应当由若干个不一样测试构成，目的是充足运行系统，验证系统各部件与否都能正

常工作并完毕所赋予的任务。

系统测试重要有如下的几种类型：

•恢复测试：重要检查系统的容错能力。

•安全测试：检查系统对非法侵入的防备能力。

・强度测试：检查程序对异常状况的抵御能力。

•性能测试：检查测试数据在超负荷环境中运行，程序与否可以承担。

4.回归测试

确定软件修改和变更后仍然满足所有软件规定。回归测试是有选择地反复已经有确实认测试,

而不开发新日勺测试。回归测试需要针对修改或者变更日勺程序进行验证，并且对该程序修正或

者变更有关口勺功能点进行验证。I可归测试不是一种独立的测试阶段，是贯穿在所有测试阶段

中反复进行的过程.

008.测试用例的设计措施

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期日勺成果。简朴日勺说，测试

用例就是设计一种场景，使软件程序在这种场景下，必须可以正常运行并且到达程序所波及

H勺执行成果。

测试用例的设计措施与测试H勺基本措施有类似之处，测试用例是对软件测试的设计，然后基

于测试用例来进行软件测试的实行。

01.测试用例H勺特性:

1.最有也许抓住错误的

2.不是反复H勺、多出的

3.一组相似测试用例中最有效的

4.既不是太简朴，也不是太复杂

02.测试用例日勺设计原则

1.测试用例H勺代表性：可以代表并覆盖多种合理的和不合理的、合法的和非法口勺、边界口勺和

越界口勺以及极限的输入数据、操作和环境等。

2.测试成果的可判断性：即测试执行成果的对的性是可鉴定的，每一种测试用例都应有对应

的期望成果。

3.测试成果的可再现性：即对同样的测试用例，系统的执行成果应当是相似的。

03.等价类划分措施

1.定义

是把所有也许H勺输入数据,即程序的输入域划提成若干部分（子集），然后从每一种子集中选

用少数具有代表性的数据作为测试用例。该措施是一种重要H勺，常用H勺黑盒测试用例设计措

施。

2.划分等价类：

等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭发程序中的错误都是等

效的，并合理地假定：测试某等价类H勺代表值就等于对这一类其他值的测试，因此，可以把所

有输入数据合理划分为若干等价类，在每一种等价类中取一种数据作为测试的输入条件就可

以用少许代表性的测试数据获得很好H勺测试成果。等价类划分可有两种不一样的状况：有效

等价类和无效等价类。

1）有效等价类

是指对于程序日勺规格阐明来说是合理日勺、故意义的输入数据构成的集合。运用有效等

价类可检查程序与否实现了规格阐明中所规定的功能和性能。

2）无效等价类

与有效等价类的I定义碰巧相反。无效等价类指对程序的规格阐明是不合理的或无意义

H勺输入数据所构成H勺集合。对于详细H勺问题，无效等价类至少应有一种，也也许有多种。

设计测试用例时，要同步考虑这两种等价类。由于软件不仅要能接受合理的数据，也要能经

受意外的考验，这样的测试才能保证软件具有更高的可靠性。

3.划分等价类的原则：

1）完备测试、防止冗余；

2）划分等价类重要的是：集合H勺划分，划分为互不相交H勺一组子集，而子集时并是整个

集合；

3）并是整个集合：完备性；

4）子集互不相交：保证一种形式的无冗余性;

5）同一类中标识（选择）一种测试用例，同一等价类中，往往处理相似，相似处理映射

到”相似的执行途径”。

4.划分等价类II勺措施

6）在输入条件规定了取值范围或值日勺个数的I状况卜，则可以确立一种有效等价类和两个

无效等价类。如：输入值是学生成绩，范围是0〜100；

0100

无效等价类—<________懿等价类________..正效等俗赛

成绩VOUW娟W1U0成绩>100

7）在输入条件规定了输入值的集合或者规定了“必须怎样”的条件的状况下，可确立一种

有效等价类和一种无效等价类；

8）在输入条件是一种布尔量U勺状况下,可确定一种有效等价类和一种无效等价类。

9）在规定了输入数据的一组值（假定n个），并且程序要对每一种输入值分别处理的状

况下,可确立n个有效等价类和一种无效等价类。

例：输入条件阐明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个

值作为四个有效等价类，此外把四种学历之外的任何学历作为无效等价类。

10）在规定了输入数据必须遵守的规则的状况下，可确正一种有效等价类（符合规则）和

若干个无效等价类（从不一样角度违反规则）；

11）在确知已划分的等价类中各元素在程序处理中的方式不一样的状况下，则应再将该等

价类深入H勺划分为更小Fl勺等价类。

5.设计测试用例

在确立了等价类后，可建立等价类表，列出所有划分出时等价类输入条件：有效等价类、无

效等价类，然后从划分出的等价类中按如下三个原则设计测试用例：

1）为每一种等价类规定一种唯一的编号；

2）设计一种新的）测试用例，使其尽量多地覆盖尚未被覆盖地有效等价类,反复这•步，直到

所有的有效等价类都被覆盖为止；

3）设计一种新的测试用例，使其仅覆盖一种尚未被覆盖日勺无效等价类,反复这一步，直到所

有的无效等价类都被覆盖为止。

04.边界值分析措施

边界值分析法就是对输入或输出的边界值进行测试口勺一种黑盒测试措施。一般边界值分析法

是作为对等价类划分法的补充，这种状况下，其测试用例来自等价类口勺边界。

1.与等价划分打勺区别

D边界值分析不是从某等价类中随便挑一种作为代表，而是使这个等价类的每个边界都要

作为测试条件。

2）边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试状况。

2.边界值分析措施的考虑：

长期欧I测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生

在输入输出范围H勺内部。因此针对多种边界状况设计测试用例，可以查出更多的错误。

使用边界值分析措施设计测试用例，首先应确定边界状况。一般输入和输出等价类的边界，

就是应着重测试的边界状况。应当选用恰好等于，刚刚不小于或刚刚不不小于边界时值作为

测试数据，而不是选用等价类中的经典值或任意值作为测试数据。

3.常见的边界值

1）对16-bit的整数而言32767和-32768是边界

2）屏幕上光标在最左上、最右下位置

3）报表的第一行和最终一行

4）数组元素的第一种和最终一种

5）循环的第0次、第1次和倒数第2次、最终一次

4.边界值分析

1）边界值分析使用与等价类划分法相似II勺划分，只是边界值分析假定错误更多地存在于划分

的边界上，因此在等价类的边界上以及两侧的状况设计测试用例。

2）等价类划分：

I.可以考虑作出如下划分：

a、输入（i）＜0和（ii）＞=0

b、输出（a）＞=0和⑹Error

II.测试用例有两个:

a、输入4,输出2。对应于（ii）和（a）。

c、输入TO,输出0和错误提醒。对应于（i）和（b）。

3）边界值分析：

划分（ii）的边界为0和最大正实数；划分（i）的边界为最小负实数和0。由此得到如

下测试用例：

a、输入｛最小负实数》

b、输入｛绝对值很小的负数｝

c、输入0

d、输入｛绝对值很小的正数｝

e、输入｛最大正实数｝

4）一般状况下，软件测试所包括的边界检查有几种类型：数字、字符、位置、重量、大小、

速度、方位、尺寸、空间等。

5）对应地，以上类型的边界值应当在：最大/最小、首位/末位、上/下、最快/最慢、最忘

/最低、最短/最长、空/满等状况下。

6）运用边界值作为测试数据

项边界值测试用例的设计思绪

起始T个字假设一种文本输入区域容许输入1个到255个字符，输入1

字符符/结束+1个个和255个字符作为有效等价类；输入。个和256个字符作

字符为无效等价类，这几种数值都属于边界条件值。

最小值7/最假设某软件的数据输入域规定输入5位口勺数据值，可以使用

数值

大信+110000作为最小值、99999作为最大值；然后使用刚好不不

小于5位和不小于5位的数值来作为边界条件。

不不小于空

余空间一点/例如在用U盘存储数据时，使用比剩余磁盘空间大一点（儿

空间

不小于满空KB）的文献作为边界条件。

间一点

7）内部边界值分析:

在多数状况下，边界值条件是基于应用程序口勺功能设计而需要考虑的原因，可以从软件口勺规

格阐明或常识中得到，也是最终顾客可以很轻易发现问题的。然而，在测试用例设计过程中，

某些边界值条件是不需要展现给顾客的），或者说顾客是很难注意到日勺，但同步确实属于检查

范围内的J边界条件・，称为内部边界值条件或子边界值条件。

内部边界值条件重要有下面几种：

a）数值的边界值检查：计算机是基于二进制进行工作的，因此，软件的J任何数值运算均有一

定H勺范围限制。

项范围或值

位(bit)0或1

字节(byte)0~255

字(word)0~65535（单字）或0~（双字）

千(K)1024

兆(M)1048576

吉(G)

b）字符的边界值检查：在计算机软件中，字符也是很重要口勺表达元素，其中ASCII和Unicode

是常见的编码方式。下表中列出了某些常用字符而应的ASCII码值。

字符ASCII码值字符ASCII码值

空(null)0A65

空格（space）32a97

斜杠（/）47Z90

048z122

冒号（：）58单引号（'）96

@64

c）其他边界值检查

5.基于边界值分析措施选择测试用例H勺原则

1）假如输入条件规定了值H勺范围，则应取刚到达这个范围口勺边界的值，以及刚刚超越这个范

围边界的I值作为测试输入数据。

例如，假如程序日勺规格阐明中规定：”重量在10公斤至50公斤范围内的邮件，其邮费计算

公式为……\作为测试用例,我们应取10及50,还应取】（）.01,49.99,9.99及50.（）1等。

2）假如输入条件规定了值H勺个数，则用最大个数，最小个数，比最小个数少一，比最大个数多

—U勺数作为测试数据。

例如，一种输入文献应包括:255个记录，则测试用例可取1和255,还应取0及256等。

3）将规则1）和2）应用于输出条件，即设计测试用例使输出值到达边界值及其左右的值。

例如，某程序的规格阐明规定计算出〃每月保险金扣除额为0至1165.25元"，其测试用例可

取O00及1165.24、还可取一0.01及1165.26等。

再如一程序属于情报检索系统，规定每次〃至少显示1务、最多显示4条情报摘要”，这时我

们应考虑的测试用例包括1和4,还应包括0和5等。

4）假如程序I为规格阐明给出口勺输入域或输出域是有序集合，则应选用集合H勺第一种元素和最

终一种元素作为测试用例。

5）假如程序中使用了一种内部数据构造，则应当选择这个内部数据构造I内边界上时值作为测

试用例。

6）分析规格阐明，找出其他也许日勺边界条件。

•错误推测法

基于经验和直觉推测程序中所有也许存在的多种错误，从而有针对性口勺设计测试用例口勺措

施。

1.错误推测措施的基本思想：

列举出程序中所有也许有的J错误和轻易发生错误的特殊状况,根据他们选择测试用例。

1）例如，输入数据和输出数据为0『、J状况；输入表格为空格或输入表格只有一行。这些都

是轻易发生错误的状况。可选择这些状况下日勺例子作为测试用例。

2）例如，前面例子中成绩汇报的程序，采用错误推测法还可补充设计某些测试用例：

1.程序与否把空格作为回答

II.在回答记录中混有原则答案记录

III.除了标题记录外，尚有某些U勺记录最终一种字符即不是2也不是3

IV.有两个学生的学号相似

V.试题数是负数,

3）再如，测试一种对线性表（例如数组）进行排序H勺程序，可推测列出如下几项需要尤

其测试的状况：

I.输入的线性表为空表；

II.表中只具有一种元素；

III.输入表中所有元素已排好序；

IV.输入表已按逆序排好；

V.输入表中部分或所有元素相似

05.因果图措施

是一种运用图解法分析输入的多种组合状况，从而设计测试用例U勺措施，它适合于检查程序

输入条件的多种组合状况。

1.因果图法产生的背景：

等价类划分法和边界值分析措施都是着重考虑输入条件，但没有考虑输入条件口勺多种组合、

输入条件之间的互相制约关系。这样虽然多种输入条件也许出错H勺状况已经测试到了：但多

种输入条件组合起来也许出错的状况却被忽视了。

假如在测试时必须考虑输入条件的多种组合，则也许的组合数目将是天文数字，因此必须考

虑采用一种适合于描述多种条件的组合、对应产生多种动作U勺形式来进行测试用例的设计，

这就需要运用因果图（逻辑模型）。

2.因果图简介

1）4种符号分别表达了规格阐明中向4种因果关系。

2）因果图中使用了简朴的逻辑符号，以直线联接左右结点。左结点表达输入状态（或称原

因），右结点表达输出状态（或称成果）。

3）Ci表达原因，一般置于图口勺左部；ei表达成果，一般在图H勺右部。Ci和ei均可取值0

或1,0表达某状态不出现，1表达某状态出现。

3.因果图概念

1）关系

①恒等：若ci是1,则ei也是1；否则ei为0。

②非：若ci是1,则ei是0：否则ei是1。

③或：若cl或c2或c3是1,则ei是1；否则ei为0,“或”可有任意个输入。

④与：若cl和c2都是1,则ei为1；否则ei为仇“与”也可有任意个输入。

2）约束

输入状态互相之间还也许存在某些依赖关系，称为约束。例如，某些输入条件自身不也许同

步出现。输出状态之间也往往存在约束。在因果图中，用特定的符号标明这些约束。

0Q-

E<--0

唯‘、©

异

0Q\

/IM

Rl.一/.：

强制•守

要求

A.输入条件时约束有如下4类：

①E约束（异）：a和b中至多有一种也许为1,即a和b不能同步为1°

②I约束（或）：a、b和c中至少有一种必须是1,即a、b和c不能同步为0。

③0约束（唯一）；a和b必须有一种，且仅有1个为1。

④R约束（规定）：a是1时，b必须是1,即不也许a是1时b是0。

B.输出条件约束类型

输出条件的约束只有M约束（强制）：若成果a是1,则成果b强制为0。

4.采用因果图法设计测试用例的环节:

1）分析软件规格阐明描述中，那些是原因（即输入条件或输入条件的等价类），那些是成果

（即输出条件），并给每个原因和成果赋予一种标识符。

2）分析软件规格阐明描述中的语义，找出原因与成果之间，原因与原因之间对应的关系，根

据这些关系，画出因果图。

3）由于语法或环境限制，有些原因与原因之间，原因与成果之间的组合状况不也许出现，为

表明这些特殊状况，在因果图上用某些记号表明约束或限制条件。

4）把因果图转换为鉴定表。

5）把鉴定表的每一列拿出来作为根据，设计测试用例。

06.鉴定表驱动分析措施

鉴定表是分析和体现多逻辑条件下执行不一样操作的I状况日勺工具。

1.鉴定表的长处

可以将复杂的问题按照多种也许的状况所有列举出来，简要并防止遗漏。因此，运用鉴定表

可以设计出完整H勺测试用例集合。

在某些数据处理问题当中，某些操作的实行依赖于多种逻辑条件口勺组合，即：针对不一样逻

辑条件的组合值，分别执行不一样的操作。鉴定表很适合于处理此类问题。

2.“阅读指南”鉴定表

12345678

觉得疲惫？YYYYNNNX

问

感爱好吗？YYNNYYN\

题

糊涂吗？YNYNYNYN

重读V

提继续

议跳下一章

休息7VVV

3.鉴定表一般由四个部分构成如下图所示。

条件桩条件项

动作项

动作桩规

则

1)条件桩(ConditionStub)：列出了问题得所有条件,一般认为列出的I条件的次序无关紧

要。

2)动作桩(ActionStub)：列出了问题规定也许采用的操作。这些操作的排列次序没有约束。

3)条件项(ConditionEntry)：列出针对它左列条件的取值。在所有也许状况下的真假值。

4)动作项(ActionEntry)：列出在条件项的多种取值状况下应当采用的动作。

4.规则及规则合并

1)规则：任何一种条件组合口勺特定取值及其对应要执行的操作称为规则。在鉴定表中贯穿条

件项和动作项的一列就是一条规则。显然,鉴定表中列出多少组条件取值，也就有多少条规则,

既条件项和动作项有多少列。

2）化简：就是规则合并有两条或多条规则具有相似的动作，并且其条件项之间存在着极为相

似H勺关系。

5.规则及规则合并举例

1）如下图左端，两规则动作项同样，条件项类似，在1、2条件项分别取Y、N时，无论条件

3取何值，都执行同一操作。即要执行的动作与条件3无关。于是可合并。“一”表达与取

值无关。

YY

NN

YNC=>

，XX

2）与上类似，下图中，无关条件项“一”可包括其他条件项取值，具有相似动作H勺规则可合

并。□

M

0M

E

3）化简后的读书指南鉴定表

1234

你觉得疲惫吗？——YN

问

你对内容感爱好吗？YYNN

题

书中内容使你胡涂吗？YN一—

请回到本章开头重读X

建继续读下去X

议

跳到下一章去读X

停止阅读，请休息X

6.鉴定表的建立环节：（根据软件规格阐明）

D确定规则的个数.假如有n个条件。每个条件有两个取值（0,1），故有2n种规则。

2）列出所有的条件桩和动作桩。

3）填入条件项。

4）填入动作项。等到初始鉴定表。

5）简化.合并相似规则（相似动作）。

07.功能图分析措施

一种程序的功能阐明一般由动态阐明和静态阐明构成.动态阐明描述了输入数据的次序或转

移U勺次序.静态阐明描述了输入条件与输出条件之间的对应关系.对于较复杂"勺程序，由于存

在大量的组合状况,因此，仅用静态阐明构成的规格阐明对于测试来说往往是不够的.必须用

动态阐明来补充功能阐叽功能图措施是用功能图FD形式化地表达程序H勺功能阐明，并机械

地生成功能图的测试用例.功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于

表达输入数据序列以及对应的输出数据.在状态迁移图中，由输入数据和目前状态决定输出

数据和后续状态.逻辑功能模型用于表达在状态中输入条件和输出条件之间H勺对应关系.逻

辑功能模型只适合于描达静态阐明，输出数据仅由输入数据决定.测试用例则是由测试中通

过的一系列状态和在每个状态中必须依托输入/输出数据满足的一对条件构成.功能图措施

其实是是一种黑盒白盒混合用例设计措施。

（功能图措施中，要用到逻辑覆盖和途径测试H勺概念和措施，其属白盒测试措施中代I内容.

逻辑覆盖是以程序内部的逻辑构造为基础口勺测试用例设计措施.该措施规定测试人员对程序

H勺逻辑构造有清晰H勺理解.由于覆盖测试日勺目H勺不一样,逻辑覆盖可分为:语句覆盖，鉴定覆

盖，鉴定-条件覆盖，条件组合覆盖及途径覆盖.下面我们指的逻辑覆盖和途径是功能或系统

水平上的，以区别与白盒测试中的程序内部的.）

1.功能图

功能图由状态迁移图和布尔函数构成.状态迁移图用状态和迁移来描述.一种状态指出数据

输入日勺位置（或时间），而迁移则指明状态的变化.同步要依托鉴定表或因果图表达小J逻辑功

能.

2.测试用例生成措施

将节点替代状态,用弧线替代迁移，则状态迁移图就可转化成一种程序的控制流程图形式.问

题就转化为程序的途径测试问题（如白盒测试）问题了.

3.测试用例生成规则

为了把状态迁移（测试途径）口勺测试用例与逻辑模型（局部测试用例）日勺测试用例组合起来,

从功能图生成实用日勺测试用例，须定义下面的规则.在一种构造化日勺状态迁移（SST）中,定义

三种形式的循环:次序,选择和反复.但辨别一种状态迁移中的所有循环是有困难的.

4.从功能图生成测试用例的过程

D生成局部测试用例：在每个状态中，从因果图生成局部测试用例.局部测试用例由原因值

（输入数据）组合与对应R勺成果值（输出数据或状态）构成。

2）测试途径生成:运用上面的规则（三种）生成从初始状态到最终状态的测试途径。

3）测试用例合成：合成测试途径与功能图中每个状态中H勺局部测试用例.成果是初始状态

到最终状态的一种状态序列，以及每个状态中输入数据与对应输出数据的组合。

08.场景设计措施

目前口勺软件儿乎都是用事件触发来控制流程H勺，事件触发时H勺情景便形成了场景，而同一事

件不一样的触发次序和处理成果就形成事件流。这种在软件设计方面的思想也可以引入到软

件测试中，可以比较生动地描绘出事件触发时H勺情景，有助于测试设计者设计测试用例，同

步使测试用例更轻易理解和执行。

基本流和备选流：如下图所示，图中通过用例的每条途径都用基本流和备选流来表达，直黑

线表达基本流，是通过用例日勺最简朴的途径。备选流用不一样日勺色彩表达，一种备选流也许

从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也也

许来源于另一种备选流（如备选流2）,或者终止用例而不再重新加入到某个流（如备选流2

和4）。

开始用例

基本流

备选流

备选流1

备选流4

结束用例

结束用例

09.测试用例设计综合方略

1）在任何状况下都必须使用边界值分析措施，经验表明用这种措施设计出测试用例发现程序

错误的能力最强。

2）必要时用等价类划分措施补充某些测试用例。

3）用错误推测法再追加某些测试用例。

4）对照程序逻辑，检查已设计出口勺测试用例的逻辑覆盖程度，假如没有到达规定的覆盖原则,

应当再补充足够口勺测试用例。

5）假如程序的功能阐明中具有输入条件H勺组合状况，则一开始就可选用因果图法。

10.测试用例的设计环节

I）构造根据设计书得出的基本功能测试用例；

2）边界值测试用例；

3）状态转换测试用例；

4）错误猜测测试用例：

5）异常测试用例；

009.软件测试的基本方式

01.黑盒测试

只需要懂得软件要做什么即可一一而无法看到盒子中是怎样运作的。只要进行某些输入，就

能得到某种输出成果。不用懂得软件怎样运行，为何会这样，只要懂得程序做什么。

02.白盒测试

用访问程序员日勺代码，并通过检查代码来协助测试一一可以看到盒子里面。测试员根据代码

检查成果判断多大的数字乜许出错，并据此调整测试程序。要注意的是，进行白盒测试要冒

某些风险。由于要调整测试程序以适应代码操作，因此很轻易形成偏见而无法进行客观测试.

03.静态测试

是指测试不运行U勺部分一一只是检查和审阅。

04.动态测试

是指•般意义上日勺测试一一运行和使用软件。

010.软件测试的基本措施

01.通过测试和失败测试

软件测试有两个基本措施，通过测试和失败测试。我们一般的测试用例的内容也就是门通过

测试和失败测试两部分构成的I。通过测试就是我们所说的正常的CASE,确认软件至少能做什

么，而不会考验其能力。软件测试员不把软件当回事，只运用最简朴最直观的测试用例。在

设计和执行测试案例时，总是首先进行通过测试。在做破坏性试验之前首先要保证软件基本

功能与否已经实现了。失败测试就是所谓H勺异常CASE,在确信软件在一般状况下对口勺运行之

后，就可以采用多种手段通过搞垮软件来找出缺陷。设计和执行破坏软件的测试用例。常见

的测试用例就是设法迫使软件出现错误提醒信息。虽然与通过测试看起来差不多，不过它是

蓄意袭击软件口勺微弱环节。

02.等价类划分

选择测试按例是软件测试员最重要H勺任务。选择测试案例H勺措施是等价分派，有时称为等价

划分。等价分派是指分环节地把过多（无限）的测试用例减小到同样有效的小范围的过程。

寻找等价区间时，想措施把软件的相似输入、输出、操作提成组。这些组就是等价区间。等

价分派日勺目日勺是把也许的测试用例组合缩减到仍然足以测试软件日勺控制范围。由于选择了不

完全测试，就要冒一定的风险，因此必须仔细选择分类。

03.数据测试

软件由数据（包括键盘输入、鼠标单击、磁盘文献、打印输出等等）和程序（可执行的流程、

转换、逻辑和运算）两个最基本的要素构成。对软件进行数据测试，就是在检查顾客输入的

信息、返回成果以及中间计算成果与否对的。重要根据下列原则来进行等价分派，以合理减

少测试案例：边界条件、空值和无效数据。

•边界条件测试

边界条件是指软件计划的操作界线所在的边缘条件。程序在处理大量中间数值时都是对日勺，

不过也许在边界处出现错误。数据类型：数值、字符、位置、数晟、速度、地址、尺寸等，

都会包括确定口勺边界。

应考虑H勺特性：第一种/最终一种、开始/完毕、空/满、最慢/最快、相邻/最远、最小值/最

大值、超过/在内、最短/最长、最早/最迟、最高/最低。

这些都是也许出现的边界条件。根据边界来选择等价分派中包括口勺数据。然而，仅仅测试边

界线上口勺数据点往往不够充足。提出边界条件时，一定要测试临近边界的合法数据，即测试

最终一种也许合法日勺数据，以及刚超过边界的非法数据。

•默认值测试（默认、空白、空值、零值和无）

好的软件会处理这种状况，常用的J措施：一是将输入内容默认为合法边界内的最小值，或者

合法区间内某个合理值；二是返回错误提醒信息。这些值在软件中一般需要进行特殊处理。

因此应当建立单独H勺等价区间。在这种默认下，假如顾客输入。或一1作为非法值，就可以执

行不一样的软件处埋过程。

•破坏测试（非法、错误、不对H勺和垃圾数据）

数据测试的这一类型是失败测试的对象。此类测试没有实际规则，只是设法破坏软件。不按

软件的规定行事，发挥发明力吧！

04.状态测试

状态测试是通过不一样的状态验证程序的逻辑流程。软件测试员必须测试软件的状态及