备战2020，软件测试工程师面试题集锦

虽然测试行业在2019不太景气，面试后的一些面试题归集和总结，为了将来面试时使用。

所有的面试题中我发现超过90%都是基础性的面试题，只要有自动化基础，功能测试接触，再加上面试的时候态度ok，且不卑不亢即可。

切记，面试时一定要不卑不亢，切记心浮气躁和心虚，你懂得！

1、http与https有何区别？

答案：
①https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
②http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
③http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
④http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

2、tcp/ip三次握手

①含义理解
TCP/IP协议不仅仅指的是TCP 和IP两个协议，而是指一个由FTP、SMTP、TCP、UDP、IP等协议构成的协议簇， 只是因为在TCP/IP协议中TCP协议和IP协议最具代表性，所以被称为TCP/IP协议。
②三次握手：
1）客户 端发送一个带SYN标志的TCP报文到server。这是三次握手过程中的报文1。
2） server端回应client的，这是三次握手中的第2个报文。这个报文同一时候带ACK标志和SYN标志。因此它表示对刚才clientSYN报文的回应。同一时候又标志SYN给client，询问client是否准备好进行数据通讯。
3） 客户必须再次回应服务段一个ACK报文，这是报文段3。
4）连接终止协议（四次握手）

3、悲观锁和乐观锁

悲观锁：
悲观锁原理是每次获取数据的时候，都会担心自己数据被修改，所以每次获取数据的时候都会进行加锁，确保在自己使用的过程中数据不会被别人修改，使用完成后再进行数据解锁。由于数据进行加锁，期间对该数据进行读写的其他线程都会进行等待。在Java中，synchronized的思想也是悲观锁。（如：同一个数据库表A用户在操作时B用户不能进行操作）
适合写入较频繁场景，如出现大量的读取操作，每次读取都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。

乐观锁：
适合读取操作比较频繁的场景，如果出现大量的写入操作，数据发生冲突的可能性就会增大，为了保证数据的一致性，应用层需要不断的重新获取数据，这样会增加大量的查询操作，降低了系统的吞吐量。
(如：A用户操作一个表，B用户同时操作这个表，乐观锁认为不会冲突，但实际会造成冲突)

4、左连接、右连接和全连接

左连接：左边有的，右边没有的为null
右连接：左边没有的，右边有的为null
内连接：显示左边右边共有的

5、数据库中sum和count的区别以及使用

一般面试会把sum与order by 分组一起使用
count:统计你查询出来的数据记录条数：select count(*) from 学生表；
sum:求和：select sum(chengji) from 学生表 where name='张三'；

6、软件测试方法有哪些？

黑盒、白盒、灰盒

7、jmeter中跟踪重定向和自动重定向区别？

1）跟踪重定向通俗的理解就是跟踪请求执行的过程，并记录一些信息给开发者看到，我们一般可以在结果日志和监控中看到
2）自动重定向是不用跟踪请求执行过程，也不用记录

8、设计一个模块测试用例

考察面试者的经验、用例设计能力、思维、以及掌握的测试方法是否全面
从功能测试、接口测试、异常测试、性能、安全测试方面分析

9、自动化测试selenium 显示等待和隐式等待

显示等待就是有条件的等待，隐式等待就是无条件的等待
显示等待：
设置等待时间
WebDriverWait(driver, 3, 0.5) #传入三个参数，第一个是浏览器驱动，第二个是等待多少秒，第三个是每隔多少秒监控一次
原理：指定一个等待条件，和一个最长等待时间，程序会判断在等待时间内条件是否满足，如果满足则返回，如果不满足会继续等待，超过时间就会抛出异常
隐式等待：
browser.implicitly_wait(10) #直接等待10秒钟
当查找元素或元素并没有立即出现的时候，隐式等待将等待一段时间再查找 DOM，默认的时间是0

10、pytest如何管理测试用例？

1）掌握案例规则，如以test开头，类以Test命名等
2）案例文件执行单个py如何执行，多个文件夹的管理方式

11、cookie、token、session的区别

优先级
Cookie<session<token
安全性
Cookie:
①cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session；
②HTTP是一种无状态协议,服务器没有办法单单从网络连接上面知道访问者的身份,为了解决这个问题,就诞生了Cookie；
Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie，客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
session:
①session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie；
②关闭浏览器不会关闭session，它具失效日期，失效后服务器认为客户端停止了活动，并删除session以节省空间；
Token:
①作为身份认证 token安全性比session好，因为每个请求都有签名还能防止监听以及重放攻击；
②Oauth token提供的是认证和授权，认证针对用户，授权针对app；
③token的生成一般是采用uuid保证唯一性，当用户登录时为其生成唯一的token，存储一般保存在数据库中。token过期时间采用把token二次保存在cookie或session里面，根据cookie和session的过期时间去维护token的过期时间；

12、软件测试结束的标准是什么？

单元测试退出标准

1) 单元测试用例设计已经通过评审
2) 核心代码100％ 经过Code Review
3) 单元测试功能覆盖率达到100％
4) 单元测试代码行覆盖率不低于80％
5) 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准
6) 不存在A、B类缺陷
7) C、D、E类缺陷允许存在
8) 按照单元测试用例完成了所有规定单元的测试
9) 软件单元功能与设计一致

集成测试退出标准

1) 集成测试用例设计已经通过评审
2) 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改
3) 按照集成构件计划及增量集成策略完成了整个系统的集成测试
4) 达到了测试计划中关于集成测试所规定的覆盖率的要求
5) 集成工作版本满足设计定义的各项功能、性能要求
6) 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准
7) A、B类BUG不能存在
8) C、D类BUG允许存在,但不能超过单元测试总BUG的50％。
9) E类BUG允许存在

系统测试退出标准

1) 系统测试用例设计已经通过评审
2) 按照系统测试计划完成了系统测试
3) 系统测试的功能覆盖率达100％
4) 系统的功能和性能满足产品需求规格说明书的要求
5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准
6) 系统测试后不存在A、B、C类缺陷
7) D类缺陷允许存在，不超过总缺陷的5％
8) E类缺陷允许存在，不超过总缺陷的10％
注：这只是一套比较理想化的退出标准，但在实际工作中不可能达到这种程度，尤其是测试覆盖率和缺陷解决率不可能是100%。现在的军方标准是达到99%。对于通用软件来说就要根据公司实际情况了。