测试面试题1、v模型：是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件测试的V模型。 2、w模型：

V模型和W模型有什么区别以及优缺点

一、指代不同

1、v模型：是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件测试的V模型。 2、w模型：由两个V字型模型组成，分别代表测试与开发过程。

二、特点不同

1、v模型：仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

2、w模型：测试的活动与软件开发同步进行，测试的对象不仅仅是程序，还包括需求和设计，尽早发现软件缺陷可降低软件开发的成本。

三、适用不同

1、v模型：是一种传统软件开发模型，适用于一些传统信息系统应用的开发。

2、w模型：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求文档的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

V模型的优缺点：

1、优点：包含了底层测试（单元测试）和高层测试（系统测试）；清楚的标识了开发和测试的各个阶段；自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。

2、缺点：自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改；实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低。改良：每个步骤都可以进行小的迭代工作。

W模型的优缺点：

优点：

　　开发伴随着整个开发周期，需求和设计同样要测试；更早的介入测试，可以发现初期的缺陷，修复成本低；分阶段工作，方便项目整体管理。

缺点：

　　开发和测试依然是线性的关系，需求的变更和调整，依然不方便；如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！

H模型的优点：

　　开发的H模型揭示了软件测试除测试执行外，还有很多工作；软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

H模型的缺点：

　　管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。

总结：

　　v模型适用于中小企业；

　　w模型适用于中大型企业（因为人员要求高）；

　　h模型人员要求非常高，很少有公司使用。

Charles抓包原理

1.客户端向服务器发起HTTPS请求

2.Charles拦截客户端的请求，伪装成客户端向服务器进行请求

3.服务器向“客户端”（实际上是Charles）返回服务器的CA证书

4.Charles拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端。

5.客户端接收到“服务器”（实际上是Charles）的证书后，生成一个对称，用Charles的公钥加密，发送给“服务器”（Charles）

6.Charles拦截客户端的响应，用自己的私钥解密对称(Charles拿到了对称)，然后用服务器证书公钥加密，发送给服务器。

7.服务器用自己的私钥解密对称，向“客户端”（Charles）发送响应

8.Charles拦截服务器的响应，替换成自己的证书后发送给客户端

9.至此，连接建立，Charles拿到了服务器证书的公钥和客户端与服务器协商的对称**，之后就可以解密或者修改加密的报文了。

修改request请求参数值

在接口处鼠标右击选择breakpoints(断言)
点击proxy(代理)选择Breakpoint settings(设置断点)
点击钻到的接口修改query(参数)为* request勾选输完值点击ok保存变量
重新请求接口 edit request(编辑要求) 在 channelID(通道) 点击具体值修改添加或删除
关掉 break point(断点) 点击 abort(终止) 修改返回值 response
选中接口右击选择break points(断点)
点击proxy(代理)选择break points settings (设置断点)
点击接口修改query(参数)为* request勾选点击ok保存
重新请求接口点击edit request 返回值所有的字符都可以修改
刷新页面请求接口点击abort(终止)修改返回值 request
复制response内容保存为TXT文件存放到本地编码的格式为'utf-8' 否则可能会出现乱码
接口返回值右击选择 save response 后选择response
选中需要修改的response值的接口后右击选择maplocal功能 query(参数)修改为 * (map to 下 local path 填TXT文件的绝对路径)
修改TXT文件中需要修改的字段值
重新请求此接口
完毕后点击 tools(工具) 点击 map local 取消勾选的 enable map local

弱网测试
1. 点击proxy(代理) 选择 throttle settings(节流阀调整) 勾选 enable throttling(使用节流阀) 修改宽带: 上限值下限值带宽的利用率:上限值下限值数据传输往返延迟时间值最大传输字节量可靠性网速不稳定性的占比等点击ok保存
2. 打开throt setting 版本3.0是红旗 4.0的是乌龟
断点调试

1.通过抓取调试的接口，设置断点（右键breakpoints）然后添加断点信息（在proxy中的breakpoints setting），要设置断点的接信息，并勾选request选择框，刷新接口，即可在charles中修改edit request值

模拟 404/403 返回值
点击tools(工具)选择blacklist(黑名单)
允许启动黑名单功能选择接口返回值的形式添加接口地址并保存
选中需要返回404/403的接口点击ok再次请求屏蔽web网页的抓包信息点击proxy(代理) 选中或取消 Windows proxy macOS proxy抓包结果列表只展示关注的接口
点击view 选择focused hosts
点击 add 添加协议域名端口号
将关注的接口勾选点击 ok 保存
重新抓包

https抓包
点击help(帮助) 选择SSL Proxying 点击 install Chales root
移动端下载证书
点击 proxy 选择 ssl proxying setting 添加主机为* (所有) 端口号点击 ok 保存
勾选添加的接口勾选 Enable ssl proxying 点击 ok

接口压力测试
选择需要进行测试的接口右键选中repeat advance(重复之前)
填写迭代次数每次迭代的并发量每次迭代中多个请求之间的间隔时间和每次迭代之间的间隔时间 3.勾选 use ranges (使用间隔时间区间) 点击ok

Jmeter

对数据库的操作
下载jmeter连接数据库的jar包在测试计划添加数据库连接jar包
右键添加 --> 线程 --> 线程组
右键新建线程组 --> 添加 --> 配置元件 --> JDBC connection configuration (连接配置)
在variable name(变量名)输入要连接的数据库
在databese URL 输入adb.mysql://端口号/库名?allowMulti Queries = true(允许执行多条sql语句)&character Encoding = utf-8(解决乱码)数据库用户名/密码
添加JDBC request 线程组右键 --> 添加 --> sampler --> JDBC request
在variable name(变量名) 输入与JDBC connection configuration (连接配置)同样的数据库名
在SQL query(SQL查询)中输入要查询的SQL语句
添加查看结果树
点击运行按钮

固定定时器

线程组 --> 添加 --> 定时器 --> 固定定时器 --> 设置线程 --> 延迟(毫秒)

