1.测试过程之需求分析和测试计划

测试基础

流程

1.分析测试需求

2.编写测试计划

3.设计与编写测试用例

4.执行测试

5.评估与总结

测试目标

根据测试阶段不同可分为四个主要目标：预防错误（早期）、发现错误（开发阶段）、建立信心（验收阶段）、提供信息（运维阶段）

1.早期测试

• 实施时机：从需求分析阶段开始同步跟进，贯穿设计、编程全过程
• 测试形式：
  • 静态测试：不执行程序的测试方式，包括文档审查（需求/设计文档）和代码走查
  • 检查要点：错别字、逻辑错误、需求偏差（多/少/错误理解）
• 核心价值：预防错误发生，避免错误"兑现"（如需求误解导致后续开发偏差）
• 典型案例：检查需求文档是否准确反映用户真实意图，算法设计是否符合业务逻辑

2.组件测试和单元测试

• 测试对象：模块化开发的独立组件（如程序中的a/b/c/d模块）
• 必要性：
  • 隔离缺陷定位：避免多模块集成后难以追溯问题根源
  • 责任明确：类似四人合作项目出问题时需要明确责任方
• 执行主体：通常由开发人员或懂开发的测试人员实施
• 测试重点：验证单个组件功能实现的正确性

3.集成测试

• 测试策略：逐步组合已通过单元测试的模块（如a+b模块组合，c+d模块组合）
• 技术需求：需要既懂开发又懂测试的复合型人才
• 与单元测试区别：
  • 关注模块间接口和交互
  • 需要实际执行程序代码
• 典型问题：模块间数据传递错误、接口协议不匹配

4.系统测试

• 测试范围：完整集成的软件系统
• 角色分工：以专业测试人员为主导，开发人员参与度降低
• 核心目标：大规模发现缺陷（追求缺陷发现数量最大化）
• 阶段特征：仍处于可修正缺陷的开发阶段（区别于验收后的维护阶段）

5.验收测试

• 执行主体：最终用户或客户代表
• 目标转变：从"发现缺陷"转为"建立使用信心"
• 通过标准：基本功能满足需求，非关键缺陷不影响主要使用
• 商业价值：决定软件能否正式交付的重要环节

6.运行或维护阶段

• 测试类型：
  • 非功能测试：性能、资源占用、兼容性等实际运行指标
  • 维护测试：漏洞修复、版本升级、灾难恢复等场景测试
• 数据反馈：收集真实使用环境下的质量信息（性能基线、用户行为数据）
• 持续改进：为后续版本迭代提供优化依据

区分概念

1.测试&调试

• 人员:
  • 测试：测试人员、开发人员和用户都会参与缺陷发现过程
  • 调试：仅由开发人员负责缺陷修复

2.软件质量保证&软件测试

• 测试三要素:
  • 发现：通过专业方法识别软件中的缺陷
  • 报告：使用缺陷管理系统规范提交问题
  • 跟踪：持续验证缺陷修复状态直至关闭
• 调试三步骤:
  • 定位：精确找到缺陷出现的代码位置
  • 分析：诊断缺陷产生的根本原因
  • 修改：编写正确的代码解决方案

软件测试定义: 软件测试不仅是对程序的测试，而是对软件所有部分（包括程序、数据和文档）的测试。

测试的过程

• 测试过程: 测试过程包括需求分析、计划制定、用例编写、执行测试、评估与总结。其中，执行测试只占整个测试过程的一小部分时间，需求和用例设计占据大部分时间（各约30%-40%）。

开始测试工作的任务

• 开始测试的首要任务: 测试需求分析。

测试早做和测试晚做的考虑
测试早做的优势: 测试早做比较好，最好在开发需求分析阶段就同步介入。
5. 测试需要谋划或规划
测试规划: 在测试之前需要制定测试计划，明确测试内容、范围、人员、时间以及可能遇到的问题和解决方案。

软件测试的原则

规格说明书（需求定义）占54%

设计阶段占25%

代码实现占15%

其他原因占6%

- 主要责任方：缺陷主要来源于需求相关方（用户、需求分析师等），而非程序员
- 深层原因：包括需求表述不清、理解偏差、沟通不畅等非技术因素
- 软件缺陷构成分析 
    * 数据解读：基于对100个典型缺陷的溯源研究
    * 重要性排序：需求问题 > 设计问题 > 编码问题 > 其他问题
    * 柱状图展示：以可视化形式再次验证饼图结论，需求文档缺陷占比最高
