項目及面試

HTTP
面试题讲解
shopXO商城

HTTP

Http是什么？/TCP/IP是什么？

HTTP：超文本传输协议。属于应用层的协议。
网络传输的底层：TCP/IP。
基于TCP/IP网络传输的底层出现了https协议，（s即安全的意思）在外网的话，都会做成安全模式。
面试时主动讲：http的方法有很多，最主要的四大方法是put,delete,get,post(get,post测试用的最多）,
接着讲：get和post的区别(post提交数据给服务器，改变服务器的数据，参数填写在body里，看不到url参数，数据都放在包里，更安全；get仅仅是获取数据，直接在params里填写。）

HTTP和HTTPS的区别

1、https协议需要得到CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。(原来网易官网是http，而网易邮箱是https。)
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的。Https协议是由SSL+Http协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)

“登录”功能测试点

1.功能：
正常（正确的用户名和密码）、
异常（错误的用户名，错误的密码的不同组合），出入错误后有提示，提示信息显示
特殊字符、密码长度、空格等
2.兼容性：
浏览器（IE,Chrome），
界面（手机，平板，web端等平台显示是否完整）
3.安全性：
cookie
4.性能：
打开速度，并发

接口自动化

测“登录”的测试

登陆有很多异常场景，用数据驱动的方法（即将测试数据放在数据文件里边，用代码去读取文件，然后用不同的测试用例去执行。）用pytest中的fixture来传递数据。
接口关联的时候怎么去测/数据关联

手工测试：

先测接A，然后将值复制出来，再传到接口B中
自动化:
方法一：将参数作为变量，然后把变量作为参数传进去（但数据量较多时不使用）
方法二：把业务封装成函数，在测业务的时候直接去调用函数

前端、后端

前端：负责开发页面，常用HTML、JavaScript、css等。
后端：负责业务逻辑的处理

前端优化时怎样优化？

在禁用缓存的情况下，在“开发者工具”中查看发送数据请求所用的时间，对此进行优化

get和post的区别

1.传送方式：
get通过地址栏传输，只是获取数据；post通过报文传输，改变服务器的数据
2.传送长度：
get参数有长度限制（受限于url长度），而post无限制
3.post请求相对get更安全

Fiddler在工作中的应用实例

1.在抓包定位问题时会用到：
做接口测试提交问题，提交之前需要先做判断问题是前端或是后端的问题。fiddler可以抓web端、手机app端，通过抓包来分析问题是前端还是后端。
2.分析竞争对手的api是怎么做的。
3.在工作中做弱网测试，可以通过抓包工具模拟弱网环境。
PS：fiddler只能抓合http,https协议的请求。

没有API文档时怎么做接口测试？

可以使用fiddler抓包，提取相关的数据，整理后和开发核对相关数据参数，最后保存文档为后期存档。

面试题讲解

预发布环境

一个项目的预发布环境一般只有一套（最多有两套，另一套是备用的）
尽量模拟真实，和线上真实环境保持一致

测试用例设计

一个测试用例没有一个好的评判标准，将自己的思路：
正反例拆开（从qa的思维去解答：正常的数据是用户用户的比较多的，回归测试时部分的话数据量会很大。其次一个小的数据有问题，这条用例会不通过，那么涉及到整个用例的通过率），设计时考虑优先级，切测试点（测试数据拎出来写，方便后期维护），以用户的场景角度考虑设计用例

一般一个项目持续多久？

没有做过一个完整的项目

一个接口，大批量数据库如何测（成百上千的数据）

这是一个get请求的数据。分析数据返回的内容（找规律，第一条和最后一条，分批量：每天的第一条和最后一条，自动化方法）

怎么做接口测试的？

做借口先拿到需求接口文档，然后分析接口文档（get，post占比，入参，出餐数据），再写测试用例，再将用例写到postman里，要注意数据上下游的传递，公共变量等，再查看返回的数据

有没有进行过异常测试？

举例：支付异常（fiddler里的前置断点before requests 和后置断点after response)

手机银行APP系统

shopXO商城

冒烟：是前后台一起做的
冒烟测试用例：每个步骤都要有预期结果，冒烟用例标题一般不给序号不需要模块化，一个场景一般1-2个步骤就可以

注册有三种注册方式，写三条用例

首页

模块名称：商品
二级功能：商品搜索、商品分类
【新闻头条】：新建、显示、链接点击跳转、条数过多的处理（最多一页显示9条，写用例时写第十条用例两种显示方式，①冲掉第一条；②下方显示查看更多，具体看需求，二选一即可）
商品显示：也是要测的，测后台配置对应的显示

【商品搜索】

测试点：有的商品，没的商品，已下架的商品，

全部分类（一级菜单）

新建新的商品分类（因为测试环境是一个大的框架，刚开始测试的时候都是需要从新建开始的）
分别建一个二级的和三级的商品
前台【全部分类】测试点：新增（是后台操作新增的）、编辑、删除，点击【全部分类】打开具体的分类、滚动条

