koorio.com
海量文库 文档专家
赞助商链接
当前位置:首页 >> 计算机软件及应用 >>

软件测试基础理论知识


[键入文字]

测试理论培训资料

[键入文字]

控 制 流 分 析

数 据 流 分 析

信 息 流 分 析

逻 辑 覆 盖

程 序 插 装

白 黑 盒 盒

等 边 输 输 因 判 正 流 价 界 入 出 果 定 交 程 类 值 域 域 图 法 试 分 覆 覆 验 析 盖 盖 法

状 态 迁 移

异 常 分 析

错 误 猜 测

静 态 分 析

动 态 分 析

内 部 实 现

整 体 特 性

输 入 输 出

条 件 组 合

处 理 过 程

其 他

SRS

HLD

LLD

GUI

DB

编码

调试

白盒

灰盒

黑盒

分析

设计

编码

UT

IT

ST

开发技术

技术

测试技术

流程

软件质量

组织

质量体系

螺 旋 模 模 模 模 型 型 型 型

瀑 布 模 型

ISO9001

CMM

6 西格玛

织 常 结 见 构 的 项 目 组

RUP IPD V&V

需求管理 配置管理 同行评审 缺陷管理

[键入文字]

[键入文字]

需求分析 SRS 评审 SRS 基线化

系统测试的计划 设计和实现 ST 计划 ST 方案 ST 用例 ST 执行

概要设计 HLD 评审 HLD 基线化

集成测试的计划 设计和实现 IT 计划 IT 方案 IT 用例 IT 执行

详细设计 LLD 评审 LLD 基线化

单元测试的计划 设计和实现 UT 计划 UT 方案 UT 用例 UT 执行

编码

代码走查

[键入文字]

需求分析 SRS 评审 SRS 基线化

系统测试的计划 设计和实现 ST 计划 ST 方案 ST 用例 ST 执行

概要设计 HLD 评审 HLD 基线化

集成测试的计划 设计和实现 IT 计划 IT 方案 IT 用例 IT 执行

详细设计 LLD 评审 LLD 基线化

单元测试的计划 设计和实现 UT 计划 UT 方案 UT 用例 UT 执行

编码

代码走查

[键入文字]

测 试 基 础 软 件 质 量 测 试 方 法 V&V 模型(测试过程) 单 元 测 试 集 成 测 试 系 统 测 试 测 试 覆 盖 率 测 试 用 例 举 例 同 行 评 审 配 置 & 需 求 管 理 缺 陷 管 理 SQL SERVER 测试工具总结 第一阶段英语单词总结 复习问题总结

7 10 17 20 22 28 36 47 49 51 54 56 59 65 81 85

[键入文字]

测 试 基 础
1、 软件测试的目的:证明(表达软件能够工作)→ 检测(发现错误)→ 预防(管 理质量) 2、 测试执行:单元测试(UT 执行) :一个测试用例的测试执行; 集成测试(IT 执行) :一个测试用例集的测试执行; 系统测试(ST 执行) :不同测试阶段的测试执行。这几句话是什么意思, 觉得不是很有针对性? 3、 回归测试的目的:a. 验证错误是否修复; b. 检测对代码的修改是否引入了新的错误。 5、 软件测试的主要工作:a. 检视代码,评审开发文档; b. 进行测试设计,写作测试文档(测试计划、测试方案、测 试用例等) ; c. 执行测试,发现软件缺陷,提交缺陷报告,并确认缺陷最 终得到了修正; d. 通过测试度量软件质量。 6、 软件危机的出现主要表现在:a. 由于缺乏大型软件开发经验和软件开发数据积累, 开发工作计划很难制定; b. 开发早期需求分析不够明确, 造成开发后期矛盾集 中暴露; c. 不遵循开发规范, 开发文档不完整, 软件难以维护; d. 缺乏严密有效的软件质量检测手段, 交付给用户的

[键入文字]

软件质量差。 7、 软件危机的后果:a. 软件质量不高,很难稳定; b. 软件项目延期,进度无法控制; c. 成本增加,无法控制预算。 8、 软件危机的根源:a. 根据摩尔定律,硬件发展很快,相应对软件系统的期望 越来越高; b. 软件系统复杂性提高,需多人合作; c. 软件开发是人的智力活动, 无法用已有的产业工程方法来组织 管理。 9、 软件生命周期的各个阶段:计划→ 需求分析→ 设计→ 编码→ 测试→ 运行→ 评 价 10、 设计:概要设计(HLD) :在设计阶段把各项需求转换成相应的体系结构,每一部分 是功能明确的模块; 详细设计(LLD) :对每个模块要完成的工作进行具体的描述。 11、 软件研发相关要素:人员、过程、工具。 12、 软件项目组人员组成:分析人员、设计人员、开发人员、测试人员、配置管理人员、 SQA(质量保证人员) ; 13、 软件研发流程类型:瀑布模型、螺旋模型、RVPRUP 流程、IPD 流程。 14、 软件研发中几个重要的过程:需求管理;配置管理;缺陷管理;同行评审。 15、 常见的引入缺陷的原因:a. 开发过程缺乏有效的沟通,或者没有进行沟通; b. 软件复杂度越来越高;

[键入文字]

c. 编程中产生错误; d. 需求不断变更; e. 项目进度的压力; f. 不重视开发文档; g. 软件开发工具本身隐藏的问题。等等??

[键入文字]

软 件 质 量
软件质量管理体系:

软件质量管理体系:

ISO9000(2000 版)

CMM

六西格玛

ISO 9000

ISO 9001

ISO 9004

黄 核 素 心
ISO9000:2000 版标准 ISO9000:制定管理理念和原则 ISO9001:标准对组织质量管理体系必须履行的要求做了明确的规定,是对产品要求的 进一进补充。 (梳心) ISO9004:是组织进行持续改进的指南标准。 八项质量管理原则: 一. 以顾客为中心:组织依存于其顾客,因此,组织应理解顾客当前的和未来的需 求, 满足顾客要求并争取赶超顾客期望。

[键入文字]

二. 领导作用: 领导者将本组织的宗旨.方向和内部环境编统一起来,并创造使员 工能 够充参与实现组织目标的环境。 三. 全员参与: 各级人员是组织之本,只有他们的充分参与,才能使他们的才干 为组 织带来最大的收益。 四. 过程方法: 将相关的资源和活动作为过程进行管理, 可以更高效地得到期望的 结 果。 五. 管理系统方法:针对设定的目标,识别.理解并管理一个由相互关联的过程的过 程 所组成的体系,有助于提高组织的有效性和效率。 六. 持续改进:持续改进是组织的一个永恒的目标。 七. 基于事实的决策方法: 对数据和信息的逻辑分析或直觉判断是有效决策的基础。 八. 互利的供方关系:通过互利的关系,增强组织及其供方创造价值的能力。 其中与软件产品产品优其相关有: (一.三.六.七项)

1、 软件质量的定义:一个实体的所有特性,基于这些特性可以满足明显的或隐含的需 求。而质量就是实体基于这些特性满足需求的程度。 2、 软件质量的三个层次:a. 符合需求规格;b. 符合用户显示需求; c. 符合用户实际需求。 3、 影响软件质量的因素:流程、技术、组织。 流程:一组活动(活动是否都是必须的;活动角色之间的关系) 过程:一组将输入转化为输出的相关联或相互作用的活动。 4、 八项质量管理原则的意义:a. 是质量管理的理论基础; b. 用高度概括易于理解的语言所表述的质量管理的最基 本,最通用的一般性规律; c. 为组织建立质量管理体系提供了理论依据; d. 是组织的领导者有效的实施质量管理工作必须遵循

[键入文字]

的原则。 5、CMM 软件质量成熟度模型 CMM(capabillty Maturity Moelel) 由于美国软件工程研究所(SEI)受美国国防部委托立项。 开发人:Watts Humphrey. 1991 年推出 CMM1.0 版,1993 年提出 CMM1.1 版 现在开发 CMMI(CMM Integration) 软件能力成熟度模型 CMM(提唱过程决定质量)

持续改进过程

5 优化级 关注过程改进

4 已管理级 Managed

可预测的过程 更

过程被描述,并得到良好理解

管理变

标准.一致的过程

3 已定义级 Definded 过程被描述,并得到良好理解

产品过程质量

纪律的过程

2 可重复级 Repeatable 可重复以前的主要经验

集成工程过程

1 初始级 initial 不可预测并且缺控制 CMM1 级

项目管理

特点: (个人英雄主义)
A 项目的成功依赖于一个非常优秀的项目经理的团队。 B 无法重复以往成功的实践。 C 缺乏基本配置管理

可视度:

[键入文字]

整个过程不可预测,不可见,不可控。 (过程管理非常混乱) CMM2 级

特点: (有纪律)
能够重复以前成功的经验和实践。 引入合理需求变更(需求管理) 测试与开发分离,整个过程能力可概为有纪律的。

可视度
原始需求——需求分析——设计——编码——测试——产品 CMM3 级

特点: (有过程,经过同行评审)
组织中有一个专门负责组织的标准软件过程。 (SEPG)

可视度
同 CMM2 但整个过程是标准和一致的。 CMM4 级特点

特点: (量化管理)
过程能力是可预防的,因为过程是已测量的并在可测的范围内运行。组织能定量地预测 过程和产品质量方面趋势。软件产品具有可预测的高质量。

可视度
同 CMM3 但整个过程是可预测的。 CMM5 级特点

特点: (改进过程本身)
通过缺陷来发现过程的不足。 新的开发技术触使改进过程。

可视度
同 CMM¥级整个是以改进的。

CMM1:初始级,Inltial,不可预测并且缺乏控制; CMM2:可重复级:Repeatable,可重复以前的主要经验; (关键过程区域:需求管理;软件项目计划;软件项目跟踪和监督;软件子

[键入文字]

合同管理;软件质量保证;软件配置管理。 ) CMM3:已定义级:Defined,过程被描述,并得到良好理解; (关键过程区域:组织过程定义;组织过程焦点;培训大纲;集成软件管理; 软件产品工程;组际协调;同行评审。 ) CMM4:已管理级:Managed,过程被测量并受控; (关键过程区域:定量的过程管理;软件质量管理。 ) CMM5:优化级,Optimizing,关注过程改进。 (关键过程区域:缺陷预防;技术变更管理;过程变更管理。 ) 7、 CMM 的用途:a. 评估组用来识别组织中的强处和弱处; b. 评价组用来识别选择不同的业务承包商的风险和监督合同; c. 管理者用来了解其组织的能力, 并了解为了提高其能力成熟度而进 行软件过程改进所需进行的活动; d. 技术人员和过程改进组用来作为指南, 指导他们在组织中定义和改 进软件过程。 8、 ISO9001 和 CMM 的关系: 相似点:强调管理、过程、规范化和文档化; 不同点:CMM 把焦点对准软件;ISO9001 的范围包括:硬件、软件、流程性材料和服 务; 两者关系:CMM2 级与 ISO9001 强相关;CMM 的每个关键过程域至少按某种解释与 ISO9001 弱相关。 六西格玛管理法(强调组织能力)

本质:全面质量管理,而不仅仅是质量提高手段 六西格玛实施方式:
DMAIC 过程

[键入文字]

5 控制 cororol

推行控制系统

4 改进 Improre

优化解决方案

3 分析 Anslyse

研究资料,确定原因

2 测量 Measure

收集资料,寻找原因

1 定义 Define

提出问题,确定目标

9、 软件质量模型: 功能性:当软件在指定条件下使用时,软件产品提供满足明确和隐含需求的功能的 能力。包括:适合性;准确性;互操作性;保密安全性;功能性的依从性。 可靠性:在指定条件下使用时,软件产品维持规定的性能级别的能力。包括:成熟 性;容错性;易恢复性;可靠性的依从性。 易用性:在指定条件下使用时,软件产品被理解、学习、使用和吸引用户的能力。 包括:易理解性;易学性;易操作性;吸引性;易用性的依从性。 效 率:在规定条件下,相对于所用资源的数量,软件产品可提供适当性能的能力。 包括:时间特性;资源利用性;效率依从性。 维护性:软件产品可被修改的能力。修改可能包括修正、改进或软件对环境、需求 和功能规格说明变化的适应。包括:易分析性;易改变性;稳定性;易测 试性;维护性的依从性。

[键入文字]

可移植性:软件产品从一种环境迁移到另外一种环境的能力。包括:适应性;易安 装性;共存性;易替换性;可移植性的依从性。 10、 软件质量活动:软件质量保证(SQA)和测试;SQA 从流程方面保证软件的质量、测 试从技术方面保证软件的质量、只进行 SQA 或者只进行测试活动不 一定能产生好的软件质量。 11、 SQA 的主要工作范围: 指导并监督项目按照过程实施; · · 对项目进行度量、分析,增加项目的可视性; · 审核工作产品,评价工作产品和过程质量目标的复合度; · 进行缺陷分析,缺陷预防活动,发现过程的缺陷,提供决 策参考,促进过程改进。 12、 度量:对事物属性的量化表示; 软件度量:是指计算机软件中范围广泛的测度,包括对软件系统、构建或生命周 期过程具有的某个给定属性的度的一个定量测量。 目的: 提高软件生产率,缩短产品研发周期,降低研发成本、维护成本; · · 提高软件产品质量,提高用户满意度; · 为组织持续改进提供量化的指标和反馈。 13、 软件度量的作用:理解;预测;评估;改进。 分类:规模;工作量;进度;质量 如何将度量的知识应用于实际工作中: 建立测试工作的度量数据, 目的是作为预测 和改进的基础(a. 熟悉需求:进度、工作量、规模;b. 设计用例:工作效率、 覆盖率;c. 执行用例:工作效率、缺陷密度; )

[键入文字]

