2023年6月29日发(作者：)

第一章 软件测试概述

1.对软件缺陷有什么真实的体验？

当登录某网站购物完毕并退出后，忽然想查查购物时付账的总金额，于是按了浏览

器左上角的 “退回”按钮，就又回到了退出前的网页。该软件缺陷所属类别与软件产品说明书的要求有关。

2.以客户为导向来讨论软件测试的理念和作用

判断软件是否存在缺陷的基本依据是软件的用户需求，软件功能特性就是为了满足用户需求，不能满足用户需求的功能是有缺陷的。所以软件测试要服从用户需求，以用户需求为依据，来对产品进行检验。软件测试的作用是尽可能多的发现软件中的错误。

3.给软件测试下定义，它的内容是什么？

软件测试是由“验证”和“有效性确认”活动构成的整体：“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性；“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。

4.软件开发和软件测试是一种对立的关系吗？为什么？

软件测试和软件开发并行的活动，使软件测试和软件开发相互协作、相互补充，构成有机的软件开发整体。

第二章 需求和设计评审 1.需求评审和设计评审可以同时进行吗？为什么？

不能，需求评审一定要“从用户的角度”出发，基于用户需求，一切围绕用户需求进行评审，而设计评审一般依据设计技术的评审标准和非功能性质量特性的设计评审要求，采用分层评审和整体评审相结合的方法，经过整体评审到分层评审，再从分层评审到整体评审的过程，既能确保评审的深度，又能确保评审的一致性。

2.需求评审和设计评审有什么不同？

从测试的观点看，产品需求评审是对需求的验证，属于静态测试，也是做好软件测试和理解设计等的基础性工作。设计评审时，先从系统架构，整体功能结构上开始审查系统的非功能特性是否得到完美实现，然后深入到功能组件，操作逻辑和用户界面设计等各个方面的细节审查，力求发现任何不合理的设计以及设计缺陷，尽早地设计上的问题得到纠正。

3.在需求评审过程中，最有效的方法是什么？

在需求形成的过程中，最好采用分阶段评审方法进行多次评审，而不是在需求最终形成后进行一次评审，分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求分析返工的风险，提高了评审的质量。

4.设计评审的难点在哪里？

结构模型的设计错误总是会导致严重的设计问题或运作问题，严重时甚至会导致项目无法完成以及影响业务。

第三章 测试用例设计

1.测试用例的要素有哪些？

标志符、测试项、测试环境要求、输入标准、输出标准、测试用例之间的关联

2.你认为提高测试用例质量的最有效的方法是什么？

对测试用例进行集体的评审，能有效地提高测试用例的质量。

3.如何开展测试用例的评审？

 分析其设计思路，是否符合业务逻辑、是否符合技术设计的逻辑、是否可以和系统架构、组件等建立起完全的映射关系？

 在局部上，应有重有轻，抓住一些测试的难点、系统的关键点，从不同的角度向测试用例的设计者提问。  在细节上，检查是否遵守测试用例编写的规范或模板，是否漏掉每一元素、每项元素是否描述清楚

 检查表，提问

4.为什么要建立测试套件？它带来哪些益处？

为了更有效地重复使用、执行测试用例。（测试套件是由一系列测试用例并与之关联的测试环境组合而构成的集合，已满足测试执行的特定要求。通过测试套件，将服务于同一个测试目标、特定阶段性测试目标或某一运行环境下的一系列测试用例有机地组合起来 ）

有效性、可复用性、易组织性、客观性、可评估性和可管理性、

5.为什么需要对测试用例进行更新和维护？

客户的需求会发生变化、产品规格说明书相应地被更新，系统设计可能会被调整，程序实现的方法会被优化、细化。软件测试用例设计必然会做出相应的变化，增加新的测试用例或修改已有的测试用例，删除一些不再适用的测试用例。

随着产品版本的不断升级，软件测试用例也需要得到及时维护，有时还需要重构——对测试用例的结构进行调整，包括用例模块的合并和分解，确保每一个测试用例都是有效的。

第四章 软件测试自动化

1.自动化测试有什么优势？和手工测试有什么不同？

自动化测试利用软件测试工具自动实现全部或者部分测试工作， 自动运行的速度快、

测试结果准确、高复用性、永不疲劳、可靠、独特的能力。手工测试是传统的测试方法，由测试人员手工编写测试用例，缺点在于测试工作量大，重复多，回归测试难以实现。

