2021-04-15面试题

1.OSI七层模型

https://www.cnblogs.com/qishui/p/5428938.html

2.公司的测试流程

编写测试计划 — 评审测试计划 – 编写测试用例 – 评审测试用例 – 执行测试阶段（冒烟测试，系统测
试） – 分析和总结测试结果 – 完成测试

产品提出需求后，开立项会进行讨论需求制定需求文档，开发根据需求文档进行编码，测试人员需要根据需求文档进行编写测试计划，以及对应的测试用例编写，用例编写结束后，进行用例评审，开发提交代码后执行冒烟测试，冒烟测试通过后执行过程中出现bug进行提交bug，并对bug进行追踪。bug关闭后我们做测试总结，提交对应的测试 告

3.你们公司的用例评审都哪方参与了

后端 开发 产品 前端 项目经理 测试

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

功能测试的进行：首先编写测试用例，测试用例中最主要的是测试步骤和预期结果；测试人员根据测试用例执行操作步骤，然后通过眼睛和思考判断实际结果与预期结果是否相等，如果相等，测试通过；如果不相等，测试失败。

接口测试自动化，根据接口文档，到底是传get请求还是post请求，调用被测试的接口，构造相应的数据（id=1，name=zero），得到返回值，是200成功，并返回查询结果，还是10021，用户名不能为空，不管输入的参数是怎样的，我们都将得到一个结果，最终断言返回的结果是否等于预期结果，如果相等，测试通过，如果不相等，测试失败。所以，接口测试关注的是数据，只要数据正确了，功能就成功大半，剩下的无非是如何把这些数据展示在页面上。

5.测试环境是在什么系统

软件测试环境包含硬件环境和软件环境，
硬件环境主要是PC机，
软件环境包括软件运行的操作系统(主流的操作系统：windows、Linux、Unix)，数据库（Oracle、MySQL、SqlServer、DB2等）、web应用服务器（Apache、IIS、tomcat、Nginx等）和集群环境（如负载均衡）。

6.用例怎么 证覆盖全面

理解需求–>了解功能–>了解业务–>拆分功能点–>利用五大方法(等价类、因果图、边界值、错误猜测、场景法)–>从不同方向出发编写测试用例

测试用例覆盖度一般是从以下几方面衡量的：
1）测试需求的覆盖：保证所有需求都已经设计用例
2）测试特性的覆盖：保证所有不同类型已覆盖，如：功能测试，性能测试等
3）平台与层次的覆盖：保证所有平台有用例覆盖，不同层次都有设计用例，如业务层、接口层等

测试用例主要分两个部分：非功能性测试、功能性测试。

• 非功能性测试，主要指产品在各种环境下是否能正常运行
• 功能性测试，主要是指每个具体功能是否按要求运行。
  用例详情：功能模块、测试编 、测试点、测试点描述、测试背景、前置条件、优先级、重要级、测试数据、测试步骤、预期结果、实际结果、备注等

7.编写用例从那些方面考虑

1. 软件或项目的名称

2. 软件或项目的版本（内部版本 ）

3. 功能模块名

4. 测试用例的简单描述，即该用例执行的目的或方法

5. 测试用例的参考信息（便于跟踪和参考）

6. 本测试用例与其他测试用例间的依赖关系

7. 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限

8. 用例的编 （ID），如可以是 软件名称简写-功能块简写-NO.。

9. 步骤 、操作步骤描述、测试数据描述

10.预期结果（这是最重要的）和实际结果（如果有BUG管理工具，这条可以省略）

11.开发人员（必须有）和测试人员（可有可无）

12.测试执行日期

8.测试 告编写过么,包括什么

数据统计
遗留bug情况
测试风险
暂停的问题
1、出现概率比较低，用户操作不易复现的问题，后续由客户端修改；
2、本地阅读定位问题，修改比较困难，不影响使用，后续优化；
3、属于遗留问题；
4、属于内容平台问题，内容优化；
暂停问题是产品人员、开发人员与测试人员沟通后暂停的

9.接口测试怎么做的

10.bug生命周期

新建 确认 解决 重新验证 关闭 重新打开

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

11.软件测试的目的

发现软件的缺陷与漏洞，对软件的质量进?评估，提升软件质量

12.性能测试怎么做的

1、制定目标和分析系统;

2、选择测试度量的方法;

3、学习的相关技术和工具;

4、制定评估标准;

5、设计测试用例;

6、运行测试用例;

7、分析测试结果。

