学习的渠道

B站一些学习视频、CSDN博客、菜鸟教程

软件测试的目的

软件测试的目的是尽可能少的时间内找到尽可能多的缺陷，保障软件的质量。其实，软件测试是确认所测软件的功能是否满足软件需求规格书提及的，是否按照规格书所要求的那样正常实现。同时，软件测试是测试人员在测试过程中向开发反馈对软件的质量，让开发人员对BUG进行修复，而且软件测试过程中发现许多缺陷的话，表明这个软件的开发过程有问题，需改正开发过程。

软件的生命周期

（市场需求🡪项目计划🡪需求分析🡪设计阶段🡪程序编码🡪测试阶段🡪运行维护）
一般是根据市场的一个需求，然后我们会制定一个具体的项目计划，最后针对项目做设计，设计出来以后，开发根据设计文档编码程序，然后测试开始根据需求文档编写测试用例，指定测试计划，执行测试，测试结束以后，上线，然后还要进行运行维护。

为什么需要需求评审

梳理需求、消除歧义、完善细节、需求文档形成一个准确的统一文档。

需求评审的流程

我们需求评审通常都是产品人员发起的，参会人员主要有我们的开发、产品、以及测试人员，主要目的就是为了消除大家对文档内容的歧义，达成共识，更有助于后续开展工作。主要评审需求文档内容是否前后一致，是否有优先级，用语是否清晰明了，没有冗余，梳理业务流程，分析功能点是否可以满足业务需求。
我们一般的流程是：
1首先会检查下需求文档的正确性，检查有没有偏离最原始的用户需求；
2就是会对需求文档里一些比较含糊的词汇，进行确认，达到用语清晰无歧义；
3会查看一下最原始的需求文档，然后和现在的文档进行一下对比，主要目的是检查现在的需求文档是否完全覆盖了用户的需求点；
4就是针对软件的限制性是否有一个清晰描述，例如一些功能可以使用，哪些功能是不能使用的；
5需求文档里是否标注了优先级，因为文档比较多，哪些比较重要，哪些比较不重要都是需要靠优先级来区分的；
6最重要的就是一致性，需求文档里面是否有前后矛盾的地方，前后保持一致。

需求评审的时间是多少

看迭代周期，如果是一个小的迭代，需求比较少，30分钟就好了，大的需求更新，可能需要两个小时左右，这个也不一定的。

软件测试计划包含内容

测试对象
测试目标
测试准则（通过还是失败 挂起还是恢复）针对测试用例
测试风险
项目周期
交付标准

做好测试用例设计的关键

我认为做好测试用例的关键主要在几个方面：
1要熟悉本次业务的需求。
2熟悉其他系统和本次需求的关联。
3熟悉开发设计文档，了解开发实现逻辑。
4熟悉数据库设计文档，了解数据存储。
5熟悉项目构架，发现隐藏的需求。

项目的流程

拿到需求文档之后要进行需求分析，之后会召开需求评审会议，评审通过后，开发按照需求文档进行软件设计和编码，测试组长或主管按照需求文档制定测试计划，组员按照计划分配的任务模块编写测试用例，待开发提测后，进行冒烟测试，测试不通过打回给开发重新编码重新提测，通过后开始执行用例，执行过程中如果发现bug，要分析定位，跟踪bug的处理，测试完成后出具测试报告，由业务进行验收测试，验收通过等待产品发布上线。
思想原理：按照测试流程的5个阶段来讲的，即：需求分析阶段、软件测试计划的制定、测试用例的设计阶段、用例执行阶段、测试报告

软件测试的流程

1拿到需求文档，提炼测试点，编写测试用例；
2用例评审；
3冒烟测试（主流程通不通）；
4全量测试（测试环境中执行测试）；
5回归测试（bug回归、功能模块的回归、主流程回归、全量回归）；
6UAT环境和生成环境在做一轮测试；
7上线前在进行一个冒烟测试；
8编写测试报告，总结文档。

测试用例包括

序号、模块、标题、前置条件、测试步骤、预期结果、实际结果、备注
测试用例执行状态
●通过：测试用例执行通过，功能正常
●失败：测试用例执行不通过，需要开发修复
●阻碍：该功能被其他功能模块阻碍掉了，无法进行测试，可以先挂起来
●无效：测试用例无效，属于无效用例，可能不存在的测试场景。

测试用例是怎么写的？

1、首先我们会通过Xmind工具提取测试点，整理好大概的框架；
2、然后再用Excel，根据整理的测试点进行编写，主要依据的测试方法有：等价类、边界值、因果分析、错误推断等，一般是用黑盒测试方法来设计用例；
3、我们公司也有自己的标准用例模板，模板主要包含：序号、模块、用例名称、前置条件、操作步骤、预期结果、实际结果、编写人、日期、优先级和备注。
4、用例编写玩之后会继续用例评审。
做好测试用例工作的关键是什么
需求和设计文档的理解程度，对系统的熟悉程度

什么是好的测试用例

测试用例对需求覆盖率100%
一个步骤对应一个预期结果
测试用例是否清晰 简单 明了 是否有冗余
你一天大概能写多少条测试用例
写多少测试用例，具体要看项目的实际情况，如果说项目非常紧急的话，我遇到过项目非常紧急的情况，我一条用例都没写，直接用思维导图写下测试点，就开始测了，要说具体写多少，这个也不太好说，可能第一天写了200条，第二天就写了几十条，主要是针对第一天的用例，做一些补充，大概是这么一个过程，那么平均的每一条写多少条，没有固定的数值，通常是跟项目的大小有关，一个项目写个几百条肯定是没有问题的。

用例写多久

我们目前是两周一个版本，一般2-3天需求的评审和用例的设计，再3天用于用例的执行，3天时间进行回归，剩下的时间是进行上线的验证。

测试报告的内容

测试报告是整个项目测试完成之后进行编写的，主要是统计和分析整个测试过程的活动和产生的数据。
1简介。编写目的、参考文档、术语定义；
2测试背景。项目背景和测试环境；
3进度执行情况。人员安排和每个模块的测试时间和版本信息；
4用例执行情况。用例数分布（模块和类型）、执行率、通过率；
5缺陷统计情况。缺陷数量统计，缺陷重要级别统计，缺陷在不同版本的数量和重要级别，缺陷总数和修复数和遗留数以及遗留原因，重要级别的bug主要是什么问题。列举一些疑难bug说明；
6测试结论。此次测试通过与否；
7测试建议。此次测试之后测试有何建议。

α测试与β测试的区别？

α测试是在公司内部进行，有测试人员，或者用户在开发环境下进行，开发会在旁边记录使用者用户使用感受等。
β测试是在公司产品成型，进行公测，一般将产品发布到网上，直接给用户来使用。
α测试参与的人员比较少，β测试参与人员较多。

灰度测试是什么？

灰度测试也就是我们说的 A/B测试。有多个版本，无法确定哪个版本带来的效益更高，所以选定部分用户，划分不同的用户画像，推送不同的版本，根据结果来确定最终的版本。在产品正式发布前，选择特定人群使用，逐步扩大试用者数量，直到覆盖所有的用户。

