软件测试最全软件测试面试题 —— 整理与解析（3）_机票购买测试场景面试，搞懂开源框架设计思想真的这么重要吗-CSDN博客

本文链接：https://blog.csdn.net/2401_84715513/article/details/138795671

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

+ [2.6 请说明压力测试和负载测试的区别](#26__93)
+ [2.7 如何对一个系统进行安全测试](#27__102)

1. 接上回

在这里插入图片描述

之前有粉丝私信博主，除了之前介绍的高频面试题之外，还想了解一些大厂经常会提出的面试题与答题思路，今天就给大家带来一部分大厂会经常使用的软测面试题，大家可以通过面试题内的一些解析再结合自己的真实工作经验来进行答题思路的提取、整理。友情提示：硬背答案虽可，但容易翻车哦。

2. 题目解析

在介绍之前，首先大家要明白的就是在大厂的此类面试中，会有很多开放性的问题，答案不仅仅局限于一个或几个，除了面试者扎实的基础岗位技能之外，用人单位更加需要的是不拘泥于现状、不易固化的产品测试意识与思维。所以，在诸如此类的面试场合，大家最好是能提前将自己掌握的技能进行总结与输出，结合实际并将彼此之间进行连接，形成自己的测试工作体系。那在面对一些开放性面试题的时候就能更加的游刃有余，而不是脑中一片空白。

2.1 你如何进行测试计划的编写和执行

在这里插入图片描述
这题我们需要分为两个部分去进行解答，首先就是编写，其实就最基本的测试计划来说，无非就包含测试范围、测试目标、测试方法、测试策略、测试资源等元素，要快速完成这些内容，那我们就需要从需求分析就开始进行计划的制定，无论是熟悉需求、内容设计、过程讨论、认知统一、计划编写、结果周知都必须有序且明确的说明到。接下来，就是执行。计划的执行阶段贯穿整个测试执行活动中，我们要突出如何有效的按照测试计划执行测试活动，并且对测试计划进行定期的更新与优化，这个动作可以在测试执行中的用例设计、执行、缺陷管理等几个环节进行说明。

切记，在回答的时候一定要根据自己的实际岗位工作经验与项目情况进行说明，最好能在讲到编写与执行方两个方面的时候结合一个例子来展开说明你是如何做这些事情的。这样做的好处就是可以强调你在测试活动中对于测试计划的理解与实践有着很强的经验，另外就是最好辅以一些团队成员与你互动的细节，毕竟测试计划的执行成功离不开团队成员的高度配合，同时也可以展现你的团队协作与沟通能力。

2.2 你如何处理软件测试中的复杂业务场景和测试用例

在这里插入图片描述
这一题也是见仁见智的经典题目，相信大家在工作中多多少少肯定会碰到复杂的测试场景和与之对应的测试用例，乍一看这题问得好像挺唬人的，但其实只要将其分解开的话，相对来说还是挺好回答的。为了能让大家看的更为的透彻，我们就将答题思路分解开给大家一一讲解。

2.2.1 何为复杂业务场景

在回答这个问题之间，我们必须先搞清楚到底什么是复杂场景，这里的复杂场景一般是指复杂的业务组合，它通常涉及多个业务流程、多个业务系统、多种用户角色、多个操作步骤、多个数据输入和输出等因素，这些因素会根据业务的需要进行组合，当这些因素组合在一起的情况下就变成了我们所谓的复杂业务场景。

而针对类似这样的复杂业务场景，我们的测试同学就需要考虑更多的测试因素，比如各种异常情况、边界条件、并发访问、数据处理等，这会使得测试变得更加困难和复杂。举个例子，如果你需要测试一款航空公司的订票软件，那么你就会碰到以下的一些复杂业务场景：

1. 被测对象需要能够正确计算各种不同的机票价格，包括成人票、儿童票、学生票、军人票、企业优惠票等，同时还需要配合不同的促销活动、折扣等因素；

2. 被测对象需要在乘客需要预订多个联程航班时，系统需要能够正确处理多个航班之间的转机、行李转运等事项；

3. 被测对象需要让乘客可以通过该系统预订特殊服务，例如残疾人服务、儿童服务、餐食服务等，系统需要能够正确处理这些服务的预订和提供相应的服务。

但实际针对以上的这些因素其实表面不单单是简单的单个复杂场景的功能测试，如果以上的3个因素相互进行组合的话，我们可以创造出更多的复杂业务场景，所以对于测试人员来说，如何处理复杂业务场景的能力也是体现其作为软测工程师的重要核心竞争力之一。

2.2.2 复杂业务场景的应对

首先我们需要先了解其相关业务的产品需求与功能设计，通过分析这些资料来准确的了解被测对象的功能内容与预期行为。对以上这些事项有了比较细致的了解之后，我们就可以在前期阶段对于测试场景的设计有一个比较良好的认知和覆盖情况。接下来我们就需要利用前期设计完成的各类测试场景与需求文档或产品设计进行比较，通过已知事项的排列组合将复杂业务场景尽可能多的筛选出来。然后要制定测试策略，不同的测试场景需要不同的测试策略，包括测试用例的设计、测试范围和测试数据的准备等等。如果需要多个场景进行协作，那我们就要将被测对象的预期行为进行明确的路线划分，确保多条测试业务流不会互相干扰，保证其独立性。除此之外，在执行的后期，我们要高效及时地进行问题管理，对于与之相对应的问题与进度及时追踪。最后客户沟通与相关行业的业务深耕也是必不可少的，随着越发的深入行业内部，相信对于复杂业务场景的理解与发现也会越发的娴熟与简单。

2.2.3 复杂测试用例的应对

对于一些复杂业务场景的测试，我们设计相关的复杂测试用例就需要针对其复杂性来进行一些特殊的处理。一般来说复杂业务场景很难用几条测试用例来进行高度覆盖，那么我们可以对测试用例进行一些额外的设计动作，比如使用场景法+正交法来设计一组测试列表，千万不要拘泥于以往的一些设计形式，一定要用一条条的测试用例来进行，换一种更贴合复杂测试场景的方式可能会有更加意想不到的效果。再一个就是我们也可以利用数据驱动测试的特性，设计一系列的数据驱动用例，这样可以更加高效的快速匹配不同数组集合在复杂业务场景下的测试结果，比起单一的测试用例与之固定的单一测试数据，测试效果要事半功倍多了。对于有自动化测试与代码设计能力的同学来说就更加的简单了，我们可以通过自己对于产品业务的理解来对测试脚本进行设计，比如上面说的三个复杂场景，我们可以将其业务逻辑转化为代码逻辑，利用自动化用例中的测试参数来进行自动化的快速验证。但这里切记不要去直接搬运开发的业务逻辑代码，道理应该也不用博主多说，你的代码逻辑和开发的代码逻辑相同，那不就是测了个寂寞吗？

2.3 简述测试用例的重要性以及应该包括哪些内容

在这里插入图片描述
我们先来说说测试用例的重要性，简单来说，测试用例就像是一个执行标准手册，我们通过上面的执行步骤来严格执行测试，并对其结果来进行判断。这个不单单是针对测试人员，现在越来越多的开发人员也在利用测试团队编写的各类测试用例对其负责的功能模块进行验证工作。试想如果没有测试用例，对于测试人员来说简直就是灾难，产品质量保障的过程中可能会有场景或功能项的遗漏不说，对于功能的追溯、测试范围与测试深度也是有着较大的影响。另外从测试管理者的角度来说，测试用例不仅是确保团队有效产出成果的重要手段，还是分配人员执行内容、掌控工作进度的重要参考依据。所以对于产品质量保障活动来说，测试用例绝对是及其重要的组成因素之一。

测试用例的组成内容就不用多说了，还是那老几样，一般情况下会根据每个公司的情况不同，使用不同的载体形式展现不同的用例形式（xmind、excel、word、禅道、jira、TAPD等等等等），万变不离其宗的还是其执行的主旨，所以只要根据自身公司与团队的实际需求来配合使用即可。

2.4 请简述QA和QC的区别及其重要性

在这里插入图片描述
要回答这个问题我们就需要先搞清楚QA和QC是什么意思，QA的全称为Quality Assurance（质量保证），一般在项目和软件的开发过程中确保从需求发布到项目上线的整个流程都可以得到质量保证。QC的全称为Quality Control（质量控制），它最主要的职责是检测软件缺陷并进行纠正，一般针对软件测试过程的，以确保软件的功能和性能达到预期的要求。

其实这个也不难理解，在我们的产品项目过程中，QA团队会制定一些编码标准、测试计划和质量指标，以确保整个开发与测试团队在开发过程中能够按照相同的标准和流程进行工作。他们还需要定期检查团队的工作，以确保整体流程的质量得到保证。而QC就更好理解了，QC团队会执行各种测试，包括功能测试、性能测试和安全测试，以确保应用程序的各项功能和性能符合预期，并且尽力确保没有缺陷。

那么说到这里其实两者的区别和重要性也就很明显了，QA关注整个开发流程的可控性和可预测性，QC则专注于测试和发现软件的缺陷。通过这种方式，QA和QC就可以各自负责确保软件的质量得到保证，以确保最终交付的软件符合用户的需求和期望。