软件测试基础面试题

1 、软件的含义

程序、数据及相关文档的完整集合。

2、测试与调试的区别是什么？

测试是由测试人员来进行，主要目标是发现、报告和跟踪缺陷。

调试是由开发人员进行，主要目标是定位缺陷位置，分析缺陷原因，修复缺陷。

3、 软件测试的含义

简单讲，软件测试是发现缺陷的过程；IEEE 中的定义是，软件测试是使用人工或自动手段来运行或测定某个系统的过程，目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

4、软件测试的目的

（1） 验证软件是否满足各类文档说明书等规定的软件质量要求

（2） 找出软件缺陷

（3） 为软件产品的质量测量和评价提供依据

（4） 帮助开发改进开发流程

5、 什么是功能、性能、兼容性

功能代表一个软件能做什么；性能反映软件运行的速度或效率、占用资源的多少等指标；兼容性表示一个软件与其所在运行环境的依赖程度，包括与硬件、操作平台、其他软件的依赖。

6、 测试分为哪几个阶段？每个阶段的测试目的是什么？

测试分为单元测试、集成测试、系统测试、验收测试四个阶段。前三个阶段的目的是尽可能多的发现缺陷，而验收测试是要验证软件满足了用户需求，帮助用户建立系统可以正常使用的信心，发现缺陷不是此阶段的目标。

7、 如果测试提交的缺陷开发人员不认可，该怎么办？

首先分析或与开发沟通开发不认可的原因。

如果拒绝原因是提交的不是缺陷，而且自己分析后，的确不是缺陷，则应该注意以后再做测试时要做好复现，认真研读需求，提高自己找缺陷的能力。

如果拒绝原因是提交的不是缺陷 但自己分析时认为缺陷应该是存在的，则再次研读需求并做好复现，拿出确实是缺陷的证据，然后与开发沟通。

如果拒绝原因是认可缺陷，但不予修复，如果自己觉得必须修复，则拿出充分理由和证据和不修复的不利影响和影响范围，再与开发沟通。

注意沟通技巧，合理的论述，向开发说明自己的判断的理由，注意客观、严谨，不掺杂个人情绪。

把问题交给测试经理，等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。

8、什么是软件开发生命周期

从软件最初构思到公开发行的过程。瀑布模型的过程是计划、需求、设计、编码、测试、运行、维护循环。

瀑布模型有严格的开发步骤，每个阶段是按顺序进行的，每个阶段都必须编写完整的文档，每个阶段完成后必须经过审查才能进入下一步。

瀑布模型不能迭代、不能反复；测试在编码之后，测试太晚；测试的只是程序。

9、 软件开发有什么模型？软件测试主要有哪些模型？

软件开发模型：大爆炸模型、边写边改模型、瀑布模型、螺旋模型、敏捷开发模型软件测试模型：V 模型、W 模型、H 模型、X 模型、前置测试模型、敏捷测试模型

10、简述V 模型。

V 模型的过程：用户需求→需求分析→概要设计→详细设计→编码→单元测试→集成测试→系统测试→验收测试。

优点：

（1）V 的左端表示传统的瀑布开发模型，V 的右端明确地将测试分为不同的级别或阶段，测试过程更为具体；

（2）测试各个阶段和开发的各个阶段相对应；

（3）V 模型的测试策略包括低层测试和高层测试，低层测试是为了源代码的正确性，高层测试是为了整个系统满足用户的需求。

缺点：

（1） 测试的对象就是程序本身。忽视了测试活动对需求分析，系统设计等活动的验证和确认的功能，直到后期的验收测试才被发现。

（2） 测试是开发之后的一个阶段。实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。

11、简述W模型。

W 模型的过程：左边 V 是需求分析→概要设计→详细设计→编码实现→模块集成→系统构建→系统安装；右边 V 是需求测试→概要设计测试→详细设计测试→单元测试→集成测试→系统测试→验收测试。

优点：

（1）W 模型体现了尽早和不断测试的原则，既强调测试方案设计，也强调测试执行。

（2） 左侧 V 是开发，右侧 V 是与开发并行的测试，相对于 V 模型，W 模型增加了软件各开发阶段中应同步进行的验证和确认活动，W 明确表示出了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早地全面的发现问题。

（3） 测试伴随整个软件开发周期，且测试的对象不仅仅是程序，需求、设计等同样要测试。

缺点：

在 W 模型中，需求、设计、编码等活动被视为串行的，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型，不利于当前软件开发复杂多变的情况。

12、简述H模型。

H 模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。H 模型的测试流程是只要测试准备工作完成，达到测试就绪点，测试就可以执行了。

优点：

（1） 软件测试不仅仅指测试的执行，还包括很多其他的活动。

（2） 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。

（3）H 模型反映出软件测试要尽早准备，尽早执行。

（4）软件测试可以进行迭代、反复进行。

13、敏捷开发