前台页面商品添加功能

测试用例：
1.进入到后台新建商品——商品新建成功
2.前台展示该商品——商品显示完整
3.点击新建的商品——商品信息与后台新建的信息相符

后台商品添加功能

用例：

提交订单：（面试时可以将此页面打印出来在上面讲）

用例：

提交订单快递邮寄新建并使用默认新地址

备注：
此处的省市选择单独写一条用例，数据是开发那边提供的，检查核对列表中的内容是否显示全

提交订单快递邮寄新建并使用默认新地址（反例）

提交订单快递邮寄新建非默认新地址

提交订单支付方式货到付款提交订单

测试点

cookie存在本地服务器是可见的，seesion存放在服务器上的是不可见的，相对cookie安全要高。cookie将数据保存在客户端没有退出放在后台再次进入时不需要重新登陆，session将数据保存在服务器上没有退出放在后台再次进入时需要重新登陆
（造数据时，一般以自己的名字命名开头，方便查找自己的数据，如果不希望被改动标明“勿动”字样）

分页：要准备的数据（9假设10条为一页）0，1，10，11，
如果数据很多时如果有分页的情况，点击首页和最后一页的的链接即可
在第一页的时候首页按钮灰色，在最后一页的时候右边最后一个按钮是灰色
综合排序的规律也是要测的
销量：考虑买东西是销量的变化
打折商品：付款时是不是打折后的价格，活动时间过后价格的变化
个人中心订单状态：数据是造出来的，对应的每个状态下最新的一条是最新更新的数据。比如下单未付款那么待付款数+1，如果付完款等商家发货，那么待付款数-1，代发货数+1

在测试执行时，快递单号数据一般用订单号，在订单号后面加1，这样方便查找快递信息。在后台模拟各种状态，然后要查看订单的状态是否随着更改，前台的数据也要查看
做回归测试时，如果时间紧迫只能测十条，那前五条一定要看前台，保证用户使用的质量

作业：在postman中写【个人中心】-【修改资料】模块虚拟接口
作业：新增地址，然后再将地址设置为默认

提交bug

bug标题不要用下划线不要有前缀，直接简单明了说明bug问题
bug描述不要有前置条件

用例设计：

收入统计：

金额——打折商品价格核对，使用代金券，小数点后的金额（一般是开发设置只有后两位，但要测这一点，如果每一笔订单都差0.004，成交量超大的话金额也会比较客观）

交易走势图：

需要新的环境（隔离式的环境），数据是空的
时间——考虑闰年，月份天数（28，29，30，31）
数据：做不到实时更新，定时更新数据
折线图变化：比如同一时间待付款完成后，待付款数量减少用一时间下待发货的数量会增加（是动态变化的）
视图切换，并且对照数据

近30日热销商品：

设计场景：第十条和第十一条一样时怎么显示
拿到30日+1天、-1天的数据，检查名字，算百分比（用excel写个小工具，填入数据自动算出百分比）
数据库查询：select 商品名称,count(数量) from 表 where 时间 between ‘2020-05-21’ and ‘2020-06-19’ group by 商品名称 order by count(数量) desc limit 10
30+1天：select 商品名称,count(数量) from 表 where 时间 between ‘2020-05-20’ and ‘2020-06-19’ group by 商品名称 order by count(数量) desc limit 10
30-1天：select 商品名称,count(数量) from 表 where 时间 between ‘2020-05-22’ and ‘2020-06-19’ group by 商品名称 order by count(数量) desc limit 10

权限：

轻描淡写地写，不必要写具体的详细步骤（但测的时候是要一步步去做的）
如果一个大的标题下有很多分类，可以一个权限写一条用例，也可以都写在一个标题下面每个权限分一个步骤来写。
后台管理系统不测兼容性，一般都是web端。
兼容性测试：做一个冒烟测试

预发布环境：

一般要做冒烟测试
一般不要挨个验证缺陷，挑几个之前比较严重的缺陷再验证一下（严重程度高的、优先级高的、探索式测试）
执行新功能优先级高的用例，等新功能完成后做回归测试

项目流程：

一般先了解需求，开发和测试进行排期【主要讲测试排期（参照设计时间+执行时间）】——是为了测试左移（在设计阶段开发也是在设计，所以这个时候我们会设计测试点、测试用例。。。）
——设计时间：需求分析，测试点设计，评审测试点，测试用例编写
——执行时间：用例执行，缺陷验证跟踪
排期完成后设计测试点，评审，测试用例执行，缺陷验证跟踪。所有用例执行完毕后，却又现已验证关闭完毕，做回归测试完成（根据影响性分析，主要功能的选取以及根据之前的经验挑选一部分用例），到预发布环境（拿测试的最后一个版本）
如果在预发布版本有缺陷时，回到最后一个测试环境进行修改，修改完成后再重新拿到预发布环境中进行测试
生产环境有问题：
在生产环境上直接修改（风险很高）或者撤回老版本用一个其他的版本直接代替重新发布

項目 及面試