你们有几套环境

●开发环境（dev环境）：
●测试环境
●预发布环境（UAT环境）：模拟生态环境，项目投入市场使用后如果生产环境发现缺陷，UAT环境中进行1:1数据测试还原。
●生成环境：每一个环境都需要进行一样的流程性测试，生产环境通过后，达到上线的标准才可以进行上线，上线后应用商店再进行一个简单的冒烟测试，编写测试报告，总结文档。

功能测试的步骤

查看功能需求，针对这个功能点使用合适的用例设计方法编写用例，注意正面和反面用例的覆盖，然后执行用例发现缺陷后提交缺陷等待缺陷修复。修复后对缺陷进行复测关闭。编写测试报告。

测试分为哪几个阶段

按照开发阶段划分，软件测试可以分为单元测试、集成测试、系统测试和验收测试；
1.单元测试：针对每个单元的测试，以及确保每个模块能正常工作为目标；
2.集成测试：对已测试过的模块进行组装，进行集成测试，目的在于检验与软件设计相关的程序结构问题；
3.系统测试：检验软件产品能否与系统的其他部分（比如硬件、数据库及操作人员）协调工作；
4.验收测试：检验软件产品质量的最后一道工序，主要突出用户的作用，同时软件开发人员也应有一定程度的参与。

冒烟测试主要测什么？怎么做的

冒烟测试主要针对主要功能或者主要的业务流程。
●接口测试：使用上下游传参的方式走一遍流程。
●功能测试：模拟用户在页面上进行操作。上线前做。
冒烟测试，通过率要求在90%以上，上线之后冒烟测试必须100%。

回归测试怎么做

我们做回归的时候分为bug回归、功能模块的回归、主流程回归以及全量回归。
Bug回归就是在开发修复好之后进行的及时验收回归；
我负责的模块测完之后，就会进行一下个整体的功能模块回归。
我们项目全部测完后，还会进行一下主流程回归。
依据时间安排，时间允许的话，还会进行一轮到两轮的全量回归测试。
回归的时候，我们主要依据我们所写的用例，划分优先级，P0级的用例作为主流程回归，P1 P2级别的用例作为全量回归。
我们在做全量回归的时候，第一轮在测试环境，测试环境没有问题的话，会把整个项目发布到预发布环境，之后再第二轮的预发布环境进行回归，预发布环境也没有问题的话，就会通知产品过来验收。

软件测试的方法有哪些

常用的测试方法比方说：等价类划分法（有效等价类和无效等价类）、边界值分析法（有效边界值和无效边界值），判定法、正交实验法、流程分析法、状态迁移法、因果分析法、错误推断法。
●单元测试（对单个功能测试）常用的方法：
○边界值，等价类相关的方法
○测试正常场景和异常场景
●集成测试（对某个流程进行测试）常用方法：
○ 针对整个流程来设计测试点以及测试用例。比如购物流程，涉及到登录，加入购物车，结算一系列的相关操作。使用 流程分析法，状态迁移法（订单有不同的状态）根据状态来设计用例。

你平时是怎么评审用例的

1、我们平时都会开一些用例评审会议，参会人员主要包括（项目经理、开发经理、产品经理、开发人员还有测试人员）
2、针对测试用例会一条条的进行评审，我们也有相对应的评审规则：
●检查是否有冗余，完整，清晰；
●有没有覆盖需求，是否依据需求。要做到对需要100%覆盖；
●检查是否有错误，流程步骤要详细，可操作，有明确的预期结果；
●除了正例，还要有足够多的反例去进行测试。
3、在评审过程当中，我们也会详细记录修改点，会后进行修改，在最终确定完整版的测试用例。

每天可以提交多少个bug

这个和项目的所处阶段有关系
维护中的项目：bug是比较少的，相对稳定
项目从来没有测试过（前期）：没有经历过系统性的测试bug超级多

如何提交一个高质量的bug

bug的标题简单明了，清楚描述出缺陷是什么
复现步骤，有截图的附上截图
所测试的版本和哪一个环境下测试出来的

如何提高软件质量

首先要对项目的需求有足够的了解，对需求梳理清晰，其次开发提测的版本质量也有影响，多轮测试也比较关键，及时跟进项目进度，针对提出来的缺陷也要进行分析，以防止修改引入一个新的问题，从而导致程序进入时一直有新的bug的情况，线上版本也要做检测。差不多就这么多。

bug的缺陷等级

一级致命缺陷
二级严重缺陷
三级一般缺陷
四级建议缺陷

bug的生命周期

bug的生命周期主要是从：
1发现bug；
2确认bug，制定给相关的开发人员；
3开发人员修改后，标识为修改状态，然后测试人员回归测试验证；
4如果开发认为不是bug，拒绝修改；
5如果认为暂时不需要修改或者暂时不能修改，则延后修改；
6修改状态的bug经测试人员的回归测试验证通过，则关闭bug；
7如果经验证bug仍然存在，则需要重新打开bug，开发人员重新修改。

禅道（jira）提交缺陷包含的内容

所属项目
bug的标题
重现步骤
严重程度
优先级
指派谁
附件截图
备注

你提交了一个bug 开发不认为是一个bug

首先确认开发环境是否跟自己测试环境一致, 排除因环境或者业务理解不一致而产生的错误bug。确认是实实在在的bug,跟开发保持有效的沟通。严重级别较高的bug, 对应需求文档、试出现的bug截图、bug对产品影响的危害，跟开发说明清楚,更有说服力。若开发仍然不接收bug，需要找上级或产品介入。级别较低的建议性bug，开发不改，暂时不需要花费大量时间去说服修改，有时间再进行集中跟进。

如果上线了发现bug怎么处理

根据缺陷等级
如果影响整个程序运行的，回退到上一个版本，进行紧急修复
如果只是一个小的模块，暂时关闭这个模块，紧急修复后在上线
如果只是很小的问题不影响用户的使用，放在下一次迭代
对于偶现bug的处理方式
一般对于偶现bug，我们一般也是会提交禅道的，这种bug提交的时候，首先要描述当时的操作环境，操作步骤，数据，并提供必要的日志，还有备注上产生的原因。当时我们也会仔细核查几遍，运用一些排除法啊，错误推测找规律，有必要的时候也会求助开发人员，项目经理一起定位分析讨论，如果最终扔未结果，那么也会在测试报告中体现出来，并分析可能造成的影响，大家一起权衡该bug是否可遗留，当时也会记录好该条记录，后期迭代中也会多加关注。

产品马上上线前，客户突然要新增需求怎么办

看这个需求的重要性，如果只是建议性的，可以留到下个版本实现，如果很重要，强制更新，就按照这个需求重新修改测试用例，并重新提测，注意修改这个需求可能引起的缺陷和可能引起的其他缺陷，以及会不会影响到老功能，一般我们会进行回归测试。

谈谈你对软件测试的理解

测试不仅仅是发现缺陷，对于项目质量严格把关
测试人员推动项目的验收，主动多和开发沟通
上线后整理相关文档，监测线上项目质量

如何跨行到这个软件测试岗位来的