敏捷开发的核心思想是：以人为本，适应变化。具体讲：

（1） 认为个体和交互重于过程和工具，强调通过过程和工具理解个人和交流的作用；

（2） 认为可用软件重于完备文档，强调通过全面的文档理解运行的软件；

（3） 认为客户协作重于合同谈判，强调通过合同和谈判得到客户的协作；

（4） 认为响应变化重于遵循计划，强调在计划的执行中做出对变更的响应。特点：

（1） 敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。

（2） 敏捷开发是以用户为中心、以客户需求为导向的开发过程，在此过程中随时做好 “迎接变化”的准备，客户是敏捷的关键环节。

（3） 敏捷开发没有单一固定的开发方法或过程，敏捷开发有三个共同点：依赖客户的参与、测试驱动以及紧凑的迭代开发周期。

14、敏捷测试

（1） 敏捷测试是协同测试的一种形式，程序员结对编程，程序员分饰测试员角色，敏捷测试是连续测试。

（2） 敏捷测试侧重单元测试和验收测试。单元测试的过程是先设计单元测试用例，然后进行编码，之后执行测试。

（3） 敏捷测试强调客户参与，单元测试通过之后代码集成到代码库中，再由客户进行验收测试，验收测试的结论反馈给开发人员，缺陷得以迅速修复。

15、软件质量要求有哪些？

功能要求和非功能要求。

16、软件非功能要求有哪些？

性能要求（负载测试、压力测试、容量测试、可靠性测试）、界面测试、兼容性测试、易用性测试、文档测试、可用性测试、安装测试、安全测试、灾难恢复测试等。

17、简述测试的基本过程

（1） 测试人员进行测试需求分析。

（2） 测试负责人编写测试计划。

（3） 测试人员根据测试需求分析设计和编写测试用例。

（4） 测试人员搭建测试环境、创建测试数据、执行测试用例、提交缺陷报告并进行跟踪、记录测试事件。

（5） 进行测试评估和总结。

每一分步工作完成后都进行评审。

18、拿到一个软件后，应该怎样开始工作？

编写需求分析并评审→编写测试计划并评审→设计测试用例并评审→搭建测试环境、执行测试用例、提交缺陷报告→进行评估和总结

19、怎么做测试？

编写需求分析并评审→编写测试计划并评审→设计测试用例并评审→搭建测试环境、执行测试用例、提交缺陷报告→进行评估和总结

20、简介测试流程

编写需求分析并评审→编写测试计划并评审→设计测试用例并评审→搭建测试环境、执行测试用例、提交缺陷报告→进行评估和总结。

21、怎么进行测试需求分析？

（1） 收集各类文档，仔细阅读文档，提出问题，分析问题或沟通解决，整理需求信息。

（2） 编写测试需求分析说明书：功能分解，编写检查点和测试点。

（3） 需求评审。

22、拿到项目后，需要分析或咨询软件哪些方面的问题？

软件主要的功能、流程、开发环境（开发语言<含数据类型>、数据库、中间件）、运行环境（硬件、软件、网络、软件架构）、用户群、测试范围、测试优先级。

23、什么时候提交发现的缺陷？

测试执行发现缺陷时立即提交缺陷。

24、什么是入口准则、出口准则？

入口准则是进行一项测试工作前需要准备好的前提条件。出口准则是一项测试工作可以结束的前提条件。

25、什么是测试策略？什么是测试范围？

测试策略主要指如何进行某种测试（如功能测试、性能测试、兼容性测试、可用性测试、易用性测试等），用于说明测试方法以及如何使用测试方法。测试范围有时候等价于测试策略，有时候可以表示要进行测试的某个软件部位。

26、什么是BVT冒烟测试？版本验证测试？怎么测？

也称冒烟测试、版本验证测试、小版本验证测试、版本构建测试。冒烟测试用例是一组想先运行以确定这个给出的小版本是否可以测试的测试用例。冒烟测试主要测试软件的基本功能，以判断整个软件值不值得进行大规模测试。通常由一个人进行 1-2 小时的测试，一般不测试次要功能和各种错误。

27、测试计划的内容和目的是什么？

包含了产品概述、测试区域/测试策略/测试范围/测试目标（测试项、被测特征）、测试配置/测试资源、测试周期、进度安排（测试任务、人员安排）、测试方法/途径、测试交流、风险分析等内容。目的是指导测试过程，规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的责任人以及与计划相关的风险。

28、怎么判断是不是软件缺陷？

（1） 软件未达到产品说明书标明的功能；

（2） 软件出现了产品说明书指明不会出现的错误；

（3） 软件功能超出产品说明书指明范围；

（4） 软件未达到产品说明书虽未指出但应达到的目标；

（5） 软件测试员具体问题具体分析，认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

29、缺陷的产生主要有哪些原因？最主要的原因是什么？

