51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 17701|回复: 16
打印 上一主题 下一主题

SQA测试过程

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2006-10-18 11:10:34 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
测试生命周期
  测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估
  测试计划就是定义一个测试项目的过程,以便能够正确的度量和控制测试。

第一部分:测试计划
测试计划的问题:
  1、测试计划经常是等到开发周期后期才开始实行,使得没有时间有效的执行计划;
  2、测试计划的组织者可能缺乏Client/Server测试经验;
  3、测试的量度和复杂性可能太大,没有自动化工具,很难计划和控制。

测试策略:
  测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试(单元测试、集成测试、系统测试)以及每个阶段内在进行的测试种类(功能测试、性能测试、压力测试等)。
  测试策略包括
  1、要使用的测试技术和工具;
  2、测试完成标准;
  3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。
  测试计划最关键的一步就是将软件分解成单元,写成测试需求。
  测试需求有很多分类方法,最普通的一种就是按照商业功能分类。把软件分解成单元元件有几个好处:
  1、测试需求是测试设计和开发测试用例的基础,分成单元可以更好地进行设计;
  2、详细的测试需求是用来衡量测试覆盖率的重要指标;
  3、测试需求包括各种测试实际和开发以及所需资源。

怎样估计测试工作量:
  1、效率假设:即测试队伍的工作效率。对于功能测试,这主要依赖于应用的复杂度,窗口的个数,每个窗口中的动作数目。对容量测试,主要依赖于建立测试所需数据的工作量大小。
  2、测试假设:为了验证一个测试需求所需测试动作数目。
  3、应用的维数:应用的复杂度指标。例如要加入一个记录,测试需求的维数就是这个记录中域的数目。
  4、所处测试周期的阶段:有些阶段主要工作都在设计,有些阶段主要是测试执行。

测试资源:

  1、人力资源
  测试经理
  为测试项目提供总体方向。开发测试计划、征集并监督测试人员、申请系统资源、监视并汇报工作进程、测试评估、测试需求的分解。
  测试工程师 ---- 设计和开发
  设计:对被测软件的详细了解、分解测试需求的技能、选择在C/S环境下用来验证测试需求的技术。
  开发:熟悉SQA、VB、和脚本语言。
  测试工程师 ---- 执行
  负责测试执行和记录结果。需要能够安装系统,网络知识,初始化数据库和其他初始条件。重要的是诊断能力。
  测试系统管理者
  每个测试项目必须指定一个专人负责管理SQA Suite。包括在服务器上安装存储库,安装打印机连接,执行备份,以及其他维护工作。管理者必须高度熟悉SQA,网络工作经验。

  2、系统资源
  安装SQA Suite的硬件和软件环境
  数据库服务器
  该服务器必须专用于 测试工作,能够重置某些初始值,包括系统日期和时间等。
写测试计划的步骤:

  1、确定工程
  收集下列信息
文档 已创建(是/否) 版本/日期 需求详述     功能详述     项目计划     设计详述     原型     用户手册      定义新的工程,Adminà New Project。
  确定软件的结构,用Assetsà Software Structure选项定义软件结构。

  2、定义测试策略
测试策略项 例子 测试阶段 系统测试 测试类型 功能测试 测试技术 75%用SQA Suite自动测试,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 设置测试系统
  执行测试
  验证测试结果
  调查突发结果(unexpected result)
  生成缺陷日记

  测试评估
1 回顾测试日记
  评估测试需求的覆盖率
  评估缺陷
  决定是否达到测试完成的标准

   7、书写测试计划
  1、介绍
    目的
    背景
    测试范围
    项目文件列表
  2、测试需求
  3、测试策略
    测试类型
    1、功能测试
    2、用户界面测试
    3、性能测试
    4、压力测试
    5、容量测试
    6、配置测试
    7、安装测试
    工具
  4、资源
    人力资源
    系统资源
  5、调度
  6、文档
    软件元件
    测试特性(Assets)
    测试日记
    缺陷报告

第二部分:测试设计

测试设计的问题
  1、不做测试设计,测试过程也是胡乱建立的。
  2、测试设计不详细,不是基于可量度的测试策略,例如测试计划覆盖一个集合或者测试需求的一个子集。
  3、测试过程没有采用最好的技术来检验Windows C/S结构的测试需求
测试用例的选择规则
  1、选择与测试需求的实质部分最相关的测试用例。
  2、选择的测试用例应该不容易应用程序的改变的影响。

  下面是选择测试用例的几点具体规则:
  1、商业函数
  商业函数一般与数据库有关,要测试数据库的变化,有几种方法:
  1、如果数据库的的改变会反映在一个列表框中,那么就要选择验证列表框内容的测试用例。
  2、还可以检查交易完成后的确认对话框。可以检查对话框的标题。图象比较也可以检查确认对话框,但图象比较容易受其他因素影响。
  3、修改脚本,SQA Basic提供了强大的数据库支持。
  2、域的验证
  各种不同的域选择相应的测试用例。
  3、用户界面测试
  对象状态测试用例
  4、性能标准
  等待状态测试用例
  5、压力下的操作
  6、访问控制
  Object state test case
  7、配置测试
  不能选择图象测试用例(也分辨率有关)和文件测试用例(与驱动器有关)
  8、安装选项和验证
  对象状态用例和窗口存在用例,文件存在用例。
书写测试设计的步骤
    生成测试需求报告
       ↓
     指定测试过程
       ↓
   指定测试用例(可选)
       ↓
    回顾测试覆盖率
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏1
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2006-10-18 11:11:04 | 只看该作者
第三部分:测试开发
输入:被测软件、基于测试需求的测试设计
输出:测试过程和测试用例
目标:
  1、创建可以重用的测试过程和测试用例
  2、维护测试过程、测试用例与相关测试需求的一一对应。
测试开发的问题:
  1、测试开发很乱,与测试需求或测试策略没有对应性
  2、测试过程不可重复或不可重用
  3、测试过程被作为一个编程任务来执行,导致脚本太长,不能满足软件移植性的要求。
错误处理
  当测试过程发生错误时,有几种解决办法:
  1、跳转到别的测试过程
  2、调用一个能够清除错误的过程
  3、退出过程,启动另一个
  4、退出过程和应用程序,重新启动启动Windows,在失败的地方重新开始测试
测试开发的步骤

  1、设立开发环境
    SQA Suite
    连接到SQA存储库
    启动SQA Baisc或VB
    被测软件
    等等
  2、录制和回放原型过程
  原型过程指出所有未知窗口控制,使得他们都能象标准窗口那样动作或者没有特别的动作,把他们都划归为Generic类型。通过这个过程,SQA Robot就知道该怎样处理应用中的特殊控制。
  1、把recording option 中的Define Unknown Object as Type Generic选项设置为off
  2、使用的过程标识符要可以被覆盖,或者能被删掉。因为这只是个原型,用来教SQA Robot 录制的过程
  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、不使用专门的软件工具进行数据输入任务和相应的评估活动,使得这些任务变得繁重累人。

测试覆盖率
  评估测试完成多少的标准

缺陷评估
  评估软件质量的重要指标,通常评估模型假设缺陷的发现是呈泊松分布的;严格的缺陷评估要考察在测试过程中发现缺陷的间隔时间长短。评估要估计软件当前的可靠性并预测随着测试的继续进行,软件可靠性会怎样提高。
  SQA Suite 提供四种形式进行缺陷评估:
  1、缺陷分布报告可以生成缺陷数量与缺陷属性的函数。如测试需求和状态。
  2、缺陷趋势报告可以看出缺陷增长和减少的趋势;
  3、缺陷年龄报告展示一个缺陷处于某种状态的时间长短
  4、测试结果进度报告展示测试过程在被测应用的几个版本中的执行结果以及测试周期。

具体步骤
  1、回顾测试日记
  [b2、评估测试需求的覆盖率
  3、分析缺陷
  4、决定是否达到完成测试的标准,没有满足标准时
    1、再测试
    2、降低标准
    3、确定软件的一个满足标准的子集,看是否可以发布。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2007-1-3 16:40:49 | 只看该作者
很详细!
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2007-2-1 13:48:56 | 只看该作者
sdlkfj8 强!
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2007-3-28 10:56:26 | 只看该作者

求助

针对项目的测试和上市产品的测试有什么差异吗?请指教
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2007-3-28 16:38:57 | 只看该作者
http://bbs.51testing.com/thread-30005-1-9.html看看这个帖子吧
就那么回事情
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2007-4-5 15:43:10 | 只看该作者

look

look
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2007-9-25 17:14:05 | 只看该作者
不实际!!
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2007-9-27 21:21:27 | 只看该作者

回复 2# 的帖子

流程很详细
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2007-9-27 21:41:40 | 只看该作者

评价

总体内容比较完整,但是缺少具体的时间说明
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2007-11-19 14:01:56 | 只看该作者
看的头晕
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2008-3-23 23:03:37 | 只看该作者
很详细,但是基本是罗列,可读性很差
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2008-4-19 22:54:36 | 只看该作者

顶一下,看不到

回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2008-8-22 08:43:18 | 只看该作者
不错,
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2008-10-26 22:13:26 | 只看该作者
很详细,不错,看看
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2018-11-29 18:32:00 | 只看该作者
请问游戏产品的QA工作怎么搞,谢谢!
回复 支持 反对

使用道具 举报

该用户从未签到

17#
发表于 2018-11-29 18:33:06 | 只看该作者
LZ好详细,但我看了之后发现在游戏产品中,基本上没法用到这些,请问游戏软件怎么开展QA工作呢?
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-18 20:18 , Processed in 0.074606 second(s), 26 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表