自动化测试是对手工测试的一种补充，自动化测试不可能完全替代手工测试，因为很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断。而仅仅依赖手工测试的话，则会让测试过于低效，尤其是回归测试的重复工作量对测试人员造成了巨大的压力。因此，自动化测试仅仅是某些条件下手工测试的一种补充，而无法全面取代手工测试。

2.如何有效地综合运用手工测试和自动化测试？举例

负载测试、性能测试和回归测试用自动化测试；复杂的逻辑判断、界面是否友好用手工测试。

3.在自动化测试实现过程中，最重要的技术是什么？

脚本技术

4.针对小型和大型软件企业，分别讨论如何有效地选择测试工具

5.谈谈你对测试自动化启动和实施的体会

❖ 测试周期缩短

❖ 更高质量的产品

❖ 软件过程更规范

❖ 高昂的团队士气

❖ 节省人力资源，降低企业成本

❖ 充分利用硬件资源，降低企业成本。

第五章 单元测试和集成测试

1.为什么要进行单元测试？任务和目标是什么？

原因：尽可能早的发现软件中存在的错误，降低软件质量成本；检查代码是否符合设计和规范。

单元测试的主要任务：

（1）单元中所有独立执行路径测试（2）单元局部数据结构测试（3）单元接口测试

（4）单元边界条件测试（5）单元的各条错误处理通路测试（6）内存分析

2.黑盒测试方法和白盒测试方法有什么不同特点？谈谈其应用范围

黑盒测试方法（功能测试或数据驱动测试）不考虑程序内部结构和逻辑结构，主要是用来测试系统的功能是否满足需求规格说明书。黑盒测试方法主要运用于单元的功能和性能方法的测试，以检验程序的真正行为是否与产品规格说明、客户的需求保持一致。

白盒测试方法（结构测试或逻辑驱动测试）根据模块内部结构，基于内部逻辑结构，针对程序语句、路径、变量状态等来进行测试，检验程序中的各个分支条件是否得到满足、每条执行路径是否按预定要求正确地工作。白盒测试方法主要应用在单元测试阶段，主要是对代码级的测试，针对程序内部逻辑结构。

3.谈谈分支覆盖和条件覆盖之间的关系

分支覆盖（又叫判定覆盖），使得程序中每一个分支都至少被执行一次。条件覆盖使，程序中每一个条件至少有一次被满足。

条件覆盖通常比分支覆盖强，但是也可能有相反的情况：虽然每个条件都取到了两个不同的结果，判定表达式却始终只取一个值。

4.代码审查有哪些方法？如何更有效地实施代码审查？

走查；会议评审；互为审查

5.比较自顶向下集成测试方法和自底向上集成测试方法各自的优缺点

自顶向下集成测试一般不需要驱动程序，减少了测试驱动程序开发和维护的费用；能够在测试阶段的早期验证系统的主要功能逻辑，越重要的模块能优先得到测试；容易进行故障隔离和错误定位。但是桩模块的开发和维护费用大，桩模块不能反映真实情况，重要数据不能及时回送到上层模块，导致测试不充分；涉及复杂算法和真正 I/O的底层模块最易出问题，在后期才遇到导致过多的回归测试。

自底向上集成测试一般不需要桩模块，而驱动程序比较容易建议；可以尽早的验证底层模块的行为，提高了测试效率；容易对错误进行定位。但是直到最后一个模块加进去之后才能看到整个系统的框架；驱动模块的设计工作量大；不能及时发现高层模块设计上的错误。

6.你喜欢使用哪个单元测试工具？为什么？

Junit、Junit+Ant构建自动的单元测试、CheckStyle（源程序是否与代码规范相符）/PMD（检查java源文件中潜在问题）与FindBug（不检查java源文件，查找java

bytecode中的潜在bug）的使用、SourceMonitor（检测代码复杂度）

第六章 功能测试

1.你认为功能测试的挑战来自于哪些地方？

2.如何综合运用因果图法和决策表方法？

直接对输入条件进行组合设计决策表，不需要进行因果分析，即直接采用决策表方法。可以由因果图导出，可以优化决策表。

3.决策表方法和正交测试方法有什么联系和区别？

4.在可用性测试中应注意哪些方面？

5.在回归测试中，如何在提高执行效率和降低风险性方面获得平衡？

回归测试的目的：

1所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；

2不影响软件原有功能的正确性。 回归测试的方法：

