掌握测试过程中的测试级别
掌握回归测试的概念与策略
掌握测试过程模型
了解测试过程规范
测试阶段划分
单元测试(UnitTesting)
集成测试(Integration Testing)
系统测试(System Testing)
测试过程模型
测试过程规范
02-测试过程单元集成系统及比较
单元测试
单元测试是针对软件基本组成单元(软件设计的最小单位)来进行正确性检验的测试工作
单元测试的目的是检测软件模块对《详细设计说明书》的符合程度 函数
详细设计说明书:详细设计说明书又可称程序设计说明书。编制目的说明一个软件各个层次中的每一个程序
(每个模块或子程序)的设计考虑,如果一个软件系统比较简单,层次很少,本文件可以不单独编写,有关
内容合并入概要设计说明书。
集成测试
集成测试是在单元测试的基础上,将所有模块按照概要设计要求组装成为子系统或系统,验证组装后
功能以及模块间接口是否正确的测试工作
集成测试的目的是检测软件模块对《概要设计说明书》的符合程度 测接口
系统测试
系统测试是将已经集成好的软件系统,作为整个基于计算机系统的一个元素,与计算机硬件、外设
、某些支持软件、数据和人员等其他系统元素结合在一起,在实际运行(使用)环境下,对计算机系统
进行一系列的测试工作
系统测试的目的在于通过与《需求规格说明书》作比较,发现软件与系统需求定义不符合或与之矛盾的地方
软件需求说明书
SRS(Software Requirements Specification),软件需求说明书的编制是为了使用户和软件开发者双方对该软件的
初始规定的一个共同的理解,使之成为整个开发工作的基础。包含硬件、功能、性能、输入输出、接口界面、警示信息
、保密安全、数据与数据库、文档和法规的要求。
单元、集成、系统测试的比较
测试方法不同
单元测试属于白盒测试范畴
集成测试属于灰盒测试范畴
系统测试属于黑盒测试范畴
考察范围不同
单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等
集成测试主要测试模块之间的接口和接口数据传递关系,以及模块
组合后的整体功能
系统测试主要测试整个系统相对于需求的符合度
评估基准不同
单元测试的评估基准主要是逻辑覆盖率
集成测试的评估基准主要是接口覆盖率
系统测试的评估基准主要是测试用例对需求规格的覆盖率
03-测试过程回归测试流程1
软件配置 回归测试
测试配置 测试 测试结果 结果分析 错误 改正错误 改正的软件
测试工具 预期结果 可靠性分析 预测的可靠性
测试过程信息流
回归测试(2) 软件在测试或其他活动中发现的缺陷经过修改后,应该进行回归测试(Regression Testing)。 目的是验证缺陷得到了正确的修复,
同时对系统的变更没有影响以前的功能
回归测试可以发生在任何一个阶段,包括单元测试、集成测试和系统测试
回归测试流程
以下流程适合于单元测试、集成测试和系统测试
1、在测试策略制定阶段,制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过,关闭缺陷跟踪单(问题单)
5、回归测试不通过,缺陷跟踪单返回开发人员,开发人员重新修改问题,再次提交测试人员回归测试。
04-测试过程回归测试策略
回归测试流程
以下流程适合于单元测试、集成测试和系统测试
1、在测试策略制定阶段,制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过,关闭缺陷跟踪单(问题单)
5、回归测试不通过,缺陷跟踪单返回开发人员,开发人员重新修改问题,再次提交测试人员回归测试
回归测试策略
完全重复测试:
重新执行所有在前期测试阶段建立的测试用例,来确认问题修改的正确性和修改的扩散局部影响性
选择性重复测试:
即有选择地重新执行部分在前期测试阶段建立的测试用例,来测试被修改的程序
回归测试策略
选择性重复测试
覆盖修改法
即针对被修改的部分,选取或重新构造测试用例验证没有错误再次发生的用例选择方法。
周边影响法:
该方法不但要包含覆盖修改法确定的用例,还需要分析修改的扩散影响,对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响
该方法比覆盖修改法更充分一点。
指标达成方法
这是一种类似于单元测试的方法,在重新执行测试前,先确定一个要达成的指标,如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖率等
基本于这种要求选择一个最小的测试用例集合。
回归测试自动化(1)
1.回归测试是一个重用以前成功的测试,很难预料到要经过多少次回归系统才能达到满意的水平,结果,这种
回归测试将可能演变成一种重复的、令人心烦意乱的工作,效果与任媛媛的积极性将大打折扣,因此,在回归测试道路上的自动化便是我们工作的追求
2.回归测试的自动化包括测试程序的自动运行、自动配置,测试用例的管理和自动输入,测试的自动执行,测试信息与结果的自动采集,测试结果的自动比较
和结论的自动输出,尤其前面提到的各类数据的共享决策
3.对系统测试功能比较简单、测试界面相对稳定并且用例良好组织的测试来说,采用“捕捉回放”工具是比较合适的,这类工具有QTP、Robot、SilkTest等
4.为了实现测试用例的自动化并实现测试结果的自动判断,脚本化的、包含控制结构、内部实现结果判断的测试用例是唯一的选择,此类脚本语言有TCL、Python、Perl等
5.对于特定系统的、复杂的测试来讲,如果没有通用的商用工具可供选择,探索开发专门的自动化测试工具是灵活且易于扩充的方法
6.回归测试的自动化(或者说工具化)的问题是一个需要尽早考虑的问题,在做测试方案时就要考虑这种可能性,必要时要投入资源进行开发,
能形成可供继承与推广的工具则是最终目的
-----------------------------------------------------------------------------
05-测试过程验收测试alpha和beta测试
其他测试阶段
单元测试、继承测试、系统测试是软件开发过程中在软件组织内部进行的测试阶段
软件正式发布前还可能进行有 用户参与 的其他一些测试,如:
验收测试
在通过了内部系统测试及软件配置审查之后,就可以开始验收测试
验收测试是以用户为主的测试,验收组应该由项目组成员、用户代表等组成
验收测试原则上在用户所在地进行,但如经用户同意也可以在公司内模拟用户环境进行
验收测试根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试
验收测试的结果有两种情况:
软件功能、性能等质量特性与用户的要求一致,软件可以接受
软件功能、性能等质量特性与用户的要求有差距,不被用户接受
α(ALPHA)测试
α测试
α测试由用户在开发环境下进行的测试,也可以是开发机构内部的用户在模拟实际操作环境下进行的测试
α测试时,软件在一个自然设置状态下使用。软件开发者坐在用户旁.随时记下错误情况和使用中的问题。这是
在受控制的环境下进行的测试
α测试的目的主要是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和技术支持)
β(BETA)测试
β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试
与α测试不同的是,β测试时开发者通常不在测试现场。因此,β测试是在开发者无法控制的环境下进行的软件现场应用
06-测试过程阶段划分
测试阶段划分
测试计划阶段-测试计划
测试计划：指明测试范围、方法、资源,以及相应测试活动的时间进度安排表的文档。
测试方案：指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。
测试用例：指明为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档。
测试规程：指明执行测试是测试活动序列的文档。
测试报告:指明执行测试结果的文档。
测试日报:每天测试执行情况的记录和总结。
测试设计阶段-测试方案
测试实现阶段-测试用例、测试规程
测试执行阶段-测试报告
测试过程模型
测试过程规范
07-测试过程模型瀑布V
常见的测试过程模型
瀑布模型
H模型
V&V模型
08-测试过程模型W
V---W 开发一个V 测试一个V
测试V&V模型(2)
V&V模型实现了测试设计和测试执行相分离
V&V模型揭示了软件测试活动分层和分阶段的本质特性,的顺序与开发活动相反
09-测试过程模型H
测试准备 测试就绪点 测试执行 测试流程
其他流程(如设计流程)
测试分两类活动：
测试准备活动,包括测试需求分析、测试计划、测试设计、测试编码、测试验证
另一类是测试执行活动,包括测试运行、测试报告、测试结果分析等
单元测试完成才能做集成测试
软件测试不仅仅指测试执行,还包括很多其他的活动。
测试是一个独立的流程,贯穿产品整个周期,与其他流程并发地进行。
测试要尽早准备,尽早执行。
各个不同阶段的测试除了简单的时间上的先后关系外,还存在触发、反复、迭代和量增关系。
010-测试过程模型验证和确认
验证与确认V&V
验证(Verificaition)
验证是保证软件正确地特定功能的一系列活动
验证是检测每一阶段形成的工作产品是否与前一阶段定义的规格相一致
“Are we building the product right?”
确认(Validation)
确认是指保证所产生的软件可追溯到用户需求的一系列活动
确认是检测每一阶段的工厂产品是否与最初定义的软件需求规格相一致
"Are we building the right product?"
011-测试过程规范过程要素
测试过程规范
CMM关于过程的要素
计划 设计 实现 执行
管理 主管 软件工程师 初级测试工程师
角色(Roles)
入口准则(EntryCriteria)
输入(Inputs)
活动(Activities)
输出(Outputs)
出口准则(ExitCtiteria)
评审和审计(Reviews and Audits)
可管理和受控的工作产品(WorkProducts Managed and Controlled)
测量(Measurements)
书面规程(DocumentedProcedures)
培训(Training)
工具(Tools)
012-测试过程规范系统测试输入输出
系统测试过程与开发阶段
需求分析解读那 概要设计 详细设计 编码 单元测试执行 集成测试执行 系统测试执行
系统测试计划
系统测试设计
系统测试实现
------------------------------------------
系统测试各阶段的输入、输出
软件开发计划
软件测试计划 需求规格说明书
需求规格说明书 系统测试计划
系统测试计划阶段 系统测试设计阶段
系统测试计划 系统测试方案
需求规格说明书 系统测试计划
系统测试计划 系统测试方案
系统测试方案 系统测试用例
系统测试实现阶段 系统测试预测试项
系统测试用例 系统测试规程
系统测试规程 系统测试执行阶段
系统测试预测试项 系统预测试报告、
系统测试报告
缺陷报告
013-测试过程规范需求分析阶段工作任务和角色及职责
需求分析阶段的主要任务(需求分析是重要和困难的工作
1.交流-业务、环境
2.不断的变化
3.复杂 需求1小时小时 设计2.5小时 编码5小时 测试25小时 维护时间更长
)
需求分析,完成SRS
软件需求规格说明书的评审
进行需求跟踪
系统测试计划
系统测试计划的评审
----------------------------------------------------------
需求阶段的角色和职责
软件开发项目经理
A、带领项目组分析审核工作任务书;
B、带领项目组与系统工程师进行需求交流并进行分析和文档化;
C、组织SRS文档评审;
D、组织需求跟踪;
软件开发工程师
A、完成SRS文档;
B、完成需求跟踪;
C、参加SRS review
D、根据SRS评审专家意见,修改SRS文档;
E、参加系统测试计划的评审;
软件经理
A、在SRS评审结束后,批准SRS文档;
QA(质量保证)
A、监督项目组遵循需求管理流程;
B、参加相关文档review
C、保证相关组参加文档review
CCB的负责人(CCB 变更控制委员会)
A、控制需求的变更;
软件测试项目经理
A、参与开发人员的软件需求分析,提出可测试性需求;
B、组织人员参与SRS的评审工作;
C、软件系统测试计划写作;
D、组织系统测试计划的评审;
E、组织本阶段测试需求跟踪;
软件测试工程师
A、参与SRS评审工作;
B、协助软件测试项目经理完成软件系统测试计划写作;
C、参加系统测试计划的评审;
D、完成本阶段测试需求跟踪;
014-测试过程规范执行阶段角色及职责
UT/IT/ST执行阶段的角色和职责(1)
开发组项目经理
A、确保缺陷分给相关软件工程师并监督及时得到解决;
B、提出转系统测试申请;
软件开发人员
A、修正缺陷;
B、验证相关的缺陷已经被修正;
C、参加各阶段测试报告的评审;
UT/IT/ST执行阶段的角色和职责(2)
QA
A、监督项目遵循测试执行流程;
B、参加测试报告和转系统测试评审;
C、保证相关组参加测试报告和转系统测试评审;
CCB的负责人
A、对缺陷的修改进行裁决; 变更 跟踪
UT/IT/ST执行阶段的角色和职责(3)
软件测试项目经理
A、组织所有的测试执行活动,安排并监督测试执行任务;
B、确保选择合适的测试工具以及测试环境的建立;
C、确保缺陷分发给相关软件工程师并及时得到解决;
D、组织测试报告和系统测试预测试报告的写作;
E、组织测试报告的评审;
F、组织转系统测试评审;
软件测试工程师
A、搭建测试环境;
B、执行测试用例;
C、发现缺陷后提交缺陷报告;
D、回归测试;
E、每天提交测试日报;
F、测试报告及系统测试预测试报告写作;
G、参加测试报告的评审
H、参加赚系统测试评审;
