监理工作-软件监理测试工作-参考_第1页
监理工作-软件监理测试工作-参考_第2页
监理工作-软件监理测试工作-参考_第3页
监理工作-软件监理测试工作-参考_第4页
监理工作-软件监理测试工作-参考_第5页
已阅读5页,还剩94页未读 继续免费阅读

下载本文档

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

文档简介

监理工作-软件监理测试工作-参考第一页,共99页。1.软件测试的原则和标准测试的定义•软件测试是为了发现错误而执行程序的过程,广义上的测试包括代码和文档。•软件测试是根据程序开发阶段的规格说明及程序内部结构而精心设计的一批测试用例(输入数据及其预期结果的集合),并利用这些测试用例去运行程序,以发现错误的过程。测试的目的:验证对象之间的交互;验证软件的所有构件是否正确集成;确认所有需求是否已经正确实施;确定缺陷并确保在部署软件之前将缺陷解决;尽早尽可能多发现缺陷;提高软件产品的质量。第二页,共99页。测试的生命周期

在软件开发生命周期中,软件是通过迭代来不断加以完善的。在这种环境中,对于每个作为测试目标的工作版本,测试的生命周期还都必须具有一种迭代方法。计划:标志测试条件(确定测试什么)和测试的优先级设计:设计测试用例(确定怎么测试)开发:测试开发(设计脚本、数据等)执行:执行测试用例评估:将测试结果与期望结果进行比较第三页,共99页。软件测试的原则和标准软件测试的原则原则一:穷尽测试是不可能的,不充分的测试是愚蠢的,过度的测试也是一种罪孽原则二:测试工作具有创造性,但很困难原则三:测试旨在防止错误的发生原则四:测试是有风险的原则五:测试要有计划性原则六:测试要有独立性(测试部门、小组)第四页,共99页。测试的局限性程序测试可以表明缺陷的存在,但决不能证明没有缺陷。测试必须用需求作为参考点。如果需求是错误的或不完全的,就会产生假的测试。基于实现的测试并不能发现遗漏,正如缺少的代码不能被测试一样。从来都不能确信一个正在测试的系统是正确的,测试设计中的错误,可能产生假的测试结果。得到一个预测是困难的,有的甚至是不可能的第五页,共99页。常用词汇错误(Error):Bug缺陷(Fault):是错误的表现失效(failure):当缺陷执行时会发生失效事故(incident):系统在制定范围内执行所需功能时表现的无能测试脚本:一个用过程脚本语言编写的程序,该程序用来执行一个测试包测试包:测试实例的集合测试装置:由测试驱动器和其他支持测试执行的工具组成的系统。测试用例(TestCase):由输入数据和预期结果组成。输入数据:数据、文件或操作序列,预期结果:后果和实际输出第六页,共99页。黑盒测试黑盒测试(Black—boxTesting)又称功能测试、数据驱动测试或基于规格说明的测试,是一种从用户观点出发的测试。被测程序被当作一个黑盒,不考虑程序内部结构和内部特性,测试者只知道该程序输入和输出之间的关系或程序的功能,依靠能够反映这一关系和程序功能的需求规格说明书考虑确定测试用例和推断测试结果的正确性。软件的黑盒测试被用来证实软件功能的正确性和可操作性。第七页,共99页。白盒测试白盒测试(White—boxTesting)又称结构测试、逻辑驱动测试或基于程序的测试。它依赖于对程序细节的严密检验,针对特定条件设计测试用例,对软件的逻辑路经进行测试。在程序的不同点检验“程序的状态”以判定其实际情况是否和预期的状态相一致。软件的白盒测试用来分析程序的内部结构。第八页,共99页。白盒测试要求对某些程序的结构特性做到一定程度的覆盖,或者说是“基于覆盖的测试”。最为常见的程序结构覆盖有:语句覆盖:它要求被测程序的每一可执行语句在测试中尽可能都检验过,这是最弱的逻辑覆盖准则;分支覆盖或判定覆盖:要求程序中所有判定的分支尽可能得到检验;条件覆盖:当判定式中含有多个条件时,要求每个条件的取值均得到检验;判定/条件覆盖:同时考虑条件的组合值及判定结果的检验;路径覆盖:只考虑对程序路径的全面检验。第九页,共99页。回归测试目标:①修改的或增加的部分是正确的②没有引起其他部分产生错误应用:①增量开发②版本控制③软件维护第十页,共99页。α测试和β测试α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。第十一页,共99页。测试的分类静态分析功能测试用户界面测试性能测试负载测试强度测试容量测试配置测试安装测试

