软件测试-6-集成测试与系统测试课件_第1页
软件测试-6-集成测试与系统测试课件_第2页
软件测试-6-集成测试与系统测试课件_第3页
软件测试-6-集成测试与系统测试课件_第4页
软件测试-6-集成测试与系统测试课件_第5页
已阅读5页,还剩101页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件测试方法和技术

第2版

第6章集成测试和系统测试第5章回顾单元测试的定义与进行单元测试的重要性单元测试的目标与任务静态测试技术的运用动态测试技术的运用调试与评估单元测试的过程与文档管理单元测试的常用工具简介第6章集成测试和系统测试6.1系统集成的模式与方法6.2功能测试6.3回归测试6.4非功能性测试6.1系统集成的模式与方法6.1.1集成测试前的准备6.1.2集成测试的模式6.1.3自顶向下和自底向上集成方法6.1.4大棒与三明治集成方法6.1.5持续集成6.1.1集成测试前的准备

人员安排p125

测试计划p126

测试内容

集成模式

测试方法集成测试界于单元测试和系统测试之间,起到“桥梁作用”,一般由开发小组采用白盒加黑盒的方式来测试,既要验证“设计”又要验证“需求”。

6制定测试计划时应考虑的因素1、是采用何种系统组装方法来进行组装测试;2、组装测试过程中连接各个模块的顺序;3、模块代码编制和测试进度是否与组装测试的顺序一致4、测试过程中是否需要专门的硬件设备。7为什么总是集成不起来?集成测试的关注点1、在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;2、各个子功能组合起来,能否达到预期要求的父功能;3、一个模块的功能是否会对另一个模块的功能产生不利的影响;4、全局数据结构是否有问题;5、单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。96.1.2集成测试的模式渐增式测试模式与非渐增式测试模式非渐增式测试模式:先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序,如大棒模式。渐增式测试模式:把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试。各自的优缺点p1266.1.3自顶向下和自底向上集成方法

驱动程序/驱动模块(driver),用以模拟被测模块的上级模块。驱动模块在集成测试中接受测试数据,把相关的数据传送给被测模块,启动被测模块,并打印出相应的结果。桩程序/桩模块(stub),也有人称为存根程序,用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用,它们一般只进行很少的数据处理,例如打印入口和返回,以便于检验被测模块与其下级模块的接口自顶向下法(Top-downIntegration)

自顶向下法(Top-downIntegration)

自底向上法(Bottom-upIntegration)

自底向上法(Bottom-upIntegration)

自顶向下测试和自底向上测试的比较自顶向下优点如果主要缺陷发生在程序顶层将非常有利一旦引入IO功能,提交测试用例会更容易早期的程序框架可以进行演示,并可激发积极性缺点必须开发桩模块桩模块要比最初表现的更复杂在引入IO功能之前,向桩模块中引入测试用例比较困难创建测试环境可能很难,甚至无法实现观察测试输出很困难使人误解设计和测试可以交迭进行会导致特定模块测试的完成延后自底向上优点如果主要的缺陷发生在程序的底层将非常有利测试环境比较容易建立观测测试输出比较容易缺点必须开发驱动模块直到最后一个模块添加进去,程序才形成一个整体16混合策略(ModifiedTop-downIntegration)

混合法:对软件结构中较上层,使用的是“自顶向下”法;对软件结构中较下层,使用的是“自底向上”法,两者相结合

6.1.4大棒集成方法(Big-bangIntegration)采用大棒集成方法,先是对每一个子模块进行测试(单元测试阶段),然后将所有模块一次性的全部集成起来进行集成测试。因为所有的模块一次集成的,所以很难确定出错的真正位置、所在的模块、错误的原因。这种方法并不推荐在任何系统中使用,适合在规模较小的应用系统中使用。三明治集成方法(SandwichIntegration)

采用三明治方法的优点是:它将自顶向下和自底向上的集成方法有机地结合起来,不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。采用这种方法的主要缺点是:在真正集成之前每一个独立的模块没有完全测试过。改善的三明治集成方法改进的三明治集成方法,不仅自两头向中间集成,而且保证每个模块得到单独的测试,使测试进行得比较彻底。6.1.5持续集成通常系统集成都会采用持续集成的策略,软件开发中各个模块不是同时完成,根据进度将完成的模块尽可能早的进行集成,有助于尽早发现Bug,避免集成中大量Bug涌现