身边有朋友学习这个行业，发展前景不错，薪资可观，稳定
朋友推荐网课 学习内容
进入到这个行业

测试方面

界面测试：这个程序做出来以后的美观度，参考设计稿
功能测试：参照需求文档，需要完成那些内容
性能测试：这个功能在做好的情况下，如何提高速度优化类的，响应时间
兼容测试：不同手机型号，不用的端（ipad、电脑、ios、andrdid）不同的版本
易用性测试：站在用户体验的角度出发，程序好用度、便捷度
安全测试：用户隐私，数据保护等角度

缺陷定义

1.需求说明书中没有但是要实现的功能
2.没有实现需求说明书中描述的功能
3.需求说明书中说了不需要的功能但是实现了
4.需求说明书中没有但是不应该有的功能
5.程序的响应时间 使用不便捷

如果你测试APP，突然崩溃了，你该怎么办

答案2：立即连上adb，把日志拉出来，记录刚刚操作的步骤，尽量试试能不能重现，然后把问题出现步骤以及时间点告知开发，日志发给开发。
答案3：重复操作步骤，bug重现，是必发还是偶发。
答案4：（1）记录操作流程（2）记录运行环境（3）获取崩溃日志
答案5：可以用抓包工具连接手机，做一下重复操作进行抓包定位。在一个就是看看是不是没有内存了或者开发在更新代码。
答案6：直接搜索Fatal或crash
答案7：回想之前的操作并且多次重复，尝试是否是因为某一个特定问题导致APP崩溃，并且记录通知程序员查看代码是否有误。

安卓测试和ios测试的区别

1， 安卓因为是开源的。由于版本的不同，界面会比iOS好看
2，分辨率不同。安卓有20多种，ios较少一点。
3， 后台制度不同，iOS不允许第三方在后台运行。Android运行所有的程序在后台运行
4，操作系统不同。安卓有操作系统比较多，IOS较少，而且IOS系统只支持单项升级，不能降级。
5，操作习惯的不同：像Android，习惯的去点击back键，虽然现在很多都是全面屏，都是通过手势滑动返回，但还是属于back键的功能，所以Android需要测试back键是否被重写了，点击了back键系统的反馈是不是正常的。
6，安装和卸载测试：Android的安装的平台和渠道相对会比较多，而iOS的话一般只支持官方的渠道比如说 APP store 、 iTunes 工具等。
7， 运行机制：OS采用的是沙盒运行机制（sandbox），沙盒就是一种独立、安全、封闭的空间。IOS几乎不会出现卡顿现象。沙盒运行机制对应用程序执行各种操作有权限限制，比如访问别人沙盒内的数据时需要访问权限。Android采用的是虚拟机运行机制，这样的运行机制需要消耗更多的系统资源，所以Android系统使用一段时间后就会变得卡顿。
8，系统更新：IOS系统一旦更新出来后，搭载其系统的苹果移动设备都可以及时的升级系统。而Android系统虽然更新出新版的系统，但是普通用户是享受不到的，因为它不能自动更新到最新版

app与web端测试的区别

1app属于cs架构，web端属于bs架构
2app需要测试安装更新卸载，而web每次打开都是最新的页面
3app测试需要考虑手机系统以及不同的系统版本，不同手机品牌，不同的分辨率等兼容，而web端主要是测试谷歌、火狐、edge、Safari等浏览器的兼容
4web端更注重响应时间，并发量，资源占用率（cpu 内存 硬盘），而app更注重网络测试（如弱网，中断网络，网络切换），接听电话，电量消耗，流量消耗
5app需要考虑蓝牙，GPS NFC等硬件的测试
——具体看你写在哪一年 ：ios 机型8-13 ，版本9-15，屏幕大小，和安卓 机型华为、小米、oppo、vivo、锤子、魅族等 版本8-12，曲屏，折叠屏幕，华为鸿蒙
弱网测试20kb/s
——手机专项测试 安装、卸载、来电、断电、短信、闹钟、关机、断网、app切换——参考会议笔记

小程序和app的区别

1安装包的不同
○手机app必须要下载安装包进行安装才能进行使用。
○小程序不需要安装，直接扫码或分享在微信中使用。
2包的大小限制不同
○手机app的安装包没有最大限制
○小程序开发，开发之后提交到微信审核，提交的包的大小不能超过2M。
3上传审核不同
○手机app提交到应用商店
○小程序是提交给微信
4开发语言不同
○手机app，Android主要使用Java，IOS主要使用swif
○小程序开发主要使用JavaScript。
5测试的兼容性
○手机app主要兼容手机，操作系统
○小程序主要是依赖于微信，兼容性主要测试微信的不用版本的兼容
移动端包括
安卓设备：安卓手机，平板，车载系统，智能手表
ios设备：苹果电脑，ipad，，，，
小程序，H5，公众号
以上都属于移动端

h5页面本质上就是一个网页，测试的时候主要是适配测试为主，就是在不同的设备上打开这个网页，观察展示的效果是否正常
兼容性测试主要考虑：
安卓设备：市面上主流的几款设备
ios设备：苹果6-13

热更新和冷更新

冷更新：指的是从应用市场下载应用，然后安装更新，会替代旧的安装包
热更新：指的是从app服务端下载更新的补丁然后自动安装。（在线更新）

热启动和冷启动

热启动冷启动的区别就是：
●热启动就是本身就是在运行，在运行的过程中，只是临时退出这个页面 ，但是后台在运行的 。
●冷启动就是现在刚刚打开这个软件。

在测试环境怎么安装软件app

1开发会直接把安装包发送给你，然后直接安装
2开发会给你一个连接或者二维码进行下载安装包，然后安装（链接和二维码是借助蒲公英平台生成的）

测试左移是什么？测试右移是什么?

左移就是产品在未上线的时候，开发人员在在编程的时候加入代码自动化测试，每次开发改动代码都能触发这些自动化测试脚本执行。
测试右移是产品上线之后，添加埋点测试，线上统计用户的行为数据，可以更好的后期为用户服务，提供更适合用户的功能或者下次提bug的过程中可以更好的站在用户角度提高用户体验。
现在大家可以做的是：左移的时候使用接口自动化的方式来做。

埋点测试怎么做

根据app中添加的埋点字段类型，去服务器检查相关日志，比如常见的的埋点，统计用户在页面停留时间，以及这个页面是从哪个页面导航过来的。统计到这些数据主要为了后面方便给用户进行相关的推荐。
设计用例的时候，考虑正向的用例和反向的用例。
正向用例：正常的操作，操作完之后检查服务器后台对应的日志，看是否有对应的日志记录。
反向用例：在操作过程中插入一些中断测试之类的，比如打开app浏览某页面的时候，将页面在后台挂起，这个时候不应该统计用户的停留时间。也是去后台查看对应的日志来检查。

大数据测试怎么测试

也是从用户的需求来出发，设计测试场景，比如购物网站首页，不同用户首页内容不一样，测试的时候
1使用全新的手机未登录状态下，浏览商品，重新打开app观察首页内容
2在一台全新的手机登录自己的账号，观察打开app首页内容
3退出自己的账号重新打开app观察首页的内容
4注册一个新账号，浏览商品以后，换台设备登录新账号，观察首页内容。