安全性测试兼容性测试第十二页,共99页。测试的标准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信息技术软件生存期过程第十三页,共99页。测试相关模型第十四页,共99页。需求分析系统设计详细设计编码单元测试集成测试系统测试验收测试时间程序员的理解=用户的理解

详细程度V模型(改良)第十五页,共99页。评价优点文档驱动的开发模型。改良后的模型很注重反馈和测试,其中V模型提出了测试驱动开发的概念。在需求非常明确的前提下可以使用,也适用于有长期专职开发人员的小型项目开发。不足:严格限定了开发的各阶段,缺乏迭代性。缺乏对变化的支持。第十六页,共99页。原型法

Brooks1975设计实现测试维护需求设计实现测试原型第十七页,共99页。设计实现初始原型初始概念修改原型直至被接受完成发布原型最终产品目的是和用户一起开发并完善一个原型,从最清楚的需求部分开始。进化原型法第十八页,共99页。评价优点:需求驱动的开发模型。帮助理解需求。增强和用户的交流,增加用户好感。不足:缺乏结构化的系统和严谨的开发流程,很难作为一个项目进行管理。第十九页,共99页。迭代1迭代2迭代3分析设计编码测试发布1分析设计编码测试发布2分析设计编码测试发布3迭代n分析设计编码测试最终发布……..增量型(例RUP)第二十页,共99页。评价优点:开发过程分解为多个迭代过程,每个过程可以有自己的开发模型。可以快速提交可用的系统,然后根据反馈实施下一个迭代。不足:是一个开发框架,对每个迭代的具体过程缺乏支持:1)如果迭代太少,很容易会蜕变为Code-Fix模式,迭代太多则往往因文档驱动而导致测试和集成的复杂度和费用太大。2)因而无法克服以往开发模型的不足。经常蜕变成Waterfall模型。第二十一页,共99页。简单设计迭代计划测试驱动Pair开发持续集成重构1..N个Iteration发布计划1..N个Release小发布发布1..N个TaskXP的增量过程第二十二页,共99页。失败通过时间单元测试100%

通过设计先写单元测试重构运行单元测试编程发现BUG集成先写功能测试UserStory运行功能测试测试驱动开发第二十三页,共99页。软件开发的测试过程第二十四页,共99页。招投标及合同签订阶段在合同中应该明确功能测试的基础《需求规格说明书》,并明确性能测试的方法、其它需测试的类型以及第三方测试等。在现在的投标书中,有在投标文件中提出验证方法的现象,应引起注意。(P1538.2)在监理规划中,应该对软件测试的监理过程方式(旁站、抽查等)进行明确。第二十五页,共99页。开发生命周期中的验证活动开发阶段验证活动需求.确定验证步骤.对需求进行评审.产生功能测试用例.确定需求一致性第二十六页,共99页。需求阶段监理任务对测试计划以及测试用例的审核审核主体:测试计划(参阅测试计划审查表)审核注意事项:时间人员安排测试环境:软、硬件、具体地点测试的依据和标准测试方法及软件,测试的可行性执行和维护需求的可行性与可测性集成、验收测试的进入、结束条件验收需求对测试设计、用例、规程、经过的跟踪测试计划的编制需符合GB/T9386标准

第二十七页,共99页。测试用例审核功能用例是否完全覆盖注意软件性能、安装、配置测试的约定第二十八页,共99页。开发阶段验证活动设计.确定设计信息是否足够.准备结构和功能的测试用例.确定设计的一致性第二十九页,共99页。设计阶段继续对功能性测试用例进行细化提交接口等测试方法对单元测试的过程、方法进行确认,核实是否已覆盖控制流和数据流提交各模块单元、集成测试方案算法和逻辑模块接口数据结构(全局和局部)边界条件独立的路径错误处理人员,环境,工具……第三十页,共99页。开发阶段验证活动编码单元测试.为单元测试产生了完整的结构和功能测试的测试用例

.进行了足够的单元测试