测 试 方 法
1、 什么是白盒测试: · 白盒测试是依据被测软件分析程序内部构造,并根据内部构造设计用例,来对内 部控制流程进行测试,可完全不顾程序的整体共能实现情况; · 白盒测试是基于程序结构的逻辑驱动测试; · 白盒测试又可以被称为玻璃盒测试、透明盒测试、开放盒测试、结构化测试、逻 辑驱动测试。 2、 为什么进行白盒测试: · 一般在测试前期进行,通过达到一定的逻辑覆盖率指标,使得软件内部逻辑控制 结构上的问难题能基本得到消除; · 能保证内部逻辑结构达到一定的覆盖程度,能够给予软件代码质量更大的保证; · 发现问题后解决问题的成本较低。 3、 白盒测试的常用技术: · 静态分析:控制流分析、数据流分析、信息流分析等; · 动态分析:逻辑覆盖测试(分支测试、路径测试等) 、程序插装等。 4、 *控制流相关概念:程序元素、控制流关系、控制流图、控制流矩阵。 (步骤:5) 5、 *控制流分析能发现的问题:转向并不存在的标号;没有用的语句标号;从程序 入口进入后无法达到的语句;不能达到停机语句的 语句。 6、 *数据流相关概念:数据的定义;数据的引用。 (步骤:3) 7、 *数据流分析的左右:分析代码中关于数据定义和引用方面的错误;进行代码优 化。 (赋值语句运算效率高) 8、 *信息流分析:输入变量和语句关系;语句和输出变量关系;输入和输出变量管

[键入文字]

理。 (步骤:4)

9、 覆盖率工具的作用: · 分析被测试代码控制结构,决定插装位置; 实施插装; 将插装代 · · 码重新编译; 执行被测对象,根据插装的监控哨信息统计覆盖率。 · 10、 白盒测试的特点: · 测试人员需要了解软件的实现; 可以检测代码中的每条分支和路 · 径; 解释隐藏在代码中的错误; 对代码的测试比较彻底; 实现代 · · · 码结构上的优化; 白盒测试投入较大,成本高; 白盒测试不验证规 · · 格的正确性。 11、 什么是黑盒测试: · 黑盒测试把被测对象看成一个黑盒,只考虑其整体特性,不考虑其内部具体 实现; · 黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块、一个子 模块、一个函数等。 · 黑盒测试又可以被称为基于规格的测试。 12、 13、 常见的黑盒测试类型:功能性测试;容量测试;负载测试;恢复性测试。 *系统测试的时候,如果没有 SRS 时,有两类 BUG 无法发现:需求遗漏; 需求偏差。 14、 黑盒测试的优点: ·对于更大的代码单元来说(子系统甚至系统级)比白 盒测试效率要高; 测试人员不需要了解实现的细节, · 包括特定的编程语言; 从用户的视角进行测试,很容 · 易被大家理解和接受; 有助于暴露任何规格不一致或 · 有歧义的问题。

[键入文字]

15、

黑盒测试的缺点: 没有清晰的和简明的规格,测试用例是很难设计 · 的; 不能控制内部执行路径,会有很多内部程序路径 · 没有被测试到;不能直接针对特定的程序段,这些程序 可能非常复杂(因此可能隐藏更多的问题) 。

16、 17、

动态和静态测试的分类依据在于:被测对象是否运行起来。 手工静态分析——同行评审:正规检视;技术评审;走查。评审对象:计 划、需求文档、设计图、代码等。

18、 ?

自动化静态分析:静态验证;语法分析器;符号执行器。 自动化测试的限制(板书) :
· 自动化测试不具备想象力,不能够检查脚本中给定的观察点之外的错误; · 自动化测试只能提高测试效率,不能提高测试效果,不能发现比人工测试更多的问题; 如被测对象不稳定,存在变动性的话不适合开展自动化测试,否则脚本的编写和维护所 耗费的时间可能远大于人工测试; · 只有手工测试积累到一定程度(提供更多的观察点) ,才能做好自动化测 试。

[键入文字]

V&V 模型(测试过程)
1、 验证与确认 V&V:验证(VERIFICATION)强调过程;确认(VALIDATION)强调 结果。 2、 V&V 告诉我们: 尽早测试(尽早准备、尽早执行) · ; · 全面测试(文档、代码) · 全过程测试(测试参与到开发过程中、对测试过程全称跟踪) · 测试是独立的、迭代的。

需求分析 SRS 评审 SRS 基线化 概要设计 HLD 评审 HLD 基线化 详细设计 LLD 评审 LLD 基线化

系统测试计划 系统测试方案设计 系统测试用例设计 集成测试计划 集成测试方案设计 集成测试用例设计 单元测试计划 单元测试方案设计 单元测试用例设计

系统测试执行

集成测试执行

单元测试执行 代码审查

CODE

3、 单元、集成、系统测试的比较:测试方法不同;考察范围不同;评估基准不同。 4、 回归测试策略:完全重复测试;选择性重复测试(覆盖修改法;周边影响法; 指 标达成方法;选择重要级别高的测试用例) 5、 其他测试阶段:验收测试;a(ALPHA)测试;B(BETA)测试。

[键入文字]

6、 主要的测试文档:测试计划;测试方案;测试用例;测试规程;测试报告;测试日 报。

[键入文字]

单 元 测 试
1、 单元测试的目的:
在于发现各模块内部可能存在的各种错误主要是基于白盒测试。 · 验证代码是与设计相符合的; 发现设计和需求中存在的错误; · · 发现在编码过程中引入的错误。 (和设计不相符 / 和设计相符,但是由于 编码疏漏引起)

2、 孤立的测试策略:
· 方法:不考虑每个模块与其他模块之间的关系,为每个模块设计桩模块和 驱动模块。每个模块进行独立的单元测试。 · 优点:该方法是最简单,最容易操作的。可以达到高的结构覆盖率。该方法是纯 粹的单元测试。 · 缺点:桩函数和驱动函数工作量很大,效率低。

3、 自顶向下的单元测试策略:
· 方法:先对最顶层的单元进行测试,把顶层所调用的单元做成桩模块。其 次对第二层进行测试,使用上面已测试的单元做驱动模块。如此类 推直到测试完所有模块。 · 优点:可以节省驱动函数的开发工作量,测试效率较高。 · 缺点:随着被测单元一个一个被加入,测试过程将变得越来越复杂,并且 开发和维护的成本将增加。

4、 自底向上的单元测试策略:
· 方法:先对模块调用层次图上最低层的模块进行单元测试,模拟调用该模 块的模块做驱动模块。然后再对上面一层做单元测试,用下面已被 测试过的模块做桩模块。以此类推,直到测试完所有模块。 · 优点:可以节省桩函数的开发工作量,测试效率较高。 · 缺点:不是纯粹的单元测试,底层函数的测试质量对上层函数的测试将产 生很大的影响。

5、

单元测试的四个阶段: 测试计划:完成单元测试计划; ·
· 测试设计:完成单元测试方案;

[键入文字]

· 测试实现:完成单元测试用例、单元测试规程、单元测 试脚本及数据文件; · 测试执行:执行单元测试用例,修改发现的问题并进行 回归测试,提交单元测试报告。

? 单元测试:桩&驱动举例:
无论是单元测试还是集成测试都涉及到以下三个函数: 主控函数:int ctrl(int x, int y) 加法函数:int add(int x, int y) 减法函数:int sub(int x, int y) 注意:进行单元测试时,设计用例时依据的是 LLD;进行集成测试时,设计测试用例依 据的是 HLD。下面给出来的是需要测试的实际的代码。 int ctrl(int x, int y) { int temp=0; if(x>=y) temp=add(x, y); else temp=sub(x, y); return temp; } int add(int x, int y) { return(x+y); } int sub(int x, int y) { return(x-y); }

? 自顶向下单元测试策略
不同测试步骤中的驱动可以写到一起,也可以分开写,这里是写到一起了。

? 测试 ctrl 函数
需要写一个驱动和两个桩。 ? 驱动函数

