第12章 软件测试基础.docx
- 文档编号:23473289
- 上传时间:2023-05-17
- 格式:DOCX
- 页数:56
- 大小:826.79KB
第12章 软件测试基础.docx
《第12章 软件测试基础.docx》由会员分享,可在线阅读,更多相关《第12章 软件测试基础.docx(56页珍藏版)》请在冰豆网上搜索。
第12章软件测试基础
软件评测师教程
第1章软件测试概论
1、国内外现状
国外:
1)、软件测试在软件公司占有重要地位
2)、软件测试理论研究蓬勃发展
3)、软件测试市场繁荣
国内:
1)、著名软件公司已经或正在建立独立的专职软件测试队伍;在相关资质的认定中软件测试能力已经被定为评介公司的技术能力的重要指标;实施软件登记制度;每年对软件产品进行质量监督抽查
2)、国家人事部和信息产业部2003年第一次在我国有了“软件评测师”的称号;软件测试正在成为部份软件学院的一门独立课程
3)、各行业通过测试规范行业软件的健康发展;用户对软件质量要求越来越高,系统验收需要通过第三方的测试机会来测试判定;第三方测试机构在蓬勃发展。
4)、“以测代评”是一项重要举措;
2、软件测试的发展趋势
1)、需求和对系统设计的技术将成为新的开研究热点
2)、测试工程师应尽早地介入整个工程
3)、测试职业得到尊重
4)、设置独立的软件测试部门将成为软件公司的共识
5)、测试外包快速增长
第2章软件测试基础
1、软件测试和软件质量
软件测试:
狭义的软件测试:
在规定条件下对程序进行操作,以发现错误,对软件质量进行评估。
测试的正确定义是“为了发现程序中的错误而执行程序的过程”。
广义的软件测试:
它是由确认、验证和测试三个方面组成。
确认:
评估将要开发的软件产品是否正确无误、可行和有价值的。
确认意味着确保一个待开发软件是正确无误的,是对软件开发构想的检测。
验证:
检测软件开发的每个阶段、每个步骤的结果是否正确无误,是否与软件开发各阶段的要求或期望的结果相一致。
验证意味着确保软件会正确无误地实现软件的需求,开发过程是沿着正确的方向进行的。
这里的测试与狭隘的测试概念统一。
软件测试贯穿于软件定义和开发的整个期间。
注意:
测试用例应由测试设计人员来制定。
测试点应由测试设计人员确立。
测试工作展开于项目立项后,而不是代码开发完成之后。
软件包括程序、数据和文档,所以软件测试并不仅仅是程序测试。
软件质量:
软件特性的总和,软件满足规定或潜在用户需求的能力
软件测试对软件质量的意义:
①度量与评估软件的质量;②发现软件错误;③改进软件开发过程。
2、软件测试和质量保证的区别
1)、QA主要着眼于软件开发活动中的过程、步骤和产物,而不是对软件进行剖析找问题或评估
2)、软件测试关心的不是过程的活动,而是对过程的产物以及开发出的软件进行剖析
3)什么是sqa
sqa,全称为SoftwareQualityAssurance,即软件质量保障;
sqa的完整定义为:
为了确保软件开发过程和结果符合预期的要求,而建立的一系列规程,以及依照规程和计划采取的一系列活动及其结果评价。
4)SQA与测试
1、测试是在发现问题(Detection),SQA是在预防问题(Prevention)
2.理论上,测试作为软件生命周期的一部分,其过程也要受到SQA监督。
3.在国内,许多名义上的SQA作着测试的工作;许多测试人员作着部分SQA的工作,职位界定比较模糊。
3、软件测试的目的
以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷,通过修正各种错误和缺陷提高软件质量,回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。
关于软件测试的目的,有以下的一些观点:
①、软件测试是为了发现错误而执行程序的过程;
②、测试是为了证明程序有错,而不是证明程序无错误。
③、一个好的测试用例是在于它能发现至今未发现的错误;
④、一个成功的测试是发现了至今未发现的错误的测试。
4、软件测试原则(八大原则)
1)、所有的软件测试都应追溯到用户需求.即测试需要发现软件与需要不一致的错误,而不是与设计不一致的错误。
2)、应把“尽早地和不断的进行软件测试”作为测试者的座右铭
3)、完全测试是不可能的,测试需要终止(为什么?
)
通常测试用例很难100%覆盖测试需求,因为:
①输入量太大
②输出结果太多
③软件实现途径多
④测试依据没有统一标准(2008年47小题)
4)、测试无法显示软件潜在的缺陷
5)、充分注意测试中的群集现象(经验表明,测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。
应该对错误群集的程序段进行重点测试。
)
6)、程序员避免测试自己的程序(注意不是指对程序的调试)
7)、尽量避免测试的随意性(为什么?
)
测试计划应包括:
所测软件的功能,输入和输出,测试内容,各项测试的进度安排,资源要求,测试资料,测试工具,测试用例的选择,测试的控制方法和过程,系统的组装方式,跟踪规则,调试规则,以及回归测试的规定等等以及评价标准。
8)、妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便。
5、软件测试对象
程序,数据和文档(源程序、目标程序、数据及相关文档)
●软件测试并不等于程序测试。
软件测试应该贯穿整个软件定义与开发整个期间。
因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档,包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序,都应该是软件测试的对象。
●在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中,任何一个环节发生了问题都可能在软件测试中表现出来。
为了把握各个环节的正确性,人们需要进行各种验证和确认(V&V)工作。
验证:
是保证软件正确实现特定功能的一系列活动过程,目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。
确认:
是保证软件满足用户需求的一系列的活动过程,目的是在软件开发完成后保证软件与用户需求相符合。
确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。
对软件的功能和性能要求在软件需求规格说明中明确规定。
确认测试一般包括有效性测试和软件配置复查。
有效性测试。
有效性测试是在模拟的环境下,运用黑盒测试的方法,验证所测软件是否满足需求规格说明书列出的需求。
软件配置复查。
软件配置复查的目的是保证软件配置的所有成分都齐全,各方面的质量都符合要求,具有维护阶段所必须的细节,而且已经编排好分类的目录。
6、测试分类
1)、按开发阶段划分
单元测试、集成测试、确认测试、系统测试、验收测试
2)、按实施组织划分
开发方测试(a测试)、用户测试(B测试)、第三方测试
开发方测试(a测试):
通常也称为“验证测试”或“a测试”。
开发方通过检测和提供客观证据,证实软件的实现是否满足规定的需求。
用户测试(B测试):
通常被看成是一种“用户测试”。
β测试就是在软件公司外部展开的测试,可以由非专业的测试人员执行的测试。
B测试主要是把软件产品有计划地免费分发到目标市场,让用户大量使用,并评价、检查软件。
通过用户各种方式的大量使用,来发现软件存在的问题与错误,把信息反馈给开发者修改。
第三方测试:
第三方测试也称为独立测试,是由相对独立的组织进行的测试。
由在技术、管理和财务上与开发方和用户方相对独立的组织进行的测试
3)、按照测试技术划分
白盒、黑盒、灰盒
7、V模型
定义:
是软件开发瀑布模型的变种,主要反映测试活动与分析和设计的关系
局限性:
把测试作为编码后的最后一个活动,需求分析等前期产生的错误直到后期的验收测试才能发现
8、W模型
定义:
在V模型的基础上,增加了开发阶段的同步测试,形成W模型;测试与开发同步进行,有利于尽早的发现问题局限性:
仍把开发活动看成是从需求到编码结束的一个串行过程,只有完成上一阶段活动后,才下进行下一阶段活动,不支持迭代、自发性变更调整。
9、H模型
定义:
在H模型中,软件测试过程活动完全独立,贯穿于整个产品的周期,与其它流程并发的进行,某个测试点准备就绪,就可以从测试准备阶段进行到测试执行阶段;软件可以尽早的进行;软件测试可以根据被测产品的不同分层进行。
10、 模型使用
V模型:
强调了在整个项目开发需要经历的若干个测试级别,并与每一个开发级别相对应;忽略了测试对象不应该仅仅包括程序,没明明确指出对需求、设计的测试。
V模型的软件测试策略既包括低层测试又包括了高层测试,低层测试是为了源代码的正确性,高层测试是为了使整个系统满足用户的需求。
V模型存在一定的局限性,它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。
W模型:
补充了V模型中忽略的内容,强调了测试计划等工作的先行和对系统需求与系统设计的测试,与V模型相同,没有对软件测试的流程进行说明。
W模型由Evolutif公司提出,相对于V模型,W模型更科学。
W模型是V模型的发展,强调的是测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。
测试与开发是同步进行的,从而有利于尽早地发现问题。
W模型也有局限性。
W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动,无法支持迭代、自发性以及变更调整。
H模型:
强调测试是独立的,只有测试准备完成就可以执行测试
H模型揭示了:
∙软件测试不仅仅指测试的执行,还包括很多其他的活动
∙软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行
∙软件测试要尽早准备,尽早执行
∙软件测试是根据被测物的不同而分层次进行的。
不同层次的测试活动可以是按照某个次序先后进行的,但也可能是反复的
在H模型中,软件测试模型是一个独立的流程,贯穿于整个产品周期,与其他流程并发地进行。
当某个测试时间点就绪时,软件测试即从测试准备阶段进入测试执行阶段。
前置测试模型:
前置测试模型主张根据业务需求进行测试设计,认为设计阶段是进行测试计划和测试设计的最好时机。
软件测试模型的使用:
在实际软件测试的实施过程中,应灵活地运用各种模型的优点,通常可以在W模型的框架下,运用H模型的思想进行独立的测试。
当有变更发生时,按X模型和前置模型的思想进行处理。
同时,将测试和开发紧密结合,寻找恰当的就绪点开始测试,并反复进行迭代测试,以达到按期完成预定的目标。
软件开发模型有:
渐进模型、螺旋模型、增量模型、敏捷模型、原型等。
11、软件生命周期测试策略
(一)软件测试与软件开发过程的关系(如图)
测试过程四个步骤:
单元测试、集成测试、确认测试和系统测试。
(二)软件测试过程(如图)
1)、测试信息流:
软件配置、测试配置、测试工具
测试的信息流如图:
软件配置:
包括软件需求规格说明、软件设计规格说明、源代码等。
测试配置:
包括测试计划、测试用例、测试驱动程序等。
是软件配置的子集。
测试工具:
为提高测试效率,可使用测试工具支持测试工作,其作用就是为测试的实施提供某种服务,以减轻测试任务中的手工劳动。
2)、分析设计阶段:
分析阶段是评审与测试相结合,包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测。
☆需求说明书评测内容:
作为需求分析阶段工作的复查手段,在需求分析的最后一步,应该对功能的正确性、完整性和清晰性,以及其它需求给予评价。
评审的主要内容是:
1·系统定义的目标是否与用户的要求一致;
2·系统需求分析阶段提供的文档资料是否齐全;
3·文档中的所有描述是否完整、清晰、准确反映用户要求;
4·与所有其它系统成分的重要接口是否都已经描述;
5·被开发项目的数据流与数据结构是否足够,确定;
6·所有图表是否清楚,在不补充说明时能否理解;
7·主要功能是否已包括在规定的软件范围之内,是否都已充分说明;
8·软件的行为和它必须处理的信息、必须完成的功能是否一致;
9·设计的约束条件或限制条件是否符合实际;
10·是否考虑了开发的技术风险;
11·是否考虑过软件需求的其它方案;
12·是否考虑过将来可能会提出的软件需求;
13·是否详细制定了检验标准,它们能否对系统定义是否成功进行确认;
14·有没有遗漏,重复或不一致的地方;
15·用户是否审查了初步的用户手册或原型;
16·软件开发计划中的估算是否受到了影响.
为保证软件需求定义的质量,评审应以专门指定的人员负责,并按规程严格进行。
评审结束应有评审负责人的结论意见及签字。
除分析员之外,用户/需求者,开发部门的管理者,软件设计、实现、测试的人员都应当参加评审工作。
一般,评审的结果都包括了一些修改意见,待修改完成后再经评审通过,才可进入设计阶段。
☆概要设计说明书的评测内容如下:
①可追溯性:
分析该软件的系统结构、子系统结构,确认该软件设计是否覆盖了所有已确定的软件需求,软件每一成分是否可追溯到某一项需求。
②接口:
分析软件各部分之间的联系,确认该软件的内部接口与外部接口是否已经明确定义,模块是否满足高内聚和低耦合的要求,模块作用范围是否在其控制范围之内。
③风险:
确认该软件设计在现有技术条件下和预算范围内是否能按时实现。
④实用性:
确认该软件设计对于需求的解决方案是否实用。
⑤技术清晰度:
确认该软件设计是否以一种易于翻译成代码的形式表达。
⑥可维护性:
从软件维护的角度出发,确认该软件设计是否考虑了方便未来的维护。
⑦质量:
确认该软件设计是否表现出良好的质量特征。
⑧各种选择方案:
看是否考虑过其他方案,比较各种选择方案的标准是什么。
⑨限制:
评估对该软件的限制是否现实,是否与需求一致。
⑩其他具体问题:
对于文档、可测试性、设计过程等进行评估。
☆详细设计说明书评测内容:
(与概要基本相同)
①可追溯性:
分析该软件的系统结构、子系统结构,确认该软件设计是否覆盖了所有已确定的软件需求,软件每一成分是否可追溯到某一项需求。
②接口:
分析软件各部分之间的联系,确认该软件的内部接口与外部接口是否已经明确定义,模块是否满足高内聚和低耦合的要求,模块作用范围是否在其控制范围之内。
③风险:
确认该软件设计在现有技术条件下和预算范围内是否能按时实现。
④实用性:
确认该软件设计对于需求的解决方案是否实用。
⑤技术清晰度:
确认该软件设计是否以一种易于翻译成代码的形式表达。
⑥可维护性:
从软件维护的角度出发,确认该软件设计是否考虑了方便未来的维护。
⑦质量:
确认该软件设计是否表现出良好的质量特征。
⑧各种选择方案:
看是否考虑过其他方案,比较各种选择方案的标准是什么。
⑨限制:
评估对该软件的限制是否现实,是否与需求一致。
⑩其他具体问题:
对于文档、可测试性、设计过程等进行评估。
★为评测设计是否达到目标,必须建立衡量设计的标准。
如下:
(重要)
①设计出来的结构应是分层结构,从而建立软件成分之间的控制。
② 设计应当模块化,从逻辑上将软件划分为完成特定功能或子功能的构件。
③设计应当既是包含数据抽象,也包含过程抽象。
④设计应当建立具有独立功能特征的模块。
⑤设计应当建立能够降低模块与外部环境之间复杂连接的接口。
⑥设计应能根据软件需求分析获取的信息,建立可驱动、可重复的方法。
☆软件编码规范评测:
●源程序文档化
①符号名的命名②程序的注释③标准的书写格式
●数据说明
●语句结构
●输入和输出
3)、开发阶段:
单元测试:
针对软件设计的最小单位(程序模块),进行正确性检验的测试工作
目的:
发现各模块内部可能存在的各种差错
测试内容:
模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
单元测试步骤:
通常单元测试是在编码阶段进行的。
在源程序代码编制完成,经过评审和验证,确认没有语法错误之后,就开始单元测试的测试用例设计。
利用设计文档、设计可以验证程序功能、找出程序错误的多个测试用例。
对每一组输入,应有预期的正确结果。
两个辅助模块:
①驱动模块:
相当于所测模块的主程序。
它接收测试数据,把这些数据传给所测模块,最后再输出实测结果
2桩模块:
也叫存根模块。
用以代替所测模块调用的子模块。
桩模块可以做少量的数据操作,不需要把子模块所有功能都带进来,但不允许什么事情也不做。
单元测试的测试环境如图:
集成测试(也叫做组装测试或联合测试):
在单元测试的基础上,需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
方式:
一次性组装方式、增殖方式组装。
在进行集成测试时,测试者应当确定关键模块,对这些关键模块及早进行测试。
关键模块至少应具有特征:
满足某些软件需求、在程序的模块结构中位于较高的层次(高层控制模块)、较复杂和较易发生错误、有明确定义的性能要求。
测试方式(组装方法):
一次性组装方式、增殖方式组装(自顶向下、自底向上、混合增殖方式测试)
一次性组装方式,非增殖式方式也叫整体拼装,对模块分别测试然后将所有模块组装;第二种增殖式组装方式,可以是自顶向下或自底向上;混合增殖式测试
自顶向下增殖方式或自底向上增殖方式各有优缺点:
自顶向下增殖方式缺点:
是需要建立桩模块。
优点:
是能够较早地发现主要的控制方面的问题。
自底向上增殖方式缺点:
是对主要的控制方面最后才接触到。
优点:
是不需要建立桩模块,而建立驱动模块,同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试,可以把最容易出问题的部分在早期解决,提高效率。
因此通常把这两种方式结合起来进行组装和测试即混合增殖式测试。
目的:
发现模块连接中的接口可能存在的各种差错
思考问题:
在集成测试阶段,可采用不同的组装方式把模块组装起来形成一个可运行的系统,其中增殖式组装方式包括哪几种?
除增殖式组装方式外还有哪种组装方式?
组装时需要考虑的问题:
穿越接口的数据是否会丢失;一个模块的功能是否会对另一个模块的功能产生不利影响;各子功能组合起来能否达到预期的父功能;全局的数据结构是否有问题;单个模块的误差积累起来是否会放大以至达到不能接受的程度。
集成测试完成的标志:
成功地执行了测试计划中规定的所有集成测试;修正了发现的错误;测试结果通过了专门的小组评审。
问答题:
经过代码审查和单元测试,单个组件的有效性已经得到全面验证,为什么还要进行集成测试?
在集成测试时,增量式集成方法为什么比一次性整体集成方法要好?
参考:
单个组件正常工作并不意味着所有组件集成在一起可以正常工作,因为组件相互连接时接口会引起许多新问题,集成测试正是将通过单元测试的各个组件组装在一起进行综合测试,以便发现与接口有关的各种错误。
整体一次性集成方法可能在测试时发现大量错误,造成定位和纠正错十分困难;增量式集成方法通过逐渐加入组件,可以比较容易定位和纠正错误。
集成测试完成的标志:
成功地执行了测试计划中规定的所有集成测试;修正了发现的错误;测试结果通过了专门的小组评审。
验证测试:
通过检查和提供客观证据,证实规定的需求已满足。
确认测试:
是验证软件的功能和性能及其他特性是否与用户的要求一致。
包括有效性测试和软件配置复查
系统测试:
将通过集成测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起,在实际或者模拟运行(使用)环境下,对计算机系统进行一系列测试。
目的:
通过与系统的需求定义作为比较,发现软件与系统定义不符合或与之矛盾的地方
验收测试:
以用户为主的测试
验收测试的依据是什么?
验收测试对测试环境有何要求?
参考答案:
验收测试根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收。
生产环境,或者软硬件配置接近生产环境的模拟环境。
12、软件失效分类与管理
软件错误:
在软件生存周期内不希望或不可能接受的错误
软件缺陷:
存在软件(文档、数据、程序)之中的那些不希望或不可接受的偏差
软件故障:
软件运行过程中出现的一种不希望或不可接受的内部状态。
软件失效:
软件动行时产生的一种不希望或不可接受的外部状态
缺陷的二八定理
是指一般情况下,软件80%的缺陷集中在20%的模块中。
所以应投入主要的人力物力和精力重点测试这20%的模块,以提高测试效率。
缺陷的二八定理也称为缺陷的集群现象或是虫子窝。
缺陷具有免疫性
注意:
每修复3~4个缺陷,一般会产生1个新的缺陷。
缺陷管理:
(1)软件缺陷与错误划分严重性和优先级的通用原则:
①表示软件缺陷所造成的危害的恶劣程度;
②优先级表示修复缺陷的重要程度与次序。
Ø按严重程度(Severity)划分
致命的,严重的,一般的,建议的
1致命的:
系统崩溃、数据丢失、数据毁坏。
2严重的:
操作性错误、错误结果、遗漏功能。
3一般的:
小问题、错别字、UI布局、罕见错误。
4建议的:
不影响使用的瑕疵或更好的实现。
Ø按优先级(Priority)划分
高(high),中(middle),低(low)
1最高优先级:
立即修复,停止进一步测试。
2次最高优先级:
在产品发布前必须修复。
3中等优先级:
如果时间允许应该修复。
4最低优先级:
可能会修复,但是也能发布
但是严重程度高的Bug其优先级就高吗?
也就是说,Bug的严重程度和优先级一定成正比吗?
不一定!
让我们看下面3个例子:
严重程度高优先级不一定高:
1.如果某个严重的软件缺陷只在非常极端的条件下产生,则没有必要马上解决。
2.如果修正一个软件缺陷,需要重新修改软件的整体架构,可能会产生更多潜在的缺陷,而且软件由于市场的压力必须尽快发布,此时即使缺陷的严重性很高,是否需要修正,需要全盘考虑。
严重程度低优先级不一定低:
1.如果是软件名称或公司名称的拼写错误,虽然说其属于界面错误,严重程度不高,但是其关系到软件和公司的市场形象,必须尽快修正。
可见Bug严重程度和优先级没有必然的联系。
实际工作中,我们需要根据具体情况来判断Bug的严重程度和优先级
Ø按测试种类划分
逻辑功能类(function),性能类(performance),界面类(UI),易用性类(usability),兼容性类(compatibility)
Ø软件产品的Bug的错误类型有哪些?
功能性错误、可靠性错误、易用性错误、效率错误、可维护性错误和可移植性错误。
软件错误跟踪管理:
1)、软件错误跟踪管理
软件错误跟踪管理的软件工具有:
TRACKRECORD、BUZILLA、BMS(国产)等。
记录错误信息及处理错误信息的内容:
(1)BUG记录信息
主要有以下几项内容:
●测试软件名称
●测试版本号
●测试人名称
●测试事件
●测试软件和硬件配置环境
●发现软件错误的类型
●错误的严重等级
●详细步骤
●必要的附图
●测试注释
(2)BUG处理信息(有4项内容)
●处理者姓名
●处理时间
●处理步骤
●错误记录的当前状态
2)软件错误的状态
新信息new),打开(OPEN),修正(fixed),拒绝(DECLINED),关闭(closed)
①新信息(new):
测试中新报告的软件BUG
②打开(OPEN):
被确认并分配给相关开发人员处理
③修正(fixed):
开发人员已完成修正,等待测试人员验证
④拒绝(DECLINED):
拒绝修改BUG
5延期(DEFERRED):
不在当前版本修复的错误,下一版本修复
⑥关闭(closed:
BUG已被修复
3)错误管理流程(有以下几项)
●测试人员提交新的错误入库,错误状态为“NEW”;
●高级测试人员验证错误。
①如果确认是错误,分配给相关的开发人员,设置状态为“OPEN”;
②如果不是错误,则拒绝,设置为“DECLINED”状态。
●开发人查询状态为“OPEN”,做如下处理:
①如果不是错误,则状态置为“DECLINED”;
②如果是错误,则修复并置状态为“FIXED”;
③如果不能解决的错误,要留
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 第12章 软件测试基础 12 软件 测试 基础