.主要进行白盒测试,辅助以黑盒测试

.对合理、不合理输入进行鉴别和响应

.在测试的过程中,需对所有的局部和全局数据结构、外部接口、程序代码的关键部分实施严格的代码审查。

.多个模块可以平行的独立进行单元测试第三十一页,共99页。测试阶段和测试方法第三十二页,共99页。单元测试目的:分别完成每个单元的测试任务,以确保每个模块能正常工作。单元测试单元测试在迭代的早期实施,侧重于核实软件的最小可测试元素。单元测试通常应用于实施模型中的构件,核实是否已覆盖控制流和数据流,以及构件是否可以按照预期工作。第三十三页,共99页。单元测试检验程序最小单位有无错误。一般在编码之后,由开发人员完成。实施效果非常好,但是实施阻力比较大“不可能出问题”“小子,我的代码肯定没错”“天,我这是怎么了,如此简单的错误”“以后绝对不可能了”第三十四页,共99页。单元测试的进入条件完成单元模块编码代码编译无错误开发单元纳入承建单位配置受控库第三十五页,共99页。单元测试的内容单元功能测试模块接口测试局部数据结构测试路径测试错误处理测试边界测试重要模块的性能测试第三十六页,共99页。单元测试的成果单元测试报告测试记录,测试结果分析软件问题报告单,软件修改报告单经修改的代码回归测试记录和结果第三十七页,共99页。单元测试过程驱动程序:用于模拟主程序的运行桩模块:用于模拟子程序的运行第三十八页,共99页。静态分析•对源代码的静态分析:主要分析代码中的类型、引用、参数传递,以及表达式等不用运行就能够发现的错误;另外还有一些容易出错的地方,如空指针赋值、下标越界等。还可以检查诸如命名规则等编程规范。•此项测试在监理的过程中,一般可以通过代码巡查的过程来保证。第三十九页,共99页。集成测试又称为组装测试或者联合测试在单元测试的基础上进行将所有模块按概要设计、详细设计的要求进行组装。在进行集成测试时,必须确定关键模块(重要需求,高层控制模块,复杂易错模块,明确性能要求模块),对关键模块及早进行测试。在做回归测试时,也应集中测试关键模块。集成测试的目的:在模块组装后查找模块间接口的错误第四十页,共99页。为什么进行集成测试?一个模块可能对另一个模块产生不利的影响将子功能合成时不一定产生所期望的主功能独立可接受的误差,在组装后可能会超过可接受的误差限度可能会发现单元测试中未发现的接口方面的错误在单元测试中无法发现时序问题(实时系统)在单元测试中无法发现资源竞争问题第四十一页,共99页。集成测试的方法:非增式测试:采用一步到位的方法来构造测试:对所有模块进行个别的单元测试后,按程序结构图将各模块联接起来,把联接后的程序当作一个整体进行测试。增式测试:把下一个要测试的模块同已经测试好的模块结合起来进行测试,一次增加一个测试的模块。第四十二页,共99页。第四十三页,共99页。自顶向下增式测试

集成步骤:主控模块作为测试驱动,所有与主控模块直接相连的模块作为桩模块;根据集成的方式(深度或广度),每次用一个替换从属的桩模块;在每个模块被集成时,都必须已经进行了单元测试;进行回归测试以确定集成新模块后没有引入错误上述过程从第2步重复进行,直到整个系统结构被集成完成。第四十四页,共99页。自底向上增式测试工作程序:组装从最底层的模块开始,组合成一个构件,用以完成指定的软件子功能编制驱动程序,协调测试用例的输入与输出测试集成后的构件按程序结构向上组装测试后的构件,同时除掉驱动程序第四十五页,共99页。集成测试为一种正式测试过程必须与单元测试协调进行必须提交完整的测试计划及方案采用何种系统组装方法测试中各模块的连接顺序模块代码编制和测试进度是否与集成测试的顺序一致测试过程中是否需要专门的硬件设备计划中应包括:各模块的编制、测试计划表,标明各模块单元测试完成、首次集成测试、集成测试全部完成的日期,需要的测试用例,期望的测试结果;以及其它人员安排等第四十六页,共99页。集成测试结束条件成功的执行了测试计划中的所有集成测试修正了测试中的错误修正通过了回归测试测试结果通过评审第四十七页,共99页。集成测试的结果集成测试报告软件使用说明软件问题报告单和软件修改报告单修改的源代码第四十八页,共99页。监理工作集成测试和单元测试一般情况下都是结合执行的。在进行单元测试和集成测试时,对测试方案可以不详细要求,监理一般情况下不对单元测试进行全程跟踪,在实际过程中,单元测试和集成测试都由承建单位自行实施。在必要情况下可以要求承建单位按天提交单元测试报告可以对单元测试结果进行抽查可分析测试报告,对错误点在系统测试阶段加以注意,同时,注意每天测试的缺陷的收敛情况。部分情况下,单元测试的时候也可以要求做核心单元的性能测试。在进行系统及验收测试前,必须要求承建单位提交集成测试结果,对集成测试可以抽查。

