Hi，大家好，我是编程小6，很荣幸遇见你，我把这些年在开发过程中遇到的问题或想法写出来，今天说一说
测试理论面试题,希望能够帮助你!!!。

1  说一下你们的测试流程

没有做过项目的直接介绍下v模型（老师上课肯定有讲过），有经验的直接从接到项目/单子后讲自己如何一步步实施测试的。

例如你可以回答这样的流程：

1.软件开发完成以后，就会把需求规格说明书、软件程序和软件源代码发过来；

2.项目经理出测试方案（要使用什么样的测试方法、测试策略）安排测试计划（测试人员、资源、进度的安排，测试的范围和完成的目标）；

3.测试人员编写和执行测试用例；

4.提交缺陷并且进行跟踪；

5.编写测试报告。

 

 2 在项目组中做过什么样的工作？

1、根据软件设计需求制定测试计划，设计测试数据和测试用例；

2、有效地执行测试用例，提交测试报告；

3、准确地定位并跟踪问题，推动问题及时合理地解决；

4、完成对产品的集成测试与系统测试，对产品的软件功能、性能及其它功能

 

 

3 你平时会写测试用例吗？

其实这是一个很经典的面试问题，留心的朋友会发现，基本上很多公司都有这样的问题。遇到这种问题最关键的不要怕，说话的时候有条有理，阐述的时候面面俱到的就好了，最重要的一定要稳。

例如：给你一个杯子如何测试？

界面测试：查看杯子的外观是否得体。（外形、图案）、

易用性：杯子是否烫手、是否有防滑措施、是否方便饮水、是否易用手端着或手拿。

安全性：使用过程中杯口是否容易给身体造成伤害，，杯子有没有毒和细菌。

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

稳定性：杯子一直盛着水，时间长了是否会漏水。

兼容性：是否可容纳高温度水、果汁、酒精、汽油等。

用户文档：用户使用手册上是否有对杯子的使用方法进行限制，是否出现使用过程中友好的提示、该注意的问题、使用环境等有详细的描述。

 

4  你认为是bug，而开发不认同时怎么办？

这个主要考察的是你与团队的沟通能力，按照套路回答就好了。

1、简单分析下需求可能对客户的影响，通过影响和严重程度来说服开发来进行修改。

2、产品需求里边没有明确要求的，需要先和需求人员讨论一下，如果确认需要进行修改。在三方会议上进行提出。

 

 

5  如何判断一个问题是bug？

根据软件需求文档里边的需求描述，对于需求描述里边没有的就要根据自己的测试经验了，这里可以说说你平时的经验，没有经验的就可以把老师课上教的一些方法说出来。

 

 

6 平时写测试用例会用到的设计方法？

这个要充分准备，最好能举出例子（非常考察课外积累和工作经验！）

几种常见的测试方法：错误推断法、正交实验法、因果图法、场景分析法、判定表法，必须对这些测试方法都能说出一二，面试官很有可能根据你说的测试用例设计方法再追问你（随便从你刚刚说过的话里边挑出来一个问你定义），所以一定不要说自己一知半解的东西，宁愿少说。

 

 

7 有哪些不同的测试计划活动？

确定测试的范围和目标

定义测试的整体方法，定义进入和退出标准

决定测试什么以及谁将测试应用程序的哪个部分

安排测试设计会话

为不同的测试活动分配资源

确定用于测试的工具

报告测试进度

生成退出报告

 

8  哪些信息应包含在给开发的缺陷或错误报告中？

缺陷的简要总结

完整描述缺陷，包括重现步骤

如果需要，可以截取附件

发现和提出缺陷的日期

谁报告了这个缺陷

缺陷的严重性和/或优先级

哪个组件是指定的缺陷

 

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

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

2、制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：

     功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试

3、设计测试用例：

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

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

     多媒体元素是否可以正确加载和显示。多语言支持是否能够正确显示选择的语言等。

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

•  
•                                                                
•  
•  
•  

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

     压力测试；             负载测试；             强度测试

数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。

安全性测试：

•  
•  
• SQL 注入等。
•  

兼容性包括：浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性

 

10 软件生存周期及其模型是什么？

软件生存周期是软件开发全部过程、活动和任务的结构框架，是从可行性研究到需求分析、

软件设计、编码、测试、软件发布维护的过程。

在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺

少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。

 

11 什么是软件测试？软件测试的目的与原则

使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需

求或弄清预期结果与实际结果之间的差别。

软件测试的目的：

测试是程序的执行过程，目的在于发现错误

一个成功的测试用例在于发现至今未发现的错误

一个成功的测试是发现了至今未发现的错误的测试

确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明。

确保产品满足性能和效率的要求

确保产品是健壮的和适应用户环境的

软件测试的原则：

软件测试应尽早执行，并贯穿于整个软件生命周期

软件测试应追溯需求

测试应由第三方来构造

穷举测试是不可能的,要遵循 Good-enough 原则

