软件测试.docx
《软件测试.docx》由会员分享，可在线阅读，更多相关《软件测试.docx（27页珍藏版）》请在冰豆网上搜索。
软件测试
1.选择题：
软件测试的目的（c）
A.避免软件开发中出现的错误
B.发现软件开发中出现的错误
C.尽可能发现并排除软件中潜藏的错误，提高软件的可靠性
D.修改软件中出现的错误
2.请概括静态测试与动态测试的不同点
是否运行程序。
静态测试是不运行被测试程序，对代码通过检查、阅读进行分析。
动态测试是真正运行被测程序，在执行过程中，通过输入有效的测试用例对其输入与输出的对应关系进行分析。
3．变量的命名规则一般规定如下：
变量名的长度不多于40个字符，第一个字符必须为英文字母，其他字符可以是英文字母、数字以及下划线的任意组合。
请用等价类划分法设计测试用例
4．在银行业务信息系统中，有三个输入条件：
A——活期存折账户，B——正确的密码输入，C——一本通账户（活期、定期合并在一本通存折上）；有两个输出结果：
e——显示活期账户信息，f——显示定期账户信息。
如果同时满足A、B，或者同时满足B、C，就会有e；如果同时满足B、C，则会有f。
请用因果图法设计以上描述的测试用例。
（1）将原因和结果分开。
原因：
A—活期存折账户
B——正确的密码输入
C——一本通账户
结果：
e——显示活期账户信息
f——显示定期账户信息
（2）绘制因果图。
画出约束条件
（3）将因果图转换成决策表
（4）设计测试用例。
根据上一步中的决策表，A和C同时为1的两列是不可能的，需要排除。
所以，可设计出6个测试用例：
1：
输入数据——使用活期存折账户并输入正确的密码；预期结果——显示活期账户信息
2：
输入数据——使用活期存折账户，未进行其他操作；预期结果——没有显示
3：
输入数据——使用一本通账户并输入正确的密码；预期结果—显示活期和定期账户信息
4：
输入数据——直接输入正确密码；预期结果——没有显示
5：
输入数据——使用一本通账户，未进行其他操作；预期结果——没有显示
6：
输入数据——未进行任何操作；预期结果——没有显示
5．有一个处理单价为5角钱的饮料自动售货机，软件测试用例的设计规格说明如下：
若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。
若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。
解法如下：
1）将原因和结果分开。
原因：
结果：
1——售货机有零钱找21——售货机〖零钱找完〗灯亮
2——投入1元硬币22——退还1元硬币
3——投入5角硬币23——找回5角硬币
4——押下橙汁按钮24——送出橙汁饮料
5——押下啤酒按钮25——送出啤酒饮料
2）因果图。
建立中间结点，表示中间状态:
11——投入1元硬币且押下饮料按钮12——押下〖橙汁〗或〖啤酒〗的按钮
13——应当找5角零钱并且售货机有零钱找14——钱已付清
3）画出约束条件。
由于2与3，4与5不能同时发生，分别加上约束条件E。
4）将因果图转换成决策表
5）设计测试用例。
1：
输入——售货机有零钱找、投入1元硬币、押下澄汁按钮预期结果——退还5角硬币、送出澄汁饮料
2：
输入——售货机有零钱找、投入1元硬币、押下啤酒按钮预期结果——退还5角硬币、送出啤酒饮料
3：
输入——售货机有零钱找、投入1元硬币预期结果——无动作
4：
输入——售货机有零钱找、投入5角硬币、押下澄汁按钮预期结果——送出澄汁饮料
5：
输入——售货机有零钱找、投入5角硬币、押下啤酒按钮预期结果——送出啤酒饮料
6：
输入——售货机有零钱找、投入5角硬币预期结果——无动作
7：
输入——售货机有零钱找、押下澄汁按钮预期结果——无动作
8：
输入——售货机有零钱找、押下啤酒按钮预期结果——无动作
9：
输入——售货机没零钱找、投入1元硬币、押下澄汁按钮预期结果——售货机〖零钱找完〗灯亮、退还1元硬币
10：
输入——售货机没零钱找、投入1元硬币、押下啤酒按钮预期结果——售货机〖零钱找完〗灯亮、退还1元硬币
11：
输入——售货机没零钱找、投入1元硬币预期结果——售货机〖零钱找完〗灯亮、无其它动作
12：
输入——售货机没零钱找、投入5角硬币、押下澄汁按钮预期结果——售货机〖零钱找完〗灯亮、送出澄汁饮料
13：
输入——售货机没零钱找、投入5角硬币、押下啤酒按钮预期结果——售货机〖零钱找完〗灯亮、送出啤酒饮料
14：
输入——售货机没零钱找、投入5角硬币预期结果——售货机〖零钱找完〗灯亮、无其它动作
15：
输入——售货机没零钱找、押下澄汁按钮预期结果——售货机〖零钱找完〗灯亮、无其它动作
16：
输入——售货机没零钱找、押下啤酒按钮预期结果——售货机〖零钱找完〗灯亮、无其它动作
6．白盒测试是_结构_测试，被测对象是_源程序_，以程序的_内部逻辑_为基础设计测试用例
7．逻辑覆盖式对程序内部有判定存在的逻辑结构设计测试用例，根据程序内部的逻辑覆盖程度又可分为语句覆盖，判定覆盖，条件覆盖，判定-条件覆盖，条件组合覆盖，路径覆盖6种覆盖技术
8．实际的逻辑覆盖测试中，一般以条件组合覆盖为主设计测试用例，然后再补充部分用例，以达到路径覆盖测试标准。
9．覆盖语句最强的是（D）
A．语句覆盖B.判定覆盖C.条件覆盖D.路径覆盖
10．发现错误能力最弱的是（A）
11．判断题：
软件的Bug就是指程序运行时出现的故障。
（错）
这句话不全面，因为文档也是软件的一部分，文档中的错误也是bug；另外，如果我们运行一个软件，没有产生任何故障，但是软件实现的功能不是我们需要的，这也是bug。
软件的bug指的是软件中（包括程序和文档）不符合用户需求的问题。
12.简答题：
1.ATM机的吞卡现象是不是Bug？
不一定。
要具体分析，如果是一种保护用户的行为就不是Bug（比如多次输入密码错误），如果是在正常的操作过程中吞卡，则是Bug。
2.需求分析、系统设计所存在的问题在软件缺陷中占有较大比例，对软件测试工作有何启发？
对软件进行充分的测试才能够有效的保证软件质量。
测试要从需求分析时就开始，问题发现得越早越好，发现缺陷后要尽快修复，从而降低修复成本。
13．使用控制流测试方法完成教材P88页第7题：
（1）分别以语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖方法设计测试用例，并写出每个测试用例的执行路径。
（2）画出程序的控制流图。
用基本路径测试方法设计测试用例。
1.要满足语句覆盖，执行路径通过：
1→2→3→4→5即可。
可设计测试用例：
A=4B=0X=8（路径1→2→3→4→5）
2.要满足判定覆盖，两个判定表达式的取真和取假分支都要走到，执行路径通过：
1→3→5和1→2→3→4→5即可：
1:
A=4B=0X=8（路径1→2→3→4→5覆盖条件:
TATB）
2:
A=1B=1X=1（路径1→3→5覆盖条件:
~TA~TB）
3.要满足条件覆盖，每个判定中的每个条件的可能取值都要取到，即：
T1T2T3T4~T1~T2~T3~T4。
观察前面设计测试用例：
1:
A=4B=0X=8（路径1→2→3→4→5覆盖条件:
T1T2T3T4）
2:
A=1B=1X=1（路径1→3→5覆盖条件:
~T1~T2~T3~T4）
上述测试用例覆盖了4个条件产生的8种情况。
4.可见，这组测试用例同时覆盖了两个判定的取真分支和取假分支以及4个条件产生的8种情况，所以它们满足判定-条件覆盖的标准。
5.要满足条件组合覆盖，每个判定中各条件的每一种组合至少要出现一次，在两个判定中有8种可能的组合：
①A>2,B=0:
T1,T2②A>2,B≠0:
T1,~T2
③A≤2,B=0:
~T1,T2④A≤2,B≠0:
~T1,~T2
⑤A=4,X>1:
T3,T4⑥A=4,X≤1:
T3,~T4
⑦A≠4,X>1:
~T3,T4⑧A≠4,X≤1:
~T3,~T4
设计测试用例：
（沿用前面两个测试用例）
1:
A=4B=0X=8（路径1→2→3→4→5覆盖条件:
T1T2T3T4①⑤）
2:
A=1B=1X=1（路径1→3→5覆盖条件:
~T1~T2~T3~T4④⑧）
3:
A=4B=1X=1（路径1→3→4→5覆盖条件:
T1~T2T3~T4②⑥）
4:
A=0B=0X=4（路径1→3→4→5覆盖条件:
~T1T2~T3T4③⑦）
6.要满足路径覆盖，每一条可能的路径至少执行一次，可能的路径包括：
1→3→5；1→2→3→4→5；1→3→4→5；1→2→3→5。
观察条件组合覆盖的测试用例，可以保留前三个，再增加下面一个新的用例即可：
1:
A=1B=1X=1（路径1→3→5覆盖条件:
~T1~T2~T3~T4④⑧）
2:
A=4B=0X=8（路径1→2→3→4→5覆盖条件:
T1T2T3T4①⑤）
3:
A=4B=1X=1（路径1→3→4→5覆盖条件:
T1~T2T3~T4②⑥）
4:
A=3B=0X=0（路径1→2→3→5覆盖条件:
T1T2~T3~T4①⑧）
设计测试用例
⏹基本路径数：
⏹流图的环形复杂度=5
⏹确定独立路径的基本集合。
⏹路径1：
1→1-1→1-2→2→3-1→3-2→5
⏹输入：
A=3，B=0，X=3；预期输出：
X=1
⏹路径2：
1→1-1→3-1→3-2→5
⏹输入：
A=0，B=0（任意），X=1；预期输出：
X=1
⏹路径3：
1→1-1→1-2→3-1→3-2→5
⏹输入：
A=3，B=1，X=1；预期输出：
X=1
⏹路径4：
1→1-1→1-2→2→3-1→4→5
⏹输入：
A=4，B=0，X=1；预期输出：
X=1
⏹路径5：
1→1-1→1-2→2→3-1→3-2→4→5
⏹输入：
A=3，B=0，X=6；预期输出：
X=3
⏹设计执行基本路径集合中每条路径的测试用例。
14.选择题：
以下关于集成测试的论述，正确的是（D）：
A.先对每个模块分别测试，然后统一组装成软件系统的方法称为渐增式测试。
B.自顶向下的集成测试本质上是非渐增式测试方法。
C.存根模块是渐增式测试方法中使用的，在非渐增式测试中用不到桩模块。
D.一般来说，存根模块和桩模块在用过以后，不会作为软件的正式模块而存在。
15.对图的程序进行三明治集成测试，试给出测试过程
第一图以B模块所在层为界进行三明治集成测试过程
16．判断正误：
安全性测试最终证明应用程序是安全的错
17．设计题：
假设163邮箱要求登录的时间最多不超过10秒钟，请设计一下163邮箱登录模块的性能、负载、压力、可靠性测试用例。
18．判断对错说明原因：
1.兼容性是一种产品特性，可以有不同程度的符合标准。
对。
软件的兼容性取决于客户的要求。
某字处理程序与其竞争的对手产品的文件格式不兼容或者新操作系统不支持某一类游戏软件，都是很正常的。
软件测试人员应该通过判断检查兼容性的工作量，为这些决定提供输入。
2.能够发布具有配置缺陷的软件产品。
可以。
永远不可能把软件缺陷全部修复。
在所有测试中，任何处理都是有风险的。
测试人员和测试小组需要决定哪些软件缺陷修复，哪些不修复。
决定发布时，可以留下的仅在少见的硬件中出现的不太重要的软件缺陷。
19．判断题：
所有软件都有用户界面，因此必须测试易用性。
（对）
验收测试的目标是使客户验收签字，并使系统符合事先约定的验收标准。
（对）
20．判断以下说法是否正确，为什么？
“制订测试进度要符合固定日期，比如测试设计阶段从下个月1号到20号共需要20天。
这样可以使大家对测试任务或测试阶段何时开始、何时结束没有异议”。
错。
因为测试对项目的其他方面非常依赖（例如，代码编写没有完成就不能执行测试），所以测试进度最好根据交付日期来制订
第一章软件测试概述
定义1：
1983年IEEE（国际电子电气工程师协会）提出的软件工程标准术语中给软件测试下的定义是：
a）“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”。
i.软件测试以检验软件是否满足需求为目标。
定义2：
软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去执行程序，以发现软件故障的过程。
b）该定义强调寻找故障是测试的目的。
定义3：
软件测试是一种软件质量保证活动，其动机是通过一些经济有效的方法，发现软件中存在的缺陷，从而保证软件质量。
软件测试是在一个可控的环境中分析或执行程序的过程，其根本目的是以尽可能少的时间和人力发现并改正软件中潜在的各种故障及缺陷，提高软件的质量。
c）一个好的测试是能够发现至今尚未被发现的故障。
d）一个成功的测试是发现了至今未被发现的故障。
单元测试：
又称为模块测试，目的是检测程序模块内部在逻辑上和功能上无故障存在。
单元测试的对象是软件设计的最小单位，与程序设计和编程实现关系密切。
一般由测试人员和编程人员共同完成。
依据：
模块详细设计说明书和源程序代码。
常采用白盒测试方法
集成测试：
又称为组装测试或子系统测试。
目的是发现与接口有关的模块之间的问题，即检测和排除与软件设计相关的程序结构问题。
集成测试的方法有非增量式集成和增量式集成两种，一般由测试人员和编程人员共同完成。
依据：
概要设计文档，采用黑盒测试为主，白盒测试为辅的方法
确认测试：
确认测试目的是对软件产品进行评估以确定其是否满足软件需求的过程，一般由测试人员完成
依据：
软件需求规格说明文档，采用黑盒测试方法
系统测试：
是针对系统中各个组成部分进行的综合性检验，目的不是要找出软件故障，而是要证明系统的性能，系统测试最好由独立的测试机构完成，一般应包括：
几个职业的系统测试专家、1~2个用户代表、1~2个软件设计师或者分析师
验收测试：
它的目的是向用户表明所开发的软件系统能够像用户所预定的那样工作。
验收测试是将最终产品与最终用户的当前需求进行比较的过程，应该在生产环境中而不是开发环境中进行
⏹软件测试误区：
⏹如果发布出去的软件有质量问题，都是软件测试人员的错
⏹软件测试技术要求不高，至少比编程容易多了
⏹有时间就多测试一些，来不及就少测试一些
⏹软件测试是测试人员的事，与开发人员无关
⏹根据软件开发瀑布模型，软件测试是开发后期的一个阶段
第二章黑盒测试
黑盒测试——把程序看作一个不能打开的黑盒子，只检查程序功能是否按照需求规格说明书的规定正常使用。
也叫做功能测试或者基于规格说明的测试。
黑盒测试用例设计主要有以下几种方法：
等价类划分法是依据程序规格说明书对输入范围进行划分，把所有可能的输入数据，即程序输入域划分为若干个互不相交的子集，称为等价类，然后从每个等价类中选取少数具有代表性的数据作为测试用例，进行测试。
★等价类划分测试用例设计的具体步骤：
为每一个等价类规定一个唯一的编号
设计一个新的测试用例，尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤，直到测试用例覆盖了所有的有效等价类。
设计一个新的测试用例，使其覆盖且只覆盖一个还没有被覆盖的无效等价类。
重复这一步骤，直至测试用例覆盖了所有的无效等价类
边界值分析法由于故障往往出现在定义域或值域的边界上，所以为检测边界附近的处理专门设计测试用例，通常都会取得很好的测试效果，具有很强的发现故障能力。
边界值分析是对有效等价类划分方法的补充
★边界值分析法测试用例设计步骤:
确定边界值情况（输入或输出等价类的边界）
选取正好等于、刚刚大于或刚刚小于边界值作为测试数据
因果图法从程序规格说明书的描述中找出因和果的关系，通过因果图转换成决策表，最后为决策表中的每一列设计一个测试用例
★因果图法测试用例的设计步骤：
确定软件规格中的原因和结果确定原因和结果之间的逻辑关系
确定因果图中的各个约束把因果图转换为决策表根据决策表设计测试用例
决策表法基于决策表的测试是最严格，最具有逻辑性的黑盒测试方法
决策表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格
决策表适合处理：
针对不同逻辑条件的组合值，分别执行不同的操作这样的问题。
★构造决策表的步骤：
列出所有的条件桩和动作桩确定规则的个数填入条件项
填入动作项，得到初始决策表简化决策表，合并相似规则
第三章白盒测试
⏹白盒测试是按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能。
（结构测试或逻辑驱动测试）
⏹白盒测试要求对被测程序的结构特性做到一定程度的覆盖，并以软件中的某类成分是否都已经得到测试为准则来判断软件测试的充分性，也称为基于覆盖的测试技术。
⏹白盒测试要求测试人员对程序的结构和处理过程有完全的了解，一般由开发工程师负责实施。
条件覆盖原则：
不考虑语句或分支是否被执行，因此它与语句覆盖之间没有包含关系，和判断覆盖之间也没有包含关系
⏹白盒测试中的其他测试方法：
⏹数据流测试——是面向程序中的变量的测试
⏹程序插装——借助被测程序中插入操作来实现测试目的的方法。
⏹程序变异测试——针对某类特定程序错误而进行的测试，是一种错误驱动测试。
⏹软件缺陷：
⏹从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；
⏹判定缺陷：
运行结果与需求规格说明书（用例中的预期结果）不一致。
⏹从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
⏹软件缺陷数目估计——播撒模型
第五章集成测试
⏹集成测试（IntegrationTesting）是在假定各个软件单元已经通过了单元测试的前提下，检查各个软件单元之间的相互接口是否正确。
又叫做组装测试或联合测试。
⏹集成测试按照集成粒度不同，可分成不同的层次：
⏹对于传统软件来说，把集成测试分为3个层次：
⏹模块间集成测试、子系统内集成测试、子系统间集成测试
⏹对于面向对象的应用系统来说，把集成测试分为2个层次：
⏹类内集成测试、类间集成测试
⏹集成测试的原则
⏹集成测试与系统测试的区别：
⏹测试对象
⏹测试时间
⏹测试方法
⏹测试内容
⏹测试目的
⏹测试角度
⏹集成测试与开发的关系
⏹集成测试是和软件开发过程中的概要设计阶段相对应的，而在软件概要设计中关于整个系统的体系结构就是集成测试用例输入的基础。
集成测试的策略
⏹当对两个以上模块进行集成时，不可能忽视它们和周围模块的相互联系。
⏹为模拟这些联系，需设置若干辅助测试模块，也就是连接被测试模块的程序段。
⏹驱动程序/驱动模块（driver），用以模拟被测模块的上级模块。
驱动模块在集成测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。
⏹桩程序/桩模块（stub），也有人称为存根程序，用以模拟被测模块工作过程中所调用的模块。
桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口。
非渐增式方法：
缺点发现错误难以诊断定位
⏹使用渐增方式把模块结合到程序中去时，有自顶向下、自底向上和三明治三种集成策略。
⏹自顶向下集成方法：
是从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来。
⏹注意：
深度优先和宽度优先的不同集成方式
⏹自底向上测试从“原子”模块（即在软件结构最底层的模块）开始组装和测试。
⏹因为是从底部向上结合模块，总能得到所需的下层模块处理功能，所以不需要桩模块。
⏹三明治集成——自两头向中间集成
⏹它是一种混合增量式测试策略，综合了自顶向下和自底向上两种集成方法的优点。
第六章系统测试
⏹系统测试一般由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的任务。
⏹系统不仅仅包括软件本身，还包括计算机硬件及其相关的外围设备，数据以及收集传输机构，甚至掌握计算机运行的人员及其操作等。
⏹系统测试是在更大的范围内进行的测试，着重对系统的性能、特性进行测试。
⏹定义：
⏹系统测试是将经过集成测试过后的软件，作为计算机系统的一个部分，与计算机硬件、某些支持软件、数据和人员等系统元素结合起来，在实际运行环境下对计算机系统进行一系列的严格有效的测试来发现软件的潜在问题，保证系统的运行。
⏹性能测试主要检验软件是否达到需求规格说明书中规定的各类性能指标，并满足一些性能相关的约束和限制条件。
⏹目的：
确认软件是否满足产品的性能需求，同时发现系统中存在的性能瓶颈，并对系统进行优化。
⏹实质就是通过测试确定系统运行时的性能表现，如得到运行速度、响应时间、占有系统资源等方面的系统数据。
⏹性能测试包括：
⏹评估系统的能力
⏹识别系统中的弱点
⏹系统调优
压力测试和性能测试
⏹压力测试、容量测试和性能测试的区别
⏹压力测试可以看作是容量测试、性能测试和可靠性测试的一种手段，不是直接的测试目标。
⏹压力测试的重点在于发现功能性测试所不易发现的系统方面的缺陷，而容量测试和性能测试是系统测试的主要目标内容，也就是确定软件产品或系统的非功能性方面的质量特征，包括具体的特征值。
⏹容量测试和性能测试更着力于提供性能与容量方面的数据，为软件系统部署、维护、质量改进服务，并可以帮助市场定位、销售人员对客户的解释、广告宣传等服务。
⏹压力测试、容量测试和性能测试的测试方法相通，在实际测试工作中，往往结合起来进行以提高测试效率。
⏹健壮性测试
⏹用于测试系统抵御错误（由于设计缺陷而带来的系统错误）的能力。
重点为当出现故障时，是否能够自动恢复或忽略故障继续运行。
⏹安全性测试
⏹是检查系统对非法侵入的防范能力，其目的是为了发现软件系统中是否存在安全漏洞。
⏹可靠性测试
⏹是以计算软件可靠性为目的的。
⏹通常使用平均无故障时间MTBF来衡量系统的可靠性。
MTBF越大，系统的可靠性越强。
⏹恢复性测试主要检查系统的容错能力。
当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。
⏹备份测试是恢复性测试的一个补充，也是恢复性测试的一个部分。
目的是验证系统在软件或者硬件失败时备份数据的能力。
⏹协议一致性测试主要测试协议实现是否严格遵循相应的协议描述。
⏹兼容性测试是指检查软件之间是否能够正确地进行交互和共享信息。
⏹安装性测试就是要验证系统成功安装的能力，并保证程序安装后能正常运行。
⏹可用性测试是对于用户友好性的测试，是指在设计过程中被用来改善易用性的一系列方法。
⏹配置测试是验证系统在不同的系统配置下能否正确工作，这些配置包括：
软件，硬件，网络等。
⏹文档测试主要针对系统提交给用户的文档进行验证，目标是验证软件文档是否正确记录系统的开发全过程的
升级会员 