软件测试基础总结Word文档格式.docx
- 文档编号:20586572
- 上传时间:2023-01-24
- 格式:DOCX
- 页数:21
- 大小:300.95KB
软件测试基础总结Word文档格式.docx
《软件测试基础总结Word文档格式.docx》由会员分享,可在线阅读,更多相关《软件测试基础总结Word文档格式.docx(21页珍藏版)》请在冰豆网上搜索。
本地化测试
配置测试
按是否运行程序划分
静态测试:
动态测试:
其他测试术语
确然测试
回归测试
冒烟测试
随机测试
猴子测试
常见的测试策略
常见软件测试工具
功能自动化测试工具
UFT
Selenium
WinRunner
SikTest
性能自动化测试工具
LoadRunner
Jmeter
WebLOAD
WAS
测试管理工具
禅道
软件测试流程
测试需求分析阶段(主要负责人:
PM(项目/产品经理))
测试计划制定阶段(主要负责人:
PM)
测试用例设计阶段(主要负责人:
测试人员全体)
测试数据准备
获取测试数据
数据与处理的方法
映射数据缩放数据处理噪声与错误处理未知属性数值离散化数值连续性属性选择
属性构造和变换数据选择与构造数据集成
测试环境的搭建
测试执行阶段(主要负责人:
测试经理和测试工程师)
缺陷记录和跟踪
回归测试
测试总结阶段(主要负责人:
测试经理)
测试文件归档
2.2软件测试过程模型
V模型(局限:
仅把测试作为编码之后的一个阶段,是针对程序进行的寻找错误,忽视了测试活动对需求分析、系统设计等活动的验证和确认功能)W模型(局限性:
无法支持迭代)
H模型:
在H模型中,软件测试模型是一个独立的流程,贯穿于整个产品周期,与其他流程并发地进行。
测试准备点
测试执行点
测试流程点
其他就绪点(如开发流程/设计流程)
(1)软件测试不仅仅指测试的执行,还包括测试准备工作。
(2)软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。
(3)软件测试要尽早准备,尽早执行。
4)软件测试是根据被测物的不同而分层次进行的,支持被测物的多次迭代。
2.3软件测试的原则
所有的测试最终都应该以用户为主;
应尽量开展软件测试工作;
软件测试中的Pareto法则
(Pareto法则又称为80/20效率法则,Pareto法则暗示:
软件测试发现的80%的错误很可能起源于20%的程序模块。
程序员应该尽量避免测试自己编写的程序;
穷尽测试是不可能的;
软件测试是有风险的;
Good-Enough原则
( 既不要做过多的测试,也不要做不充分的测试,这就是“Good-Enough原则”,也就是说当软件测试到达一个“最优工作量”的时候就停止测试。
程序中存在的软件缺陷的可能性与该部分已经发现的缺陷成正比;
软件测试经常会有免疫现象发生;
无法通过软件测试发现所有的软件缺陷;
并非所有的软件缺陷都会修复;
前进两步,后退一步。
测试计划的定义
软件测试计划包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。
借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通、跟踪和控制测试进度,应对测试过程中的各种变更。
测试计划的作用
(1)软件测试计划是保证项目成功的重要因素之一;
(2)管理者可以根据测试计划做宏观调控,进行相应资源的配置管理;
(3)可以增加团队间交流,使测试人员了解整个项目不同阶段所要进行的工作安排;
(4)便于其他成员了解测试人员的工作内容,配合有关工作;
(5)如果是项目式软件的话,可以通过测试计划交代的内容,比如测试过程、人员技能、资源、使用工具等信息,给客户信
5w原则
制定测试计划时需要考虑的最重要的6个要素。
牢记这6点,会使制定测试计划的工作变得容易起来。
虽然软件测试计划一般是由测试经理去编写,但作为软件测试新手,也要准备着向测试经理为测试计划提供内容。
为什么要对测试计划进行审评
测试计划编写完成后,一般要对测试计划的正确性、全面性以及可行性等进行评审,评审人员的组成包括项目经理、软件开发人员、测试人员、测试负责人以及其他有关负责人。
如果没有经过评审,直接发送给测试团队,测试计划内容可能不准确或遗漏。
因为可能需求发生了变更,而测试计划没有及时更新,也有可能受编写人员自身经验和对软件需求的理解所限而导致内容不完善。
一.黑盒测试基本思路:
1.通过测试:
通过测试是指确认软件能做什么。
软件测试人员只是运用最简单、最直观的测试用例进行测试,在设计和执行测试用例时,总是先进行“通过测试”,验证软件的基本功能是否都已实现。
这些通常体现在冒烟测试用例里面。
2.失败测试:
失败测试是指在确信软件能正确运行以后,就可以采取各种手段通过搞垮软件的方式来找出缺陷。
这种纯粹为了破坏软件而设计和执行的测试用例,就叫失败测试或者叫做异常测试用例。
二.等价类划分法概述:
1.基本思路:
2.有效等价类:
有效等价类是指对软件规格说明来说,合理、有意义的输入数据等构成的集合,利用有效等价类可以检验程序是否满足需求规格说明书所规定的功能和性能。
只考虑有效等价类的测试称为“标准等价类测试”。
3.无效等价类:
无效等价类是指不满足程序输入要求或者无效的输入数据所构成的集合,利用无效等价类可以检验程序异常情况的处理。
不止考虑了“有效等价类”,还考虑了“无效等价类”的测试被称为“健壮性等价类测试”。
4.划分原则:
(1)如果程序规定了输入域的取值范围,则可以确定一个有效等价类和2个无效等价类。
例如:
程序要求输入的数值是50到100,那么一个有效等价类就是50~100,而2个无效等价类就是小于50,大于100的区域数据。
(2)如果程序规定了输入值的集合,不是一个范围,则可以确定一个有效等价类和一个无效等价类。
程序要进行平方根函数的运算,那么大于等于0的数为有效等价类,而小于0的数为无效等价类。
(3)如果程序规定了输入数据的一组值,并且程序要对每一个输入值分别进行处理,则可以每一个值确定一个有效等价类,然后再选择一个无效等价类。
比如:
规定某个输入条件x的取值只能为{1、2、3、4、5}中的某一个,那么有效等价类就是x等于这几个数,而无效等价类则为x不等于这几个数。
(4)如果程序规定了输入数据必须遵守的规则,则可以确定一个有效等价类和若干个无效等价类。
程序中某个输入条件规定必须为5位数字,则可划分一个有效等价类为5位数字,3个无效等价类为:
位数少于5、位数多于5、5位中含有非数字字符。
(5)如果已知的等价类中各个元素在程序中的处理方式不同,则应将该等价类进一步划分成更小的等价类。
三.边界值分析法概述原则:
(1)如果输入/输出条件规定了值的范围,则应该取刚达到这个范围的边界的值,以及刚刚大于最小值以及刚刚小于最大值的值作为测试输入数据。
但为了检查输入数据超过极限值时系统的情况,还需要考虑健壮性取值,会增加一个略超过最大值和略小于最小值的取值。
(2)如果有多个输入/输出变量,可用边界值+正常值的组合模式,即其中一个变量取边界值,其他变量取正常值。
(3)同样的,对于有3个输入条件的程序,边界值法的运用也如此。
有一个三元函数f(x,y,z),有3个输入变量:
x,y,z。
它们的取值范围分别为1<
=x<
=31,1<
=y<
=12,1949<
=z<
=2050。
四.建立决策表的步骤:
第1步:
分析需求,列出所有的条件桩和条件项;
第2步:
分析需求,列出所有的动作桩和动作项;
第3步:
根据规则,设计初始判定表;
第4步:
简化判定表,合并相似规则,设计测试用例。
五.因果图法分析:
分析待测系统的规格说明,找出原因与结果。
并给每个原因和结果赋予一个标识符。
原因常常是输入条件或输入条件的等价类,而结果是输出条件。
明确所有原因和结果之间的制约关系以及组合关系,画出因果图。
在因果图上标记约束条件。
跟踪因果图中的状态条件,把因果图转换为判定表。
第5步:
将判定表中的每一列作为依据,生成测试用例。
六.正交实验法
基本思路:
正交实验法是一种基于正交表的、高效率、快速、经济的实验设计方法,它研究的“多因素多水平”的情况,然后套用正交表来随机地产生用例(用例之间没有主次之分),是一种提高测试覆盖率的简单易用的方法。
七.场景法
场景法一般包含基本流和备选流,从一个流程开始,通过描述经过的路径来确定测试用例的过程,经过遍历所有的基本流和备选流来完成整个场景。
我们通常以正常的用例尝尽刚开始分析,再着手分析其他的场景。
基本流也叫有效流或正确流,主要是模拟正确的业务操作过程的情景。
备选流也叫无效流或错误流,主要是模拟错误的业务操作过程的情景。
八.错误推测法
错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误,有针对性地设计测试用例的方法。
也就是列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据这些情况选择测试用例
软件测试技术
一、软件测试结束的标准
列举一些功能测试通过的标准:
(1)需求规格说明书中的需求全部实现,没有遗漏;
(2)测试用例全部执行完毕,且测试通过,没有通过的已经提交缺陷;
(3)缺陷数随着时间的增加呈收敛趋势,并趋于平稳走势;
(4)软件主流程畅通,技术架构不再发生变化;
(5)系统没有遗留一级、二级和三级Bug,遗留的四级和五级缺陷数量在遗留标准之内(这个标准需根据项目的复杂程度分别制定,比如系统遗留的一级、二级和三级缺陷为0,遗留的四级缺陷低于5%,遗留的五级缺陷低于10%等。
(6)遗留的缺陷,其风险已经过评审委员会评估,并做出决定留待下个版本解决。
须详细列在测试报告中,留作上线依据。
二、软件测试报告的作用:
一是对整个项目的测试过程和质量进行评价;
二是对产品各阶段的遗留问题进行总结;
三是为后续的测试过程改进提供依据
三、软件质量管理体系分:
1、ISO9000质量管理体系
2、CMM质量管理体系
四、软件测试前言技术
敏捷测试方法
敏捷开发中的测试分为7种类型:
(1)自动化回归测试(AutomatedRegressionTest)
运行自动化测试代码来验证当前的修改没有破坏已有的功能。
(2)单元测试(UnitTest)
验证单元级别的代码工作是否正常。
(3)公共API测试(PublicAPITest)
验证被第三方开发人员调用的API可正常工作,并且得以文档化。
(4)私有API测试(PrivateAPITest)
验证内部使用的API工作是否正常。
(5)命令行测试(Command-lineTest)
验证在命令行输入的命令工作正常。
(6)用户界面测试(UserInterfaceTest)
验证界面层的功能是否正常。
(7)“狗粮”测试(Dog-foodTest)
五、测试驱动开发TDD
测试驱动开发的基本过程如下:
●明确当前要完成的功能(可以记录成一个ToDo列表);
●快速完成针对此功能的测试用例的编写;
●测试代码编译通过;
●编写对应的功能代码及重构;
●保证测试通过;
●循环完成所有功能的开发
软件缺陷报告
一、软件缺陷的定义
软件缺陷:
(1)软件未达到产品说明书标明的功能。
(2)软件出现了产品说明书指明不会出现的错误。
(3)软件功能超出了产品说明书指明的范围。
(4)软件未达到产品说明书虽未指出但应达到的目标。
(5)软件测试人员认为软件难以理解、不宜使用、运行速度缓慢,或者最终用户认为不好。
二、编写软件缺陷报告(步骤)
1.
缺陷标题(或者叫缺陷摘要,Summary)
2.
操作步骤(也叫复现步骤,ReproducibleSteps)
3.预期结果(ExpectedResult)
4.实际结果(ActualResult)
5.注释(Notes)
三、缺陷的属性(简述)
1.
模块名称(Module)
缺陷版本号(Version)
3.
缺陷状态(Status)
5.
缺陷严重等级(Severity)
6.
缺陷处理优先级
7.
缺陷来源
四、软件缺陷报告的生命周期
缺陷在其生命周期中的不同状态如下:
(1)首先由测试人员发现缺陷,并提交到缺陷管理工具中,缺陷状态为New。
(2)测试经理或者项目经理审核状态为New的缺陷,把被确认的缺陷分配给对应的开发人员,状态为Open。
(3)开发人员开始处理属于自己的缺陷报告,处理完毕后状态设置为Resolved,但并非所有的软件缺陷都会得到修复。
Resolved状态的缺陷可能包括几种解决方案:
已经修复(Fixed)、推迟解决(Postponed)、无法复现(Unreproduced)、重复提交(Duplicate)、不是缺陷(Invalid)。
但也有缺陷管理工具把这几种解决方案和Resolved状态并行的单独成一个缺陷状态,而不仅仅是“Resolved”的解决方案。
这几种解决方案的解释,在6.2.3小节中的缺陷的状态中有详细讲述,这里不再重复。
(4)测试人员或者测试经理对于状态为“Resolved”的缺陷进行回归测试,在新的软件版本中验证缺陷是否已经被修正。
如果已经被修正,则缺陷的状态更改为Closed;
而如果没有被正确修正,则把状态改为Reopen,重新发送给开发人员,等待继续修正,继续重复第(3)步以后的流程。
根据风险决定哪些缺陷需要修复。
缺陷不被修复的原因通常有如下几个:
●提交的根本就不是一个缺陷,有可能只是提交者对需求的误解或者描述错误导致的;
●在交付期限的强大压力下,没有足够的时间修改缺陷,必须放弃某些缺陷的修改;
●有时候限于现有人员的能力和技术问题,也会导致某些缺陷无法解决;
●有些不值得修复的缺陷发生在用户使用频率非常低的模块,而且也不是特别严重的缺陷,仅仅是测试人员的建议或者体验方面的缺陷,如果迫于时间压力,可以暂时不修复;
●有些缺陷看似很简单,但修改它可能会引起底层架构的变更,导致很多新的工作量出现,或者修复了之后可能会引入新的更大的缺陷。
这样的缺陷也可以暂时不修复,可以等开发人员空闲的时候再进行底层优化。
易用性测试
一、安装易用性测试
安装是大部分软件产品实现功能的第一步。
三步:
安装测试
运行测试
卸载测试
在安装易用性测试中我们需要注意以下几点:
(1)检查安装手册是否准确;
(2)软件自动化安装的水平;
(3)安装选项和设置;
(4)安装过程中的中断;
(5)安装顺序;
(6)安装的正确性;
(7)多环境安装;
(8)软件的卸载。
二、功能易用性测试
三、常见程序控件及其测试点
1.文本框的测试
2.按钮的测试
3.单选按钮控件的测试
4.复选框控件的测试
5.Up-Down控件+文本框组合测试内容
6.下拉列表框测试
7.列表框控件的测试
8.滚动条的控件测试
9.各种控件在窗体中混合使用时的测试
四、文档测试
好的文档测试可以下述3种方式确保产品的整体质量:
(1)提高易用性。
易用性大多与软件文档有关。
(2)提高可靠性。
可靠性是指软件稳定和坚固的程度。
软件是否按照用户预期的方式和时间工作?
如果用户阅读文档,然后使用软件,最终得不到预期的结果,这就是可靠性差。
(3)降低支持费用。
客户发现问题比早在产品开发期发现并修复的费用要高出10到100倍。
其中的原因是用户有麻烦或者遇到意外情况就会请示公司的帮助,这是很贵的。
好的文档可以通过恰当的解释和引导用户解决困难来预防这种情况。
五、界面(UserInterface,UI)易用性测试
●优秀UI的构成
●符合标准和规范
●具有直观性
●一致性
●灵活性
●舒适性
●正确性
●实用性
六、界面设计的总体原则
界面大小应该符合美学观点,感觉协调舒适,能吸引用户的注意力,具体要求如下:
(1)界面长宽比应接近黄金比例,切忌长宽比例失调。
(2)按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置。
按钮大小与界面不应该有很大的空缺位置。
(3)字体的大小要与界面大小比例协调,通常使用宋体,字号为9到12号,很少使用超过12号的字体。
(4)前景色与背景色搭配协调,反差不宜太大,少用深色,如大红、大绿等。
常用色考虑使用Windows界面色调。
如果使用其他颜色,主色要柔和,具有亲和力与磁力,坚决杜绝刺目的颜色。
(5)界面风格要保持一致,字的大小、颜色、字体要相同,除非是需要艺术处理或有特殊要求的地方。
(6)菜单中相关联的功能应放在一起,窗体布局合理,不宜放置太多控件。
(7)合理使用置灰、隐藏控件的功能,保持界面的简洁。
七、辅助选项易用性测试
软件中的辅助特性
提供了一些辅助选项:
(1)粘滞键:
允许Shift、Ctrl或者Alt键持续生效,直至按下其他键。
(2)筛选键:
主要防止简短、重复(无意地)点击被认可。
(3)切换键:
在CapsLock、ScrollLock或者NumLock键盘模式开启时播放声音。
(4)声音卫士:
每当系统发出声音,给出可视警告。
(5)声音显示:
让程序显示其声音或者讲话的标题。
这些标题需要在软件中编制。
(6)高对比度:
利用为便于视力损伤者阅读而设计的颜色和字体设置屏幕。
(7)鼠标键:
允许用键盘来代替鼠标操作。
(8)串行键:
设置一个通信端口读取来自外部非键盘设备的击键。
虽然操作系统会将这些设备为标准键盘,但是把它们加入配置测试的等价划分是个好主意。
第二种就是如果测试的软件不在这些平台上运行,或者本身就是平台,就需要定义、编制和测试自己的辅助选项。
注意:
如果正在测试产品的易用性,一定要专门为辅助选项设计测试用例。
测试人员的职业素养
一、软件测试人员的必备技能(能力)
1.软件测试基础知识:
测试技能、测试方法
质量体系
工具的使用
2.技术知识:
操作系统相关知识
数据库相关知识
计算机硬件知识
网络协议、开发语言
3.行业知识:
建议不要频繁跳槽
4.美学观:
界面要引人入胜·
二、软件测试人员的职业素养
具有工作热情
具有怀疑精神
“三心二意”的精神
4.
良好的沟通和表达能力
5.
良好的文档编写能力
持续学习的能力
7.
用户心理学
三、软件测试工程师应遵守的道德规范
公共:
合格的软件测试工程师的行为应与公共利益保持一致。
客户和雇主:
合格的软件测试工程师在保证公共利益的前提下,应最大限度地保证客户和雇主的利益。
产品:
合格的软件测试工程师应保证他们发布的(在测产品和系统中的)版本最大程度地符合专业标准。
判断:
合格的软件测试工程师应在其提供的专业判断中保持公正性和独立性。
管理:
软件测试管理人员和测试领导者应统一提供合乎道德要求的测试管理。
专业:
合格的软件测试工程师应致力于提高职业的公正性和信誉并与公共利益保持一致。
同事:
合格的软件测试工程师应在工作中热切的支持他们的同事并促进与软件开发人员的合作。
自身:
合格的软件测试工程师应终生学习并不断促进职业实践的提升。
四、软件测试人员的团队协作(沟通)
六要:
(1)要细心和耐心
(2)要懂得尊重对方
(3)要能设身处地为对方着想
(4)要有原则
(5)要主动承担
(6)要客观
四不要:
(1)不要嘲笑
(2)不要在背后评论开发工程师
(3)不要动辄用上层来压制对方
(4)和开发人员的沟通不要只有Bug
五、软件测试部门组织架构和考核
测试部门的组织架构
1.金字塔式管理模式
第一种发展模式:
以产品线来构造
第二种:
以测试专业方向来构造
2.矩阵化管理模式
六、软件测试人员的考核
1.硬指标
(1)缺陷逃逸率
2.软指标
除了一些可以统计的硬指标被用于考核测试人员之外,还可以综合其他的软指标来衡量测试人员的工作质量。
例如,评价一个测试人员的Bug报告和测试报告。
通过这些报告,可以看出一个测试人员有没有用心去做好测试工作。
常见的软指标一般有:
(1)如果一个测试人员录入的Bug经常被Rejected,可能要问一下这个测试人员是否存在一些需求上的误解或者与开发人员的分歧。
(2)如果某个测试人员录入的Bug偏向单一的类型。
例如,绝大部分是界面上的问题。
那么就要看这个测试人员是否存在测试思维上的某些局限,需要进一步地突破和提高。
(3)一个测试人员只有真正认真地投入到测试工作中,才能写出出色的测试报告,写出来的报告应该有充分的各类数据来说明某些问题,应该包含很多总结出来的经验教训,能给其他测试人员学习和借鉴,甚至对程序员有很好的指导意义。
(4)其他软指标包括相关人员对其的评价,可参考每个角色对其的评价来综合评估测试人员的工作,也就是通常所说的360度评价。
∙
●可参考测试经理对其在任务执行、工作效率等方面的评价;
●可参考项目经理对其在提高产品质量方面的评价;
●可参考其他测试人员对其在团队建设、知识共享等方面的评价;
●可参考开发人员对其在Bug报告、协助调试、沟通等方面的评价;
●可参考QA对其在文档编写、流程的遵循、质量改进等方面的评价。
七、软件技术支持
售前技术支持是指在销售遇到无法解答的产品问题时给予帮助或者设计问题解决方案;
售后技术支持是指产品公司为其用户提供的售后服务的一种形式,帮助用户诊断并解决产1.什么是软件测试用例?
软件测试用例是指对一项特定的软件产品进行测试任务的描述,体现测
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 基础 总结