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

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

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

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

第一章基本知识

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：

MIQTP代替占有市场）

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

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

验证软件被翻译完毕后，与否有什么错误，与否可以正常工作。