【干货分享】2022软件测试面试题汇总

慢慢改变

前言

本篇分享的软件测试面试题内容主要包括：测试总体、需求分析、测试计划、测试策略、测试用例、缺陷报告、测试总结报告、白盒测试、单元测试、集成测试、系统测试、验收测试等等26个模块。


1. 什么是软件测试？

答：为了发现程序中的错误而执行程序的过程
2. 软件测试的目的？

答：首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布 特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分 析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。
其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。 详细而严谨的可靠性增长模型可以证明这一点。
测试的目的是按照用户所需软件的质量，检查开发软件过程出现的 bug, 使得开发人员 及时修改，可以避免在开发结束的时候发现软件存在质量问题，避免公司不必要的损失。 赢得用户对公司产品的认可。
测试的目的是以最少人力、物力和时间找出软件中潜在各种错误和缺陷，通过修正种 错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的 商业风险。
测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。 实施测试收集到的测试结果数据为可靠性分析提供了依据。 测试不能表明软件中不存在错误，它只能说明软件中存在错误。
3. 软件测试的目标

答：发现尽可能多的错误 测试是一个为了寻找错误而运行程序的过程。 一个好的测试案例是指很可能找到迄今为止尚未发现的错误的用例。 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。
4. 软件测试的原则

1) 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
2) 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
3) 程序员应避免检查自己的程序。
4) 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。
5) 软件测试的原则
6) 充分注意测试中的群集现象。 经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
7) 严格执行测试计划，排除测试的随意性。
8) 应当对每一个测试结果做全面检查。
9) 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

5. 测试的职责 测试经理：

1、制定测试计划。
2、确保测试过程正常进行。 测试工程师
1、编写测试用例
2、搭建测试环境
3、执行测试

6. 软件都有多少种分类？

答：根据功能的不同，电脑软件可以粗略地分成四个层次：
最贴近电脑硬件的是一些小巧的软件。它们实现一些最基本的功能，通常“固化”在只
读存储器芯片中，因此称为固件。 系统软件包括操作系统和编译器软件等。系统软件和硬件一起提供一个“平台”。它们
管理和优化电脑硬件资源的使用。
支持软件。包括图形用户界面、软件开发工具、软件评测工具、数据库管理系统、中间 件等。
应用软件种类最多，包括办公软件、电子商务软件、通信软件、行业软件，游戏软件等 等。
7. 软件的分类
8. 测试的主要方面

答：A、功能测试：a、链接测试 b、表单测试 c、Cookies 测试 d、设计语言测试 e、数 据库测试
              B、性能测试：a、连接速度测试 b、负载测试 c、压力测试
              C、接口测试：a、服务器接口 b、外部接口 c、错误处理
              D、可用性测试: a、导航测试 b、图形测试 c、内容测试 d、整体界面测试
             E、兼容性测试：a、平台测试 b、浏览器测试 c、视频测试 d、Modem/连接速率测试 f、打印机测试 g、组合测试
             F、安全测试：a、目录设置 b、登录 c、Session d、日志文件 e、加密 f、安全漏洞              G、代码合法性测试：a、程序代码合法性检查 b、显示代码合法性检查 H、文档测试：

9. 软件测试的对象

答：软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。
需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格
说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象
10. 什么是“测试案例”？

答：测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便 来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测 试条件/设置、输入数据要求、步骤、以及预期的结果。 注：开发一个应用软件的测试案例的过程，需要全面、深入地考虑该软件的操作，所以有助 于发现在其需求或设计里面的问题。因此，如果有可能，在开发周期中应当尽早准备测试案 例。
11. 怎么编写案例？

答：案例的编写与测试阶段的定义有很大的关系。系统测试和 unit 测试的案例可能不同。 总体而言测试案例根据系统的需求而定。
12. 软件测试的两种方法

答：黑盒测试和白盒测试
黑盒：这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑
结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。 黑盒测试又叫做功能测试或数据驱动测试。 白盒：此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑
结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。 通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测
试又称为结构测试或逻辑驱动测试。
13. 测试结束的标准是什么？

答：1.用例全部执行。2.覆盖率达到标准。3.缺陷率达到标准。4.其他指标达到质量
标准
14. 软件的生命周期

