软件测试基础

场景设计

被问到场景设计的时候，一定要记住，第一句话:好的面试官，这个场景的话有没有一些额外的需求需要补充的?(这叫主动明确需求)

·公式:功能性、界面、易用性、兼容性、性能、安全

功能方面，尽可能的多想一想，比如数据长度的校验、数据类型的校验、是否必填校验等等，还需。要考虑到业务特性，增删改查等操作，越多越完善越好界面方面，固定话术:然后如果有UI设计稿的话也会验证一下界面的布局排版、字体大小、颜色等。

方面是否符合UI设计，是否合理美观易用性方面，能想到就说，也可以使用固定话术:然后因为是XX场景，那我也会参考一下相关的竞。品，看看人家的一些用户交互方面有没有比我们好的地方，可以向产品提出一些优化建议兼容性方面，根据给到的场景去讲，是web就讲web，是app就讲app，不要混为一谈，要注意的是o会有一些跨平台的兼容要考虑到，比如聊天场景，web端给app端发消息，app能正常接收性能方面，围绕大数据量:除了以上部分，我还会测试一下大数据量的情况，看看接口的响应时间。是否符合预期

安全方面，从接口层面去讲:还有就是安全的部分，如果说涉及到一些用户隐私信息比如密码登敏感信息，也会看一下接口层面在传输数据的时候有没有做加密处理，避免信息外露，还有一些接口的鉴权机制，比如测试一下token的有效性和时效性，还有token替换的一些场景也需要考虑差不多这些吧。

购物车怎么测试?(高)

测试基础

测试流程?三分钟;

需求文档-- 需求评审 -- 用例评审 -- 开发提测自测 -- 冒烟测试 --

参考1：

我们的这个测试流程的话就这样子的，我们是两周一个迭代的，首先我们产品会把这个需求文档给到我们。然后呢，我们会看一下这个需求文档里面本次迭代的功能是什么样子的。

遇到一些不明确的点，我会自己去记下来。我们后面的话会有一个需求评审的会议。当然我自己也会站在用户的角度去做一些探索性的思考。

将我的观点给说明出来。在需求评审的时候看一下产品对于我的一个观点，或者说是这些需求不明确的地方，在会议上做一个沟通，以及我们三方意见尽可能达成一致，最终把这个需求给确认排版下来。

需求评审完了之后的话，我们接下来就开始设计我们的测试点，编写我们的一个测试用例了。

当然为了保证我们这个用力覆盖度，我们也会去通过不同的测试方法，比如说等价类边界值来保证我们的测试覆盖度，可能也会有一个用例评审的环节，

在这个会议上针对于我的一个用例看一下有没有需要补充的，或者说是有哪些地方没有关注到，甚至是说有哪些是写的不合理的。在这个时候还能做一个及时的更正。

那之后的话就是开发去做一个提测了。

开发在提测之前也会做一个自测的，提测的时候会给我们一个提测邮件，这个提测邮件上面会写好我们每个提测功能的一个通过情况。

开发百分百提测通过了之后，我们才会正常执行我们的一个测试工作的，开发提测了没问题的话，

我们也会在测试环境，自己再做一遍冒烟测试的，没问题就开始全量执行了。这一块也是要去认真负责的执行,当然在这个执行用例的过程中，也会去发现一些bug。

发现了bug之后的话，我们会通过这个禅道这个平台来进行一个项目管理。然后开发修复完成之后，我们也要去做一个bug的一个实时验证，以及这个bug所影响到的功能。

我们要做一个影响性的一个回归，然后就是经过这样一个循环，然后等版本稳定之后的话，我们最终也会做一个回归测试。就是把我们本次迭代的功能以及本次迭代过程中所发现的一些bug。

还有就是这些bug所影响到的功能，也要做一个以及影响性回归，没有问题就可以上到预发了。

在预发的话相当于就是把我们测试环境所做的一些事情，就是在预发再重新执行一遍。

执行完没问题后，基本上就是达到我们上线的标准了，然后就让产品来去做一个上线验收。

然后产品验收了没问题就可以上到生产环境，当然上到生产环境的话，我们同样也会做一遍针对于本次迭代的功能，做一遍全量的一个测试，以及所发现的一些问题也要做一个回归测试。然后同时我们也会在这个监控平台上面做好一个实时跟踪。这个的话就是我们的一个测试流程。

测试最重要的是什么

第一个就是需求分析能力，自己的逻辑思维要明确，只有把业务给理清楚才能设计出跟多的测试场景，其次才会有用例覆盖度的保证，

然后的话就是bug分析能力，要对问题要足够的敏感，发现问题之后自己就能把这个bug找出来，分析出是前端还是后端的问题，这样的话就能提升工作效率，

还有就是对于一个时间的把控，在什么时候要做什么事情，分清事情的轻重缓急，自己要管理好时间，特别是自己独立负责一个项目的时候，

如果在测试过程中遇到一些问题，先自己解决实在解决不了再去汇报，

以及对于测试中的风险要提前预警，

那还有就是技能这一块，对于我们测试常用的工具要熟练使用，并且具备一定的编码能力，也对我们的团队测试技能储备有一定的帮助，可以通过代码的方式实现一些自动化，提升工作效率

还有就是自己要对一些新事物感兴趣，平时也要自己去自学提升自己，并且能够对项目产生一定的帮助.

项目人员划分

我们现在这个电商项目，测试3个，开发14个左右，我们项目中产品经理有2个分别负责后台和用户端、前端开发有4个、后端开发有10个、测试不算组长的话其实就我和另一个同事两个在负责整个项目的测试工作，组长有空的时候或者需求紧急的时候也会参与测试

用例:我在这个项目己经有差不多一年了，用例总数我没有看过，大概估算下六七千是有的

【用例要素】:用例编号、所属模块、用例标题、优先级、前置条件、操作步骤、测试数据、预期结果、实际结果

bug:1000+大概是用例的20%左右

我们电商项目有4套环境，分别是开花环境、测试环境、预发环境、生产环境，开发环境是开发调试代码改BUG用的，开发提测之后我们会在测试环境进行冒烟测试，通过之后才会全量的测试，然后再到预发环境测试，生产环境般我们不会要求进行测试的，但是如果有上线的话，会在生产环境进行一个持续跟踪的动作确保生产上线没问题

敏捷开发,周期,什么开发方式

我们之前的项目实际就是敏捷开发模式，迭代周期比较频繁，基本上就是两周左右会迭代一次，有的时候也会有一周迭代，然后发布窗口是周二一般发布的话我们都要安排人力进行值班，防止上线出现问题可以有人及时跟进

敏捷开发特点:

项目节奏比较快，提倡尽量少写文档

每天会开个站会，讲一下情况

自己的进度是怎么样的，遇到了什么困难，有没有什么需要协助或者帮助的，时间控制在10-15分钟，边上会有scrum master(斯鸽揉 麻斯特儿)提醒，来控制时间

保证测试质量

考察对质量保障的理解和手段，从几个维度思考:本职工作、工作流程优化、防御措施，回答好了很贴金

首先拿到需求之后我会仔细分析需求，去理解其中的业务逻辑，结合文档去设计测试用例。

