监理工作-软件监理测试工作-参考课件

申明敬告: 本站不保证该用户上传的文档完整性,不预览、不比对内容而直接下载产生的反悔问题本站不予受理。

文档介绍

监理工作-软件监理测试工作-参考课件

北京市质易达工程监理有限责任公司2009年09月**工程系统工程监理-软件测试工作n1.软件测试的原则和标准测试的定义•软件测试是为了发现错误而执行程序的过程,广义上的测试包括代码和文档。•软件测试是根据程序开发阶段的规格说明及程序内部结构而精心设计的一批测试用例(输入数据及其预期结果的集合),并利用这些测试用例去运行程序,以发现错误的过程。测试的目的:验证对象之间的交互;验证软件的所有构件是否正确集成;确认所有需求是否已经正确实施;确定缺陷并确保在部署软件之前将缺陷解决;尽早尽可能多发现缺陷;提高软件产品的质量。n测试的生命周期在软件开发生命周期中,软件是通过迭代来不断加以完善的。在这种环境中,对于每个作为测试目标的工作版本,测试的生命周期还都必须具有一种迭代方法。计划:标志测试条件(确定测试什么)和测试的优先级设计:设计测试用例(确定怎么测试)开发:测试开发(设计脚本、数据等)执行:执行测试用例评估:将测试结果与期望结果进行比较n软件测试的原则和标准软件测试的原则原则一:穷尽测试是不可能的,不充分的测试是愚蠢的,过度的测试也是一种罪孽原则二:测试工作具有创造性,但很困难原则三:测试旨在防止错误的发生原则四:测试是有风险的原则五:测试要有计划性原则六:测试要有独立性(测试部门、小组)n测试的局限性程序测试可以表明缺陷的存在,但决不能证明没有缺陷。测试必须用需求作为参考点。如果需求是错误的或不完全的,就会产生假的测试。基于实现的测试并不能发现遗漏,正如缺少的代码不能被测试一样。从来都不能确信一个正在测试的系统是正确的,测试设计中的错误,可能产生假的测试结果。得到一个预测是困难的,有的甚至是不可能的n常用词汇错误(Error):Bug缺陷(Fault):是错误的表现失效(failure):当缺陷执行时会发生失效事故(incident):系统在制定范围内执行所需功能时表现的无能测试脚本:一个用过程脚本语言编写的程序,该程序用来执行一个测试包测试包:测试实例的集合测试装置:由测试驱动器和其他支持测试执行的工具组成的系统。测试用例(TestCase):由输入数据和预期结果组成。输入数据:数据、文件或操作序列,预期结果:后果和实际输出n黑盒测试黑盒测试(Black—boxTesting)又称功能测试、数据驱动测试或基于规格说明的测试,是一种从用户观点出发的测试。被测程序被当作一个黑盒,不考虑程序内部结构和内部特性,测试者只知道该程序输入和输出之间的关系或程序的功能,依靠能够反映这一关系和程序功能的需求规格说明书考虑确定测试用例和推断测试结果的正确性。软件的黑盒测试被用来证实软件功能的正确性和可操作性。n白盒测试白盒测试(White—boxTesting)又称结构测试、逻辑驱动测试或基于程序的测试。它依赖于对程序细节的严密检验,针对特定条件设计测试用例,对软件的逻辑路经进行测试。在程序的不同点检验“程序的状态”以判定其实际情况是否和预期的状态相一致。软件的白盒测试用来分析程序的内部结构。n白盒测试要求对某些程序的结构特性做到一定程度的覆盖,或者说是“基于覆盖的测试”。最为常见的程序结构覆盖有:语句覆盖:它要求被测程序的每一可执行语句在测试中尽可能都检验过,这是最弱的逻辑覆盖准则;分支覆盖或判定覆盖:要求程序中所有判定的分支尽可能得到检验;条件覆盖:当判定式中含有多个条件时,要求每个条件的取值均得到检验;判定/条件覆盖:同时考虑条件的组合值及判定结果的检验;路径覆盖:只考虑对程序路径的全面检验。n回归测试目标:①修改的或增加的部分是正确的②没有引起其他部分产生错误应用:①增量开发②版本控制③软件维护nα测试和β测试α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。n测试的分类?静态分析?功能测试?用户界面测试?性能测试?负载测试?强度测试?容量测试?配置测试?安装测试安全性测试兼容性测试n测试的标准GB/T16260-1996信息技术软件产品评价质量特性及其使用指南GB/T17544-1998信息技术软件包质量要求和测试GB/T8567-1988计算机软件产品开发文件编制指南GB/T9385-1988计算机软件需求说明编制指南GB/T9386-1988计算机软件测试文件编制规范GB/T11457-1995软件工程术语GB/T13502-1992信息处理程序构造及其表示的约定GB/T14085-1993信息处理系统计算机系统配置图符号及约定GB/T14394-1993计算机软件可靠性和可维护性管理GB/T15189-1994DOS中文信息处理系统接口规范GB/T15532-1995计算机软件单元测试B/T15535-1995信息处理单命中判定表规范GB/T1526-1989信息处理数据流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定GB/T16680-1996软件文档管理指南GB/T8566-2001信息技术软件生存期过程n测试相关模型n需求分析系统设计详细设计编码单元测试集成测试系统测试验收测试时间程序员的理解=用户的理解详细程度V模型(改良)n评价优点文档驱动的开发模型。改良后的模型很注重反馈和测试,其中V模型提出了测试驱动开发的概念。在需求非常明确的前提下可以使用,也适用于有长期专职开发人员的小型项目开发。不足:严格限定了开发的各阶段,缺乏迭代性。缺乏对变化的支持。n原型法Brooks1975设计实现测试维护需求设计实现测试原型n设计实现初始原型初始概念修改原型直至被接受完成发布原型最终产品目的是和用户一起开发并完善一个原型,从最清楚的需求部分开始。进化原型法n评价优点:需求驱动的开发模型。帮助理解需求。增强和用户的交流,增加用户好感。不足:缺乏结构化的系统和严谨的开发流程,很难作为一个项目进行管理。n迭代1迭代2迭代3分析设计编码测试发布1分析设计编码测试发布2分析设计编码测试发布3迭代n分析设计编码测试最终发布……..增量型(例RUP)n评价优点:开发过程分解为多个迭代过程,每个过程可以有自己的开发模型。可以快速提交可用的系统,然后根据反馈实施下一个迭代。不足:是一个开发框架,对每个迭代的具体过程缺乏支持:1)如果迭代太少,很容易会蜕变为Code-Fix模式,迭代太多则往往因文档驱动而导致测试和集成的复杂度和费用太大。2)因而无法克服以往开发模型的不足。经常蜕变成Waterfall模型。n简单设计迭代计划测试驱动Pair开发持续集成重构1..N个Iteration发布计划1..N个Release小发布发布1..N个TaskXP的增量过程n失败通过时间单元测试100%通过设计先写单元测试重构运行单元测试编程发现BUG集成先写功能测试UserStory运行功能测试测试驱动开发n软件开发的测试过程n招投标及合同签订阶段在合同中应该明确功能测试的基础《需求规格说明书》,并明确性能测试的方法、其它需测试的类型以及第三方测试等。在现在的投标书中,有在投标文件中提出验证方法的现象,应引起注意。(P1538.2)在监理规划中,应该对软件测试的监理过程方式(旁站、抽查等)进行明确。n开发生命周期中的验证活动开发阶段验证活动需求.确定验证步骤.对需求进行评审.产生功能测试用例.确定需求一致性n需求阶段监理任务对测试计划以及测试用例的审核审核主体:测试计划(参阅测试计划审查表)审核注意事项:时间人员安排测试环境:软、硬件、具体地点测试的依据和标准测试方法及软件,测试的可行性执行和维护需求的可行性与可测性集成、验收测试的进入、结束条件验收需求对测试设计、用例、规程、经过的跟踪测试计划的编制需符合GB/T9386标准n测试用例审核功能用例是否完全覆盖注意软件性能、安装、配置测试的约定n开发阶段验证活动设计.确定设计信息是否足够.准备结构和功能的测试用例.确定设计的一致性n设计阶段继续对功能性测试用例进行细化提交接口等测试方法对单元测试的过程、方法进行确认,核实是否已覆盖控制流和数据流提交各模块单元、集成测试方案?算法和逻辑?模块接口?数据结构(全局和局部)?边界条件?独立的路径?错误处理人员,环境,工具……n开发阶段验证活动编码单元测试.为单元测试产生了完整的结构和功能测试的测试用例.进行了足够的单元测试.主要进行白盒测试,辅助以黑盒测试.对合理、不合理输入进行鉴别和响应.在测试的过程中,需对所有的局部和全局数据结构、外部接口、程序代码的关键部分实施严格的代码审查。.多个模块可以平行的独立进行单元测试n测试阶段和测试方法n单元测试目的:分别完成每个单元的测试任务,以确保每个模块能正常工作。单元测试单元测试在迭代的早期实施,侧重于核实软件的最小可测试元素。单元测试通常应用于实施模型中的构件,核实是否已覆盖控制流和数据流,以及构件是否可以按照预期工作。n单元测试检验程序最小单位有无错误。一般在编码之后,由开发人员完成。实施效果非常好,但是实施阻力比较大“不可能出问题”“小子,我的代码肯定没错”“天,我这是怎么了,如此简单的错误”“以后绝对不可能了”n单元测试的进入条件完成单元模块编码代码编译无错误开发单元纳入承建单位配置受控库n单元测试的内容单元功能测试模块接口测试局部数据结构测试路径测试错误处理测试边界测试重要模块的性能测试n单元测试的成果单元测试报告测试记录,测试结果分析软件问题报告单,软件修改报告单经修改的代码回归测试记录和结果n单元测试过程驱动程序:用于模拟主程序的运行桩模块:用于模拟子程序的运行n静态分析•对源代码的静态分析:主要分析代码中的类型、引用、参数传递,以及表达式等不用运行就能够发现的错误;另外还有一些容易出错的地方,如空指针赋值、下标越界等。还可以检查诸如命名规则等编程规范。•此项测试在监理的过程中,一般可以通过代码巡查的过程来保证。n集成测试又称为组装测试或者联合测试在单元测试的基础上进行将所有模块按概要设计、详细设计的要求进行组装。在进行集成测试时,必须确定关键模块(重要需求,高层控制模块,复杂易错模块,明确性能要求模块),对关键模块及早进行测试。在做回归测试时,也应集中测试关键模块。集成测试的目的:在模块组装后查找模块间接口的错误n为什么进行集成测试?一个模块可能对另一个模块产生不利的影响将子功能合成时不一定产生所期望的主功能独立可接受的误差,在组装后可能会超过可接受的误差限度可能会发现单元测试中未发现的接口方面的错误在单元测试中无法发现时序问题(实时系统)在单元测试中无法发现资源竞争问题n集成测试的方法:非增式测试:采用一步到位的方法来构造测试:对所有模块进行个别的单元测试后,按程序结构图将各模块联接起来,把联接后的程序当作一个整体进行测试。增式测试:把下一个要测试的模块同已经测试好的模块结合起来进行测试,一次增加一个测试的模块。nn自顶向下增式测试集成步骤:主控模块作为测试驱动,所有与主控模块直接相连的模块作为桩模块;根据集成的方式(深度或广度),每次用一个替换从属的桩模块;在每个模块被集成时,都必须已经进行了单元测试;进行回归测试以确定集成新模块后没有引入错误上述过程从第2步重复进行,直到整个系统结构被集成完成。n自底向上增式测试工作程序:组装从最底层的模块开始,组合成一个构件,用以完成指定的软件子功能编制驱动程序,协调测试用例的输入与输出测试集成后的构件按程序结构向上组装测试后的构件,同时除掉驱动程序n集成测试为一种正式测试过程必须与单元测试协调进行必须提交完整的测试计划及方案采用何种系统组装方法测试中各模块的连接顺序模块代码编制和测试进度是否与集成测试的顺序一致测试过程中是否需要专门的硬件设备计划中应包括:各模块的编制、测试计划表,标明各模块单元测试完成、首次集成测试、集成测试全部完成的日期,需要的测试用例,期望的测试结果;以及其它人员安排等n集成测试结束条件成功的执行了测试计划中的所有集成测试修正了测试中的错误修正通过了回归测试测试结果通过评审n集成测试的结果集成测试报告软件使用说明软件问题报告单和软件修改报告单修改的源代码n监理工作集成测试和单元测试一般情况下都是结合执行的。在进行单元测试和集成测试时,对测试方案可以不详细要求,监理一般情况下不对单元测试进行全程跟踪,在实际过程中,单元测试和集成测试都由承建单位自行实施。在必要情况下可以要求承建单位按天提交单元测试报告可以对单元测试结果进行抽查可分析测试报告,对错误点在系统测试阶段加以注意,同时,注意每天测试的缺陷的收敛情况。部分情况下,单元测试的时候也可以要求做核心单元的性能测试。在进行系统及验收测试前,必须要求承建单位提交集成测试结果,对集成测试可以抽查。n测试工具的选择JunitPurifyPlusRationalRobot等nPurifyPlusPurifyPlusPurifyPureCoverageQuantifynPurifyPlusIBMRational的测试工具包,主要包括:内存和资源检查工具:Purify性能瓶颈检查工具:Quantify代码覆盖测试工具:PureCoveragenPurify查找问题内存错误内存泄露支持语言C,C++JavaAda支持平台WindowsUnixLinuxSolarisHP-Unix处理类型WindowsDLLMFCDLLVC,VB构件IE,Netscape,Office构件Excel,Wordplug-in基于COM的OLE或ActiveX构件n运行信息窗口n相同的错误缺省状态下,Purify对同一类错误统计次数UMR发生了57次n代码覆盖情况点击可排序双击打开代码统计n行代码调用情况行调用次数n比较运行数据RunControl->CompareRunsn分析内存差异内存差异越大,线条越粗CallGraph概览,可以调节显示范围可以调节显示范围nPureCoverage功能代码覆盖统计支持语言C,C++JavaVB.NET支持平台WindowsUnixLinuxSolarisHP-Unix处理类型WindowsDLLMFCDLLVC,VB构件IE,Netscape,Office构件Excel,Wordplug-in基于COM的OLE或ActiveX构件Javaapplet,class,jarnHello的运行选择No函数覆盖率50%行覆盖率31.25%n代码行覆盖情况运行的代码未运行的代码nJunit的运行结果n开发阶段验证活动测试.测试应用系统,着重在功能、性能上.验收测试方案的审核.测试用例的审核.主要进行系统测试、验收测试n进入条件所有的测试的硬件安装、配置和运行已成功通过测试所有需要的软件已成功安装、配置并测试通过所有测试阶段文档已完成并通过评审所有上一阶段的测试工作已完成单元测试通过预测试通过n监理主要工作对测试方案的审核对测试用例的审核对测试结果进行抽查最好不旁站功能测试过程性能测试过程可以旁站,但要求承建单位应提前进行准备,确保测试过程的顺利n测试方案审核对测试计划的细化可操作性时间人员安排测试环境:软、硬件、具体地点测试的需求覆盖率测试的依据和标准,预期的结果测试方法及软件集成、验收测试的进入、结束条件验收需求对测试设计、用例、规程的跟踪测试计划的编制需符合GB/T9386标准n测试用例审核按需求的场景、工作流基本事件流,备选流1,备选流2……对每个事件流准备测试用例测试的需求覆盖性测试用例:标志符要测试的特性,测试项测试方法:输入、输出说明测试用例信息:环境要求、其它特殊要求用例之间的依赖型通过/失败的规则n系统测试---确认测试功能测试*容量测试强度测试*安全测试可使用性测试*性能测试资源使用测试*配置测试兼容性测试*安装测试可靠性测试*回归测试α测试*β测试n用户界面测试符合标准和规范Mac:MacintoshHumanInterfaceGuidelineWindows:MicrosoftWindowsUserExperience尽量减少用户的工作直观性一致性灵活性舒适性正确性实用性n功能测试•验证软件是否提供了所期待的服务。包括:•“主要”方案--所有的输入是合法的。•“辅助”方案--一些或所有的输入是不合法的性能测试•响应时间•并发性•吞吐量•处理精度n强度测试:检查在系统运行环境不正常乃至发生故障的情况下,系统可以运行到何种程度的测试.把输入数据速率提高一个数量级,确定输入功能将如何响应。设计需要占用最大存储量或其它资源,会对磁盘常驻内存的数据过度访问的测试用例进行测试。•资源少的情况下发现可能的错误:低内存,磁盘空间不足•共享资源竞争的情况下发现可能的错误?系统资源数据库加锁网络带宽n容量测试•使软件经受大数据量的考验,以确定达到限制时是否引发软件失败,容量测试是要检验系统的能力最高能达到什么程度。例如,?对于编译程序,让它处理特别长的源程序;?对于操作系统,让它的作业队列“满员”;?对于信息检索系统,让它使用频率达到最大。在使系统的全部资源达到“满负荷”的情形下,测试系统的承受能力。n安全性测试目标安全性的缺陷很难被发现。大多数的情况下组织能够防止一般性的破坏者。例子定义了被保护的资源,权限进行了控制,日志文件和审查追踪是可用的。n配置测试检查计算机系统内各个设备或各种资源之间的相互联结和功能分配中的错误。软件配置硬件配置安装测试•是否能正确安装??初次安装升级安装完全安装定制安装•安装后,操作是否正确?n安装测试安装测试的目的不是找软件错误,而是找安装错误。安装软件系统时,会有多种选择。要分配和装入文件与程序库布置适用的硬件配置进行程序的联结。安装测试是在系统安装之后进行测试。它要检验:用户选择的一套任选方案是否相容;系统的每一部分是否都齐全;所有文件是否都已产生并确有所需要的内容;硬件的配置是否合理。n功能测试性能测试的方法、软件功能测试常使用手动方式完成部分情况下可使用自动化测试工具测试的主要内容包括:边界值分析:范围的边界内,最小值,稍高于最小值,正常值,稍低于最大值,最大值健壮性测试:是边界值分析的一种简单扩展,除了使用五个边界值分析取值,还要通过采用一个略超过最大值的取值,以及一个略小于最小值的取值。最坏情况测试:会产生5n个测试用例特殊值测试n性能测试性能测试中的基本概念?响应时间(ResponseTime)?点击数(Hits)?页面请求(Pageview)?吞吐量(Throughout)并发用户数*(HTML文档大小)/请求时间?并发用户(ConcurrencyUser)?资源利用率(ResourceUsage)n预期性能指标测试用例需求来源:---产品设计前的预期参数---项目对客户保证的性能指数用户并发性能测试?核心模块的测试?可以理解为“单元性能测试”?针对核心功能模块进行并发用户测试,?测试系统是否能够稳定运行?主要是针对易独立并发、或者使用频繁的模块nnnn通用指标?ProcessorTime:指服务器CPU占用率,一般平均达到70%时,服务就接近饱和;?MemoryAvailableMbyte:可用内存数,如果测试时发现内存有变化情况也要注意,如果是内存泄露则比较严重;?PhysicsdiskTime:物理磁盘读写时间情况;n统计调查结果?事务响应时间不超过4秒,可以接受?事务响应时间大于4秒小于9秒,30%用户会撤消事务?事务响应时间大于8秒小于10秒,60%用户会撤消事务?事务响应时间超过10秒,超过90%用户会撤消事务n性能测试的分类性能测试类型包括:?负载测试:确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。?强度测试:强度测试是一种性能测试,在系统资源特别低的情况下软件系统运行情况。?容量测试:确定系统可处理同时在线的最大用户数(在用户可接收的范围内)。?压力测试:通过确定一个系统的瓶颈或者最大使用极限的测试。n疲劳强度测试:系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数,持续执行一段时间业务,通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。大数据量测试?独立的数据量测试:针对某些系统存储、传输、统计、查询等业务进行大数据量测试?综合数据量测试:和压力性能测试、负载性能测试、疲劳性能测试相结合的综合测试方案n疲劳强度与大数据量测试?疲劳测试目的:确定系统处理最大工作量的性能。?内容:在系统稳定运行下,模拟最大或者恰当的用户数目、长时间运行系统,通过综合分析执行指标和资源监控来分析系统的稳定性。nn大数据量测试分为两种:?针对某些系统存储、传输、统计查询等业务进行大数据量的测试,可以通过工具完成;?数据库性能测试,可以编写程序和测试工具结合实现nn网络性能测试?主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。?测试用户数目与网络带宽的关系。?用例的编写应和用户并发测试结合起来:例如在原有的基础上采用工具来调整网络设置。nn服务器性能测试?测试用例不必独立编写,也可以根据实际需要编写少量的测试用例。系统集成部会完成一部分工作。?建议:这部分和前两部分的用例编写结合起来,在用户并发性能测试、疲劳强度与大数据量性能测试时完成对服务器性能的监控。nn性能测试脚本设计准备包含适量数据的测试数据库?书写组成负载的系统事务脚本?书写需要度量响应时间的系统事务脚本?工作量定义的开发(即负载概况的执行)?准备自动脚本参数化所需要的测试数据n分析与报告测试结果响应时间?测量值?最小响应时间?最大响应时间?平均响应时间?95%的响应时间?响应时间需求与测试结果的比较?系统的吞吐量?实际事务率和吞吐量?判断与模拟的负载概况是否相一致n?通过图表方式列出响应时间与负载的关系?随着负载的增加性能降低的频率?在可接受的响应时间内能达到的最大吞吐量?某段时间内资源的使用情况?将资源使用与当时应用负载情况相关联,有助于寻找系统框架中的瓶颈n3.测试工具n测试驱动工具的功能基本功能?建立网络连接?读取标准输入数据、准备命令行数据或准备传播的消息?承认来自远程服务器的响应?可以配置发送信息的频率?复杂功能?记录提交到服务器的事务的响应时间?在需要建立成千上百个虚拟客户端的时候,可以复制自己,在不同的实例间同步
查看更多

相关文章

您可能关注的文档