第四十九页,共99页。测试工具的选择JunitPurifyPlusRationalRobot等第五十页,共99页。PurifyPlusPurifyPlusPurifyPureCoverageQuantify第五十一页,共99页。PurifyPlusIBMRational的测试工具包,主要包括:内存和资源检查工具:Purify性能瓶颈检查工具:Quantify代码覆盖测试工具:PureCoverage第五十二页,共99页。Purify查找问题内存错误内存泄露支持语言C,C++JavaAda支持平台WindowsUnixLinuxSolarisHP-Unix处理类型WindowsDLLMFCDLLVC,VB构件IE,Netscape,Office构件Excel,Wordplug-in基于COM的OLE或ActiveX构件第五十三页,共99页。运行信息窗口第五十四页,共99页。相同的错误缺省状态下,Purify对同一类错误统计次数UMR发生了57次第五十五页,共99页。代码覆盖情况点击可排序双击打开代码统计第五十六页,共99页。行代码调用情况行调用次数第五十七页,共99页。比较运行数据RunControl->CompareRuns第五十八页,共99页。分析内存差异内存差异越大,线条越粗CallGraph概览,可以调节显示范围可以调节显示范围第五十九页,共99页。PureCoverage功能代码覆盖统计支持语言C,C++JavaVB.NET支持平台WindowsUnixLinuxSolarisHP-Unix处理类型WindowsDLLMFCDLLVC,VB构件IE,Netscape,Office构件Excel,Wordplug-in基于COM的OLE或ActiveX构件Javaapplet,class,jar第六十页,共99页。Hello的运行选择No函数覆盖率50%行覆盖率31.25%第六十一页,共99页。代码行覆盖情况运行的代码未运行的代码第六十二页,共99页。Junit的运行结果第六十三页,共99页。开发阶段验证活动测试.测试应用系统,着重在功能、性能上.验收测试方案的审核.测试用例的审核.主要进行系统测试、验收测试第六十四页,共99页。进入条件所有的测试的硬件安装、配置和运行已成功通过测试所有需要的软件已成功安装、配置并测试通过所有测试阶段文档已完成并通过评审所有上一阶段的测试工作已完成单元测试通过预测试通过第六十五页,共99页。监理主要工作对测试方案的审核对测试用例的审核对测试结果进行抽查最好不旁站功能测试过程性能测试过程可以旁站,但要求承建单位应提前进行准备,确保测试过程的顺利第六十六页,共99页。测试方案审核对测试计划的细化可操作性时间人员安排测试环境:软、硬件、具体地点测试的需求覆盖率测试的依据和标准,预期的结果测试方法及软件集成、验收测试的进入、结束条件验收需求对测试设计、用例、规程的跟踪测试计划的编制需符合GB/T9386标准第六十七页,共99页。测试用例审核按需求的场景、工作流基本事件流,备选流1,备选流2……

对每个事件流准备测试用例测试的需求覆盖性测试用例:标志符要测试的特性,测试项测试方法:输入、输出说明测试用例信息:环境要求、其它特殊要求用例之间的依赖型通过/失败的规则第六十八页,共99页。系统测试

确认测试功能测试*容量测试强度测试*安全测试可使用性测试*性能测试资源使用测试*配置测试兼容性测试*安装测试可靠性测试*回归测试

