太原理工大学软件测试课后题答案

《太原理工大学软件测试课后题答案》由会员分享，可在线阅读，更多相关《太原理工大学软件测试课后题答案（9页珍藏版）》请在装配图网上搜索。

1、第一章 软件测试概述1. 对软件缺陷有什么真实的体验？ 当登录某网站购物完毕并退出后，忽然想查查购物时付账的总金额，于是按了浏览 器左上角的 “退回”按钮，就又回到了退出前的网页。该软件缺陷所属类别与软件产 品说明书的要求有关。2. 以客户为导向来讨论软件测试的理念和作用 判断软件是否存在缺陷的基本依据是软件的用户需求，软件功能特性就是为了满足用 户需求，不能满足用户需求的功能是有缺陷的。所以软件测试要服从用户需求，以用 户需求为依据，来对产品进行检验。软件测试的作用是尽可能多的发现软件中的错 误。3. 给软件测试下定义，它的内容是什么？ 软件测试是由“验证”和“有效性确认”活动构成的整体：“

2、验证”是检验软件是否已 正确地实现了产品规格书所定义的系统功能和特性；“有效性确认”是确认所开发的软 件是否满足用户真正需求的活动。4. 软件开发和软件测试是一种对立的关系吗？为什么？ 软件测试和软件开发并行的活动，使软件测试和软件开发相互协作、相互补充，构成 有机的软件开发整体。需求分析 定义譬序开发过腥測耐程k第二章 需求和设计评审1. 需求评审和设计评审可以同时进行吗？为什么？不能，需求评审一定要“从用户的角度”出发，基于用户需求，一切围绕用户需求进 行评审，而设计评审一般依据设计技术的评审标准和非功能性质量特性的设计评审要 求，采用分层评审和整体评审相结合的方法，经过整体评审到分层评审

3、，再从分层评 审到整体评审的过程，既能确保评审的深度，又能确保评审的一致性。2. 需求评审和设计评审有什么不同？从测试的观点看，产品需求评审是对需求的验证，属于静态测试，也是做好软件测试 和理解设计等的基础性工作。设计评审时，先从系统架构，整体功能结构上开始审查 系统的非功能特性是否得到完美实现，然后深入到功能组件，操作逻辑和用户界面设 计等各个方面的细节审查，力求发现任何不合理的设计以及设计缺陷，尽早地设计上 的问题得到纠正。3. 在需求评审过程中，最有效的方法是什么？ 在需求形成的过程中，最好采用分阶段评审方法进行多次评审，而不是在需求最终形 成后进行一次评审，分阶段评审可以将原本需要进行

4、的大规模评审拆分成各个小规模 的评审，降低了需求分析返工的风险，提高了评审的质量。4. 设计评审的难点在哪里？ 结构模型的设计错误总是会导致严重的设计问题或运作问题，严重时甚至会导致项目 无法完成以及影响业务。第三章 测试用例设计1. 测试用例的要素有哪些？ 标志符、测试项、测试环境要求、输入标准、输出标准、测试用例之间的关联2. 你认为提高测试用例质量的最有效的方法是什么？ 对测试用例进行集体的评审，能有效地提高测试用例的质量。3. 如何开展测试用例的评审？ 分析其设计思路，是否符合业务逻辑、是否符合技术设计的逻辑、是否可以和系统架构、组件等建立起完全的映射关系？ 在局部上，应有重有轻，抓住

5、一些测试的难点、系统的关键点，从不同的角度向 测试用例的设计者提问。 在细节上，检查是否遵守测试用例编写的规范或模板，是否漏掉每一元素、每项 元素是否描述清楚 检查表，提问4. 为什么要建立测试套件？它带来哪些益处？ 为了更有效地重复使用、执行测试用例。（测试套件是由一系列测试用例并与之关联 的测试环境组合而构成的集合，已满足测试执行的特定要求。通过测试套件，将服务 于同一个测试目标、特定阶段性测试目标或某一运行环境下的一系列测试用例有机地 组合起来 ）有效性、可复用性、易组织性、客观性、可评估性和可管理性、5. 为什么需要对测试用例进行更新和维护？客户的需求会发生变化、产品规格说明书相应地被