设计测试用例时，我会尽可能全面地去考虑各种场景和条件。使用不同的设计用例的方法等价类、边界值等，正交试验，以确保测试覆盖所有可能的输入条件和相对应的预期结果:(根据我的经验，测试用例应特别考虑边界条件，例如输入的最大值、最小值、无效值等。

这些边界条件往往更容易出现错误或异常;同时除了对正常情况的测试，还应考虑异常处理和错误猜测。这包括对系统在遇到错误、异常或非正常情况时的反应进行测试。

我们公司会有用例评审的环节，开发和产品都会给我去补充或者提出一些建议，因为每个人的想法是不一致的，我要根据他们的想法来对我的用例进行增删改以及细化，我们总共是有两轮评审，一轮是组内一轮是负责本次需求的全部人员。

然后设计测试用例的时候还要考虑UI界面的展示问题，页面的样式、布局是否美观，有没有错别字，提示信息是否合理设计测试用例的时候还要考虑功能模块之间的交互，当前模块以及相关业务模块是否都正常，而不是只检查当前需求模块没问题就可以;

考虑系统的兼容性:系统或者app是否能在不同的浏览器、系统版本、手机、ipad、不同分辨率等各种终端上正常运行，功能都是没问题的;

• 我们测试最重要的工作内容就是编写用例和执行用例，那么肯定是要保证用例的覆盖率，一方面我们可以通过需求文档来编写用例，明确具体的测试范围，
• 可以对开发提出要求，根据编写的代码列出影响范围清单，我们可以根据这个清单去设计具体的场景用例将这些被影响的模块进行覆盖，这样很大程度上提高我们的用例覆盖率;
• 还有就是我们现在工作流程中开发没有自测的环节，我们会向开发提出要求让他们提测之前进行主流程的自测，这样其实也是在提高我们的测试质量
• 说--可以和自己的测试经理沟通或建议一下，做一个代码覆盖率检测的工具，每次测试环境测完之后，使用工具将本次新增代码扫一遍，如果存在没有覆盖的情况，我们可以针对性的设计一些测试场景将代码覆盖掉
• 还有就是可以加一些防御措施，比如加一些生产环境的监控，这样有异常信息能够直接监控捕获到，及时提醒相关人员进行排查，及时修复，降低问题的影响面以上就是我对质量提升的看法和建议
• 还有就是项目的整体质量不能只依赖于测试，如果企业所在的技术团队对质量真的比较看重的话，我认为可以组织一些质量相关的宣导会议，提升产研测所有同学的质量意识，比如说对产品来说需求文档的严谨与细节把控可以提高要求并日做到及时更新避免产生信息差，
• 这样也能让开发和测试同学以及未来的新同事对历史需求阅读过程中的理解有所提升，再比如开发这边对代码的规范性进行一定的约束，当然这个事情必须让架构师去牵头来做了，我的建议是可以让开发在代码层面做到注释清晰、日志清晰、高解耦、高拓展性等等，还有对数据库相关字段的备注信息和映射关系明确等，这些其实都是对项目整体质量会有提升的

测试用例的覆盖度是怎么保证的?

铺垫：保证需求理解

衔接词：这样就保证了我对需求是足够了解的，才能对用例覆盖度做好保证，那在保证用例覆盖度的时候

使用多种测试方法：等价类、边界值、正交法等来编写测试用例,

然后就是用例评审,也可以用代码覆盖工具或者ai 考虑一些特殊的点

【保证覆盖全】

首先拿到需求文档之后我会仔细分析需求，去理解其中的业务逻辑，结合文档去设计测试用例。设计测试用例时，我会尽可能全面地去考虑各种场景和条传。使用不同的设计用例的方法，如等价类、边界值等，正交试验，以确保测试覆盖所有可能的输入条件和相对应的预期结果:

(根据我的经验，测试用例应特别考虑边界条件，例如输入的最大值、最小值、无效值等。

这些边界条件往往更容易出现错误或异常:同时除了对正常情况的测试，还应考虑异常处理,包括对系统在遇到错误、异常或非正常情况时的反应进行测试。)

我们公司会有用例评审的环节，开发和产品都会给我去补充或者提出一些建议，因为每个人的想法是不一致的，我要根据他们的想法来对我的用例进行增删改以及细化，我们总共是有两轮评审，一轮是组内一轮是负责本次需求的全部人员。然后设计测试用例的时候还要考虑UI界面的展示问题，页面的样式、布局是否美观，有没有错别字，提示信息是否合理设计测试用例的时候还要考虑功能模块之间的交互，当前模块以及相关业务模块是否都正常，而不是只检査当前需求模块没问题就可以:

• 考虑系统的兼容性:

系统或者app是否能在不同的浏览器、系统版本、手机、ipad、不同分辨率等各种终端上正常运行，功能都是没问题的

我们测试最重要的工作内容就是编写用例和执行用例，那么肯定是要保证用例的覆盖率尽可能的高，如果只通过需求文档来编写用例，我们永远都会有想不到的场景被遗漏，那么这个时候我们就要明确具体的测试范围，

可以对开发提出要求，根据编写的代码列出影响范围清单，我们可以根据这个清单去设计具体的场景用例将这些被影响的模块进行覆盖，这样很大程度上提高我们的用例覆盖率;

【测试用例 优先级】

P0:核心主流程的正向用例(冒烟测试)，确定此版本是否可测的测试用例。

此部分测试用例如果不通过，其他测试用例就可以不用执行了需要打回去给开发重新提测。

P1:级别是主流程的反向用例,包含基本功能测试和重要的错误、边界测试。

P2:与主流程无关的其他次要功能的用例

P3:一些提示语或样式相关的用例

【测试用例组成】

用例编号、标题、模块、优先级、前置条件、测试步骤、测试数据、预期结果、实际结果、截图

什么样的用例是一条好的用例

1.用例名称具有明确的目标和针对性，能使别人容易理解是在哪个模块的用例

2.可读性和可维护性:测试用例应该编写清晰、简洁，具有良好的可读性，以便其他人员理解和维护。注释和清晰的描述可以提高测试用例的可维护性。

3.完整性和有效性:测试用例应尽可能覆盖各种边界情况、异常青况和可能的输入组合，以确保被测试对象在不同条件下的正确性和稳定性。

4.独立性:每个测试用例应该是独立的，不依赖于其他测试用例的执行结果或状态。这样可以方便测试用例的组织和管理，以及故障排查。

就是一条好的测试用例应该能够全面、准确地测试被测对象，发现问题，提高软件质量，并且易于理解和执行。

生产问题(线上的Bug)

• 生产BUG有遇到过，解决的话要看BUG的紧急程度，如果是比较紧急或者严重的BUG，首先采取紧急止血策略，一般会进行回滚到上一个版本，

然后去测试环境赶紧复现，让开发抓紧时间能修就修掉然后抓紧时间通过hotfix上线，如果是不太紧急或者不影响用户使用的BG，那可以建议产品放到下一次版本迭代优化掉，我们每次遇到生产BUG都会做一个详细的记录比如什么场景产生的，导致原因是什么，解决方案是什么等等信息，然后每个月会做一次汇总集中进行生产BUG复盘会，去分析可以通过什么办法来避免类似的情况发生，比如可能存在测试环境和生产环境的配置文件差异性上线的时候很容易忽略掉，那么就会要求每一次上线都会由需求owner对配置文件做一个check动作，这样就可以尽量避免问题的发生

【怎么做回归测试】

我们的回归测试在--测试环境和预发环境--都需要做的，

测试环境的回归一般是针对本次需求提出的BUG进行回归，预发环境除了要对本次的BUG进行回归之外，还需要对本次需求影响范围内的其他模块进行历史功能的回归，对历史功能的回归现在都是由自动化脚本直接进行，很大程度上节省了我们的测试时间

• 哪些用例做回归测试】我们在对需求进行用例编写的时候会有一个字段叫做优先级，优先级从高到底分别是P0级别核心主流程的正向用例，P1级别是主流程的反向用例，P2级别是与主流程无关的其他次要功能的用例，P3级别就是一些提示语或样式相关的用例，我们会将所有P0级别的用例追加到我们的回归用例库，然后有时间的话就会将这些新增的回归用例进行自动化的编写

工作量测试计划排期

• 工作量

一般我拿到需求，首先会梳理出测试点，然后进行评估，一般我们是有测试环境和预发环境要测试,斤以时间会分开评估，再加上我们编写用例的时间，就能够算出大概的工作量需要多少人天来完成，然后根据上线间和需求优先级来判断需要投入多少人力来完成

• 测试计划、排期

首先需求评审完之后，开发和测试都会各自去评估工作量，然后大家一起进行排期，开发要给“具体的提测时间，然后我们测试根据提测时间往后排，给出具体的测试环境时间节点和预发环境时间节点和参与、员，就能确定上线时间，我们一般周二周四发布的，所以会安排最近的发布时间做上线，如果是按照倒排期的方，产品先给出一个具体的上线时间，那么我们就按照评估出来的工作量，先把测试时间排上，然后就能推出开发须在某一个时间提测，然后再把用例编写时间和开发编码的时间往前推就能推出实际开始的时间

• 怎么进行排期

几周一迭代(两周) 10写用例需要2天

测试执行需要4天

回归 2天预发 2天会在上周周一或者上上周周五开始评审下一个版本的迭代需求

测试时间来不及

这种情况其实也比较常见的，比如需求变更啊、插入紧急需求啊或者开发延迟提测啊，就会导致我们来不及测试，首先可以重新做一下工作量评估和时间安排，如果加班加点搞不定的，我会找我的1eader反馈，看看能不能给我进行资源调配，找同事帮我一起测试，

那这个时候主要就看需求的优先级了，如果大家手里的需求优先级都比较高，无法空出时间来的，那我只能找产品沟通看看能否将需求进行延期，如果产品这边没办法进行延期的话，我会采取精益测试的策略，然后邀约产品和对应的开发进行会议沟通，评估功能点的优先级，对这个需求涉及到的功能，进行一个优先级的分层和评估，核心或者重要的功能先测，次要的功能就放到下一个迭代去做

• 【还没有开始，但是给的时间比较短】

测试尽量提前介入，提前开展工作，比如需求评审的阶段就参与进去，对需求理解透彻了，后续测试的效率也能提高，如果需求都不理解，测试的效率就比较低

2口 把测试用例提前写好，进行评审，大家一起查漏补缺，避免遗漏，还有就是提前准备好测试数据。要求开发自测，开发提测之前先进行自测，我们把冒烟测试的用例给他们自测

3 口 对于重复执行的回归测试，如果可以的话，使用技术手段做成自动化，提高测试效率

【有哪些上线风险】

上线风险还是很常见的，比如上次做的一个需求有出现偶现的BUG，类似这种我们不会在当前版本关闭也就是属于遗留BUG，这也属于一个风险项:再比如需求很紧急的情况，产品要求某个时间上线，但我们测试明显无法完成的，那我们会采取精益测试的策略，将核心功能测过，其他次要功能先不测了，直接上线，这也算一种风险:再比如有些功能模块因为测试环境和生产环境配置不同，在测试环境不具备测试条件的情况，也算是一种风险

【测试风险-项目-测试环境】

①需求不明确，我们之前是没有需求评审的，到了开发提测才发需求文档给我们，没有经过评审，可能测试产品开发对需求的理解不一致，会造成后期的一些问题，这是一个风险，不过现在我们已经增加了需求评审的环节，这个问题就可以避免了

②)偶现的BUG，类似这种我们不会在当前版本关闭也就是属于遗留BUG，这也属于一个风险项