1再测试全部用例

2基于风险选择测试

3基于操作剖面选择测试

4再测试修改的部分

6.你愿意选择开源功能测试工具还是商业的功能测试工具，为什么？

第七章 国际化和本地化测试

1.软件国际化、本地化、全球化的概念及关系

国际化（I18N）：为保证所开发的软件能适应全球市场的本地化工作而不需要对程序做任何系统性或结构性变化的特性。（这种特性通过特定的系统设计、程序设计、编码方法来实现。）

本地化（L10N）：将一个软件产品按特定国家或地区的特定需要而进行全面制定的过程。（即在源语言版本的基础上，通过翻译、定制和参数配置等工作，使软件产品或系统在语言、时区、度量衡、文化、风俗习惯等各个方面与当地国家和地区的相应内容相一致，从而满足特定地区的用户的使用需求。）

全球化（G11N）

关系：

❖ 国际化是核心，是内在的实现和将来本地化的基础

❖ 本地化是外在的表现，在国际化框架下完成制定、配置等工作，其结果就是国际化向特定本地语言环境的转换

❖ 全球化可以看作国际化和本地化合成的结果

2.国际化软件的最重要的特性是什么？为什么？

①支持Unicode字符集 ②支持不同时区的设定、显示和切换 ③分离程序代码和显示内容 ④消除硬代码 (Hard code) ⑤使用Header files 去定义经常被调用的代码段

⑥支持各个国家的度量衡、时间、货币单位等不同格式的显示方式 ⑦国际化用户界面设计 ⑧支持各个国家的键盘设置 ⑨支持文字排序和大小写转换

软件国际化的规范可以归纳为以下5点：

1切换语言的机制。

2与语言无关的输出接口。 3与语言无关的输入接口和标准的输入协议。

4资源文件的国际化。

5支持和包容本地化数据格式。

3.如何全面地完成软件国际化测试？

①设计评审和代码审查 ②针对源语言的功能测试，如不同的区域设置、不同的时区显示 ③针对伪翻译版本的测试

4.如何有效地完成软件本地化的数据格式的验证？

需要仔细检查：①日期格式 ②时间 ③货币和数字 ④度量衡的单位 ⑤复数问题（各类数据格式输入、存储和输出是否正确，包括数字、货币、时间、日期、度量衡等。）

5.在翻译验证中，要注意哪些方面？

①检查所有专业术语的建立、翻译和存储，并检查所有文档、联机帮助和应用程序中使用一致的术语 ②检查是否有应该翻译而没有翻译的内容、是否有部分遗漏的未被翻译的内容，确保所有菜单、按钮、提示、说明、图片等各类文字信息都被翻译类 ③检查是否有不应该翻译而翻译的内容，如一些特定的术语或实际内容之中举例所涉及的一些源语言单词 ④检查是否有错误的翻译，确保所翻译内容的正确性、准确性和语言的完整性 ⑤翻译的句子是否复杂、难懂，翻译后的文字中是否使用了意义含糊的词？如果句子复杂，是否拆分为简单句型？ ⑥如果使用了缩写词，检查缩写词在第一次出现的时候是否正确地标出了其全称，以便用户能够明白其含义 ⑦特殊的语言和文化环境检查，包括检查在不同的国家标点符号、货币单位等是否显示正确 ⑧政治敏感内容的检查，包括宗教内容的检查（测试人员要配合翻译人员的工作，及时对翻译的内容进行验证，确保翻译的质量、完整性和一致性；在将产品或应用翻译为本地语言后，需要对界面布局进行一些调整；把一种语言翻译成另一种语言，同时还要注意目标语言的特殊符号）

第八章 系统测试

1.负载测试、压力测试和性能测试之间的联系和区别

负载测试：通过模拟实际软件系统所承受的负载条件、改变系统负载大小和负载方式来发现系统中所存在的问题

压力测试：在强负载情况下（如大数据量、大量并发用户连接等）稳定性进行测试，查看应用系统在峰值（瞬间使用高峰）使用情况下的行为表现，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等，确认系统是否具有良好的容错能力和可恢复能力。

性能测试：是为获取或验证系统性能指标而进行的测试

关系：负载测试更多地体现了一种方法或一种技术，可以为性能测试、压力测试所采用。

2.如何设计一个合格的负载测试？

