1.什么是软件测试？

编写测试用例来发现bug，然后提交到开发，循环往复发现更多bug

2.你知道的项目开发模型都有什么？

2.1瀑布模型

是从需求分析——计划——设计——编码——测试——end 这样的线性模型

优点

1. 强调开发的阶段性

瀑布模型把整个开发流程拆分为 需求 → 设计 → 编码 → 测试 → 交付 → 维护 等阶段。
每个阶段都有明确的输入和输出，就像流水线一样一步一步推进。
👉 好处：项目成员知道自己当前在做哪一环，责任清晰，不会混乱。

2. 强调早期计划及需求调查

在开始写代码前，瀑布模型要求先把需求分析、系统设计、计划排期都弄清楚。
比如：要开发一个“机票预定系统”，在写代码前，就要明确用户能查航班、订票、退票，后台要支持支付、报表等。
👉 好处：需求前期定得比较完整，开发过程中少走弯路，避免边写边改。

3. 强调产品测试

瀑布模型认为“测试”是一个独立的阶段，在编码完成后，必须系统性地测试整个产品。
这样可以保证最终交付的产品符合需求、质量可靠。
👉 好处：保证上线前尽可能减少 bug，提高可信度

缺点

依赖于早期进行的唯一一次需求调查，不能适应需求的变化。
由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程。
风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

2.2螺旋模型

思路：在迭代开发的基础上，每一轮迭代都包含风险分析和评估，就像螺旋一样一圈一圈往外扩展。
特点：
- 每个迭代周期包括：目标确定 → 风险分析 → 开发实现 → 评估计划。
- 强调 风险驱动，特别适合规模大、风险高的项目。
- 成本较高，因为需要不断进行风险评估和验证。
重点：强调 风险控制和评估，不是单纯的分功能做，而是每次都先“想清楚、评估风险”，再开发。

👉 例子：做一个航空管制系统（高风险项目）

第一次迭代：确定核心功能（航班调度），分析风险（实时性要求高、硬件兼容性），做原型验证。
第二次迭代：扩展功能（应急处理），再做风险评估（数据丢失风险），继续实现。
迭代中持续评估和优化，避免高风险导致失败。

2.3. 增量迭代模型

思路：把系统分成多个小功能模块（增量），逐个开发，每次开发完成一个可用子系统，然后逐步叠加，直到形成完整系统。
特点：
- 每个迭代都能交付一个可运行的部分产品。
- 用户能较早用上部分功能，逐步完善。
- 适合需求较明确、但系统较复杂的项目。
重点：强调 功能分批实现，像“拼积木”。

👉 例子：做一个电商网站

第一次迭代：用户注册/登录
第二次迭代：商品浏览
第三次迭代：购物车
第四次迭代：下单支付
这样一步一步上线，逐渐变完整。

2.4敏捷模型

敏捷模型和增量迭代模型确实看起来很像，因为 它们都不是“一次性大交付”，而是分阶段交付。但它们之间有几个关键差别：

🔑 共同点

都是 分阶段逐步交付产品，不是瀑布那种一次性交付。
用户能 较早看到部分成果，并且随着迭代逐渐完善系统。

🚩 区别

对比点	增量迭代模型	敏捷模型
目标	按功能分块，逐步实现，直到完整系统	快速响应变化，持续交付价值
迭代驱动	以功能模块为主（例如：登录 → 浏览 → 下单）	以用户价值和反馈为主（客户最想要什么功能，就先做）
需求变化	初期需求相对明确，变化不大	默认需求会变，随时可以调整
用户参与	用户主要在增量交付后验证结果	用户贯穿整个过程，持续参与每个迭代
团队方式	强调分阶段开发，流程相对正式	强调小团队、自组织、频繁沟通（Scrum 每日站会）
交付节奏	交付可能按大功能块划分，周期相对长	短周期（2~4 周）就交付一个可用的版本
管理理念	偏传统：先计划好各个增量，然后按部就班实现	偏灵活：先做最有价值的功能，随时根据反馈调整计划

📌 类比理解

增量迭代模型：像盖房子，先盖好一层 → 再盖二层 → 再盖三层，最后盖成完整的楼。
敏捷模型：像做蛋糕，先做一个小的可以吃的蛋糕 → 客户尝一口说“太甜了” → 下一次做得没那么甜 → 再下一次加点水果装饰。每次交付的东西都是完整可用的。

✅ 一句话总结：

增量迭代：强调“怎么分功能逐步实现”。
敏捷：强调“快速交付、持续反馈、灵活应对变化”。

3.什么是测试左移，测试右移

如果把软件开发过程画在时间线上：
需求 → 设计 → 开发 → 测试 → 运维/上线
那么：

左边代表开发早期阶段（需求、设计）。
右边代表开发后期阶段（上线、运维）。

🔹 测试左移（Shift Left Testing）

含义：把测试活动提前（往左边）放，在需求、设计、开发阶段就介入测试，而不是等到“开发完了再测”。
做法：
- 在需求阶段做需求评审，尽早发现需求歧义。
- 在设计阶段做静态检查、代码走查。
- 在开发阶段就开始单元测试、持续集成。
目的：
- 尽早发现缺陷，降低修复成本（越早发现 bug，修复成本越低）。
例子：写代码的同时写单元测试，或者在功能还没开发完时就准备好自动化测试用例。

👉 一句话：提前测试，问题越早暴露越便宜。

🔹 测试右移（Shift Right Testing）

含义：把测试活动延伸到系统上线/运维阶段（往右边移动）。
做法：
- 在生产环境或接近生产的环境做测试。
- 使用 A/B 测试、灰度发布、金丝雀发布。
- 用监控、日志、用户行为分析来发现问题。
目的：
- 保证真实环境下的质量和用户体验，并快速发现和修复生产中的问题。
例子：上线时先让 5% 用户使用新功能（灰度），收集日志和反馈，确认稳定后再扩大范围。

👉 一句话：上线后也不停测试，保证真实环境下的质量。

📌 对比总结

对比点	测试左移	测试右移
位置	开发早期（需求/设计/开发）	开发后期（上线/运维）
目标	提前发现缺陷，降低修复成本	保证真实环境质量，优化用户体验
常见方式	需求评审、静态分析、单元测试、持续集成	灰度发布、A/B 测试、监控、日志分析
核心理念	尽早预防	持续验证

✅ 一句话总结：

测试左移 = 把测试往前挪，尽早发现问题。
测试右移 = 把测试往后延，关注上线后用户体验和真实运行质量。

4.你知道的测试设计用例方法有哪些？

https://blog.csdn.net/CYK_byte/article/details/128601439?ops_request_misc=&request_id=&biz_id=102&utm_term=%E8%AE%BE%E8%AE%A1%E6%B5%8B%E8%AF%95%E7%94%A8%E4%BE%8B%E4%B8%87%E8%83%BD%E5%85%AC%E5%BC%8F&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~sobaiduweb~default-0-128601439.nonecase&spm=1018.2226.3001.4450

5.什么是埋点测试？

埋点测试是指在应用程序（如网站、移动应用等）中特定的位置插入代码，用于收集用户行为数据的过程。这些插入的代码就像一个个“监测点”，可以捕捉用户在应用内的各种操作和行为，例如点击按钮、浏览页面、提交表单等，以便后续对这些数据进行分析，了解用户的使用习惯、行为路径等，从而为产品优化、业务决策等提供数据支持。

一.埋点类型

**代码埋点：**开发人员通过在需要收集数据的地方手动编写代码来实现埋点。这种方式灵活性高，可以精确地控制收集哪些数据以及在何时收集，但缺点是开发工作量较大，且如果需求变更，可能需要修改大量代码。

**可视化埋点：**通过可视化工具，无需编写大量代码，开发人员或运营人员可以直接在界面上选择需要埋点的元素，配置相关的数据收集规则。它的优点是操作相对简单、直观，能快速进行埋点部署，缺点是可能在某些复杂场景下灵活性不如代码埋点。

**无埋点：**通过特定的技术手段，自动收集应用程序中的所有用户行为数据，无需在代码中逐个添加埋点。这种方式可以收集到全面的数据，但可能会收集到一些无用的数据，增加了数据处理和分析的难度，并且对于一些特定的、复杂的业务逻辑数据收集可能不够精准。

二.测试内容

**数据准确性：**检查埋点所收集的数据是否准确无误，例如点击事件的记录是否与用户实际点击的位置和次数完全一致，页面浏览量的统计是否准确等。

**数据完整性：**验证是否所有需要收集的用户行为数据都被正确地记录下来，没有遗漏重要的操作或事件。

**埋点性能：**关注埋点代码对应用程序性能的影响，如是否会导致应用程序卡顿、加载速度变慢等问题。

三.实施流程(面试官问起即可showtime)

需求分析：与产品、运营等团队沟通，明确需要收集哪些用户行为数据，以及这些数据将用于何种业务目的。
埋点设计：根据需求分析的结果，确定在应用程序的哪些页面、元素上进行埋点，以及每个埋点需要收集哪些具体的数据字段。
代码实现：开发人员按照埋点设计方案，在相应的代码位置插入埋点代码。
测试验证：对埋点进行全面的测试，确保数据的准确性、完整性等符合要求。
部署上线：经过测试无误后，将埋点代码部署到生产环境中，开始正式收集用户行为数据。
数据分析与应用：对收集到的数据进行分析，提取有价值的信息，为产品优化、运营决策等提供支持。

四.应用场景

产品优化：通过分析用户在应用内的行为路径、停留时间等数据，发现用户体验不佳的环节，从而对产品的界面设计、功能流程等进行优化。

**用户行为分析：**了解用户的使用习惯、偏好，为用户画像的构建提供数据基础，以便进行精准营销、个性化推荐等。

**业务指标监测：**实时监测业务关键指标，如订单转化率、用户活跃度等，及时发现业务问题，为决策提供数据支持。

案列解读：