③如需求很紧急的情况，产品要求某个时间上线，但我们测试明显无法完成的，跟产品协商经过同意之后，那我们会采取精益测试的策略，将核心功能测过，其他次要功能先不测了，直接上线，这也算一种风险;

④工作量时间安排不合理，这个也会造成风险，所以我们通常会采取一些措施来监督大家的执行情况，日报汇报自己的情况，以及每天的站会汇报执行情况，进度，看是否达到预期的进度如果没有达到，就及时的进行调整

测试报告怎么写-准入-准出

如果我是这个需求的ower(负责人)，在测完之后会去输出一份测试报告，

内容包括需求的背景情况--测试人员的情况--谁测试的，测试时间是哪天到哪天，以及用例的情况，设计了多少用例，每个模块的用例的分布情况，用例执行情况，

然后bug的情况，提了多少BUG，BUG的修复情况，bug的严重程度的分布情况，以及有没有遗留BUG遗留的原因，还有一些风险项都要在测试报告中体现出来，然后发给负责这个需求的同事

• 【准入标准】(提测标准) 开发提测之前我们会要求开发进行自测，我们会把冒烟测试的用例发给开发，这些冒烟用例就是从我们写的用例里面挑选的，优先级比较高的，

• 主流程的用例要求开发进行自测，他们提测邮件里面要带上自测的情况，自测的用例执行情况作为附件加进去要求冒烟测通过率达到80%才能提测的，达不到就会打回，因为主流程都不通，后续没办法进行测试
• 【准出标准】(上线标准)测试用例全部执行完毕，bug全部修复，如果有未修复的那是需要产品同意之后才能后续版本迭代的时候再修复的，
• 但是也不能是那种严重的bug，如果是严重的bug，也是强烈不建议上线的。然后还有就是需要产品验收通过，没有产品验收也是不能上线的，还有就是上线前要编写测试报告，说明测试的情况，没有什么问题才可以上线的!

效能提升-提高工作效率

实际上就是在想尽办法节省人力成本，就比如我们平时写的自动化就是效能提升的一种，除此之外还有一些其他的措施可以提升我们测试的效能，

比如:代码覆盖率检测工具，可以有效的检测出哪些代码已经被测到，哪些代码我们完全没触碰到，每次需求测完之后都可以检测一遍，如果存在未覆盖的代码，那么我们还可以重新去设计一些场景，将这些代码覆盖掉，通过这个工具大幅度提升了测试覆盖率;

• 再比如说每次上线之后我们需要人工进行跟踪上线情况也是在消耗人力，像这种情况，完全可以使用一些监控平台来代替人力每次有新增的功能或者接口，都可以添加到监控平台内，让系统去捕捉异常信息，如果存在异常就发出告警通过钉钉机器人或者企业微信机器人自动做跟进;
• 还有现在AI已经大面积应用起来了，我也有在使用一些AI产品比如豆包、deepseek，然后我平时也会用到这些大模型来协助的我工作，比如新需求我会让智能体来帮我先初步的提取测试功能点，以及梳理整个业务流程，这样我可以更清晰更快速的了解需求的目标，差不多这些吧

上线前的Bug

马上就要上线了，发现还有bug未修复

1.首先要跟领导上报风险，防止因为领导不知道情况，导致的后期线上问题

2.和开发一起加班加点进行修复，在开发修复完成之后，及时进行验证，确保bug在上线之前全部修复

3.如果还是有bug没有被修复，又是那种影响不大，不影响用户使用的小问题，可以产品同意之后放到后续版本进行修复;

4.如果是比较严重的问题没修复，我们是强烈不建议进行上线的，要跟产品说明如果带着这个问题上线造成的影响，最好进行一些延期，把问题解决掉再上线!

领导不同意

为什么没测出线上bug

1.首先要承认错误，确实没测出来，是自己的失误，同时说明线上问题发生的原因，是什么原因导致的，接下来会优先修复并补充相关测试用例，防止后续再发生类似的问题

2.同时也要表明自己的工作成果，自己从哪些方面进行了考虑，设计用例的时候，覆盖了哪些场景，表现出自己工作的尽职尽责，发现了哪些问题，已经发现了很多缺陷，而不是千何问题都没有测试出来

3.测试发现所有的bug，任何系统都不是完美的，但我们会持续复盘每一次不足，最大限度降低线上风险。

项目涉及哪些接口,哪些表??

订单表 order(奥德表)

订单状态 order status

0-待付款;1-待发货;2-待收货;3-已完成;4-已关闭

支付状态 pay status(赔斯德特斯)0-待支付;1-已支付;2-已退款;3-拒绝退款

字段

订单id、订单编号、用户id订单类型:0-普通订单;

1-秒杀订单:2-拼团订单:3-砍价订单来源:

1-小程序:2-H5;3-ios;4-安卓订单状态、支付状态、支付时间、收货人、收货地址配送方式、订单商品总价、订单商品数量、发货状态使用的积分、订单备注、用户优惠券id、拼团id、拼团活动id

分析需求的时候主要关注什么地方?

主要关注本次迭代是旧功能的优化还是新功能的增加

如果是旧功能的优化，主要关注优化之前是什么样子的，优化之后会变成什么样，

以及优化之后如果是新增了一些字段，要看下旧的数据要怎么维护。

新功能的增加的话，主要先把这个功能的逻辑搞清楚，

其次的话要着重考虑这个功能他会和哪些模块去做交互，验证的结果要做考虑，

以及这个操作是需要哪些条件的支撑。

优化需求

优化前,优化后新增功能

主要考虑业务逻辑，功能之间的交互,数据库表字段，进行数据校验

怎么去分析需求的 分析需求文档

拿到需求文档之后，自己先要看一下本次迭代的需求背景是什么，

是旧功能的迭代还是新功能的增加。

了解本次迭代功能的核心流程是什么样的，再将文档中不明确的地方都罗列出来，

或者说对于模糊的地方，自己做一个探索性的思考，站在用户的角度思考用户可能想要的结果是什么样的

然后我们会有一个需求评审会议，在会议上将自己不明确的或者探索性的想法，

提出来找产品来论证一下，看一下我的一个想法与产品和开发的对齐度,如果存在一些

对需求点或者文档上理解的偏差,应及时做沟通,保证较高的理解对齐度,

就是我在上一家公司，析需求的过程

5. 平时怎么和开发沟通的

工作中与开发的沟通是最多的，也避免不了会有意见不一致的时候，最常见的就是在我提了bug的时候开发不认为是一个bug。

出现这种情况的话首先我要看一下我自己提交的bug是不是一个有效的bug，

就要去和开发沟通是因为什么原因不解决，是因为产品需求的理解不一致还是因为开发工作比较忙，如果是理解不一致的话我们两个会把自己的观点给描述出来，围绕需求做一个探讨，看一下最终的意见能否保持一致，

如果实在是观点不一致的话我才回去找产品，让产品去做定夺，如果产品认为这是一个问题，那开发修复就可以我这边去做验证，如果不是问题，那我就把这个bug关闭就可以，如果是开发工作时间比较紧张，那我会根据这个bug的严重程度来和他协商修复的时间让他给出一个最终的时间，

平时是怎么沟通的

对于测试来说在整个流程中都是需要和上下游的人员进行沟通的，

需求评审：需要和产品去沟通需求的内容，如果需求不明确或者逻辑不合理的地方，就需要拿出自己的观点和产品进行讨论

用例评审：测试、开发、项目经理等同事针对我写的用例进行审查，给我提出一些意见

提bug、bug评审：开发对于不认可我提的bug，需要和开发、甚至会和产品来拉个会议来进行定夺，到底是不是个bug

我觉得对于我们测试来说最重要的就是沟通能力，在把控测试质量的同时都是需要与测试过程中每个节点的负责人员进行交流，主要是开发以及产品、甚至说一些跨部门的人员也是需要我们去推进整个流程，不能让测试发生阻塞，如果是多次需要那边来配合我们，那我就会去把那一块的业务逻辑熟悉一下，后面就方便我自己操作，不用别的部门同事来配合我，最重要的就是不能耽误上线的时间。

7.测试环境有哪些?

四套环境首先第一个就是开发、测试、预发，还有生产般都是两个服务器的，开发和测试环境都是独立的服务器的。

但是你们用的数据库可能是一个数据库。

8.预发和生产环境的区别

其实就是预发的用户，还是我们自己测试的用户，测试账号