必须确定预期输出（或结果）

必须彻底检查每个测试结果

充分注意测试中的群集现象

缺陷的二八定理

严格执行测试计划，排除测试的随意性

注意合法合理的输入，也要注意非法的非预期的输入

检查程序是否做了不该做的

测试应从“小规模”开始，逐步转向“大规模”

反复使用同样的测试会使软件具有抵抗力

关注缺陷的修复

 

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

 

白盒测试：

逻辑覆盖

循环覆盖

基本路径覆盖

黑盒测试：

边界值分析法

等价类划分

错误猜测法

因果图法

状态图法

测试大纲法

随机测试

场景法

 

13 什么是测试用例 什么是测试脚本？

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

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

 

 

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

1、寻找 Bug；

2、避免软件开发过程中的缺陷；

3、衡量软件的品质；

4、关注用户的需求。

总的目标是：确保软件的质量。

 

15 在您以往的工作中，一条软件缺陷（或者叫 Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

 

一条 Bug 记录最基本应包含：编号、Bug 所属模块、Bug 描述、Bug 级别、发现日期、发现人、修改日期、修改人、修改方法、回归结果等等；

要有效的发现 Bug 需参考需求以及详细设计等前期文档设计出高效的测试用例，然后严格执行测试用例，对发现的问题要充分确认

肯定，然后再向外发布如此才能提高提交 Bug 的质量。

黑盒测试和白盒测试是软件测试的两种基本方法，请分别说明各自的优点和缺点！

 

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

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

包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试

交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，

可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对

测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划

测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

所以其中最重要的是测试测试策略和测试方法（最好是能先评审）。

 

 

17 BUG（缺陷）的生命周期

  对于一个问题，其处理过程是一个周期，周期的不同阶段，其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。

提交（打开） ： 表示问题被提交等待有人处理。

指派（转交） ： 问题被重新指派给某人处理。

处理 ： 问题在处理中，尚未完成。

固定 ： 确认此问题存在，但暂时不进行处理。

回归 ： 对已经修复的问题进行回归确认。Reopened :

关闭 ： 问题的最后一个状态

 

 

 

 

 

18 在团队中建立测试人员与开发人员良好沟通中注意以下几点：

一真诚

二是团队精神

三是在专业上有共同语言

四是要对事不对人，工作至上

当然也可以通过直接指出一些小问题，而不是进入 BUG Tracking System 来增加对方的好感

 

19  你对测试最大的兴趣在哪里？为什么？

回答这个面试题，没有固定统一的答案，但可能是许多企业都会问到的。提供以下答案供考：

最大的兴趣，感觉这是一个有挑战性的工作；

测试是一个经验行业，工作越久越能感觉到做好测试的难度和乐趣

通过自己的工作，能使软件产品越来越完善，从中体会到乐趣

回答此类问题注意以下几个方面：

尽可能的切合招聘企业的技术路线来表达你的兴趣，例如该企业是数据库应用的企业，那么

表示你的兴趣在数据库的测试，并且希望通过测试提升自己的数据库掌握能力。

表明你做测试的目的是为了提升能力，也是为了更好的做好测试；提升能力不是为了以后转

开发或其他的，除非用人企业有这样的安排。

不要过多的表达你的兴趣在招聘企业的范畴这外。比如招聘企业是做财务软件的，可是你表

现出来的是对游戏软件的兴趣；或招聘是做 JAVA 开发的，而你的兴趣是在 C 类语言程序的

开发。

 

20 你自认为测试的优势在哪里？

该面试也没有固定不变的答案，但可参考以下几点，并结合自身特点：

有韧性

有耐心

做事有条理性

喜欢面对挑战

有信心做好每一件事情

较强的沟通能力

从以前的经理处都得到了很好的评价表明我做的很好

 

21. 一个测试工程师应具备那些素质？

1、责任心

2、沟通能力

3、团队合作精神

4、耐心、细心、信心

5、时时保持怀疑态度，并且有缺陷预防的意识

6、具备一定的编程经验

 

22 你认为做好测试计划工作的关键是什么？

明确测试的目标，增强测试计划的实用性

编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确坚持“5W”规则，明确内容与过程“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。

采用评审和更新机制，保证测试计划满足实际需求测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。

分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

 

23你的测试职业发展目标是什么？

测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试

工程师奔去。而且我也有初步的职业规划，前 3 年累积测试经验，不断的更新自己改正自己

 

24 测试结束的标准是什么？

从微观上来说，在测试计划中定义，比如系统在一定性 能下平稳运行 72 小时，目前 Bug

Tracking System 中，本版本中没有一般严重的 BUG，普通 BUG 的数量在 3 以下，BUG 修复

率 90%以上等等参数，然后由开发经理，测试经理，项目经理共同签字认同版本 Release。

如果说宏观的，则是当这个软件彻底的消失以后，测试就结束了

 

25 一套完整的测试应该由哪些阶段组成？

可行性分析、需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验

