【测试开发学习】面向面试篇

  之前只在软件开发课程中学习过一点测试内容，接触过selenium和postman，但入门也无法做到，我将写下测试开发中一些常考的面试题和测试相关内容。

一、测试用例设计方法

1. 什么是测试用例

  测试用例（Test Case），就是为了验证某个需求是否实现、是否存在缺陷，在测试执行之前设计的一套详细的测试方案。测试用例通常由测试标题、前置条件、测试数据、测试步骤、预期结果等组成。
  以下是一个测试用例例子。

2. 为什么需要测试用例

1. 帮助我们理清测试思路及测试过程
2. 可以提前规划好测试数据
3. 记录测试所覆盖的测试内容，记录测试进度

3. 常见的测试用例设计方法

3.1 等价类划分法

  按照数据的特性将所有测试数据划分为若干类，每个类中的其中一个数据与该类中其他数据的作用一致，这种划分数据的方法叫等价类划分法。

  等价类划分具备三个特性：

• 完备性：所有划分子集合的并集为整个集合
• 无冗余性：子集间互不相交
• 等价性：属于同一等价类的数据，映射到"相同的执行路径"

  举个例子，需求为：要求用户输入年份，年份限定在1980年~2020年，由4位数字表示。

• 使用等价类划分法，首先确定有效等价类：4位数字字符且年份为1990~2020，然后确定无效等价类：如输入的类型和长度不合理，年份超出范围等，具体如下表所示：
  
• 设计测试用例，覆盖所有的有效等价类和无效等价类：
  

3.2 边界值分析

  经验发现大多数错误发生在输入或输出范围的边界，因此针对各种边界情况设计测试用例，这种为边界值法。
  在使用边界值法时，第一，边界值应为刚刚大于或者刚刚小于边界的值来做测试；第二，除了边界值我们应该考虑默认值、空值、空白、零值和无的情况；第三，除了考虑输入数据，我们也应该考虑输出数据。

  举例子，EXAMPLE 需求：豆瓣用户可在首页搜索框内输入关键词搜索感兴趣的内容。如在豆瓣搜索“星际穿越”。

  使用边界值法设计测试用例，包括输入数据和输出数据：

• 关键词（输入数据）
  • 为空
  • 关键词长度为1（最小长度）
  • 关键词长度为60（最大长度）
  • 关键词长度为61
• 搜索结果（输出数据）
  • 搜索结果为空
  • 有一个搜索结果
  • 有20个搜索结果（一次最多展示20条数据）
  • 有21个搜索结果（通过更多按钮查看）

3.3 流程分析法

  上面两种测试对于单点测试很有效，但实际中，用户可能先搜索《活着》，然后进行查看详情、点击喜欢等操作，不同的事件触发顺序将导致不同的结果，因此我们需要根据场景来设计测试用例，这称为流程分析法或场景法。

  通常我们可以从UX/BA获取流程图，若没有，则只能自己梳理。

  场景法一般包含基本流、备用流和异常流，基本流表示通过业务流程时输入都正确，能达到目标；备选流表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但是经过纠正后仍能达到能达到目标；异常流是指通过业务流程时输入错误（或者操作错误）产生异常终止流程 。

  举例子，EXAMPLE 需求：”豆瓣评分“微信小程序支持用户使用微信登陆，并在登陆时获取用户的手机号码。

注意：上图的右边只包括了基本流和备用流。

3.4 错误推断法

  很多时候，我们依靠自己的直觉和经验来推测可能存在的错误，这种称为错误推断法。

  错误推断法十分依赖个人能力，难以系统化。

二、给定场景，说明测试用例设计思路

  举个例子，针对购物车，设计测试用例。

  我们遵循下列思路来设计测试用例。

2.1 需求分析

  在面试时，与面试官聊清楚需求，主要包括以下三点：

• 确认测试范围
• 确认功能点
• 确认功能流程
  

2.2 不同角度来考虑设计测试用例

  从功能测试、易用性测试、界面测试、性能测试、安全性测试、兼容测试这几个方面来进行考虑。

2.1 功能测试

功能测试可从以下几个角度来考虑。

单个功能测试举例：

