01+02+03+11理论

软件测试期末练习题

https://download.csdn.net/download/weixin_52452443/88804224

01软件缺陷

1.什么是软件测试

IEEE中对软件测试的定义：
①在特定的条件运行系统或构件、观察或记录结果，对系统的某个方面做出评价。 （测试是评测）
②分析某个软件项以发现现存的和要求的条件之差（即错误）并评价此软件项的特性。（测试是度量）

2.什么是软件缺陷☆
出现了下述五个规则之一的情况才叫做发生了一个软件缺陷：（前四个与产品说明书有关，最后一个与用户有关）

①欠缺功能：软件未实现产品说明书要求的功能；
②错误功能：软件出现了产品说明指明不应该出现的错误；
③多余功能：软件实现了说明书未提到的功能；
④欠缺潜在功能软件未实现说明书虽未明确提及但是应该实现的功能；
⑤易用性差：软件难以理解、不易使用、运行缓慢或者—从测试员的角度看—最终用户会认为不好

软件缺陷产生的原因： **说明书**、设计、编码及其他

3.对软件开发来说,何时发现软件缺陷的意义是:发现得越晚，修复的代价越大，而且代价随时间增长是指数增加的

4.软件测试员的工作目标是尽可能早地发现软件缺陷并确保它得到修复。

5.下面算软件缺陷的是 ：

（1）软件没有实现说明书要求的功能:√
（2）软件实现了说明书没有提到的功能：√
（3）软件太大，占据硬盘空间太多：×
（4）软件出现了说明书中指明不应该的错误：√

6.软件测试员的终极目标：尽可能早地发现软件缺陷，并确保其得到修复”

7.软件测试员应具备的素质：

➢他们是群探索者；
➢他们是故障排除者；
➢他们不放过任何蛛丝马迹；
➢他们具有创造性；
➢他们是群追求完美者；
➢他们判断准确
➢他们注重策略和外交
➢他们善于说服

8.好的软件测试员应坚持不懈地追求完美:×

解析：不能过于钻牛角尖,好的测试员知道何时完美无法企及,何时达到“够好”。

02软件测试模型

1.针对软件产品的测试，以下描述正确的是：软件产品的所有可交付部分都是测试对象

2.常用的软件开发模式：

①大爆炸模式：没有测试
②边写边改模式 ：测试在编写代码和修复软件缺陷的过程中非常重要
③瀑布模式：较适合测试的模式！严重问题是：因为测试仅在最后进行，所以一些根本问题可能出现在早期，但是直到准备发布产品时才可能发现！
④螺旋模式 ：软件测试人员最喜欢的模式！
⑤敏捷软件开发（极限编程）

3.软件测试模型☆

• V模型

①活动更加并行化，可以减少生存周期结束进行测试所需的时间
②通过事先为每种活动设计测试，实际上是在进行更好的事先确认，同样可以降低最后一刻暴露严重问题的风险
③测试由具有合适技能的人员进行设计

• W模型

W模型优点：
在V模型的基础上，增加了开发阶段的同步测试，形成W模型；
测试与开发同步进行，有利于尽早发现问题。

W模型缺点：
仍把开发活动看成是从需求开始到编码结束的串行活动，
只有上一个阶段完成后，才可以开始下一个阶段的活动，不能支持迭代、自发性以及变更调整。

• X模型
• 瀑布模型
• H模型

03风险论 杀虫剂 集成测试

完全测试程序是不可能的，软件测试不可能找出所有的缺陷；
软件测试是有风险的行为，没有缺陷的完美软件是不存在的

1.找出所有的软件缺陷，确保软件完美无缺是不可能的

➢ 输入量太大
➢ 输出结果太多
➢ 软件执行路径太多
➢ 软件说明书是主观的，可以说从旁观者的角度来看是缺陷

测试工作的目标是完全测试一个软件，并尽可能找出所有缺陷:×
能不能对一个软件进行完全测试，确认没有任何缺陷存在：×

2.为什么软件测试是有风险的行为

①如果选择了不测试所有的情况（一般来说是肯定的），也就是选择了 冒险。 因为总可能有些缺陷隐藏在哪怕是最平凡的或者最不可能的地方。
② 软件测试员不可能做全部测试，只能做不完全测试，而不完全测试就 可能漏过缺陷。
③测试一旦停止，缺陷就无法修复了，产品迟早要发布的，有缺陷的产品进入市场就蕴含着风险。
④测试停止得越早，没有测试的部分就越多，而含有缺陷的可能性就越大。
⑤ 反之，测试做得越多，成本就越高，产品发布的日期就可能越晚。

