测试题-5
| 类型 | 专业定义 | 通俗解释（生活类比） | 核心特点 | 典型使用场景 |
|---|---|---|---|---|
| A. Dummy（哑对象） | 仅作为“占位符”的对象，没有实际功能，不参与逻辑，仅用于填充参数或代码结构。 | “背景路人甲”：站在场景里凑数，不说话、不互动，仅为了让“画面完整”（比如测试函数需要传入3个参数，但其中1个用不到，就传Dummy）。 | 1. 无任何逻辑和返回值；2. 不影响测试结果，仅避免代码报错。 | 测试一个需要传入3个对象的函数，但实际只用到2个，第3个用Dummy填充（避免参数缺失报错）。 |
| B. Stub（桩） | 替代真实依赖的“简化版实现”，返回预设的固定值，用于隔离被测对象与外部依赖。 | “自动售货机”：你按A按钮，永远出可乐；按B按钮，永远出雪碧（固定输入→固定输出，不关心内部逻辑）。 | 1. 仅返回预设值，不模拟复杂逻辑；2. 不校验交互（如是否被调用、调用次数）。 | 测试登录功能时，用Stub替代数据库查询：输入任意用户名，固定返回“密码正确”。 |
| C. Mock（模拟） | 模拟真实依赖的行为和交互规则（如调用次数、参数校验、条件返回值），并能验证被测对象是否按预期与之交互。 | “智能客服”：能根据你的问题返回不同答案（如问“余额”返回100，问“账单”返回明细），还能记录你问了几次、是否按流程提问。 | 1. 可模拟复杂逻辑（多条件返回值）；2. 校验交互行为（如“是否调用”“参数是否正确”“调用次数是否符合预期”）。 | 测试订单系统：用Mock模拟库存接口，预设“库存>0时扣减成功”，并验证订单系统是否在下单前调用了库存接口、参数是否正确。 |
| D. Fake（伪对象） | 具有真实逻辑的简化实现，内部可能用内存数据或简化算法模拟真实依赖，但不用于生产环境。 | “模拟厨房”：用玩具食材和简化步骤做出“看起来像真的”的菜（有真实逻辑，但不是实际厨房的复杂流程）。 | 1. 有真实逻辑，可独立运行（如用内存数据库替代真实数据库）；2. 比Stub功能强，但比真实依赖简单。 | 测试数据持久层时，用Fake内存数据库替代真实MySQL，支持增删查改（逻辑真实），但数据仅存于内存。 |
测试金字塔模型是软件测试中的经典策略，由Mike Cohn提出，推荐测试优先级为：单元测试（最多）、集成测试（中等）、UI测试（最少）。
-
Alpha 测试
- 定义：在开发环境中进行，由开发者组织，用户代表参与的验收测试。
- 目的：在受控环境下验证功能是否符合需求，发现潜在问题。
- 特点：需用户代表介入，测试过程由开发者主导。
-
Beta 测试
- 定义：在用户实际环境中进行，由最终用户独立执行的验收测试。
- 目的：收集真实场景下的用户反馈，验证兼容性与用户体验。
- 特点：无需开发者干预，属于验收测试（非系统测试）。
-
其他选项验证
- 系统测试：由开发团队执行，验证系统整体功能，与 Beta 测试无关。
- 验收测试分类：包括 Alpha（用户代表参与）、Beta（真实用户参与）两种形式。
在缺陷管理中，优先级（Priority）维度直接关注修复的紧迫性，因为它指示缺陷修复的紧急程度和顺序；而严重性（Severity）关注缺陷的影响程度，但不一定反映立即修复的需求。影响范围（Scope）和重现性（Reproducibility）是辅助维度，但不直接关注紧迫性。
题目要求评估测试是否覆盖了每个 if/else 决策点的两个分支（即真分支和假分支）。分支覆盖率（Branch Coverage）专门测量每个控制结构（如 if 语句）的真假分支是否都被执行，因此是最合适的指标。其他选项中：语句覆盖率（A）只关注语句执行，不保证分支覆盖；条件覆盖率（C）关注布尔子条件的取值，而不是整个分支；路径覆盖率（D）要求覆盖所有路径组合，更全面但不直接针对每个决策点的分支覆盖。
软件质量管理(QM, Quality Management)的组成部分确实包括质量保证(QA, Quality Assurance)和质量控制(QC, Quality Control)，而软件测试正是QC中最重要的工作内容之一。
1. 质量管理(QM)的构成：
- QA(质量保证)：着重于预防措施，确保开发过程符合质量标准
- QC(质量控制)：着重于纠正措施，通过测试等手段发现并解决问题
2. 软件测试在QC中的地位：
- 软件测试是发现软件缺陷的主要手段
- 通过各种测试方法验证软件是否满足需求
- 测试结果是软件质量评估的重要依据
3. QA与QC的关系：
- QA关注过程质量，确保开发过程符合规范
- QC关注产品质量，通过具体检测手段保证产品质量
- 两者相辅相成，共同构成完整的质量管理体系
A选项错误:制定测试计划通常是测试经理或项目负责人的职责,而不是测试设计员的工作范围。测试设计员是执行测试计划的角色。
D选项错误:评估测试活动属于测试管理层面的工作,需要从整体角度评估测试过程的有效性和测试结果,这超出了测试设计员的职责范围。
总之,测试设计员的核心职责是进行具体的测试设计工作,包括用例设计和测试脚本编写,而不负责测试项目的管理性工作。
LoadRunner是一款功能强大的性能测试工具,它主要包含脚本编辑工具(VuGen)、测试执行工具(Controller)和结果分析工具(Analysis)三个核心组件
- 性能测试（Performance Testing）：是一个广义概念，涵盖多种测试类型，旨在评估系统在特定条件下的性能指标（如响应时间、吞吐量、资源利用率等）。
- 负载测试（Load Testing）：属于性能测试的一种，目的是在正常或预期负载下验证系统的性能，确保系统能满足设计要求，而非专门找出最大承受能力。
- 压力测试（Stress Testing）：也属于性能测试的一种，目的是测试系统在极端负载（超出正常操作能力）下的行为，观察系统是否崩溃、服务是否不可用，以及如何恢复。压力测试有时也被称为强度测试（Intensity Testing），但其目标不仅仅是让系统崩溃，而是评估系统在压力下的稳定性和恢复能力。
API契约测试的关键目标是确保服务间接口的兼容性，主要验证数据格式和交互协议。
| 测试方法 | 适用测试类型 | 备注 |
|---|---|---|
| 逻辑覆盖法 | 白盒测试 | 通过分析程序内部逻辑结构设计测试用例 |
| 边界值法 | 黑盒测试和白盒测试 | 正确答案，关注输入域的边界情况 |
| 基本路径法 | 白盒测试 | 关注程序中的执行路径覆盖 |
| 正交试验设计法 | 黑盒测试 | 用于多因素、多水平的测试用例设计 |
正交试验设计法
| 特性 | 描述 |
|---|---|
| 测试类型 | 黑盒测试方法 |
| 基本思想 | 利用正交表从大量的输入条件（因素）与每个条件的取值（水平）组合中，科学地选取具有代表性的少量组合进行测试。 |
| 解决的问题 | 当输入参数很多，且每个参数有多个取值时，完全测试（所有组合都测）用例数量会爆炸性增长（组合爆炸）。正交试验法能以最少的测试用例覆盖最大范围的输入组合。 |
| 核心工具 | 正交表：一种特制的表格，具备“均匀分散、齐整可比”的特性，能保证所有因素和水平在测试中均匀出现。 |
| 举例 | 测试一个网页登录功能，有3个因素（因素A: 用户名状态，因素B: 密码状态，因素C: 验证码状态），每个因素有2个水平（水平1: 正确，水平2: 错误）。完全组合需要 2 x 2 x 2 = 8 个用例。通过正交表可能只需4个用例就能覆盖所有两两交互。 |
| 为何不适用于白盒测试 | 白盒测试关注程序内部逻辑，如语句、分支、路径的覆盖。正交试验法只关心外部的输入输出组合，完全不涉及代码内部结构，因此无法直接用于实现白盒测试的覆盖标准。 |
因为是同一个程序，所以指令数 IC相同
如果时钟频率不同，则无法确定 CPI 关系，所以选 A
CPI的全称是 Cycles Per Instruction，是 每条指令执行所需的平均时钟周期数。CPI 越小，说明 CPU 执行指令的效率越高
自顶向下集成测试的特点如下：
- 需要开发桩模块（A）：用于模拟未集成的下层模块，确保上层模块可测试。
- 首先集成主控模块（C）：从顶层模块开始，逐步向下集成下层模块。
- 能及时发现设计错误（D）：通过早期验证高层接口和结构，易于暴露设计问题。
不属其特点的选项：
- B. 需要开发驱动模块：驱动模块是自底向上测试的特征，用于调用底层模块。自顶向下方法无需驱动模块，因其从主控模块开始测试，直接控制流程。
自顶向下与自底向上集成测试的区别对比表：
| 特性 | 自顶向下集成测试 | 自底向上集成测试 |
|---|---|---|
| 集成方向 | 从主控模块开始，逐层向下集成下级模块 | 从最底层叶子模块开始，逐层向上集成到主控模块 |
| 测试顺序 | 先测试高层逻辑和接口，后测试底层实现 | 先测试底层功能，后测试高层逻辑与整体协调 |
| stub / driver 使用 | 需要大量 桩模块（Stub）模拟下层未完成的模块 | 需要大量 驱动模块（Driver）调用上层未完成的模块 |
| 主要优点 | 1. 早期验证主要控制和逻辑结构 | 1. 底层模块测试充分 |
| 主要缺点 | 1. 桩模块开发工作量大 | 1. 顶层整体逻辑到最后才测试 |
| 适用场景 | 1. 产品型项目，重视系统架构和主流程 | 1. 底层模块复杂或关键（如算法、数据库操作） |
| 发现缺陷类型 | 早期发现接口设计、控制逻辑、数据传递错误 | 早期发现底层功能、工具函数、工具类错误 |
软件测试的原则：
1.软件测试应及早执行，并贯穿于整个软件的生命周期（软件测试是在项目需求分析时就开始了，而非代码编写完成后）
2.穷举测试部不可能的，要遵循Good-enough原则（软件中总是存在bug的）
3.必须确定预定输出（或者结果）
4.必须彻查检查每个测试结果
5.充分的注意测试中的群集现象（bug会进行聚集）
6.缺陷的二八定理:通常情况下软件的80%的bug会出现在20%的模块或者功能中
7.严格执行测试计划，排除测试的随意性（严格根据项目具体测试流程， 执行测试用例）
8.注意合理的输入，也要注意非法的非预期的输入（既要考虑正常输入，也要考虑异常输入）
9.检查程序是否做了不该做的（说需求没有的功能）
10.反复使用同样的测试会使软件具有抵抗力（杀虫剂悖论）（规避方法：编写新的测试用例，让新人进行测试）
测试工具主要用于发现和验证软件中的问题,虽然测试结果可以反馈给开发团队以改进设计,但提高设计质量并不是测试工具的直接目的。设计质量的提升主要依赖于良好的设计规范和开发团队的专业能力。
mock：对代码中某些不容易获取的对象创建虚拟对象来测试
stub：桩函数是代替某些被调用了但是没有编写代码，一般再增量迭代自底向上的过程中不用编写。再自顶向下的过程中需要编写
驱动函数：调用被测函数，给被测函数传参
驱动代码用于调用和测试目标代码单元,它模拟上层模块的行为,向被测试模块传入测试数据并验证其输出结果。驱动代码是单元测试中不可或缺的组成部分。
桩代码用于模拟被测试代码单元所依赖的其他模块,它替代了实际的依赖模块,返回预设的数据。这使得测试可以独立进行,不受其他模块的影响。
Mock是一种更高级的桩代码实现方式,它不仅可以模拟依赖对象的行为,还能验证被测试代码是否正确调用了依赖对象的方法。Mock在单元测试中被广泛使用。
D选项错误原因:
GUI测试手段主要用于用户界面测试,属于系统测试或验收测试的范畴,不是单元测试的主要技术手段。单元测试主要关注代码逻辑的正确性,通常不涉及图形界面测试。
测试人员不应该机械地坚持必须完全修复所有缺陷才能通过测试。这样的做法过于绝对和僵化，不符合软件工程的实际需求。
A选项正确:这是TDD最基本的原则。在编写功能代码之前先写测试代码,通过测试用例来指导实际代码的开发。这种方式能够帮助开发人员更好地理解需求,并保证代码的质量。
B选项正确:TDD不仅仅是测试工作,而是一个完整的开发方法论。它将需求分析、设计和质量控制有机地结合在一起,形成了一个可量化的过程。通过测试来推动开发,使整个开发过程更加规范和可控。
C选项正确:TDD的价值不局限于测试本身。在编写测试用例的过程中,能够帮助发现需求中的模糊点,促进客户与开发团队之间的沟通,从而明确需求。这是TDD在需求管理方面的重要作用。
D选项正确:TDD强调先考虑使用需求,通过编写测试用例来设计功能的过程和接口。测试框架的持续验证确保了代码质量,同时也为后续的重构提供了保障。
系统测试包括：功能测试，性能测试，可靠性测试，安全性测试
接口测试是集成测试的内容
契约测试的主要优势是降低服务间依赖导致的测试环境复杂度，因为它通过模拟服务接口依赖，允许独立测试每个服务，而无需部署整个系统。
1、内测就是不公开游戏，发号给部分玩家，让玩家在游戏的同时找到游戏的问题； 2、封测是内部人员自己在测试游戏。 3、公测，就是游戏公开，所有玩家都可以玩，并在其中找到问题，给官方在对游戏里的问题给予处理。
因为“测试所有状态之间的转换”是实现最高覆盖率的、最耗时的方法，它会导致测试用例数量最大化，而不是减少。
在性能测试中，“页面完全加载时间”超标但“数据库查询响应时间”正常，表明数据库层性能无问题。页面完全加载时间包括静态资源（如CSS、JavaScript、图片等）加载、服务器处理和数据库查询。数据库查询响应时间正常排除了数据库相关因素（如选项A、D可能导致数据库延迟），服务器CPU使用率100%（选项C）可能影响整体性能，但数据库响应正常说明数据库服务器正常。选项B（静态资源CDN缓存未命中导致加载延迟）直接影响页面资源加载，与数据库无关，因此是最可能的原因。
以下是软件测试中 Alpha 测试与 Beta 测试的核心区别总结表格：
| 对比维度 | Alpha 测试（α测试） | Beta 测试（β测试） |
|---|---|---|
| 测试场所 | 软件公司内部（实验室/受控环境） | 软件公司外部（用户实际使用环境） |
| 测试执行者 | 内部员工、专业测试人员（可控、受限群体） | 最终用户、潜在客户（真实、广泛用户群） |
| 主要目的 | 发现重大缺陷、验证核心功能、评估稳定性 | 获取用户反馈、检查需求符合度、发现特定场景/兼容性问题 |
| 测试阶段 | 开发末期，Beta 测试之前（“第一个外部测试阶段”） | Alpha 测试之后，正式发布之前（“最后一个测试阶段”） |
| 关键特点 | 可控性强、环境模拟、侧重于技术问题排查 | 真实场景、用户行为不可预测、侧重于用户体验和市场验证 |
| 反馈性质 | 系统化、结构化的问题报告（来自专业人员） | 多样化、主观的用户反馈（来自真实用户） |
| 通俗比喻 | “内部彩排”：剧组内部预演，调整剧本和表演 | “公测/试映”：邀请部分观众提前观看，收集真实反应 |
测试工具主要用于发现和验证软件中的问题,虽然测试结果可以反馈给开发团队以改进设计,但提高设计质量并不是测试工具的直接目的。设计质量的提升主要依赖于良好的设计规范和开发团队的专业能力。