- 面试题及解析答案来自牛客网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