软件测试工作只能报告软件缺陷的存在，不能报告软件缺陷不存在

3.软件缺陷往往可能会成群出现

意味着在某部分发现的软件缺陷越多，通常说明还有更多的缺陷未发现；
反过来也是对的：如果在某个部分发现的缺陷很少或者没有，说明这一部分可能确实缺陷很少

*原因*：
1.程序员也有心情不好的时候
2.程序员往往犯同样错误
3.某些软件缺陷实际上是冰山一角：软件的设计或者体系可能出现基本问题，可能很多缺陷是来自同一个严重的原因

4.杀虫剂怪事----软件测试越多，软件缺陷对于测试的免疫能力也越强的现象

为了克服杀虫剂怪事，软件测试员必须不断编写不同的、新的测试程序、对软件的不同部分进行测试，才能找出更多的软件缺陷

*假如周一测试软件的某一功能，每小时发现一个新的软件缺陷，你认为周二将会以什么样的频率发现软件缺陷？*
**可能发现软件缺陷的速度继续保持原有的频率，甚至更低**
两个原因：
1.余下的软件缺陷与发现的软件缺陷成比例
2.杀虫剂现象---除非增加新的测试，否则反复执行同样的测试不会发现新的缺陷

5.不需要修复软件缺陷的原因：

并不是被找出来的软件缺陷都要修复的！决策过程通常由软件测试员、程序员和项目经理共同参与

原因：
➢ 没有足够的时间；
➢ 不算真正的软件缺陷；
➢ 修复的风险太大；
➢ 不值得修复

测试的原则

• 完全测试程序是不可能的
• 软件测试是有风险的行为
• 测试无法显示潜伏的软件缺陷
• 找到的软件缺陷越多，就说明缺陷越多
• 杀虫剂怪事----软件测试越多，软件缺陷对于测试的免疫能力也越强的现象。
• 并非所有的软件缺陷都需要修复
• 什么时候才叫做缺陷难以说清
• 产品说明书从来没有最终版本
• 软件测试是一项讲究条理的技术专业

6.软件测试的术语

①精确与准确

② 确认和验证：➢确认是保证软件符合产品说明书的过程；➢ 验证是保证软件满足用户的需要的过程。

符合产品说明书的软件未必在实际中满足用户的需要，因为产品说明书可能有错误或者不完善。

③质量和可靠性：
质量：软件满足用户要求，性能卓越
可靠性仅仅是质量的一个方面！
产品的可靠性或者产品多长时间崩溃的问题，或许很重要，但是常常不被（个人用户）考虑到。

关于现实中产品的质量和可靠性的关系：两者不一定是一致的，存在质量高但是可靠性 不高或者 可靠性高 质量不高的产品。

④测试和质量保证：