需求频繁变更、沟通不良、不了解客户的需求、实现新功能或很酷的功能、追求新技术、项目期限的压力、需求分析或设计投入的时间和精力不够、产品的复杂度、开发人员疲劳、压力过大或受到干扰、缺乏足够的知识、技能和经验、缺乏动力等。

最主要的原因：需求方面的原因

30、当你发现一个缺陷时，应该怎么确认的确是一个缺陷？

根据缺陷的判断原则来甄别发现的问题是不是一个缺陷，发现缺陷后，应该做好分离和再现（3 次），然后才能提交。

31、在正式提交一个缺陷前，你应该做些什么？

分离缺陷、再现缺陷（3 次），然后才能提交。

32、怎么处理无法再现的缺陷？

首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员。

其次，对于寻找难以再现的缺陷要合理地安排时间，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度。

最后，在测试过程中对未再现缺陷予以关注。

33、什么是重复缺陷？怎么避免重复缺陷？

提交了一个缺陷库中存在或者开发人员已经知道的缺陷。

1、如果缺陷是跟同事提交的重复，任务分工解决，也可以在提交之前查询下库缺陷是否存在。

2、如果缺陷是与自己提交的缺陷重复，则需要提高发现缺陷的能力，通过提高开发能力来理解两个缺陷本质上是一个缺陷。

34、什么是无效缺陷？怎么避免无效缺陷？

提交的缺陷不是真正的缺陷。

充分了解需求、提高自己识别缺陷的能力、提高缺陷写作能力

35、缺陷报告的写作准则是什么？

Correct（准确）：每个组成部分的描述准确，不会引起误解； Clear（清晰）：每个组成部分的描述清晰，易于理解；

Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容； Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息； Consistent（一致）：按照一致的格式书写全部缺陷报告。

36、缺陷报告的内容有哪些？

缺陷标题（或者说缺陷摘要、缺陷概述、缺陷基本信息）预处理

复现步骤预期结果实际结果严重程度优先级 测试环境测试版本

测试执行人注释

37、缺陷报告的组织结构是什么？

缺陷标题（或者说缺陷摘要、缺陷概述、缺陷基本信息）预处理

复现步骤预期结果实际结果严重程度优先级 测试环境测试版本

测试执行人注释

38、缺陷报告的写作需要注意什么问题？

不要使用我、你、他等字眼，不要使用情绪化的语言和强调符号、不要使用“似乎”、看上去可能等不确定性内容、不要使用认为比较幽默的内容、不要使用不确定的测试问题(不确定是否是缺陷)、不要人身攻击。

39、简述缺陷报告的处理流程

软件测试人员提交缺陷报告；

测试负责人审核后将缺陷报告分配给相关的开发人员修改； 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测返测通过的缺陷报告由负责人关闭；

返测未通过的缺陷报告直接返回开发人员重新修改，然后再由测试人员返测，直到测试和开发达成一致处理意见。

40、简述缺陷的生命周期

软件测试人员提交缺陷报告；

测试负责人审核后将缺陷报告分配给相关的开发人员修改； 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测返测通过的缺陷报告由负责人关闭；

返测未通过的缺陷报告直接返回开发人员重新修改，然后再由测试人员返测，直到测试和开发达成一致处理意见。

41、简述重复缺陷的处理流程

提交缺陷→分配缺陷→是重复缺陷→置为无效缺陷。

42、缺陷按照严重程度可以分为哪些类型？

致命缺陷、严重缺陷、一般缺陷、较小错误、意见建议等

43、缺陷按照优先级可以分为哪些类型？

缺陷必须立即解决；

缺陷需要正常排队等待修复或列入软件发布清单；缺陷可以在方便时被纠正；

下一个版本修复；不修复。

44、缺陷的状态有哪些？

新建/已提交打开

已拒绝

已解决/已修复已验证

已关闭

45、测试有哪些级别？

单元测试、集成测试、系统测试、验收测试

46、测试有哪些阶段？

单元测试、集成测试、系统测试、验收测试

47、什么是单元测试？单元测试谁来做？

针对一个软件单元的测试。开发人员或懂开发的测试人员

48、什么是桩模块、驱动模块？

桩模块：被被测模块调用的模块。驱动模块：调用被测模块的模块。

49、什么时候可以进行组件测试？

完成编译的测试对象，测试环境，开发工具，测试对象的规范说明书。

50、单元测试使用技术？测试重点是什么？测试条件是什么？

单元测试的技术：黑盒白盒技术，但是白盒居多，黑盒居少，一般先做黑盒再做白盒。单元测试重点：功能性测试，健壮性（逆向测试：无效值），性能。

单元测试前提条件：完成编译的测试对象，测试环境，开发工具，测试对象的规范说明

书。

51、什么是集成测试？

组件间的接口与交互的测试。

52、集成测试的测试重点是什么？测试条件是什么？使用什么技术？

接口和系统内不同部分的相互作用（交互）。

