软件测试技术经典教程笔记修汇总.docx
- 文档编号:17905900
- 上传时间:2023-08-04
- 格式:DOCX
- 页数:18
- 大小:50.36KB
软件测试技术经典教程笔记修汇总.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
对一种软件进行本地化测试就需要关注文本显示空间,由于不同语言长度不同样,因此在设计界面时候就要小心了!
验证软件被翻译完毕后,与否有什么错误,与否可以正常工作。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 技术 经典 教程 笔记 汇总