软件测试技术经典教程笔记.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
对一个软件进行本地化测试就需要关注文本显示的空间，因为不同语言的长度不一样，所以在设计界面的时候就要小心了！
验证软件被翻译完毕后，是否有什么错误，是否能够正常工作。
升级会员 