测试开发面经

0. 吹水环节

参考链接

添加链接描述
添加链接描述
添加链接描述

0.1 为什么选择测试开发 (为什么做测试，不做研发)

首先，我认为的测开是测试和开发工作都在做的。
一方面，据我了解，在近几年，国内对软件测试越来越重视，并且从用户角度来说，对于同类产品，可能会更加注重产品的质量和服务，所以我觉得测试的发展前景是非常好的。
其次，测试在一个项目开发的过程中是非常重要的一环。测试是产品上线的最后一道把关，如果测试工作做得到位，就能避免很多的问题，像最近中秋国庆12306高峰期买票老进不去，这其实就是性能做的不够好。测试人员的责任非常大，责任越大成就感就越大。我很喜欢这样的工作。
另一方面，测开还有一部分开发工作，无论是自动化脚本还是测试工具或框架，都提高了测试的效率，为质量效率保证工作提供了有力的保障。并且测开的所需技术广度也是很高，所以我认为测开会激发我对这个岗位的热爱和持续学习的态度。

0.2 怎么理解测试开发

首先从岗位名字来看，要求测开工程师即要懂测试，又要懂开发。其次这个岗位融合了开发角色和质量意识，要求我们兼具开发人员的技能和测试人员的思维。总的来说，测试开发工程师的定位就是保障产品的质量和提高测试的效率。

0.3 个人做测试开发有什么优势

技能点：会开发，了解测开的基本理论
性格优势：
有责任感，举例：实习过程中赶需求愿意加班，按时按质量的提交需求，有实际项目开发经验，明白测试在整个项目的重要性，举例实习过程中测试部门会反馈给我们问题；
做事细致，有条理，会事先做好详细的计划安排，本科组织部经历 + 比如实习过程中，写接口前会写好接口文档，写完接口后，会进行测试，设计好详细的测试样例，比如… ;

0.4 职业路线

初级测试工程师：测试计划、测试文档、测试执行、结果整理等，门槛不高。
测试开发工程师：核心-编程能力、自动化能力。
测试架构师：在整个测试架构上参与和管理测试，更强调测试流程管理和质量监管，以及白盒测试能力，对测试工具和平台的开发等

1. 给你一个购物车界面，你怎么测试?

• 需求分析
  首先第一步要做的就是需求分析。不管是在什么场景中，都应该明确需求之后，再开始进行测试用例的设计。
  在面试中，这一步可以体现为与面试官聊一聊需求的细节。
  重点需要把 3 个方向的内容确认清楚：
  确认测试范围
  确认功能点
  确认功能流程
  使用思维导图的形式来梳理
  

下面就按照上面思路来梳理购物车的测试点。

• 界面测试
  界面显示正常
  界面布局合理美观
  文案展示正确
• 功能测试
  测试功能可以从这几个方面去考虑
  
  具体的测试点比较多，请直接查看完整的思维导图。
• 易用性测试
  快捷键功能是否支持
  提示信息
  操作引导
  商品展示排序合理
• 兼容性测试
  不同的产品在考虑兼容性测试的时候，方案是不一样的。
  Web 产品的兼容需要重点考虑
  浏览器
  操作系统
  分辨率
  App 产品的兼容需要重点考虑
  平台
  厂商
  设备型号
  操作系统
  分辨率
  对于兼容性测试来说，需要保证在这些硬件环境中，产品的界面展示正确，功能可以正常使用。
• 性能测试
  界面元素多次快速操作
  响应时间
  并发量
  CPU
  内存
  App：耗电量、流量、压力测试
• 安全性测试
  账号限制：登录超时、账号互踢
  敏感信息加密传输
  漏洞扫描

2. 黑白盒测试

• 白盒测试是：

  也称逻辑驱动测试，测试者知道被测对象的内部结构和逻辑实现，将其视作一个透明的盒子，针对其中实现细节的状态、结构、路径进行测试覆盖
  目的主要是验证「白盒子」内部的结构和运作是正常的
  常通过单元测试动态地进行测试，或code review的方式静态地进行检查

• 黑盒测试是：

  也称数据驱动测试，测试者无需知悉被测对象内部实现方式，将其视作一个黑色不透明的盒子，只考虑对产品明确提供的功能特性针对性进行输入，检测其输出
  目的主要是验证「黑盒子」承诺对外提供的功能是否按规范、规格说明的要求正确实现了
  常通过在用户界面（GUI），以用户的角度进行有效、无效操作

3. 秒杀场景怎么设置测试用例

设计秒杀场景的测试用例时，需要考虑以下几个方面：

并发场景：测试在高并发下系统的稳定性和性能。可以模拟多个用户同时参与秒杀活动，设置不同的线程数和请求间隔时间，测试系统的响应时间和吞吐量等指标。
库存场景：测试系统对库存的管理和控制。可以设置不同的库存数量和秒杀人数，测试系统是否能正常抢购并准确控制库存数量。
安全场景：测试系统的安全性。可以模拟攻击者对系统进行DDoS攻击或SQL注入等攻击方式，测试系统的抗攻击能力。
异常场景：测试系统处理异常情况的能力。可以模拟网络故障、服务器宕机、重启等异常情况，测试系统是否能够快速恢复和处理异常情况。
业务场景：测试系统对业务逻辑的处理能力。可以模拟不同的用户身份、优惠券使用、活动时间等不同的业务场景，测试系统的处理能力和正确性。