void driver() { int ret=0; ret=ctrl(2,1); //x>y

[键入文字]

if(ret==3) printf(“testcase JISUAN_UT_CTRL_001 pass”); else printf(“testcase JISUAN_UT_CTRL_001 fail”); ret=ctrl(1,1); //x=y if(ret==2) printf(“testcase JISUAN_UT_CTRL_002 pass”); else printf(“testcase JISUAN_UT_CTRL_002 fail”); ret=ctrl(1,2); //x<y if(ret==-1) printf(“testcase JISUAN_UT_CTRL_003 pass”); else printf(“testcase JISUAN_UT_CTRL_003 fail”); }

?

桩函数 int stub_sub(int x, int y) { if(x==1 && y==2) return -1; return 999999; }

int stub_add(int x, int y) { if(x==2 && y==1) return 3; if(x==1 && y==1) return 2; return 999999; } ? 修改代码

为了让桩能体现在测试过程中,需要修改 ctrl 函数: int ctrl(int x, int y) { int temp=0; if(x>=y)

[键入文字]

temp=stub_add(x, y); else temp=stub_sub(x, y); return temp; }

? 测试 add 函数

?

驱动函数 同测试 ctrl 函数时的驱动

? 桩函数 同测试 ctrl 函数时 sub 函数对应的桩

? 修改代码 int ctrl(int x, int y) { int temp=0; if(x>=y) { temp=add(x, y); if(x==2 && y==1 && temp==3) printf(“testcase JISUAN_UT_ADD_001 pass”); else printf(“testcase JISUAN_UT_ADD_001 fail”); if(x==1 && y==1 && temp==2) printf(“testcase JISUAN_UT_ADD_002 pass”); else printf(“testcase JISUAN_UT_ADD_002 fail”); } else temp=stub_sub(x, y); return temp; }

? 测试 sub 函数

[键入文字]

? 驱动函数 同测试 ctrl 函数时的驱动 ? 桩函数 无

[键入文字]

? 修改代码 int ctrl(int x, int y) { int temp=0; if(x>=y) temp=add(x, y); else { temp=sub(x, y); if(x==1&&y==2 && temp==-1) printf(“testcase JISUAN_UT_SUB_001 pass”); else printf(“testcase JISUAN_UT_SUB_001 fail”); } return temp; }

27

[键入文字]

集 成 测 试
一. What:什么是集成测试 ? 集成测试(Integration Testing) 集成测试也叫组装测试、联合测试、部件测试、

子系统测试 ? 集成测试测什么 1.外部接口:各件呐在一起后表现的功能 2.内部接口:各件间的接口是否正确 ? ? 集成苏的目的 验证软件的组建对概要设计说明书的符合度 ? 集成测试的评估基准: 接口覆盖率 A.接口被测试到的百分比 B.接口的等价类、边界值的覆盖率 二. Why:为什么要做集成测试 ? ? ? ? ? 一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。 程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。 虽然已经有了 IT 和 ST,但 IT 和 UT、ST 关注点不一样,它们互为补充 反分解性公理:为一个被测模块获得的覆盖并不能覆盖他所调用的模块。 反组合性公理:对于一个模块中的对各子模块分别合适的测试包并不一定对作为一

个整体的模块合适 三. Who:谁做集成测试 ? 开发人员做 A 优势:一般来说,编程能力稍强

28

[键入文字]

B 劣势:Protect(就像变形金刚的汽车人) ,心理上不愿意否定自己的劳动成果,职 责是保护程序 ? 测试人员做 A 优势:Destroy(就像变形金刚的霸天虎) ,心理上追求完美,职责是挑刺、破坏程 序 B 劣势:目前的现状,大部分 tester 编程能力不够 四. When:什么时候做集成测试 4.1 集成测试所处的测试过程 ? 集成测试所处的测试过程 A.测试准备活动在开发活动时可以并行开展, 如开始做 HLD 设计时就可以开始做 ITP 了 B.测试执行活动在单元测试的基础上进行 五. Where:对什么部分做集成测试 ? ? ? 子系统间集成(系统内集成) 模块间集成(子系统内集成) 函数间集成(模块内集成)

六. How:怎么做集成测试 6.1 测试过程的制定 6.1.1 计划 根据 SVVP 制定 ITP 6.1.2 设计 根据 ITP 制定 IT 方案 6.1.3 实现 根据 IT 方案制定 IT 用例

29

[键入文字]

6.1.4 执行 根据 IT 用例进行集成测试,提交 Bug Report,??,回归测试 6.2 采用的测试方法 6.2.1 灰盒测试 随集成层次不同,灰度随之相应变化 6.3 制定集成测试策略 Test Strategy 6.3.1 根据被测对象(层次)选择合适的策略 1>大爆炸集成 Big Bang

优点 方法简单、效率高 缺点 ? ? ? "急于求成",成功率不高 "大海捞针",导致即使发现问题也难以定位(无法故障隔离) "囫囵吞枣",许多内部接口的错误被漏测

适用范围 ? ? 小项目、维护型项目 软件结构不清晰的系统

2>自顶向下集成 Top-Down 子策略 ? ? 深度优先(Depth-First) 广度优先(Broadth-First)

优点 A.主控模块(高层组件)得到较早验证

30

[键入文字]

B.深度优先策略能够较早验证一个完整的功能,增强了开发信心 C.基本不需要开发驱动,减少了这部分的工作量 D.和高层设计顺序一致,方便并行开展 E.定位问题容易,支持故障隔离 缺点 A.需要开发大量的桩,工作量、成本太大 B.底层变更可能导致测试推倒重来 C.底层组件的验证较晚,测试不充分 适用范围 A.软件结构清晰的系统 B.高层接口变化小,底层接口变化大 C.主控模块风险大,需尽早验证 D.希望尽早看到系统一部分功能 3>自底向上集成 Bottom-Up 优点 A.底层组件得到较早验证 B.测试初期可以并行集成,效率高 C.由于驱动模块是额外编写的,对被测模块的可测试性要求较低 D.减少了开发桩的工作量 E.定位问题容易,支持故障隔离 缺点 A.需要开发大量的驱动,工作量、成本同样很高 B.对高层的验证太晚了,设计上的缺陷不能被及早发现 C.集成到顶层后,对于底层异常将难以覆盖。而使用桩将简单得多

31

[键入文字]

适用范围 A.软件结构清晰的系统 B.底层接口稳定、或先被开发出来 C.高层接口变化较频繁 4> 三明治集成(分而治之策略) 又分为传统型和改进型 Sandwich 优点 融合了自顶向下和自底向上两种策略的优点 缺点 中间层测试要么不充分,要么测的充分但开发驱动和桩的工作量大 适用范围 软件结构清晰的系统基本都适合采用 5>基干集成(内核耦合度高) Backbone 结构与策略:内核(大爆炸)-应用子系统(自底向上)-控制子系统(自顶向下) 优点 具有三明治集成的优点 缺点 A.对系统结构的分析存在一定难度 B.由于被测系统复杂,驱动和桩的开发工作量较大 C.局部采用了大爆炸策略,存在大爆炸所有的缺点 适用范围 嵌入式系统 6>分层集成(线性关系) Layers 集成方式 A.层内集成

32

[键入文字]

策略非常灵活,可以是各种其他策略 优缺点根据策略而变 B.层间集成 策略和优缺点同"层内集成" 使用范围 有明显线性层次关系的系统 7>基于功能集成 Function-Based 优点 A.可以尽早验证关键组件的功能 B.可能同时加入多个模块,与大爆炸类似,效率较高 C.和自顶向下一样,驱动模块的开发工作量不多 缺点 A.兼具大爆炸和自顶向下的缺点,比如对有些接口测试不充分,可能导致漏测 B.可能会有较多的冗余测试 适用范围 对功能的实现没把握的产品 8>持续集成(高频集成、每日集成) Continuous/High-frequency 优点 A.错误能被较早发现,且容易定位 B.开发和集成可以并行,效率高 缺点 测试针对性不强,不容易发现有价值的问题 适用范围 迭代开发、增量开发的产品

33

[键入文字]

9>基于进度集成 Schedule-Based 优点 并行度高,能缩短项目进度 缺点 组件间缺乏整体性,无法有效集成 开发驱动和桩的工作量难以估计 由于进度原因,集成效果不好 适用范围 进度很紧的项目 10>基于风险集成 Risk-Based 优点 风险大的模块得到较早验证,有助于系统的快速稳定 缺点 风险分析偏差导致集成重点的偏离 适用范围 有些组件有较大的风险,需及早验证以增强信心 11>基于消息(事件)集成 Message-Based/Event-Based 优缺点与"基于功能集成"类似,适用面向对象系统 12>基于使用集成 Use-Based 优缺点与"自底向上"类似,适用面向对象系统 13>基于 C/S、B/S 的集成 适用 C/S、B/S 结构的系统 14>分布式集成 Distributed Services 适用分布式系统

34

[键入文字]

35

[键入文字]

系 统 测 试

?

定义

System Testing--是将已经集成好的软件系统,作为整个计算机系统的一个元素,与计 算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起,在实际运行 使用的环境下,对计算机系统进行系列的测试活动; ? 对象

36

[键入文字]

1.产品级--软件+硬件 2.项目级--软件(也可能包含硬件) ? 完备性

如何保证系统测试的完备性? 1.尽可能所有需求都有对应的 Test Case; 2.依据软件的质量特性,以不同的角度,测试需求; 3.依据不同的 Test Case、方法,构造不同的测试数据及处理过程; 常用测试方法 1.1 功能测试(功能) ? 定义:

function Testing--依据 SRS 和测试需求列表验证产品的功能是否实现和是否符合产品 需求规格 ? 目标:

1.是否有不正确或遗漏了的功能? 2.功能是实现是否满足用户需求,和系统设计的隐式需求? 3.输入能否正确接受?能否正确输出结果? 1.2 性能测试(效率) ? 定义:

Performance Testing--测试该软件在集成系统中的运行性能。 (大多使用工具测试) ? 目标:

度量系统相对与预定义目标的差距。 ? 实施:

1.性能指标定义明确。 2.构造性能测试研究数据。

37

[键入文字]

3.构造不同的性能测试场景。 4.执行性能测试 (一般>90%就通过) 。 5.性能分析。 6.性能故障定位。 7.性能优化。 ? 依据

1.资源占用性。 2.CPU 响应时间。 ? 区别:

1.压力测试--不强调施压量,只检查施压的状况。 2.容量测试--强调施压,施了多少压。 3.性能测试--施压后检验性能指标是否达到规定资源使用和响应时间的要求。 1.2.1 资源方面(资源占用情况) ? ? ? ? CPU 使用情况。 IO 使用情况。 内存使用情况。 信道使用事情。

1.2.2 时间方面(CPU 响应时间) ? ? ? ? ? ? 每个模块执行时间百分比。 一个模块等待 IO 完成的百分比。 指令随时间的跟踪路径。 每一组指令页换入和换出的次数。 系统反映时间。 系统吞吐量,即每个单元的处理数量。

38

[键入文字]

?

所有主要指令的单元执行时间。

1.3 压力测试/极限测试(可靠性) ? 定义:

Stress Testing--系统在其资源超符合的情况下表现。 ? 目标:

在极限或者恶劣的环境下,系统的自我保护能力。主要验证系统的可靠性。 ? 实施:

1.同一时间,大量的用户登陆。 2.引入大量的操作。 ? 目的:

1.是否存在内存泄露。 2.验证系统可靠性。 3.测试后给予用户一个明确的界定。 ? 区别:

1.压力测试--不强调施压量,只检查施压的状况。 2.容量测试--强调施压,施了多少压。 3.性能测试--施压后检验性能指标是否达到规定资源使用和响应时间的要求。 1.4 容量测试 ? 定义:

volume Testing--使系统能够承受超额的数据容量来发现它是否能够正确处理。 ? 目标:

1.测试系统容量是否满足需求规定系统容量。 2.若无规定系统容量可以通过此测试给出明确容量界定。 ? 实施:

39

[键入文字]

1.构造一批大容量的测试数据输入到系统。 2.对系统整体构造不同业务场景,反复执行。 ? 区别:

1.压力测试--不强调施压量,只检查施压的状况。 2.容量测试--强调施压,施了多少压。 3.性能测试--施压后检验性能指标是否达到规定资源使用和响应时间的要求。 1.5 安全性测试(功能) ? 定义:

Security Testing--验证集成在系统内的保护机制能否在实际应用中保护系统不受到非 法的侵入。 ? 目的:

保证系统安全性,数据的完整性、保密性。 1.5.1 数据 完整性 ? ? 数据存储的完整性。 数据保密的完整性。

保密性 ? ? 数据存储的保密性。 数据访问的保密性。

1.5.2 权限 ? ? 权限的分配 权限的使用

1.5.3 协议 多在手机测试用到。

40

[键入文字]

1.5.4 其他 如 LOG.. 1.6 GUI 测试(易用) ? 定义:

Graphical User Interface Testing--针对软件系统的界面进行的测试。 ? 目标:

1.界面实现与界面设计的吻合情况。(界面设计) 2.确认界面处理的正确性。 (针对不同的控件分析) ? 相关自动化测试工具

1.WinRunner 2.SilkTest 3.QaRun 1.6.1 简单界面元素 ? 定义:

指功能和属性相对比较单一的界面区域,即通常所指的各种控件。 ? 方法:

主要关注他们的外观、表现行为。 1.6.2 组合类界面元素 ? 定义:

一些复杂的界面元素,比如表格、各种文本编辑器等。 ? 方法:

先将其分解为简单的界面元素,然后再进行处理。 1.6.3 完整界面(窗口) ? 定义:

41

[键入文字]

由一系列界面元素通过适当的形式组合而成的界面形式,最为常见的为各种窗口。包括 各种对话框、单文档窗口、多文档窗口,多文档子窗口等。 ? 方法:

外观、布局、行为。 1.输入类界面元素:与要考虑其外观、输入时的特性比如回显、对齐原则、滚动原则等 内容。 2.输出类界面元素:外观。

1.7 可用性测试(易用) ? 定义:

Usability Testing--为检测用户在理解和使用系统方面到底有多好。 ? 目标:

1.考虑产品是否符合实际应用情况。 2.是否符合用户习惯或特殊要求。 3.操作方式是否方便合理、设备和用户见交互信息是否准确易于理解、是否遵从行业习 惯、外观/界面是否美观等。 ? 一般关注的可用性问题:

1.过分复杂的功能或指令。 2.困难的安装过程。 3.错误信息过于简单。 4.用户被迫去记太多信息。 5.语法、格式和定义不一致。

1.8 安装测试

42

[键入文字]

?

定义:

根据软件测试特性列表、软件安装、配置文档,设计安装过程的测试用例,发现软件在 安装过程中的错误。 ? 被测对象:

1.软件本身。 2.软件安装文档。 1.8.1 安装测试前要检查的工作 1.安装文档是否齐全。 2.安装软件的程序文件是否齐全。 3.被测软件的安装文件是否齐全。 4.软件的安装说明文档是否齐全。 5.检查软件的文件格式是否与安装说明文档中要求的文件格式相符。 1.8.2 安装测试过程中的工作 1.所有的预置数据是齐全。 2.软件环境配置是否合理。 3.硬件环境配置是否合理。 4.用户选择的一套任选方案是相容。? 5.安装过程中: A.系统提供的缺省参数值进行安装测试。 B.指定由人工完成安装过程,列出每一步安装步骤所需的工作,并仔细检查每一安装步 骤所完成工作的正确性。 C.安装测试过程中要设计异常的安装测试用例,包括配置参数的异常、安装选项和安装 路径的异常。 6.安装文档的测试。

43

[键入文字]

1.8.3 安装后要做的检查工作 1.所有文件是否都已产生并确有所需的内容。 A.程序文件的目录是否正确产生。 B.各目录及子目录下的程序文件是否都正确产生。 C.是否存在无用的目录、子目录、程序文件以及无用的子目录。 D.目录、子目录、以及程序文件本身的权限是否正确。 E.对于 Windows 还要检查与应用软件相配套的动态链接库文件齐全。 2.安装日志的检查。 3.安装完成后,要进行程序的运行,联结验证。 4.软件的卸载测试。 1.8.4 安装测试中软件的升级测试 1.软件通过重新安装来达到升级的目的。 2.通过 Patch 的方式实现软件的升级。 3.在线升级。

1.9 配置测试 ? 定义:

系统在各种软硬件配置、不同参数配置下系统具有的功能和性能。 ? 目标:

验证全部配置的可操作性,有效性。

1.10 异常测试/恢复性测试(可靠) ? 定义:

容错性测试。通过人工干预手段产生异常,能检验系统的容错、恢复能力,是系统可靠

44

[键入文字]

性评价的重要手段。 ? 异常处理

1.系统自动处理。 2.人工干预处理。 ? 注意

1.系统的异常还与系统的指标测试有关,当系统的服务能力大于系统的设计指标时,也 属于系统的异常情况。 2.系统的可靠性是设计出来的,而不是测试出来的。测试出的数据有助于为我们进一步 的系统优化设计积累经验,设计和测试是一个相互反馈的过程。

1.11 备份测试(可靠) 恢复性测试的一个补充,验证软件或硬件失败中备份他数据的能力。 1.12 健壮性测试(可靠) Robustness Testing 用于测试系统在故障时,是否能够自动恢复或者忽略故障继续运 行。 1.13 文档测试 Documentation Testing 测试文档的正确性,保证操作手册的过程能够正常工作。 1.14 在线帮助测试 Online Help Testing 检测时实在线帮助的可靠性和正确性。 1.15 网络测试 网络环境下和其他设备对接,进行系统功能、性能与指标方面的测试,保证对接的正确 性。 1.16 稳定性测试 在一定负荷情况下能持续运行的时间。

45

[键入文字]

2 系统测试测试过程
2.1 计划阶段 明确 what 目标、why 测试目的、when 可控时间、where 测试范围、how 如何开展.主要活 动有:参与开发人员软件需求的分析,SRS 评审,通过后写 ST 计划,进行 ST 计划评审。 ? ? ? ? 入口准则:SRS 完成并确定需求规格基线 输入:SRS|SDP|SVVP 出口准则:ST 计划评审通过 输出:

2.2 设计阶段 主要活动有:组织人员依据测试计划编写测试方案,并进行系统方案的评审 ? ? ? ? 入口准则: ST 计划评审通过 输入: ST 计划|SRS

出口准则: ST 方案评审通过 输出: ST 方案

2.3 实现阶段 主要活动有:组织人员依据 ST 方案编写测试用例、测试规程及预测试项,并对其进行评 审 ? ? ? ? 入口准则: ST 方案评审通过 输入: ST 计划|SRS|ST 方案

出口准则: 测试用例、测试规程及预测试项评审通过 输出: 测试用例、测试规程及预测试项

46

[键入文字]

2.4 执行阶段 主要活动有:组织测试执行活动、负责缺陷报告返回给开发部门修改、组织进行测试报 告的编写、组织进行测试报告的评审 ? ? ? ? 入口准则: 测试用例、测试规程及预测试项的评审通过 输入: ST 计划|ST 方案|ST 用例|ST 规程|ST 预测试项

出口准则: ST 报告评审并通过 输出: ST 预测试报告|ST 测试报告|缺陷报告

测 试 覆 盖 率
1、 覆盖率概念: ·覆盖率是用来度量测试完整性的一个手段。 覆盖率是测试技术有效性的一个度量。 覆盖率=(至少被执行一次的 item 数)/item 的总数; · 覆盖率大体可以划分为两大类:逻辑覆盖和功能覆盖; · 测试用例设计不能一味追求覆盖率,因为测试成本虽覆盖率的增加而增加。 2、 逻辑覆盖主要类型:语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、路径 覆盖。 3、 语句覆盖率: (Statement Coverage) ,在测试时运行被测程序后,程序中被执 行到的可执行语句的比率; 语句覆盖率 = (至少被执行一次的语句数量)/(可执行的语句总数) 4、 分支覆盖率: (Branch Coverage)也叫判定覆盖(Decision Coverage) ,它的含 义是:在测试时运行被测程序后,程序中所有判断语句的取真分 支和取假分支被执行到的比率;

47

[键入文字]

判定覆盖率=(判定结果被评价的次数)/(判定结果的总数) 5、 条件覆盖率: (Condition Coverage)的含义是,在测试时运行被测程序后,所 有判断语句中每个条件的可能取值(真值和假值)出现过的比率; 条件覆盖率=(条件操作数值至少被评价一次的数量)/(条件操作数 值的总数) 6、 分支-条件覆盖率: (Branch Condition Coverage)也叫判定条件覆盖(Decision Condition Coverage) ,它的含义是,在测试时运行被测程序 后,所有判断语句中每个条件的所有可能值(为真为假) 和每个判断本身的判定结果(为真为假)出现的比率; 分支条件覆盖率=(条件操作树枝或判定结果至少被评价一 次的数量)/(条件操作数值总数+判定结果总数) 7、 路径覆盖率: (Path Coverage)的含义是,在测试时运行被测程序后,程序中 所有可能的路径被执行过的比率; 路径覆盖率=(至少被执行到一次的路径数)/(总的路径数) 8、 其他覆盖率:功能覆盖率;面向对象的覆盖率;函数覆盖;指令块覆盖;判定 路径覆盖。

48

[键入文字]

测 试 用 例 举 例
测试用例编号 重要级别 测试项目 测试标题 用例类型 用例设计者 设计日期 对应需求编号 对应 UI 对应 UC 版本号 对应开发人员 预置条件 测试方法 输 入 BOSS_ ST_ MARKETING_NEW_01P 高(还有“较高、中、较低、低”几个等级) 新增营销记录 新增 10 元的营销记录 基本事件(对应还有“备选事件”“异常事件” 、 ) songfun 2005-04-25 REQ_ MARKETING_NEW_01 Marketing.htm UC_ MARKETING_NEW_01 Build v0.1 Frank 操作员登录营销管理系统 等价类划分(对应还有“错误猜测法”“边界值分析”等) 、 用户名:51testing 性别:男 金额:10 元 描述:aaaaaaa ①. 进入【营销下发】页面; ②. 点击『增加』按钮; ③. 输入相应数据; ④. 点击『确定』按钮; ⑤. 在后台数据库(test/test@testDB)输入查询语句验证:select * from MarketingTab where ID='1001' 预期输出 ㈠. 执行步骤④后,页面弹出添加成功提示信息框;

操作步骤

49

[键入文字]

㈡. 执行步骤⑤后查询数据库,记录确实添加成功且数据无误

50

[键入文字]

同 行 评 审
1、 同行评审: (Peer Review)是一种通过作者的同行来确认缺陷和需要变更区域的检 查方法。需要进行同行评审的特定产品在定义项目软件过程的时候被确 定并且作为软件开发计划的一部分被安排了进度。 · 需要前期准备、计划和时间进度表 · 越早越好 3、 同行评审的作用: 早期发现缺陷; 去除缺陷; 降低成本; 提高质量。 · · · · 4、 同行评审的类型: 正规检视: · (Inspection)最严格,要求有规范的流程,参 加者经过正式培训; · 技术评审: (Technique Review)以技术方案的比较、裁决 为目的,严格程度介于正规检视和走读之间; · 走 读: (Walk Through)最(自由)松散的形式,无流程要 求,有评审团队,评审流程无要求。 5、 通用评审流程步骤(正规检视流程) :
入口 准则

1.计划 阶段 5.第三小时 会议 Y
第三小时会议?

介绍会议?

N

6.返工 阶段

Y N 2.介绍 会议

7.跟踪 阶段

3.准备 阶段

4.Review 会议

出 口

6、 计划阶段: · 项目负责人指定组织者; ·作者自检工作产品; 组织者规划本次评审; · · 检查入口准则:是否符合文档标准?是否已用工具检查?代码<=500 行; 文档<=40 页;……

51

[键入文字]

· 准备评审包:工作产品(HLD) ;参考资料(SRS-检查一致性) ;评审表(Review Form) ;查检表(Checklist) 。 · 指定评审专家(3-6 人) ; · 组织者将评审包、评审通知单发给相关人员。 7、 介绍会议: · 被评审对象采用新技术、新方法; 被评审对象第一次被评审 ?(作者介绍被 · 审对象以及相关技术) · 评审专家第一次参加评审 ? (评审者介绍评审流程) · 介绍会议的召开距接到评审通知的时间大于 5 小时; · 介绍会议的时间不超过 1 小时,30-60 间为宜,关注讲解。 8、 准备阶段: (最重要、发现缺陷最多) · 评审专家个人独立完成工作产品的审视,提出缺陷; · 准备时间 大于 会议时间,且应于会议前 2 天开始; · 评审者:收到组织者发来的评审包;审核工作产品、发现缺陷;填写评审表单; 反馈评审表单给组织者; 组织者:检查评审表单;裁决是否需要增加评审评审投入(增加准备时间;增加 评审专家人数;更换评审专家) 9、 会议阶段(2 小时内;只提出问题,不关注解决) : · 组织者召开评审会议; · 讲解员讲解工作产品; (尽量不要由作者兼任) · 大家共同确认问题(评审表单中记录的问题;会上发现的问题;当争执不 下时组织者应做出裁决) · 对已确认的问题进行分类; · 作者决定是否召开第三小时会议; · 记录员记录所有的问题及分类,并发给组织者; (记录员尽量不要由作者和组织 者担任) · 组织者更新评审表单。 10、 第三小时会议 · 有争议的问题继续讨论,给出决议; · 讨论解决问题方案; · 组织者更新评审表单。 返 工:发回作者修改;

11、

52

[键入文字]

12、

跟 · · · ·

踪: 汇总所有需要的数据到评审表单发给相关评审专家; (?2 组织者) 组织评审专家确认各缺陷得到了修改,并且没有引入新的缺陷; 协助组织者确认相关问题得到了正确修改并且没有引入新的缺陷; 确认评审表单中各相关度量数据正确(发现缺陷数;评审投入时间;评审专 家人数等) (评审专家?2)

53

[键入文字]

配 置 & 需 求 管 理
1、 配置管理的目的和意义: 目的:a. 可视性:用户/买方/卖方详细知道工作内容; b. 管理层能够知道产品特性; c. 所有的项目参与者在同一平台下交流; d. 了解现在和计划的配置; e. 管理层可看到变更的影响; f. 管理层可选择参与的节点; 目标: 意义: 项目:减少返工,减少工作量; 公司:节约成本,积累项目财富; 可视性提高; 项目可跟踪性高; 2、 配置、基线、版本各自定义及关系: 配 置:是软件生命周期个阶段产生的程序、数据、文件、环境的集合; 配置项:是软件生命周期个阶段产生的程序、数据、文件、环境 基 线:配置项在其生命周期的不同时间点上通过评审而进入正式受控的一种状 态,而这个过程被称为“基线化” ; 版 本:是表示一个配置项具有一组定义的功能的一种标识; 3、 变更控制的流程(各种角色、职责输出) : · 项目成员、客户代表、市场人员提交 CR · CMO 将 CR 状态表示为已提交,并将 CR 根据条件进行判断,把不需要 CCB 进行审核的、决定采纳的 CR 直接进行签发;把不需要 CCB 进行审核的、不决 定采纳的 CR 直接关闭(4 CMO 将 CR 状态标识为已拒绝) ;将需要 CCB 评审 的 CR 提交给 CCB 进行评估; · CCB 召开会议对 CR 进行评估 · CMO 将 CR 状态标识为已接受,将 CR 于要修改的配置项发给项目组成员并开

54

[键入文字]

放 CI 的配置库权限 · 项目组成员执行更改并进行验证 · CCB 召开会议对修改进行审核, 如果通过将 CR 状态表示为已验证, 发给 CMO, 否则直接关闭,并给出提交人反馈信息 4、 配置管理中测试工程师的职责: · 测试工程师将自己创建的与测试相关配置项 (比如软件测试计划、 软件测试方案、 软件测试用例、软件测试日报、软件测试报告等)加入配置库中; · 测试工程师根据变更请求, 对已经基线化的配置项进行 Check-Out、 修改、 Check-In 操作。 比如,在测试执行之前,需要更新测试用例, 此时需要经过 CMO 的授权, 然后由测试人员对相应的配置项(测试用例文件)Check-Out、修改、Check-In 5、 需求跟踪涉及到的配置项
分配需求 SRS HLD LLD CODE

ST 文档

IT 文档

UT 文档

6、 配置项的跟踪矩阵 Input————————————Task————————————Output

SOW or AR RTM Form

初始化 RTM

初始的 RTM

准备基线化的文 档、代码 更新 RTM 对于已经基线化 的 SRS、设计文 档、代码、测试 文档等的 CRS 更新后的 RTM

55

[键入文字]

缺 陷 管 理
1、 缺陷管理的目的: 保证信息的一致性;保证缺陷得到有效跟踪,解决; · · 获取正确的 Bug 信息,用作缺陷分析和产品度量。 2、 缺陷的相关属性: 缺陷发现人(Defect Reporter) · ; · 缺陷发现时间(Defected on Date) ; · 缺陷状态(Status) ; · 缺陷严重程度(Sewrity) ; · 缺陷所属版本(Defected in Version) ; · 优先级(Priority) · 缺陷修改日期(Fixed on Date) ; · 再现性(Reproducible) ; · 回归测试(Regression) ; 3、 缺陷管理流程: (参考缺陷管理作业)

56

[键入文字]

4、 缺陷跟踪单写作准则(5C) · Correct(准确) ,每个组成部分的描述准确,不会引起误会; · Clear(清晰) ,每个组成部分的描述清晰,易于理解; · Concise(简洁) ,只包含必不可少的信息,不包括任何多余的内容; · Complete(完整) ,包含复现该缺陷的完整步骤和其他本质信息; · Consistent(一致) ,按照一致的格式书写全部缺陷报告。 5、 缺陷跟踪单基本内容: (其他相关属性) ;简单描述;详细描述;相关附件。 6、 QC 中缺陷管理流程: (实际流程应参考各公司内部流程或者书本) 1. Qatester 提交一个状态为 new 的新缺陷后 assigned to PM 2. PM 查看该缺陷,并判断是否为缺陷需要修改 : n? 在 comments 中记录否决意见后 closed; y? 在 comments 中记录相关意见后将该缺陷指派给相关 开发人员,并将 status 置为 open/reopen 3. Developer 打开缺陷模块,看到指派给自己的缺陷后确定是否修改: n? 在 comments 中记录意见后 rejected to PM?2 y? 修改该缺陷,并将 status 置为 fixed 指给 PM 4. PM 将该缺陷指派给 Qatester 进行回归测试 5. Qatester 看到指派给自己的 fixed 的缺陷后,进行回归测试,通过? y? closed; n? rejected 给 PM?2 7、缺陷度量—评价软件技术/流程/组织指标的公式 ? 分析指标 1. 反映产品质量的指标 缺陷密度=缺陷数量/软件规模(千行代码数) 潜在缺陷概数=(100%-发布前缺陷的缺陷去除率)*缺陷密度 2. 反映产品可靠性的指标 平均实效时间=软件持续运行时间/缺陷数量 3. 反映缺陷发现及修复效率的指标 缺陷检出率=某阶段发现的缺陷/属于该阶段的全部缺陷*100% 发布前缺陷去除率=发布前发现的缺陷/ 发布前发现的缺陷+软件运行 ( 前三个月)*100%

57

[键入文字]

?

缺陷修正率=修复过程中未引发其他问题的缺陷数/被修复缺陷的总数 *100% 4. 反映缺陷修复成本的指标 平均修复时间=∑缺陷修复时间/缺陷数量 平均修复成本=开发人员的平均人力成本*平均修复时间 相对返回成本=返工的工作量/项目总工作量*100% 汇总统计 1.缺陷发生的日期统计(缺陷发现趋势图) 2.缺陷性质统计(缺陷变更,需求变更) 3.缺陷状态分布(关闭,修复中,挂起等) 4.缺陷按子系统(模块)分类统计 5.缺陷引发原因分类统计 6.缺陷来源统计(缺陷提交人或提交方)

58

[键入文字]

SQL SERVER(需搭建 SQL SERVER 环境)
? 数据定义语言(DDL)
? Create table 创建数据库的表 ? Create index 创建数据库表的索引 ? Drop table 删除数据库表 ? Drop index 删除数据库表的索引 ? Truncate table 删除表的所有行 ? Alter table 修改表:增加表列、重定义表列、更改存储分配等 ? Alter table add constraint 在已有的表上增加约束

? 数据操作语言 DML
? Insert 增加数据行 ? Delete 从表里删除行 ? Update 更改表中数据 ? Select 从表或视图中检索数据行 ? 数据控制语言 DCL ? Grant 将权限或角色授予用户或其他角色 ? Revoke 从用户或数据库角色回收权限 ? Set role 禁止或允许一个角色 数据库事务控制 ? Commit work 把当前事务所作的更改永久化(写入磁盘) ? Rollback 作废上次提交以来的所有更改

?

?

Where 语句中的通配符:Select * from objects where object_namelike ?sql#_m_il? escape ?#?

? 字符类型转换: 例:convert(varchar(5),@varage) ? 汇总函数
? ? ? ? 平均值 avg 总和 sum 最小值 min 最大值 max

59

[键入文字]

? 计数 count ? Count(*)和 count (distinct )

? Insert 语句
? Insert into 表名(列名 1,n)value (值 1,n) ? Insert into student values (20051115,?黄飞鸿?,?男?,21,?cs?) ? Insert into student(sname,sno,sdept) value(?刘德华?,20055567,?cs?) ? 未指明的字段内容为 null ? Insert into 表名(列名 1,n)select 语句;如: ? Insert into student2(sno,sname,sdept) select sno,sname,sdeptfrom student1 ? 前提是两个表的结构相同

? Update 语句
?Update 表名 set 列名 1=表达式 1,列名 2=表达式 2.. Where 条件 ?Update student set sdept= ?MA?where sno= ?95001? ?所有学生年龄加 1 ?Update student set sage = sage+1 ?该语句只对单个表操作,不能同时对多表操作 ?该语句仅当事务提交(commit)后才生效;也可通过事务回滚 rollback 来作废操作

? 在 SQL Server 2000 中有 5 种约束:
主键约束(primary key constraint) 唯一性约束(unique constraint) 检查约束(check constraint) 缺省约束(default constraint) 外部键约束(foreign key constraint)

? 课程实例:
---创建表"订单 A" create table 订单 A(订单编号 int not null, 下单日期 datetime not null, 客户编号 int not null) select * from 订单 A

60

[键入文字]

---首先添加订单名称,varchar(20),null alter table 订单 A add 订单名称 varchar(20) null select * from 订单 A ---之后删除订单名称字段 alter table 订单 A drop column 订单名称 select * from 订单 A

---然后同时添加订单名称,varchar(20),null 和定购数量,int,null alter table 订单 A add 订单名称 varchar(20) null,订购数量 int null select * from 订单 A

---然后尝试同时修改订单名称的字段长度为 50,定购数量数据类型为 numeric* 不 能同时修改* alter table 订单 A alter column 订单名称 varchar(50) null select * from 订单 A alter column 订单名称 varchar(50) null 订购数量 numeric

---最后同时删除订单名称和定购数量 alter table 订单 A drop column 订单名称,订购数量 select * from 订单 A

---向已有表"订单 A"的订单编号字段添加主键约束 alter table 订单 A add constraint 订单编号_k primary key (订单编号) select * from 订单 A

61

[键入文字]

---创建"定购项目"表,并同时添加项目编号字段为主键 create table 订购项目(订单编号 int not null, 项目编号 int not null, 书籍编号 int not null, 数量 int not null, primary key (项目编号)) select * from 订购项目 ---向已有表"定购项目"添加新字段"项目名称"和"客户名称",并设置项目名称字段为 唯一键 alter table 订购项目 add 项目名称 varchar(20),客户名称 varchar(20) constraint 项目名称_u unique (项目名称) select * from 订购项目

---在现有表"定购项目"上设置"客户名称"为唯一键 alter table 订购项目 add constraint 客户名称_u unique (客户名称)

---设置数量字段必须在 10 到 100 之间 alter table 订购项目 add constraint chk_数量 check (数量 between 10 and 100) insert into 订购项目 values(1,2,3,4,'张三','李四') ---检测数量字段的约束条件是否成立 create table sincky(myid int identity(10,1) not null, ---通过函数实现自动增量 yourid varchar(10))

---添加"定购地点"字段,默认值是"上海" alter table 订购项目

62

[键入文字]

add 订购地点 varchar(50) null default '上海' create table 书籍(书籍编号 int not null primary key, 书籍名称 varchar(50) null, 价格 smallmoney null, 出版公司 char(20))

---设置缺省约束

alter table 订购项目 add constraint 订单项目_f foreign key (书籍编号) references 书籍(书籍编号)

63

[键入文字]

存储过程:

if exists (select * from sysobjects where name='sinckypro' and type='p') drop procedure sinckypro go

create procedure sinckypro @varname varchar(50),@varage int as declare @inname varchar(50) set @inname = 'sincky_'+ @varname create table testtable(myid int not null primary key, myname varchar(50) not null, mypasswd varchar(20) not null, myage int default 25)

insert into testtable values(1,@inname,'zhang',@varage) select * from testtable drop table testtable go

exec sinckypro '51testing',55

64

[键入文字]

测试工具总结
测试工具大全 工 具 类 别 Winrunner Quicktest pro Xrunner QARun TestPartner WebKing Robot Visual Test 通 用 功 能 自 动 化 测 试 工 具 Functional Tester SilkTest SilkTest International e-Tester WebFT TestComplete QA Wizard Software EggPlant Test Edition PureTest Autotester Testbench400 TestExpert TestRunner TTCN suite QC/Replay Web Mercury Mercury Mercury Compuware Compuware Parasoft IBM Rational IBM Rational IBM Rational Segue Segue Empirix Radview AutomatedQA Seapine RedStone Microsoft Visual Studio Minq Autotester Original Software VEReCOMM Qronus Telelogic Centerline AutoTester http://www.telelogic.com.cn http://www.parasoft.com http://www.ibm.com/cn http://www.ibm.com/cn http://www.ibm.com/cn 工具名称 生产厂商 相关网站

65

[键入文字]

eValid WebART MaxQ WebInject Marathon LoadRunner SiteScope Topaz QaLoad PerformaSure/benchmark Silkperformer Silkperformer Lite SilkCentralTM Performance 性 能 测 试 / 监 控 工 具 Manager e-Load Robot Performance Tester WebLoad Web applicaton stress tool Application center test PureLoad Athene APR ForeCast Impact/Impact for CBT Berkeley Laboratory sniffer Jmeter openSTA Siege StressMark DBMonster 白 盒 VcTester Jtest

Software Research OCLC 开源 开源 开源 Mercury Mercury Mercury Compuware Quest Segue Segue Segue Empirix IBM Rational IBM Rational RadView Microsoft Microsoft Minq Metron Facilita Cyrano Lawrence 开源 开源 开源 开源 开源 ezTester Parasoft http://www.eztester.com http://www.parasoft.com http://www.ibm.com/cn http://www.ibm.com/cn

66

[键入文字]

测 试 / 代 码 分 析 工 具

C++test SOA test .test Codewizard Insure++ DataRecon Numega devpartner studio DevPartnerJavaEdition BoundsChecker SmartCheck DBPartner Bean-test Aqtime QESatJava Visual Unit PC-lint Macabe Optimizeit Suite JProbe Suite Application assurance suite Sql optimizer Jprofiler workbench Logiscope rulecheck SilkPerformer Component Test Edition Purifyplus Rational Test Realtime junit cactus

Parasoft Parasoft Parasoft Parasoft Parasoft Parasoft Compuware Compuware Compuware Compuware Compuware Empirix AutomatedQA AutomatedQA Unitware Gimpel Software Macabe Borland Quest Software Quest Software Quest Software ej-technologies Cyrano TeleLogic TeleLogic Segue IBM rational IBM rational 开源 开源

http://www.parasoft.com http://www.parasoft.com http://www.parasoft.com http://www.parasoft.com http://www.parasoft.com http://www.parasoft.com

http://www.telelogic.com.cn http://www.telelogic.com.cn

http://www.ibm.com/cn http://www.ibm.com/cn

67

[键入文字]

Hansel TestNG StrutsTestCase JFCUnit Httpunit Dunit cppunit Nunit Xunit JTR MallocDebug Valgrind Kcachegrind dmalloc ElectricFence LeakTracer memprof ccmalloc mprof yamd njamd mpatrol VcTester codetest 嵌 入 式 测 试 工 具 System test scorecast Testquest UniText vectorcast Cantata/cantana++ IceMaster

开源 开源 开源 开源 开源 开源 开源 开源 开源 开源 Linux 平台工具 Linux 平台工具 Linux 平台工具 Linux 平台工具 Linux 平台工具 Linux 平台工具 Linux 平台工具 Linux 平台工具 Linux 平台工具 Linux 平台工具 Linux 平台工具 Linux 平台工具 ezTester Metrowerks IPL Reflex Technology Reflex Technology DDC-I Testquest ATTOL Vector software http://www.eztester.com

http://sourceforge.net/project

68

[键入文字]

testrunner Logiscope TestDirector(QualityCenter) QADirector 测 试 管 理 工 具 certify Product manager SilkCentral Test Manager Doors e-manager testmanager TestView Manager Professional TestDirector(QualityCenter) ClearQuest TrackRecord TestTrack pro TrueTrack 缺 陷 管 理 工 具 Devtrack Notes SilkCentral Issue Manager PVCS Tracker AR System URTrack Butterfly Bugzilla Mantis JIRA BugFree 配 置 管 ClearCase PVCS Version Manager VCS

Qronus Telelogic Mercury Compuware Worksoft Aimware Segue Telelogic Empirix IBM Rational RadView T-Plan Mercury IBM Rational Compuware Seapine McCabe Techexcel IBM Lotus Segue Merant Remedy LealSoft Hansky 开源 开源 开源 开源 IBM Rational Merant Diamond http://www.ibm.com/cn http://www.ibm.com/cn http://www.ibm.com/cn http://www.telelogic.com.cn http://www.telelogic.com.cn

69

[键入文字]

理 工 具

StarTeam Perforce TRUEchange SYNERGY CM VSS Firefly CVS SCCS CCC/Harvest

Borland Perforce McCabe Telelogic Microsoft Hansky Subversion RCS Computer Associates http://www.telelogic.com.cn

测试工具部分详解 随着软件测试的地位逐步提高,测试的重要性逐步显现,测试工具的应用已经成为 了普遍的趋势。目前用于测试的工具已经比较多了,这些测试工具一般可分为白盒 测试工具、黑盒测试工具、性能测试工具,另外还有用于测试管理(测试流程管理、 缺陷跟踪管理、测试用例管理)的工具。 总的来说,测试工具的应用可以提高测试的质量、测试的效率。但是在选择和使用 测试工具的时候,我们也应该看到,在测试过程中,并不是所有的测试工具都适合 我们使用,同时,有了测试工具、会使用测试工具并不等于测试工具真正能在测试 中发挥作用。 ? Win Runner 1. 简介 WinRunner:强大的企业级自动化测试工具 Mercury Interactive 公司的 WinRunner 是一种企业级的功能测试工具, 用于检测应用 程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用 操作,WinRunner 能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行 测试,提高测试人员的工作效率和质量,确保跨平台的、复杂的企业级应用无故障 发布及长期稳定运行。 企业级应用可能包括 Web 应用系统,ERP 系统,CRM 系统等等。这些系统在发布 之前,升级之后都要经过测试,确保所有功能都能正常运行,没有任何错误。如何 有效地测试不断升级更新且不同环境的应用系统,是每个公司都会面临的问题。

70

[键入文字]

如果时间或资源有限,这个问题会更加棘手。人工测试的工作量太大,还要额外的 时间来培训新的测试人员等等。为了确保那些复杂的企业级应用在不同环境下都能 正常可靠地运行,你需要一个能简单操作的测试工具来自动完成应用程序的功能性 测试。 2. 特征: 1) 轻松创建测试

