文章目录
- 双V模型为例介绍测试过程
-
- 软件测试过程理念
- 1）需求阶段
- 2）设计阶段
- 3）详细设计阶段
- 4）编码阶段
- 5）内部测试
- 6）外部测试
-
- i、验收测试(在系统测试之后)
- ii、回归测试
- 7、测试过程(干什么，怎么干)
- 8、测试阶段过程要素
-
- 1）系统测试
- 2）集成测试
- 3）单元测试
双V模型为例介绍测试过程
SRS：需求规格说明书；HLD：概要设计文档；LLD：详细设计文档
BD：基本设计；DD：详细设计；FD：结构设计
SRS：为使用用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之称为整个开发工作的基础
HLD：设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每个模块的功能等
LLD：为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述
软件测试过程理念
- 尽早测试
- 测试人员早期参与软件项目
- 尽早的开展测试执行工作
- 全面测试
- 对软件的所有产品进行全面的测试
- 软件开发及测试人员（有时包括用户）全面的参与到测试工作中
- 全过程测试
- 测试人员要充分关注开发过程
- 测试人员要对测试的全过程进行全程的跟踪
- 独立的、迭代的测试
- 测试活动是独立的
- 测试活动应该是循环往复的、不断的进行
1）需求阶段
产品经理、项目经理，产品工程师写**《需求规格说明书》**Software Reqwirment Specaficalion(SRS)
- 内容：需求项（业务，主要功能），需求子项，对子项的详细描述
- 测试的工作：对需求进行测试和评审A系统测试计划《系统测试计划书》B系统测试计划《系统测试方案书》C系统测试实现《系统测试用例》
2）设计阶段
开发经理、架构师，开发工程师写出**《概要设计说明书》**High-level design(HLD)
- 内容：系统程序中的模块，子模块和他们之间的关系和接口
- 测试的工作：对HLD进行测试和评审A集成测试计划《集成测试计划书》B集成测试设计《集成测试方案书》C集成测试实现《集成测试用例》
3）详细设计阶段
开发工程师，架构师，写出 《详细设计说明书》 Low-level design(LLD)
- 内容：函数、代码、逻辑
- 测试工作：对LLD进行测试和评审A单元测试计划《单元测试计划书》B单元测试计划《单元测试方案书》C单元测试实现《单元测试用例》
4）编码阶段
开发工程师写代码
5）内部测试
| 测试阶段 | 测试对象 | 测试方法 | 测试目的 | 经济价值 | 优点 | 缺点 | 必要性 | 资源 |
|---|---|---|---|---|---|---|---|---|
| 系统测试ST | 整个系统(整个产品) | 黑盒测试 | 验证产品是否符合需求规格说明书 | 能够保证产品以较高的质量尽早的上市销售，从而使公司获取利润 | 1. 简单2.技术要求低 | 1.测试介入时间晚，修改成本高2.有一些问题可能被遗留不会被修改 | 必须保证 | 1.对被测产品2.需求规格说明书 |
| 集成测试IT | 模块、子模块、接口 | 灰盒测试 | 验证模块、子模块、接口是否符合概要设计说明书 | 能够帮助更准确的定位缺陷所在，从而降低了定位缺陷的成本 | 定位准确快速 | 1.接口测试有技术要求，技术实现难度大2.接口太多，数量庞大，做所有接口的集成测试成本高 | 不是必须做的；必须测试：公共的主要模块；核心模块；和外界软件接口模块 | 1.被测的产品2.概要设计说明书3.集成测试工程师4.概要设计人员 |
| 单元测试(UT) | 函数、代码、逻辑 | 白盒测试 | 验证函数代码逻辑是否符合详细设计说明书 | 能够最早的开展测试工作，降低修复成本，防止缺钱被扩大化(注意：公共的模块；全局性的数据结构；重要的使用频率较高的功能；以往项目经常出错的严重问题；复杂度较高的模块；当开发人员业务不熟悉编码不熟练的模块要进行单元测试) | 介入时间早，发现问题早，修改成本低 | 技术难度高；工作量太大 | 不是必须的 | 1.开发环境2.详细设计文档3.单元测试工程师4.架构师(详细设计人员) |
6）外部测试
使用验收测试的原因
- 内部测试只能模拟用户使用却不能代替用户使用
- 由于专业不同业务背景不同无法模拟用户使用的习惯
- 测试人员和用户对产品的理解可能不同
i、验收测试(在系统测试之后)
α测试：由用户组织一部分人在开发环境下来对产品进行测试，如 游的内测
β测试：所有系统使用者都可以参加的测试(在实际使用环境下)，如 游的公测
| 分类 | 测试过程 | 参与人员 | 目的 | 过程主要内容 |
|---|---|---|---|---|
| 针对项目类软件 | 验收测试 | 开发人员：提供满足验收要求的软件或系统，或用户需要的相关开发文档；测试人员需要完成：1.搭建验收测试环境2.准备验收测试用例3.准备用户需要的相关测试文档4.组织人员进行验收演示；用户代表需要完成：对系统进行一定的试用；客户代表：签字确认验收是否通过；行业：负责在验收过程中提出问题并协助用户和客户检查系统是否满足需求 | 1.检查软件的功能是否与用户最初需求相一致2.是客户回款的标志 | 1.进行验收前准备：A、准备相关的资料 B、搭建验收测试环境 C、指定相关的验收参与人 2、进行验收演示：A、对产品使用进行演示 B回答专家、用户的提问 3、签署验收 告 |
| 针对产品类软件 | α测试 | 开发人员：1.提供可以进行α测试的软件 2.负责修改用户代表发现的问题；测试人员：1.检查或协助用户填写缺陷 告 2.向用户学习相关的使用关注点 ；邀请的用户或客户代表(付费)：1.按照自己的操作习惯使用软件，提出易用性等方面的问题和改进建议 | 明确用户的使用体验，提高产品的使用范围和使用质量标准 | 1.明确进行α测试的版本；2.邀请潜在用户进行使用体验；3.针对用户提出的问题进行修复或改进 |
| 针对产品类软件 | β测试 | 潜在用户：1.安装软件并使用；客服人员：记录并反馈用户的问题 | 提前占领市场 | 1.发布一个下载地址；2.用户进行软件下载并使用 |
ii、回归测试
回归测试可以发生在任何一个阶段
分为完全回归和选择回归
| 回归范围 | 回归分类 | 特点 | 优点 | 缺点 | 适用范围 |
|---|---|---|---|---|---|
| 完全回归 | 完全重复法 | 每次回归测试都要执行全部测试用例 | 回归测试充分，覆盖面广，不容遗漏 | 工作量大，时间长，成本高 | 时间充裕且测试资源较充分时，第一次和最后一次做回归测试的时候用这种方法 |
| 选择回归测试 | 覆盖修改法 | 每次回归测试时只执行法相错误的用例 | 时间最短，成本最低，简单效率高 | 回归测试不充分，漏洞较多 | 时间较紧且人力资源不足时，中间版本的测试轮次可以使用，关联度比较小的模块或功能 |
| 选择回归测试 | 周边影响法 | 每次回归除了执行发现bug的用例外，还要执行与其相关的用例 | 在考虑了测试成本的基础上有效提高了回归的测试质量、效率 | 很难确定影响的周边范围，相关用例定位较困难 | 适合全局数据结构被修改或公共模块被修改，或核心算法业务被修改时，公用的模块，关系、关联复杂的模块 |
| 选择回归测试 | 指标达成法 | 每次回归测试达到规定的语气指标，就可以停止测试了 | 所有的测试都可度量 | 1.指标生成需要很长的周期、很多的项目区累积经验；2.要有比较稳定的团队这个指标才有意义 | 成熟度较高的测试团队应用于指标达成法(适用度很低，很少有公司使用) |
确定周边范围的方法：
| 分类 | 步骤 | 优点 |
|---|---|---|
| 界面检查法 | 1.明确被修改的功能；2.修改功能的上下游功能；3.调用修改功能的功能和修改功能调用了的功能；4.和修改功能游相同输入输出的功能；5.在测试中执行上诉相关的用例 | 简单 |
| 代码检查法 | 1.明确被修改的函数和代码；2.在整个系统中检查所有调用了修改函数的函数；3.明确上诉所有函数对应的界面；4.测试上诉界面测试用例 | 准确、全面 |
7、测试过程(干什么，怎么干)
| 整个系统的内容 | 需求项(业务、主要功能) | 需求项，需求子项，详细内容 | 测试计划、测试方案、测试用例 | 测试需求项、测试需求子项、具体如何进行测试 | 系统测试阶段 |
| 整个系统的集成 | 概要设计 | 概要设计项、概要设计子项、具体内容 | 测试计划、测试方案、测试用例 | 集成测试阶段 | |
| 整个系统最小单元 | 详细设计 | 函数、逻辑、代码 | 测试计划、测试方案、测试用例 | 单元测试 |
8、测试阶段过程要素
各阶段输入、输出标准以及入口、出口准则
1）系统测试
| 系统测试 | 入口准则 | 输入文档 | 输出文档 | 出口准则 |
|---|---|---|---|---|
| 系统测试计划 | 开发计划通过评审并入基线 ；需求规格说明书通过评审并入基线 | 开发计划书，需求规格说明书 | 系统测试计划书 | 系统测试计划书通过评审并入基线 |
| 系统测试设计 | 系统测试计划书通过评审并入基线 | 需求规格说明书，开发计划书，系统测试计划书 | 系统测试方案书 | 系统测试方案书通过评审并入基线 |
| 系统测试实现 | 系统测试方案书通过评审并入基线 | 需求规格说明书、系统测试计划书、系统测试方案书 | 系统测试用例，预测试项 | 系统测试用例、预测试项通过评审并入基线 |
| 系统测试执行 | 系统测试用例、预测试项通过评审并入基线，集成测试 告通过评审并入基线 | 需求规格说明书，系统测试计划书，系统测试方案书，系统测试用例，预测试项 | 缺陷 告，预测试项 告，系统测试 告 | 系统测试 告、预测试项 告、缺陷 告通过评审并入基线 |
2）集成测试
| 集成测试 | 入口准则 | 输入文档 | 输出文档 | 出口准则 |
|---|---|---|---|---|
| 集成测试计划 | 概要设计说明书通过评审并入基线 | 概要设计说明书 | 集成测试计划书 | 集成测试计划书通过评审并入基线 |
| 集成测试设计 | 集成测试计划书通过评审并入基线 | 概要设计说明书，集成测试计划书 | 集成测试方案书 | 集成测试方案书通过评审并入基线 |
| 集成测试实现 | 集成测试方案书通过评审并入基线 | 概要设计说明书，集成测试计划书、集成测试方案书 | 集成测试用例 | 集成测试用例通过评审并入基线 |
| 集成测试执行 | 集成测试用例通过评审并入基线，单元测试 告通过评审并入基线 | 概要设计说明书，集成测试计划书、集成测试方案书集成测试用例 | 集成测试 告，缺陷 告 | 集成测试 告、缺陷 告通过评审并入基线 |
3）单元测试
| 单元测试 | 入口准则 | 输入文档 | 输出文档 | 出口准则 |
|---|---|---|---|---|
| 单元测试计划 | 详细设计说明书通过评审并入基线 | 详细设计说明书 | 单元测试计划 | 单元测试计划通过评审并入基线 |
| 单元测试设计 | 单元测试计划通过评审并入基线 | 详细设计说明书，单元测试计划书 | 单元测试方案书 | 单元测试方案书通过评审并入基线 |
| 单元测试实现 | 单元测试方案书通过评审并入基线 | 详细设计说明书，单元测试计划书，单元测试方案书 | 单元测试用例 | 单元测试用例通过评审并入基线 |
| 单元测试执行 | 单元测试用例通过评审并入基线 | 详细设计说明书、单元测试计划书、单元测试方案书、单元测试用例 | 单元测试 告，缺陷 告 | 单元测试 告、缺陷 告通过评审并入基线 |
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！