- 面试题及解析答案来自牛客网https://www.nowcoder.com/exam/interview/
-
5 了解什么测试方法?
- 测试的方法?
- 写测试用例的方法?
- 分析测试点的方法?
- 测试是个大工程,很多环节,具体是指什么方法?
- 一些分析测试点的方法:边界值、等价类、流程图、场景法、因果图
- 答案:
- 等价类划分
- 边界值分析
- 错误推测法
- 因果图法
- 逻辑覆盖法
- *程序插桩技术?
- 基本路径法
- *符号测试?
- *错误驱动测试
-
6 项目中压力测试怎么做?
- 明确对哪个部分做压力测试,以秒杀活动为例。
- 确定性能需求,明确压力的性能指标,确定测试点,对这些测试点施压。
- 可以通过写脚本产生压力机器人,对服务器进行发包和收包的操作。
- 也可以借助Jemeter、LR工具,模拟多用户同时操作。
- 明确对测试点设计的压力指标。需要明确压力测试限制的数量,即用户并发量。
- 测试结束后,通过数据定位性能问题,通过测试可以得到吞吐量、平均响应时间等数据。
- 这个数据是整个后台处理逻辑综合作用的结果。此时关注系统的CPU、内存,然后对比吞吐量、平均响应时间达到瓶颈时,这些数据的情况。
- 然后就能确认性能问题是系统的哪一块造成的。
-
7 设计一个朋友圈点赞的测试用例
-
功能测试
- 点赞一条朋友圈,验证是否成功。
- 用例名称:like-01
- 所属模块:点赞模块
- 优先级:p1
- 标题:朋友圈点赞成功
- 前置条件:账号已登录;好友列表不为空;朋友圈列表不为空;联网。
- 测试数据:无
- 测试步骤:点击“朋友圈”,查看朋友圈信息,点击点赞按钮。
- 预期结果:点赞按钮由灰色变为红色,并在点赞列表中显示当前用户的头像。
- 实际结果:执行后添加。
- 测试版本:
- 测试人员:
- 备注:
-
接口测试
- 点赞朋友圈,验证朋友能否收到提示信息。
-
性能测试
- 点赞朋友圈,是否在规定时间显示结果,是否在规定时间在朋友手机上进行提示。
-
兼容性测试
- 在不同的终端进行测试,验证是否成功。比如iPad、电脑、手机。
-
8 HTTP的报文段是什么样的?
- 请求格式:起始行-请求头-空行-请求体(get\delete 无请求体,post\put有请求体)
- 响应格式:起始行-响应头-空行-响应体
-
内容:
- 起始行:基本信息 请求——(方法 URL 版本信息);响应——(版本 状态码 原因)
- header: 报文详细说明(key:value结构)
- 空行
- [body]:实际传输的数据,比如:文本、图片、视频......
-
请求——header特有字段。
- Host: 请求特有字段。 告诉服务器此请求该由哪个主机负责处理并响应。通常服务器端托管多个虚拟主机。
- User-Agent: 请求特有字段,描述发起请求的客户端,让服务器依据此字段值来返回合适此浏览器显示的页面。
-
响应——header特有字段
- Server: 服务端向客户端展示当前正在提供web服务的软件名称和版本号。
-
通用字段
- date:HTTP报文的创建时间,通常显示在响应头中。缓存策略
- Content-Type: body的长度。
-
补充:状态码
- 100~199表示请求已收到继续处理,
- 200~299表示成功,
- 300~399表示资源重定向,
- 400~499表示客户端请求出错,
- 500~599表示服务器端出错
- 200:响应成功
- 302:跳转,重定向
- 400:客户端有语法错误
- 403:服务器拒绝提供服务
- 404:请求资源不存在
- 500:服务器内部错误
-
9 说一说HTTP请求报文
-
请求报文包含哪几部分?
- 请求行 包括请求方法,统一资源定位(路径), 协议版本。
- 请求头 包括一系列的字段名和字段值。比如Host,告诉服务器指定哪个主机处理请求;User-Agent, 告诉服务器客户端的浏览器描述类型,服务端以此返回适合在该浏览器显示的页面。
- 空行 区分请求头和请求体。
- 请求体 请求的数据。POST和PUT有请求体,GET和DELETE没有请求体。
-
请求方法都有哪些?
- GET:请求获取URL标识的资源。
- POST: 在URL所标识的资源后附加资源
- PUT:请求服务器存储一个资源,由URL作为其标识
- DELETE:请求服务器删除由URL所标识的资源
- HEAD:请求获取由URL标识的资源的响应消息报头
- TRACE:用于测试和诊断,请求服务器回送收到的请求信息
- CONNECT:保留
- OPTION:请求查询服务器性能
-
10 说一下TCP三次握手,以及为什么不是两次。
- TCP:Transmission Control Protocol,面向连接的、可靠的、基于字节流的传输层通讯协议。
- 第一次握手,A向服B发送一个请求,尝试建立连接;
- 第二次握手,B向A发送请求确认,并发送可建立连接的请求;
- 第三次握手,A向B发送确认建立连接响应。
- 两次握手,双方不能都确认可以发送和接收数据。
-
答案:
- 第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。
- 第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;
- 第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。
- 为什么不是两次: 在服务端对客户端的请求进行回应(第二次握手)后,就会理所当然的认为连接已建立,而如果客户端并没有收到服务端的回应呢?此时,客户端仍认为连接未建立,服务端会对已建立的连接保存必要的资源,如果大量的这种情况,服务端会崩溃。
-
自己的理解:
- 第一次握手,客户端发送请求syn=j;
- 如果服务端可以响应,会发送一个响应ack=j+1。
- 第二次握手,服务端发送响应ack=j+1,并发送新的请求syn=k;
- 如果客户端可以响应,就需要告诉服务端。
- 第三次握手,客户端发送响应ack=k+1。
- 三次握手包含两次请求和响应,且是互相的。
标签:HTTP,请求,报文,响应,测试,服务器,握手,客户端 From: https://www.cnblogs.com/annyanny/p/16667074.html