测试问题集锦

本文内容是根据老徐的软件测试圈和职场人每日进阶筛选后进行整理的，处于不断更新的状态

---

---

1、想学性能测试，该如何开始

• 了解性能测试是什么
• 学点服务器知识
• 学点网络知识
  1）《HTTP权威指南》，这本书还不错，但其厚度令人望而生畏
  2）《TCP/IP 详解，卷1》，内容艰涩难懂，学习难度较大
  3）《图解HTTP》，推荐理由：图文并茂，正所谓一图胜千文
• 找个工具助手（Loadrunner、Jmeter）
• 找个项目实战
• Linux知识
• DB知识
  1）关系型数据库管理系统（Relational DBMS），例如：Oracle、SQL Server、MySQL、PostgreSQL
  2）键-值 存储，例如：Redis、Mencached、DynamoDB
  3）文件存储，例如：mongodb、CouchDB、Couchbase
  4）大数据存储系统，例如：Cassandra、Hbase、Google's bigtable
  5）基于Hadoop 的数据分析系统，例如：Hive、Spark、Impala
  6）文本查询系统，例如：Solr、Elasticsearch
  注：第4和第5 ，多多少少有些交叉
• 项目架构知识
• 业务知识
• Shell脚本

2、验证码怎么测试

• 能否正常滑动（针对滑动验证码）
• 能否正常显示
• 有效时长
• 滑动过程能否正常反馈信息
• 接口能否正常验证通过
• 查看验证日志（包括错误日志）
• 浏览器缓存情况，存在cookie会不会影响
• 断网情况下，能否滑动（针对滑动验证码）
• 手动、自动刷新后，验证码是否能改变图片和位置
• 有没有过滤到敏感字符
• 脚本识别难易
• UI层面的效果

3、搭建web环境步骤

• 单个需要的服务部署（如apache、nginx、mysql、jdk、redis等）
  可以自己尝试部署禅道体验下
• 启动服务
• 配置文件调整

4、需求相关

如何提高需求分析能力

• 多看同类产品，分析他们的优劣势
• 多思考、把自己当用户
• 需求透测后，拆分成测试点，最后再根据用例设计方法及经验，输出测试用例

如何让需求评审真正发挥作用？

• 评审前，产品经理需提前发需求文档，原型等，发给相关人员，让与会人员提前了解内容，否则会议就是闷逼状态，变成产品经理一个人自嗨，其余人完全不知道是什么
• 与会人员提前看文档，标记有疑问的地方，会上重点讨论，交流
• 控制会议节奏，把控讨论主脉络
• 后续安排需求澄清会议，可由测试主导
• 会后，需求有疑问、变动的地方，邮件通知

5、针对新入职公司，之前无测试的情况下如何开展工作

• 确定一款bug管理工具，可追溯问题
• 确定提测流程和模板
• 确定测试需要参与的内容：需求评审、用例评审、开发设计文档评审
• 确定发版流程，如何确定版本达到发布标准
• 看看之前的bug、需求、多使用系统

6、面试时怎么回答面试官的问题

1）你在项目中是怎样设计测试用例的

• 附带说下根据项目的资源情况以及项目性质，去确定用例的粒度
• 保证质量与资源投入的平衡
• 用例设计本身的方法

2）如何介绍自己参与的项目？

很多面试者确实容易在这个地方被pass
一般都是因为，很多从业者，对于自己参与了一年的项目都解释不清楚。
这种情况，两种原因，要么这项目你根本没参与，要么你上班混日子的，每天只知道点点点，只管自己负责的模块。

• 什么类型项目，解决什么问题，针对的用户群，用户量级，项目业务流概述等。
• 主要负责什么内容，有哪些技术手段去保证质量。
• 什么语言，什么部署环境。
• 项目团队成员结构、人员占比等。

3）如何保证发版质量 ？

1. 流程规范 （按照严格的发版流程执行）
2. 风险规避
3. 提前准备
4. 引入灰度发布
5. 协同保障
6. 自动化手段（实时监控、异常报警、核心业务自动回归）
7. 分清主次
8. 错高峰
9. 回滚机制

7、纯手工测试，35岁以上是否还能继续在这个行业做下去？

问题不在于年龄多大，在于你对公司是否还有作用，是否还能创建价值。
况且现在很多公司越来越重视质量，测试人员的需求会越来越多，有经验的测试人员也会越来越吃香，职业发展也会越来越多。

建议：多关注测试行业动态，多关注公司行业前景与发展，多关注互联网行业信息趋势，多交流

8、测试人员晋升为测试经理，需要加强哪些方面的技能？

技能 分 软技能 和 硬技能

硬技能：

1、软件工程知识
2、测试体系
3、测试方法论
4、Linux
5、DB
6、对测试职业通用的辅助工具了如指掌，知道什么时候用什么工具，解决什么问题

软技能：

1、沟通能力
2、团队管理能力
3、资源协调能力
4、IT知识体系能力
5、快速学习能力
6、人才梯队建设能力
7、质量敏感度
8、人才培养能力

9、为何每次上线发布过程，总是各种坑

以下是老徐给的建议，供参考：

1）必须得有个预生产环境，与生产环境配置类似（如果完全模拟生产环境成本太高，那么是否有精简版的准生产环境 ？），尽量避免环境因素导致的上线失败（测试环境，太多不可控因素）。
2）上线之前，代码封版，不允许合并代码到master分支 。
3） 在发布前几个小时，已经把最新发布代码更新到预生产环境。后续发布，直接用这个代码分支，避免因为代码合并导致的问题（提前已经验证代码没问题了） 。
4）必须有上线步骤邮件（人是最不靠谱的，上线是一个很严肃的事情，按规范来）。
5）代码合并操作，避免由开发合并，直接交由自动合并脚本处理，减少人为因素 。
6）回滚机制 ，如果发布过程中，有太多不可控因素导致风险太大，快速回滚，择机再发布 。

10、关于持续集成CI/CD的 “七大原则” 和 “十大要素”

七大原则：

1. 所有的开发人员需要在本地机器上做本地构建，然后再提交到版本控制库中，从而确保他们的变更不会导致持续集成失败
2. 开发人员每天至少向版本控制库中提交一次代码
3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器
4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建
5. 每次构建都要100%通过
6. 每次构建都可以生成可发布的产品
7. 修复失败的构建是优先级最高的事情

十大要素：

1. 统一的代码库
2. 自动构建
3. 自动测试
4. 每个人每天都要向代码库主干提交代码
5. 每次代码递交后都会在持续集成服务器上触发一次构建
6. 保证快速构建
7. 模拟生产环境的自动测试
8. 每个人都可以很容易的获取最新可执行的应用程序
9. 每个人都清楚正在发生的状况
10. 自动化的部署

11、如何做好接口测试

首先要能看懂接口文档，接口的定义方式，那么如何读懂接口协议文档呢？
（1）请求的地址是什么
（2）采用的协议类型是什么，比如get、post
（3）数据的传输格式是什么样的，比如字符串、Json、XML等
（4）参数内容，以及是否使用采用了密文校验
参数的说明，一般对外的接口都会有加密校验字段，比如简单的对应内容用MD5加密，动态密钥加密等
比如，Sign是一个校验字段，它的值是MD5（参数一+参数二+校验码）
（5）接口对应的业务逻辑以及返回值有哪些
每一个接口都承载了一定的业务逻辑，在写测试用例时，接口的处理逻辑一定要清楚，建议用路径判定发进行用例设计
（6）安全性，尤其SQL注入
在前端有页面对输入进行判断时SQL的注入还不容易发现，但是很多情况后台是没有校验数据，此时就容易出错
（7）并发与性能