场景补充、接口、网络、产品特性测试举例：

2.2 界面测试

1. 界面显示正常
2. 界面布局合理美观
3. 文案展示正确

2.3 性能测试

1. 界面元素多次快速操作
2. 响应时间
3. 并发量
4. CPU
5. 内存
6. App：耗电量、流量、压力测试

2.4 安全性测试

1. 安全性测试
2. 账号限制：登录超时、账号互踢
3. 敏感信息加密传输
4. 漏洞扫描

2.5 兼容性测试

不同产品考虑兼容性测试时，方案也是不同的。

Web产品：

1. 浏览器
2. 操作系统
3. 分辨率

App 产品:

1. 平台
2. 厂商
3. 设备型号
4. 操作系统
5. 分辨率

2.6易用性测试

1. 快捷键功能是否支持
2. 提示信息
3. 操作引导
4. 商品展示排序合理

三、session和token校验的区别

3.1 session和cookie

  举个例子来说明下cookie和session的区别。

在学校旁边的一家面馆，有消费三碗免费一碗的活动。然而一次性消费三碗的可能性很小，需要用某种方式来记录顾客的消费状态，这时就有两种方案：（本人备注：多次消费就相当于多次http请求）

cookie方案: 发给顾客（本人备注：顾客就是客户端，也就是浏览器）一张卡（cooike），上面记录着消费量，一般还有个时限。每次消费的时候顾客只要出示这张卡，则此次消费的状态就被记录下来了。这就是在客户端保持状态。

session方案: 同样发给顾客一张卡（cooike），但是卡上只有一个卡号（session id），用来标识用户身份，其他什么都没有。每次顾客去消费时，只要出示这张卡，则店员就在店里（本人备注：面馆就相当于服务端）的记录本（session）上找到卡号所对应的记录，并且添加一些消费信息。这就是在服务器端保存状态的方法。

由于session方案需要session id(卡号)将客户端和服务器端连接起来，所以一般session机制需要借助cookie来在客户端保存session id。当然除了cookie还有一种url重写的方法也能够实现session机制。

总结

1. cookie保存在客户端，也就是浏览器端。每次往服务器发请求，都会在请求头里带着cookie，缺点显而易见，浪费流量、降低效率。
2. session将用户信息保存在服务端，只需要往客户端的cookie中保存一个session id值就可以了。这样每次往服务器发请求，cookie的size很小，在服务端只需要根据cookie传过来的seesion id进行匹配session，从session中获取用户信息就可以了。

3.2 session校验过程

  用户登录网站时，输入用户名和密码，点击登录，此时浏览器向服务器发送请求，验证通过后，服务器为该用户创建一个session ID然后返回给浏览器，浏览器在随后的请求中携带该session ID，服务器根据ID来识别用户身份。一般该session ID存储在cookie中，然后发送给服务器，服务器取出session ID来判断。

3.3 session测试点

对于测试人员来说，如果使用session技术的话，则在测试中可能会存在以下问题：

1. 某些浏览器禁用cookie,因此出现开发人员无法复现bug，这和测试人员测试效果不同。
2. 由于session保存在服务器端，需要占用空间。

  另外，session一个本身的问题是扩展性不强。如果将来搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，但是session数据是保存在内存中的（不是共享的），用户第一次访问的是服务器1，当用户再次请求时可能访问的是另外一台服务器2，服务器2获取不到session信息，就判定用户没有登陆过。

3.4 token技术

1. token与session的不同主要在服务器认证成功后，会对当前用户数据进行加密，生成一个加密字符串token，返还给客户端（服务器端并不进行保存）

2. 浏览器会将接收到的token值存储在Local Storage中，（通过js代码写入Local Storage，通过js获取，并不会像cookie一样自动携带）

3. 再次访问时服务器端对token值的处理：服务器对浏览器传来的token值进行解密，解密完成后进行用户数据的查询，如果查询成功，则通过认证，实现状态保持，所以，即时有了多台服务器，服务器也只是做了token的解密和用户数据的查询，它不需要在服务端去保留用户的认证信息或者会话信息，这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利，解决了session扩展性的弊端。

四、三次握手和四次挥手