①了解系统的用户角色，确定对应的关键业务操作路径 ②确定输入/输出参数，制定负载测试方案 ③准备测试环境，并完成相应的测试脚本的开发 ④设计具体的测试场景，如负载水平、加载方式等 ⑤执行测试，监控输出参数，如数据吞吐量、响应时间、资源占有率等 ⑥对测试结果进行分析 ⑦结果不满意，需要调整测试场景，进入下一个循环。

3.性能测试有几种类型？它们之间的关系如何？

性能验证测试：验证事先已定义的系统性能指标、系统能否满足系统的性能需求

性能基准测试：在系统标准配置下获得有关的性能指标数据，作为将来性能改进的基准线

性能规划测试：在多种特定的环境下，获得不同配置的系统的性能指标，从而决定在系统部署时采用什么样的软、硬件配置

容量测试：可以看作性能测试一种，因为系统的容量可以看作是系统性能指标之一

运行一系列的基准测试，确立一个已知的可控环境，然后可以进行更为复杂环境下的性能测试。

4.如何有效地完成性能测试？

①确定性能测试需求；②计划和设计测试（包括确定关键业务流程、测试类型和测试方法、选择合适的测试工具、设计测试场景等）③测试工具的选择；④配置测试环境，尽量接近实际运行环境，即建立仿真环境作为性能测试环境，测试结果才能可信；⑤实现测试设计（开发测试脚本）；⑥执行测试；⑦分析测试结果；⑧重复上述(4)~ (6)步骤，直至测试计划完成，结果满意；⑨提交性能测试报告。

5.安全性测试的主要内容有哪些？难点在哪里？

软件安全性测试就是检验系统权限设置有效性、防范非法入侵的能力、数据备份和恢复能力等，设法找出上述各种安全性漏洞

难处： 跨站脚本攻击；SQL注入式攻击 ；URL和API的身份验证 6.如何实施故障转移测试？举例说明

一旦某个组件、某个子系统、整个系统或整个数据中心出现故障，有相应的组件，（子）系统或数据中心解题原来的功能，继续提供正常的服务。举例P180

第九章 缺陷报告

1.如何有效地描述一个缺陷？

（一份有效的缺陷报告的要素应包括：标题、前提、测试环境、操作步骤、期望结果、实际结果、出现的频率等）

❖ 单一准确，每个报告只针对一个软件缺陷

❖ 可以再现，不要忽视或省略任何一项操作步骤，特别是关键性的操作一定要描述清楚，确保开发人员按照所描述的步骤可以再现缺陷

❖ 完整统一，提供完整的软件缺陷描述信息

❖ 短小简练，如使用业务关键词

❖ 特定条件，必须注明缺陷发生的特定条件

❖ 不做评价，客观描述

2.软件缺陷可能得不到修复的几个原因

①没有足够的时间 ②修复的风险太大 ③不值得修复 ④不算真正的缺陷 ⑤技术的限制或第三方产品的限制

3.软件缺陷生命周期的基本状态包括哪些？在处理缺陷过程中，要注意哪些方面？

打开——修正——关闭

注意方面：

①不是每个缺陷都能及时得到修正，可能由于时间关系或技术限制，某些缺陷不得不延迟到下一个版本中去修正②某些缺陷描述不清楚，开发人员看不懂或不能再现，将缺陷打回让测试人员补充信息③有些缺陷得到了开发人员处理，认为已得到保证，测试人员验证之后，缺陷依旧存在，没有得到彻底的处理。

4.通过软件缺陷分析，我们能获得哪些有价值的信息？

❖ 产品的质量是否达到预定的标准

❖ 缺陷修正的速度是否滞后

❖ 测试人员 验证缺陷是否及时

❖ 缺陷遗漏程度 ❖ 回归缺陷数量

❖ 流程……

5.缺陷分布分析有什么样的意义？

直观、一看就知道哪个模块缺陷最多，哪个模块缺陷最少

6.如果某项目中软件缺陷发现速度下降，测试人员对项目即将关闭准备发布表示兴奋，请问可能有哪些原因会造成这种假象？

第十章 测试计划和管理

1.如何更好地理解测试的独立性和客观性？

2.在测试计划过程中，最关键的环节是什么？为什么？

3.测试工作量估计有哪些方法？你认为哪种方法最好？

4.为什么说测试进度管理是一种艺术？

5.在众多的软件测试风险中，我们要关注哪些影响可能最大的风险？

6.如何评估软件测试覆盖率？