其实真正的一个区别其实也没什么区别，预发就是模拟生产环境的，

只不过那个里面的这个测试账号，我们用的还是测试组测试的账号，这里面的一些账号还是用的是测试账号。那生产的话就是我们会专门去新建一个账号

9.什么是冒烟测试呢?

冒烟测试就是开发提测之后，我得先跑一下本次需求的一个核心主流程有没有问题

10.那常见的测试用例方法有哪些呢？

等价类、边界值、正交，因果、判定，

等价类的话就无非就是我们的一个正向的操作和异常的操作。比如说我现在的这个账号密码登录，我如果输入正确的密码的话，这就是正向操作。我如果输入错误的密码的话，这就是什么异常操作。

边界值的话就是我们要考虑一个长度的边界。这就是我测它的一个边界。

正交一般是用来组合测试的。比如说我有多个下拉选项的话，那这个时候我就需要用到一个正交了。我会通过每一个选项的优先级来去进行一个测试；

涉及到多个下拉选项的时候，为了提高这个测试效率，通过最多下拉选最多枚举值来去做一个组合测试。

那这五个都得测，那我是不是跟后面的是不是都得去组合一遍，那跟后面去组合的时候怎么组合呢,先用优先级比较高的选项来去组合的。

比如说我们有定我们后台有一个搜索的功能，可以通过订单搜索、订单类型、配送方式、订单来源这些条件来组合的。那我就可以在里面去找到哪一个下拉选项是最多的。我就设计多少条用例，根据每一个选项的权重来设计就可以了

因果；

比如说我必须要选择一个商品放入到购物车，我那个结算的金额是不是才会出来，不然是不是就是零，是不是那我做的这个动作，我必须要做了这个动作才能看到这个东西，是不是才能去验证到我这个才能去验证到我这个结算的功能

3. 项目风险是怎么把控的?

在平常测试过程中,做好记录及汇报,让我们的项目进度一直处于可控状态

如果说上线前突然出现一个严重的bug,赶紧汇报，提bug，抓紧定位,抓紧修复,如果修复需要很多时间，可能就需要看看上线时间能不能推迟了，或者砍掉这个需求上线，主要还是看产品怎么决策了。

不严重的问题那我们可以在上线后采取一个热修复的方式。不过尽量还是在测试期间把用例优先级安排好，看看为什么这么严重的bug在上线前才测出，是不是测试安排不合理。

如果说是突然来了一个紧急需求,但就要把手上的工作排一下优先级,看看怎么安排更合理,需求大时间急的话可以先测核心功能,次要功能可以先不测,不过这是下下策了,先保证大部分功能没问题可以上线。需求小不复杂可以申请人手加班来完成。

如果是因为需求频繁变更导致的风险，可能是需求分析环节出现了问题，所以需求分析的时候就要跟产品和开发做好沟通，避免这种风险。

如果是因为客户老更改需求，那就要跟客户说清楚更改之后需要更多时间，再做一个考量。

13 Bug怎么提交的;什么样的Bug好Bug,

一个好的bug要包含前置条件，标题，操作步骤，实际结果，预期结果，

bug的严重程度，提出人，bug状态。

前置条件指的是比如我注册了什么账号，或者开启了什么功能，必须处于这种条件下才会产生bug。

标题最好写的简短又明了，操作步骤写的清楚又详细，让开发一看就知道是什么

模块出现的什么问题，怎么操作才能复现，避免反复确认，提高工作效率。

做好Bug严重程度的管理,Bug的严重程度是为了提醒开发可以优先关注这个bug

14. bug是怎么划分的?

p0->致命缺陷，导致程序崩溃，这个软件已经不能使用了，或者涉及到金钱

p1->严重的，冒烟流程没有通过，如果冒烟流程影响程度比较大会上升严重程度

p2 ->除了冒烟之外的功能

p3 ->一些界面展示、排版、错别字问题

上线后Bug的处理:

严重的：版本回滚-> 开发修复 -> 明确时间 -> bug验证 -> 影响性回归 -> 上线跟踪 -> 复盘会议

不严重：找产品去评估/ 热修复

15.前后端怎么去定位

【定位】通过F12或抓包工具来看接口的请求和响应(前)如果是请求错误，就是前端BUG比如请求参数/请求路径/请求方式这些错误。如果请求正确,接口响应也正确,界面显示错误也是前端问题。

(后)如果请求没问题，但是响应信息错误就是后端BUG;同时我们也会结合数据库进行一下数据的查询，进行问题分析还有就是使用1inux命令查询日志，去协助排除问题tail-fgrep"关键字”;

但是如果是涉及到流程类的接口，会结合上下游的接口进行定位，很可能是上游接口的问题导致当前接口的请求或响应有问题，具体问题要具体分析

前后端问题【具体例子】1.输入了正确的账号、密码之后，点击登录，页面没有反应，怎么来定位前后端问题

F12/抓包来分析,如果登录接口的账号、密码参数与我页面填写的不致，就是前端问题发请求出错了

如果登录接口请求都是对的,响应也是正确的，返回了用户相关的信息但是页面没有反应，那还是前端的问题，没有进行正确的跳转处理如果登录接口的请求参数都没问题，但是返回的信息不对，后端就有问题，同时前端也是有问题的，没有给出合理的提示

16. 如果开发不认可你提的BUG，你会怎么去沟通?

实际上这种情况是很常见的，那么我首先会确保 我和开发的需求文档内容是一致的，

其次我会当着开发的面演示-遍BUG的复现过程，如果开发还是不认可，那我会通过钉钉预约一个会议室邀请对应的产品和开发一起,我们针对这个功能点重新再讨论一下

尽量避免因为各自有理解上的偏差而产生的歧义，如果产品要求严格按照需求来做，那就让开发继续去改代码，

如果产品觉得开发现在的实现逻辑也ok的话，那我会向产品提出去将需求文档按当前沟通方案去实现,修改完整.

17. 产品和开发意见不一致?

导致的结果

1.进度开展不下去

2.写好的测试用例可能也是无效的

2.影响上线交付

怎么去做:

搞清楚:

1.需求理解不一致

2.技术难实现

砍掉

平替

总结:沟通协调，测试相当于就是产品和开发之间的梁桥，保证产品正常交付给用户

他们意见不一致就是让工作暂停，任务进行不下去，导致的是我测试时间的挤压，在这个时候我要听取一下开发好观点是什么，是因为需求理解不一致还好技术上实现比较复杂，如果是技术上的问题的话，那就找开发的老大一起开个会做个技术讨论看一下能不能实现，如果不能实现就砍掉这个需求就可以，或者换一个平替的需求，需求理解不一致的话，把两个人的观点都听取一下，并目我也要站在用户的角度去思考一下这个需求给用户带来的操作是什么样的，中和一个他们的观点，并且我也要发表我自己的想法，看一下谁的想法更加合理就采纳谁的，最终我们肯定是以用户为目的来实现这个需求，最终讨论确定下来，对于我们测试来说遇到这种情况就需要在中间协商，给出一个最终的需求方案，让我们的工作能够正常进行下去。

18. 陌生的项目怎么上手

先了解项目的背景和需求，掌握基本业务概念、流程和规则与项目团队成员，包括开发人员、产品经理、等进行沟通，进一步明确需求细节，了解项目的目标、重点和获取他们对项目的理解和期望.

熟悉系统的整体架构设计和模块划分，以便确定测试的重点和策略

查看接口文档，了解系统对外提供的接口和内部各模块之间的接口，包括按口的参数、请求方式、应格式等，同时题悉项目所涉及的数据结构、数据流向和数据处理方式。

根据项目特点和需求，选择合适的测试策略，如黑盒测试、白盒测试、自动化测试等e.

依据需求文档和测试策路，编写详细的测试用例。

用例要素有哪些?什么样的用例是一条好的用例？

模块:让我们知道这条用例是测试哪一个地方的

标题:简洁明了，一眼就能看懂这条用例主要是测试什么的

优先级:进行优先级划分，可以在时间紧张的时候进行优先级排列测试

前置条件:在执行操作的时候，需要满足什么条件才能去做

操作步骤:要足够的详细，可能用例写的多了就忘记这个动作是怎么操作了

预期结果:做完这个动作之后，想要展示成什么样或者要有什么效果，可以是每一步的结果，也可以是最终的结果

实际结果

怎么回归测试?

我们的回归测试在测试环境和预发环境都是需要做的，

测试环境的回归一般是针对本次需求提出的BUG进行回归;

预发环境除了要对本次的BUG进行回归之外，

还需要对本次需求影响范围内的其他模块进行历史功能的回归，

对历史功能的回归现在都是由自动化脚本直接进行，很大程度上节省了我们的测试时间，差不多这些

23.web端和app的区别.

web端和app端在功能上其实是差不多的,web端是在浏览器页面上操作的,app端是下载一个客户端操作的;

首先从功能层面来说，其实web端的测试和移动端app的测试是一样的，区别在于web端的兼容性要考虑不同浏览器、以及 浏览器的不同版本浏览器的不同尺寸 去验证界面的适配性，

