测试理论.docx
- 文档编号:16146139
- 上传时间:2023-07-10
- 格式:DOCX
- 页数:27
- 大小:52.60KB
测试理论.docx
《测试理论.docx》由会员分享,可在线阅读,更多相关《测试理论.docx(27页珍藏版)》请在冰点文库上搜索。
测试理论
一.测试简介与规范
1.测试概念:
1)测试是为了发现错误而执行操作的过程;
2)测试是为了证明设计有错,而不是证明设计无错误;
3)一个成功的测试是在于它能发现至今未发现的错误。
2.测试目的:
1)确保产品完成了它所承诺或公布的功能,并且用户可以访问到的功能都有明确的书面说明;
2)确保产品满足性能和效率的要求;
3)确保产品是健壮的和适应用户环境的。
3.测试的意义:
1)测试在企业价值链中的地位:
测试是每项成功产品的必经环节,
——采购——研发——测试——生产——销售——;
2)测试并不仅仅是为了要找出错误。
通过分析错误产生的原因和错误的分布特征,可以帮助项目管理者发现当前设计过程的缺陷,以便改进。
同时,这种分析也能帮助我们设计出有针对性地检测方法,改善测试的有效性;
3)没有发现错误的测试也是有价值的,完整的测试是评定测试质量的一种方法。
4.测试人员的心态:
1)怀疑、否定、批判的态度,吹毛求茨的心理(发现问题);
2)打破沙锅问到底的决心(定位解决问题);
3)错误的客观存在性;
4)任何人(再有经验的开发人员)都存在思维的死角;
5)尊重开发人员的观点(包括设计),但不要迷信;
6)敢于否定权威(有经验的开发人员,规范,标准电路);
7)寻根问底的决心。
5.测试问题级别:
Bug级别
级别描述
致命(Critical)
引起系统死机或系统崩溃的问题。
严重(Serious)
引起系统某一功能失效且不能简单恢复(如插拔单板)的问题。
中等(Medium)
引起系统某一功能失效但可简单恢复或较难重现的问题。
不严重(Low)
从操作或维护的角度发现的问题或建议。
6.测试计划:
1)明确测试对象、版本、范围;
2)明确角色和职责;
3)测试和不被测试的特性原因;
4)测试通过与否的标准;
5)测试任务安排,任务划分;
6)测试结束的交付件;
7)工作量评估。
7.测试用例:
1)测试用例更多的是需要描述测试方法,测试步骤,测试的预期效果,需要达到的指标。
需要更加详细的对每一条测试项目进行描述;
2)测试用例是直接用来指导测试的,所以对测试项目的描述需要更具体,更便于参考操作。
测试用例编号
测试项目(模块或单元)
测试子项目(子项目描述)
测试级别(必测、选测、可测)
测试条件(环境、仪器等相关要求)
测试步骤和方法(具体细致的操作方法)
应达到的指标和预期效果
备注
8.测试遗留问题处理:
1)遗留问题是指测试过程中发生的并且在测试报告时仍没有得到解决的测试问题。
测试报告时已经得到解决,并已经过回归验证的测试问题不记入其中;
2)遗留问题的划分需要非常谨慎,必须是长时间无法重现的问题,或者由于某些特定的因素(成本等),且问题并不严重的才可以通过流程中各环节人员的认可被列为遗留问题;
3)遗留问题需要定时跟踪清理,且对于一款产品需要制定一个遗留问题的数量限制;
4)遗留问题处理:
即使是遗留问题也要明确跟踪的责任人;遗留问题是可以在后续被重新激活的,一旦问题重现或者条件允许,需要重新激活解决。
9.测试规范的制定方法:
测试需要——人员制定分工——初稿完成——专家评审——修改完善——最初版本——规范试运行——问题缺陷整理——修改——正式版本——发行推广;
必要性:
测试更多的是动手的过程,测试工程师的水平参差不齐,如何保证测试质量就需要用制度和规范管理,各个测试环节均需要有流程和规范进行约束。
各个阶段的输入、输出文档均必须有相应的模板。
10.需要建立哪些测试规范和模板:
1)《测试计划模板》
2)《测试用例模板》
3)《测试报告模板》
二.测试策略及指标
1.接口与路径测试
a)数据一般通过接口输入和输出,每个接口可能有多个输入参数,每个参数有“典型值”、“边界值”、“异常值”之分,所以输入的组合数可能并不少。
根据接口的定义,可以推断某种输入应当产生什么样的输出。
输出包括函数的返回值和输出参数。
如果实际输出与期望的输出不一致,那么说明程序有错误;
b)一个函数体内的语句可能只有十几条,但逻辑路径可能有成千上万条。
想遍历测试几乎是不可能的,不测试或者胡乱找几条路径测试却又不行;
c)对于非严格系统而言,在分析路径方面化费很多精力是不值得的。
我认为在构造接口测试的同时已经建立了测试路径。
因为每一种输入将产生唯一的输出,输入与输出之间的路径也是唯一的。
由于接口测试中的输入是有代表性的,因此相应的路径也具有代表性,不用得着费煞苦心地去找测试路径。
d)路径测试的检查表
数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错误处理
e)由于接口测试是枚举的,有可能漏掉某些状况,导致一些重要的路径没有被测试。
预防措施有:
i.观察是否有程序语句从来没有被执行过。
如果发生在这种情况,要么是程序有错误,存在无用的代码;要么是接口测试不充分,漏掉了一些路径。
ii.要特别留意函数体内的错误处理程序块(如果存在的话),这是最易被人疏忽的路径,隐患最多。
接口测试用例的参考模板:
接口A的函数原型
输入/动作
期望的输出/相应
实际情况
典型值…
边界值…
异常值…
接口B的函数原型
……
2.功能测试
功能测试的基本方法是构造一些合理输入(在需求范围之内),检查输出是否与期望的相同。
如果两者不一致,即表明功能有误。
也有例外的情况,如《需求规格说明书》中的某个功能写错了,而实际上软件的功能却是正确的,这时需要更改的是《需求规格说明书》。
功能测试看起来比较简单,只要看得懂《需求规格说明书》。
难点在于如何构造有效的输入。
由于输入空间通常是无限的,穷举测试显然是行不通的,随便输入一些东西,碰运气也是不行的。
功能测试有两种比较好的测试方法:
等价划分法和边界值分析法。
等价划分是指把输入空间划分为几个“等价区间”,在每个“等价区间”中只需要测试一个典型值就可以了。
等价划分法来源于人们的直觉和经验,可令测试事半功倍。
“缺陷遗漏在角落里,聚集在边界上”。
边界值测试法是对等价划分法的补充。
如果A和B是输入空间的边界值,那么除了典型值外还要用A和B作为测试用例。
例如测试某函数,凭直觉,等价区间应是(0,1)(1,+∞),可取典型值x=0.5以及x=2.0进行“等价划分”测试,再取x=0以及x=1进行“边界值”测试。
功能测试用例的参考模板:
功能A描述
用例目的
前提条件
输入/动作
期望的输出/相应
实际情况
示例:
典型值…
示例:
边界值…
示例:
异常值…
功能B描述…
……
3.用户界面测试
绝大多数软件拥有图形用户界面。
图形用户界面的测试重点是正确性、易用性和视觉效果。
在评价易用性和视觉效果时,主观性非常强,应当考虑多个人的观点。
用户界面测试用例的参考模板:
测试人员类别
测试人员特征
A类
B类
…
检查项
测试人员类别及其评价
重点检查正确性、易用性和美观程序
……
4.健壮性测试
健壮性是指在异常情况下,软件还能正常运行的能力。
健壮性有两层含义:
一是容错能力,二是恢复能力。
容错性测试通常构造一些不合理的输入来引诱软件出错,例如:
1)输入错误的数据类型。
如“猴”年“马”月;
2)输入定义域之外的数值。
如上海人常说的“十三点”。
粗暴一些方式俗称“大猩猩”测试法。
除了不能拳打脚踢嘴咬外,什么招术都可以使出来。
例如在测试客户机-服务器模式的软件时,把网络线拔掉,造成通信异常中断。
恢复测试重点考察一下几项:
1)系统能否重新运行;
2)有无重要的数据丢失;
3)是否毁坏了其它相关的软件硬件。
健壮性测试用例的参考模板:
异常输入/动作
容错能力/恢复能力
造成的危害、损失
示例:
错误的数据类型…
示例:
定义域外的值…
示例:
错误的操作顺序…
示例:
异常中断通信…
示例:
异常关闭某个功能…
示例:
负荷超出了极限…
5.配置测试
配置测试是为了保证测试的软件使用尽量多样化的硬件组合,采用不同的组件、外设、接口等查看测试的软件在不同配置下的可用性。
如果准备开始进行软件的配置测试,就要考虑哪些配置与程序的关系最密切。
不同的软件会有不同的针对点,例如:
游戏软件:
最关心显卡和声卡测试;
图像处理软件:
最关注于显卡和打印机测试;
通信程序:
关注网络设备。
判断缺陷是配置问题还是普通缺陷的方法:
在另一台配置完全不同的机器上执行相同的操作。
如果缺陷没产生,那就很可能是配置问题了,如果缺陷在多种配置中产生,应该是普通的缺陷(BUG)。
计划配置测试时采用的一般过程如下:
1)确定所需的硬件类型;
2)确定哪些硬件,型号和驱动程序可用;
3)确定可能的硬件特性,模式和选项;
4)将确定后的硬件配置缩减为可控制的范围;
5)明确使用硬件配置的软件唯一特性;
6)设计在每一种配置中执行的测试用例;
7)在每种配置中执行测试;
8)反复测试直到小组对结果满意为止。
配置测试用例的参考模板:
功能描述
用例目的
前提条件
配置情况
具体配置
输出情况
配置1
配置2
配置3
……
6.安装测试
1)常规功能测试
a)安装手册的所有步骤得到验证;
b)安装过程中所有缺省选项得到验证;
c)安装过程中典型选项得到验证;
d)测试各种不同的安装组合,并验证各种不同组合的正确性(包括参数组合,控件执行顺序组合,产品安装组件组合,产品组件安装顺序组合(如b/s)等)
e)安装界面的所有信息都显示正确,没有错误别子,没有二义性;
f)安装界面的每个按钮都进行校验有效性;
g)安装后是否能产生正确的目录结构和文件,文件属性正确;
h)安装后动态是否正确;
i)安装后软件能否正确运行;
j)安装后没有生成多余的目录结构、文件、注册表信息、快捷方式等;
k)如果安装程序有重新安装功能的话,要考虑重新安装是否正常。
2)增强测试
a)验证用户机器已安装相同产品的情况下再进行安装,安装程序是否有进行相应校验;
b)安装测试应该在所有的运行环境上进行验证(手册上指定如:
操作系统、数据库、硬件环境、网络环境等);
c)安装路径要考虑几种情况:
a、安装路径较长;b、安装路径中包含空格;c、安装路径包含中文;d、安装路径包含特殊字符;e、安装路径编码规范校验
d)硬盘分区、可用空间校验:
a、硬盘空间不足;b、硬盘分区不存在(如用户机器不存在F盘,安装路径输入F盘);c、空间本来充足的情况下,在安装过程中往磁盘空间放入大量文件,导致磁盘空间不足的情况;
e)目的安装文件夹为只读的情况;
f)在安装过程中人为访问其他软件,比如安装过程中打开word文档或打开IE上网;
g)同时运行两个安装程序的情况:
验证同时运行相同的安装程序及同时运行不同的安装程序两种情况;
h)在笔记本环境下进行安装卸载,因为有很多养产品在笔记本中会出现问题,尤其是系统级的产品;
i)考虑文件被占用的情况下进行程序回滚或卸载;
j)校验执行安装包的系统权限,即以系统管理权限进行安装及非系统管理员权限进行安装
3)异常测试
a)安装过程中计算机断电,要保证重新插上电源,重新安装可以正常安装;
b)安装过程中计算机重启,要保证计算机重启后,重新安装可以正常安装;
c)安装过程中安装进程被迫停止(即手动停止进程),要保证重新安装可以正常安装;
d)安装包如果有创建数据为步骤,则要考虑在创建数据为步骤时数据库服务停止,安装包是否进行友好提示;重启数据库服务后,是否还可以重新安装。
4)卸载测试
a)文件删除情况:
卸载后是否删除安装时所创建的文件及文件夹(如:
程序安装在几处的)、非安装目录(向系统其它地方添加的文件及文件夹),它们包括(exe,dll,配置文件等),快捷方式(桌面,菜单,任务栏,系统栏,控件面板,系统服务列表等);
b)复原方面:
卸载后,系统能否恢复到软件安装前的状态(包含目录结构、动态库、注册表、系统配置文件、驱动程序、关联情况等)(专门的测试工具regsnap);
c)卸载方式:
程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具(如:
优化大师);
d)卸载状态:
程序在运行/暂停/终止等状态时的卸载;
e)非正常卸载情况:
卸载软件过程中,取消卸载进程,或计算机断电,后计算机重启;然后启动计算机后,重新卸载软件,如果软件无法卸载,则重新安装软件,安装之后再重新卸载;
f)卸载环境:
不同的(操作系统,,硬件环境,网络环境等)下进行卸载;
g)卸载后,该系统是否对其他的应用程序造成不正常影响(如操作系统,应用软件等);
h)健壮性测试:
在用户机器上进行反复的安装、卸载、再安装。
安装测试用例的参考模板:
配置说明
安装选项
是否正常
难易程度
全部
部分
升级
其它
反安装选项
是否正常
难易程度
……
7.可靠性测试:
可靠性是指在一定的环境下、在给定的时间内、系统不发生故障的概率。
由于软件不像硬件那样可以“加速老化”,按此定义,软件可靠性测试可能会花费很长时间。
比较实用的办法是,让用户使用该系统,记录每一次发生故障的时刻。
计算出相邻故障的时间间隔,注意要去掉非工作时间。
这样我们可以方便地统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。
其中“平均时间间隔”会让人们大体了解到系统“可靠”的程度。
可靠性测试用例的参考模板:
任务A描述
连续运行时间
故障发生的时刻
故障描述
……
统计分析
任务A无故障运行的平均时间间隔
(CPU小时)
任务A无故障运行的最小时间间隔
(CPU小时)
任务A无故障运行的最大时间间隔
(CPU小时)
8.负载测试
负载测试,通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。
在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
此外,负载测试还要评估性能特征。
例如,响应时间、事务处理速率和其他与时间相关的方面。
负载测试用例的参考模板:
性能A描述
如“最大并发用户数量”
最大预期工作量
如“1000”
前提条件
输入/动作
输出/响应
是否能正常运行
如100个用户并发操作
如200个用户并发操作
……
如1000个用户并发操作
期望的性能(平均值)
实际性能(平均值)
9.压力测试
压力测试可以被看作是负载测试的一种,即高负载下的负载测试。
压力测试是对系统不断施加压力的测试,是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
例如测试一个Web站点在大量的负荷下,何时系统的响应会退化或失败。
压力测试可以分为稳定性测试和破坏性测试:
稳定性压力测试:
在选定的压力值下,持续运行24小时以上的测试。
通过压力测试,可以考察各项性能指标是否在指定范围内,有无内存泄漏、有无功能性故障等。
破坏性压力测试:
在压力稳定性测试中可能会出现一些问题,如系统性能明显降低,但很难暴露出其真实的原因。
通过破坏性不断加压的手段,往往能快速造成系统的崩溃或让问题明显的暴露出来。
web极限压力测试举例:
1)接收大数据量的数据文件时间;
2)大数据恢复时间;
3)大数据导入导出时间;
4)大批量录入数据时间;
5)大数据量的计算时间;
6)多客户机同时进行某一个提交操作;
7)采用测试工具软件;
8)编写测试脚本程序;
9)大数据量的查询统计时间。
压力测试用例的参考模板:
极限名称A
如“最大并发用户数量”
前提条件
输入/动作
输出/响应
是否能正常运行
如10个用户并发操作
如20个用户并发操作
……
10.性能测试
性能测试即测试软件处理事务的速度,一是为了检验性能是否符合需求,二是为了得到某些性能数据供人们参考(例如用于宣传)。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试,两者可以结合进行。
有时人们关心测试的“绝对值”,如数据送输速率是每秒多少比特。
有时人们关心测试的“相对值”,如某个软件比另一个软件快多少倍。
在获取测试的“绝对值”时,我们要充分考虑并记录运行环境对测试的影响。
例如网络环境、计算机主频,总线结构和外部设备都可能影响软件的运行速度。
性能测试的一些注意事项:
1)不要试图让人拿着钟表去测时间,应当编写一段程序用于计算时间以及相关数据;
2)应当测试软件在标准配置和最低配置下的性能;
3)为了排除干扰,应当关闭那些消耗内存、占用CPU的其它应用软件(如杀毒软件);
4)不同的输入情况会得到不同的性能数据,应当分档记录。
例如传输文件的容量从100K到1M可以分成若干等级;
5)由于环境的波动,同一种输入情况在不同的时间可能得到不同的性能数据,可以取其平均值。
性能测试用例的参考模板:
性能A描述
用例目的
前提条件
输入数据
期望的性能(平均值)
实际性能(平均值)
性能B描述
……
11.容量测试
通过性能测试,如果找到了系统的极限或苛刻的环境中系统的性能表现,在一定的程度上,我们完成了容量测试。
容量可以看作系统性能指标中一个特定环境下的一个特定性能指标,即设定的界限或极限值。
容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。
容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
对软件容量的测试,能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力,如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。
知道了系统的实际容量,如果不能满足设计要求,就应该寻求新的技术解决方案,以提高系统的容量。
有了对软件负载的准确预测,不仅能对软件系统在实际使用中的性能状况充满信心,同时也可以帮助用户经济地规划应用系统,优化系统的部署。
容量测试用例的参考模板:
极限名称A
如“最大并发用户数量”
前提条件
输入/动作
输出/响应
是否能正常运行
如100个用户并发操作
如200个用户并发操作
……
最大并发用户数量
12.负载测试、压力测试、性能测试以及容量测试之间的区别与联系:
负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。
负载测试是一种测试方法,可以为性能测试、压力测试所采用。
压力测试通常是在高负载情况下来对系统的稳定性进行测试,更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。
性能测试是为获取或验证系统性能指标而进行测试。
多数情况下,性能测试会在不同负载情况下进行。
容量测试,检查被测系统处理大数据量的能力,例如存储或读取一个超长的文件。
容量测试也是采用负载测试技术来实现,而在破坏性的压力测试中,容量的确定可以看作是一种副产品。
负载测试是为了发现系统的性能问题,负载测试需要通过系统性能特性或行为来发现问题,从而为性能改进提供帮助,从这个意义看,负载测试可以看作性能测试的一部分。
但它们两者的目的是不一样的,负载测试是为了发现缺陷,而性能测试是为了获取性能指标。
压力测试可以看作是容量测试、性能测试和可靠性测试的一种手段,不是直接的测试目标。
压力测试的重点在于发现功能性测试所不易发现的系统方面的缺陷。
而容量测试和性能测试是系统测试的主要目标内容,也就是确定软件产品或系统的非功能性方面的质量特征,包括具体的特征值。
容量测试和性能测试更着力于提供性能与容量方面的数据,为软件系统部署、维护、质量改进服务,并可以帮助市场定位、销售人员对客户的解释、广告宣传等服务。
压力测试、容量测试、性能测试,测试的方法相似、相通,在实际测试工作中,往往结合起来进行,以提高测试效率。
三.测试实施过程
1.测试生命周期
制定测试计划
参与需求评审
系统测试设计
系统测试设计评审
否
是
搭建测试环境
版本预测试
迭代
缺陷管理与改错
2.软件测试的阶段划分
每个软件测试阶段都要经历以下步骤:
测试需求分析、测试过程设计、测试实现、测试实施、测试评价、测试维护。
a)测试需求分析:
测试需求是整个测试过程的基础;确定测试对象以及测试工作的范围和作用。
用来确定整个测试工作(如安排时间表、测试设计等)并作为测试覆盖的基础。
而且被确定的测试需求项必须是可核实的。
即,它们必须有一个可观察、可评测的结果。
无法核实的需求不是测试需求。
所以我现在的理解是测试需求是一个比较大的概念,它是在整个测试计划文档中体现出来的,不是类似的一个用例或者其他。
i.测试需求是制订测试计划的基本依据,确定了测试需求能够为测试计划提供客观依据;
ii.测试需求是设计测试用例的指导,确定了要测什么、测哪些方面后才能有针对性的设计测试用例;
iii.测试需求是计算测试覆盖的分母,没有测试需求就无法有效地进行测试覆盖。
b)测试过程设计:
包括测试计划,测试策略制定,测试时间安排用,测试用例编写等。
c)测试实现:
环境配置好了,新的版本也收到了,人员也都培训好了等等。
d)测试实施:
已经按照测试计划进行展开了,比如手工测试,自动化测试等。
e)测试评价:
对版本测试覆盖率,测试质量,人员测试工作以及前期的一些工作制定情况进行评价,评估。
f)测试维护:
对测试用例库,测试脚本,bug库等进行维护,保证延续性等。
软件测试步骤
输入
输出
测试需求分析
1.软件测试的方法与规范
2.软件需求规格说明
3.软件设计说明(概要设计说明和详细设计说明)
软件测试计划:
1.软件测试的定位
2.软件测试线索
3.软件测试环境的定义
4.软件需求的追踪矩阵
测试过程设计
1.软件测试的方法与规范
2.软件测试计划
软件测试说明:
1.软件测试步骤
2.软件测试基准
3.测试线索的追踪矩阵
测试实现
1.软件测试的方法与规范
2.软件测试说明
3.软件测试工具
软件测试的实现配置:
1.软件测试环境
2.测试步骤的计算机表示(用于回归测试的测试代码/测试数据)
3.测试基准的计算机表示
测试实施
1.软件测试的方法与规范
2.软件测试说明
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 理论