循环控制器

右键线程组 --> 添加 --> 逻辑控制器 --> 循环控制器 --> 设置循环次数

获取 Token 值
右键线程组 --> 添加 --> 取样器 --> HTTP请求 --> 输入 --> 协议 --> 服务器名称或IP端口 --> 请求方式 --> 路径 --> 编码 --> 根据需求

文档传参
右键HTTP请求 --> 添加 --> 后置处理器 --> 正则表达式提取器 --> 输入引用名称--> 正则表达式 Token(.*?) --> 模板 $1$ --> 匹配数字
右键HTTP请求 --> 添加 --> 配置元件 --> HTTP信息管理器填入相关参数
添加查看结果树点击运行查看结果

参数化关联用户自定义变量
右键 --> 添加 --> 线程 --> 线程组
右键线程组 --> 添加 --> 取样器 --> HTTP请求
右键线程组 --> 添加 --> 配置元件 --> 用户定义变量 --> 添加 --> 写入名称与值
点击HTTP请求 --> 引用用户定义的变量(格式为${变量名})
右键线程组 --> 添加 --> 监听器 --> 查看结果树
运行查看结果

参数化关联 CSV文件参数化
创建CSV文件写入相关数据多条数据用,(逗号)隔开
右键线程组 --> 添加 --> 配置元件 --> CSV set confing --> 填入filename:保存信息文件的相对或绝对路径编码变量名 CSV文件中各列名字用逗号隔开
找到需要传参的HTTP请求将具体值改为变量引用 ${变量名}
添加查看结果树
运行查看结果

性能测试
右键添加线程线程组设置线程数用时循环次数
右键线程组添加取样器 HTTP请求设置协议服务器名称或IP端口号请求方式路径内容编码
右键线程组添加监听器查看结果树聚合报告图形结果表格查看结果......
运行查看结果

性能测试关注点如何实现定位的

1.并发数、平均响应时间，错误率，吞吐量，cpu，内存 2.正则匹配，第一个接口返回的结果可能是第二个接口请求的参数csv数据文件设置，函数助手可以做批量数据测试

断言
右键添加线程线程组
右键线程组添加取样器 HTTP请求
右键HTTP请求添加断言响应断言设置测试字段模式匹配规则.....点击添加输入匹配内容......
右键线程组添加监听器断言结果查看结果树
运行查看结果

脚本录制
创建一个Thread Group (邮件点击： Test Plan -> Add -> Thread Group)
创建http 代理服务器（邮件点击"工作台"（WorkBench） Add-> Non-Test Elements -> HTTP(S) Test Script Recorder）
设置浏览器的代理服务器
设置好后在浏览器中访问网站
Jmeter就能录制下来了

jmeter性能测试报告
性能测试背景
性能测试目标
性能测试范围
性能名词术语约定
被测环境系统架构
被测环境软硬件配置：主机数量用途配置系统
负载机软硬件配置
测试数据
硬件性能指标
测试进度开始时间结束时间测试类别测试目的测试结果测试报告测试分析等.... 测试用例

测试用例特征: 正确性完整性准确清晰简洁可维护性适应性可重复性可追溯性可移植性

测试用例特性: 代表性: 能够代表并覆盖各种合理的和不合理合法不合法边界和越界的以及极限的输入数据操作等...... 针对性:对程序中可能存在的错误有针对性的测试可判断性:测试执行结果的正确性是可判定的每一个测试用例都应有相应的期待结果可重现性:对同样的测试用例系统的执行结构应当是相同的

测试评审的标准
测试用例的正确性 (测试用例不含有争议)
测试用例是否冗余
测试用例的覆盖率
测试用例是否满足需求文档评审的内容有以下几个方面
用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
优先极安排是否合理。
是否覆盖测试需求上的所有功能点。
用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确_期待结果是否有明显的验证方法。
是否已经删除了冗余的用例。
是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在"保护"20%的功能实现。
是否从用户层面来设计用户使用场景和使用流程的测试用例。
是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤

组成部分

测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等

测试用例模板

用例编号所属模块用例标题优先级前提条件操作步骤测试数据预期结果预期结果

接口测试用例模板

用例标识标题模块优先级描述前置条件请求类型请求参数类型操作步骤预期结果

缺陷报告模板

缺陷编号用例编号缺陷类型严重级别优先级缺陷状态测试阶段可重现性 bug原因缺陷描述预期结果实际结果重现步骤测试环境

在公司发现问题如何定位

查看报错日志查看数据库的数据查看缓存（如Memcache、apc、redis等缓存）是否正确

性能测试指标:

系统指标: 响应时间 258 吞吐量 TPS 并发数点击率资源使用率: CPU使用率 75% 内存使用率 80% 磁盘吞吐率 80% 网络吞吐率 80%

测试报告

组成部分

· 首页 · 引言（目的、背景、缩略语、参考文献） · 测试概要(测试方法、范围、测试环境、工具) · 测试结果与缺陷分析（功能、性能） · 测试结论与建议（项目概况、测试时间测试情况、结论性能汇总） · 附录（缺陷统计）

性能测试报告

1、项目描述 描述项目的背景，以及压测的目的。

2、性能指标和业务模型 列举本次性能测试所有接口的目标TPS。如果测试多个接口，需要写明各个接口的业务比例。

3、测试人员 列举本次测试项目都有哪些人组成，各自担任什么职责。

4、测试环境配置 列出压测时的网络环境拓扑图，以及本次测试涉及到的所有服务器的软硬件资源配置，包括压力机、应用服务器、数据库服务器等。如果与生产环境有差异，一定要做出说明本次测试是基于什么配置测试出来的。

5、测试数据规模 本次测试都准备了多少数据，比如用户数据、商品数据等，以及数据根据什么规则产生。

6、测试结果分析 详细记录每个测试场景的最终结果，如tps、平均响应时间、top响应时间、错误率等。另外还需要写出该场景对应的性能监控数据，如CPU、内存、磁盘和网络的监控数据。

