测试题-6

变异测试（Mutation Testing）通过注入代码变异（如修改运算符或常量）并评估测试能否杀死这些变异体，直接检验测试的缺陷检测能力，从而评估和提升断言的有效性。

1. 这个密码验证问题包含两个条件判断:
- 条件1(因):首位是否为字母
- 条件2(因):其余位是否为数字
这两个条件会导致不同的输出结果(果):message1或message2

2. 因果图特别适合处理这种具有明确输入条件和对应输出结果的逻辑关系测试。它可以清晰地展示条件组合与预期结果之间的对应关系.

此类包含明确的"if-then"规则的测试场景，因果图是最佳选择，因为它能够:
- 系统地分析输入条件与输出结果的对应关系
- 确保测试用例覆盖所有可能的条件组合
- 直观地展示测试逻辑结构

功能测试是系统测试的主要内容之一，其主要目的是验证软件的各个功能是否按照需求规格说明正常工作。

功能测试不能测试系统性能，所以本题说法错误。

单元测试依据详细设计，集成测试依据概要设计，系统测试依据需求文档

题目测试核心逻辑是验证服务解析支付成功回调并更新数据库，需要兼顾效率、可靠性和隔离性。选项分析：A（端到端测试）效率低（涉及完整流程和真实网关）、可靠性不稳定（依赖外部系统）、隔离性差；B（单元测试）效率高、隔离性好，但可靠性不足（完全mock外部依赖，可能遗漏集成问题，如数据库操作）；C（集成测试）使用隔离的真实数据库实例（如测试容器）和mock server模拟支付网关，能直接测试解析回调及数据库更新，效率较高、可靠性好（真实数据库交互）、隔离性强；D（契约测试）只验证API消费符合契约，不直接测试核心逻辑（解析及数据库更新）。因此C在效率、可靠性和隔离性上综合最佳。

A. 强度测试 - 主要测试系统在正常负载条件下长期运行的可靠性,不是专门针对资源耗尽情况
B. 容量测试 - 关注系统能够处理的最大数据量或并发用户数,但不是刻意制造资源耗尽的场景
C. 性能测试 - 测试系统在正常工作负载下的响应时间、吞吐量等指标,不涉及资源耗尽情况的测试

压力测试的主要目的是:
1. 评估系统在极限条件下的行为表现
2. 发现系统的瓶颈和崩溃点
3. 验证系统的容错和恢复机制
4. 确定系统的性能边界

（1）单元测试：

 单元测试又称为模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作，单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
（2）集成测试
又称为组装测试或联合测试，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。

（3）确认测试
确认测试的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般有第三方测试机构进行。
（4）系统测试
 软件作为计算机系统的一部分，与硬件、网络、外设、支撑软件、数据以及人员结合在一起，在实际或模拟环境下，对计算机系统进行测试，
目的在于与系统需求比较，发现问题
（5）验收测试
以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。
不是对系统进行全覆盖测试，而是对核心业务流程进行测试。

契约测试的主要优势是降低服务间依赖导致的测试环境复杂度，因为它通过模拟服务接口依赖，允许独立测试每个服务，而无需部署整个系统。选项A错误：契约测试专注于服务间接口，不覆盖UI交互流程（端到端测试更适合此目的）。选项C错误：契约测试不直接涉及并发执行，因此不易发现死锁问题（并发问题更适合集成测试或端到端测试）。选项D错误：契约测试验证点对点接口契约，而非全链路业务数据一致性（端到端测试更适合验证全链路数据）。

平均响应时间在200ms以下但用户反馈偶发卡顿，表明响应时间分布不均匀，存在少数高延迟请求。99分位响应时间（99th percentile response time）度量最慢1%请求的延迟，是诊断尾部延迟问题的关键指标，优先关注该指标可有效定位卡顿问题。其他指标如吞吐量（TPS/QPS）、CPU利用率和并发用户数虽可能影响性能，但不直接解释偶发卡顿现象。

选项A错误，因为100个虚拟用户不一定等价于100个实际用户同时访问；虚拟用户可能未模拟真实用户的思考时间（Think Time），导致请求更密集，从而可能产生高于实际用户的负载。选项C错误，因为并发用户数不仅包括登录系统的用户，还包括同时执行操作（如发送请求）的用户，且用户的操作频率会影响并发负载的强度（如高频操作会增加并发压力）。选项D错误，因为系统响应时间的增加不一定是线性的；在系统资源瓶颈（如CPU或内存耗尽）时，响应时间可能指数增长或趋于饱和。

A. 模糊测试
核心思想：向程序自动或半自动地输入大量随机、无效、非预期的数据（“畸形”数据），监视程序是否会出现崩溃、断言失败或内存泄漏等问题。
主要目的：发现那些在正常测试中难以触发的、由意外输入导致的深层错误和安全漏洞（如缓冲区溢出）。
简单比喻：像一个“压力测试机”或“破坏王”，用海量垃圾数据冲击程序，考验其稳定性和健壮性。
B. 变异测试
核心思想：这是一种评估测试用例有效性的高阶技术。它会在源代码中故意制造一些小的人为错误（即“变异”，例如将 +改为 -，或将 >改为 >=），然后运行现有的测试套件。
主要目的：检验测试用例是否足够强大。如果测试用例能检测到这些“变异”并将其“杀死”（即测试失败），说明测试用例是有效的；反之，则说明测试用例存在不足。
简单比喻：像一个“质量检查员”，通过故意制造瑕疵来检验质检流程（测试用例）是否严格。

总结对比表格

测试方法	测试对象	测试时机	主要目的	关键特点
模糊测试​	已编译/可运行的程序	动态（运行时）	发现由意外输入导致的崩溃和漏洞	基于无效输入，自动化，侧重于健壮性和安全性
变异测试​	测试用例集的有效性	动态（通过对变异代码运行时）	评估测试套件的质量和完善度​	不直接找程序bug，而是找测试的弱点
回归测试​	软件功能	动态（每次修改后运行时）	确保新的修改没有破坏现有功能	重复性活动，是软件维护期的核心测试
静态代码分析​	源代码	静态（不运行程序）	在编码阶段早期发现潜在缺陷和规范问题	预防性分析，可自动化，能检查代码风格和复杂度

A选项"制定测试计划"：这是测试经理或测试负责人的职责。测试计划涉及资源分配、进度安排等管理工作，不属于测试设计员的工作范围。
D选项"评估测试活动"：这也属于测试管理层的职责。测试活动的整体评估需要从更高的层面来把控，包括测试效果、测试覆盖率等分析工作，不是测试设计员的职责范围。

MC/DC覆盖（Modified Condition/Decision Coverage）最能确保条件语句中的所有布尔子表达式被独立评估，因为它要求每个布尔子表达式独立影响决策结果，而其他条件固定。

分支覆盖：保证每条大路（是/否）都走了一遍。
条件覆盖：保证每个路标（条件A/B）的两种状态都看到过，但可能没完整走完某条大路。
实际上，更严格的标准（如条件组合覆盖MC/DC）会要求既覆盖每个条件，又能体现出每个条件对最终结果的独立影响。

选项B正确，因为单元测试应尽可能简短以快速运行，并在开发阶段（如测试驱动开发）进行，这符合单元测试的最佳实践。选项A错误，因为单元测试不只关注外部表现，还包括内部实现细节；选项C错误，因为单元测试常需要模拟对象（如mock）来处理外部依赖；选项D错误，因为单元测试适用于各种编程范式，包括面向对象、过程式和函数式编程。

if a && （b || c）
有两个判断组：第一组 b || c 结果有2种，第二组 a && （） 结果有2种

2*2=4 覆盖所有判断路径

在测试金字塔原则中，单元测试（Unit Testing）位于最底层，执行速度快、成本低、反馈迅速，能直接验证代码单元的核心业务逻辑。持续集成（CI）流程中快速反馈代码变更的影响，应优先依赖单元测试。

语句覆盖＜判定覆盖＜条件覆盖＜语句/判定覆盖＜条件组合覆盖＜路径覆盖

