软件测试面试题3自我解答

1、fiddler模拟返回状态码
（1）AutoResponder里面进行模拟状态码，从右边拖一个请求到左边，进入AutoResponder中观察Rule Editor设置状态码，然后保存。
（2）rules中选择breakpoints打断点设置（—还不清楚怎么操作），保存需要修改的页面，修改数据，并加载到AutoResponder窗口
（3）AutoResponder中选中request右击，选择edit response，修改一些数据，保存，进入页面刷新查看是否修改成功
（4）AutoResponder中选择add rule ，在第二个窗口中选择添加文件，保存
mock说的通俗一点就是模拟返回数据，只是面试官为了装逼，搞的这么专业。模拟返回数据，用fiddler打断点修改返回数据和设置AutoResponder都能实现

2、tcp与upd
TCP又叫传输控制协议，TCP是面向连接的，并且是一种可靠的协议，在基于TCP进行通信时，通信双方需要建立TCP连接，建立连接需要经过三次握手，握手成功才可以通信，断开连接需要经历四次挥手才能断开，同时是面向字节流传输
UDP是一种面向无连接，是不可靠的协议，在通信过程中，它并不像TCP那样需要先建立一个连接，只要目的地址，端口号，源地址，端口号确定了，就可以直接发送信息报文，并且不需要一定能收到或者完整的数据。它仅仅提供了校验和机制来保障报文是否完整，若校验失败，则直接将报文丢弃，不做任何处理。同时是面向报文传输
优点：可靠，稳定
TCP的可靠性体现在传输数据之前，三次握手建立连接（四次挥手断开连接），并且在数据传递时，有确认，窗口，重传，拥塞控制机制，数据传完之后断开连接来节省系统资源
缺点：慢，效率比较低，占用系统资源，容易被攻击
传输数据之前建立连接，这样会消耗时间，而且在消息传递时，确认机制，重传机制和拥塞机制都会消耗大量的时间，而且要在每台设备上维护所有的传输连接。而且每一个连接都会占用系统的CPU，内存等硬件软件资源。并且TCP的取而机制，三次握手机制导致TCP容易被人利用，实现DOS，DDOS攻击
优点：快，比TCP安全
UDP没有TCP的握手，确认窗口，重传，拥塞机制。UDP是一个无状态的传输机制，所以在传输数据时非常快。UDP没有TCP这些机制，相应被利用的漏洞就少一点。但是UDP的攻击也是存在的，比如：UDP 的flood攻击
缺点：不可靠，不稳定
因为UDP没有TCP的那些可靠机制，在网络质量不好的时候容易发生丢包

3、Linux命令
touch 创建文件
mkdir 创建文件夹
ls 查看当前目录有多少文件
ls -l 查看当前目录有多少文件，包含隐藏的文件
rm-rf 删除文件
rmdir 删除目录
mv 移动文件或者更换文件名
cp 复制文件
cd 进入文件
cd ~ 进入用户主目录
cd … 返回上级目录
cat 在标准输出上查看文件内容
tail 在标准输出上显示最后10行，如果需要确定几行，可以用-n
tail -f test.log查看日志信息
less 按页打印文件内容，ctrl+f向前翻页，ctrl+b向后翻页
grep 在给定的文件中搜寻指定字符串grep-i表示不区分大小写
find 查找给定位置与条件匹配的文件 find-name区分大小写搜索
tar -cvf创建对应压缩文件
tar -tvf查看对应压缩文件
tar -xvf提取对应压缩文件
gzip创建和提取压缩文件
unzip对zip文档进行解压
whatis解释当前命令
who列出当前已登录的用户名
su切换不同用户
ps显示运行的进程
top显示占用量较大的进程
pwd 当前文件的路径
tail -n 1000：显示最后1000行
tail -n +1000：从1000行开始显示，显示1000行以后的
head -n 1000：显示前面1000行
sed -n ‘5,10p’ test.log 这样你就可以只查看文件的第5行到第10行
echo输出文字到标准屏幕上
其中最重要的是查看日志与进程两个，这里没有写清楚，因为我还不怎么熟悉

4、Java多态继承封装面向对象
封装：将对象的属性和实现细节隐藏，仅对外公开访问方法
继承：在现有类的基础上，新增加或者从写现有方法，产生一个新类
多态：相同事务，调用相同方法，表现行为却不一致（多态的基础是继承）
重写：子类中重写了与父类相同的方法
重载：同一个类中，定义具有相同名称但是型构不同的方法

5、整点秒杀购买项目测试点