用 WinRuuner 创建一个测试, 只需点击鼠标和键盘, 完成一个标准的业务操作流程, WinRunner 自动记录你的操作并生成所需的脚本代码。这样,即使计算机技术知识 有限的业务用户轻松创建完整的测试。你还可以直接修改测试脚本以满足各种复杂 测试的需求。WinRunner 提供这两种测试创建方式,满足测试团队中业务用户和专 业技术人员的不同需求。 2) 插入检查点

在记录一个测试的过程中,可以插入检查点,检查在某个时刻/状态下,应用程序是 否运行正常。在插入检查点后,WinRunner 会收集一套数据指标,在测试运行时对 其一一验证。WinRunner 提供几种不同类型的检查点,包括文本的、GUI、位图和 数据库。例如,用一个位图检查点,你可以检查公司的图标是否出现于指定位置。 3) 检验数据

除了创建并运行测试,WinRunner 还能验证数据库的数值,从而确保业务交易的准 确性。例如,在创建测试时,可以设定哪些数据库表和记录需要检测;在测试运行 时,测试程序就会自动核对数据库内的实际数值和预期的数值。WinRunner 自动显 示检测结果,在有更新/删除/插入的记录上突出显示以引起注意。 4) 增强测试

为了彻底全面地测试一个应用程序,需要使用不同类型的数据来测试。WinRunner 的数据驱动向导( Data Driver Wizard)可以让你简单地点击几下鼠标,就可以把一个 业务流程测试转化为数据驱动测试,从而反映多个用户各自独特且真实的行为。

