软件测试和软件质量保证练习答案
- 格式:doc
- 大小:51.50 KB
- 文档页数:9
第一章 软件质量保证
练习答案
1、 软件质量的定义?
软件质量是软件产品满足使用要求的程度。对于软件质量的衡量,就是高质量的软件系统能够准时地交付给用户,所耗费的成本不超出预算,并且最重要的是,能够正常地运行.“正常地运行”意味着该软件必须尽可能没有缺陷(bug)。
2、 软件质量保证的定义?
软件质量保证是一系列系统性的活动,它提供开发出满足使用要求产品的软件过程的能力证据.
3、 质量控制中的测试技术有哪些?想一想各自的适用情况。
审查(Inspection):软件的一种基本测试方法,它以一系列典型问题为依据进行检测.
走查(Walkthrough):一对一的审查,比审查更加仔细.
回顾(Review):以发现软件中存在的错误和缺陷为目的的一种软件测试方法,它是在软件证实执行之前完成。
4、 SDLC各阶段的文档有哪些,各自的质量目标是什么?
请参照学生用书3-5页,对于各阶段的目标,抓住主要的要点。
5、 质量计划的手段和技巧分别有哪些?
A、效益成本分析
B、基本水平标准
C、流程图,包括因果图、系统程序流程图等
D、试验设计
6、质量控制的手段和技巧分别有哪些?
有以下控制的手段和技巧:检验、控制表、排列图、抽样调查统计、流程图和趋势分析等。
作业答案
1、判断是非:好的测试员不懈追求完美。
错。好的测试员知道何时完美无法企及,何时达到“够好”。
2、有没有质量很高但是可靠性很差的产品?请举例说明.
有可能,但是它取决于客户对质量的期望.不少人购买高性能跑车,认为提速、时速、式样、舒适度和装饰好就是高质量.此类汽车一般可靠性差,经常抛锚,修理费用昂贵,而车主不把可靠性差当作质量问题.
3、请思考,可能完全测试程序吗?
除了极短小的简单程序,完全测试需要太多的输入、输出和分支组合。此外,软件说明书也许不客观,可以用多种方式解释.
4、在学习完本章后,判断下列哪种方法会减少成本:
a、让客户去找缺陷 b、发现缺陷而不是预防它们
c、预防缺陷而不是发现它们
d、忽视小的缺陷
答案:c
第二章 测试技术
练习答案
1. 对
2. 错
3. 代码
4. 功能
5. 归纳法、演绎法和回溯法。
6. 对
7. 错
作业答案
1、列举软件测试原则
软件测试过程中需要创建试用例来“破坏系统”,但在设计用例之前,需要遵循以下几个原则:
➢ 完全测试程序是不可能的
➢ 软件测试是有风险的行为
➢ 测试无法显示潜伏的软件缺陷
➢ 找到的软件缺陷越多,就说明软件缺陷越多
➢ 并非所有软件缺陷都能修复
➢ 软件测试一项讲究条理的技术专业
2、d
3、a
第三章 测试工具
练习答案
1. b
2. 对
3. 错
4. 错
5. 对
作业答案
第1题答案:
Panorama2-C/C++的主要好处如下: 1. 全面:它支持 –—
➢ 错误较少和风险较小的编码;
➢ 使用图表理解、复查和检查代码;
➢ 对系统结构、类继承、控制流等的静态分析;
➢ 通过程序逻辑分析和图表来检查逻辑错误;
➢ 通过指定自下而上的测试顺序而不设计和使用占位程序函数来进行增量式的单元和集成测试;
➢ 代码执行频率分析(在分支/段级别);
➢ 对类模板、常规类、函数、块、分支、段和条件输出的基于.mak文件且面向对象的代码测试以及测试覆盖分析,同时以图形化方式显示测试结果并突出显示未执行的元素;
➢ 自动错误模拟;
➢ 测试执行监视;
➢ 在测试结果和需求/测试用例间进行跟踪;
➢ 数据(全局和静态变量)使用分析;
➢ 运行时错误分析和运行时错误定位(显示错误在源代码中的原始行数);
➢ 质量标准值设置;
➢ 突出相关代码并报告相关数据的安全代码修改;
➢ NFS网络中的客户端 – 服务器应用程序;
2. 自动化:只需输入.mak文件/批处理文件和测试脚本文件,所有的静态和动态分析结果都会自动生成.
3. 集成:所有的工具协同工作并共享一个增量式数据库。
4. 易于查看结果:程序的所有静态和动态分析结果都可以通过以不同颜色进行标记的图/图表来生动表示.
5. 易于使用:提供Motif/OpenLook/Widows GUI、在线帮助和逐步的演示指导。
Panorama2-C/C++的主要局限有以下几点:
1、中文显示问题(对于这个缺点,请教师和学员在上机安排过程中,注意自己的操作系统环境,在一些显示中可能会有乱码,但这些乱码一般不会影响对于最终)
2、使用自己的脚本技术,但这种脚本技术与其他的测试工具不兼容
3、需要执行。mak文件,而不是编译C程序后生成的.obj文件
4、仅能处理C/C++程序
5、界面不够友好
第四章 测试计划和单元测试
练习答案
1. 对 2. 对
3. 错
4. 等价划分
5. 白盒
6. 对
7. 对
作业答案
第1题答案:单元测试说明书由一系列单元测试用例组成.每个单元测试用例都应该包括四个基本要素:
➢ 单元的初始状态说明,这是测试用例的起点(仅适用于单元在各次调用之间保持状态不变的情形)
➢ 单元的输入,包括单元读入的任何外部数据的值
➢ 测试用例实际要测试的内容,根据单元的功能性以及在设计测试用例时采用的分析(例如,要测试单元中的哪些判定)来制订
➢ 测试用例的预期结果(测试用例的预期结果应该始终在执行测试之前在测试说明书中定义好)
第2题答案:制定单元测试说明书所包括的步骤:
步骤1 — 使它运行起来
任何单元测试说明书的第一个测试用例的目的都应该是尽可能以最简单的方式来执行被测试的单元.实际执行测试时,知道至少第一个单元测试能够执行将可以大大增强信心。如果执行不了的话,那么更可取的做法是进行简单的调试(例如从起点开始)。
合适的技术:
➢ 根据说明书进行的测试
➢ 等价划分
步骤2 – 正面测试
测试用例应该设计为能够表明被测试的单元实现了它应该实现的功能。测试设计者应该通读相关的说明书;每个测试用例应该测试说明书中的一条或多条陈述。涉及到多个说明书时,最好能够使测试用例的顺序与单元主要说明书上的陈述的顺序相对应。
合适的技术:
➢ 根据说明书进行的测试
➢ 等价划分
➢ 状态变换测试
步骤3–负面测试
应该改进现有的测试用例并且设计更进一步的测试用例,以表明软件没有实现任何未指明要完成的功能。此步骤主要依赖于错误猜测,依赖于测试设计者预测问题域的经验.
合适的技术: ➢ 错误猜测
➢ 边界值分析
➢ 内部边界值测试
➢ 状态变换测试
步骤4–特殊事项
测试用例应该设计为针对性能、安全需求和保密需求等问题。特别是在安全和保密方面,可以很方便地对测试用例进行特殊重点考虑,以帮助进行保密分析或安全分析和证明。针对保密问题和安全危险而设计好的测试用例应该在单元测试说明书中加以标识。此外,还应该在单元测试说明书中添加测试用例,以确保该单元所有可能的保密问题和安全危险都得到充分体现。
合适的技术:
➢ 根据说明书进行的测试
步骤5–覆盖测试
设计好的测试用例可能达到的测试覆盖率应该是可视化的。此外,可以在单元测试说明书中添加测试用例以达到特定的测试覆盖目标。设计好覆盖测试之后,就可以制定测试规程并执行测试。
合适的技术:
➢ 分支测试
➢ 条件测试
➢ 数据定义-使用测试
➢ 状态变换测试
步骤6–执行测试
根据上面五个步骤设计的测试说明书在大多数情况下都应该能为单元提供全面的测试。在此阶段,可以使用该测试说明书来制定实际的测试规程,这个测试规程将用于执行这些测试。测试规程的执行将识别单元中的错误,然后可以更正这些错误并对该单元重新进行测试。测试规程执行期间的动态分析将会测量测试的覆盖率,表明覆盖目标是否已经达到.于是,设计测试说明书的过程中还要有一个更进一步的覆盖完成步骤.
步骤7–覆盖完成
除代码本身外,单元内的处理过程可能没有其他结构说明书,这取决于组织对单元说明书的标准。制定测试说明书的过程中有可能会有人为的错误.结果,代码中可能存在一些复杂的判定条件、循环和分支,执行测试时,可能未达到它们的覆盖目标。在未达到覆盖目标情况下,应该进行分析以确定其背后的原因。
第3题答案:
错误猜测主要是凭经验,同时还需要诸如边界值分析等其他技术的一些辅助。凭借经验,测试设计者猜测特定类型的软件中可能出现的错误类型,并设计测试用例来找到它们。例如,如果有任何类型的资源是动态分配的,那么查找错误的一个好地方就是在解除资源分配的地方。是不是所有资源都正确地解除分配了,或者软件执行过程中是否丢失了某些资源?
由有经验的工程师来进行错误猜测可能是最有效地设计能发现错误的测试的唯一方法。定位准确的错误猜测能够找到很多其他测试用例设计技术容易遗漏的错误。
相反,任用不合适的人来进行错误猜测可能会浪费时间。在最大程度地利用现有经验并为此测试用例设计技术添加一些结构时,创建一个不同类型错误的检查列表是一个不错的想法。然后可以使用这个检查列表来帮助“猜测”错误可能在单元中的什么地方出现.应该根据从较早的单元测试中获得的经验来维护这个检查列表,以改进错误猜测的整体效率。
第五章 度量测试结果与缺陷管理
练习答案
1.c、d、e
2.每一处设计.
3.错误
作业答案
第1题答案:
缺陷可以定义成:
➢ 没有实现预定的使用需求或合理期望
➢ 与规格说明书或标准存在偏差
➢ 在与标准的一致性方面导致客户不满的任何问题
第2题答案
缺陷管理的实现分各个不同阶段逐步完成。这些阶段如下所示:
1. 缺陷标识、记录和报告
2. 缺陷的消除和跟踪
3. 缺陷度量和根由分析
4. 缺陷预防/过程改进
5. 软件开发生命周期所有阶段的测试
6. 安装测试工具
7. 缺陷管理问题包括:
a. 缺陷遗漏
b. 同类缺陷重复
8. 数据库更新不完全
9. 分类不严谨-每个缺陷都划分为其他类型
10. 用来攻击项目分类的缺陷数据
11. 很多不负责任的错误
12. 重置是一个瓶颈
13. 相同的缺陷重现