测试过程简单总结
一、测试模型
1. H模型:
优点:
1.介入早 与开发并行 更早的发现问题
2.测试过程独立于开发过程 更客观 更主动
2. V模型:
㈠需求阶段
产品经理,项目经理,产品工程师写《需求规格说明书》Software Reqwirment Specaficalion(SRS)
内容:需求项(业务,主要功能)需求子项,对子项的详细描述
测试的工作:对需求进行测试和评审A系统测试计划《系统测试计划书》B系统测试计划《系统测试方案书》C系统测试实现《系统测试用例》
㈡设计阶段
开发经理,架构师,开发工程师写出《概要设计说明书》High-level design(HLD)
内容:系统程序中的模块,子模块和他们之间的关系和接口
测试的工作:对HLD进行测试和评审A集成测试计划《集成测试计划书》B集成测试设计《集成测试方案书》C集成测试实现《集成测试用例》
㈢详细设计阶段
开发工程师,架构师,写出《详细设计说明书》Low-level desragn(LLD)
内容:函数 代码 逻辑
测试工作:对LLD进行测试和评审A单元测试计划《单元测试计划书》B单元测试设计《单元测试方案书》C《单元测试用例》
㈣编码阶段
开发工程师写代码
优点:介入早,提高测试质量; 分成三个阶段,发现问题更有针对性;测试与开发并行,更好的利用项目资源。
缺点:项目成本高;技术要求高,对人员要求高;并行工作中,一方未完成就会对整个造成延误。
适用范围:规模大、软件成熟度高的项目。
二、内部测试
测试阶段 | 测试对象 | 测试方法 | 测试目的 | 经济价值 | 优点 | 缺点 | 必要性 | 资源 |
系统测试 system testing(ST) |
整个系统 (整个产品) |
黑盒测试 | 验证产品是否符合需求规格说明书 | 能够保证产品以较高的的质量尽早的上市销售,从而使公司获取利润 | 1.简单 2.技术要求低 |
1.测试介入时间晚,修改成本高 2.有一些问题可能被遗留不会被修改 |
必须保证 | 1.对被测产品 2.需求规格说明书 3.系统测试工程师 4.需求开发人员 |
集成测试 integration testing(IT) |
模块 子模块 接口 |
灰盒测试 | 验证模块、子模块、接口是否符合 概要设计说明书 |
能够帮助更准确的 定位缺陷的所在,从而降低了定位缺陷的成本 | 定位准确快速 | 1.接口测试有技术要求,技术实现难度大 2.接口太多,数量庞大,做所有接口的集成测试成本高 |
不是必须做的, 必须做测试的 1.公共的主要模块 2.核心模块 3.和外界软件接口模块 |
1.被测的产品 2.概要设计说明书 3.集成测试工程师 4.概要设计人员 |
单元测试 unit testing(UT) |
函数 代码 逻辑 |
白盒测试 | 验证函数代码逻辑是否符合详细设计说明书 | 能够最早的开展测试工作,降低修复成本,防止缺钱被扩大化(注意:加以重视:1公共的模块2全局性的数据结构3重要的使用频率较高的功能4以往项目经常出错的严重问题5复杂度较高的模块6当开发人员业务不熟悉编码不熟练的模块要进行单元测试) | 介入时间早,发现问题早,修改成本低。 | 1.技术难度高 2.工作量太大 |
不是必须的 | 1.开发环境 2.LLD 3.单元测试工程师 4.架构师(详细设计人员) |
三、外部测试
使用验收测试的原因
1.内部测试只能模拟用户使用却不能代替用户使用
2.由于专业不同业务背景不同无法模拟用户使用的习惯
3.测试人员和用户对产品的理解可能不同
1. 验收测试:(在系统测试之后)
α测试:由用户组织一部分人在开发环境下来对产品进行测试 如网游的内侧
β测试:所有系统使用者都可以参加的测试(在实际使用环境下) 如网游的公测
分类 | 测试过程 | 参与人员 | 目的 | 过程主要内容 |
针对项目类软件 | 验收测试 | 开发人员:提供满足验收要求的软件或系统,或用户需要的相关开发文档 测试人员: 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、用户进行软件下载并使用 |
2. 回归测试
回归测试可以发生在任何一个阶段
分为完全回归和选择回归
回归范围 | 回归分类 | 特点 | 优点 | 缺点 | 适用范围 |
完全回归 | 完全重复法 | 每次回归测试都要执行全部测试用例 | 回归测试充分,覆盖面广,不容遗漏 | 工作量大,时间长,成本高 | 时间充裕且测试资源较充分时,第一次和最后一次做回归测试的时候用这种方法 |
选择性回归 | 覆盖修改法 | 每次回归测试时只执行发现错误的用例 | 时间最短,成本最低,简单效率高 | 回归测试不充分,漏洞较多 | 时间较紧且人力资源不足时,中间版本的测试轮次可以使用,关联度比较小的模块和功能 |
周边影响法 | 每次回归除了执行发现bug的用例外,还要执行与其相关的用例 | 在考虑了测试成本的基础上有效提高了回归测试的质量 效率 | 很难确定影响的周边范围,相关用例定位较困难 | 适合于全局数据结构被修改或公共模块被修改,或核心算法业务被修改时,公用的模块,关系、关联复杂的模块 | |
指标达成法 | 每次回归测试达到规定的语气指标 就可以停止测试了 |
所有的测试都可度量 | 1.指标生成需要很长的周期, 很多的项目区累计经验 2.要有比较稳定的团队这个指标才有意义 |
成熟度较高的测试团队应用于指标达成法 (适用度很低,很少有公司使用) |
分类 | 步骤 | 优点 | |
确定周边 范围的方法 |
界面检查法 | 1.明确被修改的功能 | 简单 |
2.修改功能的上下游功能 | |||
3.调用修改功能的功能和 修改功能调用了的功能 | |||
4.和修改功能游相同输入输出的功能 | |||
5.在测试中执行上诉关联的用例 | |||
代码检查法 | 1.明确被修改的函数和代码 | 准确,全面 | |
2.在整个系统中检查所有 调用了修改函数的函数 | |||
3.明确上诉所有函数对应的界面 | |||
4.测试上诉界面测试用例 |
四、测试过程(干什么,怎么干)
整个系统的内容 | 需求项(业务、主要功能) | 需求项 | 测试计划 | 测试需求项 | 系统测试阶段 |
需求子项 | 测试方案 | 测试需求子项 | |||
详细内容 | 测试用例 | 具体如何进行测试 | |||
整个系统的集成 | 概要设计 | 概要设计项 | 测试计划 | 集成测试阶段 | |
概要设计子项 | 测试方案 | ||||
具体内容 | 测试用例 | ||||
整个系统最小单元 | 详细设计 | 函数 | 测试计划 | 单元测试 | |
逻辑 | 测试方案 | ||||
代码 | 测试用例 |
五、各阶段输入、输出标准以及入口、出口准则:(测试阶段过程要素)
系统测试 |
入口准则 |
输入文档 |
输出文档 |
出口准则 |
系统测试计划 |
开发计划通过评审并入基线 需求规格说明书通过评审并入基线 |
开发计划书 需求规格说明书 |
系统测试计划书 |
系统测试计划书通过评审并入基线 |
系统测试设计 |
系统测试计划书通过评审并入基线 |
需求规格说明书 开发计划书 系统测试计划书 |
系统测试方案书 |
系统测试方案书通过评审并入基线 |
系统测试实现 |
系统测试方案书通过评审并入基线 |
需求规格说明书 系统测试计划书 系统测试方案书 |
系统测试用例 预测试项 |
系统测试用例、预测试项通过评审并入基线 |
系统测试执行 |
系统测试用例、预测试项通过评审并入基线 集成测试报告通过评审并入基线 |
需求规格说明书 系统测试计划书 系统测试方案书 系统测试用例 预测试项 |
缺陷报告 预测试项报告 系统测试报告 |
系统测试报告、预测试项报告、缺陷报告通过评审并入基线 |
集成测试 |
入口准则 |
输入文档 |
输出文档 |
出口准则 |
集成测试计划 |
概要设计说明书通过评审并入基线 |
概要设计说明书 |
集成测试计划书 |
集成测试计划书通过评审并入基线 |
集成测试设计 |
集成测试计划书通过评审并入基线 |
集成测试计划书 概要设计说明书 |
集成测试方案书 |
集成测试方案书通过评审并入基线 |
集成测试实现 |
集成测试方案书通过评审并入基线 |
集成测试计划书 集成测试方案书 概要设计说明书 |
集成测试用例 |
集成测试用例通过评审并入基线 |
集成测试执行 |
集成测试用例通过评审并入基线 单元测试报告通过评审并入基线 |
集成测试计划书 集成测试方案书 集成测试用例 概要设计说明书 |
集成测试报告 缺陷报告 |
集成测试报告、缺陷报告通过评审并入基线 |
单元测试 |
入口准则 |
输入文档 |
输出文档 |
出口准则 |
单元测试计划 |
详细设计说明书通过评审并入基线 |
详细设计说明书 |
单元测试计划 |
单元测试计划通过评审并入基线 |
单元测试设计 |
单元测试计划通过评审并入基线 |
详细设计说明书 单元测试计划书 |
单元测试方案书 |
单元测试方案书通过评审并入基线 |
单元测试实现 |
单元测试方案书通过评审并入基线 |
详细设计说明书 单元测试计划书 单元测试方案书 |
单元测试用例 |
单元测试用例通过评审并入基线 |
单元测试执行 |
单元测试用例通过评审并入基线 |
详细设计说明书 单元测试计划书 单元测试方案书 单元测试用例 |
单元测试报告 缺陷报告 |
单元测试报告、缺陷报告通过评审并入基线 |