71

[键入文字]

以一个订单输入的流程为例,你可能希望把订单号或客户名称作为可变栏,用多套 数据进行测试。使用 Data Driver Wizard,你可以选择订单号或客户名称用数据表格 文件中的哪个栏目的数据替换。你可以把订单号或客户名称输入数据表格文件,或 从其它表格和数据库中导入。数据驱动测试不仅节省了时间和资源,又提高了应用 的测试覆盖率。 WinRunner 还可以通过 Function Generator 增加测试的功能。 使用 Function Generator 可以从目录列表中选择一个功能增加到你的测试中以提高测试能力。例如,你可以 选择”calendar” ,然后从日历功能的下属目录中选择,如 Calendar_select_date(),然 后你可以直观地输入参数,把这个功能插入到你的测试中。 针对相当数量的企业应用里非标准对象,WinRunner 提供了 Virtual Object Wizard 来 识别以前未知的对象。使用 Virtual Object Wizard,你可以选择未知对象的类型,设 定标识和命名。在录制使用该对象的测试时,WinRunner 会自动对应它的名字,从 而提高测试脚本的可读性和测试质量。 5) 运行测试

创建好测试脚本,并插入检查点和必要的添加功能后,你就可以开始运行测试。运 行测试时,WinRunner 会自动操作应用程序,就象一个真实的用户根据业务流程执 行着每一步的操作。 测试运行过程中, 如有网络消息窗口出现或其它意外事件出现, WinRunner 也会根据预先的设定排除这些干扰。 6) 分析结果

测试运行结束后,你需要分析测试结果。WinRunner 通过交互式的报告工具来提供 详尽的、易读的报告。报告中会列出测试中发现的错误内容、位置、检查点和其它 重要事件,帮助你对测试结果进行分析。这些测试结果还可以通过 Mercury Interactive 的测试管理工具 TestDirector 来查阅。 7) 维护测试

随着时间的推移, 开发人员会对应用程序做进一步的修改, 并需要增加另外的测试。 使用 WinRunner,你不必对程序的每一次改动都重新创建你的测试。WinRunner 可 以创建在整个应用程序生命周期内都可以重复使用的测试,从而大大地节省时间和

72

[键入文字]