软件测试员的目标是尽可能找出软件缺陷，并确保缺陷得以修复；
质量保证人员(QA）的主要职责是创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法。
两者之间可能有一些交叉，测试是质量保证的手段之一

7.软件测试的执行阶段的四个阶段

单元测试->集成测试->确认测试->系统测试->验收测试

在底层进行的测试叫做单元测试，它测试基本模块；
单元经过测试，底层软件缺陷找出来并修复之后，集成在一起，对模块的组合进行测试叫做集成测试。
先做单元测试，再做集成测试

8.增量式和非增量式集成测试☆

非增量式集成测试：
把所有通过单元测试的模块一次性集成到一起进行测试，不考虑组件之间的互相依赖性及可能存在的风险。

优点：
①可以同时集成所有模块，充分利用人力、物力资源，加快工作进度。
②需要的测试用例数目少，因此测试用例设计的工作量相对比较小。
③测试方法简单、易行
缺点：
① 难以保证对各个模块之间的接口进行充分测试
②对全局数据结构的测试不够彻底
③ 难以进行错误定位和修改

增量式集成测试

• 自顶向下集成
  按照系统层次结构图，以主程序模块为中心，采用自上而下的对各个模块一边组装一边进行测试。分为深度优先集成与广度优先集成
• 自底向上集成
  从系统层次结构图或称软件的体系结构图的最底层模块开始进行组装的集成测试方式。
• 三明治集成
  是一种混合增量式集成测试方法，综合了自顶向下和自底向上两种集成方法的优点，也属于基于功能分解的集成。
• 基于调用图的集成
  以系统功能分解为基础，以模块调用图为基础进行的测试。分为成对集成和相邻集成。

其他集成方式：
基于路径的集成
UML协作图（序列图）集成
分层集成
基于功能的集成
高频集成
基于进度的集成、基于风险的集成、基于事件的集成、基于使用的集成等

9.什么是测试桩？什么是测试驱动?两者的区别是什么?

测试驱动：自底而上的递增测试，编写称为测试驱动的模块调用正在被测试的模块，测试驱动以和将来真正模块同样的方式挂接，向被测试模块发送测试用例数据，接受返回结果，验证结果是否正确。
测试桩：自顶而下的递增测试，编写称为测试桩的模块，替换底层模块，充当被测试模块的接口，向被测试模块发送数据）。
测试驱动和测试桩的区别是：
两者替换的部分不同，前者替换被测试模块的高层模块（来调用被测试模块），后者替换被测试模块 的底层模块（被被测试模块调用）。

10.α测试与β测试

α版本： 通过系统测试之后，软件已完全组装起来，接口方面的缺陷也已排除。
指软件开发公司组织内部人员模拟各类用户对即将面市软件产品进行测试，试图发现软件缺陷并修正。
α测试的目的是评价产品的FURPS（功能、可使用性、可靠性、性能和支持),得到β版本

β测试： 指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。
β测试的意义：①广告效应②调查市场③查找BUG

回归测试是当软件发生改变时，重新测试已经通过测试的测试区域，以验证修改的正确性及其影响。
目的：检验已经发现的缺陷有没有被正确修改和修改过程中有没有引发新的缺陷。

11配置测试、自动化测试、质量保证

关于配置测试
（1）一般情况下，都做配置测试，因为软件在某些硬件平台出现配置缺陷是常见的事情；
（2）有配置缺陷的产品仍然可以发布，如果软件仅在很少见的硬件上发生缺陷；保证软件产品在所有的硬件上都没有任何缺陷是不可能的。

1.在某些显卡上工作颜色失真:**配置缺陷** 2.和其它软件交换数据不正常:**兼容性缺陷**
3.软件按钮排布混乱，难以操作:**易用性缺陷**
4.软件在某种计算机硬件上不能正常工作:**配置缺陷**
5.软件与某种打印机冲突，无法正常打印:**配置缺陷**
6.软件与另一个软件交换数据出错:**兼容性缺陷**

特别测试的特点
（1）没有组织性，无法重复，也无法跟踪，完成后也无法证实曾经做过测试；（2）不能取代常规的测试
（3）不是每一个测试员必备的技术，有最好，没有也无所谓；
（4）不是软件测试工作必须做的。

测试中提到的所谓的“猴子”做的测试，指的是随机测试

一类自动化测试工具不是为帮助执行或者自动执行测试用例而设计的，其目标是模拟用户可能的操作，此类自动化测试工具叫做测试猴子

在产品发布之前，如果用模拟这些用户可能的操作方式来补充测试用例，就有可能发现一其他测试方式会漏掉的软件缺陷，这就是测试猴子的工作。

---

笨拙的猴子：一点也不了解被测试的软件，只是随机地单击鼠标或者敲击按键。（内存泄漏等缺陷）
半聪明的猴子：增加使其更有效的特性来提高猴子的智商，使其成为半聪明的猴子。（增加日志、特定软件测试、重启等功能）
聪明的猴子：增强了对环境的认知能力。它不单单随机乱敲键盘——而是有目的地敲。
◼真正聪明的猴子知道：
➢ 它在哪里
➢ 在那里能干什么
➢它能跑到哪里
➢ 它曾经在哪里
➢所见到的是否正确
➢ 聪明的猴子会阅读软件的状态转换图

测试共享和缺陷轰炸都意味着两个及以上测试员来测试软件同一区域或者特性

共享测试任务的有趣方法是安排缺陷轰炸：在一段时间内（一般为几个小时），整个测试小组停下常规的工作，参加轰炸——选择软件的某一区域，所有测试员集中测试这个区域或者这组特性。

