软件测试基础和理论相关

软件测试理论与基础 完整学习大纲

一、 软件测试基础概念

• 1.1 软件测试的定义与目标
  • 定义：通过运行或评价软件，以验证其是否满足规定要求或识别与实际结果之间的差异的过程。
  • 核心目标：
    • 发现缺陷（主要目标）。
    • 验证软件是否满足需求规格说明书和用户需求。
    • 建立对软件质量的信心。
    • 预防缺陷。
• 1.2 软件缺陷
  • 定义：软件中存在的、会破坏其正常运行能力的问题、错误或故障。
  • 常见缺陷来源：需求、设计、编码、测试、环境。
  • 缺陷生命周期：新建 -> 打开 -> 分配 -> 修复 -> 验证 -> 关闭（或重新打开）。
• 1.3 质量、质量保证与质量控制
  • 软件质量：软件产品满足明确或隐含需求的能力的特性总和（ISO 9126模型）。
  • 质量保证：一套有计划的、系统性的活动，确保开发过程遵循既定标准和规程，旨在预防缺陷。
  • 质量控制：识别缺陷的操作技术和活动，旨在识别缺陷（如测试）。
  • QA vs QC：QA关注过程，QC关注产品。
• 1.4 测试的基本原则（七大原则 - ISTQB）
  1. 测试证明缺陷的存在：测试无法证明软件无缺陷。
  2. 穷尽测试是不可能的：必须基于风险和优先级进行测试。
  3. 尽早测试：测试活动应尽早介入开发生命周期，以降低成本。
  4. 缺陷集群性：缺陷往往集中存在于少数模块中。
  5. 杀虫剂悖论：重复同样的测试用例会发现的新缺陷越来越少。
  6. 测试活动依赖于上下文：没有一种“放之四海而皆准”的测试方法。
  7. 不存在缺陷的谬论：即使软件符合需求，但如果需求本身是错的，软件仍是不可用的。

二、 软件开发生命周期与测试模型

• 2.1 软件开发生命周期 (SDLC) 模型
  • 瀑布模型：线性的、阶段性的开发模型，测试通常在开发后期进行。
  • V模型：强调测试与开发的并行性，每个开发阶段对应一个测试级别。
  • 增量与迭代模型：软件被分解为多个部分，逐步构建和测试。
  • 敏捷模型 (Scrum, Kanban, XP)：强调迭代、协作和快速响应变化。测试是每个迭代的核心部分。
• 2.2 测试模型与测试过程
  • 测试过程：通用的测试活动集合，包括测试计划、设计、执行、评估、报告。
  • 测试左移：在开发生命周期的早期引入测试活动（如需求评审、静态测试）。
  • 测试右移：在软件发布后进行测试（如A/B测试、线上监控、众测）。
  • 测试级别：与SDLC阶段对应的测试活动（组件、集成、系统、验收）。

三、 测试的层次与类型

• 3.1 测试级别
  • 单元测试：验证单个软件单元（如函数、类、模块）的功能。通常由开发者完成。
  • 集成测试：验证多个单元、组件或系统之间的交互。关注接口和数据流。
  • 系统测试：在完整的、集成的系统上执行测试，以验证其是否满足指定的需求。关注端到端流程。
  • 验收测试：由用户/客户执行，以确定是否接受软件。包括：
    • 用户验收测试：验证是否满足用户需求。
    • 运营验收测试：验证可维护性、兼容性、部署等。
    • Alpha/Beta测试：在受控/不受控的实际用户环境中进行。
• 3.2 测试类型 (按测试目标/特性分类)
  • 功能测试：验证软件功能是否符合需求规格。
  • 非功能测试：验证软件的质量属性。
    • 性能测试：负载、压力、耐力、尖峰、容量测试。
    • 安全性测试：漏洞、渗透、授权、认证测试。
    • 可用性测试：用户界面、用户体验、可访问性。
    • 兼容性测试：跨浏览器、跨平台、跨设备、向后兼容。
    • 可靠性测试：在指定条件下无故障运行的能力。
    • 可移植性测试：软件在不同环境间迁移的能力。
  • 结构测试 (白盒测试)：基于代码内部结构进行测试。
  • 与变更相关的测试：
    • 回归测试：验证修改后的软件未对现有功能产生负面影响。
    • 再测试 (确认测试)：对已修复的缺陷进行重新测试。