资源,充分利用你的测试投资。 每次记录测试时,WinRunner 会自动创建一个 GUI Map 文件以保存应用对象。这些 对象分层次组织,既可以总览所有的对象,也可以查询某个对象的详细信息。一般 而言,对应用程序的任何改动都会影响到成百上千个测试。通过修改一个 GUI Map 文件而非无数个测试,WinRunner 可以方便地实现测试重用。 8) 帮助你的应用程序为无线应用作准备

随着无线设备种类和数量的增加,你的应用程序测试计划需要同时满足传统的基于 浏览器的用户和无线浏览设备,如移动电话、传呼机和个人数字助理(PDA)。 无线应用协议是一种公开的、全球性的网络协议,用来支持标准数据格式化和无线 设备信号的传输。 使用 WinRunner,测试人员可以利用微型浏览模拟器来记录业务流程操作,然后回 放和检查这些业务流程功能的正确性。 ? LoadRunner 1. 简介:

LoadRunner 是一种预测系统行为和性能的负载测试工具。 通过以模拟上千万用户实 施并发负载及实时性能监测的方式来确认和查找问题, LoadRunner 能够对整个企业 架构进行测试。通过使用 LoadRunner ,企业能最大限度地缩短测试时间,优化性 能和加速应用系统的发布周期。 目前企业的网络应用环境都必须支持大量用户,网络体系架构中含各类应用环境且 由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境 使公司时时担心会发生用户响应速度过慢,系统崩溃等问题。这些都不可避免地导 致公司收益的损失。 Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来 源,无需购置额外硬件而最大限度地利用现有的 IT 资源,并确保终端用户在应用 系统的各个环节中对其测试应用的质量,可靠性和可扩展性都有良好的评价。 LoadRunner 是一种适用于各种体系架构的自动负载测试工具, 它能预测系统行为并 优化系统性能。 LoadRunner 的测试对象是整个企业的系统, 它通过模拟实际用户的

73

[键入文字]

操作行为和实行实时性能监测, 来帮助您更快的查找和发现问题。 此外, LoadRunner 能支持广范的协议和技术,为您的特殊环境提供特殊的解决方案。 2. 1) 特征: 轻松创建虚拟用户

使用 LoadRunner 的 Virtual User Generator,您能很简便地创立起系统负载。该引擎 能够生成虚拟用户,以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下 业务流程(如下订单或机票预定),然后将其转化为测试脚本。利用虚拟用户,您可 以在 Windows ,UNIX 或 Linux 机器上同时产生成千上万个用户访问。所以 LoadRunner 能极大的减少负载测试所需的硬件和人力资源。另外,LoadRunner 的 TurboLoad 专利技术能。 提供很高的适应性。TurboLoad 使您可以产生每天几十万名在线用户和数以百万计 的点击数的负载。 用 Virtual User Generator 建立测试脚本后,您可以对其进行参数化操作,这一操作 能让您利用几套不同的实际发生数据来测试您的应用程序,从而反映出本系统的负 载能力。以一个订单输入过程为例,参数化操作可将记录中的固定数据,如订单号 和客户名称,由可变值来代替。在这些变量内随意输入可能的订单号和客户名,来 匹配多个实际用户的操作行为。 LoadRunner 通过它的 Data Wizard 来自动实现其测试数据的参数化。Data Wizard 直接连于数据库服务器,从中您可以获取所需的数据(如定单号和用户名)并直接 将其输入到测试脚本。这样避免了人工处理数据的需要,Data Wizard 为您节省了 大量的时间。 为了进一步确定您的 Virtual user 能够模拟真实用户,您可利用 LoadRunner 控制某 些行为特性。例如,只需要点击一下鼠标,您就能轻易控制交易的数量,交易频率, 用户的思考时间和连接速度等。 2) 创建真实的负载

Virtual users 建立起后,您需要设定您的负载方案,业务流程组合和虚拟用户数量。

74

[键入文字]

用 LoadRunner 的 Controller,您能很快组织起多用户的测试方案。Controller 的 Rendezvous 功能提供一个互动的环境,在其中您既能建立起持续且循环的负载, 又 能管理和驱动负载测试方案。 而且,您可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。 这样,您就能将测试过程自动化。同样您还可以用 Controller 来限定您的负载方案, 在这个方案中所有的用户同时执行一个动作---如登陆到一个库存应用程序----来模 拟峰值负载的情况。另外,您还能监测系统架构中各个组件的性能---- 包括服务器, 数据库,网络设备等----来帮助客户决定系统的配置。 LoadRunner 通过它的 AutoLoad 技术,为您提供更多的测试灵活性。使用 AutoLoad ,您可以根据目前的用户人数事先设定测试目标,优化测试流程。例如, 您的目标可以是确定您的应用系统承受的每秒点击数或每秒的交易量。 3) 定位性能问题

LoadRunner 内含集成的实时监测器, 在负载测试过程的任何时候, 您都可以观察到 应用系统的运行性能。这些性能监测器为您实时显示交易性能数据(如响应时间) 和其它系统组件包括 application server, web server,网路设备和数据库等的实时性 能。这样,您就可以在测试过程中从客户和服务器的双方面评估这些系统组件的运 行性能,从而更快地发现问题。 再者,利用 LoadRunner 的 ContentCheck TM ,您可以判断负载下的应用程序功能 正常与否。 ContentCheck 在 Virtual users 运行时, 检测应用程序的网络数据包内容, 从中确定是否有错误内容传送出去。它的实时浏览器帮助您从终端用户角度观察程 序性能状况。 4) 分析结果以精确定位问题所在

一旦测试完毕后, LoadRunner 收集汇总所有的测试数据, 并为您提供高级的分析和 报告工具,以便迅速查找到性能问题并追溯原由。使用 LoadRunner 的 Web 交易细 节监测器, 您可以了解到将所有的图象、 框架和文本下载到每一网页上所需的时间。 例如,这个交易细节分析机制能 够分析是否因为一个大尺寸的图形文件或是第三方的数据组件造成应用系统运行速

75

[键入文字]

度减慢。另外,Web 交易细节监测器分解用于客户端、网络和服务器上端到端的反 应时间,便于确认问题,定位查找真正出错的组件。例如,您可以将网络延时进行 分解,以判断 DNS 解析时间,连接服务器或 SSL 认证所花费的时间。通过使用 LoadRunner 的分析工具,您能很快地查找到出错的位置和原因并作出相应的调整。 5) 重复测试保证系统发布的高性能

负载测试是一个重复过程。每次处理完一个出错情况,您都需要对您的应用程序在 相同的方案下, 再进行一次负载测试。 以此检验您所做的修正是否改善了运行性能。 6) Enterprise Java Beans 的测试

LoadRunner 完全支持 EJB 的负载测试。这些基于 Java 的组件运行在应用服务器 上,提供广泛的应用服务。通过测试这些组件,您可以在应用程序开发的早期就确 认并解决可能产生的问题。 利用 LoadRunner, 您可以很方便地了解系统的性能。 它的 Controller 允许您重复执 行与出错修改前相同的测试方案。它的基于 HTML 的报告为您提供一个比较性能 结果所需的基准,以此衡量在一段时间内,有多大程度的改进并确保应用成功。由 于这些报告是基于 HTML 的文本,您可以将其公布于您公司的内部网上,便于随 时查阅。 7) 最大化投资回报 所有 Mercury Interactive 的产品和服务都是集成设计的, 能完全相容地一起运作。 由于它们具有相同的核心技术,来自于 LoadRunner 和 ActiveTest TM 的测试脚本, 在 Mercury Interactive 的负载测试服务项目中,可以被重复用于性能监测。借助 Mercury Interactive 的监测功能--Topaz TM 和 ActiveWatch TM ,测试脚本可重 复使用从而平衡投资收益。更重要的是,您能为测试的前期布署和生产系统的监测 提供一个完整的应用性能管理解决方案。

8)

支持无线应用协议

随着无线设备数量和种类的增多,您的测试计划需要同时满足传统的基于浏览器的 用户和无线互联网设备, 如手机和 PDA。 LoadRunner 支持 2 项最广泛使用的协议:

76

[键入文字]

WAP 和 I-mode。此外,通过负载测试系统整体架构,LoadRunner 能让您只需要通 过记录一次脚本,就可完全检测上述这些无线互联网系统。 9) 支持 Media Stream 应用

LoadRunner 还能支持 Media Stream 应用。为了保证终端用户得到良好的操作体验 和高质量 Media Stream, 您需要检测您的 Media Stream 应用程序。 使用 LoadRunner , 您可以记录和重放任何流行的多媒体数据流格式来诊断系统的性能问题, 查找原由, 分析数据的质量。 10) 完整的企业应用环境的支持 LoadRunner 支持广泛的协议,可以测试各种 IT 基础架构。 ? WAS 1. 简介:

Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发,专门用来进 行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具,您可以使用 少量的 Client 端计算机仿真大量用户上线对网站服务所可能造成的影响。 2 特征:

1)可以数种不同的方式建立测试指令:包含以手动、录制浏览器操作步骤、或直接 录入 IIS 的记录文件、录入网站的内容及录入其它测试程序的指令等方式。 2) 支持多种客户端接口: 标准的网站应用程序 C++的客户端, 使用 Active Server Page 客户端,或是使用 Web Application Stress 对象模型建立您自定的接口。 3)支持多用户:利用多种不同的认证方式仿真实际的情况,包含了 DPA, NTLM 及 SSL 等。 ? JTEST 1、简介:

77

[键入文字]

jtest 是 parasoft 公司推出的一款针对 java 语言的自动化白盒测试工具,它通过自动实 现 java 的单元测试和代码标准校验,来提高代码的可靠性。Jtest 先分析每个 java 类, 然后自动生成 junit 测试用例并执行用例,从而实现代码的最大覆盖,并将代码运行 时未处理的异常暴露出来;另外,它还可以检查以 DbC(Design by Contract)规范 开发的代码的正确性。用户还可以通过扩展测试用例的自动生成器来添加更多的 junit 用例。Jtest 还能按照现有的超过 350 个编码标准来检查并自动纠正大多数常见 的编码规则上的偏差,用户可自定义这些标准,通过简单的几个点击,就能预防类 似于未处理异常、函数错误、内存泄漏、性能问题、安全隐患这样的代码问题。 2、优势: 1)使预防代码错误成为可能,从而大大节约成本,提高软件质量和开发效率 2)使单元测试——包括白盒、黑盒以及回归测试成为可能 3)使代码规范检查和自动纠正成为可能 4)鼓励开发团队横向协作来预防代码错误 3、特征: 1)通过简单的点击,自动实现代码基本错误的预防,这包括单元测试和代码规范的 检查 2)生成并执行 junit 单元测试用例,对代码进行即时检查 3)提供了进行黑盒测试、模型测试和系统测试的快速途径 4)确认并阻止代码中不可捕获的异常、函数错误、内存泄漏、性能问题、安全弱点 的问题 5)监视测试的覆盖范围 6)自动执行回归测试 7)支持 DbC 编码规范 8)检验超过 350 个来自 java 专家的开发规范 9)自动纠正违反超过 160 个编码规范的错误 10)允许用户通过图形方式或自动创建方式来自定义编码规范 11)支持大型团队开发中测试设置和测试文件的共享 12)实现和 IBM Websphere Studio /Eclipse IDE 的安全集成 4、价格:昂贵

? JMETER

78

[键入文字]

1、简介: JMeter 是 Apache 组织的开放源代码项目,它是功能和性能测试的工具,100%的用 java 实现。使用 JMeter 进行性能测试 2、特征: JMeter 可以用于测试静态或者动态资源的性能(文件、Servlets、Perl 脚本、java 对 象、数据库和查询、ftp 服务器或者其他的资源) 。JMeter 用于模拟在服务器、网络 或者其他对象上附加高负载以测试他们提供服务的受压能力,或者分析他们提供的 服务在不同负载条件下的总性能情况。 你可以用 JMeter 提供的图形化界面分析性能 指标或者在高负载情况下测试服务器/脚本/对象的行为。 3、价格:未知

? JUNIT 1、简介: JUnit 是一个开源的 java 测试框架,它是 Xuint 测试体系架构的一种实现。在 JUnit 单元测试框架的设计时,设定了三个总体目标,第一个是简化测试的编写,这种简 化包括测试框架的学习和实际测试单元的编写;第二个是使测试单元保持持久性; 第三个则是可以利用既有的测试来编写相关的测试。 2、优势: 2.1)junit 是完全 Free 的。 2.2)使用方便。在你提升程序代码的品质时 JUnit 测试仍允许你更快速的撰写程序 2.3)JUnit 非常简单撰写测试应该很简单--这是重点!如果撰写测试太复杂或太耗时 间,便无法要求程序设计师撰写测试。使用 JUnit 你可以快速的撰写测试并检测你 的程序代码并逐 步随着程序代码的成长增加测试。 只要你写了一些测试, 你想要快 速并频繁的执行测试而不至于中断建立设计及开发程序。使用 JUnit 执行测试就像 编译你的程序代码那么容易。事实上,你应该执行编译时也执行测试。编译是检测 程序代码的语法而测试是检查程序代码的完整性(integrity)。如果你是以人工比对测 试的期望与实际结果那么测试是很不好玩的, 而且让你的速度慢下来。 JUnit 测试可 以自动执行并且检查他们自己的结果。 当你执行测试, 你获得简单且立即的回馈;比

79

[键入文字]