- 测试第一个任务是需求分析 
    * 工作流程：测试工作必须从需求分析开始，贯穿整个测试周期
    * 持续关注：即使在后续测试阶段也要不断回顾需求文档
    * 需求理解：需要确保测试团队与开发团队对需求的理解完全一致
- 制造缺陷的罪魁祸首不是程序员
    * 认知误区破除：发现缺陷时不应首先归咎于开发人员
    * 全面分析：需要考察缺陷是否源于需求定义不明确或不完整
    * 团队协作：测试人员应与需求分析人员保持密切沟通
- 做好需求评审 
    * 评审机制：组织开发、测试、用户三方共同参与需求评审
    * 一致性检查：确保测试需求与开发需求、用户需求三者一致
    * 文档验证：通过正式会议确认需求文档的准确性和完整性

完全测试不可能

• 并行性：测试应与软件开发或维护工作并行进行，持续开展测试活动
• 前置规划：在测试工作正式开始前较长时间就需制定测试计划，包括需求分析、环境搭建、缺陷处理、评估总结等全流程规划
• 计划价值：测试计划越详尽，测试过程越能避免走弯路，计划需覆盖整个测试生命周期

测试阶段

单元测试->集成测试->系统测试->验收测试

• 并行性：测试应与软件开发或维护工作并行进行，持续开展测试活动
• 前置规划：在测试工作正式开始前较长时间就需制定测试计划，包括需求分析、环境搭建、缺陷处理、评估总结等全流程规划
• 计划价值：测试计划越详尽，测试过程越能避免走弯路，计划需覆盖整个测试生命周期
• 单元测试特点：针对每个独立小程序进行测试，代码规模最小，由开发人员主导
• 集成测试特点：将相互调用的程序模块组合测试，代码规模中等，开发人员参与
• 系统测试特点：所有程序整体测试，代码规模最大，由专业测试人员执行
• 验收测试特点：用户主导的最终验证测试，不涉及代码层面
• 分阶段优势：能准确定位问题来源（如单元测试可隔离错误），符合"尽早测试"原则
• 实施条件：公司自有项目容易实现，外包项目可能难以严格分阶段

软件测试是一个迭代的过程

• 核心特征：测试活动是持续循环进行的，不是一次性完成的，每个版本都需要重复测试流程
• 典型流程：测试版本1→提交缺陷→修复缺陷→测试版本2→提交新缺陷→修复新缺陷→测试版本3→⋯测试版本1 ->提交缺陷 修复缺陷 ->测试版本2 -> 提交新缺陷 -> 修复新缺陷 -> 测试版本3 ->cdots测试版本1→提交缺陷→修复缺陷→测试版本2→提交新缺陷→修复新缺陷→测试版本3→⋯

处理小组关系

• 共同目标导向: 时刻提醒团队成员（包括自己）最终目标是追求高质量产品，而非追究缺陷责任人。应以合作而非争斗的态度处理问题。
• 中性沟通技巧:
  • 缺陷报告应采用中性、事实性陈述，避免使用"你/我/他"等人称代词
  • 禁用问号、叹号等带有情绪色彩的标点符号
  • 示例：用"登录按钮点击无响应"替代"你的登录功能有问题！"
• 换位思考原则:
  • 理解他人反应背后的原因
  • 反思自身沟通方式是否恰当
  • 考虑对方专业背景导致的认知差异
• 有效沟通保障:
  • 确认双方理解一致（开发理解缺陷描述，测试理解开发思路）
  • 清晰说明缺陷危害性和严重程度
  • 建立"发现-修复缺陷"的共同目标认知
• 技能互补优势:
  • 测试人员掌握基础开发知识可减少误报
  • 开发背景有助于理解系统实现原理
  • 技术共识能提升缺陷报告的专业可信度

软件开发模型

- 软件产品从最初构思到最终退役的全过程
- 包含从创意产生到停止使用的完整时间线

1.什么是软件开发模型

软件产品从最初构思到最终退役的全过程

大爆炸模型

边写边改模型

瀑布模型

制定周密计划的开发模型，强调分阶段严格审查和完整文档记录，步骤不可颠倒（计划→需求分析→设计→编码→测试→运行→评价→维护循环）

螺旋模型

敏捷模型

软件测试模型

V模型

    * 左端为开发阶段：用户需求→需求分析→概要设计→详细设计→编码
    * 右端为测试阶段：单元测试→集成测试→系统测试→验收测试