四、 静态测试与动态测试

• 4.1 静态测试
  • 定义：在不运行软件的情况下检查其表示（文档、代码）。
  • 形式：评审、静态分析。
  • 对象：需求文档、设计文档、源代码、测试用例、用户手册。
  • 优点：早期发现缺陷，成本低。
• 4.2 动态测试
  • 定义：通过运行软件来验证其行为。
  • 形式：执行测试用例，观察输出。
• 4.3 评审
  • 正式评审：有严格的流程和角色，如审查。
  • 非正式评审：走查、结对编程、同行评审。
  • 评审角色：作者、主持人、评审员、记录员。
  • 评审过程：计划 -> 启动会议 -> 个人准备 -> 评审会议 -> 返工 -> 跟踪。

五、 黑盒、白盒与灰盒测试技术

• 5.1 黑盒测试技术 (基于规格)
  • 定义：无需了解内部结构，基于输入和输出进行测试。
  • 等价类划分：将输入域划分为有效/无效等价类，从每个类中选取代表性值。
  • 边界值分析：关注输入域的边界值（上点、离点）。
  • 决策表测试：处理多个输入条件与输出动作之间的逻辑关系。
  • 状态转换测试：测试系统在不同状态间的转换。
  • 用例测试：基于用户场景或业务流程设计测试用例。
• 5.2 白盒测试技术 (基于结构)
  • 定义：基于代码内部逻辑结构进行测试。
  • 语句覆盖：每条可执行语句至少执行一次。
  • 判定覆盖 (分支覆盖)：每个判断的真假分支至少执行一次。
  • 条件覆盖：每个判断中的每个条件取真/假至少一次。
  • 判定/条件覆盖：同时满足判定覆盖和条件覆盖。
  • 路径覆盖：覆盖程序中所有可能的路径（通常不可行）。
• 5.3 灰盒测试
  • 定义：结合黑盒和白盒的方法，基于有限的内部知识（如接口定义、架构图）进行测试。

六、 测试分析与设计

• 6.1 测试分析与设计活动
  • 评审测试依据：分析需求、用户故事、架构等。
  • 识别测试条件：确定“测试什么”。
  • 设计测试用例：详细描述输入、执行条件、预期结果。
  • 建立测试数据与环境需求。
• 6.2 测试用例设计
  • 好的测试用例特征：可追溯、可重复、具体、独立。
  • 测试用例要素：用例ID、标题、优先级、预置条件、测试步骤、测试数据、预期结果、实际结果、状态。
• 6.3 测试用例管理
  • 测试用例的粒度：高层次的检查点 vs 详细的操作步骤。
  • 管理工具：Excel, TestLink, Jira (Zephyr), TestRail, QMetry。

七、 测试流程与文档

• 7.1 基本测试流程 (ISTQB)
  1. 测试计划与控制：定义目标、策略、资源和日程。监控测试进度。
  2. 测试分析与设计：将测试目标转化为具体的测试条件和用例。
  3. 测试实现与执行：准备测试环境、数据，执行测试用例，记录结果。
  4. 评估出口准则与报告：根据预定义标准评估是否完成测试，并生成报告。
  5. 测试结束活动：存档测试资产，总结经验教训。
• 7.2 关键测试文档
  • 测试计划：定义测试的总体方法、目标、范围、资源、日程、风险。
  • 测试设计规格说明：详细描述测试条件、测试用例和测试数据。
  • 测试用例：执行测试的最小单元。
  • 测试规程：执行一组测试用例的步骤。
  • 缺陷报告：描述发现的缺陷。
  • 测试总结报告：总结测试活动和结果，评估产品质量。