测试条件是完成集成的被测系统，测试台，有关组件间交互的文档。

测试技术包括白盒技术、黑盒技术，白盒居多，黑盒居少，对比单元测试，白盒下降，一般先做黑盒再做白盒。

53、集成测试有哪些策略？

自顶向下集成自底向上集成

54、什么是系统测试？

对整个系统能不能满足用户需求的测试。

55、系统测试的目的是什么？

检查软件是否满足需求。

56、系统测试能够发现哪些缺陷？会遗留哪些缺陷？

发现：非功能性缺陷、涉及整个系统的问题。

遗漏：对用户的需求的错误理解、没有实现或者没有完全实现用户的隐性需求。

57、什么是验收测试？

一般由用户/客户进行的确认是否可以接受一个系统的验证性测试。验收测试根据用户需求，业务流程进行的正式测试以确保系统符合所有验收的准则。

58、验收测试有哪些人进行？

客户或用户，测试人员可以介入。

59、验收测试的目标是什么？

对系统或子系统建立信心、对系统非功能性的特性赢得信任。

60、什么是alpha、beta测试？有何区别？

Alpha 测试：潜在的客户/用户在开发场地进行的测试。

Beta 测试：由潜在客户/用户在自己的环境下测试软件系统。

61、什么是维护测试？

软件正常使用后，对软件的变更、更新进行测试

62、什么是性能测试？负载测试？压力测试？有什么区别？

性能表现处理速度、响应时间、CPU 使用、内存使用、硬盘使用等。负载测试：通过不断增加负载来测试一个系统的性能。

压力测试：通过增加负载超过系统正常工作能力来考察系统能否在异常情况下正常工作

63、什么是功能测试？

测试一个软件能做什么，是不是做了应该做的工作，没做不该做的工作。

64、什么是结构测试？

白盒测试也称结构测试、逻辑驱动测试、基于程序本身的测试，是对程序结构进行的测

试。

65、什么是与变更相关的测试？有哪些具体类型？

与变更相关的测试是对修改过的程序进行的测试。确认测试（再测试）和回归测试。

66、什么是静态测试？动态测试？如何区分二者？

静态测试：不执行程序的测试。针对文档和不需执行的代码。

动态测试需要执行程序，方法一般采用黑盒测试方法和白盒测试方法。

67、圈复杂度怎么计算？

不重叠的闭合环数+1

68、什么是黑盒测试？白盒测试？

黑盒测试也称功能测试，基于规格说明书的测试，关注输入数据到程序中，输出结果是否正确，侧重于测试软件能做什么

白盒测试也称结构测试、逻辑驱动测试，是对程序内部逻辑结构进行的测试

69、白盒测试有哪些方法？具体解释每种方法？

白盒测试主要使用逻辑覆盖测试方法，包括语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖等。

语句覆盖：程序中的每个可执行语句至少被执行一次。能发现语句错误，但不能发现逻辑错误。

判定覆盖：也称分支覆盖，程序中的每个判定的取真分支和取假分支至少执行一次。能发现逻辑错误，但不能发现组合判断中的条件错误。

条件覆盖：程序每个判定中每个条件的可能取值至少满足一次。能发现条件错误，但不能发现逻辑错误。

判定-条件覆盖：每个条件中的所有可能取值至少执行一次，同时，每个判定的可能结果至少执行一次。

条件组合覆盖：每个判定中的所有的条件取值组合至少执行一次。

路径覆盖：用例覆盖程序中的所有可能的执行路径。如果路径数很多，会变得不切实际。

70、什么是配置测试？

不同配置环境下进行测试。

71、什么是文档测试？

不仅包括测试文档校对，还有文档和软件不一致

72、什么是国际化测试？本地化测试？

国际性的软件

翻译成本国语言的，测试是否符合本国的语言习惯，是否符合本国法律，是否符合本国的国情。

73、测试用例的内容是什么？

用例编号，测试概述或用例标题、测试步骤，预期结果，输入数据，优先级，前置条件

等

74、测试用例有哪些元素？

用例编号，测试概述或用例标题、测试步骤，预期结果，输入数据，优先级，前置条件

等

或者说测试目标 Why、测试对象 What、测试环境要求 Where、测试前提 When，输入

数据

75、什么是UI、GUI？UI测试什么意思？

界面

图形界面

界面测试

76、解释测试目标、测试环境、测试对象、前置条件、测试策略、测试范围的含义？

测试目标：功能测试、性能测试、界面测试、易用性测试、兼容性测试、安全性测试测试策略：某类别测试的过程、方法以及方法如何应用，测试的注意事项等

测试环境：硬件环境、软件环境、网络环境

前置条件：进行某些测试工作需要做好的准备条件测试范围：软件需要测试的某个部位

77、软件投入运行后还需要测试吗？需要哪些测试？

