软件测试作业指导书

软件测试作业指导书
测试作业指导书
基础篇 (5)
001．什么是软件缺陷（BUG） (5)
002．影响软件质量的原因 (5)
003．提高软件质量的方法 (6)
004．软件测试的目标与定义 (6)
005．软件测试中的原则 (7)
006．如何成为一个好的软件测试员 (9)
007．软件测试的阶段划分 (11)
008．测试用例的设计方法 (12)
01．测试用例的特征： (12)
02．测试用例的设计原则 (12)
03．等价类划分方法 (12)
04．边界值分析方法 (14)
05．因果图方法 (17)
06．判定表驱动分析方法 (19)
07．功能图分析方法 (23)
08．场景设计方法 (24)
09．测试用例设计综合策略 (24)
10．测试用例的设计步骤 (25)
009．软件测试的基本方式 (25)
01．黑盒测试 (25)
02．白盒测试 (25)
03．静态测试 (25)
04．动态测试 (25)
010．软件测试的基本方法 (25)
01．过测试和失败测试 (25)
02．等价类划分 (26)
03．数据测试 (26)
04．状态测试 (26)
05．其他黑盒测试方法 (28)
实践篇 (30)
001．测试流程图 (30)
002．测试准备 (31)
003．如何做好式样理解 (31)
004．关于测试用例的设计 (31)
005．测试数据的准备 (32)
006．测试的实施 (33)
007．测试过程中的变更管理 (34)
008．如何填写QA票和BUG票 (34)
009．文档管理工具(CVS)的使用 (35)
010．BUG管理工具（QAMS）的使用 (35)
基础篇
001．什么是软件缺陷（bug）
1．软件未达到产品说明书表明的功能
计算器的产品说明书可能声称它能够准确无误的进行加、减、乘、除运算。

如果按下加号（+）键，结果什么反应也没有，根据该条规则，这就是个软件缺陷。

假如得到错误的答案，根据规则，同样是软件缺陷
2．软件出现了产品说明书指明不会出现的错误产品说明书可能声称计算机永远不会崩溃、锁死或者停止反应。

假如狂敲键盘会使计算器停止接受输入，根据本条规则，这是一个软件缺陷
3．软件功能超出产品说明书指明范围
假如我们发现除了加减乘除之外计算器还可以求品方根，而这一功能哪儿都没提。

干劲十足的程序员加入这项功能可能因为觉得这是一项创举，根据本条规则，这是软件缺陷。

4．软件未达到产品说明书虽未指出但应达到的目标
这条规则可能让人感觉有些矛盾和奇怪，但是这样是为了抓住产品说明书上遗漏之处。

在测试计算器时，会发现电池没电会导致计算机不正确。

没有人会考虑应如何应付这种情况，使计算机反应正常，而盲目以为电池永远充足了电。

测试要持续进行到电池完全没电，是少要看到电力不足的迹象。

产品说明书指出电力不足无法正确计算，但未指出会怎样，根据本条规则，这是软件缺陷。

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

本条规则是全面的。

软件测试人员是第1个真正使用软件的人。

如果发现某些地方不对劲，无论什么原因，都要认定为软件缺陷。

对于计算器来说，可能觉得按键太小；也许等号（=）键的位置放得不好按；也许显示屏在亮光下很难以看清，根据本条规则，这些都是缺陷。

注意：每一个使用过一些软件的人都会对如何改进有一些要求和意见。

要编写令所有用户都喜欢的软件是不可能的。

作为软件测试人员，在运用第5条测试规则时应记住这一点。

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

002．影响软件质量的原因
影响软件质量的原因很多，具体地说，主要有以下几点：
1．用户原因
需求不清；二义性
2．产品说明书
没有产品说明书；说明书不够全面、经常更改3．设计方案
与产品说明书是一样的，片面、易变
4．交流不够、交流上有误解或者根本不进行交流
在应用应该做什么或不应该做什么的细节（应用的需求）不清晰的情况下进行开发
5．软件复杂性
图形用户界面（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；。