如测试是通过或失败。 而不再需要人工检查测试结果的报告。 JUnit 可以把测试组织 成测试系列; 这个测试系列可以包含其它的测试或测试系列。 JUnit 测试的合成行为 允许你组合多个测试并自动的回归(regression)从头到尾测试整个测试系列。你也可 以执行测试系列层级架构中任何一层的测试。 使用 Junit 测试框架, 你可以很便宜的 撰写测试并享受由测试框架所提供的信心。 撰写一个测试就像写一个方法一样简单; 测试是检验要测试的程序代码并定义期望的结果。这个测试框架提供自动执行测试 的背景;这个背景并成为其它测试集合的一部份。在测试少量的投资将持续让你从 时间及品质中获得回收。你写的测试愈少;你的程序代码变的愈不稳定。测试使得 软件稳定并逐步累积信心;因为任何变动不会造成涟漪效应而漫及整个软件。测试 可以形成软件的完整结构的胶结。 2.8)JUnit 测试是开发者测试。JUnit 测试是高度 区域性(localized)测试;用以改善开发者的生产力及程序代码品质。不像功能测试 (function test)视系统为一个黑箱以确认软件整体的工作性为主,单元测试是由内而 外测试系统基础的建构区块。开发者撰写并拥有 JUnit 测试。每当一个开发反复 (iteration)完成, 这个测试便包裹成为交付软件的一部份提供一种沟通的方式, 「这是 我交付的软件并且是通过测试的。使用 Java 测试 Java 软件形成一个介于测试及程 序代码间的无缝(seamless)边界。 在测试的控制下测试变成整个软件的扩充同时程序 代码可以被重整。Java 编译器的单元测试静态语法检查可已帮助测试程序并且确认 遵守软件接口的约定。 一段测试的程序代码无法单独的执行,它需要是执行环境的一部份。同时,它需要 自动执行的单元测试--譬如在系统中周期性的执行所有的测试以证明没有任何东西 被破坏。由于单元测试需要符合特定的准则:一个成功的测试不应该是人工检查的 (那可要到天荒地老了啊) ,一个未通过测试的失败应可以产出文件以供诊断修改。 而 Junit 可以提供给我们这些便利.。这样所有测试开发者所需撰写的只是测试码本 身了。跟 optimizeit、Jtest 那些昂贵而又超级麻烦的 tool 比较起来,其利昭然可见! 2.9)JUnit 测试是以 Java 写成的。 2.7)JUnit 测试提升软件的稳定性。 2.6)撰写 JUnit 测试所费不多。 2.5)JUnit 测试可以合成一个测试系列的层级架构。 2.4)JUnit 测试检验其结果并提供立即的回馈。 那听起来似乎不是很直觉, 但那是事 实。当你使用 JUnit 撰写测试,你将花更少的时间除虫,同时对你程序代码的改变 更 俱有信心。这个信心让你更积极重整程序代码并增加新的功能。没有测试,对于 重整及增加新功能你会变得没有信心; 因为你不知道有甚么东西会破坏产出的结果。 采用一个综合的测试系列,你可以在改变程序代码之后快速的执行多个测试并对于 你的变动并未破坏任何东西感到有信心。在执行测试时如果发现臭虫,原始码仍然 清楚的在你脑中,因此很容易找到臭虫。在 JUnit 中撰写的测试帮助你以一种极 大

80

[键入文字]

(extreme)的步伐撰写程序及快速的找出缺点。 3、价格:免费 ? WEBLODE 1、简介: webload 是 RadView 公司推出的一个性能测试和分析工具,它让 web 应用程序开发者 自动执行压力测试;webload 通过模拟真实用户的操作,生成压力负载来测试 web 的性 能。 2、特征: 1) 用户创建的是基于 javas cript 的测试脚本,称为议程 agenda,用它来模拟客户的行 为,通过执行该脚本来衡量 web 应用程序在真实环境下的性能 2)如有需要可以在做负载测试的同时,使用服务器监控工具对服务器端的内容进 行记录那样使负载测试更加全面。

第一阶段英语单词总结
一、Abbreviation 缩写 0、 RTM requirement trace matrix 需求跟踪距阵 1、 SRS software requirement specification 软件需求规格说明书 2、 HLD high level design 概要设计 3、 LLD low level design 详细设计 4、 IPO input process output 输入输出过程 5、 SQA software quality assurance 软件质量保证 6、 CMO configuration management operator 配置管理员 7、 RUP rational unified process 通用业务流程 8、 IPD integrated product development 集成产品开发过程

81

[键入文字]

9、 PDCA plan, do, check, act 质量管理 PDCA 循环 10、 SMART 原则 specification 具体的, related 相关性, measurable 可度量的, time-based 时限性, achievable 可达到性 11、DMAC 原则 define 定义, measure 度量, analysis 分析, check 检查 12、 SEPG software engineer process group 软件工程过程组 13、 SEI software engineer institute 美国软件工程研究所 14、 CCB change control board 变更控制委员会 15、 MTBF mean time between failure 平均失效时间 16、 MTTR mean time to repair 平均故障恢复时间 17、 SDP software development plan 软件开发计划

二、常用术语 1、 Debug 调试 2、 Test case 测试用例 3、 Siral model 螺旋模型 4、 Software life cycle 软件生命周期 5、 Initial 初始级 6、 Repeatable 可重复级 7、 Defined 已定义级 8、 Managed 已管理级 9、 Optimizing 优化级 10、 Suitability 适合性 11、Accuracy 准确性 12、 Interoperability 互操作性 13、 Security 安全性 14、 Functionality compliance 功能性依从性 15、 Maturity 成熟性 16、 Fault tolerance 容错性 17、 Recoverability 易恢复性 18、 Reliability compliance 可靠性的依从性 19、 Understandability 易理解性 20、 Learn ability 易学性 21、 Operability 易操作性 22、 Attractiveness 吸引性

82

[键入文字]

23、 24、 25、 26、 27、 28、 29、 30、 31、 32、 33、 34、 35、 36、 37、 38、 39、 40、 41、 42、 43、 44、 45、 46、 47、 48、 49、 50、 51、 52、 53、 54、 55、 56、 57、

Time behavior 时间特性 Resource utilization 资源利用性 Efficiency compliance 效率依从性 Analyzability 易分析性 Changeability 易改变性 Stability 稳定性 Testability 易测试性 Maintainability compliance 维护行依从性 Adaptability 适应性 installability 安装性 co-existence 共存行 replaceability 易替换性 portability compliance 可移植性的依从性 unit testing 单元测试 integration testing 集成测试 system testing 系统测试 regression testing 回归测试 verification 验证 validation 确认 alpha testing α 测试 beta testing β 测试 top-down testing 自顶向下测试 bottom-up testing 自底向上测试 isolation testing 孤立测试 automates testing 自动测试 artificially testing 人工测试 white box testing 白盒测试 black box testing 黑盒测试 entry criteria 入口准则 exit criteria 出口准则 reviews and audits 评审和审计 work products managed and controlled 可管理和受控的工作产品 documented procedures 书面规程 stub 桩单元 performance testing 性能测试

83

[键入文字]

58、 stress testing 压力测试 59、 volume testing 容量测试 60、 security testing 安全性测试 61、 usability testing 可用性测试 62、 backup testing 备份测试 63、 robustness testing 健壮性测试 64、 documentation testing 文档测试 65、 online help testing 在线帮助测试 66、 statement coverage 语句覆盖 67、 branch coverage 分支覆盖 68、 decision coverage 判断覆盖 69、 condition coverage 条件覆盖 70、 branch conditon coverage 分支条件覆盖 71、 decision condition coverage 判断条件覆盖 72、 path coverage 路径覆盖 73、 function coverage 功能覆盖 74、 inheritance context coverage 继承上下文覆盖 75、 state-based context coverage 基于状态的上下文覆盖 76、 User-defined context coverage 已定义用户上下文覆盖 77、 Instruction blocks coverage IB coverage 指令块覆盖 78、 Decision-to-decision paths coverage DDP coverage 判定路径覆盖 79、 Peer review 同行评审 80、 Walkthrough 走读 81、 Defect 缺陷 82、 Error 错误 83、 Syntax error 语法错误 84、 Logical error 逻辑错误 85、 Fault 故障 86、 Failure 失效 补充中??

84

[键入文字]

复习问题总结
一、测试基础: 1、 测试目的是什么 证明:证明软件的可用性 检测:发现软件中存在的错误 预防:管理软件的质量,可维护性能 2、 软件生命周期中的各个模型及其优缺点 瀑布模型:应用的最为广泛的一种模型,也是最容易理解和掌握的模型,然而它的 缺陷也是显而易见的。 ? 优点: – 强调开发的阶段性 – 强调早期计划及需求调查 – 强调产品测试 ? 缺点: – 依赖于早期进行的需求调查,不能适应需求变化 – 由于是单一流程,开发中的经验教训不能应用于本产品过程 – 测试在后期才参与,前期质量无法保证

85

[键入文字]