- 对应关系:
    * 单元测试↔详细设计
    * 集成测试↔概要设计
    * 系统测试↔需求分析
    * 验收测试↔用户需求
- 分层策略:
    * 底层测试: 单元测试和集成测试，验证源代码正确性
    * 高层测试: 系统测试和验收测试，验证需求符合性

W模型

双V结构: 由两个V字型构成，左边V代表开发过程（需求分析→概要设计→详细设计→编码实现→模块集成→系统构建→系统安装），右边V代表测试过程（需求测试→概要设计测试→详细设计测试→单元测试→集成测试→系统测试→验收测试）

• 需求测试: 验证需求说明书是否准确反映用户真实需求，检查有无遗漏、错误或多余需求
• 设计测试:
  • 概要设计测试：验证系统架构和算法是否正确
  • 详细设计测试：检查具体实现细节是否合理
• 文档测试本质: 不是简单检查文档错别字或病句，而是通过文档验证开发人员对需求和设计的理解是否正确

H模型

• 核心结构:
  • 上方为测试流程：包含"准备测试→就绪点→测试执行"三个阶段
  • 下方为其他流程：可以是开发、设计、编码等任意流程
  • 中间通过"就绪点"连接两个流程

特点：

• 独立性:
  • 测试活动完全独立于开发流程
  • 不再被开发阶段所牵制（不同于V模型和W模型）
  • 测试团队可自主安排测试活动
• 并发性:
  • 测试贯穿整个产品生命周期
  • 可与任何开发活动并行进行
  • 示例：需求分析阶段可同步开展需求文档测试
• 完整性:
  • 不仅包含测试执行，还包括：
    • 测试计划制定
    • 需求分析验证
    • 测试用例设计
    • 测试环境搭建
    • 缺陷提交与跟踪
    • 测试评估总结
• 灵活性:
  • 测试层次可打乱传统次序
  • 支持不同测试活动并行开展（如单元测试与集成测试可同时进行）
  • 示例：外包团队可分别负责不同层次的测试
• 就绪机制:
  • 当测试准备工作完成时到达"就绪点"
  • 就绪后立即转入测试执行阶段
  • 强调"尽早准备，尽早执行"原则

X模型

前置模型

敏捷测试模型

• 核心特点:
  • 新型软件开发方法，强调客户持续参与
  • 测试活动贯穿整个开发过程，与传统开发模式有显著区别
  • 采用结对编程方式，两名开发人员共用一台计算机协同工作

测试模型的使用

V模型

对应开发模型: 与瀑布模型配套使用，左边V表示开发流程，右边V表示测试流程

测试特点: 在瀑布模型每个开发环节完成后进行对应测试，属于后置测试模式

优化意义: 对传统瀑布模型的测试环节进行了系统化优化，形成完整测试体系

适用场景: 适合需求明确、变更少的项目，测试阶段划分清晰

W模型

模型特征: 双V结构形成W形状，开发与测试同步进行

对应开发模型: 主要配套螺旋模型使用，测试早期介入项目

产生背景: 伴随公司内部测试团队的工作模式而诞生

优势: 开发过程中测试团队可同步跟进，实现并行工作

H模型

核心特点: 测试完全独立于开发流程，可随时启动

触发机制: 当测试准备工作完成到达"就绪点"时即可执行测试

产生背景: 为适应第三方测试需求而发展出的模型

灵活性: 支持多团队并行测试不同模块，文档也可单独测试

应用场景: 特别适合外包项目或需要多团队协作的大型项目

敏捷测试模型

配套开发模型: 专为敏捷开发设计，强调客户持续参与

工作流程:

先编写测试用例

结对编程时同步测试

单元测试通过后集成代码

最终由客户进行验收测试

核心理念: 通过频繁交付和客户反馈实现快速迭代

测试阶段

单元测试

前置条件

功能性验证: 确保单元能正确实现设计功能，如编写求和方法时，需验证能否正确计算两数之和。

健壮性测试: 通过逆向测试验证单元对无效输入的容错能力，包括测试字母、汉字、标点符号等非法输入时的报错处理。

性能优化: 关注代码执行效率，比较不同实现方式的性能差异。例如：比效率更高，因为计算机需将乘法转换为加法运算；排序算法中不同方法的时间消耗差异（冒泡排序vs二分法排序）。

测试局限性: 单元测试阶段无法测试界面、兼容性和易用性等特性，因代码尚未形成完整运行环境。