而且容易定位Bug、修正Bug,最终提高软件开发的质量与效率几种集成方法性能的比较

自底向上自顶向下混合策略大棒三明治改进三明治集成早早早晚早早基本程序能工作时间晚早早晚早早需要驱动程序是否是是是是需要桩程序否是是是是是工作并行性中低中高中高特殊路径测试容易难容易容易中等容易计划与控制容易难难容易难难集成测试完成标准

1、成功地执行了测试计划中规定的所有集成测试;2、修正了所发现的错误;3、测试结果通过了专门小组的评审。23集成测试与系统测试的区别1.系统测试所测试的对象是整个系统以及与系统交互的硬件和软件平台。系统测试更大程度上是站在用户的角度上对系统作功能性的验证,同时还对系统进行一些非功能性的验证,包括性能测试、压力测试、容量测试、安全测试、恢复性测试等。系统测试的依据来自于用户需求规格说明书和行业的已成文的或事实上的标准。2.集成测试所测试的对象是模块之间的接口,其目的是要找出在模块接口上面,包括整体体系结构上的问题。其测试的依据来自于系统的高层设计(架构设计)。246.2功能测试

目的和内容

程序安装、启动正常,有相应的提示框、错误提示等每项功能符合实际要求系统的界面清晰、美观菜单、按钮操作正常、灵活,能处理一些异常操作能接受正确的数据输入,对异常数据的输入有提示、容错处理等数据的输出结果准确,格式清晰,可以保存和读取功能逻辑清楚,符合使用者习惯系统的各种状态按照业务流程而变化,并保持稳定支持各种应用的环境能配合多种硬件周边设备软件升级后,能继续支持旧版本的数据与外部应用系统的接口有效功能测试的方法

等价类划分法边界值分析法错误推测法因果图法组合分析法我要测试所有的功能回归测试的目的所做的修改达到了预定的目的,如错误得到了改正,新功能得到了实现,能够适应新的运行环境等;不影响软件原有功能的正确性。

回归测试的方法

再测试全部用例基于风险选择测试基于操作剖面选择测试再测试修改的部分6.3回归测试

回归测试的组织和实施回归测试

手工回归测试流程29自动回归测试流程303、回归测试的组织和实施

31(1)识别出软件中被修改的部分。(2)从原基线测试用例库T中,排除所有不再适用的测试用例,确定那些对新的软件版本依然有效的测试用例,其结果是建立一个新的基线测试用例库T0。

(3)依据一定的策略从T0中选择测试用例测试被修改的软件。(4)如果回归测试包不能达到所需的覆盖要求,必须补充新的测试用例使覆盖率达到规定的要求,生成新的测试用例集T1,用于测试T0无法充分测试的软件部分。(5)用T1执行修改后的软件。自动回归测试实施策略§分步实施,降低风险§明确的人员分工,确保具有相应技能-项目经理-测试人员VS开发人员-自动测试工程师-业务人员§完善的文档-自动测试体系-完整的项目管理文档-完整的工程文档§选用合适的工具,自动测试框架不影响测试工作的进行§关注测试目的,而不是自动化技术326.4非功能性测试6.4.1性能测试 6.4.2压力测试6.4.3容量测试 6.4.4安全性测试6.4.5可靠性测试6.4.6容错性测试压力测试、容量测试和性能测试

34

压力测试、容量测试和性能测试的测试目的虽然有所不同,但其手段和方法在一定程度上比较相似,通常会使用特定的测试工具,来模拟超常的数据量、负载等,监测系统的各项性能指标,如CPU和内存的使用情况、响应时间、数据传输量等。

一定要设法破坏它!6.4.1性能测试性能测试的目的:

为了验证系统是否达到用户提出的性能指标,同时发现系统中存在的性能瓶颈,起到优化系统的目的。性能测试指标的来源:

用户对各项指标提出的明确需求;如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。(需求+经验)主要的性能指标:

服务器的各项指标(CPU、内存占用率等)、后台数据库的各项指标、网络流量、响应时间35性能测试要点测试环境应尽量与用户环境保持一致,应单独运行,尽量避免与其他软件同时使用。性能测试一般使用测试工具和测试人员编制测试脚本来完成。性能测试的重点在于前期数据的设计与后期数据的分析。性能测试的用例主要涉及到整个系统架构的问题,所以测试用例一旦生成,改动一般不大,所以做性能测试的重复使用率一般比较高。36性能测试就是用来测试软件在系统中的运行性能的。性能测试可以发生在各个测试阶段中,即使是在单元层,一个单独模块的性能也可以使用白盒测试来进行评估,然而,只有当整个系统的所有成分都集成到一起之后,才能检查一个系统的真正性能。性能测试经常和压力测试一起进行,而且常常需要硬件和软件测试设备,这就是说,常常有必要的在一种苛刻的环境中衡量资源的使用(比如,处理器周期、内存)。外部的测试设备可以监测测试执行,当出现情况(如中断)时记录下来。通过对系统的检测,测试者可以发现导致效率降低和系统故障的原因。

37对一个网络实时在线培训系统的

性能测试38看看在各种情况下CPU使用的效率性能测试方法负载模拟

并发用户+思考时间+每次请求的数据量+负载模式性能测试步骤

确定性能测试需求根据测试需求,选择测试工具和开发相应的测试脚本建立性能测试负载模型,就是确定并发虚拟用户的数量、每次请求的数据量、思考时间、加载方式和持续加载的时间等执行性能测试结果分析,并提交性能测试报告性能测试的过程评估系统制定测试资产执行基线&基准测试分析结果验证需求完成调试系统识别探索性测试非决定性结果不符合标准调试之后重新进行基准测试开发探索性的测试符合所有的标准6.4.2压力测试41压力测试的目的

检查程序对异常情况的抵抗能力,找出性能瓶颈。压力测试的方法

在一种需要反常数量、频率或资源的方式下,执行可重复的负载测试。从本质上来说,测试者是想要破坏程序,难怪在进行压力测试时常常问自己:“我们能够将系统折腾到什么程度而又不会出错?”。这种系统折腾,就是对异常情况的设计。异常情况主要指的是峰值(瞬间使用高峰)、大量数据的处理能力、长时间运行等情况。压力测试总是迫使系统在异常的资源配置下运行。资源包括内部内存、CPU可用性、磁盘空间和网络带宽等。42压力测试与负载测试的联系与区别负载测试是通过逐步增加系统工作量,测试系统能力的变化,并最终确定在满足功能指标的情况下,系统所能承受的最大工作量的测试。压力测试实质上就是一种特定类型的负载测试。43测试压力估算:产品说明书的设计要求或以往版本的实际运行经验测试环境准备:硬件、网络环境、测试程序、数据准备等问题的分析:适当分析(日志文件)、详细记录累积效应:日积月累、量变导致质变44压力测试45试试这个游戏站点的承受力压力测试用例的参考模板46某个电话通信系统的压力测试在正常情况下,每天的电话数目大约2000个,一天24小时服从正态分布。在系统第一年使用时,系统的平均无故障时间大约1个月左右。分析表明,系统的出错原因主要来源于单位时间内电话数量比较大的情况下。为此,对系统采用压力测试,测试时将每天电话的数目增加10倍,采用均匀和正态分布两种,测试大约进行了4个月,共发现了314个错误,修复这些错误大约花费了6个月的时间,修复后的系统运行了近2年,尚未出现问题。476.4.3容量测试

48容量测试目的通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状态下还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。

容量测试完成标准所计划的测试已全部执行,而且达到或超出指定的系统限制时没有出现任何软件故障。容量测试与压力测试的区别十分相近。二者都是检测系统在特定情况下,能够承担的极限值。侧重点有所不同。压力测试主要是使系统承受速度方面的超额负载,例如一个短时间之内的吞吐量。容量测试关注的是数据方面的承受能力,并且它的目的是显示系统可以处理的数据容量。496.5安全性测试,可靠性和容错性测试

50安全性测试、可靠性测试和容错性测试的测试目的不同,其手段和方法也不同,但都属于系统测试的范畴,有一定的联系,如软件可靠性要求通常包括了安全性的要求。而且,安全性测试、可靠性测试和容错性测试的技术比较深、实施比较难,但在计算机应用系统中其作用越来越大。6.5.1安全性测试51根据ISO8402的定义,安全性是“使伤害或损害的风险限制在可接受的水平内”。安全性测试

52安全性测试是检查系统对非法侵入的防范能力。安全测试期间,测试人员假扮非法入侵者,采用各种办法试图突破防线。例如:想方设法截取或破译口令;专门开发软件来破坏系统的保护机制;故意导致系统失败,企图趁恢复之机非法进入;试图通过浏览非保密数据,推导所需信息等等。理论上讲,只要有足够的时间和资源,没有不可进入的系统。因此系统安全设计的准则是,使非法侵入的代价超过被保护信息的价值,此时非法侵入者已无利可图。两种级别的安全性安全性一般分为两个层次,即应用程序级别的安全性和系统级别的安全性,针对不同的安全级别,其测试策略和方法也不相同:应用程序级别的安全性,包括对数据或业务功能的访问,在预期的安全性情况下,操作者只能访问应用程序的特定功能、有限的数据。其测试是核实操作者只能访问其所属用户类型已被授权访问的那些功能或数据。测试时,确定有不同权限的用户类型,创建各用户类型并用各用户类型所特有的事务来核实其权限,最后修改用户类型并为相同的用户重新运行测试。系统级别的安全性,可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问,包括对系统的登录或远程访问。其测试是核实只有具备系统和应用程序访问权限的操作者才能访问系统和应用程序。53用户认证安全的测试要考虑问题明确区分系统中不同用户权限系统中会不会出现用户冲突系统会不会因用户的权限的改变造成混乱用户登陆密码是否是可见、可复制是否可以通过绝对途径登陆系统(拷贝用户登陆后的链接直接进入系统)用户推出系统后是否删除了所有鉴权标记,是否可以使用后退键而不通过输入口令进入系统54系统网络安全的测试要考虑问题测试采取的防护措施是否正确装配好,有关系统的补丁是否打上模拟非授权攻击,看防护系统是否坚固采用成熟的网络漏洞检查工具检查系统相关漏洞(即用最专业的黑客攻击工具攻击试一下,现在最常用的网站安全检测入侵工具(NBSI注入漏洞检测工具)和IPhackerIP)采用各种木马检查工具检查系统木马情况采用各种防外挂工具检查系统各组程序的客外挂漏洞55数据库安全考虑问题系统数据是否机密(比如对银行系统,这一点就特别重要,一般的网站就没有太高要求)系统数据的完整性系统数据可管理性系统数据的独立性系统数据可备份和恢复能力(数据备份是否完整,可否恢复,恢复是否可以完整)566.5.2可靠性测试

57可靠性(Reliability)是产品在规定的条件下和规定的时间内完成规定功能的能力,它的概率度量称为可靠度。软件可靠性是软件系统的固有特性之一,它表明了一个软件系统按照用户的要求和设计的目标,执行其功能的可靠程度。软件可靠性与软件缺陷有关,也与系统输入和系统使用有关。理论上说,可靠的软件系统应该是正确、完整、一致和健壮的。软件可靠性测试的步骤1

制订测试方案

本阶段的目标是识别软件功能需求,触发该功能的输入和对应的数据域,确定相关的概率分布及需强化测试的功能。

(1)分析功能需求

(2)定义失效等级判断是否存在出现危害度较大的1级和2级失效的可能性。

(3)确定概率分布

确定各种不同运行方式的发生概率,判断是否需要对不同的运行方式进行分别测试。

如果需要,则应给出各种运行方式下各数据域的概率分布;否则,给出各数据域的概率分布。

·判断是否需要强化测试某些功能。

(4)整理概率分布的信息将这些信息编码送入数据库。

58软件可靠性测试的步骤2

制订测试计划本阶段的目标是:

(1)根据前一阶段整理的概率分布信息生成相对应的测试实例集,并计算出每一测试实例预期的软件输出结果。本阶段需要注意:在按概率分布随机选择生成测试实例的同时,要保证测试的覆盖面。

(2)编写测试计划,确定测试顺序,分配测试资源。由于本阶段前一部分的工作需要考虑大量的信息和数据,因此需要一个软件支持工具,建立数据库,并产生测试实例。另外,有时预测软件输出结果也需要大量的计算,有些复杂的软件甚至要用到仿真器模拟输出结果。

总之,具体实施与被测应用软件的实际功能类型有关。59软件可靠性测试的步骤3

测试

本阶段进行软件测试。需注意的是被测软件的测试环境(包括硬件配置和软件支撑环境)应和预期的实际使用环境尽可能一致,对某些环境要求比较严格的软件(如嵌入式软件)则应完全一致。测试时按测试计划和顺序对每一个测试实例进行测试,判断软件输出是否符合预期结果。测试时应记录测试结果、运行时间和判断结果。如果软件失效,那么还应记录失效现象和时间,以备以后核对。

60软件可靠性测试的步骤4

编写测试报告按软件可靠性估计的要求整理测试记录,并将结果写成报告。软件可靠性测试的关键在于:

·对需求、输入、数据域的识别及相关概率分布的确定。

·按照概率分布随机生成测试实例,并确定测试顺序。

据国外有关文献报导,这种测试方法已成功应用于大量应用软件的可靠性测试,包括一些商用软件和航空、航天电子设备中嵌入式软件的测试,其效果很好。因此,我们有必要投入一定的人力、物力,针对我们的实际需要,有目的地对各类应用软件进行软件可靠性测试,从实践中逐步积累经验。同时需要软件开发方和使用方共同合作,进行软件可靠性测试方法的研究和有关支持工具的开发,促进我国软件可靠性水平的提高。6162可靠性测试结果的评估成熟性度量可以通过错误发现率DDP(DefectDetectionPercentage)来表现。在测试中查找出来的错误越多,实际应用中出错的机会就越小,软件也就越成熟。DDP=测试发现的错误数量/已知的全部错误数量已知的全部错误数量是测试已发现的错误数量加上可能会发现?的错误数量之和。6.5.3容错性测试

63容错性测试是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。如当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。容错性测试包括两个方面:输入异常数据或进行异常操作,以检验系统的保护性。如果系统的容错性好的话,系统只给出提示或内部消化掉,而不会导致系统出错甚至崩溃。灾难恢复性测试。通过各种手段,让软件强制性地发生故障,然后验证系统已保存的用户数据是否丢失、系统和数据是否能尽快恢复。关于自动恢复测试,需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性;对于人工干预的恢复系统,还需估测平均修复时间,确定其是否在可接受的范围内。从容错性测试的概念可以看出,容错测试是一种对抗性的测试过程。要测试软件出现故障时,如何进行故障的转移与恢复有用的数据。故障转移(Failover)是确保测试对象在出现故障时,能成功地将运行的系统或系统某一关键部分转移到其它设备上继续运行,即备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务,不影响用户的使用。要进行故障转移的全面测试,一个好的方法是将测试系统全部对象用一张系统结构图描绘出来,对图中的所有可能发生的故障点设计测试用例。例如,系统设计架构图中,如果存在单点失效的关键对象,就是设计的重大缺陷。64从质量三个纬度看系统测试

质量维度测试类型

可靠性完整性测试:侧重于评估测试对象的强壮性(防止失败的能力),语言、语法的技术兼容性以及资源利用率的测试。该测试针对不同的测试对象实施和执行,包括单元和已集成单元。结构测试:侧重于评估测试目标是否符合其设计和构造的测试。通常对基于Web的应用程序执行该测试,以确保所有链接都已连接、显示正确的内容以及没有孤立的内容。65从质量三个纬度看系统测试

质量维度测试类型

功能配置测试:侧重于确保测试对象在不同的硬件和/或软件配置上按预期运行的测试。该测试还可以作为系统性能测试来实施。功能测试:侧重于核实测试对象按计划运行,提供需求的服务、方法或用例的测试。该测试针对不同的测试对象实施和执行,包括单元、已集成单元、应用程序和系统。安装测试:侧重于确保测试对象在不同的硬件和/或软件配置上,以及在不同的条件下(磁盘空间不足或电源中断)按预期安装的测试。该测试针对不同的应用程序和系统实施和执行。安全测试:侧重于确保只有预期的主角才可以访问测试对象、数据(或系统)的测试。该测试针对多种测试对象实施和执行。容量测试:侧重于核实测试对象对于大量数据(输入和输出或驻留在数据库内)的处理能力的测试。容量测试包括多种测试策略,如创建返回整个数据库内容的查询;或者对查询设置很多限制,以至不返回数据;或者返回每个字段中最大数据量的数据条目。66从质量三个纬度看系统测试

质量维度测试类型

性能

基准测试:一种性能测试,该测试将比较(新的或未知的)测试对象与已知的参照负载和系统的性能。竞争测试:侧重于核实测试对象对于多个主角对相同资源(数据记录、内存等)的请求的处理是否可以接受的测试。负载测试:一种性能测试,用于在测试的系统保持不变的情况下,核实和评估系统在不同负载下操作极限的可接受性。评测包括负载和响应时间的特征。如果系统结合了分布式构架或负载平衡方法,将执行特殊的测试以确保分布和负载平衡方法能够正常工作。性能曲线:在该测试中,将监测测试对象的计时配置文件,包括执行流、数据访问、函数和系统调用,以确定并解决性能瓶颈和低效流程。强度测试:一种性能测试,侧重于确保系统可在遇到异常条件时按预期运行。系统面对的工作强度可以包括过大的工作量、不充足的内存、不可用的服务/硬件或过低的共享资源。67小结系统集成的不同模式,比较。系统测试:压力测试、容量测试、性能测试、回归测试、安全性测试、可靠性测试与容错性测试。68Q&A练习P.145:1,5,7性能测试的方法和技巧