而APP的兼容性要考虑的是不同品牌的手机、不同的手机型号、不同的操作系统、系统内不同的版本和不同屏幕尺寸大小，然后web端的性能测试要考虑服务器相关的参数，

比如说CPU占用率，内存损耗等，

而APP除了这些之外，性能方面还要考虑流量损耗、电量损耗等因素，APP还有一些专项测试，比如安装卸载更新、弱网测试等等，这些是web端没有的

web测试和app测试的区别？

App测试它测的是C/S架构，web测试它测的是B/S架构，

首先是功能测试，app和web其实是有相似点的。它最基本的逻辑都是基于我们业务需求的，根据需求文档来测，我们编写一个功能的测试用例，一条一条的去测试，包括一些单功能，交互功能，还有一些用户的功能场景。

然后是兼容性测试，对于web 端来说，兼容性测试就是，浏览器的一个兼容性，比如我们的常用的，像火狐，谷歌，还有edge。我们要测它在浏览器中的界面，放大的百分比，缩小的百分比，看它能不能在我们系统中正常显示。这个是我们 web 端的兼容性测试。

还有就是APP 它的兼容性，主要是针对我们手机版本，比如像iOS苹果和安卓， 鸿蒙。还有它的一个屏幕分辨率，不同机型的屏幕，像水滴屏，曲面屏折叠屏，不同大小，看他能不能正常显示，这个是APP 的兼容性测试。

安全方面，像我们web 端和APP，都会去测一些，比如像 SQL(恶意语句) 注入，XSS 攻击，这种的。APP 还有一个比较特殊的点，当我们第一次安装的时候，它会有权限设置，包括一些定位的权限，网络的权限，还有首次登录一个APP隐私的权限等等，我们也需要去测的。

然后就是网络测试。网络测试我们需要去测，不同网络下APP 的功能表现，比如像2G、3G、4G、 5G 网络，手机热点、Wifi，还会模拟弱网，去模拟一些网络切换的场景，做一些异常测试。

一个中断测试，比如你在使用APP 的时候，来电的一个中断，手机短信的一个中断，包括其他 APP 的中断，比如你在听音乐来电话了，你在看视频打游戏来电话了。这个是我们 APP 特有的， web 端是没有这方面测试的。

还有一个安装卸载升级的测试，也是APP 特有的，需要去测它的 APK 包的安装，包括原始的安装，覆盖安装和卸载。那么升级的话，我们会测一个。比如邻版本的升级和跨版本的升级，这都是要去测的。

X性能APP还有它的一个启动，我们需要去测它的一个冷启动和热启动，这是关于性能方面的一个测试，web 端是没有的。那关于性能方面，web 端测的是服务器的性能，APP 测的是对手机性能的影响，

包括对手机的资源消耗，流量消耗，耗电量。除此之外，APP 还有一些特殊的测试点，web 端也是没有的。比如像手势操作，单击、双击、滑动，切换后台，包括一些横屏、竖屏，长按缩放这些特殊操作，web 端是没有的。

开放性问题

提测质量不高怎么办?

说明我和开发之间缺乏了沟通，对于需求的理解可能不一致，导致了我写的用例是无效的用例，开发出来的功能和我想的预期结果不一致，导致测试时间挤压，甚至会导致延期交付.

解决方式：需求评审完一定要和开发进行交流，要去看一下开发的实现思路是什么样的，

以及对于本次需求来说，我要着重关注什么地方，最终要的就是我和开发的思路对齐，

即使提测之后出现什么问题也不是大问题。

6. 怎么快速了解和掌握系统?

如果我刚进入公司的话，第一件事情就是找同事要一些项目相关的资源，比如各个环境的链接和账号、历史需求文档、接口文档、

服务器地址、数据库地址、历史用例库、测试管理工县地址，

那么拿到以上资源之后，我可以快速的掌握项目的一些核心流程和操作步骤，观察数据库结构可以了解到项目整体会生成哪些数据再通过发布平台可以大概知道项目整体的一个应用分布分别涉及哪些功能模块，

通过历史用例和历史BUG来了解以往测试人员的一个工作风格尽量保持一致，以上这些大概两三天就可以快速掌握，然后就可以找leader要一下最新的需求迭代内容，开始上手参与测试工作了

7. 测试时间来不及怎么办?

核心:

如果是突然加了一个需求、任务量比较大先要把手上的工作进行优先级排列一下，哪些任务是比较重要的，先把这些重要的任务给做了,

或者是上线前来了一个紧急需求?

优先级如果不是太高了，可以放到下一个版本在选代,汇报风险

●如果逻辑复杂优先级较高，短时间内保证不了覆盖度，甚⾄加班也保证不了，就向领导及时汇报，说明情况，申请加派⼈⼿等。如果逻辑不太复杂，可以加班去保证覆盖度。

8. 怎么提升工作效率?

提升测试用例覆盖度

对于每次回归的内容采取自动化：接口、Ui

比如我们平时写的自动化就是效能提升的一种，除此之外还有一些其他的措施可以提升我们测试的效能，比如:代码覆盖率检测工具，可以有效的检测出哪些代码已经被测到，哪些代码我们完全没触碰到，每次需求测完之后都可以检测一遍，如果存在未覆盖的代码，那么我们还可以重新去设计一些场景，将这些代码覆盖掉，通过这个工具大幅度提升了测试覆盖率;再比如说每次上线之后我们需要人工进行跟踪上线情况也是在消耗人力，像这种情况，完全可以使用一些监控平台来代替人力，每次有新增的功能或者接口，都可以添加到监控平台内，让系统去捕捉异常信息，如果存在异常就发出告警通过钉钉机器人或者企业微信机器人、发送邮件，;我觉得我们要学会运用一些工具，现在AI已经大面积应用起来了，我也有在使用一些AI产品比如豆包、deepseek，然后我平时也会用到这些大模型来协助的我工作，比如新需求我会让智能体来帮我先初步的提取测试功能点，以及梳理整个业务流程，这样我可以更清晰更快速的了解需求的目标差不多这些吧

9. 测试计划是怎么写的?

在需求评审完之后，我们就会定任务的排期，采取两种排期的方式，正排期、倒排期

我们使用倒排期

倒排期:给出上线的时间点，然后我们往前反推预发、回归、测试的时间，最后给出提测的时间.

正排期:开发和测试会对于本次需求进行评估，首先要和开发确认提测的时间，测试还要排出写用例需要多长时间，

执行需要多长时间，回归要多长时间，预发要多长时间，最后确定上线的时间。

10. 测试报告

辅助领导写过用例覆盖度百分百多少测试用例多少bug bug严重程度 修复了多少 最后总结

测试报告的话，主要是分为三个维度的，就是从需求,用例,再到bug。需求的话，会列出我们本次迭代做了哪些需求，总共写了多少条用例，发现了多少个bug。用例的话，包括我们的用例的通过率，多少条用例是通过的，多少条用例是没有通过的，我们要求用例的通过率是要达到99%以上的。

bug的话，我们主要做了一个bug的分布图，对于不同严重程度的bug分别进行一个罗列。就比如说致命的，严重的，次要的。

还有遗留的bug，对于这些没有修复的bug，看一下它的严重程度以及什么时候提交的开发，还有就是对于本次测试人力产出，哪些人参与了本次迭代，计划工时是多少，实际分别用了多少工时，然后如果有风险的话，我们会在上面去做一个风险标注。

11.线上问题怎么发现

上线了之后，我们会用到Grafana这个监控平台来做一个线上的监控，

在上线之后开发和运维查看日志，有异常会先去评估它是不是一个bug:

或者说我们会建个群，里面包含产品，开发，运维，用户以及我们测试，通过用户的反馈去发现问题。

12.如果测试环境不稳定或者无法使用，但你这个模块今天又必须要测完你怎么办

a,看一下可不可建立一个备用环境，或者说公司里有备用的测试环境，就先去在备用的环境里进行测试。

b及时去和团队去商量，去找一下测试环境不稳定或者无法使用的一个方案;

c,先去抓紧时间测试优先级比较高的用例，确保在对应的时间内获得最大的用例覆盖度。

d借用开发的环境、或者用户的环境，在用户不使用的时间段进行测试，

11.测试最重要的是什么?/什么样的测试是一名好的测试

第一个就是需求的分析能力，自己的逻辑思维要明确，只有把业务给理清楚才能设计出更多的场景，

其次才会有用例覆盖度的保证，然后要对问题要足够的敏感，

发现问题之后自己就能把这个bug给出来是前端的问题还是后端的问题，这样的话就是提升一个工作效率，

还有就是对于一个时间的把控，在什么时候要做什么事情，自己要管理好时间，特别是自己独立负责一个项目的时候，

如果在测试过程中遇到一些问题，先自己解决实在解决不了再去进行汇报，以及对于测试中的风险要提前预警，

那还有就是技能这一块，对于我们测试常用的工具要熟练的去使用，最好具备一定的编码能力，

可以通过代码的方式实现一些自动化，提升工作效率，

还有就是自己要对一些新事物感兴趣吧，平时也要自己去自学提升自己，并且能够对项目产生一定的好处。

给你一包纸你会从哪些方面进行测试?

功能、兼容、安装卸载、网络、中断、权限、性能

首先从功能上来说的话，这个纸它能正常抽出来，并且抽的时候他不会连带其他的纸出来，你抽的是一张，他肯定不会你抽一张出来很多张，你这包纸拿出来了之后，就是这种它的厚度是什么样子的，它是几层纸。以及这张纸的一个这种耐用性，把这张纸撑开了，上面可以放多少重的一个东西。

还有就是这包纸它可以去擦是什么样的一个内擦拭一个什么样的东西，它可以擦水?可以擦灰，它可以去擦任何的一些东西，你以及你要看它的人擦完的效果是什么样子?它的吸水程度是什么样的那以及我这包纸是不是可以放在不同的容器里面，可以放在不同的那种盒子里面。还有就是我这包纸我拿开之后，我通过什么样的力度我就能把这包纸给扯断。还有就是这包纸我放在水里面了，它的这个溶解的速度是什么样的?以及我这包纸我在持续往出抽的时候，我那个塑料袋会不会开了，就是上面的开口会不会直接撕开的这种是不是会不会因为我的速度比较快了，他这个纸的质量不是很好。以及我这包纸其实也就这些了，我能想到也就这些，也没什么东西了

电动牙刷怎么测的?

可以从功能、安全、性能和外现几个方面去展开测试。

首先，功能层面，测量电动牙刷的振动频率是否符合设计安求，广动频率每分钟几干次到万次之间，然后，电动牙用工作时的噪音水平，确保在合理范围内，不能影构用户体验感。

还要确保电动牙体在使用过程中不会因进水而导致故障，测试他的一个防水性，还就就是同型号的牙刷的引头和主体之间是可以互换的，拼接使用过程是稳定的。然后就是观试电动牙成的开关、模式切换等功能是否正常且方便实用。

并且电动牙刚对牙齿表面污演的清除效果也会做多险去澳时。

其次，安全层面，确保电动牙刷在正常使用中不会造成漏电等安全隐，我们可以测试他的绝缘性。

然后，看一下电动牙制在充电过载情况下是杏有足够的保护机制，充电过程中会不会过热爆炸，保证电池从空到满电会充满停止，不司的电压下充电是否稳定、安全，

然后，性能层面，测试电动牙刷在长时间使用后的旅动性能是否稳定，如果长时间连续使用，电动牙刷的使用寿命足多久。电动牙刷从空电到充满电所需的时间。开关、模式切换按键按下到切换成功所用的时间。

最后，外观上，电动牙刷的材料对人体无害，牙刷各部件是否含有有害物质，如重金震、塑化剂等。电动牙的手感、坦持舒适度等符合人体力学，用户体验良好，牙別的开关和各模式的文字标汗清晰，大小，色搭配合理。

接口测试

1. 接口测试怎么做

如果要测接口的话，首先我会找开发去要一个接口文档，通过这个接口文档对接口进行用例的设计，

比如说接口的请求头、请求方式、请求体都需要根据接口文档来设计，包括请求体内的各个参数字段是否必填、数据类型、和字段的规则，

可以像功能一样通过等价类边界值的方式来进行用例的编写，敏感字段还需要考虑一些安全性方面的，比如密码字段，通过调用接口，密码是否以加密形式展示，

除此之外还需要对这个接口所涉及的场景，进行正向和反向的用例设计，有些接口基于业务需要也会考虑一些幂等性测试

比如通过jmeter的同步定时器对一个接口同时触发多次，看看是不是只有一次通过其他的都正常拦截，

那如果没有接口文档的话，我就会通过抓包的方式先去分析接口内的各个参数，然后再去进行用例的编写，编写的时候会加上数据库的校验，并且对业务code码和massage文本信息进行断言

2. 接口的用例设计

根据参数进行正向 以及异常的操作，比如说参数的边界值，或者说这个填错、不填，多填一个参数，少填一个参数

（前端开发在传参的时候可能会出现错误，所以需要我们去测试），

比如说，我们有一个查看用户明细的接口，总共有两个参数，一个是source，一个是type，source是用来查看余额、积分、成长值明细的，

type可以规定是增加还是减少，那我们就可以通过正交的方式进行一个组合测试，比如余额增加、余额减少。

3. 接口工具的使用

我们接口测试是用jmeter来去做的，’主要就是线程组内的配置

以及还需要对接口进行断言，响应状态码以及响应体内容。

4. 为什么做接口测试

前端还未开发好，测试后端，看看功能是否实现联通，

前后端联调的时候我这边基本上已经排除后端的问题了，可集中时间测试前端。

5. jmeter怎么用的?

新增线程组，添加HTTP信息头管理器，填入authorization、content-type、token（看情况），再添加HTTP默认值，

将请求的公共内容填入进去，比如协议、IP、端口、编码方式，

再添加HTTP请求，将我们的请求方式、请求url地址、请求参数填入进去。多接口需要上下游传参的，可以通过json提取器进行提取，在json提取器中设置一个变量名，写一个json表达式进行响应体提取，下游接口就可以直接引用了，通过${变量名}进行引用,最后也是需要对接口进行断言，断言响应状态码以及响应体断言。

察看结果树

6. 接口怎么做断言的?

断言响应状态码、以及响应体 的值，会获取一些关键的数值进行校验，一般断言2-3个，比如通过状态200，“获取成功”，也会进行一些数据库的断言，

7. 接口怎么连接数据库的

我是通过JDBC connection这个元件进行与数据库的连接，

通过JDBC request这个元件执行sql语句，进行数据库的结果验证。

8. jmeter怎么进行 跨线程组 传参

在请求下面新增一个beanshell断言，在这个元件里面写入调用现成的setproperty这个方法，

将提取出来的内容设置为全局属性

下一个线程组再去使用的时候通过property这个方法进行使用，传入我们设置好的属性名称就可以。

9. 常见的性能指标

99线，99%的请求没有超过这个响应时间

95线，90线，

吞吐量：表示系统在单位时间内能够处理的请求数量。通常表示为“每秒处理的请求数”（Requests per Second，RPS）或 “每分钟处理的请求数”（Requests per Minute，RPM）。它反映了在特定时间段内，系统能够成功处理的事务数量。

平均响应时间

错误率：报错接口占总接口数量的百分比

CPU利用率

响应时间：从用户发起请求到系统返回结果的时间间隔

吞吐量：系统在单位时间内处理的事务数量

并发用户数：系统能够同时支持的用户数量

资源利用率：表示软件对系统资源（如CPU、内存等）的占用情况

99线（P99/TP99） 99%的请求响应时间不超过该值，反映系统在高负载下的性能稳定性，如果有99%的请求响应时间不超过某个时间阈值，那么这个时间阈值就是99线。

CPU利用率 衡量CPU在单位时间内被占用的程度，通常以百分比表示 内存利用率 表示内存被占用的比例，反映系统对内存的使用情况

8.

10. 响应状态码有哪些?

200 通过,但结果不一定正确

301 永久重定向

302 临时重定向

400 请求体错误

401 未经授权

403 被禁止访问

404 not found url地址错误

405 请求方法出错

500 服务器错误

502 网关错误

503 无法处理客户请求

504 请求超时

11. http和https的区别

http 不够安全，端口号是80

https比http多了ssl安全协议，需要购买ca证书，端口号443

12. cookie\session\token有什么区别？

cookie:保存在用户端本地，不安全，没有时效

session:保存在服务器，更安全，有时效，session过多会对服务器产生性能压力，需要通过脚本定时清理

Token：登录之后下发的一个token值

13. 参数化的方式有几种?

CSV文件、用户自定义变量、函数小助手Random

14. jmeter是怎么进行上下游传参的?

在json提取器中写一个变量名进行接收提取出来的值，然后再写一个json表达式进行响应体提取，下游接口就可以直接引用了，通过${变量名}进行引用,最后也是需要对接口进行断言，断言响应状态码以及响应体断言。

15. 性能测试是怎么做的?

什么是负载测试：不断的增加用户量，以梯度形式上升，直到出现性能拐点，这个就是系统最大承受的用户量。到了多少用户量的时候系统开始崩溃。

什么是压力测试：长时间在一定用户量上进行测试，持续15-20分钟。通过模拟高并发、高负载的场景，测试系统的极限容量和稳定性，帮助发现潜在的性能瓶颈和故障点。

什么是并发测试：同一时间开始大量用户开始发送请求：抢购秒杀的时候的场景，同步定时器来做。

80%的业务量在20%的时间内完成。

我们这边进行性能测试的时候，产品会给我们一个工单，产品开发已经商量好了要对哪些接口进行性能测试，指标也已经确定好了，他会把这个工单通过邮件的方式发送我们，我们去执行就可以了。当然这个具体的性能测试的脚本还是需要我们去写的。一般我们就是会对用户使用比较频繁的功能来做接口压测,具体是哪些接口就是产品已经确定好了，

我们会使用 jmeter模拟客户的使用情况来进行性能测试脚本的编写，主要就是线程的设置，