螺旋模型:综合了基本的瀑布式模型和演化/渐增原型方法。 ? 优点: – 强调全过程风险管理 – 强调各开发阶段的质量 – 提供机会检讨项目是否有价值继续下去 ? 缺点: – 每个阶段都要提出多个备选方案,并进行充分的风险分析,研发周期长, 效 率低。 – 需要有专门的风险分析人员参与 RUP 流程:所有工作流在各个阶段都有体现。 ? 优点: – 任何功能一经开发就能进入测试以便验证是否符合产品需求 – 在早期对风险进行识别,采取预防措施 – 尽早得到用户的验证 ? 缺点: – 如果需求一开始并不完全弄清楚,会给总体设计带来困难及削弱产品设 计的 完整性。 – 如果缺乏严格的过程管理,就可能退化为原始的无计划的“试—错— 改”模 试。 – 不加控制地让用户接触开发并尚未测试稳定的功能,可能对开发和用户 都会 产生负面的影响 IPD 流程:从整个产品角度出发,不仅仅针对研发。 – 流程是由 IBM 提出来的一套集成产品开发流程,非常适合于复杂的大型 开发项目。从整个产品角度出发,流程综合考虑了从系统工程、研发(硬件、软件、 结构工业设计、测试、资料开发等,制造、财务到市场、采购、技术支援等所有流 程。是一个阶段性模型,具有瀑布模型的影子。 – 通过复杂的流程把一个庞大而又复杂的系统进行分解并降低风险。通 过流程成本来提高整个产品的质量并获得市场的占有。此模式不适合经常变动的需 求,若用此模式开发小型项目,成本消耗非常大。 3、 软件研发中几个重要的过程是什么,每个过程中的主要内容是什么?

86

[键入文字]

需求管理:对软件开发中的需求进行管理,包括需求分配、需求评审、建立需求基 线、需求跟踪、变更控制。 配置管理:配置管理是通过对在软件生命周期的不同的时间点上的软件配置进行标 识,并对这些被标识的软件配置项的更改进行系统控制,从而达到保证 软件产品的完整性和可溯性的过程。 缺陷跟踪:对软件开发过程缺陷的发现、确认、定位、修改、评审、关闭等过程进 行跟踪管理的流程。 同行评审:对于软件工作产品(包括文档、代码、用户手册等) ,组织工作产品作者 的同行来确认是否存在缺陷、是否需要变更的检查方法。 4、 引入缺陷的原因都有哪些? 缺陷引入的原因 : ⑴开发过程缺乏有效的沟通,或者没有进行沟通 ⑵ 软件复杂度越来越高 ⑶ 编程中产生错误 ⑷ 需求不断变更 ⑸ 项目进度的压力 ⑹ 不重视开发文档 ⑺ 软件开发工具本身隐藏的问题 二、软件质量: 1、软件质量分哪几个层次,分别是什么? 1. 符合需求的规格:符合开发者明确定义的目标,即产品是不是符合需求规格。 2. 符合用户显示需求:符合用户所明确说明的目标。 3. 符合用户实际需求:符合用户明确说明的和隐含的目标。 2、影响软件质量的因素有哪些?为什么? 影响软件质量因素主要有: 流程:针对不同的需求选用不同的软件流程模型图。 技术:包括开发技术、测试技术以及美工工艺的技术。 组织:一组特性及特性之间的关系,它提供规定质量需求和评价质量的基础。 ? 流程: 从计划到策略的实现, 流程就是按照这种思维方式指导软件开发的, 并且流程来源于成功的经验, 可以指导项目少走弯路, 从而提高软件质量, 不仅如此,流程还对项目的成本和进度控制有很大的帮助 技术:包括了分析技术、设计技术、编码技术、测试技术,需求是项目的 灵魂,良好的需求分析便是项目成功的关键所在,若是需求分析做不好不

?

87

[键入文字]

可避免的要出现返工;设计,软件的质量是设计出来的,良好的设计基本 上决定了软件产品的最终质量;编码技术产生正确高效的代码;测试是保 证软件的一道防线。所以各种技术对质量来说都是很重要的 ? 组织:好的组织可以有效的促进流程的实施,同时提供员工的发展通道以 吸引更多的人(技术的载体) 总结:质量铁三角互相促进,缺一不可 3、CMM 是什么?CMM 各级的特点 CMM(capabillty Maturity Moelel) 由于美国软件工程研究所(SEI)受美国国防部委托立项。 开发人:Watts Humphrey. 1991 年推出 CMM1.0 版,1993 年提出 CMM1.1 版 现在开发 CMMI(CMM Integration) 软件能力成熟度模型 CMM(提唱过程决定质量)

持续改进过程

5 优化级 关注过程改进

4 已管理级 Managed

可预测的过程 更

量化管理,过程能力可预防性

管理变

标准.一致的过程

3 已定义级 Definded 过程被描述,并得到良好理解

产品过程质量

纪律的过程

2 可重复级 Repeatable 可重复以前的主要经验

集成工程过程

1 初始级 initial 不可预测并且缺控制

88

[键入文字]

项目管理 CMM1 级

特点: (个人英雄主义)
A 项目的成功依赖于一个非常优秀的项目经理的团队。 B 无法重复以往成功的实践。 C 缺乏基本配置管理

可视度:
整个过程不可预测,不可见,不可控。 (过程管理非常混乱) CMM2 级

特点: (有纪律)
能够重复以前成功的经验和实践。 引入合理需求变更(需求管理) 测试与开发分离,整个过程能力可概为有纪律的。

可视度
原始需求——需求分析——设计——编码——测试——产品 CMM3 级

特点: (有过程,经过同行评审)
组织中有一个专门负责组织的标准软件过程。 (SEPG)

可视度
同 CMM2 但整个过程是标准和一致的。 CMM4 级特点

特点: (量化管理)
过程能力是可预防的,因为过程是已测量的并在可测的范围内运行。组织能定量地预测 过程和产品质量方面趋势。软件产品具有可预测的高质量。

可视度
同 CMM3 但整个过程是可预测的。 CMM5 级特点

特点: (改进过程本身)
通过缺陷来发现过程的不足。 新的开发技术触使改进过程。

可视度

89

[键入文字]

同 CMM¥级整个是以改进的。 CMM 的用途: 1 评估供用商的能力; 2 企业的过程改进指南; 3 评估组用来识别组织中的强处和弱点; 4 管理者用来了解其组织的能力,并了解为了提高其能力成熟度而进行软件过程改进所 需要进行的活动; 5 评价组用来识别选择不同的业务承包商的风险和监督合同。 4、软件质量模型是什么? 软件质量模型可分为 6 大模块 27 子模块 ? 功能性 1. 适合性 2. 准确性 3. 互操作性 4. 保密安全性 5. 功能性的依从性 ? 可靠性 1. 成熟性 2. 容错性 3. 易恢复性 4. 可靠性的依从性 ? 易用性 1. 易理解性 2. 易学性 3. 易操作性 4. 吸引性 5. 易用性的依从性 ? 效率 1. 时间性 2. 资源利用性 3. 效率依从性 ? 维护性 1. 易分析性

90

[键入文字]

2. 易改变性 3. 稳定性 4. 易测试性 5. 维护性的依从性 ? 可移植性 1. 适应性 2. 易安装性 3. 共存性 4. 易替换性 5. 可移植性的依从性 5、SQA 和测试的关系是什么? SQA 从过程上保证软件质量 测试从技术上保证软件质量。 6、SQA 的主要工作范围是什么? 1. 保障制度体系顺利执行。 2. 促进过程改进。 3. 指导项目实施。 4. 增强项目的可视度(进度、质量、过程) 。 5. 评审工作产品。 6. 审核工作产品。 (核心工作) 。 7. 协助问题解决。 8. 提供决策支持。 9. 缺陷预防(提高产品质量,降低缺陷发现修复成本) 。 10. 实现质量目标 7、质量管理的 PDCA 循环是什么? 1. Plan 计划 (计划设计) 2. Do 执行 (实施执行) 3. Check 检查 (检查检测) 4. Act 改进 (纠正措施) 8、软件度量的手段是什么? 1. 规模(size) 2. 工作量(effort) 3. 进度(schedule) 4. 质量-缺陷(quality-defect) 三、测试方法:

91

[键入文字]

1、黑盒测试和白盒测试的区别? 黑盒:被测对象当作一个黑盒子,参考与 SRS,站在用户立场上进行测试,方便与 功能测试、验收测试、易用性测试等。 白盒:玻璃盒,基与代码测试,参考与 LLD,HLD 在了解程序的内部数据结构和逻 辑结构的基础上展开的更适合于单元测试、集成测试等。 2、常用的黑盒测试技术有哪些? ? 输入输出:等甲类 边界之 输入域覆盖 输出域覆盖 ? 条件组合:因果图 正交试验 判定法 ? 过程处理: 流程分析 状态迁移 ? 其他: 错误猜测 异常分析 3、常用的白盒测试技术有哪些? ? 静态分析:信息流分析、数据流分析、控制流分析。 ? 动态分析:逻辑覆盖、程序插装。 4、静态测试和动态测试的区别 静态和动态测试的区别是:是否运行被测软件。 5、静态测试的方法有哪些? 上题 6、动态测试的方法有哪些? 上题 7、手工测试和自动化测试的区别? 手工测试:测试活动以及执行由人工来完成。 自动化测试:通过工具模拟人的测试执行,由计算机自动执行。 8、手工测试和自动化测试的优缺点是什么? 手工测试: 自动化测试: 四:测试过程: 1、 系统测试、集成测试和单元测试的区别? 用三种不同角度比较如下表: 阶段 系统测试 集成测试 考察范围 整个系统相对与需 求的符合度 黑盒 测试方法 评估基准 测试用例对需求规 格的覆盖率 接口覆盖率

模 块 间 的 接 口 和 接 灰盒 口的数据传递关系, 以及模块组合后的 整体功能 测试单元内部数据 结构、逻辑控制、异 白盒

单元测试

逻辑覆盖率

92

[键入文字]

常处理等 2、 为什么测试要分阶段进行 虽然在表面看来分阶段测试在成本和进度比不分阶段测试大,但实际测试分阶段进 行原因是各个阶段都有它不同的关注点,这样可以尽早发现缺陷,不会导致因为局 部缺陷导致全局瘫痪。如果不分阶段,那么缺陷的放大效应导致修复成本将变的异 常庞大,修复进度将不可预测。除此之外分阶段测试因为分工明确也会很大程度上 提高产品的质量。 3、 回归测试的策略如何选择? 回归测试的策略主要有:完全重复测试 和选择性重复测试。 完全重复测试:重新执行所有在前期测试阶段建立的测试用例 选择重复测试: 即有选择地重新执行部分在前期测试阶段建立的测试用例,主要测 被修改的程序。 选择重复测试可分为:覆盖修改法、周遍影响法、指标达成法。 根据产品进度、缺陷的严重性以及缺陷发现的阶段性进行选择。 4、 回归测试的自动化什么情况下使用? a) 重复率高。 b) 相对稳定的版本。 c) 手工无法达到的场景模拟。 5、 V&V 模型的特点是什么?与瀑布模型和 H 模型相比有什么优势 a) 实现了测试设计与执行的分离。 b) 测试与开发同步进行,各阶段相对应。 c) 揭示了测试过程分阶段分层的本质 瀑布模型没有实现测试的分阶段和分层, H 模型虽然是开发测试同步进行却没有 而 标明测试与开发各个阶段的对应关系 6、 主要的测试文档有哪些,分别都是什么内容,作用和读者都是什么? 作者 测试计划 测试经理 测试计划人员 内容 测试策略 测试方法 测试项 时间、进度安排 读者 项目经理 开发人员 测试人员 作用 了解测试安排, 掌控项目进度 评审 评审、设计测试 方案及用例的 依据、执行时参 考 度量

SQA

93

[键入文字]

测试方案

测试经理 测试工程师 测试设计人员

测试子项 具体测试方法

测试经理 开发人员 测试人员

评审 评审 评审、设计用例 的依据、执行时 参考 度量 评审 评审 测试执行的依 据 度量 提高测试执行 的效率 了解测试结果 掌握软件的质 量水平 确认缺陷、修改 的依据 判断是否重复 分配缺陷

SQA 测试用例 测试工程师 测试实现人员 编号、标题、输 测试经理 入、处理过程、 开发人员 预期输出等 测试人员 SQA 测试规程 测试报告 测试工程师 测试实现人员 测试工程师 测试执行人员 测试工程师 测试执行人员 测试用例的执 行先后顺序 测试执行情况 记录 测试执行人员 测试经理 项目经理 开发人员 测试经理 项目经理

缺陷报告

7、 系统测试过程各阶段的输入、输出是什么? 系统测试计划阶段输入:软件需求规格说明书、软件测试计划、软件开发计划 输出:系统测试计划 系统测试设计阶段输入:软件需求规格说明书、系统测试计划 输出:系统测试方案 系统测试实现阶段输入:软件需求规格说明书、系统测试计划、系统测试方案 输出:系统测试用例、系统测试规程 系统测试执行阶段输入:系统测试计划、系统测试方案、系统测试用例、系统测试规程 输出:系统测试报告、缺陷报告单 8、 集成测试过程各阶段的输入、输出是什么? 集成测试计划阶段输入:概要设计说明书、软件测试计划 输出:集成测试计划

94

[键入文字]

集成测试设计阶段输入:概要设计说明书、集成测试计划 输出:集成测试方案 集成测试实现阶段输入:概要设计说明书、集成测试计划、集成测试方案 输出:集成测试用例、集成测试规程 集成测试执行阶段输入:集成测试计划、集成测试方案、集成测试用例、集成测试规程 输出:集成测试报告、缺陷报告单 9、 单元测试过程各阶段的输入、输出是什么? 单元测试计划阶段输入:详细设计说明书、软件测试计划 输出:单元测试计划 单元测试设计阶段输入:详细设计说明书、单元测试计划 输出:单元测试方案 单元测试实现阶段输入:详细设计说明书、单元测试计划、单元测试方案 输出:单元测试用例、单元测试规程 单元测试执行阶段输入:单元测试计划、单元测试方案、单元测试用例、单元测试规程 输出:单元测试报告、缺陷报告单 10、需求分析阶段主要的任务是什么? 把用户的需求, 包括显式需求和隐式需求转换为规格化的描述确切的说明文档, 形成 SRS 11、概要设计阶段主要的任务是什么? 把 SRS 中的需求转化为模块化的体系结构,每个模块具有明确的功能 12、详细设计阶段主要的任务是什么? 对每个模块要完成的功能的实现给出具体的描述 13、编码阶段主要的任务是什么? 将设计转换成程序代码 14、单元测试执行阶段阶段主要的任务是什么? 检验被测单元与 LLD 的符合程度 15、集成测试执行阶段主要的任务是什么? 检验被测单元与 HLD 的符合程度 16、系统测试执行阶段主要的任务是什么? 检验被测单元与 SRS 的符合程度 五、系统测试: 1、系统测试的目的是什么? 2、系统测试的类型有哪些? 1) 功能测试

95

[键入文字]

2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15) 16)

性能测试 压力测试 容量测试 安全性测试 可用性测试 GUI 测试 安装测试 配置测试 异常测试 备份测试 健壮性测试 稳定性测试 文档测试 在线帮助测试 网络测试

3、系统测试的用例设计思路是什么? 4、如何保证系统测试用例的完备性? a) 附盖 SRS 中功能来设计用例 b) 从质量模型的不同特性来设计用例 c) 每个测试项目从不同的角度来设计测试数据 六、通用测试用例 1、测试用例模板的要素分别是什么? a) 用例编号 b) 测试项目 c) 测试标题 d) 重要级别 e) 预置条件 f) 输入参数 g) 操作步骤 h) 预期输出 七、同行评审 1、什么叫同行评审? 通过作者的同行来确认产品的缺陷以及变更区域的检查方法

96

[键入文字]

2、同行评审的目的? 发现和排除产品中的缺陷和不足 3、同行评审的流程?

入 口 准 则

计划阶段 出 口 准 则 跟踪阶段 介 绍 会 议?

N Y 介绍会议 返工阶段

N

准备阶段

评审会议

第三小 时 会 议?

Y

第 三 小时 会 议

八、配置管理 1、什么叫配置管理? 对软件生命周期的各个阶段的成果物进行版本控制 2、配置管理的相关术语是什么?

97

[键入文字]

a) 配置 b) 配置项 c) 基线 d) 版本 3、配置管理的目标? a) 保证各个阶段成果物的完整性 b) 保证成果物的可溯性 c) 保证成果物的一致性 d) 使成果物处于受控状态 4、配置管理的流程? 九、需求管理 1、什么叫需求管理? 在项目的研发过程中对需求的跟踪和控制等方面的流程 2、进行需求管理的作用是什么? 3、如何控制需求的变更? 4、如何进行需求跟踪? 八、缺陷管理 1、什么叫缺陷管理? 2、缺陷管理的作用? 3、缺陷管理的流程? 4、如何可以保证缺陷报告的编写质量?

98


赞助商链接
推荐相关:

软件测试基础知识大全(新手入门必备)

软件测试基础知识大全(新手入门必备)_IT/计算机_专业资料。非常好的入门级资料,涵盖了所有涉及到的基础知识,很适合新手 1. 软件生命周期(SDLC)的六个阶段 1、...


软件测试基本知识

软件测试基本知识_计算机软件及应用_IT/计算机_专业资料。软件测试基本知识第一章 软件工程及 UML 笔试题 1. 2. 【基础题】UML:Unified Modeling Language 它是一...


软件测试基础知识点汇总

软件测试基础知识点汇总_计算机软件及应用_IT/计算机_专业资料。软件测试基础知识点汇总 一、测试基础 1. 软件测试的定义 ? 1983 年,IEEE 提出的软件工程标准术语...


软件测试基础知识整理

软件测试基础知识整理_计算机软件及应用_IT/计算机_专业资料 暂无评价|0人阅读|0次下载|举报文档软件测试基础知识整理_计算机软件及应用_IT/计算机_专业资料。软件...


软件测试基础知识

软件测试基础知识_计算机软件及应用_IT/计算机_专业资料。测试重要知识软件测试基础知识 一、软件测试的描述: ? 测试能提高软件的质量,但是提高质量不能依赖测试;...


最全面的软件测试基础知识-整理版

最全面的软件测试基础知识-整理版_求职/面试_求职/职场_应用文书。软件测试面试基础知识,整理版,将重复的部分删除,添加了文章的结构方便同学们阅读。Q...


最全面的软件测试基础知识-面试不愁

最全面的软件测试基础知识-面试不愁_电脑基础知识_IT/计算机_专业资料。软件测试基础知识 北测教育 Q:什么是软件测试?软件测试的目的是什么? A:IEEE 软件测试定义...


软件测试基础理论知识

软件测试基础理论知识_计算机软件及应用_IT/计算机_专业资料。[键入文字] 测试理论培训资料 [键入文字] 控制流分析 数据流分析 信息流分析 逻辑覆盖 程序插装 白...


软件测试知识点(很有用)_图文

质量---软件测试---软件的组成---测试- ---对象---目的---原则---软件测试工程师---衡量标准 1 软件测试基础 1. 软件生存周期模型 阶段 可行性研究 ...


移动客户端测试基础知识

移动客户端测试基础知识_计算机软件及应用_IT/计算机_专业资料 暂无评价|0人阅读|0次下载|举报文档移动客户端测试基础知识_计算机软件及应用_IT/计算机_专业资料。...

网站首页 | 网站地图
All rights reserved Powered by 酷我资料网 koorio.com
copyright ©right 2014-2019。
文档资料库内容来自网络,如有侵犯请联系客服。zhit325@126.com