一.测试流程

开发:编写概要和详细设计

立项(确定项目)–编写需求(需求人员)–需求评审(编写需求人员发起) --部署环境(Linux)–冒烟测试–提交bug—回归测试–验收测试–上线

测试:测试用例,测试用例评审

二.软件测试的分类

按照阶段:

单元测试,集成测试,系统测试,验收测试

按照是否查看源代码划分:

白盒测试

黑盒测试

功能测试:逻辑功能测试,界面测试,易用测试,安装测试,兼容测试

性能测试

一般性能测试,稳定测试

负载测试:让被测系统在其能够忍受的压力范围之内连续运行,来测试系统的稳定性。(测试载重)

压力测试:持续不断的给被测试的系统增加压力,直到被测试的系统压垮为止,用来测试系统所承受的最大压力。(测试强度)

其他

回归测试:回归测试是指修改了旧代码后,重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

冒烟测试:指对一个软件进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。

随机测试:是指测试中所有的输入数据都是随机生成的,其目的是模拟用户的真实操作,并发现一些边缘性的错误

三.压力测试和负载测试的区别

负载测试:让被测系统在其能够忍受的压力范围之内连续运行,来测试系统的稳定性。(测试载重)

压力测试:持续不断的给被测试的系统增加压力,直到被测试的系统压垮为止,用来测试系统所承受的最大压力。(测试强度)

四.冒烟测试和回归测试的概念

回归测试:回归测试是指修改了旧代码后,重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

冒烟测试:指对一个软件进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。

五.单元测试,集成测试,系统测试,验收测试概念

单元测试:是指对软件中的最小可测试单元进行检查和验证

1

集成测试:集成测试是单元测试的下一个阶段,是指将通过测试单元模块组装成系统或者子系统,再进行测试,重点测试不同模块的接口部分。

系统测试:指的是将整个软件系统看做一个1个整体进行测试,包括对功能、性能,以及软件所运行的软硬件环境进行测试。

验收测试:以用户为主的测试,软件开发人员和质量保证人员参加

六.软件生命周期模型

V模型

描述:

V 模型的左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即各测试过程的各个阶段。

V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发各阶段的对应关系

优点:

1 每一个阶段都清晰明了,便于控制开发的每一个过程。

2 既包含单元测试又包含系统测试。

缺点:

1 测试介入的比较晚,对于前期的一些缺陷无从发现和修改。

2 测试和开发串行。

W模型

描述:

相对于V模型,W模型更科学。W模型是V模型的发展,强调的是测试伴随着整个软件开发周期,

而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。测试与开发是同步进行的,从而有利于尽早地发现问题

      优点

    1 测试伴随着软件的整个生命周期,例如,在需求分析结束后就可以进行需求分析测试。

    2 测试于开发是并行独立进行的。

缺点

1 对有些项目,开发过程中根本没有文档产生,故W模型无法使用。

    2 对于需求和设计的测试技术要求很高,实践起来很困难。

1

2

3

4

5

6

7

8

9

10

七.编写测试用例的基本方法以及应用场景

等价类划分,边界值-,错误推测,因果图,场景法,正交表

应用的场景

等价类划分

多用于输入框:注册/登录

边界值

多和等价类划分结合使用,有边界限制的:注册的密码长度,,

场景法

从基本流开始,再将基本流和备选流结合起来,可以确定用例场景 银行取钱

正交表

用于多个下拉框之间的组合,可以通过正交助手生成测试用例

错误推测

错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。

一般这种方法是基于经验和直觉推测程序中可能发送的各种错误,有针对性地设计。只能作为一种补充

因果图

因果图法比较适合输条件比较多的情况,测试所有的输入条件的排列组合。所谓的原因就是输入,所谓的结果就是输出

自动贩卖机

八.测试计划包含什么内容

确定测试范围,制定测试策略,测试资源安排,人员的分配,时间安排,风险分析

九.缺陷报告的八大要素

缺陷编号,缺陷状态,缺陷标题,严重程度,优先级,重现步骤,缺陷类型,测试环境(指派人员,抄送人员,截至日期)

十.bug生命周期

new(新建),open(已打开),fixed(已修复),closed(已关闭),reopen(重新打开)

首先测试人员提交Bug,这时Bug的状态标识为“新建”;