答：软件生命周期是指一个计算机软件从功能确定、设计，到开发成功投入使用，并在使用中不断地修改、增补和完善，直到停止该软件的使用的全过程（从酝酿到废弃的过 程）
什么是软件的生命周期？
生命周期从收到应用软件开始算起，到该软件不再使用为止。它有如下各方面的内容： 初始构思、需求分析、功能设计、内部设计、文档计划、测试计划、文档准备、集成、测 试、维护、升级、再测试、逐步淘汰 (phase-out)、等等。
15. 软件测试按过程分为三个步骤

答：单元测试：单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，
进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单
元测试。
集成测试：在运行（可能是不完整）的应用中保证软件单元被结合后能正常操作的测 试执行的阶段
系统测试：当应用作为整体运行时的测试执行阶段
16. 面向对象的设计如何影响测试？

答：好的面向对象的工程设计使得从代码追溯内部设计、再到功能测试，最后追溯到需 求，成为一件容易的事。因为它对黑盒测试的影响很少 (不需要了解应用软件的内部设计) ， 而白盒测试只需针对该应用软件的对象。如果该应用软件设计得好，就可简化测试设计。
17. 软件带来错误的原因很多。主要的原因有哪些？

1) 交流不够、交流上有误解或者根本不进行交流
2) 软件复杂性
3) 程序设计错误
4) 需求变化
5) 时间压力
6) 代码文档贫乏
7) 软件开发工具

18. 软件测试的步骤是什么？

1) 测试过程按 4 个步骤进行，即单元测试（Unit Testing）、集成测试（Integrated Testing）、确认测试（Validation Testing）和系统测试（System Testing）及发 版测试。
2) 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序 模块是否正确地实现了规定的功能。
3) 集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进 行测试。
4) 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求， 以及软件配置是否完全、正确。
19. 如何录制测试脚本？

1) 新建一个脚本（Web/HTML 协议）
2) 点击录制按钮，在弹出的对话框的 URL 中输入”about:blank”。
3) 在打开的浏览器中进行正常操作流程后，结束录制。
4) 调试脚本并保存。可能要注意到字符集的关联。
5) 设置测试场景
6) 针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否 达标
7) 针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力 的条件下，系统是否会崩溃

20. 完全测试是不可能的，必须对测试的各项进行等价划分。

概念 等价分配：软件有无限的测试案例，我们要想办法把软件的相似输入、输出、操作分成
一组，来使无限的测试案例减小到同样有效的小范围，这个过程称为等价分配。
边界条件：软件计划的操作界限所在的边缘条件，即如果超出这个边界条件，就可能会 引出错误。
原因

输入量太大 输出结果太多 软件实现途径太多
软件说明书没有客观标准。从不同的角度看，软件缺陷的标准不同。
方法

数据测试：

1） 确定输入的边界条件，对边界线上的及边界线两边的数据进行测试；
2） 边界线可能是 2 的乘方，默认值、空白值、零值等；每一个软件测试问题各不相同， 可能包含格式各样边界的不同数据。

状态测试（软件的状态是指软件当前所处的情况或者模式）：

1） 每种状态至少访问一次；
2） 测试看起来最常见最普遍的状态转换；
3） 测试状态之间最不常用的分支；
4） 测试所有错误状态及其返回值；
5） 测试随机状态转换。

21. 应该考虑进行如何测试的测试方法

黑盒测试 (Black box testing) ── 不考虑内部设计和代码，根据需求和功能进行测 试。
白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑，按照代码的语
句、分支、路径和条件进行测试。
功能测试（functional testing）——对一个应用软件的功能模块进行黑盒测试。这种 测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。（这一 原则适用于所有的测试阶段。）
系统测试 ── 针对全部需求说明进行黑盒测试，包括系统中所有的部件。
回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变 化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。 进行此种测试，特别适于使用自动测试工具。
负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网 站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。
压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。 这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大
量重复、输入大数、对数据库进行非常复杂的查询，等等。
性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互 代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文 档终予以规定。
可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是 一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或 者使用其他技术。程序员和测试人员通常不参加可用性测试。
       安装/卸载测试 (install/uninstall testing) ── 对安装/卸载进行测试 (包括全部、 部分、升级操作)。
        安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损
坏时的防护情况。这需要精密复杂的测试技术。
        兼容性测试 (compatability testing) ── 测试在特殊的硬件/软件/操作系统/网络环 境下的软件表现。
        α 测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还 允许有较小的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人 员来进行。
       β 测试 (beta testing) ── 当开发和测试已基本完成，需要在正式发行之前最后寻找 毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来 进行。