7、调优说明 在压测过程中，如果项目进行了性能调优，要写明问题的原因和优化的内容，以及优化前后的性能对比。

8、结论 根据测试的实际结果和预期结果进行判断，本次性能测试是否通过。

9、建议 在压测过程中，根据测试实际结果提出的一些建议，如部署建议，中间件配置等。

缺陷报告的书写 1、尽量保证缺陷可以重现 2、简洁、准确、完整 3、一个缺陷报告只写一个缺陷

缺陷书写规范 1、标题简洁、提供缺陷的本质信息即可 2、复现的步骤要详细，应包含如何使别人能够很容易的复现该缺陷的完整步骤。用数字编码。 3、实际结果要描述清楚，及错误的结果。 4、列出预期结果 5、测试数据 6、提供附件 7、提供严重属性和公司需要填写的属性

压力测试

app端

功能测试：

1.业务逻辑正确性测试：依据：产品文档->测试用例编写

兼容性测试：

1.系统版本：Android:官方版本,定制版本;IOS：官方提供版本 2.分辨率：720 * 1280 1080* 1920 3.网络情况:2g 3g 4g 5g Wi-Fi

异常测试

1.热启动应用:应用在后台长时间待机;应用在后台待机过程中，手机重启 2.网络切换和中断恢复:网络切换;中断恢复： 3.电话信息中断恢复升级，安装，卸载测试 1.升级测试：临近版本升级(1.0->1.1);跨版本(1.0->....->2.2) 2.安装测试：首次安装;覆盖安装(同版本，不同版本覆盖);卸载后安装 3.卸载测试：首次卸载;卸载安装后在卸载健壮性测试 1.手机资源消耗：cpu，内存 2.流量消耗：图片，数据，视频 3.电量测试 4.崩溃恢复

mysql

左关联和右关联的区别

左关接是已左边表中的数据为基准，若左表有数据右表没有数据，则显示左表中的数据右表中的数据显示为空。右关联相反

左连接：只要左边表中有记录，数据就能检索出来，而右边有的记录必要在左边表中有的记录才能被检索出来。右连接：右连接是只要右边表中有记录，数据就能检索出来。

增删改查

增 : insert into 表名(字段名,...) value (值,.....)

删: delete from 表名 where 条件 (删除记录)

delete from 表名 (删除所有记录)
drop 表名 (删除表)

改: update 表名 set 字段=值 where 条件 (有条件则修改符合条件的无则是全部)

查: select * from 表名 (显示所有字段)

select * from 表名 where 条件 
关系运算符:= != > < <= >= 
select * from 表名 where 字段名 (not)in (元素,...) (不在 或 在)
select * from 表名 where 字段名 (not)between 值1 and 值2(不在...里 或 在...里)
select * from from 表名 where 字段名 is(not) null   (是否为空)
select distinct 字段名 from 表名  (去重)
select * from 表名 where 字段名 (not)like '匹配字符串'   (关键字查询)
select * from 表名 where like 'a%'   (模糊查询) 
select * from 表名 where 条件1 and 条件2 ......   (多条件精准查询)
select * from 表名 where 条件1 or 条件2    (或查询)

高级查询

聚合函数

count()记录总条数

select count(*) from 表名

sum()所有值的总和

select sum(字段名) from 表名

AVG()平均值

select AVG(字段名) from 表名

max()最大值

select max(字段名) from 表名

min()最小值

select min(字段名) from 表名

排序

select 字段,... from 表名 order by 字段 asc (升序)

select 字段,... from 表名 order by 字段 desc (降序)

分组

select 字段,.. from 表名 group by 字段,...

select sum(字段名) from 表名 group by 字段名 having sum(字段名) < 10 (查询某字段总和小于10的)

分页

select * from 表名 limit 0,2 (每页显示2个,第一个页面)

连接查询

inner join ... on 等值连接 left join ... on 左连接 right join ... on 右连接 select 表A.字段1,表B.字段1 from 表A [inner | left | right] join 表B on 表A.字段2 = 表B.字段2

子查询

select * from 表A where 字段1 > (select AVG(字段) from 表B)

约束

int unsigned 无符号整形

auto_increment 表示自动增长

not null 表示不能为空

primary key 表示主键

default 默认值

外键

建表时: foreign key(a_id) references 表B(id)

取消外键约束: show create table 表名 (获取名称之后根据名称删除)

添加外键约束: alter table 要连接表名 add foreign key (a_id) references 被连接的表名(id)

bug 的生命周期

一个Bug由测试人员发现并提交,我们将状态标注为新建;开发人员接收了该 Bug,将Bug的状态修改为已分配(Assigned),表示已经认可;开发人员解决了该 Bug后,就将Bug的状态修改为解决,并发给测试人员回归测试;测试人员对Bug 进行回归测试，如果确实已经解决,就将Bug的状态修改为关闭,否则的话则发给开发人员重新修改。还要说明的是,Bug是可以“死而复生”的,以前版本已经关闭的Bug,如果新版本中重新出现,我们就需要将其状态修改为重新打开。

bug 的优先级

高中低

bug的种类划分

功能错误：功能上的错误性bug
代码错误：一般很少出现，通常在自测时出现（对白盒测试、自测的比较适合）
内容相关：业务逻辑方面以及业务描述等相关问题
表单相关：表单逻辑、样式、内容问题
用户界面：UI表现，包括对话框样式和文字描述问题
需求变动：原有的需求基础上的更改
新增需求：会议上提出的新需求，非正式会议提出的不属于该项
设计文档：数据库设计文档、概要/详细设计文档
建议：功能已满足但待改善，属于改良性建议
配置相关：如web服务器或者数据库服务器配置等问题
安装部署：项目部署时出现的错误，可能不是程序本身的问题而是工具本身和人为因素引起
安全相关：加密和水印等安全信息
性能压力：负载、压力测试
标准规范：根据国际标准或者公司内部制定的某标准
测试脚本：如用工具LR编写并执行脚本进行测试

