软件测试技术经典教程笔记修.docx

软件测试技术经典教程笔记修.docx

《软件测试技术经典教程笔记修.docx》由会员分享，可在线阅读，更多相关《软件测试技术经典教程笔记修.docx（17页珍藏版）》请在冰豆网上搜索。

软件测试技术经典教程笔记修

第一章基础知识

1.1、软件

1）、软件=程序+文档

2）、分类

功能：

系统+应用

架构：

单机+C/S+B/S

用户：

产品+项目

规模：

小型+中型+大型

1.2、Bug

1）、类型一（广义上，软件生命周期，与用户需求不符的问题）：

完全没有实现的功能

基本实现功能，但有功能上或性能上的问题

实现了用户不需要的功能

2）、类型二（测试执行阶段的问题）

Defect---------Requirements&Design

Error-----------Development

Bug------------Testing

Failure---------Postproduction

1.3、测试

1）、概念：

测试是为了检验实际的软件是否符合用户需求，所以不能为了发现错误而发现错误。

使用人工或自动手段，来运行或测试某个系统的过程。

2）、测试环境：

硬件+软件+网络

要求：

真实（项目、产品）+干净+无毒+独立（测试与开发）

1.4、测试用例

测试用例=输入+输出+测试环境

便于团队交流，便于重复测试，便于跟踪统计，比纳与用户自测

开发生命周期

需求分析→概要设计→详细设计→编码→维护

测试生命周期

测试计划→测试设计→测试执行→测试评估

需求分析和测试计划完成后，根据《系统需求规格说明书》和软件原型（DEMO）写测试用例

1.5其他

1）、测试人员素质要求：

细心、耐心、信心、服务意识、团队合作意识、沟通能力

2）、如何成为优秀的测试工程师：

1、不断学习充电2、阅读原版书籍3、阅读缺陷管理系统中的缺陷报告4、阅读高手写的测试用例5、学习产品相关的业务知识

1.6软件测试的基本规则

1）ZeroBug与GoodEnough

GoodEnough原则：

不充分测试是不负责任，过分的测试是一种资源浪费。

参考：

*遗留bug不超过10个，严重的不超过5个

*测试用例执行率为100%，通过率为95%

*单元测试，关键模块语句覆盖率达到100%，分支覆盖率达到85%

2）不要视图穷举法

3）开发人员不能既是运动员又是裁判员

4）软件测试要尽早执行

5）软件测试应该追溯需求

原始需求

需求分析

正确的规格说明

错误的规格说明

设计

正确的设计

错误的设计

对错误说明的设计

编码

正确编码

错误的编码

对错误设计编码

对错误说明设计的编码

测试

正确功能

可改正的错误

不可改正的错误

潜伏的错误

不完善的软件产品

6）缺陷的二八定理

一般情况下，软件80%的缺陷集中在20%的模块中。

7）缺陷具有免疫性

缺陷具有免疫性，需要根据新版本修改维护测试用例，另外，有一个值得注意的经验：

没修复3-4个bug，可能会产生一个新bug。

第二章测试分类

2.1、是否运行程序

StaticTesting------------代码规范、界面、文档

DynamicTesting--------运行程序

2.2、根据阶段分类

UnitTesting（单元测试）----------10%

最小模块，依据源程序和《详细设计》

白盒测试人员||开发人员

编译代码→静态测试→动态测试

桩模块（Stub）、驱动模块（Driver）

IntegrationTesting（集成测试）----------20%

模块间的接口，依据单元测试的模块和《概要设计》

白盒测试人员||开发人员

一般单元和集成同步进行

SystemTesting（系统测试）----------40%

整个系统（功能、性能、软硬件环境），依据《需求规格说明书》

黑盒测试工程师

AcceptanceTesting（验收测试）----------20%

整个系统（功能、性能、软硬件环境），依据《需求规格说明书》和验收标准

用户，可配合黑盒测试工程师

α测试：

内侧

β测试：

公测

2.3、是否查看代码

1）、White-BoxTesting-----源代码的测试

2）、Black-BoxTesting-----功能测试、性能测试

FunctionTesting（功能测试）

LogicFunctionTesting（逻辑功能测试）

UITesting（界面测试）：

窗口、下拉式菜单和鼠标操作

UsabilityTseting（易用性测试）

InstallationTesting（安装测试）

CompatibilityTesting（兼容性测试）

其他：

恢复测试、裸机测试、确认测试、接口测试、数据库测试、安全测试、配置测试