然后在准备测试数据的时候，会用到CSV进行参数化，保证测试数据的多样性，来模拟用户真实的一个业务操作，“然后会使用 jmeter里面的聚合报告和查看结果树进行分析，一般主要关注接口错误率，响应时间、吞吐量，99线，95线这些性能指标，服务器的资源指标，比如CPU使用率和内存使用率我们会进行关注，一般不要超过70%，压测的过程中我们不断增加用户数，随着用户数的增加，各项性能指标也会相应产生变化，当出现了性能拐点，比如，当用户数达到某个数量级时，响应时间突然增长，或者吞吐量突然降低，那么这个拐点处对应的用户数就是系统能承载的最大用户数.

并发怎么测的?

就Jmeter设置线程数，用一个同步定时器，用同步定时器，这个回不了，回答不了太长时间的并发怎么测的，就是什么呢?

jmeter设置一下线程数，用通过这个同步定时器来设置一个数量，我们同一时间请求的数量是多少，然后的话就去发送请求就可以，我们要并发的请求是哪一个，在这个请求下面添加一个同步定时器就可以了,他是要就是要看你测的接口是哪一个，在这个接口下面添加一个同步定时器，设置一下你们并发的人数就可以了。

进行性能测试的时候，产品会给我们一个工单，产品开发已经商量好了要对哪些接口进行性能测试，指标数据也已经确定好了，他会把这个工单通过邮件的方式发送我们，我们去执行就可以了，一般我们就是会对用户使用比较频繁的功能来做接口压测，具体是哪些接口就是产品已经确定好了，我们会使用jmeter模拟客户的使用情况来进行性能测试脚 写，主要就导线程的设置，然后在准备测试数据的时候，会用到CSV进行参数化，保证测试数据的多样性，来拟真实用户的一个业务操作，然后使用jmeter里面的聚合报告和查看结果例进行分析，

一般主要关注接口错误率，响应时间、吞吐量，99线，95线这些性能指标，服务器的资源指标，比如CPU使用率和内存使用率我们会进行关注，一般不要超过60%。

16性能测试出现过什么问题?是怎么解决的?

我们去购买商品。

很多个人在去购买这个商品的时候，一个人买一个,比如说他有五个库存，但是我有十个人买，它会出现一个超卖，它出现了一个超卖的情况，我只有五个库存，但是他卖出去了七个是吧,这个就是超卖.

这就是我在jmter里面通过这个同步定时器来设置这个设置我们同时请求人数的时候突然发现的我们这个库存出现了一个超卖的情况。

Fiddler抓包

1. fiddler的原理？

描述发送接口请求到响应的过程

偷窥请求和响应以及可以进行篡改

Fiddler 的工作原理有点像“中间人”,在本地终端和服务器之间，终端发送的请求（比如打开网页、发送消息等）都会先经过 Fiddler，然后再发到服务器；同样，从服务器返回的响应也会先经过 Fiddler，最后再返回到终端。

Fiddler 收到这些请求后，就可以对它们进行拦截和处理。

网络通信是基于HTTP或HTTPS 协议的。这些协议规定了数据的格式和传输方式。

Fiddler 利用这些协议规则，把数据包解码，我们能看到里面的内容，它可以查看请求的详细信息，如请求的网址、请求方法（GET、POST 等）、请求头中的信息（如用户代理、Cookie 等）和请求体中的数据（如果有）。并且，Fiddler 还能

根据需求对这些请求进行修改，比如修改请求参数、添加或删除请求头信息等，然后再将修改后的请求发送到目标服务器，从而实现对网络请求的拦截和处理。

建立代理服务器：Fiddler 运行时会在本地电脑上创建一个代理服务器。代理服务器就像是一个中间桥梁，介于浏览器或其他应用程序与目标服务器之间。

请求转发：当浏览器或其他应用程序要访问网络，比如访问某个网站时，原本应该直接发送给目标服务器（如网站的服务器）的请求，现在会先被发送到Fiddler 设置的代理服务器上。

2. fiddler怎么去抓app的包？

1. 安装证书2.配置代理 3.同一wifi下

首先运行Fiddler 的电脑和需要抓包的移动设备连接到同一个wifi,保证它们在同一个网段内，才能够相互通信

然后需要在手机端安装证书在Fiddler可以自动生成一个用于解密 HTTPS 协议的证书,

同时会有下载证书的网址,复制网址在手机端浏览器打开网址就可以直接安装fiddler工具生成的一个数字证书.

还需要在手机端进行代理配置,输入电脑的 IP 地址和 Fiddler 端口号8888。这样设置后，移动设备上的App 在进行网络通信时，所有的请求都会先发送到 Fiddler 所在的代理服务器,就可以抓到app的包了.

3. fiddler能做什么事情？

1.前后端bug定位，可以抓app的也可以抓web端

2.篡改请求和篡改响应

3.mock挡板,用在第三方

开发调试：程序员可以用它来调试网页应用，看看请求和响应是否正确。

性能分析：可以查看请求的大小、响应时间等，帮助优化网络性能。

安全测试：可以查看加密数据（比如HTTPS），帮助发现安全漏洞。

4. 断点是用在什么地方的？

对于一些页面上的排版进行验证就可以通过断点的方式来去验证，或者说前后端一起进行条件限制，

可以将请求拦截下来，然后对后端进行验证

列举案例

比如说我们前台用户个人中心可以查看自己的余额积分还有优惠券，

在这一栏有三个选项分别展示对应的数字，就可以通过fiddler打断点的方式，来去查看这一栏其中一项数字超长或者这三个选项都超长.

关注一下ui的排版又没有bug。

还有就是在注册的时候，账号密码输入框前后端会一起进行条件限制，

比如说格式以及长度，验证完前端之后还需要验证后端对于这些异常的格式和长度有没有去做校验，

就可以通过大断点拦截下来进行修改为异常请求进行验证后端响应。

断点就是中途拦截请求/响应，手动改数据来测试：

前端：改返回值看页面会不会崩（比如超长数字、特殊字符）。

后端：改请求数据看服务端会不会拦截非法输入（比如密码太短、格式不对）。

这样能提前发现开发时没考虑到的问题。

5. 怎么定位bug的？怎么进行前后端定位的？发现bug之后是怎么分析的？

发现问题从两个方面进行排查，请求和响应

先去检查请求的url，请求方法、请求头、请求体这些有没有问题，如果这些有问题就是前端的bug.

以及后端给响应了，也要看页面上展示的有没有问题，如果这些没有问题就要去排查后端的问题了，

只要响应有问题就是后端的问题，但是还要在进一步排查，先看一下数据库的数据有没有问题，

如果库里面数据有问题就说明在落库的时候就错了，如果库里面的数据没有问题，就说明接口在拿数据的时候有问题，开发写的sql语句出错了。

数据库

1. 数据库怎么用的

from -> where（between and /like） -> group by (having聚合函数)-> select -> order by -> limit

连表:

左连接：先展示两表共有数据，保证左表完整性，与右表不匹配的数据以null值展示

右连接：先展示两表共有数据，保证右表完整性，与左表不匹配的数据以null值展示

内连接：展示两表共有数据

A join B on A.共有字段 = B.共有字段

找出每一科的最高分

Select 科目，max（成绩）from 成绩表

Group by 科目

找出总分排名第六的学生？

Select sum(成绩) as 总成绩 from 成绩表

Join 学生表 on 成绩表.sid = 学生表.sid

数据库类型有哪些

id name

money优惠券面额

use type 优惠券类型

create_time 创建表时间

update_ time 更新表时间

group by 用于根据指定列对数据进行分组，常与聚合函数配合，实现分组统计

SELECT 聚合列,聚合函数(列)

FROM 表名 [WHERE 条件]

GROUP BY 分组列 [HAVING 分组后筛选条件];

Order by 排序按顺序 ASC AESC

常用的adb命令

8.连接:adb connec +本地域名+端口号

b.断开连接:adb disconnect+本地域名+端口号

查看连接设备:adb devicesC.

d.安装:adbinstall +本地apk包路径

e.查看包名:adb shell pm list package -3

f. 卸载:adb uninstall +app包名

9、查看日志:adb logcat -v time

h.推送:adb push 本地电脑路径/shcard/手机路径

1拉取:adb pull /shcard/手机路径 电脑路径

截图:adb shell screencap-p手机路径+文件名+后缀i

adb进样的内存

a. adb shell free

自动化

UI自动化 ---python

⾸先我们框架是分为三层的，有common公共层、pages业务层、test_case测试层：

1. ⾸先就是common层：

- common层我⾥⾯存放的我的locator定位器，还有我的截图，记录⽇志的⼀些⽅法，这些都是放在我的common层⾥⾯的。截图就是当我的⽤例执⾏失败后，就去调⽤我封装截图的⽅法，然后对我当前界

⾯ 进⾏⼀个截图，⽅便我进⾏测试，排查问题。

2. 还有就是⻚⾯层：