例如，可以设计以下测试用例：

在高并发场景下，测试系统的响应时间和吞吐量是否满足要求。
设置不同的库存数量和秒杀人数，测试系统是否能正常抢购并准确控制库存数量。
模拟攻击者对系统进行DDoS攻击或SQL注入等攻击方式，测试系统的抗攻击能力。
模拟网络故障、服务器宕机、重启等异常情况，测试系统是否能够快速恢复和处理异常情况。
模拟不同的用户身份、优惠券使用、活动时间等不同的业务场景，测试系统的处理能力和正确性。

4. 软件测试流程

需求调查：全面了解系统概况、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价，制定测试计划。
测试设计：按照测试计划完成测试设计，包括测试用例的设计，并且对编写完毕的测试用例进行评审和完善。
测试执行：按照测试计划执行测试用例，并对 Bug 进行跟踪管理。
在开发提测之后，先执行冒烟用例（冒烟测试就是版本转测试之前，对系统的基本功能进行简单的测试），冒烟测试通过之后，再执行其他用例。
在执行测试用例过程中，要根据用例步骤操作系统，对比执行出来的实际结果和预期结果是否一致。
如果一致测试通过。
实际结果与预期结果不一致测试失败，需要提交 Bug 进入 Bug 管理流程。
Bug 修改好之后要回归验证，确认改好了并且没有新增问题。
老功能回归测试。
测试评估：总结测试工作。根据测试的结果，出具测试评估报告。
上线：监控线上产品，及时发现并解决线上问题。

5. 微信朋友圈点赞测试用例

5.1 功能

• 能否点赞成功
• 点赞成功后
  能不能看到共同好友的点赞
  对方能否收到你的点赞消息提示
  共同好友点赞后，会有消息提示吗?
  是否可以实时显示点赞信息
• 能否看到非好友的点赞。
• 你能给自己竖起大拇指吗?
• 可以多次点赞吗?
• 可以取消点赞吗?
• 取消点赞后，对方还能看到你的点赞信息吗?
• 显示的点赞信息最多可以连续显示
• 一行满后会自动换行吗
• 点赞数有限制吗
• 点击喜欢的人的名字，是否可以跳转到他们的主页信息
• 点赞信息会按照点赞时间依次显示吗

5.2 性能表现

• 从点赞到显示点赞信息的响应时间
• 从取消点赞到成功取消点赞的响应时间
• 点赞到对方收到点赞消息提示的响应时间
• 连续点赞和取消点赞，还能正常使用吗

5.3 界面

• 是否可以显示点赞数
• 是否可以显示点赞的人的名字(昵称、评论名)
• 点赞栏的位置
• 如果朋友圈有图，在图下方显示
• 如果只有文字，则显示在文字下方

5.4 兼容性

• Android系统是否可以点赞，点赞功能是否正常
• 在苹果系统上是否可以点赞，点赞功能是否正常
• PC端朋友圈是否可以点赞

5.5 网络和异常测试

• 在网络较弱(2G、3G、wifi、信号弱)的情况下，是否可以点赞
• 在不同的网络操作中，like功能是否正常
  　　·中国移动
  　　·中国电信
  　　·中国联通
• 断网时不能点赞
• 突然点赞时，输入短信或电话，点赞能否成功

5.6 安全

点赞是否会泄露用户信息

6. 你们公司中缺陷的原因有哪些?如何归类的

代码错误：因为代码编写错误导致的缺陷。一般来说，如果没有其它类型的原因，默认为引起缺陷的原因为代码错误
需求不清晰：在需求中没有具体定义、需求设计缺陷、或者需求理解存在二义性的场景下产生的 Bug。
需求变更：产品需求移交后中途变更需求时产生的 Bug。这种场景一般时因为需求的变更开发与测试获取的需求信息不一致。
新引入问题：开发改 Bug 时，产生新的 Bug
配置问题：客户配置不正确，或者未导入正确配置产生的 Bug
覆盖升级：因版本覆盖升级导致的 Bug
性能问题：系统卡顿，响应慢等
兼容问题：由于不同硬件设备和操作系统的区别产生的 Bug
线上故障：线上版本的影响主流程的 Bug

7.接口测试 -接口测试能发现哪些问题

现在大部分系统前后端架构是分离的，接口作为前后端数据交互的，它的质量是必须要通过接口测试去保障的。

而且系统越来越复杂，传统的靠前端测试已经大大降低了效率，而且现在都推崇测试左移，希望测试能更早的介入测试，那接口测试就是一种及早介入的方式。如果是只测试功能，是需要等前后端都完成才能进行测试。

而如果是接口测试，只需要前后端定义好接口，那这时自动化就可以介入编写接口自动化测试代码。手工接口测试只需要后端代码完成就可以介入测试后端逻辑而不用等待前端工作完成。

而且只依赖前端进行数据限制已经完全不能满足系统的安全要求，现在绕过前端直接对接口发起请求非常容易。在这种情况下就需要从接口层面进行验证。尤其是涉及到用户的隐私信息，如身份证，银行卡等，需要看是否加密传输，保证系统的安全性。
可以检验接口是否按照约定返回响应
可以修改请求参数，突破前端页面输入限制，检验系统的异常处理能力。比如边界值处理错误，输入异常值接口抛异常，输入参数多或者少接口抛异常等等
可以检验系统的安全性。比如明文传输、返回结果含有敏感信息，没对用户身份信息做校验，没做恶意请求拦截等等
可以通过接口测试并发场景，检验系统的性能和稳定性。比如接口并发多条相同操作，响应时间过长，

8. 登录模块测试

8.1 基本登录功能测试

8.2 安全性能

8.3 界面测试

• 1.界面内容
  登录模块放置在页面中的哪个位置，如果居中，是否又居中显示了；
  其它位置放置什么东西；
  用户输入框、密码输入框、登录按钮排列、是否对齐；
  框的大小；
  用户名、密码字样是否相同，对齐；
• 2.提示
  用户名、密码输入框是否有默认提示内容；
  输入错误的用户名或密码是否给出了正确的提示，提示的文字、大小、颜色是否按需求描述（如果需求中没有明确指出，那可以借鉴其它网站相同功能的提示风格）
  用户名和密码是否是必填的，如果是必填的，是否用红色星号表示（通用规则）；输入为空时，给出的提示是否正确。
  密码显示：密码是否是密文显示，如果需求中规定了可支持明文显示，显示有相应的控件。

8.4 兼容性测试

不同浏览器
不同系统
移动设备
不同分辨率

8.5 性能测试

打开界面需要多久
点击登录后需要多久

9. 常见的自动化测试工具

9.1 Jmeter

接口测试，性能测试。主要用于web应用程序的负载测试

9.2 Postman

接口测试。提供功能强大的Web API和HTTP请求的调试，它能够发送任何类型的HTTP请求。

9.3 Selenium

浏览器 web 应用测试框架

9.4 Monkey

稳定性测试
软件附带在sdk中，适用于android和ios，通过adb shell，生成用户或系统的伪随机事件。
压力测试结果：崩溃crash，无响应anr，
基本命令：adb shell monkey 1000。

10. 微信红包测试用例

• 功能
  1.在红包钱数，和红包个数的输入框中只能输入数字
  2.红包里最多和最少可以输入的钱数 200 0.01
  3.拼手气红包最多可以发多少个红包 100
  3.1超过最大拼手气红包的个数是否有提醒
  4.当红包钱数超过最大范围是不是有对应的提示
  5.当发送的红包个数超过最大范围是不是有提示
  6.当余额不足时，红包发送失败
  7.在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号，
  7.1是否可以输入它们的混合搭配
  8.输入红包钱数是不是只能输入数字
  9.红包描述里许多能有多少个字符 10个
  10.红包描述，金额，红包个数框里是否支持复制粘贴操作
  12.红包描述里的表情可以删除
  13.发送的红包别人是否可以领取
  13.1发的红包自己可不可以领取 2人
  14.24小时内没有领取的红包是否可以退回到原来的账户
  14.1 超过24小时没有领取的红包，是否还可以领取
  15.用户是否可以多次抢一个红包
  16.发红包的人是否还可以抢红包 多人
  17.红包的金额里的小数位数是否有限制
  18.可以按返回键，取消发红包
  19.断网时，无法抢红包
  20.可不可以自己选择支付方式
  21.余额不足时，会不会自动匹配支付方式
  22.在发红包界面能否看到以前的收发红包的记录
  23.红包记录里的信息与实际收发红包记录是否匹配
  24.支付时可以密码支付也可以指纹支付
  25.如果直接输入小数点，那么小数点之前应该有个0
  26.支付成功后，退回聊天界面
  27.发红包金额和收到的红包金额应该匹配
  28.是否可以连续多次发红包
  29.输入钱数为0，"塞钱进红包"置灰
• 性能
  1.弱网时抢红包，发红包时间
  2.不同网速时抢红包，发红包的时间
  3.发红包和收红包成功后的跳转时间
  4.收发红包的耗电量
  5.退款到账的时间
• 兼容
  1.苹果，安卓是否都可以发送红包
  2.电脑端可以抢微信红包
• 界面
  1.发红包界面没有错别字
  2.抢完红包界面没有错别字
  3.发红包和收红包界面排版合理，
  4.发红包和收到红包界面颜色搭配合理
• 安全
  1.对方微信号异地登录，是否会有提醒 2人
  2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加
  3.发送红包失败，余额和银行卡里的钱数不会少
  4.红包发送成功，是否会收到微信支付的通知
• 易用性(有点重复)
  1.红包描述，可以通过语音输入
  2.可以指纹支付也可以密码支付