测试所用技术

白盒测试技术

• 核心概念：将程序视为透明盒子，关注内部处理流程和程序结构
• 测试对象：包括顺序语句、if语句、if-else、switch-case、while/for循环等程序结构，以及>>>,<<<,andandand,ororor等逻辑运算符
• 典型方法：通过覆盖率指标（语句覆盖、分支覆盖等）来验证程序内部逻辑
• 测试特点：需要观察程序执行的每个细节过程，就像观察透明机器中鸡被拔毛时的反应（痛苦程度、是否挣扎等）

黑盒测试技术

• 核心概念：将程序视为黑色盒子，只关注输入输出是否符合预期
• 测试对象：程序整体功能，不关心内部实现细节
• 典型方法：等价类划分、边界值分析、场景法、决策表、错误猜测等
• 测试特点：如同给机器蒙上黑布，只关心投入公鸡后是否光着出来（功能结果），不关心内部处理过程
• 应用顺序：通常先进行黑盒测试验证基本功能，再进行白盒测试（先确认程序能完成基本功能再检查内部结构）

灰盒测试

• 混合特性：结合白盒和黑盒测试的特点
• 典型应用：网页测试中，既检查前台输入输出（黑盒），又检查部分代码（白盒）
• 优势：能兼顾功能验证和部分内部逻辑检查

组件测试能够发现的缺陷

• 功能性缺陷：组件内部功能实现错误
• 运行时缺陷：仅在实际运行时会暴露的问题（如死循环）
• 本机性能问题：代码层面的性能瓶颈
• 健壮性问题：异常处理能力不足等鲁棒性问题
• 测试局限：只能发现组件单独运行时的缺陷，无法发现与其他组件的交互问题

组件测试可能遗留的缺陷

• 接口问题：组件间参数传递和返回值问题
• 大环境问题：多组件协同工作时的兼容性问题
• 非功能性缺陷：界面美观性、易用性、整体系统性能等
• 遗留原因：单元测试环境与真实运行环境存在差异，无法完全模拟实际使用场景

集成测试

• 测试重点:
  • 接口测试: 组件连接时的静态参数传递机制
  • 交互测试: 系统各部分协同工作的动态行为
• 必备知识:
  • 开发技能(需编写测试驱动器和桩模块)
  • 测试技术专业知识
  • 组件间交互的详细知识(参数传递规则、数据处理逻辑)
• 前提条件:
  • 已完成集成的被测系统
  • 测试台(test bed)的建立(包含可复用的测试工具和环境)
  • 完整的组件交互文档
• 关键区别:
  • 单元测试: 验证独立模块功能，侧重内部逻辑
  • 集成测试: 验证模块组合功能，侧重接口和交互

系统测试

定义：测试集成系统以验证它是否满足指定需求的过程，是基于风险的测试，确认系统满足特定的功能性和非功能性需求。

• 测试对象：整个集成后的系统，如同拼图中所有单元模块组合完成的整体。
• 环境要求：测试环境应尽可能与目标环境保持一致，不再是开发环境，而是接近用户实际使用环境。
• 测试范围：包含之前单元测试和集成测试未覆盖的全部功能性和非功能性需求（如性能、易用性、兼容性、界面、安全性、可维护性、可移植性等）。

验收测试

• 执行主体: 由客户方的商业用户/普通使用者执行
• 测试重点:
  • 验证系统可用性
  • 检查是否满足基本业务需求
  • 确认无严重影响使用的缺陷
• 典型场景: 如普通员工测试新采购的办公系统是否能完成日常业务流程

• Alpha测试:
  • 在开发场地由潜在用户执行（如游戏公司邀请玩家到公司内部测试）
  • 又称"内测"，测试环境受控
  • 目的：发现开发环境下的系统问题
• Beta测试:
  • 在用户实际环境执行（如软件公测版发布）
  • 又称"公测"或"外测"，测试环境多样
  • 特点：自动收集使用数据（用户可能不知情）
  • 目的：识别未知环境下的系统影响
• 关键区别:
  • 测试场地不同（开发场地 vs 用户环境）
  • 测试规模不同（小范围 vs 大规模）
  • 游戏行业典型应用：内部封测→公开测试→正式发行

项目功能拆分与测试点

• 评审方式：分为小评审（小组内部讨论功能拆分、需求整理和测试点）和大评审（集体评审）
• 功能表示方法：习惯用按钮名称表示功能（如"确定"代表连接数据库），但表示方式不固定