6、更新，系统设计可能会被调整， 程序实现的方法会被优化、细化。软件测试用例设计必然会做出相应的变化，增加新的 测试用例或修改已有的测试用例，删除一些不再适用的测试用例。随着产品版本的不断升级，软件测试用例也需要得到及时维护，有时还需要重构 对测试用例的结构进行调整，包括用例模块的合并和分解，确保每一个测试用例都是 有效的。第四章 软件测试自动化1. 自动化测试有什么优势？和手工测试有什么不同？ 自动化测试利用软件测试工具自动实现全部或者部分测试工作， 自动运行的速度快、 测试结果准确、高复用性、永不疲劳、可靠、独特的能力。手工测试是传统的测试方 法，由测试人员手工编写测试用例，缺点在于测试工作量

7、大，重复多，回归测试难以 实现。自动化测试是对手工测试的一种补充，自动化测试不可能完全替代手工测试，因为很 多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判 断。而仅仅依赖手工测试的话，则会让测试过于低效，尤其是回归测试的重复工作量 对测试人员造成了巨大的压力。因此，自动化测试仅仅是某些条件下手工测试的一种 补充，而无法全面取代手工测试。2. 如何有效地综合运用手工测试和自动化测试？举例 负载测试、性能测试和回归测试用自动化测试；复杂的逻辑判断、界面是否友好用手工测试。3. 在自动化测试实现过程中，最重要的技术是什么？脚本技术4. 针对小型和大型软件企业，分别讨论如何

8、有效地选择测试工具5. 谈谈你对测试自动化启动和实施的体会 测试周期缩短 更高质量的产品 软件过程更规范 高昂的团队士气 节省人力资源，降低企业成本 充分利用硬件资源，降低企业成本。第五章 单元测试和集成测试1. 为什么要进行单元测试？任务和目标是什么？ 原因：尽可能早的发现软件中存在的错误，降低软件质量成本；检查代码是否符合设计 和规范。单元测试的主要任务： （1）单元中所有独立执行路径测试（2）单元局部数据结构测试（3）单元接口测试 （4）单元边界条件测试（5）单元的各条错误处理通路测试（6）内存分析2. 黑盒测试方法和白盒测试方法有什么不同特点？谈谈其应用范围 黑盒测试方法（功能测试或数

9、据驱动测试）不考虑程序内部结构和逻辑结构，主要是用 来测试系统的功能是否满足需求规格说明书。黑盒测试方法主要运用于单元的功能和性 能方法的测试，以检验程序的真正行为是否与产品规格说明、客户的需求保持一致。 白盒测试方法（结构测试或逻辑驱动测试）根据模块内部结构，基于内部逻辑结构，针 对程序语句、路径、变量状态等来进行测试，检验程序中的各个分支条件是否得到满足、 每条执行路径是否按预定要求正确地工作。白盒测试方法主要应用在单元测试阶段，主 要是对代码级的测试，针对程序内部逻辑结构。3. 谈谈分支覆盖和条件覆盖之间的关系 分支覆盖（又叫判定覆盖），使得程序中每一个分支都至少被执行一次。条件覆盖使，

10、 程序中每一个条件至少有一次被满足。条件覆盖通常比分支覆盖强，但是也可能有相反的情况：虽然每个条件都取到了两个 不同的结果，判定表达式却始终只取一个值。4. 代码审查有哪些方法？如何更有效地实施代码审查？ 走查；会议评审；互为审查5. 比较自顶向下集成测试方法和自底向上集成测试方法各自的优缺点自顶向下集成测试一般不需要驱动程序，减少了测试驱动程序开发和维护的费 用；能够在测试阶段的早期验证系统的主要功能逻辑，越重要的模块能优先得到测 试；容易进行故障隔离和错误定位。但是桩模块的开发和维护费用大，桩模块不能反 映真实情况，重要数据不能及时回送到上层模块，导致测试不充分；涉及复杂算法和 真正I/O

11、的底层模块最易出问题，在后期才遇到导致过多的回归测试。自底向上集成测试一般不需要桩模块，而驱动程序比较容易建议；可以尽早的验 证底层模块的行为，提高了测试效率；容易对错误进行定位。但是直到最后一个模块 加进去之后才能看到整个系统的框架；驱动模块的设计工作量大；不能及时发现高层 模块设计上的错误。6. 你喜欢使用哪个单元测试工具？为什么？Junit、Junit+Ant构建自动的单元测试、Checkstyle （源程序是否与代码规范相符） /PMD （检查java源文件中潜在问题）与FindBug （不检查java源文件，查找java bytecode中的潜在bug）的使用、SourceMonit

