测试-测试过程

此物.....此物.......此物最相思！

测试过程

组织机构：公司人员结构
外包：1. 项目外包 2. 人力外包

• 测试阶段划分

  • 单元测试(白盒测试)-->集成测试(灰盒测试)-->系统测试(黑盒测试)
  • 单元测试：
    • 单元测试是针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的测试工作
    • 单元测试的目的是检测软件模块对《详细设计说明书》的符合程度
  • 集成测试：
    • 集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作
    • 集成测试的目的是检测软件模块对《概要设计说明书》的符合程度
  • 系统测试
    • 系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作
    • 系统测试的目的在于通过与《需求规格说明书》作比较，发现软件与系统需求定义不符合或与之矛盾的地方

• 单元、集成、系统测试的比较

  • 测试方法不同
    • 单元测试属于白盒测试范畴
    • 集成测试属于灰盒测试范畴
    • 系统测试属于黑盒测试范畴
  • 考察范围不同
    • 单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等
    • 集成测试主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能
    • 系统测试主要测试整个系统相对于需求的符合度
  • 评估基准不同
    • 单元测试的评估基准主要是逻辑覆盖率
    • 集成测试的评估基准主要是接口覆盖率
    • 系统测试的评估基准主要是测试用例对需求规格的覆盖率

• 回归测试

  • 软件在测试或其他活动中发现的缺陷经过修改后，应该进行回归测试（Regression Testing）。目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能
  • 回归测试可以发生在任何一个阶段，包括单元测试，集成测试，系统测试。

• 回归测试流程

  • 以下流程适合于单元测试，集成测试，系统测试
    • 1、在测试策略制定阶段，制定回归测试策略
    • 2、确定需要回归测试的版本
    • 3、回归测试版本发布，按照回归测试策略执行回归测试
    • 4、回归测试通过，关闭缺陷跟踪单（问题单）
    • 5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

• 回归测试策略一

  • 完全重复测试：重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性
  • 选择性重复测试：即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序
    • 覆盖修改法：即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法。
    • 周边影响法：该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响。该方法比覆盖修改法更充分一点。
    • 指标达成方法：这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。

• 回归测试自动化

  • 后面的功能由前面的数据支撑，而前面的功能没有bug，那么可以通过自动化脚本来写前面的测试部分。

• 什么时候需要回归测试

  • bug修复之后
  • 大版本升级

• 其它测试阶段

  • 有用户参与的测试阶段

    • 验收测试
    • α测试：现场测试（开发者在现场）
    • β测试：多用户/多环境的现场测试（开发者不在现场）

  • 测试过程：

    • 上线测试：验收测试之前的第一步测试
    • 验收测试：在客户端试运行

• 测试过程阶段划分

  • 测试计划阶段-测试计划
  • 测试设计阶段-测试方案
  • 测试实现阶段-测试用例、测试规程
  • 测试执行阶段-测试报告

• 测试总结：

  • 项目功能
  • 功能流程（联系）
  • 测试用例/测试功能/bug的数量
  • 收获（遇到的难点，解决的想法）

• 主要的测试文档

  • 测试计划：指明测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档。
  • 测试方案：指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。
  • 测试用例：指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档。（需要评审）
  • 测试规程：指明执行测试时测试活动序列的文档。
  • 测试报告：指明执行测试结果的文档。
  • 测试日报：每天测试执行情况的记录和总结。

• 常见的测试模型

  • 瀑布模型
  • H模型
  • V&V模型

• H模型

  • 测试分两类活动：
    • 测试准备活动，包括测试需求分析、测试计划、测试设计、测试编码、测试验证
    • 另一类是测试执行活动，包括测试运行、测试报告、测试结果分析等
  • 软件测试不仅仅指测试执行，还包括很多其他的活动。
  • 测试是一个独立的流程，贯穿产品整个周期，与其他流程并发地进行。
  • 测试要尽早准备，尽早执行。
  • 各个不同阶段的测试除了简单的时间上的先后关系外，还存在触发、反复、迭代和增量关系。

• v模型

  • V&V模型实现了测试设计和测试执行相分离
  • V&V模型揭示了软件测试活动分层和分阶段的本质特性，测试执行的顺序与开发活动相反

• 验证与确认V&V

  • 验证（Verification）---重点在软件
    • 验证是保证软件正确地实现特定功能的一系列活动
    • 验证是检测每一阶段形成的工作产品是否与前一阶段定义的规格相一致
    • “Are we building the product right？”
  • 确认（Validation）---重点在需求
    • 确认是指保证所生产的软件可追溯到用户需求的一系列活动
    • 确认是检测每一阶段的工作产品是否与最初定义的软件需求规格相一致
    • “Are we building the right product？”

• 需求分析阶段的主要任务

  • 需求分析，完成SRS
  • 软件需求规格说明书的评审
  • 进行需求跟踪
  • 系统测试计划
  • 系统测试计划的评审

• 需求阶段的角色和职责

  • 软件开发项目经理：
    • A、带领项目组分析审核工作任务书；计划
    • B、带领项目组与系统工程师进行需求交流并进行分析和文档化；
    • C、组织SRS文档评审；
    • D、组织需求跟踪；
  • 软件开发工程师：
    • A、完成SRS文档；
    • B、完成需求跟踪；
    • C、参加SRS review；
    • D、根据SRS评审专家意见，修改SRS文档；
    • E、参加系统测试计划的评审；
  • 软件经理：A、在SRS评审结束后，批准SRS文档；
  • 软件测试项目经理：
    • A、参与开发人员的软件需求分析，提出可测试性需求；
    • B、组织人员参与SRS的评审工作；
    • C、软件系统测试计划写作；
    • D、组织系统测试计划的评审；
    • E、组织本阶段测试需求跟踪；
  • 软件测试工程师：
    • A、参与SRS评审工作；
    • B、协助软件测试项目经理完成软件系统测试计划写作；
    • C、参加系统测试计划的评审；
    • D、完成本阶段测试需求跟踪；

• 概要设计阶段的主要任务

  • 进行软件系统各层设计，完成HLD文档
  • 概要设计的评审
  • 系统测试方案，用例的设计
  • 系统测试方案，用例的评审
  • 需求跟踪更新
  • 集成测试计划
  • 集成测试计划评审

• 概要设计阶段的角色和职责

  • 软件开发项目经理：
    • A、安排概要设计任务，并确保有足够的资源；
    • B、组织概要设计文档的评审；
    • C、批准评审后的概要设计说明书；
    • D、组织需求跟踪；
  • 软件开发工程师：
    • A、数据字典
    • B、完成需求跟踪；
    • C、参加概要设计文档review；
    • D、根据评审专家意见，修改概要设计文档；
    • E、参加系统测试方案、用例、集成测试计划的评审；
  • 测试经理：在集成测试计划评审结束后，批准集成测试计划。
  • 软件测试项目经理：
    • A、组织人员参与HLD的评审工作；
    • B、软件集成测试计划写作；
    • C、组织集成测试计划的评审；
    • D、安排相关系统测试方案、用例设计任务；
    • E、组织系统测试方案、用例评审；
    • F、组织本阶段测试需求跟踪；
  • 软件测试工程师：
    • A、参与HLD评审；
    • B、参与集成测试计划的评审；
    • C、进行系统测试方案、用例的设计；
    • D、参与系统测试方案、用例评审；
    • E、完成本阶段的测试需求跟踪；