如果在测试过程中出现的BUG 而开发人员不认为是BUG的时候你怎么办???

1.首先我会从自身去经过多次的测试发现BUG出现的次数和频率记录复现BUG的方式然后发送给开发人员 2.再根据需求文档来确认是否为BUG 3.如果开发不认为是BUG的将复现BUG的记录和需求文档找产品经理和项目经理来确定是否BUG 4.如果项目经理和产品经理都不认为是BUG 我会将BUG记录在测试文档中方便在下次评审会上将问题再次抛出

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

前台的bug通常是功能、界面和兼容性等有关；后台的bug与逻辑、性能和与数据相关的错误、排序安全性有关。

Bug不能复现怎么办?

首先考虑环境问题，看是否能够还原原来的环境
遇到问题就要提，不能放过任何一个Bug，在提交的Bug描述中加上一句话，那就是复现概率，尝试20次，出现一次或尝试10次，交给开发，开发会根据Bug的复现概率，调整改Bug的优先级。
尽量回想发生问题时的复现步骤，不要漏掉任何一个细节，按照步骤的组合尝试复现
与开发人员配合，让开发人员对相应的代码检查，看是否通过代码层面检查出问题也许是代码变更，引起的Bug
保留发生bug时的log，附加到提交的Bug中，希望可以通过log中找到一些蛛丝马迹。

上线之后复现的bug如何解决

1、测试人员复现问题后，提交问题单进行跟踪； 2、评估该问题的严重程度，以及修复问题时和影响范围，回归测试需要测试哪些功能 3、问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试； 4、总结经验，分析问题发生的原因，避免下次出现同样问题

adb命令

查看当前连接设备： adb devices
查看日志：adb logcat
安装apk文件：adb install -r (apk的绝对路径)
卸载App: adb uninstall 包名 adb uninstall -k 包名 (保存配置及缓存文件)
列出所有的包名: adb shell pm list package
列出第三方的包名: adb shell pm list package - 3
列出系统应用的包名: adb shell pm list package - s
查看手机内存的命令: adb shell dumpsys meminfo 包名
启动: adb start server
关闭: adb kill-server
adb logcat . 日志级别 V Verbose 最低 D Debug bug I Info 信息 W Warn 警告 E Error 错误 F Fatal 致命S Silent (supress all output)

monkey

monkey命令的启动: adb shell monkey + 命令参数
对app进行多次访问的测试: adb monkey -p (包名具体的页面) 100 访问的测试
显示日志的详细程度:
-v 启动提示及测试完成最终结果
-v -v 标为详细的日志发送到activity (页面的)的事件信息
-v -v -v 最为详细的日志测试中选中或者是没有选中的activity(信息)测试信
打印日志的命令: adb shell monkey 200 >d: / monkeylog. txt
触摸事件：--pct-touch
动作事件：--pct-motion
轨迹事件：--pct-tackball
系统按键：--pct-sykeys
基本导航：--pct-nav
主要导航：--pct-majornav
启动事件：--pct-qppswitch
指定弹窗事件：--pct-flip
指定其他事件：--pct-anyevent
指定缩放事件：--pct-pinchzoom
忽略崩溃：--ignore-crashes
忽略超时：--ignore-timeouts
忽略许可异常：--ignore-security-exeptions
延时：--throttle

Linux

切换目录

切换到该目录下usr目录：cd /usr/
切换到上一层目录：cd ../

切换到系统根目录：cd /

目录操作

查看隐藏目录：ls -a

查看目录和文件的详细信息：ls -l 或者ll

查找目录：find 目录参数 find / -name 'test*'

修改目录：mv 旧名称新名称

移动目录: mv 文件路径

拷贝目录：cp -r 文件路径

文件操作

创建文件：touch 文件名

查看文件(日志)：cat/more/less/tail/head 文件

实时/动态查看日志：tail -f 日志

修改文件：vim/vi(进入命令模式)>>>i/o/a(进入编辑模式)>>esc(提出编辑模式进入命令模式)>>> shift : 输入 wq保存并退出/q!强制退出不保存修改的数据

删除文件:rm -rf 文件名

打包或者压缩文件

打包：tar -zcvf 文件名.tar 要打包的文件

压缩: tar -zcvf 文件名.gz 要压缩的文件

打包并压缩: tar -xvf 文件名.tar.gz 要打包并压缩的文件

解压文件

解压tar包:tar -xvf 文件.tar

解压zip包:unzip 文件.zip

解压到某个目录下: tar -xvf 文件.tar -C /路径

查询文件或者目录的位置:pwd

搜索命令(多用于查日志中的错误信息)

grep 关键字(exeption) 日志名(文件名)

| 管道符：把前面的命令传到后面命令中

grep 过滤的作用

查看进程: ps -ef | grep 名称比如查看tomcat进程是否开启 ps -ef | grep tomcat

杀死进程： kill -9 pid(对应进程的pid)

查看端口信息:netstat -an |grep 端口号比如查看3306端口是否被占用 netstat -an | grep 3306

查看网络命令:ifconfig (查看ip信息)

查看网络是否联通：查看外网:ping www.baidu.com 查看内网:ping 内网ip

查看内存信息：free

查看cpu：top

查看磁盘信息: df -h

权限：chmod 777 文件名（赋权可读可写可执行）

远程连接的工具有ssh,xshell

xshell上传文件：rz(需要提前下载yum -y install lrzsz)

xshell下载文件:sz 要下载的文件名

文档权限

r：可读(4)， w: 可写(2)， x: 可执行(1), -(0): 没有权限
u: 当前用户，g：同组用户， o:其它用户， a:所有用户
权限设置： + 添加权限， - 删除权限， = 设定权限
L rwx rwx rwx 0 123 456 789
下标为0代表确定文件类型
下标为123 确定文件的所属拥有该文件的权限
下标为456 确定属性组所有有权限的用户组
下标789 其他用户拥有该文件的权限
数字法: chmod 000 1.txt 表示1.txt的所有用户都没有权限