弱网测试怎么测

1弱网的功能测试。2G/3G/4G/5G的网络可以通过使用电话卡移动/联通/电信等网络进行模拟；
2无网络状况测试。主要关注界面的显示、用户交互、本地数据的存储断网功能的使用等；
3网络切换测试。这部分主要是进行几个不同网络场景的切换，包括WiFi到2G/3G/4G/5G、WiFi到无网、2G/3G/4G/5G到WiFi、无网到2G/3G/4G/5G、无网到WiFi等。
4用户体验度。页面响应时间，包括热启动、冷启动时间，界面切换，前后台切换，首字显示时间，首屏显示时间等；界面呈现是否完整一致；超时文案是否符合定义，异常信息是否显示正常；是否有超时重连机制；安全角度：登录ip更换频繁、单点登录异常等；大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。

项目有关的面试题
测试计划包含内容

测试计划主要是测试组长编写的。主要包含测试概述（编写目的、背景、参考文档）、测试目的、测试范围、测试资源（人力、测试环境、bug管理工具）、测试管理（人员分工、进度时间安排）、测试策略、测试标准、测试风险、测试输出。

3年的工作经验，平时具体的工作是什么

刚接触测试行业的时候，平时主要工作就是一些界面上的功能测试，后面新的项目中有接口测试，当时之前没有做过接口，跟开发一边学习一边来做，当时使用postman做基本的接口，后来每次做回归都要单个接口单个接口运行，比较费时间，后来通过不断的学习，根据业务实现接口串联。
再到后来公司有性能测试的需求，于是使用jmeter功能整理以及做性能测试，到现在为止，主要的测试比如app，小程序，接口，功能测试都已经非常的熟练，平时工作中我们正在做的xxx项目，我主要负责的xxx功能，接口，性能测试。
项目验收之前还需要做什么
测试报告、评估、确认是否能上线、文档汇总提交
之前项目有没有遇到延期的
我之前做的几个项目中，其中有一个项目有延期的，当时是因为我们项目的需求一直在整改，包括测试环境一直反复的崩溃，还有开发这边拖延了，所以导致我们当时没办法按时交付。

git常用命令

git clone 把远程仓库克隆到桌面
git status 查看文件状态
git add 添加文件到暂存区
git commit -m 备注信息
git push 推送文件到远程仓库
git push -f 强制推送
git log 查看日志
git reset —hard 通过哈系数回退任何一个版本

adb常见命令

查看连接设备：adb devices
查看设备运行日志：adb logcat
过滤设备运行日志：adb logcat | findstr 关键词 #通过关键词过滤日志’err’ ‘error’ ‘exception’
进入手机内核：adb shell
安装文件：adb install
覆盖安装：adb install -r
卸载程序：adb uninstall
退出内核：exit
上传文件：adb push
下载文件：adb pull

monkey常用参数

●-s 种子值 （种子值可以是上次执行时生成的种子值）
●-vv 显示日志
●-throttle 延迟时间 ms
●-p 指定运行的包名
monkey随机测试
monkey是对app进行稳定性测试，模拟用户的随机操作，保证软件不会出现闪退，崩溃的情况
●adb shell monkey -s 种子值 -p 软件包名 -vv 随机事件数
●adb shell monkey —throttle 200 -p 软件包名 -vv 随机事件数
你们公司怎么使用monkey的
晚上下班以后，monkey连接手机开启运行，一般运行一个晚上，运行数30w-50w。

linux常用命令

查看进程：ps -ef
杀死进程：kill
查看服务器：top htop(更专业)
查看端口号：netstat -anpt
查看ip地址：ifconfig
查看磁盘：df -h
查看端口号：netstat -anpt
查看内存：free -m
查看历史命令：history
查看网络是否连接：ping
修改权限：chmod 读r4 写w3 执行x1
统计文件：wc
对比文件：diff
查看当前路径：pwd
切换路径：cd
查看端口号：ifconfig
上传：rz
下载：sz
查看文件：cat，head，tail，还有grep过滤文件内容
有一个a文件怎么查看文件的5-10行 head -10 | tail -6 或者 sed -n ‘5,10p’ a
怎么打印日志的后10行 tail -f 日志文件 或者 tail -10f 日志文件 或者 tail -fn -10 日志文件
1，平时查看日志文件。通过tail -f查看实时日志，也会使用tail -f | grep “error”来过滤日志；
2，在做性能压测的时候，通过top或者htop来监控服务器的运行状态，也会使用df -h查看磁盘，free -m查看内存；
3，像vi 编辑文件，tar 解压缩文件，chmod 修改文件权限，wc 统计文件，diff对比文件等等。

你们怎么查看服务器的运行情况

top 查看cpu（查看系统运行情况）
ps -ef 查看进程
netstat 查看端口号
de -h 查看系统磁盘
free -m 查看内存

你这边一般回去查看日志吗？

有查看过，一般我们每个项目的日志文件存放的路径都是不同的，但是日志文件一般都是在logs目录下进行存放，并且以为log后缀，开发一般都会告诉我们日志文件的具体路径，找不到的话，我也会根据日志的名字，用find命令查找。
日志里面有时间信息，有日志类型，以及请求的具体内容，我这边主要关注error类型的日志，并且我一般用tail -f来实时打印日志，并且我还会通过grep来对日志进行过滤。
我一般用grep过滤的关键词有error，exception。
日志类型：info【信息】| debug【调试】|warning【警告】|error【错误】

linux三剑客知道吗

之前有使用过，其中grep过滤文本，sed修改编辑文本，awk分析处理文本。
grep 通过行首特定字符，行位特定字符，忽略关键词的大小写，显示行号。
sed 添加文字，删除文本，批量修改关键字。
awk 打印列，打印行，打印包含某些关键词的行，制定分隔符。

你会搭建测试环境吗

有搭建过，我们之前都是老大会给我一个环境部署文档，然后我按照文档上面的内容进行测试环境搭建，一般就是rz，sz上传下载安装包和配置文件，也会用到vi来修改配置文件的内容，以及通过git clone来下载项目代码，还有重启服务之类的命令。

数据库

数据库常用sql（5.7版本）
查询：select
分组：group by
分组过滤：having
排序：order by
限制返回结果：limit m,n m+1开始取n条数据
聚合函数：sum()求和；min()最小值;max()最大值;avg()平均值;count()计数
其他函数：distinct去重；concat()拼接字符串
添加数据：insert into 表名 values
修改数据：update 表名 set 修改的状态 where 条件
删除表中的某一行数据 或者某些行数据：delete from 表名 where 条件
清空表：truncate 表名
将整个表数据删除，表不会存在：drop table
清空表中的数据，但是表还存在：truncate table

左连接和右连接和内连接的区别

left join 以左表为主表。显示出所有左表的内容，如果该内容右表没有，用null填充；
right join 以右表为主表，显示出所有右表的内容，如果该内容左表没有，用null填充。
内连接：只有两个元素表相同匹配的才能在结果集合中显示。

union 和 union all的区别