收测试

 

26 、测试用例通常包括那些内容？

不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出„„）

软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。

用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：

PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为“ 高 ” ；反之亦然，一般而言，是 5 级划分。

测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在

实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

 

27 在您所经历的测试活动中，参与人员有哪些？您所担任的角色是什么？

有项目管理员、开发管理员、系统分析员、设计员、开发员、质量管理员、测试管理员、测

试设计员、测试员

担任过测试管理员、测试设计员、测试员

 

28 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收 测试的区别与联系。

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要

求。

白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规

格要求，所有内部成分是否以经过检查。

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑

盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，

检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒

测试主要是为了发现以下几类错误：

1、是否有不正确或遗漏的功能？

2、在接口上，输入是否能正确的接受？能否输出正确的结果？

3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

4、性能上是否能够满足要求？

5、是否有初始化或终止性错误？

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个

打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，

对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状

态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行

如下检查：

1、对程序模块的所有独立的执行路径至少测试一遍。

2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性，等等。

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、

很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下

某个特定函数的行为。

单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有

责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了

证明这段代码的行为和我们期望的一致。

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：

两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组

件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程

序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起

测试。最后，将构成进程的所有模块一起测试。

系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能

提供系统方案说明书中指定功能的有效方法。（常见的联调测试）

系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并

且遵循系统设计。

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，

并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计

把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步

验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

 

29 针对于软件的行业背景，你如何理解软件的业务？

阅读用户手册了解软件的功能和操作流程；

看一些业务的专业书籍补充业务知识；

如果有用户实际的数据，可以拿实际的数据进行参考；

参考以前的用例和 BUG 报告；

在使用软件的过程中多思考；

多与产品经理交流。

 

30 什么是版本控制，常用的版本控制系统有哪些？

版本控制（Revision control）是一种软体工程技巧，籍以在开发的过程中，确保由不同人所编辑的同一档案都

得到更新。

Git(读音为/gɪt/。)是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。

Git 是 Linus Torvalds 为 了 帮 助 管 理 Linux 内 核 开 发 而 开 发 的 一 个 开 放 源 码 的 版 本 控 制 软 件 。

https://git-scm.com/doc

SVN 是 Subversion 的简称，是一个开放源代码的版本控制系统，相较于 RCS、CVS，它采用了分支管理系统，

它 的 设 计 目 标 就 是 取 代 CVS 。 互 联 网 上 很 多 版 本 控 制 服 务 已 从 CVS 迁 移 到 Subversion 。

https://tortoisesvn.net/support.html

 

 31 一个有广告的纸杯子，请设计测试用例？

测试项目：杯子

需求测试：查看杯子使用说明书

界面测试：查看杯子外观

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

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

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

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

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

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

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

疲劳测试：将杯子盛上水（案例一）放 24 小时检查泄漏时间和情况；盛上汽油（案例二）放 24 小时泄漏

时间和情检查况等

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

跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损

震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输

基本功能测试（逻辑功能测试）。

（1）硬度：是否达到设计标准。

装载能力：在杯子内分别装入少量的、半杯的、满杯的，看其装载量是否达到设计标准。

装载种类：开水（是否产生异味）、温水、冷水、冰水、咖啡。。。

（2）界面测试（UI 测试）。

看其形状、大小设计是否适合人方便拿起。

外观是否吸引人（广告嘛），赏心悦目。

带广告的图案沾水受是否掉色、模糊。

（3）易用性测试。

看其形状、大小设计是否适合人方便拿起。

残疾人士用此杯去喝水的容程度。

杯子设计是否上大下小，在运输过程中可以套在一起有效利用空间，在使用时也容易拿开。

（4）稳定性测试（24 X 7 测试）。装入液体后记录其多少以后漏水。

（5）安全性测试。杯子所用的材料（包括纸基、涂层和广告颜料）是否符合食品卫生标准，在内外温度等环境

因素下是否会与所盛各种饮料相反应，而产生对人体有害的物质。

（6）本地化测试。为国际化和本地化的需要，广告图案和文字是否在政治、宗教和文化方面具有广泛的适用性。

（7）对设计的改进建议。“如果是一次性杯子，能否标示已使用（比如变色）”和“杯子是否有使用者标贴（多人

使用时防止混淆）”。

 

32 .一个身份证号码输入框，怎么设计用例？

校验身份证号规则的有效性（包括地址码、生日期码、顺序码和校验码

校验 15 位身份证号和 18 位身份正好都是可用的

校验末位是 X 的情况

校验不足 15 位、16-17 位和大于 18 位的情况

如果是必输项，校验不输入的时候会不会有正确的提示

如果不是必输项，则要校验不输入的时候流程能否正常进行

校验输入非数字的情况，是否会有正确提示信息（包括大小写字母、汉字、特殊字符和标点符号）

校验输入全角的数字的时候，系统是否会识别（这个得根据需求确定是否可以使用全角的数字）

 

 

今天的分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。