软件测试重点DOC.docx
《软件测试重点DOC.docx》由会员分享，可在线阅读，更多相关《软件测试重点DOC.docx（19页珍藏版）》请在冰豆网上搜索。
软件测试重点DOC
第一章
软件测试概述
1、软件测试是对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
2、软件故障与硬件故障导致系统失效的比例为：
10:
1
3、软件缺陷的典型例子：
（1）千年虫问题（银行计算利息为负数）
（2）爱国者导弹防御系统（系统时钟错误积累，使导弹延时，美国的导弹误杀了美国的士兵）
（3）美国火星登陆事故（接口错误，没有测试，导致飞船加速下降，撞成碎片）
（4）Intel奔腾芯片缺陷（计算错误，损失巨大）
（5）Windows2000安全漏洞（系统，网站等受到攻击）
（6）迪斯尼的圣诞节礼物
（7）冲击波”计算机病毒
4、软件缺陷产生的原因：
（1）、开发人员不太了解需求，软件需求分析不够全面、准确是导致软件缺陷的最主要原因。
（2）、软件系统越来越复杂，开发人员不太可能精通所有的技术。
（3）、技术文档普遍比较糟糕，文档本身就有错误。
（4）、软件需求、设计报告、程序经常发生变更，每次变更都可能产生新的错误。
（5）、任何人在编程时都可能犯错误，导致程序中有错误。
（6）、人们常处于进度的压力之下，急忙之下容易产生错误。
（7）、人们过于自信，不真实的“没问题”将产生真正的问题。
（8）、软件设计和编码过程中的失误也会导致软件缺陷的产生。
（9）、但很多情况下，不正确的软件设计是不正确的需求分析引起的，编码阶段出现的错误则是由需求分析和软件设计不够完善、准确引起的。
5、软件测试的目的和意义
软件测试的根本目的是以尽可能少的时间和人力发现并改正软件中潜在的各种故障及缺陷，提高软件的质量。
6、软件测试原则：
（1）尽早和不断测试
（2）每个程序员都应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）
（3）完全测试是不可能的
（4）测试能提高软件的质量，但是提高质量不能依赖测试
（5）测试只能证明错误存在，不能证明错误不存在
（6）测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试
（7）80-20原则：
80％的错误聚集在20％的模块中，经常出错的模块改错后还会经常出错
（8）测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”
7、软件测试过程
（1）单元测试（模块测试）
目的:
检测程序模块中有无故障存在
对象:
软件设计的最小单位，与程序设计和编程实现关系密切
（2）集成测试（组装测试、子系统测试）
目的:
发现与接口有关的模块之间的问题
方法：
非增式集成测试法和增式集成测试法
分类：
非增式集成测试法
对每一个模块进行单元测试
在此基础上按程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试
增式集成测试法
不断地把待测模块连接到已测模块集（或其子集）上，对待测模块进行测试，直到最后一个模块测试完毕
（3）．确认测试
目的：
对软件产品进行评估以确定其是否满足软件需求的过程
确认测试的结果：
a.测试结果满足需求规格说明；b.与需求规格有偏离。
（4）．系统测试
目的：
针对系统中各个组成部分进行的综合性检验，证明系统的性能
测试人员要求：
系统开发人员不能进行系统测试。
系统开发组织不能负责系统测试。
（5）．验收测试
目的：
向用户表明所开发的软件系统能够像用户所预定的那样工作
主要任务：
明确规定验收测试通过的标准；
确定验收测试方法；
确定验收测试的组织和可利用的资源；
确定测试结果的分析方法；
制定验收测试计划并进行评审；
设计验收测试的测试用例；
审查验收测试的准备工作；
执行验收测试；
分析测试结果，决定是否通过验收。
8、软件开发过程
正规的软件开发过程一般包括六个阶段，即：
第一阶段计划
第二阶段需求分析（开发人员和用户共同决定）
第三阶段设计（包括概要设计和详细设计）
第四阶段程序编写
第五阶段测试（单元，集成，确认，验收）
第六阶段运行和/维护
这六个阶段构成了软件的生存周期。
9、软件测试与软件开发的关系
软件测试在软件开发中的作用：
项目规划阶段：
负责整个测试阶段的监控。
需求分析阶段：
确定测试需求分析，制定系统测试计划。
测试需求分析是指产品生存周期中测试所需的资源、配置、各阶段评审通过的标准等。
概要设计和详细设计阶段：
制定集成测试计划和单元测试计划。
编码阶段：
开发相应的测试代码或测试脚本。
测试阶段：
实施测试，并提交相应的测试报告。
10、软件测试在软件开发中的作用
测试在软件开发中占有重要地位
测试成本占有开发成本的近一半
11、软件测试工具
（1）、白盒测试工具
静态测试工具
职能：
主要集中在需求文档、设计文档以及程序结构上，可以进行类型分析、接口分析、输入输出规格说明分析等。
工具：
McCabe&Associates公司开发的McCabeVisualQualityToolSet分析工具；ViewLog公司开发的LogiScope分析工具；SoftwareResearch公司开发的TestWork/Advisor分析工具及SoftwareEmancipation公司开发的Discover分析工具，北京邮电大学开发的DTS缺陷测试工具等。
动态测试工具
职能：
功能确认与接口测试、覆盖率分析、性能分析、内存分析等
工具：
Compuware公司开发的DevPartner软件、Rational公司研制的Purify系列等。
（2）、黑盒测试工具
工具：
Rational公司的TeamTest，Compuware公司的QACenter。
分类：
功能测试工具和性能测试工具
习题1
1什么是软件测试？
软件测试的目的和意义是什么？
2简述软件测试过程。
3简述软件测试过程V模型和软件测试过程W模型的主要区别。
软件测试过程V模型
特点：
非常明确地表明了测试的不同级别，清晰地展示了软件测试与开发之间的关系。
软件开发是一个自顶向下逐步细化的过程，软件测试则是一个自底向上逐步集成的过程。
软件测试过程W模型
形象的展示了开发与测试的并行，测试贯穿与开发过程。
第二章黑盒测试
1、黑盒测试是一种常用的软件测试方法，它将被测软件看作一个打不开的黑盒，主要根据功能需求设计测试用例，进行测试
黑盒测试的基本概念
黑盒测试是一种从软件外部对软件实施的测试，也称功能测试或基于规格说明的测试。
其基本观点是：
任何程序都可以看作是从输入定义域到输出值域的映射，这种观点将被测程序看作一个打不开的黑盒，黑盒里面的内容（实现）是完全不知道的，只知道软件要做什么。
因无法看到盒子中的内容，所以不知道软件是如何实现的，也不关心黑盒里面的结构，只关心软件的输入数据和输出结果。
目的：
黑盒测试是从用户观点出发的测试，其目的是尽可能发现软件的外部行为错误。
在已知软件产品功能的基础上，
1）检测软件功能能否按照需求规格说明书的规定正常工作，是否有功能遗漏；
2）检测是否有人机交互错误，是否有数据结构和外部数据库访问错误，是否能恰当地接收数据并保持外部信息（如数据库或文件）等的完整性；
3）检测行为、性能等特性是否满足要求等；
4）检测程序初始化和终止方面的错误等。
优点：
黑盒测试着眼于软件的外部特征，通过上述方面的检测，确定软件所实现的功能是否按照软件规格说明书的预期要求正常工作.
两个显著的优点：
①黑盒测试与软件具体实现无关，所以如果软件实现发生了变化，测试用例仍然可以使用；
②设计黑盒测试用例可以和软件实现同时进行，因此可以压缩项目总的开发时间。
2几种常用的黑盒测试方法
等价类划分边界值分析法
因果图法决策表法
（1）等价类划分法是一种典型的黑盒测试方法，它完全不考虑程序的内部结构，只根据程序规格说明书对输入范围进行划分，把所有可能的输入数据，即程序输入域划分为若干个互不相交的子集，称为等价类，然后从每个等价类中选取少数具有代表性的数据作为测试用例，进行测试。
所谓等价类是指输入域的某个互不相交的子集合，所有等价类的并便是整个输入域。
等价类划分测试用例设计
在设计测试用例时应同时考虑有效等价类和无效等价类测试用例的设计。
根据等价类表设计测试用例，具体步骤如下：
（1）为每个等价类规定一个唯一的编号。
（2）设计一个新的测试用例，尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到测试用例覆盖了所有的有效等价类。
（3）设计一个新的测试用例，使其覆盖并且只覆盖一个还没有被覆盖的无效等价类。
重复这一步，直至测试用例覆盖了所有的无效等价类。
（2）、边界值分析法
大量的软件测试实践表明，故障往往出现在定义域或值域的边界上，而不是在其内部。
为检测边界附近的处理专门设计测试用例，通常都会取得很好的测试效果。
因此边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的发现故障的能力。
边界条件
1边界是一些特殊情况。
程序在处理大量中间数值时都是正确，但是在边界处可能出现错误。
边界条件就是软件计划的操作界限所在的边缘条件。
2一些可能与边界有关的数据类型有：
数值，速度，字符，地址，位置，尺寸，数量等。
在等价类划分基础上进行边界值分析测试的基本思想是，选取正好等于、刚刚大于或刚刚小于等价类边界的值作为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。
（3）、因果图法
因果图法是基于这样的一种思想：
一些程序的功能可以用判定表（或称决策表）的形式来表示，并根据输入条件的组合情况规定相应的操作。
因果图法的定义：
是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
采用因果图法设计测试用例的步骤：
（1）根据程序规格说明书描述，分析并确定因（输入条件）和果（输出结果或程序状态的改变），画出因果图。
（2）将得到的因果图转换为决策表（判定表）。
（3）为决策表中每一列所表示的情况设计一个测试用例。
使用因果图法的优点：
（1）考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系。
（2）能够帮助测试人员按照一定的步骤，高效率的开发测试用例。
（3）因果图法是将自然语言规格说明转化成形式语言规格说明的一种严格的方法，可以指出规格说明存在的不完整性和二义性。
因果图法测试用例的设计步骤:
（1）确定软件规格中的原因和结果。
分析规格说明中哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
（2）确定原因和结果之间的逻辑关系。
分析软件规格说明中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系画出因果图。
（3）确定因果图中的各个约束。
由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。
为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。
（4）把因果图转换为决策表。
（5）根据决策表设计测试用例。
（4）、决策表法
在一个程序中，如果输入输出比较多，输入之间和输出之间相互制约的条件比较多，在这种情况下适宜用决策表，可以很清楚的表达它们之间的各种复杂关系。
决策表
决策表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。
概念：
决策表是分析和表达多逻辑条件下执行不同操作的情况的工具。
优点：
它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。
因此，利用决策表能够设计出完整的测试用例集合。
在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：
针对不同逻辑条件的组合值，分别执行不同的操作。
决策表很适合于处理这类问题。
决策表通常由条件桩、条件项、动作桩和动作项4部分组成。
构造决策表可采用以下5个步骤：
（1）列出所有的条件桩和动作桩。
（2）确定规则的个数。
（3）填入条件项。
（4）填入动作项，得到初始决策表。
（5）简化决策表，合并相似规则。
⏹决策表测试法适用于具有以下特征的应用程序：
if-then-else逻辑突出；输入变量之间存在逻辑关系；涉及输入变量子集的计算；输入与输出之间存在因果关系。
适用于使用决策表设计测试用例的条件：
Ø规格说明以决策表形式给出，或较容易转换为决策表。
Ø条件的排列顺序不会也不应影响执行的操作。
Ø规则的排列顺序不会也不应影响执行的操作。
Ø当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
Ø如果某一规则的条件要执行多个操作，这些操作的执行顺序无关紧要。
3、黑盒测试方法的比较与选择
几种典型的黑盒测试方法，这些测试方法的共同特点是，它们都把程序看作是一个打不开的黑盒，只知道输入到输出的映射关系，根据软件规格说明设计测试用例。
⏹在等价类分析测试中，通过等价类划分来减少测试用例的绝对数量。
⏹边界值分析方法则通过分析输入变量的边界值域设计测试用例。
⏹在因果图测试方法和决策表测试中，通过分析被测程序的逻辑依赖关系，构造决策表，进而设计测试用例。
4、黑盒测试工具介绍
黑盒测试是在已知软件产品应具有的功能的条件下，在完全不考虑被测程序内部结构和内部特性的情况下，通过测试来检测每个功能是否都按照需求规格说明的规定正常使用。
黑盒测试工具又分为：
功能测试工具和性能测试工具。
①功能测试工具:
功能测试工具主要用于检测被测程序能否达到预期的功能要求并能正常运行。
②性能测试工具:
性能测试工具主要用于确定软件和系统性能。
黑盒功能测试工具，如MercuryInteractive公司的WinRunner，IBMRational公司的TeamTest和Robot，Compuware公司的QACenter等。
第三章
软件测试用例设计
1、黑盒测试方法：
等价类划分、边界值分析、决策表测试、因果图法
白盒测试：
数据流测试、逻辑覆盖、路径测试
面向对象测试：
有限状态机、Petri网、正交阵列法、UML测试
2、白盒测试（WhiteBoxTesting,GlassBoxTesting）又称为结构测试、逻辑驱动测试或基于程序的测试。
一般用来分析程序的内部结构。
基于覆盖的测试技术---白盒测试要求对被测程序的结构特性做到一定程度的覆盖，并以软件中的某类成分是否都已经得到测试为准则来判断软件测试的充分性。
白盒测试的目的：
白盒测试通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；
在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
白盒测试的特点：
依据软件设计说明书进行测试；
对程序内部细节的严密检验；
针对特定条件设计测试用例；
对软件的逻辑路径进行覆盖测试。
白盒测试的实施过程：
1.测试计划阶段：
2.测试设计阶段：
依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。
3.测试执行阶段：
4.测试总结阶段：
路径测试
1）控制流图
程序流程图是一种程序控制结构的图形表示方式。
在程序流程图上的处理框内常常标明了处理要求或条件。
控制流图：
为了更加突出控制流的结构，需要对程序流程图做些简化，这种简化了的流程图称为控制流图。
控制流图中的符号：
①节点：
以标有编号的圆圈表示，代表程序流程图中矩形框所表示的处理、菱形表示的分支及多选择结构点。
②控制流线：
以带箭头的直线或弧表示，与程序流程图中的数据流线是一致的，表明了控制的顺序。
控制流线通常标有名字，如图中所标的a、b、c等。
程序流程图----〉控制流图
转换的原则如下：
控制流图中的每一个节点可以表示程序流程图中矩形框所表示的处理；
菱形表示的两个甚至多个出口判断；
多条流线相交的汇合点。
2）基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路（圈）复杂性，导出基本可执行路径集合，从而设计测试用例的方法。
逻辑覆盖
语句覆盖判定覆盖（分支覆盖）
条件覆盖判定/条件覆盖
条件组合覆盖
语句覆盖准则
在测试中，要求程序中的每条语句都得到运行。
在控制流图中，要求所有的语句都被运行的充分必要条件是覆盖图中的所有节点。
语句覆盖准则的优缺点：
优点：
可以很直观地从源代码得到测试用例，无须细分每条判定表达式。
缺点：
由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件是无法测试的。
如在多分支的逻辑运算中无法全面的考虑。
语句覆盖是最弱的逻辑覆盖。
判定覆盖准则（分支覆盖）
要求在测试中，每个分支都至少获得一次“真”和一次“假”。
在控制流图中，分支表现为图中的一条有向边。
分支（判定）覆盖只能作到分支（判定）覆盖仍无法确定判断内部条件的错误。
判定覆盖优缺点：
优点：
分支（判定）覆盖具有比语句覆盖更强的测试能力。
同样分支（判定）覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。
缺点：
往往大部分的分支（判定）语句是由多个逻辑条件组合而成，若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。
判定覆盖仍是弱的逻辑覆盖。
条件覆盖
一个分支的条件是由谓词组成的。
单个谓词称为原子谓词。
（1）原子谓词覆盖准则（条件覆盖）
要求每个复合谓词所包含的每一个原子谓词都至少获得一次“真”和一次“假”。
即要使每个判断中每个条件的可能取值至少满足一次。
条件覆盖优缺点：
优点：
增加了对条件判定情况的测试，增加了测试路径。
缺点：
原子谓词（条件）覆盖不一定包含分支（判定）覆盖。
原子谓词（条件）覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
判定/条件覆盖准则
要求不仅每个复合谓词所包含的每一个原子谓词都至少获得一次“真”和一次“假”，而且每个复合谓词本身也至少获得一次“真”和一次“假”。
即使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次。
判定/条件覆盖优缺点：
优点：
能同时满足判定、条件两种覆盖标准。
缺点：
分支-谓词（判定/条件）覆盖准则的缺点是未考虑条件的组合情况。
从表面来看，它测试了所有条件的取值。
但实际并不是这样。
因为一些条件往往掩盖了另一些条件。
对于条件表达式（A＞1）&&（B=0）来说，只要（A＞1）的测试为真，才需测试（B=0）的值来确定此表达式的值，但是若（A＞1）的测试值为假时，不需再测（B=0）的值就可确定此表达式的值为假，因而B=0没有被检查。
同理，对于（A=2）||（X＞1）这个表达式来说，只要（A=2）测试结果为真，不必测试（X＞1）的结果就可确定表达式的值为真。
所以对于判定/条件覆盖来说，逻辑表达式中的错误不一定能够查得出来。
条件组合覆盖准则
要求每个谓词（判定）中条件的各种可能组合都至少出现一次。
条件组合覆盖优缺点：
优点：
复合谓词（条件组合）覆盖准则满足分支（判定）覆盖、原子谓词（条件）覆盖和分支-谓词（判定/条件）覆盖准则，是前述几种覆盖标准中最强的。
缺点：
线性地增加了测试用例的数量。
逻辑覆盖测试的5种标准
几种覆盖准则间的关系
白盒测试策略
1：
桌前检查
桌前检查是在程序员实现特定功能后，进行单元测试之前，对源代码进行的初步检查。
该项工作的参与人员为开发人员，重点检查编码、语句的使用等是否符合编码规范，并根据《编码规范》调整自己的代码以符合编码规范的要求。
2：
单元测试
单元测试也称作模块测试，在传统结构化程序中，以一个函数、过程为一个单元；在面向对象编程过程中，一般将类作为单元进行测试。
该项工作的参与人员为专门的白盒测试人员。
可采用白盒测试和黑盒测试相结合的方法。
3：
代码评审
代码评审是在编码初期或编写过程中采用一种有同行参与的评审活动。
该项工作需要所有开发小组共同参与，通过大家共同阅读代码或由程序编写者讲解代码，其他同行边听边分析问题的方法。
共同查看程序，可以找出问题，使大家的代码风格一致或遵守编码规范。
4：
同行评审
在同行评审中，由软件产品创建者的同行们检查该工作产品，识别产品的缺陷，改进产品的不足。
主要用于检验工作产品是否正确的满足了以往的工作产品中建立的规范，如需求或设计文档；识别工作产品相对于标准的偏差，包括可能影响软件可维护性的问题；向创建者提出改进建议；促进参与者之间的技术交流和学习等。
根据CMM标准，该项工作的参与人员为程序员、设计师、单元测试工程师、维护者、需求分析师、编码标准专家。
至少需要开发人员，测试人员和设计师。
5：
代码走查
代码走查由测试小组组织或者专门的代码走查小组进行代码走查，这时需要开发人员提交有关的资料文档和源代码给走查人员，并进行必要的讲解。
代码走查往往根据《代码检查单》来进行，代码检查单常常是根据《编码规范》总结出来的一些条目，目的是检查代码是否按照《编码规范》来编写的。
当然，代码走查的最终目的还是为了发现代码中潜在的错误和缺陷。
该项工作的参与者为测试人员。
代码走查速度一般建议为：
汇编代码与C代码150行/小时，C++/Java200-300行/小时。
6：
静态分析
静态分析通常需要辅助工具支持，通过提取代码信息，进行统计，根据统计结果对源代码进行质量评估。
代码规则检查也是静态分析的一个方面。
该项工作的参与人员为测试小组
3、面向对象的测试用例设计
有限状态机Petri网
正交阵列法UML软件测试
将开发分为面向对象分析（OOA），面向对象设计（OOD），和面向对象编程（OOP）三个阶段。
正交阵列法
正交阵列法的应用范围：
正交表测试法适用于输入条件相互独立，并且需要对输入
什么是正交测试法？
正交测试源于正交试验设计方法。
正交试验设计方法是一种研究多因素多水平的试验设计方法，它根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点。
正交试验设计方法一般使用已经造好了的正交表格来安排试验并进行数据分析。
正交测试法与正交试验设计方法类似也使用已经造好了的正交表格来生成测试用例，它简单易行，应用性较好。
什么是因素（Factor）
在一项试验中，凡欲考察的变量称为因素（变量）。
什么是水平（位级）（Level）
在试验范围内，因素被考察的值称为水平（变量的取值）。
什么是正交表？
（源自古希腊）
正交表是一个二维表格，它的构成如下：
行数（Runs）：
正交表中的行的个数，即试验的次数。
因素数（Factors）：
正交表中列的个数。
水平数（Levels）：
任何单个因素能够取得的值的最大个数。
正交表中的包含的值为从0到“水平数-1”或从1到“水平数”。
正交表的表示形式：
L行数（水平数因素数）
正交表的正交性
1）每一列中各数字出现的次数都一样多；
2）任何两列所构成的各有序数对出现的次数都一样多。
正交测试用例设计步骤
（1）确定测试中有多少个相互独立的变量，这映射到表中的因素数（Factors）。
（2）确定每个变量可以取值的个数，这映射到表中的水平数（Levels）。
（3）选择一个最适合的正交表，其因素数>=测试中的变量数，各因素的水平数>=对应变量的取值个数，另外，次数（Run）最少。
（4）把因素和值映射到表中。
（5）为剩下的水平数选取值。
（6）把次数中所描述的组合转化成测试用例，再增加一些没有生成的但可疑的测试用例。
UML软件测试
1.场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景即为场景。
而同一事件不同的触发顺序和处理结果就形成了事件流。
运用在软件设计中的场景法也可用在软件测试中。
两个概念：
基本流和备选流
升级会员 