软件测试作业指导书

测试作业指导书

基础篇 (3)

001．什么是软件缺陷（BUG） (3)

002．影响软件质量的原因 (3)

003．提高软件质量的方法 (4)

004．软件测试的目标与定义 (4)

005．软件测试中的原则 (5)

006．如何成为一个好的软件测试员 (7)

007．软件测试的阶段划分 (9)

008．测试用例的设计方法 (9)

01．测试用例的特征： (9)

02．测试用例的设计原则 (9)

03．等价类划分方法 (10)

04．边界值分析方法 (11)

05．因果图方法 (15)

06．判定表驱动分析方法 (16)

07．功能图分析方法 (20)

08．场景设计方法 (21)

09．测试用例设计综合策略 (21)

10．测试用例的设计步骤 (22)

009．软件测试的基本方式 (22)

01．黑盒测试 (22)

02．白盒测试 (22)

03．静态测试 (22)

04．动态测试 (22)

010．软件测试的基本方法 (22)

01．过测试和失败测试 (22)

02．等价类划分 (22)

03．数据测试 (23)

04．状态测试 (23)

05．其他黑盒测试方法 (25)

001．测试流程图 (26)

002．测试准备 (27)

003．如何做好式样理解 (27)

004．关于测试用例的设计 (27)

005．测试数据的准备 (28)

006．测试的实施 (29)

007．测试过程中的变更管理 (30)

008．如何填写QA票和BUG票 (30)

009．文档管理工具(CVS)的使用 (30)

010．BUG管理工具（QAMS）的使用 (30)

基础篇

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

1．软件未达到产品说明书表明的功能

计算器的产品说明书可能声称它能够准确无误的进行加、减、乘、除运算。如果按下加号（+）键，结果什么反应也没有，根据该条规则，这就是个软件缺陷。假如得到错误的答案，根据规则，同样是软件缺陷

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

产品说明书可能声称计算机永远不会崩溃、锁死或者停止反应。假如狂敲键盘会使计算器停止接受输入，根据本条规则，这是一个软件缺陷

3．软件功能超出产品说明书指明范围

假如我们发现除了加减乘除之外计算器还可以求品方根，而这一功能哪儿都没提。干劲十足的程序员加入这项功能可能因为觉得这是一项创举，根据本条规则，这是软件缺陷。4．软件未达到产品说明书虽未指出但应达到的目标

这条规则可能让人感觉有些矛盾和奇怪，但是这样是为了抓住产品说明书上遗漏之处。在测试计算器时，会发现电池没电会导致计算机不正确。没有人会考虑应如何应付这种情况，使计算机反应正常，而盲目以为电池永远充足了电。测试要持续进行到电池完全没电，是少要看到电力不足的迹象。产品说明书指出电力不足无法正确计算，但未指出会怎样，根据本条规则，这是软件缺陷。

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

本条规则是全面的。软件测试人员是第1个真正使用软件的人。如果发现某些地方不对劲，无论什么原因，都要认定为软件缺陷。对于计算器来说，可能觉得按键太小；也许等号（=）键的位置放得不好按；也许显示屏在亮光下很难以看清，根据本条规则，这些都是缺陷。注意：每一个使用过一些软件的人都会对如何改进有一些要求和意见。要编写令所有用户都喜欢的软件是不可能的。作为软件测试人员，在运用第5条测试规则时应记住这一点。最好能全面地客观评价，做到合情合理。

002．影响软件质量的原因

影响软件质量的原因很多，具体地说，主要有以下几点：

1．用户原因

需求不清；二义性

2．产品说明书

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

3．设计方案

与产品说明书是一样的，片面、易变

4．交流不够、交流上有误解或者根本不进行交流

在应用应该做什么或不应该做什么的细节（应用的需求）不清晰的情况下进行开发

图形用户界面（GUI），客户/服务器结构，分布式应用，数据通信，超大型关系型数据库以及庞大的系统规模，使得软件及系统的复杂性呈指数增长，没有现代化开发经验的人很难理解它。

6．程序设计错误

跟所有的人一样，程序员也会出错

7．时间压力

软件项目的日程表很难做到准确，很多时候需要预计和猜测。当最终期限迫近和关键时刻到来之际，错误也就跟着来了。

8．自负

自负的人更喜欢说：“没问题”；“这件事很容易”；“几个小时我就能拿出来”，太多不切实际的“没问题”结果只能是引入错误。

9．代码文档贫乏

贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。事实上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和容易理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码更易于工作的保密（“写的艰难必定读的痛苦”）

10.软件开发工具

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

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

003．提高软件质量的方法

1．软件工程化

2．CMM 能力成熟度模型Capability Maturity Model for Software

3．软件测试

004．软件测试的目标与定义

软件测试的目的决定了如何去组织测试，在项目的不同阶段，测试的目的也不相同。

1．在UT(Unit Test)阶段，测试的目的是为了尽可能多地找出错误，那么UT阶段测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。在此阶段，可以引用Grenford J. Myers在《The Art of Software Testing》一书中的观点：

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

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

好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

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

这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的，事实并非如此。

首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。

其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。

2．SI测试阶段的目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。

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

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

对于软件产品的不同角色来说，他们的测试目的也是不同的。

用户：通过测试来暴露错误

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

测试人员：找出软件缺陷，尽可能早一些，并确保其得以修复

测试从狭义上说，就是：凭借测试用例Test Case→运行程序→发现错误的过程。

005．软件测试中的原则

1．完全测试程序是不可能的

在软件测试的过程中，想要进行完全测试，找出所有软件缺陷，并使软件臻于完美，实际上这是不可能的，即使最简单的程序也不行，主要有如下4个原因：

●输入量太大

●输出结果太多

●软件实现途径太多

●软件说明书没有客观标准。从不同的角度看，软件缺陷的标准不同。

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

正因为完全测试程序是不可能的，那么在测试的过程中必定会对某些你认为是重复的或者没必要的或者为了节省时间，而将其提出，如果决定不去测试所有的情况，这就是选择了风险。既然不可能做完全测试，那么这种风险就是无法避免的了。软件测试员要学会的一个主要原则就是如何把无边无际的可能减少到可以控制的范围，以及如何针对风险制定做出明智抉择，去粗存精。

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

软件测试工作与防疫员的工作极为相似，可以报告已发现的软件缺陷，却无法报告潜伏的软件缺陷。你可以进行测试，查找并报告软件缺陷，但是不能保证软件缺陷全部找到。

唯一的方法是继续测试，可能还会找到一些。

4．找到的软件缺陷越多，就说明软件缺陷越多

通常，软件测试员在没有找到软件缺陷之前拼命地琢磨。找到一个之后，就会接二连

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

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

会烦躁不安了。一个软件缺陷很可能是泄露附近有更多软件缺陷的信号。

●程序员往往犯同样的错误。每个人都有偏好。一个程序员总是反复犯下自己容易犯

的错误。

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

软件测试员可能会发现某些软件缺陷开始似乎毫无关联的，但是最后才知道它们是

由一个极其严重的原因造成的。

但是，如果无论如何也找不出软件缺陷，那么也有可能是软件经过精心编制，确实存在极少软件缺陷

5．反复使用相同的测试会使软件具有抵抗力

在测试过程中你会发现经过几个回合的测试之后，该发现的软件缺陷都被发现了，在测试下去也不会有新的发现了。这时，软件测试员，需要采用其他新的方法，对程序的不同部分进行测试，以找出更多软件缺陷。

6．并非所有的软件缺陷都能修复

这要求软件测试员能过进行良好的判断，搞清楚在什么情况下不能追求完美。项目小组需要对每一个软件缺陷进行取舍，根据风险决定哪些需要修复，哪些不要。

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

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

测试人员较少，而且在项目进度中没有为编制和测试留出足够的空间。常常会在不可更改的交付期限内，必须按时完成软件。

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

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

●修复的风险太大。修复一个软件缺陷可能导致其他软件缺陷出现；在紧迫的产品发布

进度压力之外，修改软件将冒很大的风险。不去理睬未知软件缺陷，以避免出现未知新缺陷的做法也许是安全之道。

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

躲过和用户有办法预防或避免的软件缺陷通常不用修复。这些都要归结为商业风险决策。

7．要尽早、不断地进行测试

测试是无穷近的，而测试的时间又是有限的，所以我们要尽早地开始测试，尽快地找出软件缺陷，以便降低修复成本。在几个回合的测试以后，没有再检测出BUG，不能说程序没有错误，只能说还没有找到错误，没有人能够找出程序中所有的错误，没有任何软件产品是完美无错的，我们能做的只是不断地进行测试。

8．测试用例可以帮助我们有效地进行测试