Union：对两个结果集进行并集操作，不包括重复行，同时进行默认规则的排序；
Union All：对两个结果集进行并集操作，包括重复行，不进行排序；

给你一个新表测试要注意什么

只读权限
关系型数据库和非关系型数据库

关系型数据库最典型的数据结构是表，由二维表及其之间的联系所组成的一个数据组织。
非关系型数据库严格上不是一加粗样式种数据库，应该是一种数据结构化存储方法的集合，可以是文档或者键值对等。
关系型数据库优点：1、复杂操作，支持SQL，可用于一个表以及多个表之间非常复杂的查询。2、使用方便。3、易于维护。
缺点：1、读写性能差，尤其是海量数据的高效率读写。2、固定的表结构，灵活度稍欠。3、高并发读写需求，传统关系型数据库来说，硬盘I/O是一个很大的瓶颈。
非关系型数据库优点：1、格式灵活，存储数据的格式可以是key,value形式、文档形式、图片形式等等。2、速度快。3、高扩展性。4、成本低。
缺点：1、不提供SQL支持，学习和使用成本高，2、无事务处理。3、数据结构相对复杂，复杂查询方面欠缺。

悲观锁和乐观锁

悲观锁：当3个请求访问数据库中的资源的时候，其中一个请求会获取到锁，而其他两个请求会在外面进行等待，等第一个请求访问完之后会释放锁，然后下一个请求获取锁然后访问，然后一直循环刚刚的操作
获取锁—-访问完数据库，释放锁——下一个请求获取锁——访问完成，释放锁。。。。。一直重复循环这个步骤
乐观锁：当3个请求同时访问服务器的时候，都可以对服务器中的数据进行更改，更改完之后提交，第一个提交的请求可以成功，其他两个请求都会失败。然后那他两个请求需要重复刚刚的操作。
3个请求访问数据库——第1个修改完然后提交成功——-其他两个也提交然后显示操作失败，请重试——重复刚刚的操作
区别：
悲观锁：对数据处理持以悲观的状态，认为肯定会发生数据冲突，修改数据的时候，别人也会修改；保证数据的安全性，但是降低了性能。
乐观锁：对数据处理持以乐观的态度，认为一般不会发生数据冲突，只有提交数据的时候会检测版本号是否与当前版本号一致。提高了性能，但是会发生冲突，让用户进行重复的操作，反而会降低性能，高并发的情况下悲观锁更加实用一些。

count（*）和count（字段）的区别

count（）是对所有字段进行统计，只要一行中有一个字段有值，就会认为是一行数据。
count（字段）是对该字段的统计
mysql中空字符串的长度是多少？null的长度是多少
MySQl中空字符串的长度为0（””）
null的长度为nul
where和having的区别是什么
where后面是用来过滤表里面的行，并且where后面不可以使用聚合函数
having是用来过滤分组的，having后面可以使用聚合数。
平时有操作过数据库吗
之前工作的时候有操作过，一般是在数据库中进行查询的操作，select 查询，where 条件过滤，group by分组，having 分组过滤，以及连表 join on 这些语法都会用到。
就比如说where后面的逻辑运算符，in ，not in，is null， betwwen and ，like 这边都会使用到，包括一些常用的函数，max，min，avg，sum，count。
然后增删改我这边没有操作权限，没有实际在工作中使用，但是这些命令和语法我有自己私下操作过，也很熟悉。
mysql关键字的执行顺序
from > where > group by > having > select > order by > limit
什么是索引
●给字段添加索引就相当于给这个字段里面的值添加了一个字典目录
●优点：提高sql语句的查询速度，在数据量比较大的情况下，可以明显提高工作效率
●缺点：占用系统空间，维护起来比较麻烦，添加，修改，删除数据会变慢
怎么不让索引失效
1.不在索引列上做任何操作(计算,函数、自动or手动类型转换),这样会导致索引失效而转向全表扫描。
2.存储引擎不能使用索引中范围条件右边的列。这个是因为age中查询时范围查询了,pos列的索引就没有生效了。
3.尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致)),减少select 。
4.mysql在使用不等于(!=或者<>)的时候无法使用索引会导致全表扫描。。

如何避免笛卡尔积

解决办法
这样冗余的数据可不是我们想要，所以想要你的结果避免笛卡尔积，既要做到以下⼏点：
1.关联范围在最⼩粒度的列。
2.如果是三张表连接，并且是1：n：n的关系，就要先关联两张表，然后将两张表关联的结果与第三表在进⾏关联，这样就可以取得
我们想要的结果啦！多张表同理！

主键、外键和索引的区别

1定义：
●主键：唯一标识的一条记录，不能有重复的，不允许为空
●外键：表的外键是另一个表的主键，外键可以有重复的，可以是空值
●索引：该字段没有重复值，但可以有一个空值
2作用：
●主键：用来保证数据的完整性
●外键：用来和其他表建立联系用的
●索引：用来查询排序的速度
3个数
●主键：只能有一个
●外键：一个表可以有多个外键
●索引：一个表可以有多个索引

存储过程

运行复杂的sql语句的时候可以把这些sql定义为存储过程，简单理解就是sql语句的集合，并且编译一次之后可以一直使用，提高工作效率，以及sql的复用性。

接口测试

API是什么

Api文档就是接口文档，会有对相关接口的说明。

接口测试的原理

模拟：客户端给服务器发送请求，然后服务器接收到后，对这个请求进行响应的一个过程。

什么是接口测试

接口测试就是测试系统组件间接口的一种测试，接口测试主要用于检测外部系统于系统质检以及内部各个子系统质检的交互点。测试的重点是检查数据的交换，传递和控制管理过程，以及系统间的项目逻辑依赖关系等。

为什么做接口测试

因为现在大多数系统都是前后端架构分离的，前端有前端代码，后端有后端代码，如果只依赖前端进行限制，已经不能满足系统的安全要求，绕过前面太容易了，需要后端同样进行控制，这种情况下，就需要从接口层次进行验证。前后端传输、日志打印等信息是否加密传输，也是需要验证的，特别数涉及到用户的隐私信息，比如身份证、银行卡等。所以从系统安全性角度来讲，是要做接口测试的。

在项目当中一般什么时候开始做接口测试

在我们项目中，需求确定后，一般前端和后端开发人员会同时进行开发，接口开发完成并发布后，我们就开始进行接口测试，而不需要等前端页面完成，这样就可以尽早的进行软件测试，我们的接口测试完成后，前端在调用接口的时候就可以节省联调的时间。

接口测试和功能测试的区别

功能测试： 就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
接口测试：接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
区别：功能测试和接口测试的区别在于，功能测试侧重点在于前端ui界面，数据展示，图形界面，业务逻辑操作等，接口测试侧重点在于，后端返回的数据是否正确，接口是否正常。

做完接口测试之后为什么还需要做功能测试

首先功能是由接口实现的，接口也是先开发出来的，首先做的就是接口测试，但是接口没有问题，并不能保证前端的功能没有问题，所以还需要做一遍前端的功能测试。
功能测试只可以把前端功能能覆盖到，并没有办法测试到接口里面的一些场景，因为有的场景在前端页面是无法操作的，就比如下单一个不存在的商品或者下架的商品，修改商品的价格为1分钱然后下单，在前端页面就无法实现，所以要专门对接口进行测试，保证接口的安全性。