选择区域可能是软件缺陷聚集之地，也可能是怀疑不存在软件缺陷的区域

---

另一种让他人验证和确认软件的常用过程称为beta测试。
beta测试是用于描述外部测试过程的术语，在该过程中，软件分发给选定的潜在客户群，让他们在实际环境中使用软件

由于时间紧张，项目经理决定不做内部测试，直接交给用户作 beta 测试，该做法是错误的，beta 测试不能取代正规的内部测试
关于 beta 测试:
（1）是把尚未发布的软件送给潜在的客户，请他们使用，帮助寻找缺陷；
（2）找出除了易用性、兼容性和配置缺陷之外的软件缺陷的能力很差；
（3）非常重要，绝不是可有可无的；（4）通常未经过 beta 测试的软件是不可靠的，不能正式发布的

哪一种缺陷容易被 beta 测试所发现的缺陷 
（1）配置缺陷（2）兼容性缺陷（3）易用性缺陷

软件测试计划是测试员与产品开发小组交流意图的主要方式
关于测试计划:
（1）必须制定计划；最终一定要形成一个书面的文档，但是这个文档并不重要，重要的是制定计划的过程
（2）计划不是一经制定、必须严格执行、决不能违背的，而是可以根据情况修改;
（3）制定进度计划不能制定固定日期，是相对日期;一个测试阶段结束，另一个测试阶段开始要有明确的进入和退出规则
（4）定义软件的质量和可靠性目标是测试计划的重要部分。
（5）制定测试计划不只是测试小组内部的事情，而是整个团队所有人员包括开发小组和项目经理都要参与。

随机测试的特点：
（1）通常借助随机测试工具来实现；（2）非常重要，不是可有可无的；
（3）但是它不能取代其他测试，只做随机测试而不做常规测试是不行的

分离和再现软件缺陷是技术含量最高、最困难的工作，是需要充分发挥侦探才干的地方。
◼ 好消息：不存在随机软件缺陷——如果建立完全相同的输入和完全相同的环境条件，软件缺陷就会再次出现。
◼ 坏消息：验明和建立完全相同的输入和完全相同的环境条件要求技巧性非常高，而且非常耗时。一旦 知道了答案，就显得很容易，当不知道答案时，就 显得很难。

---

分离软件缺陷的建议：
➢ 不要想当然地接受任何假设；
➢ 查找时间依赖和竞争条件的问题；
➢ 边界条件软件缺陷、内存泄露和数据溢出等白盒问题可能会慢慢自己显露出来；
➢状态缺陷仅在特定软件状态中显露出来；
➢ 要考虑资源依赖性和内存、网络、硬件共享的相互作用；
➢ 不要忽视硬件。
◼ 如果尽最大努力分离软件缺陷，也无法用简明的步骤再现，那么仍然需要记录软件缺陷，以免跟丢了

在报告软件缺陷时，测试员要对软件缺陷分类，以简明扼要的方式指出其影响，常用的分类是给软件缺陷划分严重性和优先级。
◼ 严重性：软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。
◼ 优先级：修复缺陷的重要程度和紧迫程度

常用划分方法清单：
◼ 严重性
1）系统崩溃、数据丢失、数据毁坏、安全性破坏；
2）操作性错误、结果错误、功能遗漏；
3）小问题、拼写错误、UI布局、罕见故障；
4）建议。
◼ 优先级：
1）立即修复，阻止了进一步测试，立竿见影；
2）在产品发布之前必须修改；
3）如果时间允许应该修复；
4）可能会修复，但是即使有产品也能发布。

导致软件无法启动的缺陷应当属于严重性 1 级、优先级 1 级

软件缺陷的生命周期
打开状态：测试员发现软件缺陷并
公布，软件缺陷进入打开状态
解决状态：程序员修复缺陷，进入解决状态
关闭状态：测试员做回归测试，证明
缺陷已修复，进入关闭状态
审查状态：如果暂时不能确定软件缺陷是否要修复，它进入审查状态；项目经理或者委员会(变动控制委员会)决定软件缺陷是否应该修复。
推迟状态：经高层会议审查的缺陷不予修复（进入关闭状态）或者推迟到下个版本修复（进入推迟状态）或者应予修复（回到打开状态）。