PerformanceTesting（性能测试）

时间性能：

主要指一个事务的具体响应时间（RespindTime）。

空间性能：

主要指软件运行时所消耗的系统资源（CPU、内存、硬盘）。

分类：

一般性能测试、稳定性测试、负载测试、压力测试

a、一般性能测试：

让被测系统在正常的软硬件环境下运行，不向其施加任何压力

b、稳定性测试（也叫ReliabilityTesting可靠性测试）：

指连续运行被测系统，检查系统运行时的稳定程度。

通常用MTBF（MeanTimeBetweenFailure）

c、负载测试（LoadTesting）：

让被测系统在其能忍受的压力极限范围内连续运行，检测系统的稳定性。

d、压力测试（StressTesting）：

持续不断的给被测系统增加压力，知道被测系统压垮为止，用来测试系统能承受最大压力。

2.4、回归测试、冒烟测试、随机测试

RegressionTesting（回归测试）：

软件新版本测试时，重新执行上一个版本测试用例。

可以在任何阶段进行（单元测试、集成测试、系统测试、验收测试等），既有黑盒测试的回归，也有白盒测试的回归。

SmokeTesting（冒烟测试）：

对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。

RandomTesting（随机测试）：

指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

第三章测试技术

黑盒测试技术

3.1、等价类技术（EquivalenceClassTesting）

等价类：

某个输入域的子集合。

在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。

有效等价类：

符合《需求规则说明书》，合理地输入数据集合

无效等价类：

不符合《需求规则说明书》，无意义的输入数据集合

等价类划分步骤：

1）先考虑输入数据的类型（合法和非法）

2）再考虑数据范围

3）画出示意图，区分等价类

4）为每个等价类编号

5）从等价类中选择测试数据构造用例

3.2、边界值技术（BoundaryValueTesting）

3.3、因果图法（Cause-EffectGraphs）

因果图法步骤

1）找出所有的输入条件和输出，并编号

2）分析输入条件之间的关系，是互斥还是可以同时满足

3）画出输入条件的排列组合情况

4）编写测试用例

因果图试用于输入条件过多

3.4、流程图法（WorkflowMethod）

流程图法步骤

1）详细了解需求

2）根据需求说明或界面原型，找出业务流程的各个页面及各页面之间的流转关系

3）画出业务流图

4）写用例，覆盖所有路径分支

流程图法是针对整个系统，而非某个页面或模块

还有其他如：

判定表、错误推测、场景法等，例：

ATM机取钱-场景法（不全）

场景

密码

帐号

输入金额

账面金额

ATM现金

预想结果

场景1：

成功提款

1

1

1

1

1

提款

场景2：

ATM内无现金

1

1

1

1

0

不可提款

场景3：

ATM内现金不足

1

1

1

1

0

提示，返回开始

场景4：

密码错误，可再次输入

0

1

null

1

1

警告，返回开始

场景5：

密码错误，不可再次输入

0

1

null

1

1

警告，卡预保留

白盒测试技术

3.5白盒测试检查点

*对程序模块的所有独立的执行路径至少测试一次

*对所有的逻辑判定，取’真’与’假’都至少测试一次

*在循环的边界和运行界限内执行循环体

*测试内部数据结构的有效性等

步骤：

1）根据分析画出流程图

2）计算圈复杂度=判定节点数+1

3）写出独立路径

4）根据独立路径设计测试用例

第四章缺陷管理

4.1、Bug的分类

1）严重程度（Severity）：

系统崩溃、严重、一般、次要、建议

2）优先级（Priority）：

高（High）、中（Middle）、低（Low）

严重程度高，优先级不一定高，严重程度低，优先级不一定低

3）按测试种类：

逻辑功能类（Fcuntion）、性能类（Performance）、界面类（UI）、易用性类（Usability）、兼容性类（Compatibility）

4）按功能模块

5）按生命周期：

新建（New）、确认（Confirmed）、解决（Fixed）、关闭（Closed）、重新打开（Reopen）

4.2缺陷报告

注意点：

1）确保重现Bug

2）用最少且必要步骤描述Bug

3）简洁、准确、完整

4）一个Bug一个报告

4.3缺陷管理工具

TrackRecord、Clearquest、Bugzilla（免费）、Mantis（免费）、JIRA（免费）

Bugzilla：

TerryWeissman研制，perl编写，后台数据库是MySQL，最初是用来在Netscape内部跟踪Bug的，可以在多种平台运行