一般来说，性能测试要统一考虑这么几个因素：Thoughput吞吐量，Latency响应时间，资源利用（CPU/MEM/IO/Bandwidth…），成功率，系统稳定性。

一，你得定义一个系统的响应时间latency，建议是TP99，以及成功率。比如路透的定义：99.9%的响应时间必需在1ms之内，平均响应时间在1ms以内，100%的请求成功。

二，在这个响应时间的限制下，找到最高的吞吐量。测试用的数据，需要有大中小各种尺寸的数据，并可以混合。最好使用生产线上的测试数据。

三，在这个吞吐量做Soak Test，比如：使用第二步测试得到的吞吐量连续7天的不间断的压测系统。然后收集CPU，内存，硬盘/ 络IO，等指标，查看系统是否稳定，比如，CPU是平稳的，内存使用也是平稳的。那么，这个值就是系统的性能

四，找到系统的极限值。比如：在成功率100%的情况下（不考虑响应时间的长短），系统能坚持10分钟的吞吐量。

五，做Burst Test。用第二步得到的吞吐量执行5分钟，然后在第四步得到的极限值执行1分钟，再回到第二步的吞吐量执行5钟，再到第四步的权限值执行1分钟，如此往复个一段时间，比如2天。收集系统数据：CPU、内存、硬盘/ 络IO等，观察他们的曲线，以及相应的响应时间，确保系统是稳定的。

六、低吞吐量和 络小包的测试。有时候，在低吞吐量的时候，可能会导致latency上升，比如TCP_NODELAY的参数没有开启会导致latency上升（详见TCP的那些事），而 络小包会导致带宽用不满也会导致性能上不去，所以，性能测试还需要根据实际情况有选择的测试一下这两咱场景。

（注：在路透，路透会用第二步得到的吞吐量乘以66.7%来做为系统的软 警线，80%做为系统的硬 警线，而极限值仅仅用来扛突发的peak）

13.性能测试关注的指标

从外部看,性能测试主要关注如下三个指标
吞吐量:每秒钟系统能够处理的请求数,任务数
响应时间:服务处理一个请求或一个任务的耗时
错误率:一批请求中结果出错的请求所占比例
从服务器的角度看,性能测试主要关注CPU,内存,服务器负载, 络,磁盘io等

14.性能测试的指标是根据什么对比的(响应时间和谁对比的)

前端主要关注点是
加载速度
电量
流量
Crash和ANR
响应时间

后端主要关注的是：
响应时间：接口从请求到响应、返回的时间。

并发用户数：同一时间点请求服务器的用户数，支持的最大并发数。

内存占用：APP的内存开销。

吞吐量（TPS）：Transaction Per Second, 每秒事务数。在没有遇到性能瓶颈时：TPS=并发用户数*事务数/响应时间。

错误率：失败的事务数/事务总数。

资源使用率：CPU占用率、内存使用率、磁盘I/O、 络I/O。

15.linux

查看进程
ps aux
查看指定进程
ps -ef |grep python
查看80端口被谁占用
ps -ef |grep 80
包含”text”文件怎么查找

创建层级目录树

vi用过吗,怎么用的

说你自己知道的常用命令

16.设计用例

搜索框

鼠标

朋友圈点赞

发红包

给你个百度 址设计用例(结合七层模型)

进入会议间的用例(腾讯会议)

17.给一个web端或者是app端你如何展开测试h4>

App测试

首先拿到项目原型图或者思维导图然后进行具体的：

功能测试：每项开发的新功能都要进行测试，功能测试是App中的重要方面，要进行手动测试和后期的自动化测试，刚开始测试时要把App当做“黑盒测试”，看功能是否正常，除了经典测试以外，像点击按钮、提交订单…等等，看会出现什么情况。

客户端性能测试：App好不好，不仅仅时功能展示，在高端机正常运行，中/低端机型卡的不行，这也不能算是好的App。关于性能测试主要是：cup、内存、耗电量、流量、FPS…等

适配兼容测试：不同机型/不同品牌/不同系统测试

安全测试： App在上线前，都需要做详细的安全测试。安全测试主要为了检测应用是否容易被外界破解；是否存在被恶意代码注入的风险；上线后外挂的风险高不高等。

服务器性能测试：服务器性能测试，主要包含单机容量测试和24小时稳定性测试。单机容量测试，可以检测到单机服务器在90%的响应时间和成功率都达标的前提下，能够承载多少用户量。使用特定游戏模型压测24小时，服务无重启，内存无泄漏，并且各事务成功率达标

web测试