开发经理确认后将Bug分配给相关的开发人员去处理,此时Bug状态为“已打开”;

开发人员拿到指派给自己的Bug,开始进行处理,开发人员已经修复了该Bug后,设置Bug状态为“已修复”;

测试人员拿到已经修复的Bug进行验证,如果验证通过,则将该Bug设置为“已关闭”状态;如果验证未通过,则将该Bug设置成“重新打开”

十一.linux基本命令

目录

进入目录: cd 目录名

返回上一级:cd …

进入根目录: cd /

创建目录(新增)mkdir 目录名

修改目录名:mv 目录名称 新目录名称 (剪切:mv 目录名 路径 )

删除目录 :rm -rf 目录名

查看目录:find / -name ‘目录名’ (重点)

查看当前所在的位置:pwd

查看当前目录下的所有文件和目录:ls

查询目录下的详细的文件和目录信息:ll 或者ls -l

查询当前目录下的隐藏文件:ls -a

复制目录: cp 目录名 路径

cp和mv的区别 :cp是复制,mv是剪切

文件

创建文件:touch 文件名

修改文件:vi/vim>>>>i/o/a>>>编辑>>>Esc>>>shift加:>>>wq(保存并退出,q!强制退出,不保存本次编辑)

删除文件:rm -rf 文件名

查询文件:cat/more/less/tail

实时查看文件:tail -f 文件名

查看关键字(一般用在查询日志中的报错信息):grep 关键字(error) 文件(日志)

打tar包:tar -zcvf xxx.tar 目录名

解压tar包:tar -xvf xxx.tar

解压tar包到指定目录下:tar -xvf xxx.tar -C 路径

命令1 | 命令2:管道符(将命令1的结果传递到命令2中)

grep:过滤,经常结合管道符一块使用

查看全部进程:ps -ef

查看指定的进程:ps -ef | grep 名称

杀死进程:kill -9 进程pid

查看全部的端口号:netstat -an

查看指定的端口号:netstat -an | grep 端口号

查看ip:ifconfig

查看网络:ping ip

权限:可读可写可执行:chmod 777 文件名

查看内存:free

查看磁盘信息:df -h

查看CPU信息:top

关机命令

shutdown -h now 立刻关机,其中now相当于时间为0的状态

shutdown -h 10:23

shutdown -h +10 系统再过十分钟后自动关机

重新启动 :reboot 重新启动操作系统

十二.linux环境部署

在公司的共享文件中找到对应的jdk.tar和tomcat.tar包

通过远程连接工具ssh(或者xshell),将这两个包上传到Linux服务器中

解压jdk包(tar -xvf )

然后配置jdk的环境变量,重新加载配置文件

通过Java -version 验证jdk是否配置成功(成功显示jdk版本)

解压tomcat包(tar -xvf)

然后执行./startup.sh启动tomcat服务即可

十三.web项目部署

将开发给的war包,通过远程连接工具放在Linux服务中

找到tomcat中的webapps目录,将war包放在该目录下

启动tomcat即可

访问项目ip:端口/项目名称

十四.移动端测试包括哪些

安装/卸载,业务功能测试,兼容测试,稳定性测试,性能测试,网络测试,界面易用性测试,安全测试

十五.adb常用指令

查看移动端设备:adb devices

1

开启adb服务:adb start-server

关闭adb 服务:adb kill-server

安装apk:adb install apk路径

覆盖安装:adb install -r apk路径

系统程序包:adb shell pm list packages –s

第三方包:系统程序包:adb shell pm list packages –3

手机全部的包:adb shell pm list packages

卸载程序:adb uninstall 包名

把电脑上的文件传到移动端:adb push 电脑中文件路径 移动端路径

把移动端文件传送电脑上:adb pull 移动端文件路径 电脑路径

查看adb命令:adb help

截屏:adb shell screencap -p 移动端路径

查看性能

查看cpu:adb shell dumpsys cpuinfo

查看内存:adb shell dumpsys meminfo

查看磁盘:adb shell dumpsys diskstats

查看电池:adb shell dumpsys battery

清除缓存:adb shell pm clear 包名

查看日志

查询日志 adb logcat

将日志打印在指定路径下:adb logcat >路径

将日志中打印时间:adb logcat -v time