接口测试的流程

1先拿到API文档，如果没有API文档，需要抓包。
2根据API文档，整理API的测试点，接口又分为单接口和多接口测试：
a单接口测试（csv参数化），需要整理接口的正常场景和异常场景，将测试数据整理到csv文件中，在接口工具中上传csv文件，通过读取csv文件的方式来进行接口测试；
b多接口（上下游传参，接口关联），首先要梳理接口之间的关联关系，根据业务确定上下游接口和下游接口，在上游接口提取变量，下游接口引用变量。
3接口配置完以后，针对每个接口添加相应的断言，断言是根据具体的业务来设置，主要有状态码断言，响应文本断言和json断言（我用的最多）。
4执行的时候观察最后的执行结果，与我预期的是否一致即可。

单接口怎么测试

主要通过csv，csv里面整理正常场景以及异常场景，再通过postman中run界面，选择要做的接口，上传csv文件，再去执行。
jmeter的话，需要配置csv data config这个配置的元件，在配置元件里面，上传csv文件，然后在接口以引用变量的方式，调用csv中的数据，最后在设置线程组的循环次数，csv中有几条数据，就要设置几次，循环次数不能少于csv文件中的数量数据。

上下游传参怎么做

我做的时候一般使用jmeter或者postman工具。
首先我说下用postman去做，也是先根据业务场景，确定上下游关系，在上游接口中【tests】面板中，编写代码，把响应结果中需要传递的参数提取出来，设置为变量，然后在下游接口中通过使用{{变量名}}的方式来引用变量。

那么jmeter的话，也是先确定上下游的关系，在上游接口中，我一般会用到json提取器，或jmes提取器，在查看结果树的返回结果中，通过json代码的方式来提取传输的值，来设置变量，json提取的话需要加上$.,jmes的话一般不用加$.,直接写表达式即可。如果碰到复杂的json，我主要就是使用jmes提取器，比如根据特定的条件提取某个值的话，会使用[?contians(字段名,’具体的条件’)]这样的方式去提取变量，随后在下游接口中通过使用${变量名}的方式去引用这个变量即可。

Postman怎么做接口

首先是我一般做的接口测试会先整理测试点，然后编写测试数据和测试用例，主要就是修改接口的入参，写完以后，会把测试数据整理为csv格式的文件，然后在postman中建立一个请求，填写请求方式、请求地址、请求头和请求参数，这里面的请求参数，我会引用csv文件中的数据（通过变量名的方式引用），然后在run这个接口请求，上传csv文件，然后执行，看一下接口的执行接口是否与预期结果一致，我这边还会使用到动态断言的方式，来进行判断，这个就是单接口的测试。
多接口的话，首先我会根据业务关系，确定上下游的接口，然后把上游的返回结果中的参数提取出来，设置为变量，然后在下游接口中进行引用（实现动态传递参数）。

jmeter怎么做接口

首先我会先做单接口的测试，根据接口文档整理接口的测试点，编写测试用例，并把测试数据整理为csv格式的文件，然后在jmeter中添加线程组，添加http请求和查看结果书还有【csv data config】csv数据驱动配置元件，然后在里面上传csv文件，设置编码格式，和变量名，然后在设置线程组的循环次数，循环次数需要与csv文件中的数据保持一致，然后在接口中通过变量的方式引用csv数据。 然后运行，观察接口的运行结果是否与预期一致，这边我还会使用动态断言的方式给请求添加断言。
多接口测试，也是需要先确定上下游关系，在上游接口中，提取变量，我主要使用的是json提取器和jmepath提取器来进行提取，然后在下游接口中通过${变量名}的方式来引用上游的变量。随后在给接口添加断言。

怎么添加断言

在我工作中，主要用到的断言有状态码断言以及json断言。
在做接口测试的时候，要针对每个接口设计断言，断言的内容主要根据服务器返回的结果来设置断言，在postman中，在【teses】面板中通过postman内置的语法进行断言，比如code is 200内置语法。
在jmeter中，选中接口—-右键添加响应文本断言，根据具体的内容，选中响应状态码，或响应文本，在选中包含相等或字符串，在下面测试模式中，添加状态码，如200.
json断言的话，首先要写好json的路径表达式，然后选中接口—-添加json断言，在里面把json表达式写上去，再写一下预期的返回结果即可。

jmeter中常用的提取变量的方法有哪些

常用的比如json提取器
正则表达式提取器 ：主要是使用（.+?）来设置变量
jmespath提取器
以及jdbc的方式去提取，现在jmeter中配置jdbc请求，在请求里面写sql语句，在varible name中写设置变量名，下游接口引用的方式是${变量名_1}的方式去引用

复杂接口如果提取变量，如何进行断言

提取变量值，我做的时候，一般就会使用jmespath提取器，具体语法就是[?contians(‘字段名’,’具体的条件’)],[?字段==值],然后提取变量值，断言的话，一般是使用json断言和响应断言，也会根据每个接口返回的结果不同而设置动态断言。

如何判断是前端bug还是后端bug

方法一：如果请求数据有错误，就是前端问题，如果响应数据有问题，就是服务器有问题（代码逻辑问题,,执行sql 问题 看日志）
方法二：通常我们是通过抓包工具来进行分析，可以从三个方面分析：请求接口、传参、响应。
1、请求接口url是否正确。如果请求的接口url错误，为前端bug。
2、传参是否正确。如果传参不正确，为前端bug。
3、请求接口url和传参都正确，查看响应码是否正确。如果响应码不正确，为后端bug。
4、当我们发现一个bug，并不确定属于前端还是后端。可以查看后端服务的日志，复现bug时，查看日志中，如果日志没有输出，很可能这个功能没有与后端交互，也就不存在后端的问题。反之，如果日志输出，可以进一步查看有误错误日志输出，进一步分析。

app出现bug怎么定位

第一先尝试复现bug,先看页面提示报错,然后打开开发者工具,查看console前端日志提醒,如果没有找到问题,再看network,查看 请求方法,请求路径，请求数据有没有错误，请求有没有发送成功，发送参数是否有误,如果发送成功了看network 的响应,如果响应正确没有显示那么也是前端问题
如果响应有问题则去看日志,看后台日志(看日志需要 服务器ip,账号,密码,文件路径需要)
去后台系统安装的linux服务器看日志,看日志如果是历史bug 使用more或者less 文件小可以用cat 查看日志关键字可以使用 |grep ‘关键字搜索’,比如用用户编号,订单号,时间等,如果复现bug 可以用tail -fn 20 查看最新实时日志 ,如果日志中有sql语句可以复制出来链接数据库进行对比看是否符合业务逻辑,提交bug时可以加上截图,日志等附件

前端如何调用后端接口，后端接口还没有开发完如何测试

创建mock挡板，模拟接口请求的返回接口，然后测试，前端页面在各种场景能否正常显示。

接口常见的协议

●http 超文本传输协议
●https 超文本传输加密协议
●tcp 文本传输协议

