百捷网站建设,用 可以做网站软件吗,主播网站开发,mysql 收费 网站建设#x1f60f;作者简介#xff1a;博主是一位测试管理者#xff0c;同时也是一名对外企业兼职讲师。 #x1f4e1;主页地址#xff1a;#x1f30e;【Austin_zhai】#x1f30f; #x1f646;目的与景愿#xff1a;旨在于能帮助更多的测试行业人员提升软硬技能#xf… 作者简介博主是一位测试管理者同时也是一名对外企业兼职讲师。 主页地址【Austin_zhai】 目的与景愿旨在于能帮助更多的测试行业人员提升软硬技能分享行业相关最新信息。 声明博主日常工作较为繁忙文章会不定期更新各类行业或职场问题欢迎大家私信有空必回。 阅读目录1. 接上回2. 题目解析2.1 你如何进行测试计划的编写和执行2.2 你如何处理软件测试中的复杂业务场景和测试用例2.2.1 何为复杂业务场景2.2.2 复杂业务场景的应对2.2.3 复杂测试用例的应对2.3 简述测试用例的重要性以及应该包括哪些内容2.4 请简述QA和QC的区别及其重要性2.5 什么是回归测试 为什么要进行回归测试2.6 请说明压力测试和负载测试的区别2.7 如何对一个系统进行安全测试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行业中安全测试不一定每个公司都会去做但他却是一种评估系统、应用程序或网络的安全性和弱点的优秀测试方法。它其实可以帮助测试人员发现系统和应用程序中的安全漏洞和脆弱性以及评估其安全性能和风险。如果你想让公司的产品拥有强健和稳定的生命周期那么安全测试一定是每个测试人员都无法回避的测试活动。 这里博主给到大家一个较为主流的安全测试执行流程。首先确定测试目标和范围比如这次安全测试需要达成的测试目标是发现系统漏洞评估系统的安全性范围很好理解和黑盒一样被测对象的哪些功能模块其次设计测试计划与测试用例同黑盒不展开第三针对测试目标的具体内容开展对应的测试活动利用各种测试手段渗透、代码走查、模拟攻击、加密检测、安全评估、社交工程等等第四测试过程中收集测试数据这些数据对于测试结果的汇总与安全性评估报告等的产出有着决定性的作用一定要保证测试手段的正确最后就是结果数据分析与问题修复根据测试报告中的问题和建议分析和修复系统中存在的安全问题和漏洞达成最终以提高系统的安全性的目的。 另外很多测试人员习惯使用各类的安全测试自动化工具但这里博主还是要建议大家在执行自动化检测的同时最好可以自己动手对被测对象做一些手工的安全测试因为有些场景可能无法使用自动化工具来达到较为理想的测试效果比如未授权访问、会话管理问题等。