软件缺陷的生命周期的有哪三种基本状态？它们之间如何转换？
答：打开、解决、关闭。
测试员发现缺陷并公开，软件缺陷变成打开状态；
程序员修复之后，转入解决状态；
测试员做回归测试，确认缺陷已修复，进入关闭状态

关于软件缺陷的修复
（1）由于各种原因，被发现的软件缺陷是可能不予修复的；
（2）软件缺陷是否修复通常由专门的小组（审查委员会，高层）来决定，测试员无权擅自决定；
（3）不予修复的软件缺陷可能被完全忽略，也可能被推迟到后续版本中修复

（1）软件缺陷一经发现，必须修复，否则产品不能发布:**错误**；
（2）测试员可以决定不修复软件缺陷:**错误**；
（3）程序员可以拒绝修复软件缺陷，直接
通知测试员该缺陷取消:**错误**；
（4）被发现的软件缺陷是可能不予修复的，通常这由项目经理或者更高层决定:**正确**
如果测试工作中每天发现的软件缺陷数目持续明显下降至很少，通常说明 ：**测试工作临近结束**

如果程序员宣称已经修复了软件缺陷，测试员应该对该缺陷做回归测试，根据测试结果确定该缺陷是关闭还是重新打开。

回归缺陷：由于软件测试员永远不会放弃，因此原来认为已经修复、测试和关闭的缺陷可能会再次出现，这样的缺陷叫做回归缺陷

---

一旦记录了软件缺陷，就要跟踪其生命 周期，不要跟丢了，并且提供必要的信息驱使其得到修复和关闭。

质量的费用可分为两类：一致性费用和非一致性费用。
➢一致性费用指与一次性计划和执行测试相关的全部费用，用于保证软件按照预期方式运行。
➢ 如果发现了软件缺陷，必须花时间分离、报告和回归测试以保证其得以修复，则非一致性费用就会上涨

---

因为软件缺陷在软件发布之前发现，所以这些费用归属于内部失败
如果软件缺陷被遗漏并落到客户手中，就是代价昂贵的产品支持电话，可能还要修复、重新测试和发布软件——更糟糕的情况下，产品要召回或者卷入官司。这些也是不一致费用，属于外部失败

由于内部失败引起的一致性费用加上非一致性费用 小于 由外部失败引起的非一致性费用

尽早剔除软件缺陷，或者在理想的情况下一开始就没有软件缺陷，产品的开销就会比可能的情况要小，所以：质量是免费的！

软件测试员不负责软件的质量！即使软
件测试员竭尽全力使发现的软件缺陷都得以修复，也不能使质量本身低劣的产品变好——质量不是靠测试解决的！

多加测试员可以多发现软件缺陷，从而使产品变得更好——这是错误的想法。 ◼ 如果在名为“软件测试”的团队中工作，就要由测试经理负责项目小组了解软件测试员的角色定义。 赶不上进度和遗漏软件缺陷通常是大家争论的焦点。
因此，这一点最好在项目的测试计划中提前进行澄清。

质量保证人员(QA)：主要职责是检查和评价当前软件开发的过程，找出改进过程的方法，以达到防止软件缺陷出现的目的。
QA团队的的任务是保证产品具有高质量！

◼ 既然单靠软件测试不能保证产品的质量，那么软件QA团队如何实现目标呢？

答案是：
对项目进行近似完全的控制，建立标准和方法论，有条理地仔细监视和评估软件开发过程， 对发现的过程问题反馈解决建议，执行测试（或者 检查），拥有决定产品何时准备发布的授权。
让项目经理以实现“无缺陷”为目标，而不是使软件如期发布或者低于预算

全面质量管理：
◼ 用集中的质量保证团队来负责质量是不实际的，因为从事工作的人员（编写代码或者制作小工具）并不负责质量，所以他们不会设法实现质量保证的目的。
◼ 要想制造高质量的产品，需要创立从管理开始自上而下的质量文化，使全体人员共同承担责任

软件测试团队进行配置管理或者构造软件是不正常的，问题有两个方面：
➢ 占用了应该用于测试产品的资源；
➢ 测试团队的最终目标是破坏而不是建立，与承担软件的构造过程形成利益的冲突。
◼ 最好让程序员或者独立小组构造软件，测试应该专注于寻找软件缺陷。