八、 缺陷管理

• 8.1 缺陷生命周期与状态流转
  • 新建 -> 打开 -> 分配 -> 修复 -> 验证 -> 关闭/重新打开/延迟/拒绝。
• 8.2 缺陷报告
  • 要素：标题、严重程度、优先级、复现步骤、实际结果、预期结果、环境、附件（截图、日志）。
  • 编写原则：客观、准确、清晰、可复现。
• 8.3 缺陷严重程度与优先级
  • 严重程度：缺陷对系统功能的影响程度（致命、严重、一般、轻微）。
  • 优先级：修复缺陷的紧急程度（高、中、低）。两者无必然联系。

九、 测试管理

• 9.1 测试估算
  • 方法：基于经验的猜测、基于工作分解、基于测试点分析、使用历史数据、德尔菲法。
• 9.2 测试策略与测试计划
  • 测试策略：高层次文档，描述测试的总体方法和目标。
  • 测试计划：基于策略，描述具体“如何做”。
• 9.3 测试监控与控制
  • 监控指标：测试用例通过率、缺陷发现率、缺陷密度、测试执行进度、需求覆盖率。
  • 控制动作：根据监控结果调整测试计划、资源、范围。
• 9.4 配置管理
  • 确保所有测试工件（用例、脚本、数据）都被版本控制，并与正确的软件版本对应。
• 9.5 风险与测试
  • 项目风险：可能影响项目成功的事件（如资源短缺）。
  • 产品风险：软件中可能存在的问题（如性能不达标）。
  • 基于风险的测试：将测试重点放在风险最高的区域。

十、 测试技术与趋势

• 10.1 自动化测试
  • 何时自动化：重复性高、回归测试、多配置测试、性能测试。
  • 金字塔模型：单元测试（底层，量大）、集成/服务测试（中层）、UI测试（顶层，量少）。
  • 自动化框架：数据驱动、关键字驱动、混合驱动、行为驱动开发。
• 10.2 性能测试 (扩展)
  • 负载测试、压力测试、耐力测试、尖峰测试。
• 10.3 安全测试 (扩展)
  • OWASP Top 10，渗透测试，漏洞扫描。
• 10.4 探索性测试
  • 在测试设计的同时进行测试执行，强调测试人员的自由度和创造力，以发现计划外缺陷。
• 10.5 测试驱动开发与行为驱动开发
  • TDD：先写失败的单元测试，再写最小代码使其通过，然后重构。
  • BDD：用自然语言描述功能行为（Given-When-Then），促进业务、开发和测试的协作。
• 10.6 敏捷与DevOps中的测试
  • 持续测试：在CI/CD流水线中自动化执行测试。
  • 测试左移：开发人员承担更多测试责任（如单元测试）。
  • 测试右移：关注生产环境监控和反馈。

十一、 测试团队与职业

• 11.1 测试角色与职责
  • 测试经理/主管：管理团队、计划、资源、报告。
  • 测试分析师/设计师：设计测试用例、分析需求。
  • 测试工程师：执行测试、报告缺陷、可能编写自动化脚本。
  • 自动化测试工程师：专攻测试自动化框架和脚本开发。
  • 性能/安全测试专家。
• 11.2 测试人员的技能
  • 硬技能：测试技术、工具使用、领域知识、编程/脚本。
  • 软技能：沟通、批判性思维、好奇心、怀疑精神、细致。
• 11.3 职业认证
  • ISTQB：国际软件测试资格认证委员会，提供基础、高级、专家级别认证。
  • CSTE, CSQA 等。

十二、 标准、术语与资源

• 12.1 主要术语标准
  • ISO/IEC/IEEE 29119：软件测试国际标准系列。
  • ISTQB术语表。
• 12.2 学习资源
  • 书籍：《软件测试的艺术》、《Google软件测试之道》、《敏捷软件测试》。
  • 网站/社区：Ministry of Testing, Software Testing Help, InfoQ, Stack Overflow。
  • 认证机构：ISTQB官方站点。