- ⻚⾯这⼀层，我封装了⼀个基类（Base），基类⾥⾯所存放的就是我对⻚⾯进⾏交互的⼀个⽅法。我是把打开浏览器作为我的构造⽅法,设置了⼀个类属性，⽤来判断我的浏览器，如果我当前打开了⼀个浏览器，我就不需要再次打开了，我就⽤旧的；如果没有的话，我就去新打开⼀个新的浏览器。其他就是我的找元素，找到元素点击，发送，切换弹窗这些⽅法，都是有关⻚⾯交互的⽅法，都是放在我的基类⾥⾯的，我其他⻚⾯的话只需要继承我的基类，调⽤这些⽅法就可以了。

-

- 其他⻚⾯类的话就是按照我们系统来进⾏命名的，⽐如说购物⻋⻚⾯，我就命名为购物⻋；⽀付⻚，我就命名为⽀付⻚。每⼀⻚都是

⼀个⻚⾯类。

3. 最后就是我们的test_case测试层：

- 测试层的话就是调⽤我业务层的函数去实现⼀个我的业务流。并且⽤到conftest的⼀个前置条件，把打开浏览器作为我的前置条件，关闭浏览器作为我的⼀个后置条件（这个就是fixture夹具的使⽤）。

- 最终通过allure装饰器来丰富我的测试报告，使⽤main.py⽂件来执⾏我的⼀个测试⽤例。然后其他的话就是⽤jenkins，让它⾃动去跑⾃动化的。还有我写完代码的话，我们组⾥⾯就上传，然后可以拉取最新的代码

UI自动化的通过率

我们这边自动化因为是制作巡检和回归的场景，所成功率相对来说是比较高的，像我下单的六七十个景用例，基本上能达到100%的通过率，

除非遇到一环境问题或者页面加载不稳定的情况，环境问题的这个没办法，可能在发服务器或者环境挂了都有可，那页面加载问题的话，

我这边是做了一些元素来提高我脚本的稳定性，比如说判断元素是否在中正常加载，还有判断元素是否在页面上可见，有元素是否可以被点击，

那么这个是我使用了selenium中的等待器配合ec条件进行了二次封装，这做的话每一次获取元素相对来说稳定性是有了很大提升，不至于说页面稍微加载久一点就导致我用例败，然后也有遇到过一些页面BUG，比如说我们在手测试的时候一些页面元素不可能每一个都肉眼去查，那自动化用例中会有一些断言机制，比如说我会断言页面的title、或者关键元素的一些文本之类的,之前也有发现果BUG，我们页面上的title不展示中只展示出了域名，最后排查发现是前端在做优化的候，title读取的文案没有读取到，导致只展示了域除了，所以说自动化还是能帮我们发现一些日常不易发现的问题的

自动化发现过哪些问题

有的，一方面是环境问题，一方面是代码问题;环境的话就有时候会不太稳定导致用例脚本执行失败，然后我们会去手动跑一下相关场景排除代码问题，还有就是有时候前端可能改了一些标签或者属性，导致定位失败找不到元素，然后就要我们重新去维护;

之前也有发现过一些BUG是代码的问题，比如我页面上设置了断言一些元素的文案或者关键字段的一些页面展示，会出现那种莫名其妙的toast提示，然后手动执行就发现在前端页面当中有留存一些console.1og(康搜唠个)或者一些调试的信息没有注释掉然后就在页面弹出了;

再比如说有一次还发现过页面title展示不出中文的页面名称只有一串域名，这种比较隐蔽的情况不可能我们每次做功能测试的时候都会关注到的，所以通过自动化的一些断言，还是可以找到一些问题的;但是我们这边自动化主要是做的回归用例节省人力的，所以大多情况下通过率都是100%

3. pytest执行顺序？

首先要符合pytest的用例识别规则，以test_开头或者_test结尾的py文件或者函数或者类.

py文件是从上到下，py文件中的函数或者类也是从上到下

4. 用到了哪些pytest的命令？

pytest -m 执行标记的用例

pytest -vs 输出详细信息，并且将函数中的打印语句输出出来

5. 装饰器的原理是什么？+

在不改变函数本身的情况下，给他增加一些额外的功能

采用的闭包的原理，内部函数引用外部函数的参数，外部函数返回内部函数函数名

6. 那你写过装饰器吗？

自己看过一些底层源码，所以说自己知道是这个原理，平时在这一块只是用的比较多，自己去写实际上不是很多的。

7. 用过哪些装饰器？

mark 对用例进行标记，实现分批执行

paramtrize 数据驱动，能够减少代码的冗余，只需要传入不同的测试数据就可以

8. 深拷贝和浅拷贝

深拷贝：由内而外都是全新的对象

浅拷贝：外层对象是全新的，内层都是共用的同一个

接口的同步请求和异步请求有什么区别？（低）

同步请求：发起请求之后必须要等得结果才能做下一个事情

异步请求：发起请求之后不用等结果就做下一个事情

9. 什么是接口的幂等性？

一个事情可以做多次，但是只有一个是正确的结果，其他的都是错误的提示

一个商品删除的功能，点了多次删除按钮，只有一次是删除成功，其他的都是错误的提示，该商品已删除.

Python

1. python常见的数据类型有哪些？

字符串str 整型 int 浮点型 float 布尔值 bool

列表list 元组 tuple 集合 set 字典 dict

10. 测试数据怎么造？存储过程会吗？

新增这个数据的业务接口，轮循去调用这个接口

通过python写脚本，连接数据库进行sql插入

2. 列表和元组的区别？

列表：是可变的，可以增删改查，值可以是任意数据类型，是有序的

元组：不可变的，只可以查，是有序的

集合：可变的，值是不会重复的无序的，有一个去重的功能，是无序的

字典：是可变的，值是键值对的方式，键名不能重复，是无序的

3. Selenuim的八大定位方法

id、name、xpath、css

Xpath 可以通过属性或者文本进行定位元素xpath可以进行轴定位，可以通过父子节点或者兄弟节点来进行定位css 只能通过元素的属性进行定位，不支持文本定位

4. 元素定位方法？

id、name、xpath、css

xpath 可以通过属性或者文本进行定位元素

可以进行轴定位，可以通过父子节点或者兄弟节点来进行定位

css 只能通过元素的属性进行定位，不支持文本定位

5. 三种等待方式有什么区别？

强制等待必须要等够这个时间才能做下一个事情，一般是用在打开一个新的页面的时候

隐式等待

直到这个元素出现了才会对这个元素进行操作，作用于全局的，每一次寻找元素都会自动去触发，如果在规定的时间内找到了则不再继续等待，如果没有找到则会报错。

智能等待

直到这个元素出现或者不出现，开始做下一个事情

6. 元素定位不到怎么办？

1. 检查表达式是不是正确的

2. 多加等待机制，这一步前面多加几个等待

3. 看一下有没有iframe框架的切换或者窗口有没有切换

7. 关于动态元素怎么定位？

通过显示等待去进行定位

8.ui自动化和接口自动化有什么区别？

ui更加关注界面的展示，界面的交互，验证界面上的元素进行断言

接口更加关注后端返回的响应报文 里面的数据

9.问题定位

怎么定位前后端bug

从请求和响应内容上进行bug定位

先检查前端发出的请求信息，比如说:请求url地址、请求头、请求体、请求方法这些信息是不是正确的，h这些信息有问题就是前端的bug，还有如果响应体是正确的，但是页面上展示有问题，也是前端的bug再看后端的问题，后端的话就是看响应体是不是正确的，如果响应体是错的，需要进一步排查，要石数据片6.的数据对不对如果数据库的数据就是错的，就是后端逻辑有问题，数据库的数据是对的，返回的就是有问题，说明接口在拿数据的时候拿错了，

怎么定位问题一股当BUG产生后首，我们会马上去验证一下url地址，请求的参数、请求头和请求体这些内容是不是正确的，是否和需求文档一致，在传参的时候，参数的数据类型有没有错，如果说这些都没有问题，那再去看响应，如果有应也是正确的， 但是页面的展示内容是错的，那就是前端的BUG。如果说响应体或者状态码发生了错误， 那我就会先去看看前端的参数有没有问题，如果没有问题，但是后端响应是错的，那么我会再进一步看看是不是数据库的问题，如果数据库正确，接口返回时错误的，那就足后拿数据的时候出错了。

出现bug你是怎么排查和定位的

首先，我会检查前端发出的请求信息，比如说:请求ur地址、调求头、调求体、请求方法这些信息是不是2，正确的，可以使用工具(如Chares、浏览器开发者工具)检查网络请求和响应，这些信息有问览就是前的bwg，还有如果响应体是正确的，但是更面上展示有问题，也是前的b49，然后，再看后端的问题，后端的话就是看响应体是不是正确的，如果响应体是错的，需要进一步排查，要看教把车的教据对不对如果数据库的数摇就是错的，就是后端逻辑有问题，数据库的数据足对的，返回的值就是有问题，说明接口在拿数据的时候拿错了，还可以拉取服务器的日志，通过分析日志去排查问题。如果bug比较复杂，可以让开发人

图片就在哪里,前端找到,出问题后找错地方,后端找到空,前端放错了地方;