《软件测试》复习重点精.docx
《《软件测试》复习重点精.docx》由会员分享，可在线阅读，更多相关《《软件测试》复习重点精.docx（18页珍藏版）》请在冰豆网上搜索。
《软件测试》复习重点精
1.软件开发过程中错误之所以不可避免,从客观上说,是由于所开发的软件具有相当的复杂性。
从主观方面讲,则是由于人们思维的局限性。
2.软件测试是指在特定的条件下系统或其中的部件进行操作、观测并记录结果,并对系统或部件的某方面作出评估的过程。
3.Myers给出的三个重要观点:
测试是为了证明程序有错,而不是证明程序无错误;
一个好的测试用例是在于它能发现至今未发现的错误;
一个成功的测试是发现了至今未发现的错误的测试。
4.错误出现在书写程序的过程中
导致错误的原因:
对需求的误解;编写代码逻辑不清或疏忽软件配置错误
故障是错误在程序代码中的体现,程序中的故障就是导致程序按照非预期的方式运行的因素,并不是所有的软件故障均有编码错误引起,当一段包含故障的代码被执行且导致不正确的状态并传播到程序的输出,即失效发生。
并不是所有的故障均会导致失效,一个故障可能导致多种失效症状
由错误→故障→失效的基本过程:
由于程序设计人员犯了一个错误,并导致软件源代码中形成一个故障。
如果在一定的条件下该故障被执行且促使系统产生错误的结果,从而形成了一个失效。
5.软件可靠性就是软件在给定条件和给定时间间隔内不出现失效的概率。
软件正确性只有当一个程序在每一种输入下都能按预期执行才能被称为是正确的。
正确性是一种二进制度量,而可靠性则是0至1的区间度量。
6.软件调试是在计算机程序中发现故障并减少其数目的一个方法性的过程。
Testing与Debugging的区别
测试的目的是显示存在错误,而调试的目的是发现错误或导致程序失效的错误原因,并修改程序以修正错误。
调试是测试之后的活动。
测试和调试在目标、方法和思路上都有所不同,具体
如下:
1.测试从一个已知的条件开始,使用预先定义的过程,有预知的结果。
调试从一个未知的条件开始,结束的过程不可预计。
2.测试过程可以事先设计,进度可事先确定。
调试不能描述过程或持续时间。
3.测试是显示错误的行为;调试是推理的过程。
4.测试显示开发人员的错误;调试是开发人员为自己辩护。
5.测试能预期和可控;调试需要想象,经验和思考。
6.测试能在没有详细设计的情况下完成;没有详细设计的信息调试不可能进行。
7.测试能由非开发人员进行;调试必须由开发人员进行。
7.SQA与ST的区别与联系
软件测试和软件质量保证是软件质量工程的两个不同层面的工作。
软件测试只是软件质量保证工作的一个重要环节。
质量保证（QA的工作是通过预防、检查和改进来保证软件质量。
SQA从流程方面保证软件的质量
ST从技术方面保证软件的质量
QA采取的方法主要是按照“全面质量管理”和“过程管理”并改进的原来展开工作。
在质量保证的工作中会掺入一些测试活动,但它所关注的是软件质量的检查和测量。
因此,其主要工作是着眼于软件开发活动中的过程、步骤和产物,并不是对软件进行剖析,找出问题和评估。
测试虽然也与开发过程紧密相关,但它所关心的不是过程的活动,相对的是关心结果。
测试人员要对过程中的产物（开发文档和源代码进行静态审核,运行软件,找出问题,报告质量甚至评估,而不是为了验证软件的正确性。
当然,测试的目的是为了去证明软件有错,否则就违背了测试人员的本职了。
因此,测试虽然对提高软件质量起了关键的作用,但它只是软件质量保证中的一个重要环节。
SQA重点是对软件开发过程进行监督、管理、控制;
ST重点是对软件开发的成果进行检查、控制。
8.确认是指如何决定最后的软件产品是否正确无误。
验证是指如何决定软件开发的每个阶段、每个步骤的产品是否正确无误,并与其前面的开发阶段和开发步骤的产品相一致。
确认和验证是有联系的,但也有明显的差别。
Boehm在1981年是这样来描述两者差别的:
确认要回答的问题是:
我们正在开发一个正确无误的软件产品吗?
验证要回答的问题是:
我们正开发的软件产品是正确无误的吗?
9.CMM软件评估与软件测试成熟度TMM无联系
10.软件测试方法可以从不同的角度进行分类:
按照是否执行程序划分
按照代码的可见性划分
按照测试的实施者划分
按照测试过程划分
针对软件特定特征的测试
11.静态测试是指不利用计算机运行被测试的程序,而是通过人工的方式对程序或相关文档进行检查以达到检测目的的方法。
动态测试就是通过执行被测程序,并监视其执行状态、收集并对比其执行结果以判断程序是否正确运行的方法。
12.静态测试主要包含的方法有:
桌面检查（desktopcheck一种最为传统的方法,由程序员检查自己编写的程序。
程序员在程序通过编译之后,对源程序代码进行分析、检验,并补充相关的文档,目的是发现程序中的故障。
由于程序员熟悉自己的程序及其程序设计风格,桌面检查由程序员自己进行可以节省很多的检查时间,但应避免主观片面性。
同行评审（peerreview由若干程序员和测试员组成一个审查小组,通过阅读、讨论和争议,对程序进行静态分析的过程。
通常分两步进行:
小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员,作为审查的依据。
小组成员在充分阅读这些材料后,进入评审的第二步。
召开评审会。
在会上,首先由程序员逐句讲解程序的逻辑。
在此过程中,程序员或其他小组成员可以提出问题,展开讨论,审查缺陷是否存在。
实践表明,程序员在讲解过程中能发现许多原来自己没有发现的错误,而讨论和争议促进了问题的暴露。
代码走查（codewalkthrough代码走查同样也分两步进行:
第一步也是把材料先发给走查小组成员,让他们认真研究程序,然后再开会。
开会的程序与同行评审不同,不是简单地读程序和对照错误检查单进行检查,而是让与会者“充当”计算机,即首先由测试组成员为所测程序准备一批有代表性的测试用例,提交给走查小组。
走查小组开会,集体扮演计算机角色,让测试用例沿程序的逻辑进行运行一遍,
随时记录程序的执行轨迹,供分析和讨论用。
走查人员借助测试用例的媒介作用,对程序的逻辑和功能提出各种疑问,结合问题开展热烈的讨论和争议,能够发现更多的问题。
13.功能性测试,又称作黑盒测试、基于规格说明的测试等,是通过软件的外部表现来发现其缺陷和错误,检查程序是否按照需求规格说明书的规定正常实现。
结构性测试,又称作白盒测试、基于程序的测试等,通过分析程序的内部结构,以覆盖程序结构元素为目标的一类测试方法的总称
在结构性测试中可使用各种测试方法的综合策略如下:
在测试中,应尽量先用工具进行静态结构分析。
测试中可采取先静态后动态的组合方式:
先进行静态结构分析、代码检查和静态质量度量,再进行覆盖率测试。
利用静态分析的结果作为引导,通过代码检查和动态测试的方式对静态分析结果进行进一步的确认,使测试工作更为有效。
覆盖率测试是白盒测试的重点,一般可使用基本路径测试法达到语句覆盖标准;对于软件的重点模块,应使用多种覆盖标准衡量代码的覆盖率。
在不同的测试阶段,测试的侧重点不同:
在单元测试阶段,以代码检查、逻辑覆盖为主;在集成测试阶段,需要增加静态结构分析、静态质量度量;在系统测试阶段,应根据黑盒测试的结果,
采取相应的白盒测试。
14.过错缺陷:
是指在实现软件过程中对某些功能进行了错误的实现而引起的一类软件缺陷。
遗漏缺陷:
是指在实现软件过程中遗漏对某些功能的实现而引起的一类软件缺陷
15.功能性测试遗漏缺陷
结构性测试过错缺陷
能力强
16.灰盒测试结合了白盒测试盒黑盒测试的要素,是两者的折中
17.按照测试实施的组织,软件测试通常可以划分为如下三类:
开发方测试:
通常也叫“验证测试”或“α测试”。
用户方测试:
通常也叫β测试
第三方测试:
介于软件开发方和用户方之间的测试组织实施的测试活动。
是由在技术、管理和财务上与开发方和用户方相对独立的组织进行的软件测试。
一般情况下是在模拟用户真实应用的环境下,进行软件确认测试。
18.功能性测试v.s.结构性测试
19.按照测试过程,通常可以划分为如下四个步骤:
单元测试（UnitTesting:
又称为模块测试,针对软件设计的程序模块进行正确性检验的测试工作
集成测试（IntegratedTesting:
集成测试也叫组装测试,通常是在单元测试的基础上,对由若干个模块组装而成的子系统实施的测试。
确认测试（ValidationTesting:
验证软件的功能和性能及其他特性是否与用户的要求一致。
系统测试（SystemTesting:
是将通过集成测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起,在实际或者模拟运行（使用环境下,对计算机系统进行的一系列测试。
验收测试（AcceptanceTesting:
验收测试往往不是对系统进行全覆盖测试,而是针对用户的核心业务流程进行的测试。
20.单元测试要解决的问题:
模块接口:
对于被测模块,信息能否正常无误地流入和流出。
（应首先检验
局部数据结构:
在模块工作过程中,其内部的数据能否保持其完整性,包括内部数据的内容、形式及相互关系不发生错误。
边界条件:
在为限制数据加工而设置的边界处,模块是否能够正常工作。
覆盖条件:
模块的运行能否做到满足特定的逻辑覆盖。
出错处理:
模块工作中发生了错误,其中的出错处理设施是否有效。
21.驱动模块（driver:
用以模拟被测模块的上级模块。
桩模块（stub:
用以模拟被测模块工作过程中所调用的模块。
22.集成测试的分类:
非增量式集成测试
增量式集成测试
1.自顶向下集成测试:
将模块按系统程序结构,沿控制层次自顶向下进行组装。
、
测试实施步骤:
（1首先以主模块作为所测模块兼驱动模块,所有直属于主模块的下属模块全部用桩模块代替,对主模块进行测试。
（2再采用深度优先或广度优先的策略,用实际模块代替相应的桩模块,再用桩模块代替它们的直接下属模块,与已测试的模块或子系统组装成新的子系统。
（3然后测试新组装成的子系统,排除组装过程中引入新错误的可能,直至所有模块均组装到系统中为止。
优点:
（1在测试过程中较早地验证了主要的控制和判断点,能较早地发现主要控制方面的问题。
（2如果选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能,可先对逻辑输入的分支进行组装和测试,检查和克服潜藏的错误和缺陷,验证其功能的正确性,为对其后分支的组装和测试提供了保证。
缺点:
（1在测试需要建立桩模块,而要使桩模块能够模拟实际子模块的功能十分困难。
（2涉及复杂算法和真正输入/输出的模块一般在底层,它们是最容易出问题的模块,到组装和测试的后期才遇到这些模块,一旦发现问题,就会导致过多的重复测试。
2.
自底向上集成测试:
实施步骤:
（1首先由驱动模块控制最底层模块的并行测试,也可以把底层模块组合成实现某一特定软件功能的簇,由驱动模块控制它进行测试。
（2再用实际模块代替驱动模块,与它已测试的直属子模块组装成为子系统。
（3然后为子系统配备驱动模块并进行新的测试,直至组装达到主模块为止。
优点:
（1不需要桩模块,而建立一个驱动模块一般比建立桩模块容易。
（2由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试,可以把容易出问题的部分在早期解决。
（3可以实施多个模块的并行测试,从而提高测试效率。
缺点:
程序一直未能作为一个实体存在,直到最后一个模块加上去后才形成一个实体。
也就是说,在自底向上组装和测试的过程中,对主要的控制直到最后才接触到。
23.V模型
V模型是软件开发瀑布模型的变种,它反映了测试活动与分析和设计的关系,从左到右,描述了基本的开发过程和测试行为,非常明确地表明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
V模型的软件测试策略既包括低层测试又包括了高层测试,低层测试是为了源代码的正确性,高层测试是为了使整个系统满足用户的需求。
V模型的局限性:
仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。
容易使人理解为测试是软件开发的最后的一个阶段,主要是针对程序进行测试寻找错误,而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。
V模型的局限性在于没有明确地说明早期的测试,不能体现“尽早地和不断地进行软件测试”的原则。
改进措施:
在V模型中增加软件各开发阶段应同步进行的测试,被演化为一种W模型,因为实际上开发是“V”,测试也是与此相并行的“V”。
W
模型
W模型的局限性:
W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。
开发和测试保持一种线性的前后关系,无法支持迭代、自发性以及变更调整。
24.软件测试信息流:
软件配置:
包括软件需求规格说明、软件设计规格说明、源代码等。
测试配置:
包括测试计划、测试用例、测试驱动程序等。
实际上,在整个软件工程中,测试配置只是软件配置的一个子集。
测试工具:
为测试的实施提供某种服务,以减轻测试任务中的手工劳动。
例如:
测试数据自动生成程序、静（动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。
25.回归测试（RegressionTesting:
在软件维护过程中,为了确保修改代码或新增功能的正确性,并保证修改部分不带来副作用的测试活动称之为回归测试。
回归测试的基本过程:
（1识别出软件中被修改的部分。
（2从原基线测试用例库T中,排除所有不再适用的测试用例,确定那些对新的软件版本依然有效的测试用例,其结果是建立一个新的基线测试用例库T0。
（3依据一定的策略从T0中选择测试用例测试被修改的软件。
（4如果必要,生成新的测试用例集T1,用于测试T0无法充分测试的软件部分。
（5用T1执行修改后的软件。
第（2和第（3步测试验证修改是否破坏了现有的功能,第（4和第（5步测试验证修改工作本身。
26.测试用例的维护主要内容包括下述几个方面:
（1删除过时的测试用例。
（2改进不受控制的测试用例:
一些对输入或运行状态十分敏感的测试用例→测试不容易重复且结果难以控制。
（3删除冗余的测试用例。
→测试用例集约简
（4增添新的测试用例。
26.在组织回归测试时需要注意两点:
首先是各测试阶段发生的修改一定要在本测试阶段内完成回归,以免将错误遗留到下一测试阶段。
其次,回归测试期间应对该软件版本冻结,将回归测试发现的问题集中修改,集中回归。
27.功能性测试方法
1.边界值测试
2.等价类（划分测试:
把所有可能的输入数据,即程序的输入域划分成若干部分,然后从每个部分中选取少数代表性数据当作测试用例。
两个步骤:
（1划分等价类;
划分原则（1如果输入条件规定了取值范围,或值的个数,则可以确立一个有效等价类和两个无效等价类。
例如,在程序的规格说明中,对输入条件有一句话:
“„„项数可以从1到999„„”则有效等价类是“1≤项数≤999”,两个无效等价类是“项数<1”或“项数>999”。
在数轴
上表示成:
划分原则（2如果输入条件规定了输入值的集合,或者是规定了“必须如何”的条件,这时可确立一个有效等价类和一个无效等价类。
例如,在Pascal语言中对变量标识符规定为“以字母打头的„„串”。
那么所有以字母打头的构成有效等价类,而不在此集合内（不以字母打头的归于无效等价类。
划分原则（3如果输入条件是一个布尔量,则可以确定一个有效等价类和一个无效等价类。
划分原则（4如果规定了输入数据的一组值（假定n个,而且程序要对每个输入值分别进行处理。
这时可为每一个输入值确立一个有效等价类（共n个,此外针对这组值确立一个无效等价类,它是所有不允许的输入值的集合。
划分原则（5如果规定了输入数据必须遵守的规则,则可以确立一个有效等价类（符合规则和若干个无效等价类（从不同角度违反规则。
划分原则（6如果我们确知,已划分的等价类中各元素在程序中的处理方式是不同的,则应将此等价类进一步划分成更小的等价类。
（2选取测试用例。
例:
某程序规定:
“输入三个整数作为三边的边长构成三角形。
当此三角形为一般三角形、等腰三角形及等边三角形时,分别做计算...”试用等价类划分方法为该程序进行测试用例设计。
依据程序的需求规格说明,可以看出程序输入条件要求的关键之处有:
（1整数;（2三个数;（3非零数;（4正数
输出条件要求的关键之处有:
（5应满足两边之和大于第三边;（6等腰;（7等边
其中,（3、（4和（5并没有在题目上明显给出,但这些条件是必要的。
列出等价类表:
列出覆盖上述等价类的测试用例:
覆盖有效等价类的测试用例:
覆盖无效等价类的测试用例:
3.判定表测试方法:
判定表（决策表是分析和表达多逻辑条件下执行不同操作的情况下的工具。
判定表的建立步骤:
（根据软件规格说明
1.确定条件及其可能的取值;
2.确定规则的个数;
3.确定动作项;
4.填入条件项的可能取值;
5.针对每一条规则,填入恰当的动作项值;
6.验证规则是否正确;
7.化简规则。
条件桩（ConditionStub:
列出了问题的所有条件,通常认为列出的条件的次序无关紧要。
动作桩（ActionStub:
列出了问题规定可能采取的操作,这些操作的排列顺序没有约束。
条件项（ConditionEntry:
列出针对它左列条件（即条件桩的取值。
动作项（ActionEntry:
列出在条件项的各种取值情况下应该采取的动作。
规则（Rule:
任何一个条件组合的特定取值及其相应要执行的操作。
在判定表中贯穿条件项和动作项的一列就是一条规则。
4.因果图测试方法
因果图测试方法的基本步骤
1、分析软件规格说明描述中,哪些是原因（即输入条件或输入条件的等价类,哪些是结果（即输出条件,并给每个原因和结果赋予一个标识符。
2、分析软件规格说明描述中的语义,找出原因与结果之间、原因与原因之间的关系。
根据这些关系,画出因果图。
3、标明原因与原因之间,原因与结果之间不可能出现的组合情况地约束或限制条件。
4、把因果图转换成判定表。
5、把判定表的每一列拿出来作为依据,设计测试用例。
例:
设要对一个自动饮料售货机软件进行黑盒测试,该软件的规格说明如下:
有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。
若投入1元5角硬币,按下“可乐”、“雪碧”或“红茶”按钮,相应的饮料就送出来。
若投入的是2元硬币,在送出饮料的同时退还5角硬币。
首先,可以列出原因和结果如下:
原因:
（1投入1元5角硬币;（2投入2元硬币;（3按“可乐”按钮;（4按“雪碧”按钮;（5按“红茶”按钮。
中间状态:
（11已投币;（12已按钮。
结果:
（1退还5角硬币;（2送出“可乐”饮料;（3送出“雪碧”饮料;（4送出“红茶”饮料。
根据原因和结果,可以设计这样一个因果图如下:
转换为测试用例,如下表所示,每一列可作为确定测试用例的依据
5.组合测试方法用在两个方面：
1.程序输入；2.配置空间正交设计试验：
假定有一个3因子3水平的测试问题，其中三个因素分别记为A、B和C，三个水平则分别用1、2、3表示。
如果取三因子所有水平的组合，则可以得到：
简单对比法：
首先固定B、C于B1、C1，使A变化：
如得出结果A3最好，则固定A于A3，C还是C1，使B变化：
得出结果以B2为最好，则固定B于B2，A于A3，使C变化：
28.测试用例：
就是事先设计的程序的一种执行情形，主要由测试数据与期望结果构成。
看程序在测试数据的输入下，能否正常运行并且达到所设计的预期执行结果。
29.程序插装就是向程序中插入一条或是多条语句，以便监视程序的某方面的执行特征或行为。
分类：
语句覆盖插装；边覆盖插装；断言插装
30.控制流分析（ControlFlowAnalysis,CFA就是发现一个过程（方法中的控制流，并用适当的形式表达出来，可扩展到过程（方法间。
常见的控制流表示方式有两种：
（1抽象语法树AST，主要用于程序编译处理阶段，进行程序控制逻辑的存储与优化；（2控制流图CFG，是在AST基础上更高层的抽象表示，能较好地可视化表示程序中语句、模块之间的执行顺序和相互调用关系，被公认是当今程序分析、理解与测试的基础。
此外，还有一些基于形式语义的分析与表示方法。
31.控制流图CFG是一有向图G=（N,E,nentry,nexit.其中，N是节点集，程序中的每个语句都对应图中的一个节点；边集E={|n1,n2∈N且n1执行后，可能立即执行n2}；nentry和nexi分别为程序的入口和出口节点。
程序控制流图的绘制：
程序语句格式化、规范化处理；识别程序的逻辑行；根据程序逻辑行之间的控制关系绘制CFG图；在CFG图上作适当的标记，例如入/出口、真假分支等。
32.基本块（BasicBlock是由连续的语句或表达式组成的序列，仅能从它的唯一入口进入且仅能在末端的唯一出口转移控制，若其中的某一语句节点被执行，则所有的语句节点均能被执行。
这里假定不会因为基本块中的异常而导致控制从语句序列的中间部分转移出去。
33.几种常见的面向控制流的测试方法（或覆盖率：
语句覆盖测试,SC/NC判定覆盖（分支覆盖测试,DC/BC条件覆盖测试,CC条件判定覆盖测试,CDC多条件覆盖测试,MCC修正的条件判定覆盖测试,MCDC是在保证具备相当于MCC的覆盖能力的同时，减少测试用例数目的一种方法。
示例程序：
01intfunction（boola,boolb,boolc
{intx;02x=0;03if（a&&（b||c04x=1;05returnx;06}基本路径覆盖测试,PC是在控制流图的基础上，通过分析控制结构的环形复杂度，导出执行路径的基本集，再从该基本集设计测试用例。
示例程序一：
物理行逻辑行程序代码0101floatavg（02{03charch;04intcount,sum;05floataverage;0602count=0;0703sum=0;0804ch=getchar（;0905while（ch!
=‘\n’{1006if（isdigit（ch{1107sum+=ch-48;1208count++;1309}14else1510printf（“%cisabadinput!
”,ch;1611
升级会员 