12、or （检测代码复杂度）第六章 功能测试1. 你认为功能测试的挑战来自于哪些地方？2. 如何综合运用因果图法和决策表方法？ 直接对输入条件进行组合设计决策表，不需要进行因果分析，即直接采用决策表方 法。可以由因果图导出，可以优化决策表。3. 决策表方法和正交测试方法有什么联系和区别？4. 在可用性测试中应注意哪些方面？5. 在回归测试中，如何在提高执行效率和降低风险性方面获得平衡？ 回归测试的目的： 1所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新 的运行环境等；2不影响软件原有功能的正确性。回归测试的方法：1再测试全部用例2基于风险选择测试3基于操作剖面选择测试4

13、再测试修改的部分6. 你愿意选择开源功能测试工具还是商业的功能测试工具，为什么？第七章 国际化和本地化测试1. 软件国际化、本地化、全球化的概念及关系国际化（I18N）：为保证所开发的软件能适应全球市场的本地化工作而不需要对程序做 任何系统性或结构性变化的特性。（这种特性通过特定的系统设计、程序设计、编码方 法来实现。）本地化（L10N）：将一个软件产品按特定国家或地区的特定需要而进行全面制定的过 程。（即在源语言版本的基础上，通过翻译、定制和参数配置等工作，使软件产品或系 统在语言、时区、度量衡、文化、风俗习惯等各个方面与当地国家和地区的相应内容 相一致，从而满足特定地区的用户的使用需求。）

14、全球化（G11N）关系： 国际化是核心，是内在的实现和将来本地化的基础 本地化是外在的表现，在国际化框架下完成制定、配置等工作，其结果就是国际化向特定本地语言环境的转换 全球化可以看作国际化和本地化合成的结果2. 国际化软件的最重要的特性是什么？为什么？支持Unicode字符集 支持不同时区的设定、显示和切换分离程序代码和显示 内容消除硬代码（Hard code）使用Header files去定义经常被调用的代码段支持各个国家的度量衡、时间、货币单位等不同格式的显示方式国际化用户界面设计 支持各个国家的键盘设置支持文字排序和大小写转换软件国际化的规范可以归纳为以下5点：1切换语言的机制。2与语

15、言无关的输出接口。3 与语言无关的输入接口和标准的输入协议。4 资源文件的国际化。5 支持和包容本地化数据格式。3. 如何全面地完成软件国际化测试？设计评审和代码审查 针对源语言的功能测试，如不同的区域设置、不同的时区显 示 针对伪翻译版本的测试4. 如何有效地完成软件本地化的数据格式的验证？需要仔细检查：日期格式时间货币和数字度量衡的单位复数问题（各 类数据格式输入、存储和输出是否正确，包括数字、货币、时间、日期、度量衡等。）5. 在翻译验证中，要注意哪些方面？检查所有专业术语的建立、翻译和存储，并检查所有文档、联机帮助和应用程序中 使用一致的术语检查是否有应该翻译而没有翻译的内容、是否有部

16、分遗漏的未被翻 译的内容，确保所有菜单、按钮、提示、说明、图片等各类文字信息都被翻译类 检 查是否有不应该翻译而翻译的内容，如一些特定的术语或实际内容之中举例所涉及的 一些源语言单词检查是否有错误的翻译，确保所翻译内容的正确性、准确性和语言 的完整性翻译的句子是否复杂、难懂，翻译后的文字中是否使用了意义含糊的词？ 如果句子复杂，是否拆分为简单句型？如果使用了缩写词，检查缩写词在第一次出 现的时候是否正确地标出了其全称，以便用户能够明白其含义 特殊的语言和文化环 境检查，包括检查在不同的国家标点符号、货币单位等是否显示正确 政治敏感内容 的检查，包括宗教内容的检查（测试人员要配合翻译人员的工作，

17、及时对翻译的内容 进行验证，确保翻译的质量、完整性和一致性；在将产品或应用翻译为本地语言后， 需要对界面布局进行一些调整；把一种语言翻译成另一种语言，同时还要注意目标语 言的特殊符号）第八章 系统测试1. 负载测试、压力测试和性能测试之间的联系和区别 负载测试：通过模拟实际软件系统所承受的负载条件、改变系统负载大小和负载方式 来发现系统中所存在的问题 压力测试：在强负载情况下（如大数据量、大量并发用户连接等）稳定性进行测试， 查看应用系统在峰值（瞬间使用高峰）使用情况下的行为表现，更有效地发现系统稳 定性的隐患和系统在负载峰值的条件下功能隐患等，确认系统是否具有良好的容错能 力和可恢复能力。性