需要测试。维护测试（含升级测试）、数据迁移测试、备份恢复测试、灾难恢复测试等

78、给你一个网站，你如何测试？

• 首先，查找需求说明、网站设计等相关文档，分析测试需求。

• 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试、界面测试、性能测试、数据库测试、安全性测试、兼容性测试。

• 设计测试用例：

  • 功能性测试可以包括，但不限于以下几个方面：

    • 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。

    • 提交功能的测试。

    • 多媒体元素是否可以正确加载和显示。

    • 多语言支持是否能够正确显示选择的语言等。

  • 界面测试可以包括但不限于一下几个方面：

    • 页面是否风格统一，美观

    • 页面布局是否合理，重点内容和热点内容是否突出

    • 控件是否正常使用

    • 对于必须但未安装的控件，是否提供自动下载并安装的功能

    • 文字检查

  • 性能测试一般从以下两个方面考虑：

    • 压力测试、负载测试

    • 数据库测试要具体决定是否需要开展。

    • 数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。

  • 安全性测试：

    • 基本的登录功能的检查

    • 是否存在溢出错误，导致系统崩溃或者权限泄露

    • 相关开发语言的常见安全性问题检查，例如 SQL 注入等

  • 兼容性测试，根据需求说明的内容，确定支持的平台组合：

    • 浏览器的兼容性；

    • 操作系统的兼容性；

    • 软件平台的兼容性；

    • 数据库的兼容性

  • 开展测试，并记录缺陷。

  • 合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。

  • 定期评审，对测试进行评估和总结，调整测试的内容。

79、一台客户端有三百个客户与三百个客户端有三百个客户对服务器施压，有什么区别?

• 300 个用户在一个客户端上

  • 会占用客户机更多的资源，而影响测试的结果。线程之间可能发生干扰，而产生一些异常。

  • 需要更大的带宽。

  • IP 地址的问题，可能需要使用 IP 欺骗来绕过服务器对于单一 IP 地址最大连接数的限制。

  • 不必考虑分布式管理的问题。

• 用户分布在不同的客户端上

  • 需要考虑使用控制器来整体调配不同客户机上的用户。

  • 需要给予相应的权限配置和防火墙设置。

80、试述软件的概念和特点？软件复用的含义？构件包括哪些？

软件是计算机系统中与硬件相互依存的另一部分，与计算机系统操作有关的计算机程序、规程、规则，以及可能有的文件、文档及数据。

软件复用(SoftWare Reuse)是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。

可以被复用的软件成分一般称作可复用构件。

81、软件配置管理的作用？软件配置包括什么？

软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术。

软件配置管理应用于整个软件工程过程。

在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM 是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。

软件配置包括如下内容：配置项识别、工作空间管理、版本控制、变更控制、状态报告、配置审计。

82、什么是软件质量？

概括地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。

具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。

软件质量包括正确性、健壮性、效率、完整性、可用性、风险（产品运行）；可理解性、可维修性、灵活性、可测试性（产品修改）；可移植性、可再用性、互运行性（产品转移）。

83、目前主要的测试用例设计方法是什么？

白盒测试：逻辑覆盖（语句覆盖、判定/分支覆盖、条件覆盖、条件-判定覆盖、多条件组合覆盖）、基本路径覆盖

黑盒测试：测试大纲法、场景法、等价类划分、边界值分析法、错误猜测法、判定表法、随机测试、探索性测试

84、软件的安全性应从哪几个方面去测试？

• 软件安全性测试包括程序、数据库安全性测试。

• 根据系统安全指标不同测试策略也不同。

• 用户认证安全的测试要考虑的问题

  • 明确区分系统中不同用户权限、系统中会不会出现用户冲突、系统会不会因用户的权限的改变造成混乱、用户登陆密码是否是可见、可复制、是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）、用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统

• 系统网络安全的测试要考虑的问题

  • 测试采取的防护措施是否正确装配好，有关系统的补丁是否打上、模拟非授权攻击，看防护系统是否坚固、采用成熟的网络漏洞检查工具检查系统相关漏洞、采用各种木马检查工具检查系统木马情况、采用各种防外挂工具检查系统各组程序的外挂漏洞

• 数据库安全考虑的问题

  • 系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）、系统数据的完整性、系统数据可管理性、系统数据的独立性、系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

85、什么是测试用例，什么是测试脚本，两者的关系是什么？

测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。

测试脚本是为了进行自动化测试而编写的脚本。

测试脚本的编写一般都需要对应相应的测试用例。

86、软件测试各个阶段通常完成什么工作？各个阶段的结果文件是什么？包括什么内容？

单元测试阶段：各独立单元模块在与系统地其他部分相隔离的情况下进行测试，单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能。生成单元测试报告，提交缺陷报告。

集成测试阶段：集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。该阶段生成集成测试报告，提交缺陷报告。