python

python列表和元组的区别

列表是动态数组，它们可变且可以重设长度（改变其内部元素的个数）。

元组是静态数组，它们不可变，且其内部数据一旦创建便无法改变。

元组缓存于Python运行时环境，这意味着我们每次使用元组时无须访问内核去分配内存。

列表可被用于保存多个互相独立对象的数据集合

元组用于描述一个不会改不安的事务的多个属性

面向对象

面向对象编程是在面向过程编程的基础上发展来的，它比面向过程编程具有更强的灵活性和扩展性。是一种封装代码的方法

面向过程：

核心是过程二字，过程指的是解决问题的步骤，好比如设计一条流水线，是一种机械式的思维方式。

封装

隐藏对象的属性和实现细节，仅对外提供公共访问方式。

好处：

将变化隔离；
便于使用；
提高复用性；
提高安全性；

封装原则：

将不需要对外提供的内容都隐藏起来，
把属性都隐藏，提供公共方法对其访问。

什么是继承？

继承是一种创建新类的方式，在python中，新建的类可以继承一个或多个父类，父类又可称为基类或超类，新建的类称为派生类或子类。子类会“遗传”父类的属性，从而解决代码重用的问题。

多态

多态指的是一类事物有多种形态

请求头Request Headers

Accept : 指定客户端能够接收的内容类型，内容类型中的先后次序表示客户端接收的先后次序。在Ajax代码中，可以使用XMLHttpRequest 对象中setRequestHeader函数方法来动态设置这些Header信息。
Accept-Encoding : 指定客户端浏览器可以支持的web服务器返回内容压缩编码类型。表示允许服务器在将输出内容发送到客户端以前进行压缩，以节约带宽。而这里设置的就是客户端浏览器所能够支持的返回压缩格式。
Accept-Language : 指定HTTP客户端浏览器用来展示返回信息所优先选择的语言。
Connection ：表示是否需要持久连接。如果web服务器端看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点， web服务器需要在返回给客户端HTTP头信息中发送一个Content-Length（返回信息正文的长度）头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。
Connec-Length : 请求头的长度。
Connect-Type : 显示此HTTP请求提交的内容类型。一般只有post提交时才需要设置该属性。
有关Content-Type属性值可以如下两种编码类型：
“application/x-www-form-urlencoded”：表单数据向服务器提交时所采用的编码类型，默认的缺省值就是“application/x-www-form-urlencoded”。然而，在向服务器发送大量的文本、包含非ASCII字符的文本或二进制数据时这种编码方式效率很低。
“multipart/form-data”：在文件上载时，所使用的编码类型应当是“multipart/form-data”，它既可以发送文本数据，也支持二进制数据上载。
当提交为单单数据时，可以使用“application/x-www-form-urlencoded”；当提交的是文件时，就需要使用“multipart/form-data”编码类型。
在Content-Type属性当中还是指定提交内容的charset字符编码。一般不进行设置，它只是告诉web服务器post提交的数据采用的何种字符编码。
cookie : 浏览器端cookie。
Hose : 客户端地址
Origin : 目标地址
Referer : 包含一个URL，用户从该URL代表的页面出发访问当前请求的页面
User-Agent : 客户端信息
x－Requested-With : 是否为同步请求，如果为XMLHttpRequest，则为 Ajax 异步请求。如果为null则为传统同步请求

响应头

Accept-Ranges	表明服务器是否支持指定范围请求及哪种类型的分段请求
Age	从原始服务器到代理缓存形成的估算时间（以秒计，非负）
Allow	对某网络资源的有效的请求行为，不允许则返回405
Cache-Control	告诉所有的缓存机制是否可以缓存及哪种类型
Content-Encoding	web服务器支持的返回内容压缩编码类型。
Content-Language	响应体的语言
Content-Length	响应体的长度
Content-Location	请求资源可替代的备用的另一地址
Content-MD5	返回资源的MD5校验值
Content-Range	在整个返回体中本部分的字节位置
Content-Type	返回内容的MIME类型
Date	原始服务器消息发出的时间
ETag	请求变量的实体标签的当前值
Expires	响应过期的日期和时间
Last-Modified	请求资源的最后修改时间
Location	用来重定向接收方到非请求URL的位置来完成请求或标识新的资源
Pragma	包括实现特定的指令，它可应用到响应链上的任何接收方
Proxy-Authenticate	它指出认证方案和可应用到代理的该URL上的参数

冒泡排序

def bubble_sort(alist):
     """元素个数"""
     n = len(alist)
     """构造外层循环次数,外层循环一次 ,内层循环一遍"""
     for i in range(n-1):
         """比较相邻两个元素的大小,如果左侧数据大于右侧数据,则交换变量的值"""
         for j in range(n-1-i):
             """如果左侧数据大于右侧数据"""
             if alist[j] > alist[j+1]:
                 """则交换变量的值"""
                 alist[j],alist[j+1]=alist[j+1],alist[j]
 if __name__ == '__main__':
     a_list = [22,55,66,33,88,11,77,99,-56,-54,23,56]
     bubble_sort(a_list)
     print(a_list)
     [-56, -54, 11, 22, 23, 33, 55, 56, 66, 77, 88, 99]

选择排序

 def select_sort(alist): 
  n = len(alist)    
		"""外层循环,循环一次确定一个最小值"""    
		for i in range(n-1):        
			min_index = i        
			"""内层循环,循环一遍确定一个最小值位置,交换变量的值"""        
			for j in range(i+1,n):            
				if alist[j] < alist[min_index]:
		                min_index = j
					"""判断默认最小值,是否和初始值一致 如果不一致说明找到了最小值,交换变量的值"""
		if min_index != i:
			"""交换变量的值"""   				                
	      	alist[i],alist[min_index]=alist[min_index],alist[i] 
if __name__ == '__main__':
    a_list = [22,55,66,33,88,11,77,99,-56,-54,23,56]
    select_sort(a_list)    print(a_list)
