1.一次完整 http 请求需要经历那些流程,描述一下请求过程?

1.浏览器输入对应的 url
2.解析域名,找到主机 ip 地址
3.浏览器与主机建立 tcp 连接
4.浏览器定向发起定向请求
5.服务器响应请求,返回 html 页面

2.https 和 http 的区别?

1.https 协议需要到 CA 申请证书,一般免费证书较少,因而需要一定费用
2.http 是超文本传输协议,信息是明文传输,https 则是具有安全性的 ssl/tls 加密传输协议。
3.http 和 https 使用的是完全不同的连接方式,用的端口也不一样,前者是 80,后者是 443
4.http 的连接很简单,是无状态的;HTTPS 协议是由 SSL/TLS+HTTP 协议构建的可进行加密传输、身份认证的网络协议,比 http 协议安全。

3.cookie 和 session 的区别?

1.cookie 数据存放在客户的浏览器上,session 数据放在服务器上。
2.cookie 不是很安全,别人可以分析存放在本地的 COOKIE 并进行 COOKIE 欺骗考虑到安全应当使用 session。
3.设置 cookie 时间可以使 cookie 过期。但是使用 session-destory(),将会销毁会话。
4.session 会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能考虑到减轻服务器性能方面,应当使用 cookie。
5.单个 cookie 保存的数据不能超过 4K,很多浏览器都限制一个站点最多保存 20 个 cookie。(Session 对象没有对存储的数据量的限制,其中可以保存更为复杂的数据类型)

** 备注:**
两者最大的区别在于生存周期,一个是浏览器启动到浏览器关闭.(浏览器页面一关 ,session 就消失了),一个是预先设置的生存周期,或永久的保存于本地的文件。(cookie)

4.接口测试常用的几种数据准备方式?

1.yaml 文件方式
2.json 文件 方式
3.csv 文件方式
4..xlsx,excel 方式
5.读取数据库的方式
** 要是面试官问方法的话可以如下回答:**

1.如果是只测试一次的接口,可以使用硬编码的方式准备测试数据,在写测试代码的时候,使用到什么数据就写什么数据,为了避免数据重复,可能比较多的会用到随机字符或随机数
2.可以直接通过调用其他 API 的方式准备测试数据,这种情况在测试最上层服务的时候比较有用,比如测试团购购买服务,就需要准备要购买的团购数据,购买团购的用户数据,这个时候,可以直接调用生产团购的 api 和生成用户的 api 直接生成测试数据
3.使用 excel 或 xml 准备测试数据,这种准备测试数据的方式,主要针对对象数据的准备,比如可以将一条团购数据对应 excel 中的一条数据,因为一般开发都会使用 pojo 映射,而在准备测试数据的时候,这些 pojo 对象属性的设置往往是重复和大工作量的,用 excel 或 XML 方式准备,则可以减少在代码当中重复去准备这些数据。
4.也可以使用工具方法的形式去准备测试数据,通过在代码中写工具方法去实现数据生成,而在测试代码中调用工具方法去得到所需数据。

5.web 和 app 测试有什么异同?

1.相同点

1.测试流程相同:都需要立项,反串讲,用例设计,测试执行,缺陷管理,测试报告,上线,线上持续跟进
2.测试内容和测试方法相同:都需要功,性,安与 Gui 的等一系列的测试

2.不同点

1.性能测试:web 主要吞吐量和响应时间这两个要素。App 需要考虑流量,耗电,帧率等
2.兼容性:web 需要兼容浏览器,App 需要兼容的是设备,前者是软件兼容,后者需要考虑硬件以及系统版本等
3.install:web 没有客户端,App 是存在用户本地的,所以需要
3.App 是基于手机设备的,所以需要部分专项测试,例如交叉事件测试,操作类型测试,网络测试
4.架构层面:web 只需要 跟新 service 端,客户端就会同步跟新,可以保证每个 user 的客户端都能保持一直(但是需要注意,个性化配置的客户端),App 是不能保持一致的,除非客户端跟新,如果客户端下更改了 service 端,那么所有的核心版本,都需要回归测试一遍
5.升级测试:web 没有,App 需要有提醒机制,升级是否会影响原有功能的使用,升级之后,本地数据是否被抹除了,以及缓存的兼容性

6.测试 App 登录场景

功能层面

1.输入已注册的用户名和正确的密码,验证是否登录成功;
2.输入已注册的用户名和不正确的密码,验证是否登录失败,并且提示信息正确;
3.输入未注册的用户名和任意密码,验证是否登录失败,并且提示信息正确;
4.用户名和密码两者都为空,验证是否登录失败,并且提示信息正确;
5.用户名和密码两者之一为空,验证是否登录失败,并且提示信息正确;
6.如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入正确的验证码,验证是否登录成功;
7.如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入错误的验证码,验证是否登录失败,并且提示信息正确。
8.用户名和密码是否大小写敏感;
9.页面上的密码框是否加密显示;
10.后台系统创建的用户第一次登录成功时,是否提示修改密码;
11.忘记用户名和忘记密码的功能是否可用;
12.前端页面是否根据设计要求限制用户名和密码长度;
13.如果登录功能需要验证码,点击验证码图片是否可以更换验证码,更换后的验证码是否可用;
14.刷新页面是否会刷新验证码;
15.如果验证码具有时效性,需要分别验证时效内和时效外验证码的有效性;
16 用户登录成功但是会话超时后,继续操作是否会重定向到用户登录界面;
17 不同级别的用户,比如管理员用户和普通用户,登录系统后的权限是否正确;
18.页面默认焦点是否定位在用户名的输入框中;
19.快捷键 Tab 和 Enter 等,是否可以正常使用。

安全层面

1. 用户密码后台存储是否加密;
2. 用户密码在网络传输过程中是否加密;
3. 密码是否具有有效期,密码有效期到期后,是否提示需要修改密码;
4. 不登录的情况下,在浏览器中直接输入登录后的 URL 地址,验证是否会重新定向到用户登录界面;
5. 密码输入框是否不支持复制和粘贴;
6. 密码输入框内输入的密码是否都可以在页面源码模式下被查看;
7. 用户名和密码的输入框中分别输入典型的 “SQL 注入攻击” 字符串,验证系统的返回页面;
8. 用户名和密码的输入框中分别输入典型的 “XSS 跨站脚本攻击” 字符串,验证系统行为是否被篡改;
9. 连续多次登录失败情况下,系统是否会阻止后续的尝试以应对暴力破解;
10. 同一用户在同一终端的多种浏览器上登录,验证登录功能的互斥性是否符合设计预期;
11. 同一用户先后在多台终端的浏览器上登录,验证登录是否具有互斥性。

性能层面

1. 单用户登录的响应时间是否小于 3 秒;
2. 单用户登录时,后台请求数量是否过多;
3. 高并发场景下用户登录的响应时间是否小于 5 秒;
4. 高并发场景下服务端的监控指标是否符合预期;
5. 高集合点并发场景下,是否存在资源死锁和不合理的资源等待;
6. 长时间大量用户连续登录和登出,服务器端是否存在内存泄漏。

兼容层面

1. 不同浏览器下,验证登录页面的显示以及功能正确性;
2. 相同浏览器的不同版本下,验证登录页面的显示以及功能正确性;
3. 不同移动设备终端的不同浏览器下,验证登录页面的显示以及功能正确性;
4. 不同分辨率的界面下,验证登录页面的显示以及功能正确性。
其他的还有很多方面的,暂时脑子就存储这些了。。。。。
c

student 表(id,name,age)查询 student 中重复的名称?

select * from student a where (a.name) in  (select name from student group by name  having count(*) > 1)

使用你熟悉的语言写一个冒泡排序,数组 A 排序,int[]={11,2,5,82,7,0,4,89,72,42}

** 偷懒写法 **
使用内置排序函数

A = [11, 2, 5, 82, 7, 0, 4, 89, 72, 42]
A.sort()
print(A)

结果如下(虽然完成了,但是没有冒泡)

[0, 2, 4, 5, 7, 11, 42, 72, 82, 89]

** 冒泡写法 **

def bubble_sort(lists):
    # 冒泡排序
    count = len(lists)
    for i in range(0, count):
        for j in range(i + 1, count):
            if lists[i] > lists[j]:
                lists[i], lists[j] = lists[j], lists[i]
    return lists

linux 命令,在 a.log 中查找 abc

cat -n a.log | grep abc 

查询 80 端口占用情况

lsof -i:80

性能测试报告需要关注那字段?

1. 并发用户数
2. 资源性质
3. 用户平均请求等待时间 和 服务器处理请求的平均时间


↙↙↙阅读原文可查看相关链接,并与作者交流