“好的测试用例是极可能发现迄今为止尚未发现的错误的测试用例”，可见测试用例对在软件测试中占有很重要的地位，它可以弥补软件测试员在测试时的遗漏、偏差以及经验上的不足，给我们的测试提供依据。同时测试用例也是作为向用户提供的质量保证的重要依

9．程序员应避免测试自己的程序

“自负”是影响程序质量的原因之一，程序员测试的目的是证明程序的无错，基于这种心理，程序员是很难测试自己程序中的BUG的。另一方面，程序员在理解式样的时候难免会有偏差，如果测试自己的程序是很难找出这些偏差的。

10. 正确和错误的测试

软件测试员测试的目的是要找出软件潜在的错误和缺陷，这里的错误和缺陷不仅指软件本身的错误，还要检测软件对错误的处理能力，所以我们在测试的时候既要准备正确的数据也要准备错误的数据，一般来说测试错误的CASE比正确的CASE要多很多。

11. 群集现象

在测试的过程中，会发现某些画面BUG特别多，某些功能会出现BUG群集的现象，所以要重视这些群集现象，并且及时的采取对策。

12. 杜绝随意性

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

软件测试员是客户的眼睛，是第一次看到软件的人，代表客户说话，应力求完美。但力求完美的同时，最好能全面地客观评价，做到合情合理。

006．如何成为一个好的软件测试员

现在，大多数公司把软件测试视为技术工程专业工作。他们意识到在项目组中培训软件测试员，并在开发过程中早期投入工作可以制造出质量更优的软件。

下面是大多数软件测试员应具备的素质：

●沟通能力。一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技

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

来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重

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

息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够

同等地同用户和开发者沟通。

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

小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。

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

这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较

深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习

曲线。

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

自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。因为开发

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

信开发人员的说法。

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

也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和

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

●幽默感。在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

●很强的记忆力。一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记

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

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

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

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

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

必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

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

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

●洞察力。一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能

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

的测试针对重点环节。

●不懈努力。软件测试员总是不停尝试。他们可能会碰到瞬间即逝或者难以重建的软

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

●创造性。测试显而易见的事实，那不是软件测试员。他们的工作是相处富有创意甚

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

●追求完美。他们力求完美，但是知道某些无法企及时，不去苛求，而是尽力接近目

标。

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

的缺陷。

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

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

软件测试员的一个基本素质是打破砂锅问到底。他们喜欢找出那些深藏不露的系统冲突。他们乐于处理最复杂的问题。他们外表上热衷于来回奔忙，追求尽善尽美。

软件测试员的任务是检查和批评同事的工作，挑毛病，公布发现的问题。这样难免与项目组中的其他人员会产生摩擦，下面是保持小组成员和睦的建议：

●早点找出软件缺陷。这是软件测试员的当然任务，但是不容易做到。在三个月之前

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

接受。

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

自胜。但是，如果兴冲冲地闯进程序员同事的房间告诉他程序中存在不可救药的软

件缺陷，他不会高兴的。

不要总是报告坏消息。假如意外发现某些代码没有软件缺陷，就大声宣扬。花一些时间找程序员聊聊天。如果总是报告坏消息，别人就会惟恐避之不及。

007．软件测试的阶段划分

1．单体测试

单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试时,系统内多个模块可以并行地进行测试。在这个测试阶段所发现的往往是编码和详细设计的错误。

2．结合测试

也可以称作“集成测试”，是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。

3．系统测试

系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的任务。

系统测试主要有以下的几种类型：

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

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

●强度测试：检查程序对异常情况的抵抗能力。

●性能测试：检查测试数据在超负荷环境中运行，程序是否能够承担。

4．回归测试

确定软件修改和变更后仍然满足所有软件要求。回归测试是有选择地重复已有的确认测试，而不开发新的测试。回归测试需要针对修改或者变更的程序进行验证，并且对该程序修正或者变更相关的功能点进行验证。回归测试不是一个独立的测试阶段，是贯穿在所有测试阶段中反复进行的过程。

008．测试用例的设计方法

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。简单的说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所涉及的执行结果。

测试用例的设计方法与测试的基本方法有类似之处，测试用例是对软件测试的设计，然后基于测试用例来进行软件测试的实施。

01．测试用例的特征：

1．最有可能抓住错误的

2．不是重复的、多余的

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

4．既不是太简单，也不是太复杂

02．测试用例的设计原则

1．测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和

2．测试结果的可判断性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

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

03．等价类划分方法

1.定义

是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

2.划分等价类：

等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

1)有效等价类

是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

2)无效等价类

与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。

设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