一、功能测试

1、链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

2、表单测试
当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会 错。

3、Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。

4、数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于 络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
二、性能测试

1、连接速度测试
用户连接到Web应用系统的速度根据上 方式的变化而变化，他们或许是电话拨 ，或是宽带上 。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

2、负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线超过了这个数量，会出现什么现象b应用系统能否处理大量用户对同一个页面的请求p>

3、压力测试
负载测试应该安排在Web系统发布以后，在实际的 络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。压力测试的区域包括表单、登陆和其他信息传输页面等。
三、可用性测试

1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观b系统的主要部分是否可通过主页存取b系统是否需要站点地图、搜索引擎或其他的导航帮助p>

在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

3、内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的”拼音与语法检查”功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓”相关文章列表”。

4、整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方Web应用系统的设计风格是否一致体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。

18.说出你常用的adb 命令（15个）和 monkey命令 （5个）

19.web端测试和app端测试的相同点和不同点

1、相同点

不管是传统行业的web测试，还是新兴的手机app测试，都离不开测试的基础知识，即是不管怎么变，测试的原理依然会融入在这两者当中。

1）设计测试用例时，依然都是依据边界值分析法、等价类划分等；

2）多数采用黑盒的测试方法，来验证业务功能是否得到正确的应用；

3）需要检查界面的布局、风格和按钮等是否简洁美观、是否统一等；

4）测试页面载入和翻页的速度、登录时长、内存是否溢出等；

5）测试应用系统的稳定性等。

2、不同点

相对于web测试，手机软件测试，除了要考虑基本的功能测试、性能等，还要考虑手机本身固有的属性特征。所以对比web测试和手机测试，手机测试过程中还需要注意如下几个方面特性：

1）手机作为通信工具，来电、去电、接收短信等操作都会对app应用程序产生影响，所以app测试第一个要考虑的属性特征是：中断测试。

中断测试有人为中断、新任务中断以及意外中断等几种情况，主要从以下几个方面进行验证：

a.来电中断：呼叫挂断、被呼叫挂断、通话挂断、通话被挂断

b.短信中断：接收短信、查看短信

c.其他中断：蓝牙、闹钟、插拔数据线、手机锁定、手机断电、手机问题（系统死机、重启）

2）手机用户对app产品的安装卸载操作：从上一个版本/上两个版本直接升级到最新版本。

全新安装新版本

新版本覆盖旧版本安装

卸载旧版本，安装新版本

卸载新版本，安装新版本

3）web自动化测试使用的工具较常用的是QTP，而android手机自动化测试工具比较常用的是monkey、monkeyrunner。

20.charles 抓取移动端的步骤 和进行响应断点的步骤 以及如何进行模拟404的步骤

http请求
首先，需要将 Charles 的代理功能打开：在 Charles 的菜单栏上选择 Proxy -> Proxy Settings，填入代理端口 8888，并且勾上 “Enable transparent HTTP proxying” 就完成了在 Charles 上的设置,还需要在SSL Proxying Settings里设置我们需要监听的app域名,然后，我们需要获取 Charles 运行所在电脑的 IP 地址，Charles 的顶部菜单的 Help -> Local IP Address，即可在弹出的对话框中看到 IP 地址,接着，将手机上的 络手动设置代理，服务器主机名就是上一步中获得的ip地址，端口 为第一步里的端口 。
设置好之后，我们打开手机上任意程序，就可以看到 Charles 弹出手机请求连接的确认菜单，点击 “Allow” 即可完成设置。
https请求
首先，我们需要安装证书：点击 Charles 的顶部菜单，选择 Help -> SSL Proxying -> Install Charles Root Certificate on a Mobile Device or Remote Browser。点击之后会出现如图所示弹窗：
接着，将移动端设置代理后，打开浏览器，输入上图红线标示的地址，直接访问，就可以在移动端下载证书了。下载安装证书之后，便可以抓取https请求了。
响应断点的步骤:
方法一、选中想要设置断点的接口，右键，点击Breakpoints，即可完成断点设置
方法二、点击工具栏Proxy选项->Breakpoints Settings，新增输入想要设置断点的接口，然后点击 “OK”按钮，即可完成断点设置
1、把服务端接口设置断点

2、由于我只需更改接口的返回值即可进行检查，所以设置断点的时候可以仅选择Response
3、设置断点后，再次使用客户端请求此接口
按上述步骤就能完成更改接口返回值了，这样就能检查客户端接收到的值是120时，是否显示99+
模拟404的步骤: