# -*- coding: utf-8 -*- """手写知识点大纲（用于课件正文抽取不足的章节，按《软件测试方法和技术（第4版）》知识体系编写）。 结构：{次课号: [(知识点标题, [要点, ...]), ...]}，在 _gen_教学文件.py 中优先于自动大纲。""" KEY_OUTLINE = { 3: [ ("软件测试方法分类框架", [ "测试方法可按依据划分为基于直觉与经验、基于输入域、基于组合、基于逻辑、基于模型与形式等类别。", "方法选择取决于需求形态、风险等级、可获取的模型信息与投入成本，实际项目多为组合使用。", "任何方法都服务于同一个目标：以可接受的成本发现更多、更严重的缺陷。", "错误猜测法、探索式测试属于经验驱动，适合需求不完整、时间受限的早期阶段。", ]), ("错误猜测法（Error Guessing）", [ "依据测试者对系统易错点的经验判断，直接列出高风险场景并构造用例。", "常见猜测点：空值与超长输入、边界值、非法格式、重复提交、并发操作、异常中断、权限越权。", "优点是快速、成本低；缺点是依赖个人经验，覆盖不可度量、难以复用。", "应把猜测结果沉淀为检查表（Checklist）与缺陷模式，交由团队共享复用。", ]), ("探索式测试（Exploratory Testing）", [ "学习、设计、执行三者同步进行，边理解系统边设计并立即执行的测试方式。", "以会话（Session）为组织单位，采用时间盒管理，配合章程（Charter）明确测试目标与范围。", "测试记录应包含：测试思路、操作路径、发现的问题与后续待验证点。", "适合需求快速变化、文档不足或者需要补充脚本化用例盲区的场景。", "与脚本化测试互补：脚本化保证回归与覆盖，探索式负责发现未知缺陷。", ]), ("基于缺陷模式的测试（DPBT）", [ "把历史缺陷抽象为可识别的缺陷模式，如空指针、数组越界、资源未释放、边界处理错误。", "按模式检索代码或设计中的可疑点，据此设计针对性用例，提高缺陷命中率。", "缺陷模式可来源于缺陷库、根因分析与行业缺陷分类（如正交缺陷分类 ODC）。", "该思想同时服务于缺陷预防：在评审与设计阶段即按模式排查。", ]), ], 4: [ ("基于输入域的测试方法", [ "等价类划分：把输入域划分为若干等价类，每类取代表值，用少量用例覆盖全部有效与无效类。", "边界值分析：错误最易出现在边界上，取最小值、略大于最小值、正常值、略小于最大值、最大值及其越界点。", "判定表与因果图：用于处理输入条件之间存在组合与约束的逻辑关系。", "正交试验与组合覆盖：用两两组合（Pairwise）等方法在组合爆炸与覆盖之间取得平衡。", ]), ("基于逻辑覆盖的白盒方法", [ "语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖，覆盖强度依次递增。", "基本路径测试：以控制流图计算环路复杂度，导出独立路径集合以确定最少测试用例数。", "循环测试关注零次、一次、多次、最大次数及越界循环。", "覆盖率高不等于缺陷少，需与需求覆盖、数据覆盖结合判断测试充分性。", ]), ("基于模型的测试（MBT）", [ "从需求或设计抽取状态机、流程图、决策表、序列图等模型，由模型生成测试用例。", "状态迁移测试需明确状态、事件、迁移与守卫条件，覆盖准则包括全状态、全迁移、全路径等。", "基于场景的测试以典型业务流为主线，覆盖基本流与各种备选流、异常流。", "MBT 的收益在于需求与用例同步、变更后可快速重生成；代价是建模与工具投入。", ]), ("形式化测试方法", [ "以严格数学语义描述系统行为与测试条件，如有限状态机、Petri 网、Z/VDM 规约。", "适用于安全关键系统（航天、医疗、轨交），可支撑证明式的正确性验证。", "建模与验证成本高，对人员数学与工具能力要求高。", "实践中常与常规测试结合，用于核心逻辑而非全系统。", ]), ("测试方法的选择与组合", [ "按风险排序：高风险、高复杂度、频繁变更的模块优先采用更严格的方法。", "黑盒方法主导功能与业务验证，白盒方法补充代码结构与逻辑覆盖。", "静态方法与动态方法互补，评审与静态分析可在编码前发现问题、成本最低。", ]), ], 6: [ ("单元测试的概念与内容", [ "单元测试针对软件最小可测单位（函数、类、方法）验证其逻辑正确性。", "测试内容：模块接口、局部数据结构、边界条件、独立路径、错误处理路径。", "单元测试通常由开发者完成，先于集成测试，是缺陷发现成本最低的环节。", "驱动模块（Driver）与被测模块（Stub）用于替代未完成的上下层依赖。", ]), ("代码评审与静态分析", [ "代码评审包括走查、审查、同行评审等，以人工阅读结合检查表发现缺陷。", "静态分析工具检查编码规范、复杂度、潜在空指针与资源泄漏，可在提交前自动拦截。", "评审需明确检查项、缺陷记录方式与闭环跟踪，避免流于形式。", ]), ("测试框架与单元测试工具", [ "xUnit 家族（JUnit、pytest、NUnit）提供断言、测试用例组织与测试报告能力。", "测试替身分为桩（Stub）、模拟对象（Mock）、伪造对象（Fake），用于隔离外部依赖。", "Mock 用于验证交互行为，Stub 用于提供固定输入，避免过度使用导致测试脆弱。", "推荐实践：一个用例一个断言目标、命名可读、可重复执行、不依赖执行顺序。", ]), ("集成测试策略", [ "集成测试验证模块间接口与协作，关注数据传递、调用时序、全局数据结构与错误传播。", "集成方式：一次性集成（大爆炸）、自顶向下、自底向上、三明治集成。", "自顶向下需要桩，自底向上需要驱动，三明治结合两者优点。", "现代工程更倡导持续集成：小步提交、自动构建与自动化回归，尽早暴露集成缺陷。", ]), ("持续集成与持续测试", [ "持续集成要求代码频繁合入主干，每次合入自动触发构建、单元测试与静态检查。", "持续测试把测试左移到需求与编码阶段，右移到生产环境监控。", "流水线质量门禁：编译失败、用例失败、覆盖率下降或严重缺陷未修复即阻断发布。", ]), ], 7: [ ("系统功能测试的目标与过程", [ "系统测试在完整系统上验证功能与非功能需求是否满足规格与用户预期。", "过程：测试需求分析 → 测试计划 → 用例设计 → 环境准备 → 执行 → 缺陷跟踪 → 报告。", "功能测试关注“做什么”，以黑盒视角依据需求规格、业务规则与用户场景验证。", "需明确测试准入条件（版本、环境、数据就绪）与准出条件（用例通过率、缺陷收敛）。", ]), ("功能测试用例设计", [ "以需求条目为追踪单元，保证每条需求至少被一条用例覆盖，建立需求—用例追踪矩阵。", "综合使用等价类、边界值、判定表、场景法、错误猜测法设计用例。", "用例要素：编号、前置条件、测试数据、操作步骤、预期结果、优先级。", "业务流用例覆盖正常主流程与各类异常分支，如支付失败、库存不足、超时。", ]), ("界面与易用性相关功能验证", [ "界面测试检查布局、控件、文案、提示信息、输入校验与多分辨率适配。", "检查交互一致性：按钮可用状态、必填校验、错误提示是否明确可行动。", "可用性验证关注任务完成效率与用户出错率，可与少量用户试用结合。", ]), ("接口测试与自动化", [ "接口测试绕过界面直接验证服务契约，覆盖参数组合、鉴权、异常码与幂等性。", "常用工具：Postman、JMeter、requests/pytest 等，可纳入持续集成流水线。", "自动化适合稳定、重复、回归量大与数据驱动的场景，不适合需求频繁变动部分。", "自动化收益需评估维护成本，避免用例脆弱导致“自动化负债”。", ]), ], 8: [ ("性能测试的目标与指标", [ "性能测试为发现性能问题或获取性能指标而开展，需在真实或逼近真实环境下施加特定负载。", "核心指标：响应时间、吞吐量（TPS/QPS）、并发用户数、资源利用率、错误率。", "常见性能问题内因：资源耗尽、资源泄漏（如内存泄漏）、锁竞争、慢查询与算法低效。", "外部表现：页面卡顿、超时、请求失败、CPU 或内存持续高位。", ]), ("性能测试类型与实施", [ "类型：基准测试、负载测试、压力测试、稳定性（疲劳）测试、容量测试、并发测试。", "实施步骤：确定指标与场景 → 构造脚本与数据 → 环境准备与监控 → 施压 → 分析调优 → 回归验证。", "性能测试必须同时监控应用、中间件、数据库与主机资源，才能定位瓶颈。", "调优后需回归确认，防止以牺牲其他指标换取局部改善。", ]), ("安全性测试", [ "安全性缺陷即脆弱性（Vulnerability），又称弱点或漏洞；来源包括恶意（木马、陷门、逻辑炸弹）与非恶意（校验错误、隐秘通道）。", "安全属性：保密性、完整性、可用性（CIA），三者可能相互制约。", "常见漏洞：注入（SQL/命令）、跨站脚本 XSS、越权访问、敏感信息泄露、不安全配置。", "测试方法：威胁建模、渗透测试、漏洞扫描、代码审计、模糊测试；贯穿研发全生命周期。", "Web 安全测试应覆盖身份认证、会话管理、权限控制、输入校验与日志审计。", ]), ("兼容性测试", [ "兼容性测试验证软件在不同硬件、操作系统、浏览器、数据库、分辨率与网络环境下的可用性。", "维度：平台兼容、浏览器兼容、版本前后兼容、数据兼容与向下兼容。", "策略：按用户占比确定测试矩阵，优先覆盖主流与关键组合，配合虚拟机与云真机。", "重点关注升级安装、数据迁移与新旧版本互操作导致的失败。", ]), ("可靠性与易用性测试", [ "可靠性测试关注长时间运行、异常恢复、故障注入与容错能力，指标如 MTBF、MTTR。", "易用性测试从效率、易学性、易记性、出错率与满意度评价产品可用程度。", "A/B 测试通过对比不同方案在真实用户上的数据表现辅助设计决策。", ]), ], 10: [ ("自动化测试的适用条件", [ "适合：需求稳定、执行频繁、回归量大、结果可判定、数据可参数化的测试。", "不适合：需求频繁变更、一次性验证、依赖主观判断（如界面美观）的测试。", "自动化率不是目标，投入产出比与维护成本才是决策依据。", ]), ("自动化测试框架的分层", [ "常见分层：测试脚本层、测试对象/页面抽象层、数据层、驱动与报告层。", "关键字驱动、数据驱动与行为驱动（BDD）是常用的框架组织思路。", "页面对象模型（PO）隔离界面变化，降低脚本维护成本。", "框架需具备：用例组织、断言、数据管理、日志、报告、失败重跑与并行执行能力。", ]), ("典型框架与工具链", [ "Web UI：Selenium、Playwright、Cypress；移动端：Appium；接口：Postman、pytest、RestAssured。", "测试运行器与报告：pytest、TestNG、Allure；持续集成：Jenkins、GitLab CI、GitHub Actions。", "选型考虑语言栈、社区活跃度、并行与跨端能力、与流水线的集成成本。", ]), ("自动化测试的设计原则与常见问题", [ "用例相互独立、可重复执行、不依赖执行顺序与外部人工准备。", "定位方式优先使用稳定属性，避免依赖易变的样式与绝对路径。", "常见问题：用例脆弱、等待处理不当、数据污染、失败定位困难与缺乏维护。", "自动化用例同样需要评审、版本管理与定期清理。", ]), ], 11: [ ("测试需求分析", [ "测试需求来源于需求规格、设计文档、用户场景与标准规范，需转化为可验证的测试项。", "识别测试项的可测性：输入、输出、约束、边界与异常处理是否明确。", "需求可追踪性矩阵用于保证需求—用例—缺陷—报告全链路可追溯。", "需求评审阶段即应介入测试视角，尽早发现二义性、遗漏与不可测需求。", ]), ("测试目标与测试策略", [ "测试目标应可度量：缺陷发现率、用例通过率、需求覆盖率、遗留缺陷等级分布。", "测试策略明确测试范围（测什么、不测什么）、测试类型组合、准入准出与风险应对。", "按风险分配资源：高风险模块投入更多测试类型与更严格覆盖。", ]), ("测试计划的内容", [ "计划要素：测试范围与目标、测试项与优先级、方法与环境、进度与人员分工、风险与应对、交付物。", "进度安排需与开发里程碑对齐，预留回归测试与缺陷修复验证时间。", "计划不是一次性文档，需随需求变更与执行情况滚动更新。", ]), ("测试估算与风险控制", [ "估算方法：基于用例数、历史数据、专家判断与工作分解结构。", "时间不足时的应对：按风险裁剪范围、加大自动化回归、明确遗留风险并向干系人披露。", "测试风险包括需求不清、环境不可用、数据不可得、人员能力与进度压缩。", ]), ], 13: [ ("测试环境与基础设施", [ "测试环境需尽量贴近生产配置，包括操作系统、中间件、数据库版本与网络拓扑。", "基础设施资源包括硬件（机架式服务器、刀片式服务器）、软件（操作系统、数据库、Web 服务器、测试工具）、数据与网络资源。", "环境管理要求：版本可追溯、可快速重建、环境间相互隔离，避免相互干扰。", "建议用配置管理工具与脚本实现环境自动化部署，减少人工搭建差异。", ]), ("测试数据准备", [ "测试数据包括原有数据、正确数据与错误数据，需覆盖正常、边界与异常场景。", "数据获取途径：生产脱敏数据、脚本生成、工具造数与手工构造。", "须遵守数据安全与隐私合规，敏感字段脱敏，禁止真实个人信息外泄。", "数据应可复位，保证用例可重复执行与结果可比较。", ]), ("虚拟机与容器技术", [ "虚拟机通过 Hypervisor 在一台物理机上运行多个独立操作系统，分裸金属型与宿主型。", "容器共享宿主内核，启动快、资源开销小，适合快速交付测试环境。", "镜像与快照能力便于环境复制、回滚与并行测试，显著降低环境准备成本。", ]), ("缺陷管理与跟踪", [ "缺陷生命周期：新建 → 指派 → 修复 → 验证 → 关闭，异常时重新打开或延期处理。", "缺陷报告要素：标题、复现步骤、实际与预期结果、环境版本、截图日志、严重程度与优先级。", "严重程度反映技术影响，优先级反映修复紧迫性，两者需分别评定。", "缺陷跟踪工具（如 Bugzilla、Jira、禅道）提供流程流转、统计分析与度量。", ]), ], 14: [ ("测试执行与结果记录", [ "执行前确认准入条件：版本正确、环境与数据就绪、用例已评审。", "执行中如实记录实际结果、执行时间、环境与失败现象，保留截图与日志证据。", "用例状态：通过、失败、阻塞、未执行；阻塞需说明原因与解除条件。", "失败用例应先做自检（数据、环境、脚本），再判定为缺陷，避免误报。", ]), ("缺陷报告与跟踪", [ "缺陷报告的核心是可复现：步骤最小化、描述客观、证据充分、期望结果明确。", "缺陷分类与定级依据影响范围、严重程度与出现频率，便于研发排期。", "跟踪闭环：修复后回归验证，确认无回归并关闭，遗留缺陷需评估发布风险。", "定期做缺陷分析：缺陷密度、分布、根因与趋势，反哺设计与测试改进。", ]), ("测试进度与质量管理", [ "进度管理方法：里程碑与任务分解、燃尽图、每日站会同步阻塞与风险。", "进度与质量、成本相互制约，压缩测试时间必然提高遗留缺陷风险，需显式权衡。", "质量度量：需求覆盖率、用例执行率与通过率、缺陷发现与修复趋势、遗留缺陷等级。", "测试报告需给出明确的发布建议与遗留风险说明。", ]), ("测试报告与结果评估", [ "测试报告内容：测试范围与依据、环境与数据、执行统计、缺陷汇总、结论与建议、风险与遗留问题。", "结论必须有数据支撑：用例执行情况、缺陷分布与趋势、关键需求验证结果。", "评估需区分“测试完成”与“质量达标”：执行完毕不代表可以发布。", "报告面向不同干系人：管理层关注结论与风险，开发关注缺陷细节，需分层表述。", ]), ], 15: [ ("测试技术的发展趋势", [ "测试左移与右移：需求与设计阶段介入，生产环境持续监控与反馈闭环。", "智能化测试：用大模型辅助用例生成、脚本维护、缺陷定位与测试数据分析。", "精准测试与变更影响分析：依据代码变更与调用关系选择回归范围，降低回归成本。", "质量内建：把质量责任嵌入研发流程与工程能力，而非依赖末端把关。", ]), ("测试组织与岗位能力", [ "岗位方向：功能测试、自动化测试、性能测试、安全测试、测试开发与质量工程师。", "能力结构：测试理论与方法、编程与工具、业务理解、分析与沟通、工程规范意识。", "职业发展强调持续学习与工程质量思维，测试开发能力是重要增长点。", ]), ("综合案例复盘", [ "以本学期真实缺陷事故案例为主线，复盘缺陷产生的根因与可预防环节。", "对照测试流程与规范，评估案例中缺失的测试活动与改进措施。", "把案例经验转化为检查表与测试策略，应用于课程设计项目。", ]), ], } KEY_OUTLINE.update({ 1: [ ("软件测试的必要性：从真实事故说起", [ "《狮子王》安装失败、Intel 奔腾浮点除法错误、火星探测器坠毁、波音星际客机、骑士资本 4.6 亿美元损失、AWS S3 四小时宕机、Therac-25 放疗仪致死——缺陷代价可能远超开发成本。", "软件缺陷客观存在：需求理解偏差、设计疏漏、编码错误、集成不当与运行环境差异都会引入缺陷。", "测试是产品发布前的质检关卡，缺少把关的软件等于把风险直接交给用户。", "国产游戏《血狮》（1997）宣传远超前于被验证的产品：大量用户无法安装运行、兼容性差、功能与宣传不符，成为反面教材。", ]), ("为什么要进行软件测试", [ "测试的直接目的是保证软件质量：软件总存在缺陷，只有通过测试才能发现缺陷，只有发现缺陷才可能将其清除。", "缺陷发现得越迟，修复成本越高且呈非线性增长；测试左移的本质是尽早发现、降低总成本。", "缺陷带来的损失包括直接经济损失、人身安全风险、企业信誉受损与法律合规责任。", "测试不仅发现问题，也提供质量信息，支撑发布决策与风险评估。", ]), ("什么是软件测试", [ "定义：在指定条件下运行或评审系统与组件，观察或记录结果，对照预期作出评价。", "测试包含静态测试（评审、走查、静态分析）与动态测试（执行程序观察结果）。", "狭义测试把测试等同于程序测试；广义测试认为软件不只是可执行程序，文档、数据与配置同样需要验证。", "正向思维（Bill Hetzel）：测试是评价程序或系统特性、确认是否达到预期结果的活动。", "反向思维（Glenford J. Myers）：测试是为了发现错误而执行程序的过程，测试的目的是发现缺陷而非证明正确。", ]), ("软件测试学科的形成与发展", [ "从“调试即测试”到独立学科：测试由开发者的附属活动发展为独立的工程实践与职业岗位。", "以缺陷预防为导向的现代测试观：测试贯穿需求、设计、编码、集成、发布与运维全生命周期。", "质量内建思想：把质量责任嵌入研发流程，而不是依赖末端把关。", ]), ("测试与质量保证（SQA）", [ "SQA 面向过程，通过规范、评审、度量与过程改进保证质量体系的建立与执行。", "测试面向产品，通过验证与确认获取产品质量信息。", "两者互补：没有过程保证的测试只能反复救火，没有测试的 SQA 缺乏事实依据。", ]), ("测试与开发的关系", [ "开发与测试是并行协作关系：测试在需求与设计阶段即介入（测试左移），而非开发完成后才开始。", "测试驱动开发（TDD）主张先写测试再写实现：以测试明确需求、驱动设计、形成回归保护网。", "在敏捷团队中，开发与测试逐渐融合，提倡整个团队对质量负责。", ]), ("测试岗位与能力要求", [ "岗位方向：功能测试、自动化测试、性能测试、安全测试、测试开发与质量工程师。", "能力结构：测试理论与方法、编程与工具、业务理解、分析与沟通、工程规范意识。", "从就业市场看，测试岗位需求稳定，自动化与测试开发是主要增长方向。", ]), ("课程导学与课程设计任务", [ "课程定位：专业选修、32 学时 / 2 学分，第 1–17 周含实验，期末以课程设计作品与答辩考核。", "主线安排：原理方法 → 测试技术 → 项目实践，教材为朱少民《软件测试方法和技术（第 4 版）》。", "课程设计任务：以一个具体软件系统为对象，完成测试需求分析、测试计划、用例设计、执行、缺陷报告与总结答辩。", "考核构成：考勤与课堂表现 10% ＋ 实验与阶段任务 40% ＋ 课程设计（计划与用例 15% ＋ 执行与缺陷 15% ＋ 报告与答辩 20%）。", ]), ], 2: [ ("软件缺陷与软件质量", [ "软件缺陷：系统或组件中存在的、导致其无法满足预期需求或产生不正确结果的瑕疵。", "缺陷来源贯穿全生命周期：需求二义与遗漏、设计缺陷、编码错误、接口不匹配、环境与数据问题。", "软件质量内涵包括功能性、可靠性、易用性、效率、可维护性与可移植性等特性（参照 ISO/IEC 25010）。", "质量成本分为预防成本、评价成本与失效成本（内部/外部），缺陷越早发现总成本越低。", ]), ("软件测试的分类与测试级别", [ "按是否运行程序：静态测试与动态测试。", "按对内部结构的了解程度：黑盒测试、白盒测试、灰盒测试。", "按测试目的：功能测试、性能测试、兼容性测试、安全性测试、可靠性测试、易用性测试等。", "测试级别：单元测试、集成测试、系统测试、验收测试，各阶段对象、目标与执行主体不同，构成完整测试链。", ]), ("静态测试与动态测试", [ "静态测试不运行程序：文档评审、代码走查、代码审查、静态分析工具检查。", "静态测试可在编码前发现问题，成本最低；对文档与规范质量依赖较大。", "动态测试通过执行程序并观察结果，验证功能与非功能需求是否满足。", "两者互补：静态测试覆盖“无法执行”的问题，动态测试验证运行时的真实行为。", ]), ("主动测试与被动测试", [ "主动测试：测试者主动设计并执行用例，按计划施压，发现问题的可控性高。", "被动测试：在系统真实运行中被动收集信息（日志、监控、用户反馈），用于发现计划外问题。", "生产环境的监控与灰度发布属于典型的被动测试实践。", ]), ("黑盒、白盒与灰盒测试", [ "黑盒测试依据需求与业务规则，从外部输入输出验证功能，不关心内部实现。", "白盒测试基于代码结构，关注语句、分支、条件与路径覆盖。", "灰盒测试结合两者：了解部分内部结构（如接口、数据库）以设计更有效的用例。", "选择依据：需求稳定性、代码可获取性、风险等级与投入成本。", ]), ("软件测试工作范畴与岗位分工", [ "工作范畴：测试需求分析、测试设计、测试执行、缺陷管理、测试环境与工具建设、测试度量与报告。", "分工：测试工程师、测试开发工程师、性能/安全专项测试工程师、测试经理。", "测试活动贯穿研发全流程，需与产品、开发、运维紧密协作。", ]), ], 5: [ ("传统的软件测试过程", [ "V 模型：需求分析、概要设计、详细设计、编码对应单元测试、集成测试、系统测试、验收测试，测试与开发阶段一一对应。", "W 模型：开发与测试并行，测试在需求阶段即介入并贯穿全过程。", "TMap：以结构化方式组织测试生命周期，强调计划、设计、执行、评估与改进的闭环。", "传统过程强调阶段评审、文档与准入准出条件。", ]), ("敏捷测试过程", [ "敏捷宣言与原则：个体与互动、可工作的软件、客户合作、响应变化优先于流程与文档。", "敏捷测试特征：测试与开发同步、迭代内完成验证、自动化回归支撑持续交付。", "测试左移（需求与设计阶段介入）与测试右移（生产环境监控与反馈）。", "基于会话的测试管理（SBTM）用于组织探索式测试，兼顾灵活性与可追溯性。", ]), ("软件测试学派与测试规范", [ "主要学派：分析学派（以需求与风险为驱动）、标准学派（以规范与流程为依据）、质量学派、上下文驱动学派、敏捷学派。", "测试规范包括测试计划、用例规范、缺陷报告规范、测试报告规范与配置管理要求。", "规范的价值在于保证一致性、可追溯性与可复用性，避免过度形式化。", ]), ("测试过程改进", [ "以度量驱动改进：缺陷逃逸率、缺陷密度、用例有效性、回归成本等。", "常见模型与框架：TMMi、TPI Next、CTP，用于评估并提升测试过程成熟度。", "改进要点：缺陷根因分析、测试资产复用、自动化覆盖与质量门禁建设。", "过程改进应结合团队规模与项目特点，小步迭代、持续验证效果。", ]), ], 9: [ ("本地化测试的基本概念", [ "本地化（L10n）是在国际化（I18n）基础上，把产品适配到目标语言与地区文化的过程。", "本地化测试验证本地化后的产品在语言、格式、功能与法律合规方面是否正确、完整、可用。", "与翻译验证的区别：翻译验证关注文字，本地化测试覆盖语言、界面、功能、数据与文化全维度。", ]), ("翻译验证", [ "检查译文准确性、术语一致性、语境恰当性与专业表达规范性。", "检查语言细节：标点规范、大小写、换行与截断、特殊符号与文化心理适宜性。", "典型问题：漏译、错译、术语不统一、译文过长导致界面溢出或遮挡。", ]), ("数据格式与区域设置验证", [ "日期与时间格式、度量衡单位、货币符号与精度、数字千分位与小数分隔符。", "复数规则、姓名与地址格式、时区与夏令时处理。", "字符集与编码：多语言字符显示、排序规则、输入法兼容性。", ]), ("本地化功能测试", [ "验证本地化版本的功能完整性与一致性：安装卸载、核心业务流、错误提示与帮助文档。", "验证区域相关的功能差异：支付方式、税率、隐私政策与法律条款合规。", "双字节与双向文字（如阿拉伯语 RTL）界面布局验证。", ]), ], 12: [ ("测试用例的构成与作用", [ "测试用例是为特定测试目标而设计的一组前置条件、输入数据、操作步骤与预期结果的集合。", "作用：明确“测什么、怎么测、预期是什么”，提升测试的有效性、可复用性、可评估性与可管理性。", "用例是测试执行与缺陷判定的依据，也是测试资产与知识传递的载体。", ]), ("测试用例的基本元素与书写标准", [ "最基本内容：用例编号、测试项、前置条件、测试数据、操作步骤、预期结果。", "其他重要属性：测试目的与类型、优先级（高/中/低）、所属层次（父/子/孙）、估计用时、设计者与版本。", "书写要求：避免含糊表述，预期结果必须可判定（Pass/Fail 明确），一条用例聚焦一个验证点。", "良好用例的特征：能最大程度发现隐藏缺陷、执行效率高、可重复、易维护。", ]), ("测试用例设计原则与颗粒度", [ "设计原则：代表性、典型性、覆盖需求、优先针对设计与功能弱点。", "颗粒度权衡：粗颗粒度用例数量少但定位困难；细颗粒度定位清晰但维护成本高。", "通过数据驱动把测试数据与步骤分离，兼顾覆盖广度与维护效率。", "设计方法综合使用等价类、边界值、判定表、场景法与错误猜测法。", ]), ("测试用例的组织与维护", [ "测试集（Test Suite）由一组相关用例及其测试环境构成，用于满足特定执行要求。", "组织维度：按功能模块、按测试类型、按优先级、按业务流程，便于分层执行与回归选择。", "维护内容：需求变更后同步更新用例、清理失效用例、补齐缺陷对应的回归用例。", "用例需评审：可执行性、覆盖充分性、预期结果明确性与冗余情况。", ]), ], })