1. 三次握手：当建立连接的时候，客户端和服务器之间需要交换三个tcp报文段。

  刚开始客户端处于关闭状态，服务器处于listen状态。

• 第一次握手：客户端向服务器发送请求建立连接报文，Syn=1,seq=x。
• 第二次握手：服务器端收到客户端的SYN报文之后，如果同意建立连接，就发送确认报文，询问客户端是否做好准备，Ack=1，Syn=1，ack=x+1,seq=y。
• 第三次握手：客户端收到确认报文后，向服务器发送确认。Ack=1,ack=y+1。建立连接。

2. 为什么需要三次握手？两次不可以吗？
     当客户端向服务器端发送请求建立连接时，若该报文因为网络原因暂时无法到达服务器端，而是在网络中某个节点进行滞留了（滞留到之后连接释放以后），这时由于客户端没有收到确认，因此进行重传，再次建立连接，然后传输数据完毕后就释放连接。但若之前的那个连接到达了，那么服务器端就会对该连接发送确认报文。此时不使用三次握手就建立连接，客户端收到该报文并不会理睬它，因此服务器端这时会一直等待客户端传送数据，浪费服务器端的资源。

3. 四次挥手：当要断开TCp连接时，就发送四次报文。

• 第一次挥手，客户端向服务器端发送连接释放报文，停止发送数据。客户端进入终止等待1状态，fin=1,seq=x。
• 第二次挥手，服务器端收到该报文，发送确认报文，Ack=1，ack=x+1,seq=y。此时服务器端进入关闭等待状态，通知高层应用程序，这时处于半关闭状态，客户端不能发送数据，但仍可以接收数据。客户端收到确认报文后，进入终止等待2状态。
• 第三次挥手，服务器端传送完数据，发送fin报文，ack=x+1,fin=1,Ack=1,服务器端进入Last-ack状态。
• 第四次挥手，客户端收到Fin报文后，发送确认报文，服务器端收到确认报文后，关闭连接，而客户端需要等待2msl之后才会关闭连接。

4. 为什么需要等待2msl？
   ● 这是为了保证客户端发送的最后一个确认报文可以到达服务器端。如果客户端收到释放连接报文后立即关闭连接，由于最后一个确认报文可能会丢失，则服务器端无法正常的关闭连接。
   ● 为什么不是1msl？最关键的原因是让此次 TCP 连接中的所有报文在网络中消失。在B收到ACK前的一刹那，B可能因为没收到ACK而重传了一个FIN报文，这个FIN报文要从网络中消失最多还需要一个MSL时长，所以A还需要多等一个MSL。

5. 为什么握手是三次，挥手是四次？
     第二次握手时，服务器端将ACK和SYN一起返回。而挥手时，对于第二次和第三次是分别传输的，第二次挥手是为了可以给客户端一个确认，由于tcp是全双工通信，两方都可以发送数据，此时服务器端还有些必要的数据没有发送，因此只是先返回给客户端一个确认，避免fin报文不必要的重传。第三次挥手是为了告诉客户端我不需要再发送数据了。
     第2次和第3次不能合并，因为第一次挥手时，服务器端仍然有未传的数据，而为了避免客户端一直在重传fin报文，因此返回确认。

五、selenium底层原理

WebDriver是用于通过浏览器对WEB应用进行自动化测试的开源工具。它提供了一系列操作浏览器的能力，比如WEB页面的导航、用户输入，js脚本执行等等。ChromeDriver是满足W3C标准WebDriver的针对Chrome浏览器的具体实现，GeckoDriver是针对Firefox浏览器的具体实现，以此类推。

  然后这一系列操作浏览器的能力，都是通过HTTP接口形式进行提供的，即可以通过这些接口达到操作浏览器的目的，这也是selenium操作WebDriver的底层原理。

  我们可以通过postman来手动请求，而selenium就是将这些手动的操作进行封装，提供了更简单的方式供使用。

总结

  今天先到这里了，后续再更新，我对于测试开发内容了解不深，所以可能会有错误，恳请大家指出来，我将改正它。

参考文献

1. 测试用例设计
2. 面向购物车测试用例举例
3. selenium操作浏览器原理