软件测试.docx
- 文档编号:30243234
- 上传时间:2023-08-13
- 格式:DOCX
- 页数:24
- 大小:31.82KB
软件测试.docx
《软件测试.docx》由会员分享,可在线阅读,更多相关《软件测试.docx(24页珍藏版)》请在冰豆网上搜索。
软件测试
软件测试
软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试,甚至根据需要编写不同的测试工具,设计和维护测试系统,对测试方案可能出现的问题进行分析和评估。
执行测试用例后,需要跟踪故障,以确保开发的产品适合需求。
概念
使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别.
它是帮助识别开发完成(中间或最终的版本)的计算机软件(整体或部分)的正确度(correctness)、完全度(completeness)和质量(quality)的软件过程;是SQA(softwarequalityassurance)的重要子域。
GrenfordJ.Myers曾对软件测试的目的提出过以下观点:
(1)测试是为了发现程序中的错误而执行程序的过程;
(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案;
(3)成功的测试是发现了至今为止测试。
然而,这种观点指出测试是以查找错误为中心,而不是为了演示软件的正确功能.但是只从字面意思理解,可能会产生误导,认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上并非如此!
(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者
发现当前软件开发过程中的缺陷,以便及时改进;
(2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性;
(3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法
软件测试的内容
软件测试主要工作内容是验证(verification)和确认(validation),下面分别给出其概念:
验证(verification)是保证软件正确地实现了一些特定功能的一系列活动,即保证软件做了你所期望的事情。
(Dotherightthing)
1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程;
2.程序正确性的形式证明,即采用形式理论证明程序符合设计规约规定的过程;
3.评市、审查、测试、检查、审计等各类活动,或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
确认(validation)是一系列的活动和过程,目的是想证实在一个给定的外部环境中软件的逻辑正确性。
即保证软件以正确的方式来做了这个事件(Doitright)
1.静态确认,不在计算机上实际执行程序,通过人工或程序分析来证明软件的正确性;
2.动态确认,通过执行程序做分析,测试程序的动态行为,以证实软件是否存在问题。
软件测试的对象不仅仅是程序测试,软件测试应该包括整个软件开发期间各个阶段所产生的文档,如需求规格说明、概要设计文档、详细设计文档,当然软件测试的主要对象还是源程序。
软件测试的分类
从是否关心软件内部结构和具体实现的角度划分
A.白盒测试
B.黑盒测试
C.灰盒测试
白盒测试
白盒测试也称结构测试或逻辑驱动测试,它是按照程序内部的结构测试程序,通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。
这一方法是把测试对象看作一个打开的盒子,测试人员依据程序内部逻辑结构相关信息,设计或选择测试用例,对程序所有逻辑路径进行测试,通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。
采用什么方法对软件进行测试呢?
常用的软件测试方法有两大类:
静态测试方法和动态测试方法。
其中软件的静态测试不要求在计算机上实际执行所测程序,主要以一些人工的模拟技术对软件进行分析和测试;而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序,而达到发现程序错误的过程。
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。
其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
六种覆盖标准:
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。
语句覆盖每条语句至少执行一次。
判定覆盖每个判定的每个分支至少执行一次。
条件覆盖每个判定的每个条件应取到各种可能的值。
判定/条件覆盖同时满足判定覆盖条件覆盖。
条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
路径覆盖使程序中每一条可能的路径至少执行一次。
"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
"白盒"法是穷举路径测试。
在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。
贯穿程序的独立路径数是天文数字。
但即使每条路径都测试了仍然可能有错误。
第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。
第二,穷举路径测试不可能查出程序中因遗漏路径而出错。
第三,穷举路径测试可能发现不了一些与数据相关的错误。
如何挑选白盒测试工具
白盒测试目前主要用在具有高可靠性要求的软件领域,例如:
军工软件、航天航空软件、工业控制软件等等。
白盒测试工具在选购时应当主要是对开发语言的支持、代码覆盖的深度、嵌入式软件的测试、测试的可视化等。
对开发语言的支持:
白盒测试工具是对源代码进行的测试,测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。
但是对于不同的开发语言,测试工具实现的方式和内容差别是较大的。
目前测试工具主要支持的开发语言包括:
标准C、C++、VisualC++、Java、VisualJ++等。
代码的覆盖深度:
从覆盖源程序语句的详尽程度分析,逻辑覆盖标准包括以下不同的覆盖标准:
语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正判定条件覆盖。
·语句覆盖为了暴露程序中的错误,程序中的每条语句至少应该执行一次。
因此语句覆盖(StatementCoverage)的含义是:
选择足够多的测试数据,使被测程序中每条语句至少执行一次。
语句覆盖是很弱的逻辑覆盖。
·判定覆盖比语句覆盖稍强的覆盖标准是判定覆盖(DecisionCoverage)。
判定覆盖的含义是:
设计足够的测试用例,使得程序中的每个判定至少都获得一次“真值”或“假值”,或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次,因此判定覆盖又称为分支覆盖。
·条件覆盖在设计程序中,一个判定语句是由多个条件组合而成的复合判定。
为了更彻底地实现逻辑覆盖,可以采用条件覆盖(ConditionCoverage)的标准。
条件覆盖的含义是:
构造一组测试用例,使得每一判定语句中每个逻辑条件的可能值至少满足一次。
·多条件覆盖多条件覆盖也称条件组合覆盖,它的含义是:
设计足够的测试用例,使得每个判定中条件的各种可能组合都至少出现一次。
显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
·修正条件判定覆盖修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”,目前在国外的国防、航空航天领域应用广泛。
这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。
它要求满足两个条件:
首先,每一个程序模块的入口和出口点都要考虑至少要被调用一次,每个程序的判定到所有可能的结果值要至少转换一次;其次,程序的判定被分解为通过逻辑操作符(and、or)连接的布尔条件,每个条件对于判定的结果值是独立的。
不同的测试工具对于代码的覆盖能力也是不同的,通常能够支持修正条件判定覆盖的测试工具价格是极其昂贵的。
嵌入式软件的测试:
对于嵌入式软件的测试,我们还需要一方面进一步考虑测试工具对于嵌入式操作系统的支持能力,例如DOS、Vxworks、Neculeus、Linux和WindowsCE等;另一方面还需要考虑测试工具对于硬件平台的支持能力,包括是否支持所有64/32/16位CPU和MCU,是否可以支持PCI/VME/CPCI总线。
测试的可视化:
白盒测试是工作量巨大并且枯燥的工作,可视化的设计对于测试来说是十分重要的。
在选购白盒测试工具时,应当考虑该款测试工具的可视化是否良好,例如:
测试过程中是否可以显示覆盖率的函数分布图和上升趋势图,是否使用不同的颜色区分已执行和未执行的代码段显示分配内存情况实时图表等,这些对于测试效率和测试质量的提高是具有很大的作用的。
白盒测试之基本路径测试法
白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。
其中运用最为广泛的是基本路径测试法。
基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法。
设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。
在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。
包括以下4个步骤和一个工具方法:
1.程序的控制流图:
描述程序控制流的一种图示方法。
2.程序圈复杂度:
McCabe复杂性度量。
从程序的环路复杂性可导出程序基本路径集合中的独立路径条数,这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
3.导出测试用例:
根据圈复杂度和程序结构设计用例数据输入和预期结果。
4.准备测试用例:
确保基本路径集中的每一条路径的执行。
工具方法:
图形矩阵:
是在基本路径测试中起辅助作用的软件工具,利用它可以实现自动地确定一个基本路径集。
程序的控制流图:
描述程序控制流的一种图示方法。
圆圈称为控制流图的一个结点,表示一个或多个无分支的语句或源程序语句
流图只有二种图形符号:
图中的每一个圆称为流图的结点,代表一条或多条语句。
流图中的箭头称为边或连接,代表控制流
任何过程设计都要被翻译成控制流图。
如何根据程序流程图画出控制流程图?
在将程序流程图简化成控制流图时,应注意:
在选择或多分支结构中,分支的汇聚处应有一个汇聚结点。
边和结点圈定的区域叫做区域,当对区域计数时,图形外的区域也应记为一个区域。
基本路径测试法的步骤:
第一步:
画出控制流图
流程图用来描述程序控制结构。
可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。
在流图中,每一个圆,称为流图的结点,代表一个或多个语句。
一个处理方框序列和一个菱形决测框可被映射为一个结点,流图中的箭头,称为边或连接,代表控制流,类似于流程图中的箭头。
一条边必须终止于一个结点,即使该结点并不代表任何语句(例如:
if-else-then结构)。
由边和结点限定的范围称为区域。
计算区域时应包括图外部的范围。
第二步:
计算圈复杂度
圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量,将该度量用于计算程序的基本的独立路径数目,为确保所有语句至少执行一次的测试数量的上界。
独立路径必须包含一条在定义之前不曾用到的边。
有以下三种方法计算圈复杂度:
流图中区域的数量对应于环型的复杂性;
给定流图G的圈复杂度V(G),定义为V(G)=E-N+2,E是流图中边的数量,N是流图中结点的数量;
给定流图G的圈复杂度V(G),定义为V(G)=P+1,P是流图G中判定结点的数量。
第三步:
导出测试用例 根据上面的计算方法,可得出四个独立的路径。
(一条独立路径是指,和其他的独立路径相比,至少引入一个新处理语句或一个新判断的程序通路。
V(G)值正好等于该程序的独立路径的条数。
)
路径1:
4-14
路径2:
4-6-7-14
路径3:
4-6-8-10-13-4-14
路径4:
4-6-8-11-13-4-14
根据上面的独立路径,去设计输入数据,使程序分别执行到上面四条路径。
白盒测试三步法
1)根据代码的功能,人工设计测试用例进行基本功能测试;
2)统计白盒覆盖率,为未覆盖的白盒单位设计测试用例,实现完整的白盒覆盖,比较理想的覆盖率是实现100%语句、条件、分支、路径覆盖;
3)自动生成大量的测试用例,捕捉"程序员未处理某些特殊输入"形成的错误。
第1步的测试用例通常是现成的,因为详细设计文档会规定程序的基本功能,没有文档的,程序员在编程时也要想清楚程序的功能,这些基本功能就是基本测试用例;
第2步是在第1步的基础上,检查未覆盖的白盒单位,由于未覆盖的逻辑单位通常对应未测试的等价类,因此第2步可以找出第1步所遗漏的测试用例;
第3步用自动动态测试弥补第2步的固有缺陷。
"三步法"尽量避免重复工作,白盒方法和黑盒方法相结合,人工方法和自动方法相补充,如果第2步的覆盖率比较理想,那么基本上可以保证找出所有等价类。
在开发过程允许的限度内,"三步法"已接近极限,当得起"彻底测试"四个字。
黑盒测试与白盒测试区别
黑盒测试
黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。
黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。
“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。
实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。
白盒测试
白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
“白盒”法是穷举路径测试。
在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。
贯穿程序的独立路径数是天文数字。
但即使每条路径都测试了仍然可能有错误。
第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。
第二,穷举路径测试不可能查出程序中因遗漏路径而出错。
第三,穷举路径测试可能发现不了一些与数据相关的错误。
软件人员使用白盒测试方法,主要想对程序模块进行如下的检查:
–对程序模块的所有独立的执行路径至少测试一次;
–对所有的逻辑判定,取“真”与取“假”的两种情况都至少测试一次;
–在循环的边界和运行界限内执行循环体;
–测试内部数据结构的有效性,等。
具体包含的逻辑覆盖有:
–语句覆盖–判定覆盖–条件覆盖–判定-条件覆盖–条件组合覆盖–路径覆盖。
白盒测试技术(WhiteBoxTesting):
深入到代码一级的测试,使用这种技术发现问题最早,效果也是最好的。
该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段,开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。
这一阶段测试以软件开发人员为主,在JAVA平台使用Xunit系列工具进行测试,Xunit测试工具是类一级的测试工具对每一个类和该类的方法进行测试。
黑盒测试技术(BlackBoxTesting):
黑盒测试的内容主要有以下几个方面,但是主要还是功能部分。
主要是覆盖全部的功能,可以结合兼容,性能测试等方面进行,根据软件需求,设计文档,模拟客户场景随系统进行实际的测试,这种测试技术是使用最多的测试技术涵盖了测试的方方面面,可以考虑以下方面
c正确性(Correctness):
计算结果,命名等方面。
d可用性(Usability):
是否可以满足软件的需求说明。
e边界条件(BoundaryCondition):
输入部分的边界值,就是使用一般书中说的等价类划分,试试最大最小和非法数据等等。
f性能(Performance):
正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间在可以接受范围内。
J2EE技术实现的系统在性能方面更是需要照顾的,一般原则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了。
如果在测试过程中发现性能问题,修复起来是非常艰难的,因为这常常意味着程序的算法不好,结构不好,或者设计有问题。
因此在产品开发的开始阶段,就要考虑到软件的性能问题
g压力测试(Stress):
多用户情况可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行。
如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况,如果有必要可以模拟大量数据输入,对硬盘的影响等等信息。
如果有必要的话必须进行性能优化(软硬件都可以)。
这里的压力测试针对的是某几项功能。
h错误恢复(ErrorRecovery):
错误处理,页面数据验证,包括突然间断电,输入脏数据等。
i安全性测试(Security):
这个领域正在研究中,防火墙、补丁包、杀毒软件等的就不必说了,不过可以考虑。
破坏性测试时任意看了一些资料后得知,这里面涉及到的知识、内容可以写本书了,不是一两句可以说清的,特别是一些商务网站,或者跟钱有关,或者和公司秘密有关的web更是需要这方面的测试,在外国有一种专门干这一行的人叫安全顾问,可以审核代码,提出安全建议,出现紧急事件时的处理办法等,在国内没有听说哪里有专门搞安全技术测试的内容。
j兼容性(Compatibility):
不同浏览器,不同应用程序版本在实现功能时的表现不同的上网方式,如果你测试的是一个公共网站的话。
从是否执行程序的角度
A.静态测试
B.动态测试。
从软件开发的过程按阶段划分有
A.单元测试
B.集成测试
C.确认测试
D.系统测试
E.验收测试
*测试过程按4个步骤进行,即单元测试、集成测试、确认测试和系统测试及发版测试。
*开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。
*集成测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。
*确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。
*系统测试把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。
单元测试(UnitTesting)
*单元测试又称模块测试,是针对软件设计的最小单位─程序模块,进行正确性检验的测试工作。
其目的在于发现各模块内部可能存在的各种差错。
*单元测试需要从程序的内部结构出发设计测试用例。
多个模块可以平行地独立进行单元测试。
1.单元测试的内容
*在单元测试时,测试者需要依据详细设计说明书和源程序清单,了解该模块的I/O条件和模块的逻辑结构,主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理的输入和不合理的输入,都能鉴别和响应。
(1)模块接口测试
*在单元测试的开始,应对通过被测模块的数据流进行测试。
测试项目包括:
–调用本模块的输入参数是否正确;
–本模块调用子模块时输入给子模块的参数是否正确;
–全局量的定义在各模块中是否一致;
*在做内外存交换时要考虑:
–文件属性是否正确;
–OPEN与CLOSE语句是否正确;
–缓冲区容量与记录长度是否匹配;
–在进行读写操作之前是否打开了文件;
–在结束文件处理时是否关闭了文件;
–正文书写/输入错误,
–I/O错误是否检查并做了处理。
(2)局部数据结构测试
*不正确或不一致的数据类型说明
*使用尚未赋值或尚未初始化的变量
*错误的初始值或错误的缺省值
*变量名拼写错或书写错
*不一致的数据类型
*全局数据对模块的影响
(3)路径测试
*选择适当的测试用例,对模块中重要的执行路径进行测试。
*应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
*对基本执行路径和循环进行测试可以发现大量的路径错误。
(4)错误处理测试
*出错的描述是否难以理解
*出错的描述是否能够对错误定位
*显示的错误与实际的错误是否相符
*对错误条件的处理正确与否
*在对错误进行处理之前,错误条件是否已经引起系统的干预等
(5)边界测试
*注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。
对这些地方要仔细地选择测试用例,认真加以测试。
*如果对模块运行时间有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响模块运行时间的因素。
2.单元测试的步骤
*模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与被测模块相联系的其它模块。
–驱动模块(driver)
–桩模块(stub)──存根模块
*如果一个模块要完成多种功能,可以将这个模块看成由几个小程序组成。
必须对其中的每个小程序先进行单元测试要做的工作,对关键模块还要做性能测试。
*对支持某些标准规程的程序,更要着手进行互联测试。
有人把这种情况特别称为模块测试,以区别单元测试。
集成测试(IntegratedTesting)
*集成测试(集成测试、联合测试)
*通常,在单元测试的基础上,需要将所有模块按照设计要求组装成为系统。
这时需要考虑的问题是:
–在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;
–一个模块的功能是否会对另一个模块的功能产生不利的影响;
–各个子功能组合起来,能否达到预期要求的父功能;
–全局数据结构是否有问题;
–单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。
在单元测试的同时可进行集成测试,
发现并排除在模块连接中可能出现
的问题,最终构成要求的软件系统。
*子系统的集成测试特别称为部件测试,它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
*通常,把模块集成成为系统的方式有两种
–一次性集成方式
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试