软件测试详细重点内容教材.docx
《软件测试详细重点内容教材.docx》由会员分享,可在线阅读,更多相关《软件测试详细重点内容教材.docx(46页珍藏版)》请在冰豆网上搜索。
![软件测试详细重点内容教材.docx](https://file1.bdocx.com/fileroot1/2023-2/26/071df2f5-1b0b-45f3-95a0-c4003eeb8738/071df2f5-1b0b-45f3-95a0-c4003eeb87381.gif)
软件测试详细重点内容教材
第一章
第一讲软件测试背景
1.软件=程序+文档+数据
第二讲软件测试基础知识
1.测试的含义
首先是一项活动,在这项活动中某个系统或组成的部分将在特定的条件下运行,结果将被观察和记录,并对系统或组成部分进行评价。
2.软件测试
使用人工或自动化手段,来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别(IEEE)
3.软件测试的根本目的
发现\修改缺陷满足需求,提高用户满意程度优化软件品质
一个好的测试用例在于发现了还未曾发现的错误;一次成功的测试则是发现了错误的测试。
4.软件测试对象
1)软件测试不等于程序测试
2)软件开发过程中所产生的需求规格说明、概要设计规格说明、详细设计规格说明以及源程序、用户文档都是软件测试的对象
在软件生命周期中,每个阶段都有不同的测试对象,形成了不同开发阶段的不同类型的测试。
5.软件测试分类
a)测试组织:
开发方+用户方+第三方
b)测试用例设计方法:
黑盒+白盒+灰盒
c)测试策略与过程:
单元—>集成—>系统—>验收
d)基本要求和适用要求:
功能、性能
e)回归测试、冒烟测试、随机测试
按测试组织:
开发方测试、用户测试、第三方测试
按测试技术:
黑盒测试(不去看代码)、白盒测试、
灰盒测试是介于白盒测试与黑盒测试之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。
按测试过程:
单元测试、集成测试、系统测试、验收测试.
按测试类型:
功能、性能、界面、易用性测试、兼容性测试、安全性测试、安装测试
(单元测试:
在编码过程中,对每个小程序单元测试)
(集成测试:
将单元集成在一起后,可称为组件)
回归测试、冒烟测试、随机测试
(冒烟测试:
是指在对一个新版本进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。
专门针对某一项功能的测试---主干功能)
验收测试(α测试,不能由程序员或测试员完成。
β测试,测试版,公众)
•我们使用QQ2009Beta版进行聊天(用户测试、黑盒测试、验收测试)
•程序员A对刚开发出来的add函数进行检验(开发方测试、白盒测试、单元测试)
•SCIS系统开发完成了,几名测试老师对该系统进行检验(开发方测试、黑盒测试、系统测试
•测试老师首先验证SCIS的登录功能和其他基本主功能(开发方测试、黑盒测试、系统测试、冒烟测试)
•针对SCIS测试老师提出系统缺陷,开发者修改后,测试老师再次检验(开发方测试、黑盒测试、系统测试、回归测试)
•SCIS系统通过测试老师的检验,从各班中抽取几名同学代表进行系统初体验(用户测试、黑盒测试、验收测试(alpha测试或系统初验))
6.测试环境(软件+硬件+网络)
指测试软件的时候,软件运行的平台
软件开发环境:
VB、VC、VS等
软件生产运行环境:
最终用户环境
7.测试环境搭建原则(记住)
●真实:
(项目软件、产品软件):
尽量模拟用户的真实使用环境
●干净:
测试环境中尽量不要安装其他与被测软件无关的软件
●无毒:
测试环境没有病毒
●独立:
测试环境和开发环境要独立开来
项目软件:
有明确的客户群体,周期较短
产品软件:
面向大众去发送,周期较长
8.软件测试时间
•软件生命周期
计划、需求à设计、编码、测试à运行维护à淘汰停用
•软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程中,都有可能产生和发现缺陷。
随着整个开发过程的时间推移,更正缺陷或修复问题的费用呈几何级数增长。
•软件测试尽早开展。
•软件测试覆盖整个软件生命周期。
9.测试信息流程(简单看)
测试过程中需要三类输入:
软件配置、测试配置和测试工具。
测试最终的结果或输出:
得到软件的功能正确或者找出缺陷。
软件配置:
包括软件需求规格说明、软件设计规格说明、源代码等;
测试配置:
包括测试计划、测试用例、测试驱动程序等。
测试工具:
为提高测试效率,采用测试工具支持测试工作,包括测试数据自动生成程序、驱动测试的测试数据库等。
10.软件测试周期
软件测试的周期性是指测试、改错、再测试、再改错。
这样一个循环过程,如下图所示。
12.软件测试停止依据(理解,第五种推荐)
•第一类标准:
测试超过了预定时间,则停止测试。
•第二类标准:
执行了所有的测试用例,但并没有发现故障,则停止测
•第三类标准:
使用特定的测试用例设计方案作为判断测试停止的基础
•第四类标准:
正面指出停止测试的具体要求,即停止测试的标准可定义为查出某一预订数目的故障。
•第五类标准:
根据单位时间内查出故障的数量和严重程度决定是否停止测试。
13.软件测试原则(理解)
•尽早地和及时地测试
软件缺陷分布图软件产品说明书(需求阶段)56%、设计阶段27%、编写代码7%、其他10%。
需求阶段产生缺陷最多
•测试前应当准备好测试数据和与之对应的预期结果这两部分
测试数据+ 预期结果 = 测试用例
•测试输入数据应包括合理的输入条件和不合理输入条件
•程序提交测试后,应当由专门的测试人员进行测试
•严格执行测试计划,排除测试的随意性(随意测试,丢失功能点)
回归测试更要注重测试计划
•测试用例的所有相关预期结果做全面的检查
•充分注意测试当中的群体现象
•保存测试计划、测试用例、出错统计和最终分析报告,为维护工作提供充分的资料
•(补充)缺陷具有免疫性(每修复3-4个缺陷,一般就会产生一个新的缺陷)
14.测试工作误解
-误区一:
软件测试技术要求不高,至少比编程容易多了
-误区二:
若发布的软件有质量问题,那是软件测试人员的错
-误区三:
软件测试是测试人员的事,与开发人员无关
-误区四:
根据软件开发瀑布模型,软件测试是开发后期的一个阶段
-误区五:
有时间就多测试一些,来不及就少测试一些
-误区六:
软件测试是非建设性的工作,甚至是破坏性的,测试中发现错误是对责任人工作的一种否定
第三讲软件测试模型
1.软件产品需要各种开发投入
产品说明书、设计文档、进度计划、产品审查、上一版本信息反馈、商业竞争对手的同类软件产品情况、客户调查、易用性数据、观察与感受说明书等
2.产品开发过程
•需求调研
-对客户调查所收集的详细信息
-以前软件的使用情况及存在问题
-竞争对手的软件产品信息等
-目的:
确定将要开发的软件产品应该具有哪些功能
•需求规格说明书
-对客户需求信息进行综合描述
-包括用户未提出、但必须要实现的要求
-目的:
针对产品进行定义并确定其功能
•设计说明书
架构、数据流示意图、状态变化示意图、流程图、注释代码
(建筑一栋大楼,在施工前必须先进规划、设计、绘制各类工程图纸。
)
•开发进度表
•软件产品组成部分
程序代码、帮助文件、用户手册、样本和示例、产品支持信息、图表和标志、标签、产品和宣传材料、软件的安装、软件说明文件、测试错误提示信息
•测试文档
一般测试文档所包含的内容
测试计划:
描述用于验证软件是否符合产品说明书和客户需求的整体方案。
测试用例:
依据测试的项目,并描述验证软件的详细步骤。
软件测试报告:
描述依据测试用例找出的问题,通常提交测试报告。
归纳、统计和总结:
采用图表、表格和报告等形式来描述整个测试过程。
3.开发模型
a)大棒开发法
⏹优点:
思路简单,通常可能是开发者的“突发奇想”
⏹缺点:
开发过程是非工程化的,随意性大,结果不可预知
⏹测试:
开发任务完成后,修复较困难
b)边写边改发
⏹优点:
简单考虑到了软件的需求,产品周期短
⏹缺点:
没有计划和文档的编制
⏹测试工作:
由于新的版本不断产生,测试工作长期循环
采用边写边改法的软件开发通常只是有了比较粗略的想法就开始进行简单的设计、然后进行较长的反复编写、测试与修复这样一个循环的过程。
在认为无法更精细的描述软件产品要求时,就发布产品。
c)瀑布发
瀑布模式是将软件生命周期的各项活动,规定为按照固定顺序相连的若干个阶段性工作,形如瀑布流水,最终得到软件产品。
⏹优点:
易于理解;调研开发的阶段性(明确的阶段性划分);强调早期计划及需求调查;确定合适能够交付产品及何时进行评审与测试
⏹缺点:
需求分析只进行一次,不能适应需求变化;顺序的开发流程,使得开发中的经验教训不能反馈到该项目的开发中去;不能反映出软件开发过程的反复与迭代性;没有包含任何类型的风险评估;开发中出现的问题直到开发后期才能够显露,因此失去及早纠正的机会。
不适应需求变化;各步骤分立、没有交叉;反复、迭代不可显示、无法后退;
缺少风险评估;后期暴露问题
⏹测试工作:
测试工作被定义为在开发后才开始进行
d)快速原型法
根据客户需求在较短的时间内解决用户最迫切解决的问题,完成可演示的产品。
这个产品只实现最重要功能,在得到用户的更加明确的需求之后,原型将丢弃。
增加用户反馈阶段。
e)螺旋模型法
瀑布模型+ 边写边改模型 + 风险评估 = 螺旋模型
主要思想是在开始时不必详细定义所有细节,而是从小开始,定义重要功能,尽量实现,接受客户反馈,进入下一阶段,并重复上述过程,直到获得最终产品。
(一个螺旋包括6个步骤:
1.确定目标,可选方案有限制条件;2.指出并解决风险;3.评估方案;4.本阶段开发和测试;5.计划下一阶段;6.确定进入下一阶段的方法。
测试一直在进行,直到最后宣布成功!
)
每一螺旋(开发阶段)包括5个步骤:
确定目标,选择方案-à评估方案,解决风险à本阶段的开发和测试à计划下一阶段à确定下阶段方法
⏹优点:
严格的全过程风险管理;强调各开发阶段的质量;提供机会评估项目是否有价值继续下去。
(发现问题早)
4.开发与测试的关系(了解)
•测试与开发各阶段的关系
•测试在开发阶段的作用
✧项目规划阶段:
负责从单元测试到系统测试的整个测试阶段的监控。
✧需求分析阶段:
确定测试需求分析、系统测试计划的制定,评审后成为管理项目。
✧详细设计和概要设计阶段:
确保集成测试计划和单元测试计划完成。
✧编码阶段:
由开发人员进行自己负责部分的测试代码。
在项目较大时,由专人进行编码阶段的测试任务。
✧测试阶段(单元、集成、系统测试):
依据测试代码进行测试,并提交相应的测试状态报告和测试结束报告。
•完整的软件开发流程
5.软件测试模型介绍(重点模型特点、模型图)
●软件测试过程模型-------V模型
✧V模型是最具有代表意义的测试模型。
✧V模型是软件开发瀑布模型的变种,它反映了测试活动与需求分析和设计的关系。
✧从左到右,描述了基本的开发过程和测试行为,非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
✧箭头代表了时间方向,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即各测试过程的各个阶段。
✧V模型存在一定的局限性
测试过程编码之后的一个阶段
需求分析阶段的隐藏的问题一直到后期的验收测试才被发现
✧V模型的改进
V模型+各阶段同步测试=W模型
✧W模型体现了“尽早的和不断进行软件测试”的原则
●软件测试过程模型------W模型
W模型强调测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、设计等同样需要测试,也就是说测试和开发是同步进行的。
关于W模型的缺陷:
在W模型中,需求、设计、编码等活动被视为串行的,同时,测试和开发活动也保持着一种线性的前后关系,只有上一阶段完成后,才可以开始下一阶段的活动,不能支持迭代和适应开发过程中的变更调整。
W模型的优点:
W模型可以说是V模型自然而然的发展。
它强调:
测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。
●软件测试过程模型------H模型
H模型揭示出:
✧软件测试应尽早准备尽早执行
✧软件测试是一个独立的流程,贯穿于整个产品周期,与开发并行
✧软件测试不仅仅指测试的执行,还包括很多其他的活动
✧软件测试是根据被测物的不同而分层次进行的,不同层次的测试活动可以是按照某个次序先后进行的,但也可以是反复的
第四讲软件测试与软件质量
1.软件质量的概念
•质量是系统、部件或过程满足客户或者用户需要的程度。
•软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。
2.软件质量标准(评价一个软件质量好坏的准则)
软件质量标准主要分为两个方向:
产品质量:
人们实践产物的属性和行为。
模型:
McCall、ISO9126、Boehm
过程质量:
人们生产产品的过程的好坏。
模型:
CMM、ISO9000
McCall模型:
(3方面11个质量特性记住,名词含义理解)
✧产品修订:
•可维护性:
为了满足用户新的要求或当环境发生了变化,或运行中发现了新的错误时,对一个已投入运行的软件进行相应诊断和修改所需工作量的大小。
•可测试性:
测试软件以确保其能够执行预定功能所需工作量的大小。
•灵活性:
修改或改进一个已投入运行的软件所需工作量的大小。
✧产品变迁:
•可移植性:
讲一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境所需工作量的大小
•可复用性:
一个软件能再次用于其它应用程序的程度
•互联性:
又称互操作性,连接一个软件和其他系统所需工作量的大小。
✧产品运行:
•正确性:
在预订环境下,软件满足设计规格说明及用户预期目标的程度。
他还要求软件本身没有错误。
•可靠性:
软件按照设计要求,在规定时间和条件下不出故障,持续运行的程度。
•可使用性:
对于一个软件系统,用户学习、使用软件及为程序准备数据和解释输出所需工作量的大小
•完整性:
为某一目的而保护数据,避免它受到偶然的或有意的破坏、改动或遗失的能力。
•效率:
为了完成预定功能,软件系统所需的计算机资源的多少。
ISO9126模型:
(6个性质特性记住、21个子特性)
•功能性(适合性、准确性、互用性、依从性、安全性)
•可靠性(成熟性、容错性、可恢复性)
•易使用性(易理解性、易学性、易操作性)
•效率(时间特性、资源特性)
•可维护性(易分析性、易改变性、稳定性、易测试性)
•可移植性(适应性、易安装性、一致性、易替换性)
CMM过程质量
•能力成熟度模型:
是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。
•CMM的意义:
迄今为止学术界和工业界公认的有关软件工程和管理实践的最好的软件过程。
为评估软件组织的生产能力提供了标准。
为提高软件组织的生产过程指明了方向。
•CMM五级模型(达到3级基本以成熟记住)
第一级:
初始级特点是软件过程无秩序,有时甚至是混乱的。
软件过程定义几乎没有章法和步骤可循,软件产品所取得的成功往往依赖极个别人的努力和机遇(需求、设计、工作计划没有,做完之后就算完了,重新做一个系统的时候就直接再开始做)
第二级:
可重复级已建立了基本的项目管理过程,可用于对成本,进度和功能特性进行跟踪。
对类似的应用项目,有章可循,并能重复以往所取得的成功。
(1.Milestone可见,按计划开发2.软件开发的首要问题不是技术问题而是管理问题。
因此,可重复级的焦点集中在软件管理过程上。
3.一个可管理的过程则是一个可重复级的过程,一个可重级的过程则能逐渐进化和成熟。
4.该级管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面。
5.项目管理分为计划过程和跟踪监控过程两个过程。
6.通过实施这些过程,从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
)
第三级:
定义级用于管理的、工程的软件过程均已实现文档化、标准化,并形成了整个软件组织的标准软件过程。
全部项目均已采用与实际情况相吻合的、适当修改的标准软件过程来进行。
✓每个阶段的内部活动可见
✓较普遍的看法是,只有当达到了第3级能力成熟度时,才表明这个软件组织的软件能力“成熟”了。
第四级:
定量管理级软件过程和产品质量有详细的度量标准,软件过程和产品质量得到了定量的认证和控制。
第五级:
(不断)优化级通过对来自过程、新概念和新技术等方面各种有用信息的定量分析,能够不断地、持续性的对过程进行改进。
ISO9000标准
ISO9000是关于质量管理和质量评价的一系列国际标准。
定义了一套基本达标的做法,有助于公司一致的交付符合客户质量要求的产品或者服务。
ISO9000与CMM区别
ISO9000国际标准,广泛领域CMM行业标准,软件行业
3.软件质量相关人员种类(区别理解)
QC(qualitycontrol)着眼于软件、保证质量符合规定、发现问题、受控
QA(assurance)着眼于过程整体、建立体系,确保执行、预防问题、监督
QA工作内容:
监控软件开发过程、参与评审,确保文.档有效、保证产品和过程符合相应标准和规程、保证问题得以处理
第五讲软件测试职业与素质
1.第三方测试:
独立于软件公司自身测试的测试。
既不是开发方,也不是客户方,而是指软件公司和软件用户之间的一方
第六讲测试流程+测试文档(很重要)
1.软件测试流程
前期:
参加需求评审会议
拟定软件测试计划—>设计和生成测试用例—>搭建测试环境—>实施测试—>测试评估—>测试总结
测试阶段:
指定测试计划—>测试设计与开发—>执行测试—>评估总结
2.制定测试计划
•测试计划阶段主要处于测试的先期准备工作阶段,在该阶段中主要是对将要进行的测试工作做整体计划安排。
•本阶段的主要工作内容
对需求规格说明书的仔细研究
将要测试的产品分解成可独立测试的单元
为每个测试单元确定采用的测试技术
为测试的下一个阶段及其活动制定计划
概要测试计划+ 详细测试计划 = 制定计划
3.测试设计与开发
•测试设计与开发阶段包含两部分,一部分是设计,主要是参照各种相关文档对测试进行设计的工作,包括测试需求的分析和测试用例的设计;另一部分工作是开发,主要是按照设计的测试需求分析与测试用例设计的方案要求进行实施的过程,该过程包括:
测试用例数据的准备,测试工具的配置、测试脚本的开发录制与维护等工作,此阶段的工作可一直持续到软件测试结束。
测试用例文档是软件测试的依据,包括测试输入、测试步骤、预期结果等内容。
•测试用例文档的本质
从测试的角度对被测对象的功能和各种特性的细化和展开。
测试用例,设计测试用例–>测试用例文档
•测试用例文档的好处
保证测试功能不被遗漏,也不被重复测试。
合理安排测试人员。
使得软件测试不依赖于个人
4.实施测试
•实施软件测试阶段主要是将设计和开发阶段的测试用例和数据应用于软件的过程,执行的过程,执行过程中发现缺陷,可提交缺陷报告。
•缺陷报告:
是软件测试过程中最重要的文档,它的内容包括:
1)记录问题发生的环境,如:
各种资源的配置情况。
2)记录问题的在现步骤3)记录问题性质的说明4)记录问题的处理进程--问题处理进程从一定角度上反映测试的进程和被测软件的质量状况以及改善过程。
•初测期——测试主要功能和关键的执行路径,排除主要障碍。
•细测期——依据测试计划和测试用例,逐一测试大大小小的功能、方方面面的特性、性能、用户界面、兼容性、可用性等等;预期可发现大量不同性质、不同严重程度的错误和问题。
•回归测试期——系统已达到稳定,在一轮测试中发现的错误已十分有限;复查已知错误的纠正情况,确认未引发任何新的错误时,终结回归测试。
5.评估总结
评审阶段是在测试结束后对整个测试过程与产品进行评估的过程。
6.测试文档类型
第七讲测试计划
1.测试计划:
就是在软件测试工作正式实施之前明确测试的对象,并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划,保证有效的实施软件测试。
2.为什么制定测试计划
1)把知识和经验直接转化为执行任务的具体方法2)为组织、安排和管理测试项目提供一个整体框架3)促进团队间关于测试任务和过程的交流4)对项目执行过程中的风险进行分析,并制定相关的应对策略
3.何时制定测试计划
软件测试计划应当尽早的制定,需求说明书确定之后进行
软件测试计划在测试活动中处于中心位置
4.使用和维护测试计划
使用过程中要对测试计划进行必要的监测
a)测试计划要经过评审
b)测试项目是否按照计划执行
c)测试计划是否需要调整或修改
5.测试计划基本结构
测试计划的简介、测试项目说明、测试范围、测试手段和策略、项目通过或失败的标准、暂停和重新启动测试的标准\原则、测试的可交付性、测试任务分配、环境的需求、职责、人员和培训需求、进度表、风险及偶然事故的预测
6.正确认识测试计划
•谁是测试计划的最终用户
✧测试计划的最终用户一般是研发团队
✧测试计划作为产品提交给用户(特殊需求、军方、外包测试用户)
•关于测试计划的格式和内容
用户是研发团队:
✧测试计划的价值取决于它能在多大的程度上帮助你管理你的测试项目和帮助你发现错误。
✧千万不要为了写测试计划而写测试计划,测试计划务必能指导测试工作,切实具有可用性。
✧简单的套用模版,没有意义。
用户是特殊用户:
按用户要求填写
7.怎样进行软件风险分析
软件风险分析目的:
确定被测模块的优先级、深度。
第二章
第1讲项目测试环境搭建
1.测试环境=软件环境+硬件环境+网络环境
对软件系统进行各级测试所基于的软/硬件设备和支持(包括被测软件的运行平台、用于各级测试的工具和与该测试有关的软硬件环境,越接近用户环境越好)
•硬件环境:
指测试必需的服务器、客户端、网络连接设备,以及打印机/扫描仪等辅助硬件设备所构成的环境
•软件环境:
指被测软件运行时的操作系统、数据库及其他应用软件构成的环境
•网络环境:
指被测软件运行时的网络系统、网络结构及其他网络设备构成的环境
•对测试环境的要求:
a.尽可能真实的环境,b.营造纯净、独立的测试环境c.无毒的环境*符合软件运行的最低要求d.选用比较普及的操作系统和软件平台
2.测试环境的备份
•测试过程中会遇到多种不可预测的事情发生,一但造成系统崩溃,则会造成测试数据丢失、测试过程中断或者测试环境的重新搭建
•经常对测试环境进行多次必要的备份是一个必备的预防措施和一个比较好的习惯
•对测试环境的备份可以挽回不必要的损失、节省测试的时间、保持测试的连续性
3.测试环境的恢复
•一旦测试环境遭到破坏,可以还原最近备份的系统,实现测试环境的恢复
•目的:
维持测试环境的一致性、恢复测试数据、恢复测试环境的当前状态
•工具:
Ghost(Symantec)、Partimage(Linux)
4.测试环境的快速恢复
•将对测试环境备份获得的文件复制到其他硬件配置相同的计算机上
•利用备份恢复工具进行恢复
•实现多台机器同样的测试环境的快速搭建,从而节省搭建测试环境的时间
5.测试数据的获取
•测试数据也是影响测试环境的一个因素
•测试数据直接影响着测试的质量
•测试数据有多种来源:
用户、测试人员设计、随机生成
•功能测试不需要大量的数据,需要数据的覆盖率高,测试数据要求尽量真实
•性能测试需要大量的数据,测试数据应尽可能的达到符合实际的数据分配
•用户数据:
从最终用户处获得实际数据
•手动:
对测试数据进行手动的添加
•自动: