软件测试复习资料 西工大.docx
- 文档编号:11934813
- 上传时间:2023-04-16
- 格式:DOCX
- 页数:34
- 大小:358.47KB
软件测试复习资料 西工大.docx
《软件测试复习资料 西工大.docx》由会员分享,可在线阅读,更多相关《软件测试复习资料 西工大.docx(34页珍藏版)》请在冰豆网上搜索。
软件测试复习资料西工大
第1章概述
为什么要进行软件测试?
就是因为软件缺陷的存在。
因为只有通过测试,才可以发现软件缺陷。
也只有发现了缺陷,才可以将软件缺陷从软件产品或软件系统中清理出去。
软件缺陷是任何程序、系统中的问题,和产品设计书的不一致性,不能满足用户的需求IEEE国际标准729给出了软件缺陷的定义——软件缺陷就是软件产品中所存在的问题,最终表现为用户所需要的功能没有完全实现,不能满足或不能全部满足用户的需求
根据软件缺陷的定义,可以从两方面考虑:
☐从产品内部看,软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题;
☐从外部看,软件缺陷是系统所需要实现的某种功能的失效或违背。
软件缺陷的主要类型/现象:
☐功能、特性没有实现或部分实现
☐设计不合理,存在缺陷
☐实际结果和预期结果不一致
☐运行出错,包括运行中断、系统崩溃、界面混乱
☐数据结果不正确、精度不够
☐用户不能接受的其他问题,如存取时间过长、界面不美观
软件缺陷的产生
1技术问题,算法错误,语法错误,计算和精度问题,接口参数传递不匹配
2团队工作误解、沟通不充分
3软件本身文档错误、用户使用场合(userscenario),时间上不协调、或不一致性所带来的问题,系统的自我恢复或数据的异地备份、灾难性恢复等问题
验证和确认
Verification:
Arewebuildingtheproductright?
是否正确地构造了软件?
即是否正确地做事,验证开发过程是否遵守已定义好的内容。
验证产品满足规格设计说明书的一致性
Validation:
Arewebuildingtherightproduct?
是否构造了正是用户所需要的软件?
即是否正在做正确的事。
验证产品所实现的功能是否满足用户的需求
需求评审和设计评审是验证软件产品的需求定义和设计实现,验证所定义的产品特性是否符合客户的期望、系统的设计是否合理、是否具有可测试性以及满足非功能质量特性的要求。
这个阶段主要通过对需求文档、设计文档等阅读、讨论,从中发现软件需求工程和系统设计中所存在的问题。
产品需求审查是软件开发重要环节之一,也是测试活动之一,即静态测试——需求验证。
需求评审归为静态测试范畴,包含了文档评审和技术评审双重内容,通常通过正式的评审会议来进行。
而测试人员主要起着评审员的作用,检查需求定义是否合理和清楚。
单元测试的对象是程序系统中的最小单元---模块或组件上,在编码阶段进行,针对每个模块进行测试,主要通过白盒测试方法,从程序的内部结构出发设计测试用例,检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。
多个模块可以平行地、对立地测试,通常要编写驱动模块和桩模块
单元测试一般由编程人员和测试人员共同完成
集成测试,也称组装测试、联合测试、子系统测试,在单元测试的基础上,将模块按照设计要求组装起来同时进行测试,主要目标是发现与接口有关的模块之间问题
两种集成方式:
一次性集成方式和增殖式集成方式。
功能测试,依据产品设计规格说明书完成对产品功能进行操作,以验证系统是否满足用户的功能性需求
系统测试是将软件放在整个计算机环境下,包括软硬件平台、某些支持软件、数据和人员等,在实际运行环境下进行一系列的测试,包括恢复测试、安全测试、强度测试和性能测试等
第2章需求和设计评审
产品需求审查是软件开发重要环节之一,也是测试活动之一,即静态测试——需求验证。
借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映,并使各类开发人员在需求理解上达成一致
软件评审是对软件元素或者项目状态的一种评估手段,以确定其是否与计划的结果保持一致,并使其得到改进。
技术评审
文档评审
管理(流程)评审
检查表(checklist)是一种常用的的质量保证手段,也是正式技术评审的必要工具,评审过程往往由检查表驱动。
一份精心设计的检查表,对于提高评审效率、改进评审质量具有很大帮助。
☐可靠性。
人们借助检查表以确认被检查对象的所有质量特征均得到满足,避免遗漏任何项目。
☐效率。
检查表归纳了所有检查要点,比起冗长的文档,使用检查表具有更高的工作效率。
软件缺陷并不只是在编程阶段才产生,需求和设计阶段同样会产生缺陷。
测试需求
测试目标取决于软件质量需求,而这种需求分为功能性需求和非功能性需求,功能性的需求相对容易确定,非功能性的测试需求难以确定。
☐在制定测试计划之前,必须清楚测试需求
☐明确测试需求的优先级
☐测试需求分解得越细,对测试用例的设计质量越有帮助
☐详细的测试需求还是衡量测试覆盖率的重要依据
☐测试需求是规划具体项目资源和时间的基础。
功能性测试需求
功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求,包括用户界面的友好性。
☐程序安装、启动正常,有相应的提示框、错误提示
☐各项功能符合设计要求,正常运行并输出正确结果
☐功能逻辑合理,并能处理各种异常操作
☐能接受正确的数据输入,输出结果准确,格式清晰
☐系统的各种状态按照业务流程而变化并保持稳定
☐支持各种应用环境,能配合硬件设备
非功能性需求
非功能性质量需求,包括系统性能、安全性、兼容性、扩充性,其测试需求会因不同的项目类型差异较大
☐客户端软件,如字处理软件、媒体播放软件等占用较少资源,在容错性、兼容性等方面要求高。
☐Web应用系统对性能、安全性等有很高要求
☐客户端/服务器应用系统。
☐大型复杂企业级系统。
需求评审归为静态测试范畴,包含了文档评审和技术评审双重内容,通常通过正式的评审会议来进行。
而测试人员主要起着评审员的作用,检查需求定义是否合理和清楚。
设计审查
成功的产品开发和演化依赖于体系结构恰当的选择。
软件设计一般可以分为体系结构设计和详细设计。
测试人员参与设计评审保证需求能在设计中得到准确和完整的表示,也就是保证产品规格说明书的质量。
☐系统架构的审查
☐设计规格说明书的审查
☐系统部署设计的审查
☐多层次审查:
high-levellow-level
系统设计的评审标准
☐设计技术评审标准。
稳定、清晰、合理
☐非功能性质量特性的设计评审要求。
安全、性能、稳定、扩展、可靠。
☐评审的输入:
体系结构文档、设计规范与指南、风险列表
☐评审的输出:
经认可的软件体系结构文档、变更需求、评审记录
☐评审的检查点:
软件体系结构、设计模式、部署视图、进程视图、封装体、协议。
第3章测试用例设计
测试用例(testcase)是可以被独立执行的一个过程,这个过程是一个最小的测试实体,不能再被分解。
测试用例也就是为了某个测试点而设计的测试操作过程序列、条件、期望结果及其相关数据的一个特定的集合。
测试用例要描述
Why——为什么而测?
What——测什么?
Where——在哪里测?
When——什么时候开始测?
Which——哪些输入数据?
How——如何操作软件?
为什么需要测试用例
☐如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标。
☐测试用例是测试工作的指导,是软件测试的必须遵守的准则,更是软件测试质量稳定的根本保障。
☐软件测试是有组织性、步骤性和计划性的,为了能将软件测试的行为转换为可管理的、具体量化的模式,需要创建和维护测试用例
单个测试用例的质量要求
v具有可操作性
v具备所需的各项信息
v各项信息描述准确、清楚
v测试目标针对性强
v验证点完备,而且没有太多的验证点
v没有太多的操作步骤,例如不超过7步
v符合正常业务惯例。
整体测试用例的质量要求
v覆盖率。
依据特定的测试目标的要求,尽可能覆盖所有的测试范围、功能特性和代码。
v易用性。
测试用例的设计思路清晰、组织结构层次合理,测试用例操作的连贯性好,使单个模块的测试用例执行顺畅。
v易维护性。
应该以很少的时间来完成测试测试用例的维护工作,包括添加、修改和删除测试用例。
易用性和易读性,也有助于易维护性。
v粒度适中。
既能覆盖各个特定的场景,保证测试的效率;又能处理好不同数据输入的测试要求,提高测试用例的可维护性。
良好测试用例的特征
v可以最大程度地找出软件隐藏的缺陷
v可以最高效率的找出软件缺陷
v可以最大程度地满足测试覆盖要求
v既不过分复杂、也不能过分简单
v使软件缺陷的表现可以清楚的判定
▪测试用例包含期望的正确的结果
▪待查的输出结果或文件必须尽量简单明了
v不包含重复的测试用例
v测试用例内容清晰、格式一致、分类组织
第4章自动化测试
自动化测试(automatedtest)是相对手工测试(manualtest)而存在的一个概念,由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。
测试工具的使用是自动化测试的主要特征
自动化测试焦点集中在测试执行,主要是由测试工具自动地完成测试。
测试自动化指“一切可以由计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行”
自动化测试测试工具测试执行单项活动
测试自动化理念全过程所有测试活动包括测试设计测试管理
在系统功能逻辑测试、验收测试、适用性测试、涉及交互性测试时,多采用手工测试方法;
单元测试、集成测试、系统负载或性能、可靠性测试等比较适合采用TA;
对那种不稳定、开发周期短或一次性的软件等不适合TA
工具本身缺乏想象力和创造性,自动测试只能发现15%的缺陷,而手工测试可以发现85%的缺陷;
代码分析
代码的静态分析的关键是建立各种规则,而这种规则的建立是依赖于相应编程语言的语法。
如依据EBNF(扩展巴科斯-诺尔范式)对Java代码的分析。
脚本技术
线性脚本,是录制手工执行的测试用例得到的脚本,这种脚本包含所有的击键、移动、输入数据等,所有录制的测试用例都可以得到完整的回放。
结构化脚本,类似于结构化程序设计,具有各种逻辑结构、函数调用功能。
数据驱动脚本,将测试输入存储在独立的(数据)文件中,而不是存储在脚本中。
关键字驱动脚本,是数据驱动脚本的逻辑扩张
开源工具解决方案
v单元测试:
JUnit&XUnit家族
v功能测试:
Selenium、AbboAutoIT/AutoHotkey
v性能测试:
JMeter
v数据库:
DBprobe
v网络监控:
Wireshark/Ethereal,Netcat,Snort
第5章单元测试
单元测试就是对已实现的软件最小单元进行测试,以保证构成软件系统的各个单元的质量
单元测试活动中,强调被测试对象的独立性
单元测试应从各个层次来对单元内部算法、外部功能实现等进行检验,包括对程序代码的评审和通过运行单元程序来验证其功能特性等内容。
单元测试的目标
单元实现了其特定的功能,如果需要,返回正确的值
单元的运行能够覆盖预先设定的各种逻辑
在单元工作过程中,其内部数据能够保持完整性,包括全局变量的处理、内部数据的形式、内容及相互关系等不发生错误
可以接受正确数据,也能处理非法数据,在数据边界条件上,单元也能够正确工作
该单元的算法合理,性能良好
该单元代码经过扫描,没有发现任何安全性问题
单元测试主要采用白盒测试方法,辅以黑盒测试方法。
白盒测试方法应用于代码评审、单元程序检验之中,而黑盒测试方法则应用于模块、组件等大单元的功能测试之中
黑盒测试方法(Blake-boxTesting),是把程序看作一个不能打开的黑盒子,不考虑程序内部结构和内部特性,而是考察数据的输入、条件限制和数据输出,完成测试
白盒测试方法(White-boxTesting),也称结构测试或逻辑驱动测试。
白盒测试方法是根据模块内部结构了解,基于内部逻辑结构,针对程序语句、路径、变量状态等来进行测试,检验程序中的各个分支条件是否得到满足、每条执行路径是否按预定要求正确的工作。
驱动程序(driver),对底层或子层模块进行(单元或集成)测试时所编制的调用被测模块的程序,用以模拟被测模块的上级模块
桩程序(stub),也有人称为存根程序,对顶层或上层模块进行测试时,所编制的替代下层模块的程序,用以模拟被测模块工作过程中所调用的模块。
白盒方法的目标
v语句覆盖,使得程序中每一条可执行语句至少被执行一次
v分支覆盖,使得程序中每一个分支都至少被执行一次
v条件覆盖,程序中每一个条件至少有一次被满足
v路径覆盖,对程序模块的所有独立的基本路径至少要测试一次
环路复杂性
vV(G)=区域数目
vV(G)=边界数目–节点数目+2
vV(G)=判断节点数目+1
v示例计算结果:
V(G)=4
MCDC
vMC/DC背后的原则是每个子条件必须表现为独立的影响结果。
v在子条件不独立的情况下,MC/DC或许是不可能的
v这是由于程序的逻辑而不是由于工具的限制
v在这些情况下不可能达到100%的MC/DC
代码规范性的审查
v代码规范性的审查将助于更早地发现缺陷,代码质量的提高,而且可以帮助程序员遵守规则、养成好的习惯,以达到预防缺陷的目的
v代码风格和编程规则两者不可缺一,都应列入代码评审的范围里
v命名规则、缩进与对齐、注释和函数处理等
代码缺陷检查表
把程序设计中可能发生的各种缺陷进行分类,以每一类列举尽可能多的典型缺陷,形成代码缺陷检查表。
代码评审常常会使用这类检查表,以表的内容为检查依据、要点,防止人为的疏漏,并提高评审效率。
在每次评审之后,对新发现的缺陷也要进行分析、归类,不断充实缺陷检查表
复杂度度量
控制流结点圈复杂度基本结点和基本圈复杂度循环嵌套和结构化(时间间隔)函数的扇入,扇出不可达性
圈复杂度
例子:
12边
9节点
VG=12-9+2=5
圈复杂度和结点度量是相互补足的.
一般而言,程序结构度量测量了软件属性的`大小'.
圈复杂度是问题复杂性的一个指示.
‘结点’度量了由程序执行产生的附加复杂性.
集成测试的模式
渐增式集成模式与非渐增式集成模式
非渐增式测试模式:
先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序,如大棒模式。
渐增式测试模式:
把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试。
驱动程序/驱动模块(driver),用以模拟被测模块的上级模块。
驱动模块在集成测试中接受测试数据,把相关的数据传送给被测模块,启动被测模块,并打印出相应的结果。
桩程序/桩模块(stub),也有人称为存根程序,用以模拟被测模块工作过程中所调用的模块。
桩模块由被测模块调用,它们一般只进行很少的数据处理,例如打印入口和返回,以便于检验被测模块与其下级模块的接口
采用三明治方法的优点是:
它将自顶向下和自底向上的集成方法有机地结合起来,不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。
采用这种方法的主要缺点是:
在真正集成之前每一个独立的模块没有完全测试过。
第6章功能测试
功能测试,依据产品设计规格说明书完成对产品功能进行操作,以验证系统是否满足用户的功能性需求
功能测试用例的设计
☐6.2.1等价类划分法
☐6.2.2边界值分析法
☐6.2.3循环结构测试的综合方法
☐6.2.4因果图法
☐6.2.5决策表方法
☐6.2.6功能图法
☐6.2.7正交试验设计方法
等价类法
v等价类是某个输入域的子集,在该子集中每个输入数据的作用是等效的
v将程序可能的输入数据分成若干个子集,从每个子集选取一个代表性的数据作为测试用例,、
v在分析需求规格说明的基础上划分等价类,列出等价类表
设计测试用例时,要同时考虑这两种等价类。
因为软件不仅要能接收合理的数据,也要能经受意外的考验。
经过正反的测试才能确保软件具有更高的可靠性。
有效等价类和无效等价类
v有效等价类是有意义的、合理的输入数据,可以检查程序是否实现了规格说明中所规定的功能和性能
v无效等价类和有效等价类相反,即不满足程序输入要求或者无效的输入数据构成的集合
边界值计方法
程序的很多错误发生在输入或输出范围的边界上,因此针对各种边界情况设置测试用例,可以更有效地发现缺陷。
设计方法:
确定边界情况(输入或输出等价类的边界)
选取正好等于、刚刚大于或刚刚小于边界值作为测试数据
循环结构测试
v循环结构在软件程序中应用较多,但其测试用例的设计需要采用综合方法
v将白盒方法和黑盒方法结合起来,将条件覆盖方法、路径覆盖方法和黑盒测试方法中的等价类划分、边界值分析相结合起来,才能解决问题。
v循环结构有单循环、嵌套循环、并列循环等多种形式。
从单循环结构开始,逐步深入地进行讨论
嵌套循环结构
1.除最内层循环外,从最内层循环开始,置所有其它层的循环为最小值。
2.对最内层循环做简单循环结构的全部测试。
测试时保持所有外层循环的循环变量取最小值,另外,对越界值和非法值做类似的测试。
3.逐步外推,对其外面一层循环进行测试。
测试时保持所有外层循环的循环变量取最小值,所有其它嵌套内层循环的循环变量取“典型”值。
4.反复进行,直到所有各层循环测试完毕。
并列循环结构
•独立循环,没有依赖性,可以看作两个单循环结构
•非独立循环,则可以看作嵌套循环结构
因果图法
v在实际应用的测试之中,经常碰到多种条件及其组合的情况
v通过因果图,可以建立输入条件和输出之间的逻辑模型,从而比较容易确定输入条件组合和输出之间的逻辑关系,有利于设计全面的测试用例
设计步骤
v分析软件规格说明书中的输入输出条件并划分出等价类,将每个输入输出赋予一个标志符
v分析规格说明中的语义,通过这些语义来找出多个输入因素之间的关系。
v找出输入因素与输出结果之间的关系,将对应的输入与输出之间的关系关联起来,并将其中不可能的组合情况标注成约束或者限制条件,形成因果图。
v由因果图转化成决策表,任何由输入与输出之间关系构成的路径,形成决策表的一列
v将决策表的每一列拿
决策表方法
一个决策表由“条件和活动”两部分组成,也就是列出了一个测试活动执行所需的条件组合。
所有可能的条件组合定义了一系列的选择,而测试活动需要考虑每一个选择。
v条件桩,列出问题的所有条件
v动作桩:
列出可能针对问题所采取的操作
v条件项:
针对所列条件的具体赋值(可取真值和假值)
v动作项:
列出在条件项组合情况下应该采取的动作
v规则:
任何一个条件组合的特定取值及其相应要执行的操作
根据输入3条边(a、b、c)边长的值来判断是否构成一个三角形,如果是三角形,继续判断是等腰三角形还是等边三角形等
v如果不能构成三角形,则不需要判断后3个条件
v如果构成三角形,即a+b>c、a+c>b和b+c>a都必须成立,没有例外
v如果a=b且a=c,则b=c肯定成立
v如果a=b,而a=c不成立,就不需要判断b=c,实际上b=c也肯定不能成立,只能为等腰三角形
功能图法
每个程序的功能通常由静态说明和动态说明组成,静态说明描述了输入条件和输出条件之间的对应关系,而动态说明描述了输入数据的次序或者转移的次序。
功能图法就是为了解决动态说明问题的一种测试用例的设计方法
功能图由状态迁移图(statetransitiondiagram,STD)和逻辑功能模型(logicfunctionmodel,LFM)构成
状态迁移图,描述系统状态变化的动态信息——动态说明,由状态和迁移来描述,状态指出数据输入的位置(或时间),而迁移则指明状态的改变
功能图法是综合运用黑盒方法和白盒方法来设计测试用例,即整体上选用白盒方法——路径覆盖、分支和条件覆盖等,而局部上选用的是黑盒方法——决策表或因果图方法
从功能逻辑模型(决策表或因果图)导出局部测试用例,即设计测试用例覆盖某个状态的各种输入数据的组合
从状态迁移图导出整体的测试用例,以覆盖系统(程序)控制的逻辑路径
可用性
可用性是指以有效性、效率和满意度为指标,产品在特定使用背景下为了特定的目的可为特定用户使用的程度
v满意:
对用户界面赏心悦目的程度。
v可学习性:
用户第一次使用软件时完成基本任务的容易程度。
v效率:
一旦用户学会了使用,完成任务的速度
v可记忆性:
当用户在一段时间没有使用产品,重新使用产品,再次达到熟练程度的容易程度。
v正确性:
用户会碰到多少错误?
系统又如何从错误中恢复
软件可用性测试,仅靠软件组织的内部测试是不够的,还需要真正的用户参与,并观察他们的表情、行为,这需要建立专业的适用性测试实验室
回归测试策略
1.测试全部用例,选择测试用例库中的全部测试用例构成回归测试套件。
2.基于风险选择测试,基于一定的风险标准来从测试用例库中构造缩减的回归测试用例套件。
3.基于操作剖面选择测试,会优先选择那些最重要或最频繁使用功能所关联的测试用例(如80-20原则中20%的重要功能),有助于发现那些对质量有显著影响的缺陷,而放弃次要功能关联的测试用例。
4.测试修改的部分。
1.通过代码相依分析,识别出软件中被修改的部分和影响的范围。
2.从原有测试用例基线库中,排除不再适用的测试用例,确定那些对新的软件版本依然有效的测试用例,从而建立起新的测试用例基线库T0。
3.基于操作剖面和风险选择相结合的策略,从新的测试用例基线库中选择测试用例构造有效的套件,测试被修改的软件。
4.如果回归测试套件不能达到所需的覆盖要求,必须补充新的测试用例使覆盖率达到规定的要求,生成新的测试用例集T1,用于测试T0无法充分测试的软件部分。
5.用T1执行修改后的软件。
第7章国际化和本地化测试
本地化的概念
软件本地化是在源语言版本的基础上,通过翻译、定制和参数配置等工作,使软件产品或系统在语言、时区、度量衡、文化、风俗习惯等各个方面与当地国家和地区的相应内容相一致,从而满足特定地区的用户的使用需求。
国际化的概念
国际化为保证所开发的软件能适应全球市场的本地化工作而不需要对程序做任何系统性或结构性变化的特性,这种特性通过特定的系统设计、程序设计、编码方法来实现
国际化测试方法
v设计评审和代码审查
v针对源语言的功能测试,如不同的区域设置、不同的时区显示
v针对伪翻译(pseudocode,pseudo-translation)版本的测试
本地化测试
v7.3.1软件本地化的实现
v7.3.2功能测试
v7.3.3数据格式验证
v7.3.4UI验证
v7.3.5配置和兼容性验证
v7.3.6翻译验证
技术层面的更改
调整大小、调整默认设置、重新编译、创建新的图形、重新编排文档格式;
文化层面的更改
包装、图标、宣传、样品、政治
敏感的术语,地方规章和宗教信仰
功能性测试,所有基本功能、安装、升级等测试;
☐翻译测试,包括语言完整性、术语准确性等的检查;
☐可用性测试,包括用户界面、度量衡和时区等;
☐兼容性调试,包括硬件兼容性、版本兼容性等测试;
☐文化、宗教、喜好等适用性测试
☐手册验证,包括联机文件、在线帮助、PDF文件等测试
不仅要查看用户界面,而且要对文件保存、打印等类似的功能进行测试,特别要注意语言环境特定的组件,比如时间、日期格式以及文字处理等相关方面的功能进行测试。
软件
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件测试复习资料 西工大 软件 测试 复习资料