将日志过滤:adb logcat *:W(日志级别)

日志级别有7类:V,D,I,W,E,F,S

十六.monkey命令

adb shell monkey --ignore-timeouts --ignore-crashes -p 包名 -v --throttle 300 -s 种子书 >路径

1

--ignore-timeouts忽略超时

--ignore-crashes忽略奔溃

-p 包名 指定包名

-v -v -v 打印日志详细程度

--throttle 时间 :延迟等待时间

-s 种子书

>路径 :将日志打印在指定路径下

十七.bs和cs区别

B/S 只需要有操作系统和浏览器就行,可以实现跨平台,客户端零维护,但是个性化能力低,响应速度较慢

C/S响应速度快,安全性强,一般应用于局域网中,因为要针对不同的操作系统,需要针对性的开发,并且维护成本高

十八.什么是http协议

HTTP是hypertext transfer protocol(超文本传输协议)的简写,它是TCP/IP协议的一个应用层协议,用于定义WEB浏览器与WEB服务器之间交换数据的过程。客户端连上web服务器后,若想获得web服务器中的某个web资源,需遵守一定的通讯格式,HTTP协议用于定义客户端与web服务器通迅的格式

十九.http1.0和http1.1的区别

在HTTP1.0协议中,客户端与web服务器建立连接后,只能获得一个web资源。

  在HTTP1.1协议,允许客户端与web服务器建立连接后,在一个连接上获取多个web资源

二十.http请求方式

Get:向特定的路径资源发出请求,数据暴露在URL中,

Post:向指定路径资源提交数据进行处理请求(一般用于上传表单或者文件),数据包含在请求体中

Options:返回服务器针对特定资源所支持的HTTP请求方法,允许客户查看,测试服务器性能,

Head:向服务器与get请求相一致的响应,响应题不会返回,可以不必传输整个响应内容,

Put:从客户端向服务器传送的数据取代指定的文档的内容,

Delete:请求服务器删除指定的页面,

Trace:回显服务器收到的请求,主要用于测试或诊断,

Connect:HTTP/1.1协议中预留给能够将连接改为管道模式的代理服务

二十一.常见的http请求(get和post区别)

GET使用URL或Cookie传参。而POST将数据放在BODY中。

 GET的URL会有长度上的限制,2kb,则POST的数据则可以非常大。

 POST相比GET更安全,因为数据在地址栏上不可见。

 一般get请求用来获取数据,post请求用来发送数据。

二十二.http状态码

100 发起请求

200 客户端请求成功

400 客户端请求有语法错误,不能被服务器所理解

401 请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用

403 服务器收到请求,但是拒绝提供服务

404 请求资源不存在,eg:输入了错误的URL

500 服务器发生不可预期的错误

503 服务器当前不能处理客户端的请求,一段时间后可能恢复正常

二十三.cookie概念

Cookie是客户端技术,服务器把每个用户的数据以cookie的形式写给用户各自的浏览器。当用户使用浏览器再去访问服务器中的web资源时,就会带着各自的数据去

二十四.session概念

当用户打开浏览器,访问某个网站时,服务器就会在服务器的内存为该浏览器分配一个空间,该空间被这个浏览器独占,这个空间就是session空间,该空间的数据默认存在时间为30min,也可以修改

二十五.cookie和session的区别

数据bai存放位置不同:

cookie数据存放在客户的浏览器上,session数据放在服务器上。

安全程度不同:

cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。

性能使用程度不同:

session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用cookie。

数据存储大小不同:

单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie,而session则存储与服务端,浏览器对其没有限制。

会话机制不同

session会话机制:session会话机制是一种服务器端机制,它使用类似于哈希表(可能还有哈希表)的结构来保存信息。

cookies会话机制:cookie是服务器存储在本地计算机上的小块文本,并随每个请求发送到同一服务器。 Web服务器使用HTTP标头将cookie发送到客户端。在客户端终端,浏览器解析cookie并将其保存为本地文件,该文件自动将来自同一服务器的任何请求绑定到这些cookie。

二十六.charles的7个功能操作

26.1:断点调试

方法一: breakpoints(修改request)

接口处 鼠标右击,选择breakpoints(允许本接口使用breakpionts功能)

开始设置断点值

输完值记得点【ok】按钮保存设置。。。

4.重新请求接口(charles的界面变为可编辑状态),修改请求参数,执行请求

5.关掉breakpoint,点击【abort】

如果点击了【cancel】,只关闭此次编辑。下次访问此接口时还会进入breakpoints页面。

方法二: breakpoints(修改response)

接口处 鼠标右击,选择breakpoints(允许本接口使用breakpionts功能)

开始设置断点值

输完值记得点【ok】按钮保存设置。。。

4.重新请求接口(charles的界面变为可编辑状态),修改请求参数,执行请求

5.刷新页面,请求接口(返回值便是上一步已经修改好的值)

6.关掉breakpoint,点击【abort】

如果点击了【cancel】,只关闭此次编辑。下次访问此接口时还会进入breakpoints页面。

26.2:本地修改

对于maplocal功能的理解:

接口返回值通过抓包工具处理成了 一个本地文件。这个本地文件中的设定值被作为接口返回值了。

复制 response内容,保存为.txt 文件,存在电脑本地。

注意:

保存为txt 后,将文件“另存为”编码方式选择utf-8,否则接口可能无法识别汉字导致出现乱码

2.修改response指向(选中需要修改response值的接口 后点击右键,选中maplocal功能)

注意:记得点击【OK】键才能将配置保存成功!!!

3.修改txt文件中 需要修改的字段值,保存

4.重新请求此接口,此时接口返回值已经是 txt文件中的期望值了

5.不用的时候,关掉maplocal。

26.3:弱网测试

模拟超慢网速(会导致接口数据返回超时的那种...)

设置带宽和延迟时间(毫秒)

注:可以根据下图中的翻译体会下导致网络延迟的原因:

2.打开 throt settings (功能生效后 接口数据返回会很慢)

26.4:模拟403/404

1.tools——>blacklist

2.允许启用黑名单功能,选择接口返回错误的形式(404 或者403),添加接口地址并保存

注:【blocking connection】 选项可以选择“drop connection”或者 “403 respose”.前者接口会直接返回404错误,后者接口返回403错误

3.选中需要返回404/403的接口,点击【ok】

26.5:屏蔽web网页的抓包信息

应用场景:屏蔽web网页的抓包信息

proxy-->windows proxy(前面没有对勾,就不会抓到 PC浏览器的包)

proxy-->macOS proxy(mac电脑)

26.6:关注接口

抓包列表中有好多抓包结果是我们不会关注的,用下面的方法可以让这些我们不关注的接口在列表中隐藏

添加关注的接口

注:host : *baidu* 代表 host中含有"baidu"字符的所有host

      protocol :http 或者https. 如果什么都选,代表 两中协议都会生效,相当于二者兼选

      port:  protocol为http 时填  80  ,protocol 为https时填 443  。什么都不填也没有关系。

2.启用关注接口

3.重新抓包结果

不在上一步配置中的接口,都会隐藏在other host中

26.7:简单压力测试

接口请求次数、并发量、请求延迟时间均可配置

1.选中需要进行测试的接口,鼠标右键 选中【repeat advance】

2.

下面的图中,选择了三个接口,每次迭代中3个接口同时请求,迭代1000次(总计请求3000次接口),

每个接口每次并发100次请求。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

二十七.bug优先级

紧急、高、中和低

紧急的意思就是必须立即修复/在下一次构建中修复;

高的意思是必须在任何即将发布的版本中修复;

中的意思是可在发布后/下次发布时修复;

低的意思是能修复,也可能不修复。

二十八.测试的设计点

功能测试:

1.杯子能否装水;

2.杯子的厚度和高度是否与规格说明书一致

3.杯子是否可以放冰箱;

4.水可不可以被喝到。

5.是否容易变形

6.是否防摔

8.是否漏水

9.能承受的最低最高的温度

10.杯子的容量与生产要求是否一致

11.纸杯装完水后放在桌子上是否平稳

12.防风性如何,多大的风力杯子会被吹倒

13.杯子的重量是否和生成要求一致

14.杯子是否有刻度线

15.杯子上是否有有二维码,二维码是否能扫描成功

安全性测试:

1.杯子有没有毒和细菌;

2.杯子的材料是否符合国家安全标准

3.杯子是否有缺口,容易滑倒嘴巴;

4.杯子是否你有异味

5.杯子的材料是否有毒

6.杯子在高温的情况下会不会释放有毒物质

7.杯子的的东西会不会和杯子的材料发生反应,释放有毒物质

8.杯子是否在安全日期内

9.杯子内壁上的材料,是否会溶解到水中

10.杯子是否容易长细菌

11.杯子对环境的危害程度

性能测试:

1.看杯子能够容纳的最大体积和最高温度;

2.疲劳测试:将杯子盛上水,经过24小时后查看杯子的泄露情况和时间;

3.将杯子装上水,看不会摔破的最高度;

4.用根针并在针上面不断加重量,看压强多大时会穿透;

5.杯子在多大的压力下会变形

6.杯子的最大使用次数

7.耐热性,是否变形

8.耐寒性,是否变形

9.杯子在潮湿环境下的腐化速度

易用性测试:

1.杯子是否好拿,

2.是否烫手,

3.是否防滑,

4.是否方便饮用。

5.纸杯的手感是否舒服

6是否容易清洗

7.使用简单,容易操作

8.杯壁是否光滑

兼容性测试:

除了装水,是否还可以装其它的液体,比如果汁,汽油,调料,酒精等。

界面测试:

1.查看杯子的形状是否符合大众要求:

2.颜色搭配是否合理,,

3.杯子的图案是否合法

4.杯子的图案是否容易掉落

5.杯子的商标是否正确

6.杯子内壁上的涂料是否容易脱落

7.杯子的形状是否与规格说明书一致

8.二维码的形状是否好看

界面测试:

外观(里面、外面)美观性

电梯空间尺寸是否和设计尺寸一致

按钮是否清晰和易懂

显示楼层的显示屏是否安装

是否联系外界的电话、紧急电话

设备检测说明书

安全规范说明书

标识的承重和人数

扶手

镜子

仅提供可到达楼层的按钮

电梯制作的材料

功能测试:

测试电梯能否实现正常的上升和下降功能,每层是否都可以停靠。

每层停靠楼层是否与所按的楼层一致

电梯按键在按下时是否点亮按键灯

电梯在每个楼层的上行和下行的申请是否可以有效

电梯满负载的时候,是否会忽略其他楼层外部的上行和下行申请

电梯的两边按钮是否都可以使用,三列按钮。

电梯的楼层选择是否可以取消

电梯门的打开,关闭是否正常关闭(自动关闭)。

报警装置是否可用。(满载)

超重时是否能强制关门

超重时重新挪动一下人员是否可以上下行

与另外一部电梯之间是否协作良好。(算法)

电梯的灯光是否满足看书的要求

联系外界的电话是否可用

通风状况如何,人多的时候是否会很热,通风不畅(排气扇)

电梯里面的摄像头是否可用,拍摄是否清晰

门不夹人

伸手的话,应该不会强制关门

管理员可以和内部人通话

在各种场合下,可以强制开门

运行中时,不能按开门键,不会强制开门

在不同情况下(如:有人挡着、马上关门的时候、停电的时候、没有请求的时候…),一直按开门键和关门键

从电梯外部可以强制开门

不同温度下的测试

进入电梯,拨打手机,是否有信号

进入电梯喊话,外面是否能听到

楼层显示屏显示的楼层、以及电梯运行升降状态是否正确

两台电梯能否同时使用(或停用)

其中一台使用,另一台是否可以停用

A电梯按上行,B电梯按上行

A电梯按上行,B电梯按下行

A电梯按上行,B电梯按上下行

A电梯按上行,B电梯按下上行

A电梯按下行,B电梯按下行

A电梯按下行,B电梯按上下行

A电梯按下行,B电梯按下上行

A电梯按上下行,B电梯按上下行

A电梯按上下行,B电梯按下上行

电梯空时如何运转

电梯门开时不进电梯

进入电梯后不做任何操作

电梯门开的时间多长,超过时间后是否自动关门

电梯门开的时间超时后关门到最后2厘米,是否可以撬开门

电梯门关闭后还未上升时,电梯外按下上行(或下行)按钮,电梯门是否会打开

电梯最底层是否有下行按钮

电梯最顶层是否有上行按钮

停靠算法测试:

2部均空闲时,采取就近原则,离乘电梯人最近的电梯优先运行;