α测试*β测试第六十九页,共99页。用户界面测试符合标准和规范Mac:MacintoshHumanInterfaceGuidelineWindows:MicrosoftWindowsUserExperience尽量减少用户的工作直观性一致性灵活性舒适性正确性实用性第七十页,共99页。功能测试•验证软件是否提供了所期待的服务。包括:•“主要”方案--所有的输入是合法的。•“辅助”方案--一些或所有的输入是不合法的性能测试•响应时间•并发性•吞吐量•处理精度第七十一页,共99页。强度测试:检查在系统运行环境不正常乃至发生故障的情况下,系统可以运行到何种程度的测试.把输入数据速率提高一个数量级,确定输入功能将如何响应。设计需要占用最大存储量或其它资源,会对磁盘常驻内存的数据过度访问的测试用例进行测试。•资源少的情况下发现可能的错误:低内存,磁盘空间不足•共享资源竞争的情况下发现可能的错误系统资源数据库加锁网络带宽第七十二页,共99页。容量测试•使软件经受大数据量的考验,以确定达到限制时是否引发软件失败,容量测试是要检验系统的能力最高能达到什么程度。例如,对于编译程序,让它处理特别长的源程序;对于操作系统,让它的作业队列“满员”;对于信息检索系统,让它使用频率达到最大。在使系统的全部资源达到“满负荷”的情形下,测试系统的承受能力。第七十三页,共99页。安全性测试目标安全性的缺陷很难被发现。大多数的情况下组织能够防止一般性的破坏者。例子定义了被保护的资源,权限进行了控制,日志文件和审查追踪是可用的。第七十四页,共99页。配置测试检查计算机系统内各个设备或各种资源之间的相互联结和功能分配中的错误。软件配置硬件配置安装测试•是否能正确安装?初次安装升级安装完全安装定制安装•安装后,操作是否正确?第七十五页,共99页。安装测试

安装测试的目的不是找软件错误,而是找安装错误。安装软件系统时,会有多种选择。要分配和装入文件与程序库布置适用的硬件配置进行程序的联结。安装测试是在系统安装之后进行测试。它要检验:用户选择的一套任选方案是否相容;系统的每一部分是否都齐全;所有文件是否都已产生并确有所需要的内容;硬件的配置是否合理。第七十六页,共99页。功能测试性能测试的方法、软件功能测试常使用手动方式完成部分情况下可使用自动化测试工具测试的主要内容包括:边界值分析:范围的边界内,最小值,稍高于最小值,正常值,稍低于最大值,最大值健壮性测试:是边界值分析的一种简单扩展,除了使用五个边界值分析取值,还要通过采用一个略超过最大值的取值,以及一个略小于最小值的取值。最坏情况测试:会产生5n个测试用例特殊值测试第七十七页,共99页。性能测试性能测试中的基本概念响应时间(ResponseTime)点击数(Hits)页面请求(Pageview)吞吐量(Throughout)并发用户数*(HTML文档大小)/请求时间并发用户(ConcurrencyUser)资源利用率(ResourceUsage)第七十八页,共99页。预期性能指标测试用例需求来源:产品设计前的预期参数项目对客户保证的性能指数用户并发性能测试核心模块的测试可以理解为“单元性能测试”针对核心功能模块进行并发用户测试,测试系统是否能够稳定运行主要是针对易独立并发、或者使用频繁的模块第七十九页,共99页。第八十页,共99页。第八十一页,共99页。第八十二页,共99页。通用指标ProcessorTime:指服务器CPU占用率,一般平均达到70%时,服务就接近饱和;MemoryAvailableMbyte:可用内存数,如果测试时发现内存有变化情况也要注意,如果是内存泄露则比较严重;PhysicsdiskTime:物理磁盘读写时间情况;第八十三页,共99页。统计调查结果事务响应时间不超过4秒,可以接受事务响应时间大于4秒小于9秒,30%用户会撤消事务事务响应时间大于8秒小于10秒,60%用户会撤消事务事务响应时间超过10秒,超过90%用户会撤消事务第八十四页,共99页。性能测试的分类性能测试类型包括:负载测试:确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。强度测试:强度测试是一种性能测试,在系统资源特别低的情况下软件系统运行情况。容量测试:确定系统可处理同时在线的最大用户数(在用户可接收的范围内)。压力测试:通过确定一个系

温馨提示

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

评论

0/150

提交评论