3.划分等价类的标准：

1)完备测试、避免冗余;

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

集合;

3)并是整个集合：完备性;

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

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

到"相同的执行路径"。

4.划分等价类的方法

6)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个

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

7)在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个

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

8)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。

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

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

例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。

10)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和

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

11)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价

类进一步的划分为更小的等价类。

5.设计测试用例

在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：

1)为每一个等价类规定一个唯一的编号；

2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直

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

3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。

04．边界值分析方法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

1．与等价划分的区别

1)边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

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

2．边界值分析方法的考虑：

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数

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

3．常见的边界值

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

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

3)报表的第一行和最后一行

4)数组元素的第一个和最后一个

5)循环的第 0 次、第 1 次和倒数第 2 次、最后一次

4．边界值分析

1)边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。

2)等价类划分：

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

a、输入 (i)<0 和 (ii)>=0

b、输出 (a)>=0 和 (b) Error

II.测试用例有两个：

a、输入4，输出2。对应于 (ii) 和 (a) 。

c、输入-10，输出0和错误提示。对应于 (i) 和 (b) 。

3)边界值分析：

划分(ii)的边界为0和最大正实数；划分(i)的边界为最小负实数和0。由此得到以下测试用例：

a、输入 {最小负实数}

b、输入 {绝对值很小的负数}

c、输入 0

d、输入 {绝对值很小的正数}

e、输入 {最大正实数}

4)通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、

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

5)相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高

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

6)利用边界值作为测试数据

7)内部边界值分析：

在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户可以很容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。

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

a)数值的边界值检验：计算机是基于二进制进行工作的，因此，软件的任何数值运算都有一定的范围限制。

b)字符的边界值检验：在计算机软件中，字符也是很重要的表示元素，其中ASCII和Unicode 是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。

c)其它边界值检验

5.基于边界值分析方法选择测试用例的原则

1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范

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

例如，如果程序的规格说明中规定："重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……"。作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等。

2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。

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

3)将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。例如，某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元"，其测试用例可取0.00及1165.24、还可取一0.01及1165．26等。

再如一程序属于情报检索系统，要求每次"最少显示1条、最多显示4条情报摘要"，这时我们应考虑的测试用例包括1和4，还应包括0和5等。

4)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

5)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。

6)分析规格说明,找出其它可能的边界条件。

错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

1．错误推测方法的基本思想：

列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

1) 例如, 输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

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

I.程序是否把空格作为回答

II.在回答记录中混有标准答案记录

III.除了标题记录外，还有一些的记录最后一个字符即不是2也不是3

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

V.试题数是负数。

3) 再如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：

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

II.表中只含有一个元素；

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

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

V. 输入表中部分或全部元素相同

05．因果图方法

是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

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

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

2．因果图介绍

1) 4种符号分别表示了规格说明中向4种因果关系。

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

3) Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。

3．因果图概念

1) 关系

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

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

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

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

2) 约束

输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

A.输入条件的约束有以下4类：

① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。

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

③ O约束（唯一）；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．判定表驱动分析方法

判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

1．判定表的优点

能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表

能够设计出完整的测试用例集合。

在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

2.“阅读指南”判定表

3. 判定表通常由四个部分组成如下图所示。

1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

4.规则及规则合并

1)规则：任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。

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

似的关系。

5.规则及规则合并举例

1)如下图左端，两规则动作项一样，条件项类似，在1、2条件项分别取Y、N时，无论条件3取何值，都执行同一操作。即要执行的动作与条件3无关。于是可合并。“－”表示与取值无关。

2)与上类似，下图中，无关条件项“－”可包含其他条件项取值，具有相同动作的规则可合并。

3)化简后的读书指南判定表

6.判定表的建立步骤：（根据软件规格说明）

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

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

3)填入条件项。

4)填入动作项。等到初始判定表。

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

07．功能图分析方法

一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例. 功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。

（功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.该方法要求测试人员对程序的逻辑结构有清楚的了解.由于覆盖测试的目标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下面我们指的逻辑覆盖和路径是功能或系统水平上的,以区别与白盒测试中的程序内部的.）

1.功能图

功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置（或时间）,而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.

2.测试用例生成方法

将节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题（如白盒测试）问题了.

3.测试用例生成规则

为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则.在一个结构化的状态迁移（SST）中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所有循环是有困难的.

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

1)生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。

2)测试路径生成:利用上面的规则（三种）生成从初始状态到最后状态的测试路径。

3)测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态

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