http协议组成部分

http请求的组成：
1请求行 （请求方式：get post）
2请求头
3请求体
http响应的组成：响应行、响应头、响应体

http和https的区别

1、传输方式的不同；（http是明文传输，https是加密传输）
2、安全性；（http不安全，httpst比较安全）
3、端口号；（http是80端口，https是443端口）
4、证书；（http无证书认证，https是有证书认证—-CA申请证书，一般免费证书很少，因而需要一定的费用）
5、传输速度；（http速度要快一些，https速度要慢一些—-差距很小，相对于安全来讲可忽略不计）

B/S和C/S的区别

C/S构架：安装升级卸载测试
B/S架构：超链接测试，activeX控件测试，页面测试（背景字体排列），cookies测试（保存用户个人设置-密码-搜索记录等等）
优点 缺点：
C/S架构：数据处理分散在客户端。 安装升级麻烦
B/S架构：统一客户版本方便、 太依赖于网络

get和post的区别

方式: get更多的用在数据查询类的接口，post用在数据提交和编辑类的接口
入参地址: get的入参接口测试时写在url后，post的入参写在请求正文,通过request body 传递参数
安全性: get 安全性相对较低，主要是因为 get 方法是通过 url 传递参数，参数信息很容易被普通用户看到，post 安全性相对较高，但是执行效率 get 比 Post 方法高一些
数据大小限制: get 传送的数据量较小，不能大于 2KB。post 传送的数据量较大，一般被默认为不受限制。
缓存:get请求，会被浏览器缓存。post不会。

接口常见的响应状态码

100 （继续） 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其他请求;
200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
3xx （重定向）
表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。
300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
4xx（请求错误） 这些状态代码表示请求可能出错，妨碍了服务器的处理。
代码 说明
400 （错误请求） 服务器不理解请求的语法。
401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 （禁止） 服务器拒绝请求。
404 （未找到） 服务器找不到请求的网页。
405 （方法禁用） 禁用请求中指定的方法。
414 请求的URL过长
500 （服务器内部错误） 服务器遇到错误，无法完成请求。
502 网关错误
503 服务不可用
504 网关超时

带有cookie的接口怎么做

在做接口的时候，cookie一般是保留在浏览器中的header中，我做cookie接口的话，一般通过抓包工具把cookie抓出来，然后去配置执行接口。
1使用浏览器F12开发者工具抓包或使用Charles抓包，可以抓到cookie
2在发送请求的时候，将cookie直接放在信息头管理器中就可以了
3如果直接就有cookie，直接放在header中传递即可

session鉴权怎么测试

session鉴权的话，他是通过session来做鉴权的，原理是session能够保存数据，其他接口 被调用的时候会先验证session中的值是否正确，比如用户登录，会把用户的用户名密码存在 session中，其他接口要正常调用，必须要先进行登录，再调用其他接口。

cookie和session的区别

1、cookie 数据存放在客户的浏览器上，session 数据放在服务器上。
2、cookie 不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗考虑到安全应当使用 session。
3、session 会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能 ,考虑到减轻服务器性能方面，应当使用 cookie。
4、单个 cookie 保存的数据不能超过 4K，很多浏览器都限制一个站点最多保存 20 个 cookie。Session理论上无上限
5、建议：将登陆信息等重要信息存放为 session，其他信息如果需要保留，可以放在 cookie中

批量造数据的几种实现方式

1、通过批量请求创建接口的方式
●首先，获取创建数据的接口请求方式、路径和参数
●其次把请求放入到jmeter中，使用函数或者csv参数化来保证数据的不重复性（因为根据不同业务场景，用户名和手机号是不能重复的）
●最后设置线程数，和循环次数，根据要创建多少条数据自由设置，然后进行发出请求。

什么是幂等性

幂等性就是用户对同一个操作发起的一次请求，或者多次请求的结果是一致的，不会因为多次点击而产生副作用。举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条。在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等。
那么如何设计接口才能做到幂等呢？
方法一：单次支付请求，也就是直接支付了，不需要额外的数据库操作了，这个时候发起异步请求创建一个唯一的ticketId，就是门票，这张门票只能使用一次就作废，具体步骤如下：
1、异步请求获取门票
2、调用支付，传入门票
3、根据门票ID查询此次操作是否存在，如果存在则表示该操作已经执行过，直接返回结果；如果不存在，支付扣款，保存结果
4、返回结果到客户端
如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的.

同步处理和异步处理的区别和优缺点

同步处理：同步处理就是同一时间只执行一个任务，任务处理完以后在继续执行第二个任务，同步处理适用于一些顺序执行的任务。
异步处理：以用户登录为例，登录任务是在一个登录的线程中执行的，登录任务执行过程中除了验证用户名和密码是否正确外，还需要处理其他子任务，例如从服务器获取用户信息，更新本地缓存信息等。这些子任务通常会在新开辟的子线程里执行，执行登录的线程可以称主线程，执行获取用户信息的线程称为子线程，在一个登录操作过程中分别执行两个任务，这个过程就叫做异步处理。
同步的好处：
1、同步流程对结果处理通常更为简单，可以就近处理
2、同步流程对结果的处理始终和前文保持在一个上下文内
3、同步流程可以很容易捕获、处理异常
4、同步流程是最天然的控制过程顺序执行的方式
异步好处：
1、异步流程可以立即给调用方返回初步的结果
2、异步流程可以延迟给调用方最终的结果数据，在此期间可以做更多的额外工作，例如结果记录等等
3、异步流程在执行的过程中，可以释放占用的线程资源，避免阻塞等到结果产生再重新获取线程处理
4、异步流程可以等多次调用的结果出来后，再统一返回一次结果集合，提高影响效率。

水平越权和垂直越权

水平越权：相同权限下，不用的用户可以互相访问。
垂直越权：指权限低的用户可以访问权限高的用户。
水平越权测试方法：主要是看看能否通过A用户操作影响到B用户。
垂直越权测试方法：看看低权限用户是否能越权使用高权限的功能，比如普通用户可以使用管理员的功能。
越权测试：登录用户A时，正常更改或者是查看A的用户信息，然后抓取数据包，将传参ID修改为其他用户，如果成功查看或者修改了同权限其他用户信息就属于水平越权测试（如果可以影响到高权限用户就是垂直越权）。
常见平行越权：不需要输入原密码的修改密码
抓包改用户名或者用户ID修改他人密码
需要资料的时候修改用户ID
查看订单ID的时候，遍历订单ID

中间件

是一类提供系统软件和应用软件之间的连接、便于软件各部件之间的沟通的软件，应用软件可以借助中间件在不同的的技术构架之间共享信息与资源。中间件位于客户服务器操作系统之上，管理者计算资源和网络通信。
常见的WBE中间件：（tomcat/weblogic/jboss/jetty/webshere/glasshfish）

并发出现问题怎么优化

并发主要是因为多个线程在多个cpu上执行，此时cup之间的缓存并不可见，从磁盘或内存获取数据后，此时如果内存和磁盘的数据被更新了，cpu并不会发现，这个时候出现了平时经常说的并发。
1、优化数据库。2、异步请求。