有1部运行时,以同行方向且顺路的电梯优先运行,否则安排空闲电梯;

2部均运行时,以方向通行且顺路的电梯优先运行;

每部电梯,在电梯内部每层在上升和下降过程中,再电梯内部均申请每层停靠

每部电梯,在电梯内部每层在上升和下降过程中,再内部没有任何申请的情况下,在电梯外部均申请每层停靠

每部电梯,在电梯内部每层在上升和下降过程中,再电梯内部均申请每层停靠,在电梯外部也申请每层停靠

电梯本来在1楼,如果有人按18楼,那么电梯在上升到5楼的时候,有人按了10楼,这时候是否会在10楼先停下来

电梯下降到10层时显示满员,此时若8层有人等待电梯,是否在8层停。

类似7、8测试步骤地随机测试,在电梯内部和外部均有不同组合申请的情况下,验证楼层停靠是否准确和合理。

电梯的平稳性,是否会上升过快或者下降过快,造成人体不适应反应

可靠性:

无任何申请的时候,可以长时间停留在某层,并且门是关闭的

门关上的一刹那出现障碍物。

长期有障碍物在门口堵住,电梯应该也不会关门或上升和下降

同时按关门和开门按钮。

快速交替按关门开门按钮

点击当前楼层号码。

快速点击不同楼层

上升到顶层后,电梯中的原有下楼请求均会被取消

下降到负楼层后,电梯中的原有上楼请求均会被取消

电梯外部同时按上键和下键会怎样。

长按打开按钮,电梯门是否持续打开

突然停电或超载时的情况,电梯(停靠、正在上升、正在下降)不会坠落,电梯门可以通过外力打开,并且紧急电话可用

电梯运行中,申请马上要经过的楼层停靠,电梯应该不会停靠。

在电梯里面蹦跳,电梯不会出现不稳定的情况。

电压不稳定的情况下的电梯运行情况

电梯不能正常工作的时候是否有监控系统自动报警

电梯不能正常工作的时候,是否有流程可以精确的指定到人进行所有故障解决的高效处理

易用性:

电梯的按钮的设计符合一般人使用的习惯吗.

按钮是否考虑残疾人和小孩儿

楼层显示屏是否处于电梯的上部,方便别人看到

可维护性

是否有方便维修和维护电梯的工作条件(竖井通道、统一断电等)

电梯的常用配件是否容易更换

电梯的维修成本如何

电梯的安装、维护、测试

超过维修年限,是否可以正常运转

二十九.你在项目中印象最深的bug

三十.开发认为不是bug的时候

三十一.接口的测试用例有哪些

用例编号,用例描述,接口地址,请求方式,请求头,请求参数,请求数值,预期结果,实际结果

三十二.http和https的区别

安全性上,HTTPS是安全超文本协议,在HTTP基础上有更强的安全性。简单来说,HTTPS是使用TLS/SSL加密的HTTP协议

申请证书上,HTTPS需要使用ca申请证书

传输协议上, HTTP是超文本传输协议,明文传输;HTTPS是具有安全性的 SSL 加密传输协议

连接方式与端口上,http的连接简单,是无状态的,端口是 80; https 在http的基础上使用了ssl协议进行加密传输,端口是 443

————————————————

版权声明:本文为CSDN博主「skk_ks」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/skk_ks/article/details/112174400

©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

相关阅读更多精彩内容

  • 测试发现bug 开发不认为是bug的时候你怎么办? 1.1、首先明确开发说不是bug的理由。 1.2、如果是需求变...
    贩低阅读 699评论 0 0
  • 兰瑟作为一个已经工作有4年经验的测试工程师,其间也辗转了几个大的互联网公司,虽然确实缺少了一些稳定性,但同时也积累...
    依然小阿K阅读 1,238评论 0 5
  • 1.测试流程 开始测试前准备-->需求分析-->测试设计(测试计划,测试用例)-->执行测试--> 提交BUG--...
    秃头测试员阅读 1,190评论 0 14
  • 1.测试流程 开始测试前准备-->需求分析-->测试设计(测试计划,测试用例)-->执行测试--> 提交BUG--...
    2640a8321f43阅读 733评论 0 0
  • 夜莺2517阅读 127,953评论 1 9

友情链接更多精彩内容