两种负载类型“flat”测试ramp-up测试 对于企业级的系统,性能测试的方法主要有:基准测试性能规划测试渗入测试峰谷测试两种负载类型

“Flat”测试:

对于一次给定的测试,应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户,然后在预定的时间段内持续运行。虚拟用户的数量两种负载类型

Ramp-up测试:

用户是交错上升的(每几秒增加一些新用户)。ramp-up测试不能产生精确和可重现的平均值,这是因为由于用户的增加是每次一部分,系统的负载在不断地变化。其优点是,可以看出随着系统负载的改变,测量值是如何改变的

据此选择要运行的flat测试的范围。Flat测试“波动”效应

PageDownloadedperSecond系统吞吐量

Flat测试“波动”效应

ResourceUsage基准测试同时与服务器通信的连接(或虚拟用户)的数目,每个虚拟用户请求之间间隔时间的长短。随着服务器上负载的增加,吞吐量会不断攀升,直到到达一个点,并在这个点上稳定下来基准测试的关键是要获得一致的、可再现的结果。假定测试的两个指标是服务器的响应时间和吞吐量,会受到负载的影响。而负载又受两个因素影响:与服务器通信的用户越多,负载就越大。同样,请求之间间隔时间越短,负载也越大。这两个因素的不同组合会产生不同的服务器负载等级.基准测试(2) 在某一点上,执行队列开始增长,因为服务器上所有的线程都已投入使用,传入的请求不再被立即处理,而是放入队列中,当线程空闲时再处理。当系统达到饱和点,服务器吞吐量保持稳定后,就达到了给定条件下的系统上限。但是,随着服务器负载的继续增长,响应时间也随之延长,虽然吞吐量保持稳定。队列产生响应时间资源使用将系统置于相同的高负载下,将请求之间间隔时间设为零。这样服务器会立即超载,并开始构建执行队列。如果请求(虚拟用户)数保持一致,基准测试的结果会非常精确

flat运行是获得基准测试数据的理想模式基准测试(3)两个事务的响应时间曲线性能规划测试

性能规划类型的测试其目标是找出在特定的环境下,给定应用程序的性能可以达到何种程度。例如,如果要以5秒或更少的响应时间支持8,000个当前用户,需要多少个服务器?要确定系统的容量,需要考虑几个因素:用户中有多少是并发与服务器通信的。每个用户的请求间时间间隔是多少。

如何加载用户以模拟负载状态?

最好的方法是模拟高峰时间用户与服务器通信的状况。如果用户负载状态是在一段时间内逐步达到的,选择ramp-up测试,每隔几秒增加x个用户;如果所有用户是在一个非常短的时间内同时与系统通信,就应该使用flat测试,将所有的用户同时加载到服务器

什么是确定容量的最好方法?

结合两种负载类型的优点,并运行一系列的测试

如:首先使用ramp-up测试确定系统支持的用户范围

该范围内不同的并发用户负载进行一系列的flat测试,更精确地确定系统的容量。性能规划测试(2)渗入测试

渗入测试是一种比较简单的性能测试。渗入测试所需时间较长,它使用固定数目的并发用户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集(GC)或系统的其他问题,显示因长时间运行而出现的任何性能降低。

建议运行两次测试——一次使用较低的用户负载(要在系统容量之下,以便不会出现执行队列),一次使用较高的负载(以便出现积极的执行队列)。峰谷测试

