1.浏览器输入对应的 url
2.解析域名，找到主机 ip 地址
3.浏览器与主机建立 tcp 连接
4.浏览器定向发起定向请求
5.服务器响应请求，返回 html 页面
1.https 协议需要到 CA 申请证书，一般免费证书较少，因而需要一定费用
2.http 是超文本传输协议，信息是明文传输，https 则是具有安全性的 ssl/tls 加密传输协议。
3.http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443
4.http 的连接很简单，是无状态的；HTTPS 协议是由 SSL/TLS+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全。
1.cookie 数据存放在客户的浏览器上，session 数据放在服务器上。
2.cookie 不是很安全，别人可以分析存放在本地的 COOKIE 并进行 COOKIE 欺骗考虑到安全应当使用 session。
3.设置 cookie 时间可以使 cookie 过期。但是使用 session-destory（），将会销毁会话。
4.session 会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用 cookie。
5.单个 cookie 保存的数据不能超过 4K，很多浏览器都限制一个站点最多保存 20 个 cookie。(Session 对象没有对存储的数据量的限制，其中可以保存更为复杂的数据类型)
** 备注：**
两者最大的区别在于生存周期，一个是浏览器启动到浏览器关闭.(浏览器页面一关 ,session 就消失了)，一个是预先设置的生存周期，或永久的保存于本地的文件。(cookie)
1.yaml 文件方式
2.json 文件 方式
3.csv 文件方式
4..xlsx，excel 方式
5.读取数据库的方式
** 要是面试官问方法的话可以如下回答：**
1.如果是只测试一次的接口，可以使用硬编码的方式准备测试数据，在写测试代码的时候，使用到什么数据就写什么数据，为了避免数据重复，可能比较多的会用到随机字符或随机数
2.可以直接通过调用其他 API 的方式准备测试数据，这种情况在测试最上层服务的时候比较有用，比如测试团购购买服务，就需要准备要购买的团购数据，购买团购的用户数据，这个时候，可以直接调用生产团购的 api 和生成用户的 api 直接生成测试数据
3.使用 excel 或 xml 准备测试数据，这种准备测试数据的方式，主要针对对象数据的准备，比如可以将一条团购数据对应 excel 中的一条数据，因为一般开发都会使用 pojo 映射，而在准备测试数据的时候，这些 pojo 对象属性的设置往往是重复和大工作量的，用 excel 或 XML 方式准备，则可以减少在代码当中重复去准备这些数据。
4.也可以使用工具方法的形式去准备测试数据，通过在代码中写工具方法去实现数据生成，而在测试代码中调用工具方法去得到所需数据。
1.测试流程相同：都需要立项，反串讲，用例设计，测试执行，缺陷管理，测试报告，上线，线上持续跟进
2.测试内容和测试方法相同：都需要功，性，安与 Gui 的等一系列的测试
1.性能测试：web 主要吞吐量和响应时间这两个要素。App 需要考虑流量，耗电，帧率等
2.兼容性：web 需要兼容浏览器，App 需要兼容的是设备，前者是软件兼容，后者需要考虑硬件以及系统版本等
3.install：web 没有客户端，App 是存在用户本地的，所以需要
3.App 是基于手机设备的，所以需要部分专项测试，例如交叉事件测试，操作类型测试，网络测试
4.架构层面：web 只需要 跟新 service 端，客户端就会同步跟新，可以保证每个 user 的客户端都能保持一直（但是需要注意，个性化配置的客户端），App 是不能保持一致的，除非客户端跟新，如果客户端下更改了 service 端，那么所有的核心版本，都需要回归测试一遍
5.升级测试：web 没有，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
select * from student a where (a.name) in (select name from student group by name having count(*) > 1)
** 偷懒写法 **
使用内置排序函数
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
cat -n a.log | grep abc
lsof -i:80
1. 并发用户数
2. 资源性质
3. 用户平均请求等待时间 和 服务器处理请求的平均时间