[-56, -54, 11, 22, 23, 33, 55, 56, 66, 77, 88, 99]

九九乘法表

for循环

for i inrange(1,10):
	for j in renge(1,i+1):
		print('%d * %d = %2d  '% (j,i,j*i),end=' ')
	print()
whike循环
i = 1
while i <= 9:
    j = 1
    while j <= i:
        print("%d*%d=%-2d" % (j,i, j*i),end=" ")
        j += 1
    print()
    i += 1

三角形

for循环

#### 三角形

##### for循环

自动化测试框架有哪些

Appium AppUI自动化测试
Selenium WebUI自动化测试
Jmeter 接口测试，性能测试
Postman 接口测试
Soapui 接口测试
Monkey 稳定性测试
Robot WebUI自动化测试，接口测试
QTP WebUI自动化测试
Locust 性能测试
Loadrunner 性能测试
GT App性能测试
Appscan 安全测试

UI

用户界面(User Interface)是指对软件的人机交互、操作逻辑、界面美观的整体设计。好的UI设计不仅是让软件变得有个性有品味，还要让软件的操作变得舒适、简单、自由、充分体现软件的定位和特点。

微信发红包测试点

1、功能测试

1）发给单个好友 ①　正确的金额+无留言+无表情 ②　错误的金额+无留言+无表情 ③　正确的金额+有留言+无表情 ④　错误的金额+有留言+无表情 ⑤　正确的金额+无留言+有表情 ⑥　错误的金额+无留言+有表情 ⑦　正确的金额+有留言+有表情 ⑧　错误的金额+有留言+有表情其中，金额（0.01-200）可以测试以下数据数字：测试0, 0.009, 0.01，0.011, 01， 199.99, 200, 200.01这些边界值中文、英文、特殊字符或者这几种的组合是否支持复制黏贴为空/包含空格金额的增删查改留言可以测试以下数据数字、中文、英文、特殊字符、表情或者他们的组合输入超长文本时，是否会给出相应的限制或提示包含空格是否支持复制黏贴留言的增删查改表情可以测试以下数据选择收藏的表情测试（动图/静图）选择下载的表情测试（动图/静图）录制表情，并添加进行测试表情的增删查改 ⑨　点击塞钱进红包，选择零钱付款，此时需要考虑金额＞零钱，金额＜零钱，金额=零钱三种情况 ⑩　点击塞钱进红包，选择已添加的银行卡付款，此时同样需要考虑金额＞银行卡余额，金额＜银行卡余额，金额=银行卡余额三种情况 ⑪　点击塞钱进红包，选择使用新卡付款，按照流程添加新卡，此时同样需要考虑金额＞新卡余额，金额＜新卡余额，金额=新卡余额三种情况 ⑫　使用指纹确认付款（正确的/不正确的指纹） ⑬　使用密码确认付款（正确的/不正确的密码） ⑭　发送成功之后，对应的途径会减少相应的金额 ⑮　发送者/接受者可以点击红包查看到红包的具体信息，且金额，留言，表情均能正确显示 ⑯　好友点击红包之后，零钱中将增加相应的金额，再次点击之后，只能查看到红包的信息 ⑰　24小时之内没有领取的红包，将退回原账户，此时原账户的零钱将增加相应金额的金钱。24小时后好友点击红包，显示红包已过期，无法查看到红包的余额 ⑱　右上角的红包记录中，可以查看刚刚发出的红包的金额 ⑲　检测帮助中心中链接是否均可以正常跳转，查看 20 当红包超过24小时之后，则无法查看红包被每个人领取的详细信息 2）发送群红包（与发给好友的测试点相似，以下仅写出不同的部分） ①　选择为拼手气红包时，群中每个人收到的金额随机（但加起来为红包的总金额），为普通红包时，群中每个人收到的金额相同 ②　红包个数（1-100）：0，1，2，大于群成员人数，小于群成员人数，等于群成员人数，99，100，101，小数，中文、英文、特殊字符、表情或者他们的组合 ③　但红包没有被抢完时，此时首次点击该红包的人可以抢到一定金额的红包，不是首次点击该红包的人只能查看该红包的信息；当红包抢完时，所有人只能查看该红包的信息。 ④　在24小时之内红包的金额被完全抢完，且此时为拼手气红包时，金额最多的人会显示为最佳手气（若有两个人取得红包的最大值时，则只有一个人会显示为最佳手气）；若没有被完全抢完，则没有最佳手气，且余额会退还到原账户 ⑤　群中所有人均可以抢红包（包括自己），每个人最多只有一次抢该红包的机会 ⑥　测试当红包个数使得每个红包分到钱小于0.01，即总金额为0.02，而红包个数为3时的情况

2、兼容性测试

1）苹果手机和安卓手机 2）苹果手机的不同版本 3）安卓手机不同的机型 4）不同分辨率

3、性能测试

1）打开红包的响应时间不能超过三秒，高并发场景下不能超过5秒 2）耗电量 3）消耗流量的多少 4）所占内存

4、UI测试&易用性测试

1）界面的设计风格是否统一 2）界面中文字是否简洁，没有错别字 3）是否易操作，易学习，易理解 5、中断测试：前后台切换，网络异常，低电量，断电，来电，短信等 6、网络测试 1）网络兼容性：2g/3g/4g，WiFi，热点，移动/联通/电信 2）无网测试 3）弱网：延时&丢包

linux部署环境

安装jdk，tomcat（配置环境） 1:从公司的工具库中拿到jdk.tar，tomcat.tar包 2：通过远程连接工具(ssh/xshell)连接Linux服务器，将jdk和tomcat上传到服务器上 3：首先解压jdk.tar包（tar -xvf）,将解压的之后的jdk路径填写在配置文件中 4：重启配置文件 5：通过Java -version 判断是否安装成功，安装成功则显示jdk的版本信息(1.8.0的版本) 6：jdk配置成功之后，接下来解压tomcat.tar包(tar -xvf ) 7:开放8080端口 8：在tomcat中的bin目录在，启动(./startup.sh) 9：在游览器中输入ip:8080,可以检验tomcat是否成功启动(如果tomcat没有启动，可以通过ps -ef | grep tomcat 查看tomcat进程是否开启，如果没有开启，，再次执行启动tomcat命令)