postman和jmeter的区别

首先postman与jmeter都可以做接口测试，也都可以进行接口串联，和csv接口参数化，但还是有区别的。
1postman不能直接操作数据库，但是jmeter可以通过jdbc操作数据库执行SQL语句
2postman不能做压测，jmeter可以做
3jmeter的断言和提取变量方式更丰富，postman需要通过编程来实现同样的效果难度更大。

性能测试

怎么做性能测试

之前做压测是时候，我们会有具体的测试场景，以及对应压测指标，我主要习惯使用jmeter工具来进行压测，在压测之前，我会先把具体的业务场景做到jmeter中，web端压测的时候如果不是调用现成的api接口，需要抓包，我会用F12或工具进行抓包，抓包完成之后，将包导入jmeter中就可以直接运行、为了让数据更真实，我也会使用函数助手生成数据，比如随机字符串函数，随机日期函数等等。
如果直接调用api接口的话，使用jmeter做上下游传参，csv也可以做参数化，在这些jmeter中做完之后，然后开始根据性能指标设置线程组，添加聚合报告。开始执行压测脚本，压测过程中，我会使用htop命令或top监控服务区运行状态，主要就是查看CPU MEM内存以及磁盘IO使用情况进行监控。
压测完成后，查看对应的聚合报告并且截图，以及服务器状态截图，发给开发人员。如果压测不达标，会让开发进行一轮程序优化做性能调优，调优完成之后会再次执行压测最后出一份测试报告。

你做压测的指标一般有哪些

我做的一般的指标就是吞吐量，平均响应时间，异常率，cpu内存使用率，磁盘使用率
场景的话，一般是模拟2000-5000用户同时操作，平均响应时间维持在2秒左右，异常率不能超过1%（1%-5%都可以），cpu使用率以及内存使用率不能超过30%，磁盘使用率不能超过20%，网络带宽占用率不能超过30%，然后线程组配置的话，一般线程数设置2000，循环次数100，一共200000个请求。
以上配置完成后，在添加聚合报告再执行，我就是负责根据指标执行的，不负责性能优化，我做的比较简单。

如何找到系统的性能瓶颈

首先保证压测及其稳定，配置也够用，以及网络情况，我们公司的压测机网络宽带1000M（128兆每秒下载，大概是5兆到25兆每秒的上传），四核cpu 3.51Gz，内存32G，磁盘500G固态。
我做的话，一般会有一个基准值，比如100并发，并发时间5分钟，然后的话我会根据这基准值，并发数每隔50个进行递增，递增的时候观察聚合报告，比如100并发，并发5分钟，发送样本数为10000个，系统运行良好，接口性能在压测标准内，那么我会增加50的并发，当150并发的时候，也并发5分钟，如果系统没有达到瓶颈，那么发送的样本数会增加。
这时候我会持续加压，一直加到服务器的卡顿，异常率开始突然间开始增高为止，响应时间增加。主要就是持续增压，观察异常率的方式找到大概的性能瓶颈。

定时器

固定定时器：设置延迟时间，比如设置3000ms，发送请求以后，三秒后会有响应
同步定时器：一种请求全部响应完成以后，会进行下一个请求，一个商品券有五件，七个人去抢，不添加同步定时器，响应结果是一个登录一个秒杀，加了之后，响应结果是先登录后秒杀
随机定时器：设置延迟3000ms，偏移500ms，会在500-3500ms之间随机等待
吞吐量定时器：防止吞吐量过高，导致系统崩溃，设置个最高阈值，达到这个吞吐量后不再增加

TCP三次握手和四次挥手

三次握手是指的是创建连接的过程：
1首先客户端向服务器端发送一个请求，询问是否可以发送数据
2服务器端收到请求之后，如果同意会响应一个确认报文
3客户端收到确认报文之后，就开始发送数据
四次挥手指的是：
1第一次挥手：”我客户端没有数据要发给你了”，但是如果你服务器还有数据没有发送完成，则不必急着关闭连接，可以继续发送数据。
2第二次挥手：告诉客户端，你的请求我收到了，但是我还没有准备好，请继续你等我的消息。
3第三次挥手：当服务器确定数据已发送完成，告诉客户端，好了，我这边数据发完了，准备好关闭连接了。
4第四次挥手：但是他还是不相信网络，怕服务器端不知道要关闭，他会等待一段时间，则证明服务器端已经正常关闭，那好，我客户端也可以关闭连接了，最终完成四次挥手。

渗透性测试怎么测

渗透测试是一项在计算机系统上进行的授权模拟攻击，旨在对其安全性进行评估。渗透测试人员使用与攻击者相同的工具、技术和流程，来查找和展示系统弱点对业务带来的影响。
渗透测试通常会模拟各种可能威胁您业务的攻击。渗透测试可以检查系统是否足够稳定，能否抵抗来自经过认证和未经认证的攻击，以及一系列系统角色发起的攻击。在合适的范围内，针对您需要评估的系统的任何方面，渗透测试都可以深入其中。

你还有什么想问的吗？ 大概2个左右差不多了 从自身利益出发

1、方便问下咱们面试有几轮吗
2、请问下咱们这边迭代周期是多久呢 一般是几点发布迭代
3、平时加班的话是算调休吗？如果回答是 可以问几点后开始算呢
4、对于这个岗位的话薪资涨幅是怎么样的
5、咱们这边测试一般都用什么工具居多
6、对于项目这块的话，贵公司主要涉及哪些类型的
7、对于前面面试有回答不上的 可以这个时候问下 比如想请教下面试官刚才这个RT是什么意思

Python相关问题

遍历

所谓遍历，是指沿着某条搜索路线，依次对树中每个结点均做一次且仅做一次访问。访问结点所做的操作依赖于具体的应用问题。 遍历是二叉树上最重要的运算之一，是二叉树上进行其它运算之基础。
比如在程序中你要把它遍历一边 就相当于给全部循环 比如你写个程序 给每个数加1 ，然后给的数是1,2,3,4,5， 就等于第一次程序循环先给1加1，然后再循环回来给2加1，再循环回来给3加1，树的节点相当于字典中的目录。根节点就是最大的目录，子节点是在根节点中的可以有多个

python中的六大数据类型

●不可变数据（3 个）：Number（数字）、String（字符串）、Tuple（元组）；
●可变数据（3 个）：List（列表）、Dictionary（字典）、Set（集合）。

列表和元祖的区别

1定义的方式不同：列表是用[ ] ，元祖使用（ ）；
2列表的数据可以进行修改，但是元祖定义好的数据不能修改；
3相同的地方：
a都可以通过索引值来访问里面的数据。

字典和集合的区别

1集合的类型是set，字典的类型是dict；
2集合都是以值的形式保存，集合中的数值无序，并且会自动去重；
3字典的值是以key(键)：value(值)对的形式来保存。字典的key是不重复的；
4访问字典的值是以[key]来访问。

元祖和集合的区别

●元祖
a可以包含任何数据类型；
b元祖数据不可以修改、添加、删除；
c有序。
●集合
a集合的元素会自动去重；
b无序
c集合里面可以有元祖，不能有列表和集合。
9