第五章常用测试工具

分类：

黑盒测试工具、白盒测试工具、测试管理工具

MI公司产品：

1、LoadRunner：

性能测试工具

2、WinRunner：

功能测试工具（QTP：

MI的QTP代替占有市场）

3、TestDirector：

测试管理工具（QC：

HP收购MI公司后退出的一款TD升级产品）

性能学习LoadRunner，功能学些QTP，管理学习TD

IBMRational公司的产品：

RationalTestmanager（测试管理工具）

RationalClearQuest（缺陷管理工具）

RationalRobot（功能/性能工具）

RationalPurify（白盒测试工具）

Compuware公司产品

QACenter（测试管理）

TrackRecord（缺陷管理）

QARun（功能）

QAload（性能）

DevPartner（白盒测试）

Telelogic公司产品

TelelogicDoors（需求管理）、Logiscope（白盒测试工具）

其他公司产品

微软-WAS（性能测试）

Radview公司-WebLoad（性能测试），TestViewManager（测试管理）

Parasoft公司-JTest（白盒测试），C++Test（白盒测试）

另外，很多缺陷管理工具是开源的，如：

Bugzilla、Mantis、Jira

第六章测试管理

6.1、测试与质量

软件质量：

软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准，以及所

有专业开发的软件都应具有的隐含特征的程度（需求一致、符合准则、隐含特征）

SQA（SoftwareQualityAssurance）：

软件质量保证，为确保软件开发过程和结果符合预期

要求而建立的一系列规程，以及一照规程和计划采取的一系列活动及其结果评价。

SQA需要做的工作：

*建立软件质量保证活动的实体

*制定软件质量保证计划

*坚持各阶段的评审、审计、跟踪

*监控软件产品的质量

*采集软件质量保证活动的数据

*度量软件质量保证活动

SQA需要达到目标：

*通过监控软件开发过程来保证产品质量

*保证开发出来的软件和软件开发过程符合相应标准与规程（ISO90000或CMM）

*保证软件产品、软件过程中存在的不符合问题得到处理，必要时将问题反映给高级

管理者

*确保项目组指定的计划、标准和规程适合项目组需要，同时满足评审和审计需要。

SQA工作人员：

QA，QC工作人员：

主要是TESTER

QA与QC：

QA-预防问题（Prevention），贯穿于整个软件生命周期中，预防错误的成因，重点是对软件开发过程进行监督、管理、控制

QC-发现问题（Detection），主要是测试人员，关注于最后的产品的质量活动，重点是对开发出的产品进行检查

6.2、常用模型

CMM：

能力成熟度模型

1）初始级（Initial）：

软件过程的特征是无序的，有时甚至是混乱的。

几乎没有过程定义，成功完全取决于个人的能力。

2）可重复级（Repeatable）：

建立了基本的项目管理过程，能够追踪费用、进度和功能。

有适当的必要的过程规范，使得可以重现以前类似项目的成功。

3）已定义级（Defined）：

用于管理和工程活动的软件过程己经文档化、标准化，并与整个组织的软件过程相集成。

所有项目都使用文档化的、组织认可的过程来开发和维护软件。

4）已管理级（Managed）：

软件过程和产品质量的详细度量数据被收集，通过这些度量数据，软件过程和产品能够被定暈地理解和控制。

5）优化级（Optimizing）：

通过定量的反馈，进行不断的过程改进，这些反馈来自于过程或通过测试新的想法和技术而得到。

KPA（KeyProcessArea）：

除第一级外，CMM的每一级是按完全相同的结构组成的。

每一级包含了实现这一级目标的若干关键过程域，指出了企业需要集中力量改进的软件过程。

CMM2:

可重复阶段

　　需求管理：

requrementmanagement

　　软件项目计划：

softwareprojectplanning

　　软件项目跟踪和监督：

softwareprojecttrackingoversight

　　软件子合同管理：

softwaresubcontractmanagement

　　软件质量保证：

softwarequalityassurance

　　软件配置管理：

softwareconfigurationemanagement

CMM3:

已定义阶段

　　组织过程焦点：

organizationprocessfocus

　　组织过程定义：

organizationprocessdefinition

　　培训大纲：

trainingprogram

　　集成软件管理：

intergratedsoftwaremanagement

　　软件产品工程：

softwareproductengineering

　　组间协调：

intergroupcoordination

　　同行评审：

peerreview

CMM4:

已管理阶段

　　定量管理过程：

