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