18、能测试：是为获取或验证系统性能指标而进行的测试 关系：负载测试更多地体现了一种方法或一种技术，可以为性能测试、压力测试所采 用。2. 如何设计一个合格的负载测试？了解系统的用户角色，确定对应的关键业务操作路径确定输入/输出参数，制定 负载测试方案准备测试环境，并完成相应的测试脚本的开发设计具体的测试场 景，如负载水平、加载方式等执行测试，监控输出参数，如数据吞吐量、响应时 间、资源占有率等 对测试结果进行分析结果不满意，需要调整测试场景，进入 下一个循环。3. 性能测试有几种类型？它们之间的关系如何？ 性能验证测试：验证事先已定义的系统性能指标、系统能否满足系统的性能需求 性能基准测试：在系统

19、标准配置下获得有关的性能指标数据，作为将来性能改进的基 准线性能规划测试：在多种特定的环境下，获得不同配置的系统的性能指标，从而决定在 系统部署时采用什么样的软、硬件配置容量测试：可以看作性能测试一种，因为系统的容量可以看作是系统性能指标之一 运行一系列的基准测试，确立一个已知的可控环境，然后可以进行更为复杂环境下的 性能测试。4. 如何有效地完成性能测试？确定性能测试需求；计划和设计测试(包括确定关键业务流程、测试类型和测试 方法、选择合适的测试工具、设计测试场景等)测试工具的选择；配置测试环 境，尽量接近实际运行环境，即建立仿真环境作为性能测试环境，测试结果才能可 信；实现测试设计(开发测

20、试脚本)；执行测试；分析测试结果；重复上述 (4) (6)步骤，直至测试计划完成，结果满意；提交性能测试报告。5. 安全性测试的主要内容有哪些？难点在哪里？ 软件安全性测试就是检验系统权限设置有效性、防范非法入侵的能力、数据备份和恢 复能力等，设法找出上述各种安全性漏洞难处：跨站脚本攻击；SQL注入式攻击；URL和API的身份验证6. 如何实施故障转移测试？举例说明 一旦某个组件、某个子系统、整个系统或整个数据中心出现故障，有相应的组件，（子）系统或数据中心解题原来的功能，继续提供正常的服务。举例P180第九章 缺陷报告1. 如何有效地描述一个缺陷？ （一份有效的缺陷报告的要素应包括：标题、前

21、提、测试环境、操作步骤、期望结果、实际结果、出现的频率等） 单一准确，每个报告只针对一个软件缺陷 可以再现，不要忽视或省略任何一项操作步骤，特别是关键性的操作一定要描 述清楚，确保开发人员按照所描述的步骤可以再现缺陷 完整统一，提供完整的软件缺陷描述信息 短小简练，如使用业务关键词 特定条件，必须注明缺陷发生的特定条件 不做评价，客观描述2. 软件缺陷可能得不到修复的几个原因没有足够的时间 修复的风险太大 不值得修复 不算真正的缺陷 技术的限 制或第三方产品的限制3. 软件缺陷生命周期的基本状态包括哪些？在处理缺陷过程中，要注意哪些方面？ 打开修正关闭注意方面：不是每个缺陷都能及时得到修正，可

22、能由于时间关系或技术限制，某些缺陷不得不 延迟到下一个版本中去修正某些缺陷描述不清楚，开发人员看不懂或不能再现，将 缺陷打回让测试人员补充信息有些缺陷得到了开发人员处理，认为已得到保证，测 试人员验证之后，缺陷依旧存在，没有得到彻底的处理。4. 通过软件缺陷分析，我们能获得哪些有价值的信息？ 产品的质量是否达到预定的标准 缺陷修正的速度是否滞后 测试人员 验证缺陷是否及时 缺陷遗漏程度 回归缺陷数量 流程5. 缺陷分布分析有什么样的意义？ 直观、一看就知道哪个模块缺陷最多，哪个模块缺陷最少6. 如果某项目中软件缺陷发现速度下降，测试人员对项目即将关闭准备发布表示兴 奋，请问可能有哪些原因会造成这种假象？第十章 测试计划和管理1. 如何更好地理解测试的独立性和客观性？2. 在测试计划过程中，最关键的环节是什么？为什么？3. 测试工作量估计有哪些方法？你认为哪种方法最好？4. 为什么说测试进度管理是一种艺术？5. 在众多的软件测试风险中，我们要关注哪些影响可能最大的风险？6. 如何评估软件测试覆盖率？