Q：按测试内容划分，测试有哪些种类？
参考答案：
大致可以分为：单元测试、集成测试、系统测试、验收测试和回归测试
知识点：
1、单元测试:完成最小的软件设计单元(模块)的验证工作，目标是确保模块被正确的编 码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下 是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决 不易显现的错误。（一般由开发人员去进行单元测试）
2、集成测试:通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来， 构造一个在设计中所描述的程序结构，应当避免一次性的集成(除非软件规模很小)，而采用增 量集成。（分功能模块进行测试）
自顶向下集成:模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成， 隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。
自底向上集成:从子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要 求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。
3、系统测试:是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系 统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。（测试工程师实际工作中更多是在进行系统测试）
4、回归测试:回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本 上再次出现。根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经 修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。（验证修复后的bug）
5、验收测试:验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立 测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一 项确定产品是否能够满足合同或用户所规定需求的测试。
验收测试包括 Alpha 测试和 Beta 测试。
Alpha 测试:是由用户在开发者的场所来进行的，在一个受控的环境中进行。
Beta 测试:由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用 户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终 的软件。
Q：软件开发（测试）的流程是怎么样的？
参考答案：
目前互联网行业大致的流程都是：
- 首先产品经理出产品需求，并进行需求评审
- PMO进行项目排期
- UI设计出设计稿
- 开发编写代码，此时测试编写测试用例
- 进行测试用例评审
- 开发人员联调自测后提测
- 测试人员进行冒烟测试
- 集成测试、系统测试
- 回归测试、验收测试、灰度测试
- 上线发版
另外，软件开发（测试）流程有V模型和W模型之分，V模型主要是测试过程加在开发过程的后半段，而W模型是测试提前，甚至和开发是同步进行，测试不仅是程序，还包括需求和设计。W模型有利于尽早地全面的发现问题，降低软件开发的成本，风险前置。
知识点：
V模型：
W模型：
Q：你印象最深刻的 bug 是？
参考答案：
其实能被发现的bug，更多都是显而易见的bug。有一个bug，让我印象十分深刻，这个bug并不是发生在我负责测试的系统上，是发生在我们所依赖的系统上。
当时在测试分类页，分类页数据接口需要调用商品系统的接口，别的很多服务也依赖商品系统接口。在某次大促之前，商品系统在夜间压测，突然我们的服务接到接口调用超时的报警，一番排查之后，才发现是调用商品系统的时候超时了，我们的服务没有做降级处理，直接给前端抛了一个错误。当时还好是凌晨，给线上用户的影响较小，但是也是敲响了警钟，后面我们做了降级处理，缓存了部分商品数据，待商品系统大规模调用超时后，将调用商品系统接口的开关关闭，走我们的缓存数据。
这个bug也提醒我，要有大局意识，不要只关注自己的系统，也要关注上下游服务，每逢大促或者重大活动时，最好都要做压测，要对服务的性能有个预期。
回答的关键点：
（1）发现了什么bug？
（2）bug怎么解决的？
（3）带给你什么启示？
Q：谈谈你对 CI/CD 的理解
参考答案：
CI是指持续集成，CD是指持续交付。
目前CI/CD在互联网公司中十分流行，同时，CI/CD也特别适合敏捷开发流程。
CI/CD不是指特定的某个工具，而是指开发方法，并且是相辅相成的。
CI/CD的优点是：将重复的工作用自动化来代替、减少时间成本、最终缩短版本发布时间。一般常用的CI工具是jenkins。
Q：谈谈你对 DevOps 的理解
参考答案：
DevOps是研发运营一体化。在IT软件及相关服务的研发及交付过程中，将应用的需求、开发、测试、部署和运营统一起来，基于整个组织的协作和应用架构的优化，实现敏捷开发、持续交付和应用运营的无缝集成。帮助企业提升IT效能，在保证稳定的同时，快速交付高质量的软件及服务，灵活应对快速变化的业务需求和市场环境。
简单来说，DevOps的目标就是实现快速稳健的把产品交付给用户，并给企业更快的带来商业价值。
最终软件工程将像汽车制造业一样，具备稳健的生产流水线和流程管理方式。
Q：什么是 BDD ? 什么是 TDD
参考答案：
BDD是行为驱动开发，TDD是测试驱动开发
行为驱动开发(BDD)是测试驱动开发的延伸，其中，BDD又可以用Cucumber来编写用例，强调的是复杂场景化的验收，Cucumber也可以用来编写自动化用例。
Q：APP的一个页面，你怎么区分是原生Native页面，还是H5？
参考答案：
可以从运行速度、交互性、是否跨平台、页面修改是否需要审核、是否可以使用设备的底层功能、是否依赖网络、打开一个页面是否有进度条、点击输入框，弹出的键盘是否有“完成”按钮等等方式去区分。
另外，安卓手机可以通过打开开发者模式->显示布局边界，来判断，就是密密麻麻的红线，布局很规范的页面就是原生页面；打开页面中间一大部分都没有红线，只有页面边缘有红线的布局就是H5页面。
https://blog.csdn.net/qq_37941471/article/details/87864317
2.2
测试方法
Q：黑盒测试的方法有哪些？
黑盒测试:
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测 每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序 内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规 格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外 部信息(如数据库或文件)的完整性。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。
“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出 程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
常用的黑盒测试方法有:等价类划分法;边界值分析法;因果图法;场景法;正交实验设计 法;判定表驱动分析法;错误推测法;功能图分析法。
Q：白盒测试的方法有哪些？
白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它 根据程序的控制结构设计测试用例，主要用于软件或程序验证。
白盒测试法检查程序内部逻辑结 构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但 仍然有可能存在错误。因为:穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是 否是一个错误的程序;穷举路径测试不可能检查出程序因为遗漏路径而出错;穷举路径测试发现 不了一些与数据相关的错误。
白盒测试需要遵循的原则有:
1. 保证一个模块中的所有独立路径至少被测试一次;
2. 所有逻辑值均需要测试真(true)和假(false);两种情况;
3. 检查程序的内部数据结构，保 证其结构的有效性;
4. 在上下边界及可操作范围内运行所有循环。
常用白盒测试方法:
静态测试:不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试 等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具(Fxcop)自动进 行。
动态测试:需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、 性能分析、内存分析等。
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆 盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化:
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。
Q：什么是单元测试？
单元测试:完成最小的软件设计单元(模块)的验证工作，目标是确保模块被正确的编 码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下 是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决 不易显现的错误。
Q：什么是集成测试？
集成测试:通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来， 构造一个在设计中所描述的程序结构，应当避免一次性的集成(除非软件规模很小)，而采用增 量集成。
自顶向下集成:模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成， 隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。
自底向上集成:从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要 求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。
Q：测试用例怎么编写与设计？
参考答案：
1、测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础
2、如果以前有类似的需求，可以参考类似需求的测试用例，然后还需要看类似需求的 bug 情况
3、清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行 逻辑，通过等价类、边界值、判定表等方法找出大部分用例
4、找到需求相关的一些特性，补充测试用例
5、根据自己的经验分析遗漏的测试场景
6、多总结类似功能点的测试点，才能够写出质量越来越高的测试用例
7、测试用例要突出用例优先级
8、书写格式一定要清晰
Q：什么是灰盒测试？
参考答案：
灰盒测试是一种综合测试的方法，他将白盒测试和黑盒测试结合在一起，构成一种无缝测试技术。
除了完成黑盒测试的一些测试手段之外，还会通过codereview，日志检查，甚至通过编写代码去调用服务的接口或者函数来进行测试。
2.3
测试文档
Q：测试用例都包含哪些要素？
参考答案：
有八大要素：
1、用例编号
2、测试项目
3、测试标题
4、重要程度
5、预置条件
6、输入
7、操作步骤
8、预期结果
Q：测试报告需要展示哪些要素？
参考答案：
- 测试结论
- 测试版本
- 测试条件
- 测试内容&范围
- 用例执行情况
- 测试效果（缺陷数据）
- 优化建议
Q：测试排期应该怎么估算？
参考答案：
一般以人天作为计算单位。
估算的步骤：
1、先了解需求，判断测试的难度
2、看开发的排期，一般开发的排期都会比测试要早，大部分情况是：开发代码量越大，需要测试的内容也就越多。
3、看项目规划，具体是哪个版本上线，Deadline是什么时候。
4、填写排期时，时间估算到人天，但是自己和开发沟通的时候，一定要明确到小时级别，比如开发说5月10号提测，就得明确是5月10号上午提测还是下班前提测。
Q：谈谈你构造数据的经历？
参考答案：
构造数据的经历有很多次，测试分类页时，前端样式根据后端下发的字段来展示相应的字段，有3种方法可以构造数据，如果要测试展示逻辑，最好是能够走一遍主流程从后台配置去验证；假如步骤比较繁琐，且对代码比较熟悉，可以通过调试走查后端代码的逻辑去测试。假如测试UI样式，则可以直接用charles 的 local map 功能去 mock 数据来测试。