😏作者简介：博主是一位测试管理者，同时也是一名对外企业兼职讲师。
📡主页地址：🌎【Austin_zhai】🌏
🙆目的与景愿：旨在于能帮助更多的测试行业人员提升软硬技能，分享行业相关最新信息。
💎声明：博主日常工作较为繁忙，文章会不定期更新，各类行业或职场问题欢迎大家私信，有空必回。

 
 

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就可以各自负责确保软件的质量得到保证，以确保最终交付的软件符合用户的需求和期望。

 
 

2.5 什么是回归测试？ 为什么要进行回归测试？

  什么是回归测试的这个概念应该也不用博主在这里展开说了，大家只要知道回归测试一般在软件代码修改或更新之后，对软件进行的再次测试，以确保修改或更新后的软件仍然能够正常工作，而且没有引入新的问题或缺陷的一种测试类型就行。那么为什么要做回归测试呢？其实在我们的软件测试过程中，无论是因为需求还是缺陷的缘故，这都会需要开发人员不断进行代码的修改和更新，以使软件更加完善和健壮。然而，这些修改或更新有可能会影响到原有的功能或者产生新的问题，因此需要执行回归测试来让我们及时发现和纠正软件修改后可能产生的问题，保证软件的稳定性和可靠性，同时也因为回归测试大部分执行的内容都是主流程和修改更新的功能模块部分以及与之业务相关的功能模块，所以也可以大大节约测试成本和时间。

 
 

2.6 请说明压力测试和负载测试的区别

  虽然压力与负载测试都属于性能测试，但无论对于测试目的、场景、策略来说都是完全不同的两类测试活动。简单来说压力测试是通过模拟高负载情况下的各种条件和场景，来测试系统在极限负荷下的性能和稳定性。而负载测试则是通过模拟用户使用软件的真实场景，来测试系统在正常负载下的性能和稳定性。经常会有测试同学把这两个概念混淆在一起，对于所需要的测试性能指标也是云里雾里的，像负载测试的性能指标可以找运维人员去拿，而压力测试的指标一般是由产品人员给出。

  这里为了方便大家更好的理解其中的区别，我们举个例子，比如在测试活动中我们需要对一个web产品做压力和负载测试。那么先确认请测试的范围（具体针对哪些业务流和与之相关联的功能模块），在做压力测试时，我们需要模拟大量的用户同时访问产品，例如10000个用户，同时模拟这些用户在同一时刻进行测试前规定的业务操作，以测试产品在高负载情况下的性能和稳定性；而在做负载测试时，我们就需要根据web产品的真实用户访问情况，模拟一定数量的用户访问产品，例如1000个用户，模拟这些用户在一段时间内（比如1小时）内访问产品并做一些测试前规定好的业务操作，以测试产品在正常负载下的性能和稳定性。

 
 

2.7 如何对一个系统进行安全测试

  在现今的IT行业中，安全测试不一定每个公司都会去做，但他却是一种评估系统、应用程序或网络的安全性和弱点的优秀测试方法。它其实可以帮助测试人员发现系统和应用程序中的安全漏洞和脆弱性，以及评估其安全性能和风险。如果你想让公司的产品拥有强健和稳定的生命周期，那么安全测试一定是每个测试人员都无法回避的测试活动。

  这里博主给到大家一个较为主流的安全测试执行流程。首先，确定测试目标和范围，比如这次安全测试需要达成的测试目标是发现系统漏洞？评估系统的安全性？范围很好理解，和黑盒一样，被测对象的哪些功能模块；其次，设计测试计划与测试用例，同黑盒，不展开；第三，针对测试目标的具体内容，开展对应的测试活动，利用各种测试手段（渗透、代码走查、模拟攻击、加密检测、安全评估、社交工程等等）；第四，测试过程中收集测试数据，这些数据对于测试结果的汇总与安全性评估报告等的产出有着决定性的作用，一定要保证测试手段的正确；最后就是结果数据分析与问题修复，根据测试报告中的问题和建议，分析和修复系统中存在的安全问题和漏洞，达成最终以提高系统的安全性的目的。

  另外很多测试人员习惯使用各类的安全测试自动化工具，但这里博主还是要建议大家在执行自动化检测的同时，最好可以自己动手对被测对象做一些手工的安全测试，因为有些场景可能无法使用自动化工具来达到较为理想的测试效果，比如未授权访问、会话管理问题等。