项目部署（web端项目）

1:将开发的压缩包(.tar),解压之后，放到tomcat中的webapps目录下，重启tomcat(./startup.sh) 2:在游览器中输入ip:8080/解压后名称，查看项目

安装MySQL

1:从公司的工具库中拿到mysql.tar包 2：通过远程连接工具(ssh/xshell)连接Linux服务器，将mysql压缩包上传到服务器上 3：解压mysql.tar包（tar -xvf ） 4:解压后的rpm文件,分别进行客户端和服务端的安装(rpm -ivh) 5：启动mysql（service mysql start） 6:将mysql加到系统服务中并设置开机启动 7:登录mysql(msyql –u root -p) 8:修改密码(set password = password('xxx');) 9:需要设置开启远程登录mysql的权限 10:开放Linux的对外访问的端口3306 11:通过连接MySQL工具（navicat）直接访问

get和post区别

1.get是获取参数，post是提交数据 2.get的参数是但在url中的，用户可以直接看到，post的参数是放在请求踢中的，用户看不到，post比get安全 3.get传达的数据量较小，一般被默认为不受限制 4.get执行率比post方法好，get是form提交的默认方法

http和https的区别

1.http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输 2.端口不同，http协议，使用的端口是80，https协议。使用端口是443 3.证书申请方式不同，http协议，免费申请，https协议，需要到ca申请证书，一般免费证书很少，需要交费

http1.0和http1.1和http2.0有什么区别

1.1 长连接(Persistent Connection) HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启长连接keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。

1.2 节约带宽 HTTP1.0中存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。

1.3错误通知的管理在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

2.1 多路复用 HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。

2.2 头部数据压缩在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。

HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

常见的状态码有哪些

	类别	原因短语
1xx	Informational（信息性状态码）	接受的请求正在处理
2xx	Success（成功状态码）	请求正常处理完毕
3xx	Redirection（重定向）	需要进行附加操作以完成请求
4xx	Client error（客户端错误）	客户端请求出错，服务器无法处理请求
5xx	Server Error（服务器错误）	服务器处理请求出错

100：这个状态码是告诉客户端应该继续发送请求，这个临时响应是用来通知客户端的，部分的请求服务器已经接受，但是客户端应继续发送求请求的剩余部分，如果请求已经完成，就忽略这个响应，而且服务器会在请求完成后向客户发送一个最终的结果 200：这个是最常见的http状态码，表示服务器已经成功接受请求，并将返回客户端所请求的最终结果 202：表示服务器已经接受了请求，但是还没有处理，而且这个请求最终会不会处理还不确定 204：服务器成功处理了请求，但没有返回任何实体内容，可能会返回新的头部元信息 301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；

302 Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；

   301与302的区别：前者是永久移动，后者是临时移动（之后可能还会更改URL）

303 See Other：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；

  302与303的区别：后者明确表示客户端应当采用GET方式获取资源

304 Not Modified：表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回改状态码；

307 Temporary Redirect：临时重定向，与303有着相同的含义，307会遵照浏览器标准不会从POST变成GET；（不同浏览器可能会出现不同的情况）； 400 Bad Request：表示请求报文中存在语法错误；

401 Unauthorized：未经许可，需要通过HTTP认证；

403 Forbidden：服务器拒绝该次访问（访问权限出现问题）

404 Not Found：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用； 500：服务器遇到未知的错误，导致无法完成客户端当前的请求。 503：服务器由于临时的服务器过载或者是维护，无法解决当前的请求

编写测试用例的方法

1 测试用例的概念

测试用例是为了实施测试而向被测试系统提供的一组集合，这组集合包括：测试环境、操作步骤、测试数据、预期结果等要素

2 常见编写测试用例的七种方法

基于需求的设计方法等价类边界值因果图场景设计法错误猜测法

3 基于需求的设计方法

定义：依据看客户需求设计测试用例，但是在设计的过程中一定要辩证的看待需求（即：需求不一定都是正确的）

4 等价类法

（1）定义：依据需求将输入划分为若干等价类，从等价类中选定一个测试用例，如果该测试用例通过，则表明整个等价类通过测试。（2）适用场景：对于等价类这个方法，一般适用于有无限多种输入，我们不可能完成穷举测试，等价类可以使我们用较少的测试用例尽可能多的将功能覆盖。（3）有效等价类和无效等价类一般划分为：有效等价类、无效等价类有效等价类：有意义的输入构成的集合，对于需求规格说明书是合法的；无效等价类：不满足需求的集合。

5 边界值法

（1）定义：边界值法是对输入数据的边界测试，是一种黑盒测试方法；一般来说边界值法是对等价类划分后的补充（2）例：对于设定密码的测试，要求密码必须为6-15位分析过程：有效等价类为>=6 && <=15 无效等价类为：<6 || >15 设定边界值：5、6、10、15、16

边界值选定解释：

A. 6和15作为有效等价类中的内容，又是边界值，可以判定有效等价类的内容是否满足要求 B. 但是6和15又很特殊，它不仅代表了有效等价类，还代表了边界值，所以我们选定一个普通的有效等价类作为一个测试用例，如：10 C. 5和16作为无效等价类中的内容，又是边界值（比4或者17更具有代表性），可以判定无效等价类的内容

6 因果图

（1）定义：因果图是一种简化的逻辑图，能够表示输入条件和输出结果之间的关系。（2）认识因果图的表示方法：恒等、与、或、非一般在使用因果图编写测试用例的时候，因果图不一定能把所有的情况含括进去，所以在因果图之后，我们可以通过画判定表来确定最终的测试用例。

7 正交排列