系统测试阶段：将通过确认测试的软件，作为整个给予计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行全面的功能覆盖。该阶段需要提交测试总结和缺陷报告。

验收测试阶段：一般由用户进行测试，或者是用户委托第三方进行测试，主要验证软件是否满足用户的使用需求，提升用户的信心，出具验收测试报告。

87、测试人员在软件开发过程中的任务是什么？

尽可能早的找出系统中的 Bug；

避免软件开发过程中缺陷的出现；

衡量软件的品质，保证系统的质量；

关注用户的需求，并保证系统符合用户需求。

88、如何测试一个纸杯？

功能：用水杯装水看漏不漏；水能不能被喝到

安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水放 24 小时检查泄漏时间和情况；盛上汽油放 24 小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

89、测试计划工作的目的是什么？测试计划文档的内容应该包括什么？其中哪些是最重要的？

• 软件测试计划是指导测试过程的纲领性文件：

  • 领导能够根据测试计划进行宏观调控，进行相应资源配置等。

  • 测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等。

  • 便于其他人员了解测试人员的工作内容，进行有关配合工作

• 测试计划包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

• 测试计划编写 6 要素（5W1H）：

  • why→→为什么要进行这些测试；

  • what→测试哪些方面，不同阶段的工作内容；

  • when→测试不同阶段的起止时间；

  • where→相应文档，缺陷的存放位置，测试环境等；

  • who→项目有关人员组成，安排哪些测试人员进行测试；

  • how→如何去做，使用哪些测试工具以及测试方法进行测试

• 测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术，其中最重要的是测试测试策略和测试方法（最好是对计划先评审）。

90、什么是测试覆盖率

• 是指完成的测试工作目标量占总目标量的百分比，有很多分类。

• 软件测试覆盖率常用的计算公式：

  • 功能覆盖率=至少被执行一次的测试功能点数/测试功能点总数（功能点）

  • 需求覆盖率=被验证到的需求数量/总的需求数量（需求）

  • (用例)覆盖率=至少被执行一次的测试用例数/应执行的测试用例总数

  • 语句覆盖率=至少被执行一次的语句数量/有效的程序代码行数

  • 判定覆盖率=判定结果被评价的次数/判定结果总数

  • 条件覆盖率=条件操作数值至少被评价一次的数量/条件操作数值的总数

91、一个好的测试用例，有哪些特点

• 用例要完整、简洁、一致

  • 至少含有编号、标题、操作步骤和预期结果。

• 用例要表明测试目的

• 用例覆盖程度要高

• 用例能够使工作量最小化

• 用例描述正确、规范

  • 含有正确的、规范的测试标题和编号

• 用例的分类以及描述要足够清晰

• 用例要具有可测试性

• 测试用例易于维护

  • 如果被测对象有所升级，测试用例的说明或者脚本是不是容易维护呢？

• 可复用

• 可重复性

  • 不管谁执行此用例，结果一样。

• 可追踪性

  • 用例能追踪到一个具体的需求。

92、测试结束的标准是什么

• 全部测试用例都执行完成。
• 未修改 bug 都被确认或置为应有状态，暂缓修改的问题都有详尽的解释。
• 测试报告编写完成。
• 测试收尾工作结束。
• 测试总结完成。
• 项目处于试运行或上线阶段
• 在测试计划中定义结束标准
  • 如计划中规定：系统在一定性能下平稳运行 72 小时，本版本中没有严重的 BUG，普通 BUG 的数量在 3 以下，BUG 修复率 90%以上
  • 实际测试达到上述要求，然后由开发经理，测试经理，项目经理共同签字，认同测试结束，版本即可发布。

93、如何全面测试一款产品，请以手机短信功能为例来辅助说明，前提是手机自带的短信功能，并非微信，QQ 这种软件

• 能正常打开或进入短信界面
• 短信可以正常编辑、修改、删除
• 短信可以正常发送和接收
• 短信页面字体、颜色显示正常
• 短信字体可调整
• 给多人同时发短信
• 给特殊号码发送短信
  • 如运营商（手机号所属运营商、其他运营商）
  • 不存在手机号
  • 服务号（收费、不收费）
• 接收验证码
• 短信耗电量测试
• 短信不耗流（联网、不联网）
• 短信干扰测试
  • 编辑短信期间（已经编辑好、正在打字），电话进来
  • 编辑短信期间（已经编辑好、正在打字），收到短信
  • 隐藏到后台（已经编辑好、正在打字），进行其他操作，再返回

94、你手中的这支笔有多少用途，请发挥你的想象力

• 写、画（纸上、墙上、桌子上、地上、其他位置）
• 染色
• 承重
• 当书签
• 当筷子
• 用来扎人
• 用来掏掉进笔记本键盘的小东西
• 用来去除缝隙（比如手机上的缝隙）里的灰尘
• 当作燃料
• 拿在手里转着玩，消遣一下
• 用来碰电门
• 塑料笔管用来当吸管