quantitativeprocessmanagement

　　软件质量管理：

softwarequalitymanagement

CMM5:

优化阶段

　　缺陷预防：

defectprevention

　　技术改革管理：

technologychangemanagement

过程更改管理：

processchangemanagement

常见的质量模型：

*ISO90000族标准：

国际标准（ISO/TC176），适合所有行业，其中9000-3针对软件开发

*CMM标准：

行业标准（卡耐基-梅隆大学），针对软件开发行业，分5等级，推出CMMI

*TICKIT标准：

行业标准（英国软件行业协会），针对软件开发行业，不太流行

*ISO15504标准：

国际标准（试图结合1、2与软件工程概念），适用所有行业，有待实践

其他模型：

TMM：

软件测试成熟度模型

*初始级

*阶段定义级

*集成级

*管理和度量级

*优化、预防缺陷和质量控制级

McCall模型：

【产品运行】正确性、健壮性、效率、完整性、可用性、风险

【产品修改】可理解性、可维护性、灵活性、可测试性

【产品转移】可移植性、可再用性、互运行性

6.3、软件的生命周期

软件：

可行性研究、需求分析→设计、编码、测试→软件发布维护→淘汰

软件开发：

需求分析→概要设计→详细设计→编码→维护

软件测试：

测试计划→测试设计测试执行→测试评估

软件生命周期模型：

1、WaterfallModel（瀑布模型）：

计划-需求-设计-编码-测试-维护

开发的各个阶段比较清晰依赖早起需求调查，不适应需求变化

强调早期计划及需求调查单一流程，不可逆

适合需求稳定的产品开发风险往往迟至后期才发现，失去及早纠正机会

2、SpiralModel（螺旋模型）：

重复执行多个’瀑布模型’

适合需求经常变化的软件项目，但开发过程复杂，控制不好，容易混乱

3、V模型

用户需求验收测试

规格定义系统测试

概要设计集成测试

详细设计单元测试

编码

详细表示了测试的各个阶段及参考依据，但没有说明在项目前期测试需要做哪些工作，且流程也是单项，不可逆

4、W模型

需求分析需求测试系统安装验收测试

概要设计概要设计系统构建系统测试

测试

详细设计详细设计模块集成集成测试

测试

编码实现单元测试

强调测试伴随整个软件开发生命周期，对象也不仅是程序，有利于尽早发现问题，但是需求设计编码等活动也被视为串行，测试和开发也保持一种线性的前后关系。

W模型、H模型、X模型

通常可以在W模型的框架下，运用H模型的思想进行独立的测试，当有变更发生时，按X模型和前置模型的思想进行处理。

（XX另几种模型）

6.4软件测试计划

撰写测试计划时，应注意一下四点：

*增强测试计划实用性注意体现项目的测试特点

*坚持”5W1H”规则，明确内容与过程

5W1H：

”WHAT”,”WHY”,”WHEN”,”WHERE”,”WHO”,”HOW”

what：

明确测试范围和内容

why：

测试目的

when：

确定测试开始和结束日期

where：

给出测试文档和软件的存放位置

who：

测试人员的分配

how：

指出测试的方法和工具

*采用评审和更新机制，保证测试计划满足实际需求

*分别创建测试计划与测试策略

其他

RUP：

rationalunifiedprocess统一软件开发过程

它定义了在整个软件开发过程中：

在什么时候，应该有谁，进行什么样的开发活动，产生什么样的结果，来确保按时提交筒质量的产品。

RUP总体结构

每个角色完成指定的活动

每个活动产出合格的产品

每个产品拥有相关的指南，模板等

RUP主要特点

迭代化软件开发

以架构为核心的软件开发

用例驱动的软件开发

风险驱动的软件开发

最佳经验

迭代化开发

需求管理

基于构件的软件架构

可视化建模

持续的质量验证

配置管理

RUP适合任何项目

RUP在实施之前必须进行裁剪

RUP是个丰富的知识库，需要你不断的去查阅，选择

实践RUP是个持续的过程

国际化与本地化

Globalizationtesting

注意的是它与翻译是没什么太大关系的。

国际化测试关注产品是否达到了不同的时区、时间日期、货币格式和不同的文化习惯等，当然还有政治规定方面的要求。

Localizationtesting

对一个软件进行本地化测试就需要关注文本显示的空间，因为不同语言的长度不一样，所以在设计界面的时候就要小心了！

验证软件被翻译完毕后，是否有什么错误，是否能够正常工作。