面试总结：测试常见面试题汇总

理论

测试流程

• 总体流程

1. 测试需求分析：理解需求，学习业务点
2. 制定测试计划：根据测试需求确定测试计划，安排测试人力、进度安排；制定风险评估与规避措施方案
3. 测试设计阶段：设计测试用例并做评审
4. 测试执行阶段：搭建环境，执行冒烟测试（预测试）-然后进入正式测试，bug管理（推进bug修改并做回归测试）直到测试结束
5. 测试评估阶段：出测试报告，并以此评估是否可以上线

各个测试阶段 / 单元测试、集成测试、系统测试区别？

单元测试：是模块测试，验证软件的基本组成单位的正确性，是白盒测试
集成测试：是模块间的测试，测试接口（软件各模块之间的接口和软件与硬件之间的接口）是否正确，是灰盒测试（白盒和黑盒结合）
系统测试：系统测试包括：冒烟测试 系统测试 回归测试
（1）冒烟测试：主干流程测试，确认软件的基本功能正常，可以进行后续的测试工作
（2）系统测试：是检测系统的功能、质量、性能能否满足系统的要求，包括功能、性能、界面、可靠性、兼容性等等，是黑盒测试
（3）回归测试：修改了旧代码之后重新进行测试，确认修改后的代码没有引入新的错误或导致其他代码产生新的错误
验收测试：是确保软件的实现能否满足用户的需求或合同的要求
————————————————
版权声明：本文为CSDN博主「fanfan_1120」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_39294633/article/details/81805893

• 测试与开发的关系-并行
  【软件测试的V模型 & W模型】
  参考
  

测试用例设计

什么是好的测试用例？

ref

方法

• 白盒测试
  白盒测试用例设计有如下方法：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
  依据就是代码结构。
• 黑盒测试
  黑盒测试用例设计方法：基于用户需求的测试、等价类划分方法、边界值分析方法、错误推测方法、因果图方法、判定表驱动分析方法、正交实验法、场景法。
  依据是用户需求规格说明书，详细设计说明书。

【用户登录】实例

• 功能性
  (流程：输入，登录成功后，登录失效；辅助性功能：验证码；场景：不同用户权限，不同创建方式)

用户名和密码是否大小写敏感；
页面上的密码框是否加密显示；
后台系统创建的用户第一次登录成功时，是否提示修改密码；
忘记用户名和忘记密码的功能是否可用；
前端页面是否根据设计要求限制用户名和密码长度；
如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
刷新页面是否会刷新验证码；如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；

• 安全性

用户密码后台存储是否加密；
用户密码在网络传输过程中是否加密；
密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面；
密码输入框是否不支持复制和粘贴；
密码输入框内输入的密码是否都可以在页面源码模式下被查看；
连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。

【web攻击】

用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改；

• 性能压力

单用户登录的响应时间是否小于 3 秒；
高并发场景下用户登录的响应时间是否小于 5 秒；
高并发场景下服务端的监控指标是否符合预期；
高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。

• 兼容性

不同浏览器下，验证登录页面的显示以及功能正确性；
相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
不同分辨率的界面下，验证登录页面的显示以及功能正确性。

App测试和Web测试的区别

• 功能测试
  在流程和功能测试上是没有区别的。系统测试和一些细节可能会不一样。
  web和app的区别。
  • 架构：
    web项目，一般都是b/s架构，基于浏览器的，web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。
    而app则是c/s的，必须要有客户端。但是app端是不能够保证完全一致的，除非用户更新客户端。如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。
• 性能测试
  web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory这些了。
• 兼容性测试
  web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容，不过一般还是以浏览器的为主。而浏览器的兼容则是一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox）。
  app的测试则必须依赖phone或者是pad，不仅要看分辨率，屏幕尺寸，还要看设备系统。系统总的来说也就分为Android和iOS，不过国内的Android的定制系统太多，也是比较容易出现问题的。
• 相比较web测试，app更是多了一些专项测试：
  • 异常场景
    一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断，来电，短信，关机，重启等。
  • 弱网测试
    而弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制。避免用户的流失。
  • 安装、卸载、更新：
    web测试是基于浏览器的所以不必考虑这些。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app相关的文件等等。
  • 界面操作：
    现在app产品的用户都是使用的触摸屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，事件触发区域等测试。

ref: app测试与web测试区别

典型测试场景

聊天功能测试用例怎么设计？

ref: 聊天类APP的测试点

怎么测试微信朋友圈？【TODO】

怎么测试微信红包？

客户端测试：分功能，性能，兼容性（手机端-不同系统，电脑端等），易用性（界面友好，语音输入等），安全性