模糊测试方法通过发送随机或畸形数据来模拟攻击场景，直接针对程序输入处理进行压力测试，能有效暴露缓冲区边界未检查的漏洞

B选项（边界值分析）虽可能涉及边界但主要针对功能边界而非安全漏洞

解析：TDD（强调实践和快速迭代）和CMM/CMMI（强调过程管理和文档）在理念上确有不同，但并不能说TDD“不适合”或“不能”在CMMI框架下使用。它们可以结合，只是侧重点不同。

（1）敏捷开发方法核心思想：​ 拥抱变化，小步快跑，持续交付，不断获取用户反馈并调整方向。

常用的敏捷开发方法有哪些？

方法名	通俗解释	核心特点
Scrum（最流行）​	像打橄榄球一样，团队作为一个整体，在一个个固定的短冲刺（Sprint，通常2-4周）内，完成一小批明确的功能。有站会、复盘会等固定仪式。	角色分明（产品负责人、Scrum主管、开发团队），迭代固定，仪式感强。
Kanban（看板）​	像工厂的生产流水线。把所有要做的任务贴在看板（白板或电子看板）上， columns 分为“待办”、“进行中”、“已完成”。限制“进行中”的任务数量，让流程像水一样顺畅。	可视化工作流，限制在制品，强调持续交付，灵活性极高。
极限编程（XP）​	特别强调工程技术实践，目的是在需求多变的情况下依然产出高质量的代码。是测试驱动开发（TDD）​ 的强力倡导者。	结对编程（两个人用一台电脑写代码），测试驱动开发，持续集成，简单设计。
精益开发（Lean）​	源自丰田生产方式。核心是消除一切浪费（比如没用的功能、等待时间）。只做用户真正需要的东西。	消除浪费，​ amplifying learning（强化学习），尽可能晚做决策。

（2）测试驱动开发（TDD）
专业解释：​ 一种软件开发过程，要求在编写某个功能的代码之前，先编写用于定义该功能行为的失败测试用例，然后编写最少量的代码使其通过测试，最后重构代码以达到良好设计。
通俗解释（“红-绿-重构”循环）：
假设你要做一个计算器，实现加法功能。
红（Red）：先写一个肯定会失败的测试
        你还没写加法代码呢，就先写一个测试代码：assertEqual(add(2, 3), 5)（断言2+3等于5）。
        运行测试，结果肯定是失败（红色）。因为add函数还不存在。这证明你的测试是有效的，它真的能检测出错误。
绿（Green）：用最快最丑的方式让测试通过
        现在你的唯一目标是让这个红灯变绿灯。于是你写了最简单的代码：
def add(a, b):
    return 5  # 对，直接返回5！虽然很傻，但能让测试通过！
        运行测试，通过（绿色）！目标达成。这确保了你的代码100%满足了测试的要求。
重构（Refactor）：在绿灯下把代码整理干净
        现在测试是绿的，你有安全网了。可以放心大胆地整理刚才的“烂代码”。
        把函数改成正确的样子：def add(a, b): return a + b
        再次运行测试，如果还是绿色，说明重构没破坏任何功能。
TDD的本质：​ 不是一种测试技术，而是一种设计工具。它强迫你在写代码前就想清楚“这个功能到底要干什么”，从而得到高测试覆盖率和易于测试（即设计良好）的代码。

（3）CMM / CMMI

专业解释：​ 一套评估和改进组织软件开发过程的成熟度模型。

通俗解释：

想象一下你要评估一个餐馆的做菜水平。

CMMI一级（初始级）：​ 江湖菜馆
        做菜全靠厨师的心情和天赋。今天咸了，明天淡了。过程不可预测，质量不稳定。能做出菜，但好不好吃看运气。

CMMI二级（已管理级）：​ 有固定菜谱的连锁店
        至少有了菜谱（标准流程）。对时间、成本（盐放多少，炒几分钟）有了基本的管理。能保证这次吃的和上次吃的味道差不多（可重复）。
CMMI三级（已定义级）：​ 米其林星级餐厅
        不仅有自己的标准菜谱（组织级流程），而且对整个烹饪过程（切菜、调味、火候）都有精确定义和最佳实践。质量稳定且很高。
CMMI四级（量化管理级）：​ 食品科学实验室
        能用数据量化管理过程。比如“油温控制在180±2度时，炸鸡的含水量和酥脆度达到最佳”。通过数据分析来持续优化。
CMMI五级（优化级）：​ 能自我进化的未来餐厅
        能基于数据持续地、主动地改进和创新烹饪流程和菜谱。防止缺陷发生，而不仅仅是事后纠正。

CMMI的核心思想：​ 先标准化、文档化你的过程（二级、三级），做到可重复和稳定，然后再用数据量化地管理和优化它（四级、五级）。

设置环境变量应使用 pm.environment.set，pm.globals.set 设置全局变量

在产品可靠性工程中,可靠性指标是衡量产品质量和性能的重要参数。ABDE都是典型的可靠性指标:
A. 失效率 - 表示单位时间内产品发生失效的概率,是最基本的可靠性指标之一。失效率越低,说明产品越可靠。
B. 平均寿命 - 反映产品从开始使用到失效的平均时间长度,也称为平均无故障工作时间(MTTF)。是衡量产品耐久性的重要指标。
D. 可靠度 - 表示产品在规定时间和条件下完成规定功能的概率。是最直观的可靠性指标。
E. 维修度 - 表示产品发生故障后的可维修性,通常用平均修复时间(MTTR)来衡量。也是可靠性的重要组成部分。
C选项"直通率"错误: 直通率是指产品一次性通过检验的比率,属于生产过程中的质量指标,不是可靠性指标。直通率反映的是生产过程的能力,而不是产品本身的可靠性特征。
总的来说,可靠性指标主要反映产品在使用过程中的可靠性特征,包括失效、寿命、可靠度和维修等方面。而直通率属于生产过程的质量指标,因此不属于可靠性指标范畴。

软件质量保证（SQA-Software Quality Assurance）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。

AIpha测试：用户代表参与，开发者主导，受控环境。 beta测试：用户独立参与，真实环境，开发者不干预。

想象一下，您是一位监考老师，您的任务是观察学生A（OrderService）在“考试时间只剩5分钟”这个情况下，会不会举手向学生B（NotificationService）要橡皮。

您不关心学生B会不会真的把橡皮给出去（那是B的能力测试），您只关心 “A到底举没举手”​ 这个动作。

现在，我们怎么设计这个“观察”？

我们需要一个“学生B的替身”来配合测试。

Ⓓ Dummy（木头人）：我放一个玩具熊在学生B的座位上。结果：学生A一举手，程序就报错了，因为玩具熊根本不会“接收举手”这个指令。（完全没用）

Ⓐ Stub（应答机）：我安排一个工作人员坐在B的座位上，他只会机械地回答：“好的，收到”。他能让程序不报错，但他不会记录A是否举过手。测试结束后，我问这个工作人员：“A举手了吗？”他回答：“我不知道，我的任务只是说‘好的’。” （无法验证行为）

Ⓒ Fake（临时演员）：我请来一位真正的演员扮演学生B，他有一套复杂的表演逻辑。这确实能完成测试，但大材小用了。我们只需要知道“举没举手”，却请了个影帝，增加了不必要的复杂性。

Ⓑ Mock（智能监控摄像头）：这是最完美的方案！我在学生B的座位上安装一个智能摄像头。测试开始前，我设置好监控的期望：“记录下学生A的举手动作”。

替身类型	核心用途	在本场景的比喻
Stub​	提供数据​ (控制输入)	应答机：只负责回应，不记录行为
Mock​	验证行为​ (验证交互)	智能摄像头：专为验证“是否调用”而生​
Fake​	实现功能​ (用简易版替代)	临时演员：功能完整，但没必要
Dummy​	占位​ (防止报错)	玩具熊：连基本交互都无法完成

系统测试是验证整个系统是否满足需求规格的测试阶段，涵盖功能测试、性能测试、安全测试、兼容性测试等多个方面。功能测试仅是系统测试的一部分，而非“主要内容”。