比如下面这是一份埋点数据的统计表，记录了多个埋点事件，通过统计埋点ID(属性)的次数，来得到一份具体的数据，例如B站的用户在观看视频的时候，可能会有一系列的行为操作如：拖动进度条，调整倍速，选择比例，切换画质等，用户的一系列操作会产生一定的数据，每一步点击/滑动等操作的频次，对于公司的“数据分析师”来说是非常重要的数据指标，产品/项目同学会依据这些数据来调整/发掘需求和已有功能的优化等。

6.什么是冒烟测试？

1.核心

冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。

如果不通过，则打回开发那边重新开发；

如果通过测试，才会进行下一步的测试(功能测试，集成测试，系统测试等等)。

简化：门槛测试，一个开关而不是一个阶段。

目的：版本验证测试BVT（Build Verification Testing）。

时间：开发转测试，历时半至一个小时，很短。

对象：需求覆盖，主功能路径。

优点：节省测试时间，防止build失败。

缺点：覆盖率还是比较低。

操作：对着需求文档把新功能过一遍；把所有流程功能走一遍；用monkey跑个一两个小时；如果有历史用例的话，可以把用例分级，冒烟级、详细级、回归级等等

用例：冒烟测试基本上不需要什么用例，如果有的话，就用详细用例里，覆盖需求文档级别的用例就可以了

冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，冒烟测试最大的优点在于节约测试的时间成本，减少测试轮数。

回归测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

2.定义

冒烟测试这个名称的来历，最初是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过。

而在软件研发中，冒烟测试其实是微软首先提出来的一个概念，和微软一直提倡的每日build（构建版本）有很密切的联系。具体说，冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。

冒烟只是这类测试活动更形象化一些的叫法，直接叫做BVT（Build Verification Testing）其实个人觉得更为贴切。

3.WHY

为什么进行冒烟测试？软件测试从业者都知道，bug发现得越晚，修复bug的成本就越高。那成本高在哪里呢？

影响的代码多，开发的修复成本会增加

影响的功能范围较大，测试回归的范围增加

容易引发更多的bug，拉长测试周期，还有质量风险

更多的bug，会增加bug的提交、沟通成本

所以，如何尽早发现bug，把bug置解决是降低成本和控制止风险的有效方式，也是QA的主要职责之一。因此使用冒烟测试的方式，对开发提测的代码进行审查，找出那些非常浅显的bug是很有必要的

4.特点

(1) 这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。

(2) 冒烟测试是随着版本转测进行的，它应该是一个开关(判断版本能否转测试)而不是一个研发流程中的测试阶段。

(3) 冒烟测试用例一般选取的是测试用例中level 0的用例，保证主功能可用。

(4) 冒烟测试就是在一个新版本出来的时候，将软件的全部功能过一遍，看有没有什么大问题。如果功能可以正常运行，不会影响测试进行，那么这个版本就可以真正开始测试了。如果功能有重大问题或影响测试进行，那么这个版本就是不合格的，不用进行进一步的测试。

5.实现

开展冒烟测试工作有助于尽早发现软件代码存在的问题，提高软件代码的质量和开发效率。

基于持续集成(Continuous Integration，CI)的冒烟测试采用自动化测试脚本进行测试工作，能够提高测试效率，减少测试人员大量的重复测试验证工作。

冒烟测试的最佳实践还是最好被自动化，在CI中每一个Build都自动的去执行主流程的测试，确保其是一个基本可用的版本。

冒烟测试可以手动执行，也可以自动化执行。稳定的系统适合自动化冒烟测试，集成过程中的系统适合手工冒烟测试，因为冒烟测试内容在动态变化，变化中的自动化脚本维护工作量比较大。

6.案例选择原则

既然只是个准入门槛那就不会选择全部案例进行测试，根据经验，选择全部案例数的 40%-50% 测试通过率在 80% 左右即可视为冒烟测试通过，允许测试准入，那这部分案例如何选择呢？

遵循以下原则

A选取重要功能案例。

重要功能案例至少应占冒烟案例的 30%，特别关注对软件功能实现具有重要影响的功能模块测试案例，例如：一个事件（业务）的增加、删除、修改、查询，一个统计、计算逻辑的的结果校验等。

B选取主要流程

主、分流程，对于主流程案例原则上应选取，分支流程案例可视其与主流程关联度和影响度从高到低选择部分。如主流程未通过，即使总案例通过率达到通过标准，该软件也应被拒绝准入，待开发人员修正后重新进入冒烟测试环节。例如：一个审批流程，即使增加、删除、修改、查询的功能均通过，但如果整个流程环节中出现阻塞，无法完成完整的审批，则应视为冒烟未通过。

C筛选数据案例

筛选与主流程、重要功能相关度高的数据测试案例，原则是确保数据的埋设满足主流程、重要功能测试条件。例如：想校验一个商品购买的正确性，就离不开商品种类、单位、库存、价格、购买数量等数据相关案例。这仅是一个简单的商品购买，如果是统计分析则更需要大量不同种类、不同时点的数据作为测试基础。