ref: 微信发红包-测试用例（全）

补充：抢红包场景&随机红包算法

• 抢红包场景 （参考：高并发-抢红包实现）
  全链路：发红包，拆红包，转账，入账
  难点：随机红包，并发问题 （参考：图解随机算法，简单模拟-提前算好随机数）

问题分析

多个 API 连续调用的测试用例设计难点是什么？你是如何解决的？

重点：多个API调用间参数的传递

单个 API 测试并不难，难的是多个 API 的连续调用，并且后一个 API 的参数值使用的是前一个 API 调用的返回结果，这就要求多个 API 调用之间可以方便地进行参数传递。一个最典型的场景就是，前一个 API 调用会返回一个有效的 token，后一个 API 调用需要带着这个 token 才能调用成功。
为了解决这个问题，一般来讲有三种处理方法：
第一种方法是，手工复制前一个 API 返回结果中的某个值，然后粘贴给后一个 API 作为输入参数。当然，这是最基本的方法，但是效率太低，而且无法实现自动化。
第二种方法是，使用基于代码的 API 测试框架。由于此时所有的测试逻辑都是通过代码来实现的，因此可以很容易地实现 API 之间的参数传递。
第三种方法是，借助于类似 HttpRunner 之类的已有 API 测试框架。此类框架可以通过关键字，很方便地将前一个 API 的返回值中的某个值传递给下一个 API 作为输入参数。

性能压测过程中，当面对大量并发用户调用的时候，服务器端 CPU 的使用率是高好还是低好？为什么？

重点：理解性能测试指标解读的复杂性，必须要全盘考虑多个指标间的相互关联和制约。

这个问题的答案，一定会有坚持不同意见的两派人。
一部分人认为，CPU 使用率当然是越低越好。这说明后端代码实现得很高效，只占用很少的计算资源就能实现较高的并发。并发情况下，越低的 CPU 占用率，说明系统可以继续承载越多的并发负载。
而另一部分人则认为，CPU 的使用率是越高越好。这说明系统的计算资源被充分利用了起来。

你同意哪个观点呢？其实，这个问题本身就是个伪命题，单单通过题干中的信息是不足以给出孰好孰坏的结论的。
这里的关键是，随着并发用户数的上升，事务的响应时间是如何变化的。如果随着并发用户数的增加，事务的响应时间也呈线性增长，但 CPU 的使用率一直上不去，这就是典型的 CPU 资源没有被充分利用的现象。此时，你就需要去进一步诊断为什么 CPU 资源不能在并发场景下被充分利用。而如果随着并发用户数的增加，事务的响应时间能基本保持稳定，同时 CPU 的使用率会随着并发用户数的增加呈线性增加，这反倒是我们希望看到的结果，也就是说更多的并发用户会需要使用更多的 CPU 资源。

网页很卡是为什么？

• 本机硬件原因
  带宽不足、硬件配置低、CPU或者是内存被占满。

ref:网页加载慢，你知道几种原因？

• 网络原因 (可以打开浏览器开发者工具查看瀑布图)
  http请求次数太多
  接收数据时间过长，如下载资源过大
  JS脚本过大，阻塞了页面的加载
  网页资源过多、接受数据时间长、加载某个资源慢
  DNS解析速度

ref: 网页很卡的原因

APP闪退的原因总结

• 移动端设备原因
  • 缓存过多
  • 运行的程序过多
  • 杀毒软件干扰

  部分软件存在着恶意代码，会被杀毒软件拦截或者由于安全软件误将前台软件当做后台软件清理所致

  • 系统进程被卸载、停用或丢失
  • 系统存储空间严重不足

  部分应用需要不停的读写数据从而占用系统存储空间，当系统空间严重不足可能会出现卡顿、闪退甚至是死机的现象

• APP与移动端设备不兼容
  • 分辨率不兼容
  • 应用版本问题

  应用版本太低，会导致不兼容，造成闪退。（有些API在老版本中有,在新版本中没有,造成对象为空引起闪退）

  • 系统不兼容：APP的SDK和手机的系统不兼容

ref: APP闪退的原因

• 软件条件与APP本身缺陷
  • 网络条件不好

  弱网络情况下，服务端响应不及时，可能倒是闪退。（网络异常引起的）

  • 设计不合理
    e.g: 1) 1个接口，拉取的数据量太大，请求结果会很慢，且占用大量内存，APP会闪退（比如，我们现在做的记录仪，进入相册列表时候，要拉取所有图片，拉取太慢了，就闪退了）
    代码缺陷：空指针、空数组、死循环……

ref: Android中造成APP闪退的原因总结