6、dns问题，dns根据域名解析ip地址
arp地址解析协议，将ip地址转物理地址
百度一下，你就知道 com是顶级域名 baidu是次级域名（用户可购买） www是三级域名

7、css定位与xpath的区别
xpath定位根据路径确定，可以存在多种方式定位到此元素，css定位根据标签/类/id等，目标是唯一确定的。但是xpath定位更复杂

8、monkey命令

9、get请求长度与浏览器有关吗
是的，get请求的长度与浏览器和服务器都有关系
ie：限制是2083
firefox：限制为 65 536字符
chrome：限制超过8182个字符返回请求参数过长时会返回414错误
safari：限制至少为 80 000 字符
opera：长度限制为190 000 字符
服务器一般使用ngnix（根据配置进行改变长度）和apache（限制8192）

10、直播打赏测试点

11、腾讯视频播放界面测试点

12、支付功能测试点

13、fiddler打断点和弱网
1、通过rules中customerize rules进入，在fiddler script 里修改控制数据上传下载的延迟时间
点击save script 保存
if (m_SimulateModem) {
// Delay sends by 123ms per KB uploaded.
oSession[“request-trickle-delay”] = “300”;
// Delay receives by 24ms per KB downloaded.
oSession[“response-trickle-delay”] = “150”;
Save script
2、在rules performance 里勾选 simulate modem speeds弱网的开关
fiddler菜单栏->rules->automatic Breakpoints->选择断点方式

14、三次握手：客户端请求连接，服务端收到且发送，客户端收到
四次挥手：客户端请求断开，服务端收到，服务端请求断开，客户端收到
第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。 从客户端的视角来看，我接到了服务端发送过来的响应数据包，说明服务端接收到了我在第一次握手时发送的网络包，并且成功发送了响应数据包，这就说明，服务端的接收、发送能力正常。而另一方面，我收到了服务端的响应数据包，说明我第一次发送的网络包成功到达服务端，这样，我自己的发送和接收能力也是正常的。
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。 第一、二次握手后，服务端并不知道客户端的接收能力以及自己的发送能力是否正常。而在第三次握手时，服务端收到了客户端对第二次握手作的回应。从服务端的角度，我在第二次握手时的响应数据发送出去了，客户端接收到了。所以，我的发送能力是正常的。而客户端的接收能力也是正常的
最少是需要三次握手过程的。两次达不到让双方都得出自己、对方的接收、发送能力都正常的结论
为什么建立连接是三次握手，关闭连接确是四次挥手呢？
建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。（因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥）
如果已经建立连接，客户端出现故障
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
为何一定要等2MSL？
如果不等，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络里的老的TCP报文可能与新TCP连接报文冲突，造成数据冲突，为避免此种情况，需要耐心等待网络老的TCP连接的活跃报文全部死翘翘，2MSL时间可以满足这个需求（为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。）

15、http与https区别
HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全

16、查看日志，CPU，内存的adb指令
adb shell dumpsys meminfo 包名------查看包名的内存信息
RSS - Resident Set Size实际使用物理内存（包含共享库占用的内存）是单个进程实际占用的内存大小，对于单个共享库，尽管无论多少个进程使用，实际该共享库只会被装入内存一次
adb shell top -m 10 -s cpu //按照cpu排序，显示前10个 或者adb shell dumpsys cpuinfo
adb shell dumpsys battery 查看电池电量
查看某apk的流量：
首先先查出该apk的uid，ps一下找到应用的pid；
然后拿到pid后，查看uid，直接查看/proc/$pid/status这个文件下，存储了uid；最后通过uid查看/proc/ui{d}_{s}tat/$uid/tcp_rcv 和/proc/uid_stat/$uid/tcp_snd，这两个文件一个是请求耗费的流量，一个是接受的数据流量
*查看进程列表
adb shell ps

17、session与cookie区别：
cookie在第一次浏览网站时，会将一部分信息保存在客户端，然后下次访问时，先看有没有上次访问的cookie信息，如果有就送出指定网页内容。
session是采用在服务器端保持状态的方案，同时需要在客户端也保存一个标识，即session需要借助cookie
cookie有设置过期时间，在关闭浏览器就过期的叫做会话cookie，保存在内存中，否则保存在硬盘中
cookie 和session 的区别：
1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
5、所以个人建议：
将登陆信息等重要信息存放为SESSION
其他信息如果需要保留，可以放在COOKIE中

18、fiddler抓取浏览器（火狐）的包方法：fiddler中复制tools–》options–》connection–》copy xxxxxx
打开浏览器，进入设置，选择网络设置–》自动代理配置–》粘贴刚刚复制的