22. 怎样估计测试工作量？

效率假设：即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度， 窗口的个数，每个窗口中的动作数目。对容量测试，主要依赖于建立测试所需数据 的工作量大小。
测试假设：为了验证一个测试需求所需测试动作数目。
应用的维数：应用的复杂度指标。例如要加入一个记录，测试需求的维数就是这个 记录中域的数目。
所处测试周期的阶段：有些阶段主要工作都在设计，有些阶段主要是测试执行。
23. 测试设计的问题

1) 不做测试设计，测试过程也是胡乱建立的。
2) 测试设计不详细，不是基于可量度的测试策略，例如测试计划覆盖一个集合或者测试需 求的一个子集。
3) 测试过程没有采用最好的技术来检验 Windows C/S 结构的测试需求
4) 测试用例的选择规则
5) 选择与测试需求的实质部分最相关的测试用例。
6) 选择的测试用例应该不容易应用程序的改变的影响。

24. 当测试过程发生错误时，有哪几种解决办法？

1) 跳转到别的测试过程
2) 调用一个能够清除错误的过程
3) 退出过程，启动另一个
4) 退出过程和应用程序，重新启动启动 Windows，在失败的地方重新开始测试

25. 测试执行的问题

测试执行的问题

1) 自动化测试没有有效的利用，使得手工测试太多。
2) 测试结果的捕获没有系统性，而且没有查看或调查
3) 缺陷报告必须用手工加入缺陷跟踪系统 错误分类

1、 测试用例失败 正常错误
2、 脚本命令失败 当测试过程不能不能执行录制过程中的某个功能时，回产生这种错误，如鼠标单击按钮或选 择菜单项等。它也能指示是缺陷还是测试过程的设计问题。
3、 致命错误 导致测试停止，这种情况最好重起 Windows。
具体步骤：

1) 建立测试系统
2) 准备测试过程
3) 运行初始化过程
4) 执行测试
5) 从终止的测试恢复
6) 验证预期结果
7) 调查突发结果
8) 记录缺陷日记

26. 测试评估的目标

1) 量化测试进程
2) 生成缺陷和测试覆盖率的总结报告
测试评估的问题
3) 没有把测试覆盖率作为报告测试进程的根据，使得不知测试是否结束；
4) 没有做缺陷评估，缺陷评估是量度软件可行性的重要指标；
5) 不使用专门的软件工具进行数据输入任务和相应的评估活动，使得这些任务变得繁重累 人。
测试覆盖率——评估测试完成多少的标准

27. 这些软件常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试 的尺度。

1) 测试是不完全的（测试不完全）
2) 测试具有免疫性（软件缺陷免疫性）
3) 测试是 “ 泛型概念 ” （全程测试）
4) 80-20 原则
5) 为效益而测试
6) 缺陷的必然性
7) 软件测试必须有预期结果
8) 软件测试的意义 - 事后分析

28. 如何提高测试？ 提高测试需要从几个方面着手，其实只是自己的一些感觉，不一 定就需要按部就班，需要找自己适合的点。

制定完备的测试计划 清楚的认识测试计划，测试计划是一个文档，能够保证整个研发过程中顺利执行的一个指导性文档，它描述了几个方面的问题。

1) 描述了项目的的
2) 描述了项目的开发周期
3) 描述了在测试中遇到的技术
4) 描述了测试案例的设计周期
5) 描述测试案例的执行周期
6) 描述了测试过程中用到的工具或者技术
7) 描述了测试过程中用到的资源情况
8) 描述了测试过程中可能遇到的风险以及规避方法
9） 提高案例设计水平

29. C/S 模式的优点和缺点

优点：

1) 由于客户端实现与服务器的直接相连，没有中间环节，因此响应速度快。
2) 操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。
3) C/S 结构的管理信息系统具有较强的事务处理能力，能实现复杂的业务流程。

缺点：

1) 需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户 群体，不能够实
2) 现快速部署安装和配置。
3) 兼容性差，对于不同的开发工具，具有较大的局限性。若采用不同工具，需要重新 改写程序。
4) 开发成本较高，需要具有一定专业水准的技术人员才能完成。

写在最后

作者本人平时也收集了一些简历模板，面试题资源完整版，及自动化资源详细解析，有需要请扣我。作为一位过来人也是希望你们少走一些弯路。
这些资料，对于做软件测试的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…….
祝大家都能拿到心动的offer~~