（1）定义：正交法的目的使为了减少用例的数量，用尽量少的测试用例覆盖输入的两两组合。（2）正交表的两条性质：A. 每一列中各数字出现的次数都一样多（不考虑顺序） B. 任何两列所构成的有序对的次数都一样多（3）两个概念： A. 因素：在一次实验中所需要考察的变量因素数：因素的个数（即，正交表中列的个数），用C表示 B. 水平：在实验范围内，因素被考察的取值（4）计算正交表的行数：C*（ T-1 ） + 1 （5）用正交排列编写测试用例的流程： A. 分析该场景下有哪些因素，因素数为多少； B. 分析该场景下有哪些水平，水平数为多少； C. 计算正交表的行数，选择合适的正交表； D. 依据正交表的两条性质，生成正交表； E. 分析正交表中的测试用例，如果有不全的情况，增补测试用例。

8 场景设计

定义：目前的大多数软件的事件触发来控制流程的，我们可通过想象事件触发时的情景形成流程，依据同一事件不同的触发顺序和结果形成事件流，再依据事件流设计测试用例。7 一般场景设计法与需求设计法结合使用，能够将多个孤立的功能联系在一起。

9 错误猜测法

定义：错误猜测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例。列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

常见的请求方式有哪些，对应的作用是什么？

（1）GET方法（获取资源）（2）POST方法（向服务器提交资源，服务器请求处理）（3）PUT方法（传输文件，例如：上传图片、上传视频）（4）DELETE方法（删除文件，按请求的url删除指定资源）（5）HEAD方法（获得报文首部，确认url是否有效，以及更新资源日期时间等）（6）OPTIONS方法（询问支持方式，告诉资源请求的方法）（7）TRACE（追踪路径）（8）CONNECT（要求用隧道协议连接代理，建立通信隧道）

B/S架构和C/S架构的区别：

b/s是浏览器和服务器端,c/s是客户端和服务器端；从更新上说，b/s只需要更新服务器端不需要更新游览器而c/s需要更新客户端和服务器端，c/s维护成本高；从处理速度上来说c/s的处理速度比b/s要快，因为游览器不处理数据只能服务器端处理，而客户端和服务器端都可以进行数据的处理；从测试上来说，都需要进行兼容性测试，c/s需要测试手机型号，手机系统的不同版本，手机的分辨率，b/s需要测试不同游览器，同游览器的不同版本以及分辨率，但是c/s有专项测试，比如中断测试，弱网测试，安装升级卸载测试等。。。。

测试计划包括哪些：

测试目标测试概要测试范围重点事项质量目标资源需求人员组织猜测策略发布提交测试进度和人员安排测试开始/完成/延迟/继续的标准风险分析

黑盒测试和白盒测试的优缺点：

黑盒测试的优点有：

　 1) 比较简单，不需要了解程序的内部的代码及实现

2) 与软件的内部实现无关

3) 从用户的角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题

4) 基于软件开发文档，所以也能知道软件实现了文档中的哪些功能

5) 在做软件自动化测试时较为方便

缺点：

　　　1) 不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%

2) 自动化测试的复用性较低。

白盒测试的优点有 :

　　　1) 帮助软件测试人员增大代码的覆盖率。提供代码的质量，发现代码中隐藏的问题

缺点：

　　　1) 程序运行会有很多不同的路径，不可能测试所有的运行路径

2) 测试基于代码，只能测试开发人员做的对不对，而不能知道设计是否正确，可能会漏掉一些功能需求

3) 系统庞大时，测试开销会非常大。

alpha测试和beta测试的区别是什么：

1、测试时间不同：

Beta测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段。

alpha测试简称“α测试”，可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

2、测试的目的不同：

α测试的目的是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和支持）。尤其注重产品的界面和特色。α测试即为非正式验收测试。

Beta测试是一种验收测试，通过了验收测试，产品就会进入发布阶段。

3、测试人员及场所不同：

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，α测试不能由程序员或测试员完成。α测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。

Beta测试由软件的最终用户们在一个或多个客户场所进行。开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。

印象中最深的bug：

这个bug是发现在app端的因为我最后一个项目是个阅读的app么一个版本用户在搜索图书的时候没有搜索出来对应的书籍原因是因开发人员对app进行代码优化时，在查询接口head信息中漏传一参数值导致没有测到的原因是开发人员提交测试的时候没有告知优化内容和影响范围为什么印象深刻 -因为被罚了钱

测试面试题

V模型和W模型有什么区别以及优缺点

Charles抓包原理

修改request请求参数值

弱网测试

断点调试

模拟 404/403 返回值

https抓包

接口压力测试

Jmeter

对数据库的操作

固定定时器

循环控制器

获取 Token 值

文档传参

参数化关联 用户自定义变量

参数化关联 CSV文件参数化

性能测试

性能测试关注点如何实现定位的

断言

脚本录制

jmeter性能测试报告

测试评审的标准

组成部分

测试用例模板

接口测试用例模板

缺陷报告模板

在公司发现问题如何定位

性能测试指标:

测试报告

组成部分

性能测试报告

压力测试

app端

功能测试：

兼容性测试：

异常测试

mysql

左关联和右关联的区别

增删改查

高级查询

聚合函数

排序

分组

分页

连接查询

子查询

约束

外键

bug 的生命周期

bug 的优先级

bug的种类划分

如果在测试过程中出现的BUG 而开发人员不认为是BUG的时候 你怎么办???

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

Bug不能复现怎么办?

上线之后复现的bug如何解决

adb命令

monkey

Linux

切换目录

目录操作

文件操作

打包或者压缩文件

解压文件

搜索命令(多用于查日志中的错误信息)

远程连接的工具有ssh,xshell

文档权限

python

python列表和元组的区别

面向对象

面向过程：

封装

好处：

封装原则：

什么是继承？

多态

请求头Request Headers

响应头

冒泡排序

选择排序

参数化关联用户自定义变量

如果在测试过程中出现的BUG 而开发人员不认为是BUG的时候你怎么办???

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