兼有容量规划ramp-up测试和渗入测试的特征,目标是确定从高负载(例如系统高峰时间的负载)恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。系统瓶颈分析举例-1交易的响应时间如果很长,远远超过系统性能需求,表示耗费CPU的数据库操作,例如排序,执行aggregatefunctions(例如sum、min、max、count)等较多,可考虑是否有索引以及索引建立的是否合理;尽量使用简单的表联接;水平分割大表格等方法来降低该值。系统瓶颈分析举例-2分段排除错误。测试工具可以模拟不同的虚拟用户来单独访问Web服务器、应用服务器和数据库服务器,这样,就可以在Web端测出的响应时间减去以上各个分段测出的时间就可以知道瓶颈在哪并着手调优。系统瓶颈分析举例-3UNIX资源监控(NT操作系统同理)中指标内存页交换速率(Pagingrate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。“Swapinrate”和“Swapoutrate”也有类似的解释。系统瓶颈分析举例-4UNIX资源监控(NT操作系统同理)中指标CPU占用率(CPUutilization),如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。合理使用的范围在60%至70%。系统瓶颈分析举例-5UNIX资源监控(NT操作系统同理)中指标磁盘交换率(Diskrate),如果该参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统、重新部署业务逻辑等,另外设置TempdbinRAM,减低"maxasyncIO","maxlazywriterIO"等措施都会降低该值。系统瓶颈分析举例-6SQLServer资源监控中指标缓存点击率(CacheHitRatio),该值越高越好。如果持续低于80%,应考虑增加内存。注意该参数值是从SQLServer启动后,就一直累加记数,所以运行经过一段时间后,该值将不能反映系统当前值。6.4.2压力测试压力测试(Stresstest),也称为强度测试、负载测试。压力测试是模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时间或超大负荷地运行测试软件,来测试被测系统的性能、可靠性、稳定性等。压力测试类型

并发性能测试(重点)疲劳强度测试大数据量测试在一种需要反常(如长时间的峰值)数量、频率或资源的方式下,执行可重复的负载测试,以检查程序对异常情况的抵抗能力,找出性能瓶颈。从本质上来说,测试者是想要破坏程序。并发性能测试考察客户端应用的性能,测试的入口是客户端并发性能测试的过程,是一个负载测试和压力测试的过程。即逐渐增加并发虚拟用户数负载,直到系统的瓶颈或者不能接收的性能点,通过综合分析交易执行指标、资源监控指标等来确定系统并发性能的过程。并发性能测试是负载压力测试中的重要内容。ramp-up测试

疲劳强度测试通常是采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数,持续执行一段时间业务,通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。疲劳强度测试案例制定的原则是保证系统长期不间断运行的业务量,并且应该尽量去满足该条件。

Flat测试大数据量测试独立的数据量测试

针对某些系统存储、传输、统计、查询等业务进行大数据量测试

综合数据量测试

和压力性能测试、负载性能测试、并发性能测试、疲劳性能测试相结合的综合测试方案6.4.3容量测试

容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状态下还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。度量系统容量举例查看现有系统中性能与负载间的关系,并确定出现响应时间显著延长的位置“拐点”。可以确定是否需要增加资源以支持额外的用户。6.4.4安全性测试根据ISO8402的定义,安全性是“使伤害或损害的风险限制在可接受的水平内”。安全性测试

安全性测试是检查系统对非法侵入的防范能力。安全测试期间,测试人员假扮非法入侵者,采用各种办法试图突破防线。例如:

想方设法截取或破译口令;专门开发软件来破坏系统的保护机制;故意导致系统失败,企图趁恢复之机非法进入;试图通过浏览非保密数据,推导所需信息等等。理论上讲,只要有足够的时间和资源,没有不可进入的系统。因此系统安全设计的准则是,使非法侵入的代价超过被保护信息的价值,此时非法侵入者已无利可图。6.4.5可靠性测试

可靠性(Reliability)是产品在规定的条件下和规定的时间内完成规定功能的能力,它的概率度量称为可靠度。软件可靠性是软件系统的固有特性之一,它表明了一个软件系统按照用户的要求和设计的目标,执行其功能的可靠程度。软件可靠性与软件缺陷有关,也与系统输入和系统使用有关。理论上说,可靠的软件系统应该是正确、完整、一致和健壮的。规定的时间

规定的环境条件规定的功能可靠性测试结果的评估成熟性度量可以通过错误发现率DDP(DefectDetectionPercentage)来表现。在测试中查找出来的错误越多,实际应用中出错的机会就越小,软件也就越成熟。DDP=测试发现的错误数量/已知的全部错误数量已知的全部错误数量是测试已发现的错误数量加上可能会发现的错误数量之和。故障转移测试Failover测试:故障转移(Failover)和故障恢复(Failback).服务器的Failover测试的目的:检查系统是否具备某种灾难性恢复的手段.当系统局部或全部出错时,能否在指定时间内修正错误.具有良好故障恢复

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论