95、常见的性能测试策略有哪些

负载测试、压力测试、并发测试、内存泄露测试、基准测试、配置测试、数据容量测试、疲劳强度测试

96、说说你对集成测试中自顶向下集成和自底向上集成两个策略的理解，要谈出它们各自的优缺点和主要适应于哪种类型测试

• 自顶向下集成

  • 优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。

  • 缺点：桩的开发量大；底层验证被推迟；底层组件测试不充分。

  • 适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产品控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。

• 自底向上集成

  • 优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。

  • 缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。

  • 适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。

97、系统测试的策略有哪些

有功能测试、性能测试、负载测试、强度/压力测试、易用性测试、安全测试、配置测试、安装测试、文档测试、故障恢复测试、用户界面测试、可用性测试。

98、怎么理解回归测试?

• 回归测试: (regression testing)有两类：用例回归和错误回归；

  • 用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试，看看会不会重新发现问题。

  • 错误回归，就是在新版本中，对以前版本中出现并修复的缺陷进行再次验证，并以缺陷为核心，对相关修改的部分进行测试的方法。

99、LoadRunner分为哪三个模块？请简述各模块的主要功能。

• Virtual User Generator

  • 虚拟用户发生器

  • 用于录制脚本、调试脚本、增强脚本、运行脚本

• Controller

  • 控制器

  • 用于创建、运行和监控场景

• Analysis

  • 分析

  • 用于分析测试结果

100、性能测试的流程?、

• 测试需求分析
• 测试计划制定与评审
• 测试用例设计与开发，编写测试脚本
• 测试执行与监控，开发场景
• 分析测试结果
• 编写性能测试报告·
• 测试经验总结

101、功能测试中常用的测试方法有哪些？做简要说明

• 场景法
  • 主要对业务流程进行测试
  • 将业务流区分为基本流和备选流，基本流按照正确的流程设计用例，备选流测试各种错误流程
• 等价类划分
  • 将输入区域划分为若干个等价的类别，具体的分为有效等价类、无效等价类
  • 有效等价类是依据规格说明书中的要求设计用例
  • 无效等价类是违反规格说明书中的要求进行设计用例
• 边界值分析
  • 依据输入数据的范围进行用例设计，一般选择边界点上的 4 个或 6 个值进行用例设计
  • 通常选择比最小值正好小一点的值、最小值、最大值、比最大值刚刚大一点的数据作为用例
• 决策表
  • 分析不同输入的各种组合产生不同的输出
• 错误猜测
  • 考虑各种对软件的攻击

102、简单说一下对冒烟测试|集成测试的了解

• 冒烟测试
  • 也称为小版本验证测试
  • 对软件基本功能的验证
  • 通过对软件基本功能的测试，确定能否进行后续大规模的测试，如果冒烟测试通过，则后续可以进行大规模测试，否则将软件打回开发
  • 一般，冒烟测试由一个人进行，通常耗时 1-2 小时
  • 不同测试类型的冒烟测试可能会有不同，比如性能测试的冒烟测试需要的人力和时间也许会拉长
• 集成测试
  • 主要是测试软件多个单元合并到一起时需要的测试
  • 通常测试软件各部件之间的接口和交互
  • 一般由多个懂开发的测试人员进行

103、如何判断一个系统是否通过冒烟测试？

软件的基本功能或者重要功能已经正确实现

104、简单说一下bug等级是如何确定的？

• 致命
  • 一般会引发蓝屏、死机、人身生命安全威胁、非常重要的功能没有实现或未正确实现、数据库死锁、数据库连接失败、因为错误操作导致程序中断
• 严重
  • 重要功能没实现或者出现错误、接口出错
• 一般
  • 常用功能没实现或者出错，界面错误、出错不提示、输入限制不在前台实现
• 小
  • 界面不规范，长时间操作不提示、文字不使用专业术语、必输项与可输入项没有明确区分
• 意见和建议

105、在三角形计算中，要求三角形的三个边长：A，B和C。当三边不可能构可构成三角形时提示错误，可构成三角形时计算三角形周长。若是等腰三角形打印“等腰三角形”，若是等边三角形，则提示“等边三角形”。画出程序流程图、控制流程图、找出基本测试路径，对此设计一个测试用例。

• 程序流程图

• 控制流图

• 测试路径

• 语句覆盖/路径覆盖

  • 124578
    • 用例：3、3、4
  • 123
    • 用例：1、2、3
  • 12456
    • 用例：3、3、3

• 判定覆盖

  • 用例同上

• 条件覆盖

  • 条件 a+b>c、a+c>b、b+c>a、a=b、a=c、b=c
  • 都成立的用例：3、4、5
  • 都不成立的用例：0、0、0

• 判定-条件覆盖

  • 上边判定+条件

• 条件组合

• 条件 a+b>c、a+c>b、b+c>a

  • a+b>c 真、a+c>b 真，b+c>a 真
    • 用例：3、4、6
  • a+b>c 真、a+c>b 真，b+c>a 假
    • 用例：2、1、0
  • a+b>c 真、a+c>b 假，b+c>a 真
    • 用例：0、2、1
  • l …

• 条件 a=b、a=c、b=c

  • a=b 真、a=c 真
    • 用例：3、3、3
  • a=b 真、a=c 假
    • 用例：3、3、4
  • a=b 假，a=c 真
    • 用例：3、4、3
  • a=b 假，a=c 假
    • 用例：3、4、6

107、没时间写测试用例怎么办？

• 在日常测试过程中，每天写日志时，记录重要的需求
• 随时记录重要的测试点
• 测试过程中，会发现一些缺陷，把这些缺陷整理成测试点
• 重要数据也可以做记录
• 寻找空闲时间，写出用例

108、有一个在线购物网站，分别适配PC端和微信端，针对选择商品—提交订单—支付这个流程（默认已经成功登录），请列出你能想到的测试点。

• 不选择商品，提交订单
• 选择一件商品
• 选择一件商品的多件
• 选择不同商品各一件
• 选择多种商品各多件
• 选择多件商品，有一件的，有多件的
• 修改商品的件数
  • 一件变多件
  • 多件变一件
  • 一件变 0
• 删除某类商品
• 清空所有商品
• 提交订单后，撤销订单
• 提交订单后，付款
• 提交订单后，不付款
• 分别在 pc 端和微信端作上述测试
• 查看 pc 段和微信端数据是否同步

109、说说你的测试用例设计思路

在测试用例设计中，我会考虑以下几个方面：

功能测试：针对每个功能点设计测试用例，确保其按照预期工作。例如，对于一个登录功能，可以设计一些测试用例来验证不同的用户名和密码组合的登录是否成功，以及登录成功后是否跳转到正确的页面。

边界测试：针对每个功能的边界条件设计测试用例，以测试系统的鲁棒性和容错性。例如，对于一个取值范围为1-100的输入框，可以设计测试用例来验证输入为1、100以及1-100之外的值时系统的反应。

异常测试：设计测试用例来测试系统的异常处理能力。例如，对于一个上传文件的功能，可以设计测试用例来验证系统对于不支持的文件类型、超过限制大小的文件等情况的处理。

性能测试：设计测试用例来评估系统的性能。例如，对于一个搜索功能，可以设计测试用例来测试搜索过程的响应时间、并发用户数以及搜索结果的准确性。

安全测试：设计测试用例来验证系统的安全性。例如，对于一个用户权限管理功能，可以设计测试用例来验证系统是否正确地限制了用户的访问权限。

兼容性测试：设计测试用例来验证系统在不同平台安卓还是苹果，还是windows，苹果系统等、浏览器、设备上的兼容性。例如，对于一个网页应用，可以设计测试用例来测试在不同浏览器（Chrome、Firefox、Safari等）上的兼容性。 在设计测试用例时，还需要考虑测试的可重复性、覆盖率以及测试数据的准备等因素，以保证测试的全面性和可靠性。同时，测试用例的设计思路也可以根据具体的场景和需求进行调整和补充。

110、知道Selenium底层原理吗？

是的，我了解Selenium的底层原理。Selenium是一个用于自动化浏览器操作的工具，底层原理主要涉及三个组件：WebDriver，浏览器驱动和浏览器本身。

WebDriver：
WebDriver是Selenium的核心组件，用于控制浏览器进行页面操作和模拟用户行为。
WebDriver提供了丰富的API来操作浏览器，如页面导航、元素定位和操作、表单填写、截图等功能。
WebDriver支持多种编程语言，如Java、Python、C#等，开发人员可以根据自己的喜好和项目需求选择合适的语言进行自动化测试脚本的编写。

浏览器驱动：
浏览器驱动是连接WebDriver和浏览器的桥梁，它负责与特定浏览器进行通信。
不同浏览器需要使用对应的驱动程序，如Chrome需要使用ChromeDriver，Firefox需要使用GeckoDriver，以及其他浏览器的相应驱动。
浏览器驱动接收来自WebDriver的指令，将其翻译为浏览器可理解的操作，然后将结果返回给WebDriver。

浏览器：
浏览器是实际被自动化的目标，它将WebDriver传递的指令执行，然后将结果返回给WebDriver。
Selenium支持多种主流浏览器，如Chrome、Firefox、IE、Safari等。

通过这三个组件的协作，Selenium能够模拟用户在浏览器中的操作，实现自动化测试和网页数据抓取等任务。它支持跨浏览器、跨平台，并具有广泛的应用领域，如Web应用测试、UI自动化、爬虫等。

111、我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？

1、检查系统是否有中毒的特征；

2、检查软件/硬件的配置是否符合软件的推荐标准；

3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；

4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；

5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。