测试生命周期.docx
- 文档编号:3947630
- 上传时间:2022-11-26
- 格式:DOCX
- 页数:9
- 大小:21.32KB
测试生命周期.docx
《测试生命周期.docx》由会员分享,可在线阅读,更多相关《测试生命周期.docx(9页珍藏版)》请在冰豆网上搜索。
测试生命周期
测试生命周期-SQA测试过程
测试生命周期
测试计划→测试设计→测试开发→测试执行→测试评估
测试计划就是定义一个测试项目的过程,以便能够正确的度量和控制测试。
第一部分:
测试计划
测试计划的问题:
1、测试计划经常是等到开发周期后期才开始实行,使得没有时间有效的执行计划;
2、测试计划的组织者可能缺乏Client/Server测试经验;
3、测试的量度和复杂性可能太大,没有自动化工具,很难计划和控制。
测试策略:
测试策略描述测试工程的总体方法和目标。
描述目前在进行哪一阶段的测试(单元测试、集成测试、系统测试)以及每个阶段内在进行的测试种类(功能测试、性能测试、压力测试等)。
测试策略包括
1、要使用的测试技术和工具;
2、测试完成标准;
3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。
测试计划最关键的一步就是将软件分解成单元,写成测试需求。
测试需求有很多分类方法,最普通的一种就是按照商业功能分类。
把软件分解成单元元件有几个好处:
1、测试需求是测试设计和开发测试用例的基础,分成单元可以更好地进行设计;
2、详细的测试需求是用来衡量测试覆盖率的重要指标;
3、测试需求包括各种测试实际和开发以及所需资源。
怎样估计测试工作量:
1、效率假设:
即测试队伍的工作效率。
对于功能测试,这主要依赖于应用的复杂度,窗口的个数,每个窗口中的动作数目。
对容量测试,主要依赖于建立测试所需数据的工作量大小。
2、测试假设:
为了验证一个测试需求所需测试动作数目。
3、应用的维数:
应用的复杂度指标。
例如要加入一个记录,测试需求的维数就是这个记录中域的数目。
4、所处测试周期的阶段:
有些阶段主要工作都在设计,有些阶段主要是测试执行。
测试资源:
1、人力资源
测试经理
为测试项目提供总体方向。
开发测试计划、征集并监督测试人员、申请系统资源、监视并汇报工作进程、测试评估、测试需求的分解。
测试工程师----设计和开发
设计:
对被测软件的详细了解、分解测试需求的技能、选择在C/S环境下用来验证测试需求的技术。
开发:
熟悉SQA、VB、和脚本语言。
测试工程师----执行
负责测试执行和记录结果。
需要能够安装系统,网络知识,初始化数据库和其他初始条件。
重要的是诊断能力。
测试系统管理者
每个测试项目必须指定一个专人负责管理SQASuite。
包括在服务器上安装存储库,安装打印机连接,执行备份,以及其他维护工作。
管理者必须高度熟悉SQA,网络工作经验。
2、系统资源
安装SQASuite的硬件和软件环境
数据库服务器
该服务器必须专用于测试工作,能够重置某些初始值,包括系统日期和时间等。
写测试计划的步骤:
1、确定工程
收集下列信息
文档已创建(是/否)版本/日期需求详述 功能详述 项目计划 设计详述 原型 用户手册 定义新的工程,AdminàNewProject。
确定软件的结构,用AssetsàSoftwareStructure选项定义软件结构。
2、定义测试策略
测试策略项例子测试阶段系统测试测试类型功能测试测试技术75%用SQASuite自动测试,25%手工测试完成标准95%测试用例通过并且最高级缺陷全部解决特殊考虑测试必须在上午进行 3、分解软件,写测试需求
分析各种信息
反复检查并理解各种信息,和用户交流,理解他们的要求。
可以按照以下步骤执行:
1、确定软件提供的主要商业任务
2、对每个商业任务,确定完成该任务所要进行的交易。
3、确定从数据库信息引出的计算结果。
4、对于对时间有要求的交易,确定所要的时间和条件。
这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况。
5、确定会产生重大意外的压力测试,包括:
内存、硬盘空间、高的交易率
6、确定应用需要处理的数据量。
7、确定需要的软件和硬件配置。
通常情况下,不可能对所有可能的配置都测试到,因此要选择最有可能产生问题的情况进行测试,包括:
最低性能的硬件、几个有兼容性问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器。
8、确定其他与应用软件没有直接关系的商业交易。
包括:
管理功能,如启动和推出程序
配置功能,如设置打印机
操作员的爱好,如字体、颜色
应用功能,如访问email或者显示时间和日期。
9、确定安装过程,包括定置从哪安装、定制安装、升级安装。
10、确定没有隐含在功能测试中的户界面要求。
大多界面都在功能测试时被测试到。
还有写没有测到,如:
操作与显示的一致性,如使用快捷键等;界面遵从合理标准,如按钮大小,标签等。
把需求组织成层次图
4、估计测试工作量
∑(每个测试的时间*每个需求的测试的数目*测试需求的的数目)
(测试设计、开发、….)
5、确定资源
人力资源
职位姓名特殊责任/说明测试经理 测试工程师
设计/开发(可以多人) 测试工程师
测试执行(可以多人) 测试系统管理员 系统资源
系统名称/类型数据库服务器网络/子网
服务器名称
数据库名称
SQA测试存储库网络/子网
服务器名称
客户测试机包括专门的配置需求
列表 测试开发的PC机列表 6、创建工程调度表
任务相关工作量(天)整个SQA过程38测试计划12确定项目1定义测试策略 决定测试需求 估计工作量 确定资源 调度测试活动 生成测试计划文档 测试设计7分析测试需求 指定测试过程 指定测试用例 查看测试需求的覆盖率 测试开发12建立测试开发环境 录制和回放原型过程 开发测试过程 测试和调试测试过程 修改测试过程 建立外部数据集合 重新测试并调试测试过程 测试执行6设置测试系统 执行测试 验证测试结果 调查突发结果(unexpectedresult) 生成缺陷日记 测试评估1回顾测试日记 评估测试需求的覆盖率 评估缺陷 决定是否达到测试完成的标准 7、书写测试计划
1、介绍
目的
背景
测试范围
项目文件列表
2、测试需求
3、测试策略
测试类型
1、功能测试
2、用户界面测试
3、性能测试
4、压力测试
5、容量测试
6、配置测试
7、安装测试
工具
4、资源
人力资源
系统资源
5、调度
6、文档
软件元件
测试特性(Assets)
测试日记
缺陷报告
第二部分:
测试设计
测试设计的问题
1、不做测试设计,测试过程也是胡乱建立的。
2、测试设计不详细,不是基于可量度的测试策略,例如测试计划覆盖一个集合或者测试需求的一个子集。
3、测试过程没有采用最好的技术来检验WindowsC/S结构的测试需求
测试用例的选择规则
1、选择与测试需求的实质部分最相关的测试用例。
2、选择的测试用例应该不容易应用程序的改变的影响。
下面是选择测试用例的几点具体规则:
1、商业函数
商业函数一般与数据库有关,要测试数据库的变化,有几种方法:
1、如果数据库的的改变会反映在一个列表框中,那么就要选择验证列表框内容的测试用例。
2、还可以检查交易完成后的确认对话框。
可以检查对话框的标题。
图象比较也可以检查确认对话框,但图象比较容易受其他因素影响。
3、修改脚本,SQABasic提供了强大的数据库支持。
2、域的验证
各种不同的域选择相应的测试用例。
3、用户界面测试
对象状态测试用例
4、性能标准
等待状态测试用例
5、压力下的操作
6、访问控制
Objectstatetestcase
7、配置测试
不能选择图象测试用例(也分辨率有关)和文件测试用例(与驱动器有关)
8、安装选项和验证
对象状态用例和窗口存在用例,文件存在用例。
书写测试设计的步骤
生成测试需求报告
↓
指定测试过程
↓
指定测试用例(可选)
↓
回顾测试覆盖率
第三部分:
测试开发
输入:
被测软件、基于测试需求的测试设计
输出:
测试过程和测试用例
目标:
1、创建可以重用的测试过程和测试用例
2、维护测试过程、测试用例与相关测试需求的一一对应。
测试开发的问题:
1、测试开发很乱,与测试需求或测试策略没有对应性
2、测试过程不可重复或不可重用
3、测试过程被作为一个编程任务来执行,导致脚本太长,不能满足软件移植性的要求。
错误处理
当测试过程发生错误时,有几种解决办法:
1、跳转到别的测试过程
2、调用一个能够清除错误的过程
3、退出过程,启动另一个
4、退出过程和应用程序,重新启动启动Windows,在失败的地方重新开始测试
测试开发的步骤
1、设立开发环境
SQASuite
连接到SQA存储库
启动SQABaisc或VB
被测软件
等等
2、录制和回放原型过程
原型过程指出所有未知窗口控制,使得他们都能象标准窗口那样动作或者没有特别的动作,把他们都划归为Generic类型。
通过这个过程,SQARobot就知道该怎样处理应用中的特殊控制。
1、把recordingoption中的DefineUnknownObjectasTypeGeneric选项设置为off
2、使用的过程标识符要可以被覆盖,或者能被删掉。
因为这只是个原型,用来教SQARobot录制的过程
3、录制测试过程和测试用例
1、录制模块测试过程和与测试需求最低层对应的测试用例;
2、录制初始化过程;
3、录制导航过程,把前面的过程串起来;
4、测试和调试测试过程
5、修改测试过程(可选)
6、建立外部数据集合
如果测试过程是用来循环一套输入和输出数据,就需要建立数据集合。
7、重复测试和调试测试过程,回到4
第四部分:
测试执行
测试执行的问题
1、自动化测试没有有效的利用,使得手工测试太多。
2、测试结果的捕获没有系统性,而且没有查看或调查
3、缺陷报告必须用手工加入缺陷跟踪系统
错误分类
1、测试用例失败
正常错误
2、脚本命令失败
当测试过程不能不能执行录制过程中的某个功能时,回产生这种错误,如鼠标单击按钮或选择菜单项等。
它也能指示是缺陷还是测试过程的设计问题。
3、致命错误
导致测试停止,这种情况最好重起Windows。
具体步骤:
1、建立测试系统
2、准备测试过程
3、运行初始化过程
4、执行测试
5、从终止的测试恢复
6、验证预期结果
7、调查突发结果
8、记录缺陷日记
第五部分:
测试评估
测试评估的目标
1、量化测试进程
2、生成缺陷和测试覆盖率的总结报告
测试评估的问题
1、没有把测试覆盖率作为报告测试进程的根据,使得不知测试是否结束;
2、没有做缺陷评估,缺陷评估是量度软件可行性的重要指标;
3、不使用专门的软件工具进行数据输入任务和相应的评估活动,使得这些任务变得繁重累人。
测试覆盖率
评估测试完成多少的标准
缺陷评估
评估软件质量的重要指标,通常评估模型假设缺陷的发现是呈泊松分布的;严格的缺陷评估要考察在测试过程中发现缺陷的间隔时间长短。
评估要估计软件当前的可靠性并预测随着测试的继续进行,软件可靠性会怎样提高。
SQASuite提供四种形式进行缺陷评估:
1、缺陷分布报告可以生成缺陷数量与缺陷属性的函数。
如测试需求和状态。
2、缺陷趋势报告可以看出缺陷增长和减少的趋势;
3、缺陷年龄报告展示一个缺陷处于某种状态的时间长短
4、测试结果进度报告展示测试过程在被测应用的几个版本中的执行结果以及测试周期。
具体步骤
1、回顾测试日记
2、评估测试需求的覆盖率
3、分析缺陷
4、决定是否达到完成测试的标准,没有满足标准时
1、再测试
2、降低标准
3、确定软件的一个满足标准的子集,看是否可以发布。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 生命周期
![提示](https://static.bdocx.com/images/bang_tan.gif)