书签 分享 收藏 举报 版权申诉 / 99
上传文档赚钱

类型监理工作-软件监理测试工作-参考概要课件.ppt

  • 上传人(卖家):晟晟文业
  • 文档编号:5166367
  • 上传时间:2023-02-15
  • 格式:PPT
  • 页数:99
  • 大小:1.50MB
  • 【下载声明】
    1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
    2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
    3. 本页资料《监理工作-软件监理测试工作-参考概要课件.ppt》由用户(晟晟文业)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
    4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
    5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
    配套讲稿:

    如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。

    特殊限制:

    部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。

    关 键  词:
    监理 工作 软件 测试 参考 概要 课件
    资源描述:

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

    2、测试的生命周期n 在软件开发生命周期中,软件是通过迭代来不断加以完善的。在这种环境中,对于每个作为测试目标的工作版本,测试的生命周期还都必须具有一种迭代方法。n 计划:标志测试条件(确定测试什么)和测试的优先级n 设计:设计测试用例(确定怎么测试)n 开发:测试开发(设计脚本、数据等)n 执行:执行测试用例n 评估:将测试结果与期望结果进行比较软件测试的原则和标准n 软件测试的原则软件测试的原则 原则一:穷尽测试是不可能的,不充分的测试是愚蠢的,过度的测试也是一种罪孽 原则二:测试工作具有创造性,但很困难 原则三:测试旨在防止错误的发生 原则四:测试是有风险的 原则五:测试要有计划性 原则六:

    3、测试要有独立性(测试部门、小组)测试的局限性n 程序测试可以表明缺陷的存在,但决不能证明没有缺陷。n 测试必须用需求作为参考点。如果需求是错误的或不完全的,就会产生假的测试。n 基于实现的测试并不能发现遗漏,正如缺少的代码不能被测试一样。n 从来都不能确信一个正在测试的系统是正确的,测试设计中的错误,可能产生假的测试结果。n 得到一个预测是困难的,有的甚至是不可能的常用词汇n 错误(Error):Bugn 缺陷(Fault):是错误的表现n 失效(failure):当缺陷执行时会发生失效n 事故(incident):系统在制定范围内执行所需功能时表现的无能n 测试脚本:一个用过程脚本语言编写的

    4、程序,该程序用来执行一个测试包n 测试包:测试实例的集合n 测试装置:由测试驱动器和其他支持测试执行的工具组成的系统。n 测试用例(Test Case):由输入数据和预期结果组成。输入数据:数据、文件或操作序列,预期结果:后果和实际输出黑盒测试n 黑盒测试(Blackbox Testing)又称功能测试、数据驱动测试或基于规格说明的测试,是一种从用户观点出发的测试。n 被测程序被当作一个黑盒,不考虑程序内部结构和内部特性,测试者只知道该程序输入和输出之间的关系或程序的功能,依靠能够反映这一关系和程序功能的需求规格说明书考虑确定测试用例和推断测试结果的正确性。n 软件的黑盒测试被用来证实软件功能

    5、的正确性和可操作性。白盒测试n 白盒测试(Whitebox Testing)又称结构测试、逻辑驱动测试或基于程序的测试。它依赖于对程序细节的严密检验,针对特定条件设计测试用例,对软件的逻辑路经进行测试。n 在程序的不同点检验“程序的状态”以判定其实际情况是否和预期的状态相一致。n 软件的白盒测试用来分析程序的内部结构。n 白盒测试要求对某些程序的结构特性做到一定程度的覆盖,或者说是“基于覆盖的测试”。最为常见的程序结构覆盖有:n 语句覆盖:它要求被测程序的每一可执行语句在测试中尽可能都检验过,这是最弱的逻辑覆盖准则;n 分支覆盖或判定覆盖:要求程序中所有判定的分支尽可能得到检验;n 条件覆盖:

    6、当判定式中含有多个条件时,要求每个条件的取值均得到检验;n 判定条件覆盖:同时考虑条件的组合值及判定结果的检验;n 路径覆盖:只考虑对程序路径的全面检验。回归测试n 目标:修改的或增加的部分是正确的 没有引起其他部分产生错误n 应用:增量开发版本控制软件维护n 测试和测试n 测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。n 测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。测试的分类n 静态分析n 功能测试n 用户界面测试n 性能测试 负载测试 强度测试 容量测试n 配置测试n 安装测试n 安全性测试n 兼容性测

    7、试测试的标准n GB/T16260-1996信息技术信息技术 软件产品评价软件产品评价 质量特性及其使用指南质量特性及其使用指南n GB/T17544-1998信息技术信息技术 软件包软件包 质量要求和测试质量要求和测试n GB/T8567-1988计算机软件产品开发文件编制指南计算机软件产品开发文件编制指南n GB/T9385-1988计算机软件需求说明编制指南计算机软件需求说明编制指南n GB/T9386-1988计算机软件测试文件编制规范计算机软件测试文件编制规范n GB/T11457-1995软件工程术语软件工程术语n GB/T13502-1992信息处理信息处理 程序构造及其表示的约

    8、定程序构造及其表示的约定n GB/T14085-1993信息处理系统信息处理系统 计算机系统配置图符号及约定计算机系统配置图符号及约定n GB/T14394-1993计算机软件可靠性和可维护性管理计算机软件可靠性和可维护性管理n GB/T15189-1994DOS中文信息处理系统接口规范中文信息处理系统接口规范n GB/T15532-1995计算机软件单元测试计算机软件单元测试n B/T15535-1995信息处理信息处理 单命中判定表规范单命中判定表规范n GB/T1526-1989信息处理信息处理 数据流程图、系统流程图、程序网络数据流程图、系统流程图、程序网络图和系统资源图的文件编制符号

    9、及约定图和系统资源图的文件编制符号及约定n GB/T16680-1996软件文档管理指南软件文档管理指南n GB/T8566-2001信息技术信息技术 软件生存期过程软件生存期过程n 测试相关模型测试相关模型需求分析系统设计详细设计编码单元测试集成测试系统测试验收测试时间程序员的理解程序员的理解=用户的理解用户的理解 详细程度V 模型(改良)评价n 优点优点l文档驱动文档驱动的开发模型。的开发模型。l改良后的模型很注重反馈和测试,其中改良后的模型很注重反馈和测试,其中V模型提出了测模型提出了测试驱动开发的概念。试驱动开发的概念。l在需求非常明确的前提下可以使用,也适用于有长期在需求非常明确的前

    10、提下可以使用,也适用于有长期专职开发人员的小型项目开发。专职开发人员的小型项目开发。n 不足:不足:l严格限定了开发的各阶段,缺乏迭代性。严格限定了开发的各阶段,缺乏迭代性。l缺乏对变化的支持。缺乏对变化的支持。原型法原型法Brooks 1975设计实现测试维护需求设计实现测试原型设计实现初始原型初始概念修改原型直至被接受完成发布原型最终产品目的是和用户一起开发并完善一个原型,从最清楚的需求部分开始。进化原型法进化原型法评价n 优点:优点:l需求驱动需求驱动的开发模型。的开发模型。l帮助理解需求。帮助理解需求。l增强和用户的交流,增加用户好感。增强和用户的交流,增加用户好感。n 不足:不足:l

    11、缺乏结构化的系统和严谨的开发流程,很难作缺乏结构化的系统和严谨的开发流程,很难作为一个项目进行管理。为一个项目进行管理。迭代1迭代2迭代3分析设计编码测试发布1分析设计编码测试发布2分析设计编码测试发布3迭代n分析设计编码测试最终发布.增量型(例增量型(例RUP)评价n 优点:优点:l开发过程分解为多个迭代过程,每个过程可以有自己的开发开发过程分解为多个迭代过程,每个过程可以有自己的开发模型。模型。l可以快速提交可用的系统,然后根据反馈实施下一个迭代。可以快速提交可用的系统,然后根据反馈实施下一个迭代。n 不足:不足:l是一个开发框架,对每个迭代的具体过程缺乏支持:是一个开发框架,对每个迭代的

    12、具体过程缺乏支持:n1)如果迭代太少,很容易会蜕变为)如果迭代太少,很容易会蜕变为Code-Fix模式,迭代太多模式,迭代太多则往往因文档驱动而导致测试和集成的复杂度和费用太大。则往往因文档驱动而导致测试和集成的复杂度和费用太大。n2)因而无法克服以往开发模型的不足。经常蜕变成)因而无法克服以往开发模型的不足。经常蜕变成Waterfall模型。模型。简单设计迭代计划测试驱动Pair开发持续集成重构1.N个个Iteration发布计划1.N个个Release小发布发布1.N个个TaskXP的增量过程失败通过时间单元测试 100%通过设计先先写写单元测试单元测试重构运行运行单元测试单元测试编程发现

    13、BUG集成先先写写功能测试功能测试User Story运行运行功能测试功能测试测试驱动开发n软件开发的测试过程软件开发的测试过程n 招投标及合同签订阶段招投标及合同签订阶段 在合同中应该明确功能测试的基础在合同中应该明确功能测试的基础需求规需求规格说明书格说明书,并明确性能测试的方法、其它需,并明确性能测试的方法、其它需测试的类型以及第三方测试等。测试的类型以及第三方测试等。在现在的投标书中,有在投标文件中提出验在现在的投标书中,有在投标文件中提出验证方法的现象,应引起注意。(证方法的现象,应引起注意。(P153 8.2)在监理规划中,应该对软件测试的监理过程在监理规划中,应该对软件测试的监理

    14、过程方式(旁站、抽查等)进行明确。方式(旁站、抽查等)进行明确。开发生命周期中的验证活动开发阶段验证活动需求需求.确定验证步骤确定验证步骤.对需求进行评审对需求进行评审.产生功能测试用例产生功能测试用例.确定需求一致性确定需求一致性需求阶段监理任务n 对测试计划以及测试用例的审核对测试计划以及测试用例的审核n 审核主体:测试计划(参阅审核主体:测试计划(参阅测试计划审查表测试计划审查表)n 审核注意事项:审核注意事项:时间时间 人员安排人员安排 测试环境:软、硬件、具体地点测试环境:软、硬件、具体地点 测试的依据和标准测试的依据和标准 测试方法及软件,测试的可行性测试方法及软件,测试的可行性

    15、执行和维护需求的可行性与可测性执行和维护需求的可行性与可测性 集成、验收测试的进入、结束条件集成、验收测试的进入、结束条件 验收需求对测试设计、用例、规程、经过的跟踪验收需求对测试设计、用例、规程、经过的跟踪 测试计划的编制需符合测试计划的编制需符合GB/T 9386标准标准 n 测试用例测试用例 审核功能用例是否完全覆盖审核功能用例是否完全覆盖n 注意软件性能、安装、配置测试的约定注意软件性能、安装、配置测试的约定开发阶段验证活动设计设计.确定设计信息是否足够确定设计信息是否足够.准备结构和功能的测试用例准备结构和功能的测试用例.确定设计的一致性确定设计的一致性设计阶段n 继续对功能性测试用

    16、例进行细化继续对功能性测试用例进行细化n 提交接口等测试方法提交接口等测试方法n 对单元测试的过程、方法进行确认,核实是否已覆对单元测试的过程、方法进行确认,核实是否已覆盖控制流和数据流盖控制流和数据流n 提交各模块单元、集成测试方案提交各模块单元、集成测试方案 算法和逻辑 模块接口 数据结构(全局和局部)边界条件 独立的路径 错误处理 人员,环境,工具开发阶段验证活动编码编码单元单元测试测试.为单元测试产生了完整的结构和功能测试的测试为单元测试产生了完整的结构和功能测试的测试用例用例 .进行了足够的单元测试进行了足够的单元测试 .主要进行白盒测试,辅助以黑盒测试主要进行白盒测试,辅助以黑盒测

    17、试 .对合理、不合理输入进行鉴别和响应对合理、不合理输入进行鉴别和响应 .在测试的过程中,需对所有的局部和全局数据在测试的过程中,需对所有的局部和全局数据结构、外部接口、程序代码的关键部分实施严格结构、外部接口、程序代码的关键部分实施严格的代码审查。的代码审查。.多个模块可以平行的独立进行单元测试多个模块可以平行的独立进行单元测试测试阶段和测试方法单元测试n 目的:分别完成每个单元的测试任务,以确保每个模块能正常工作。n 单元测试 单元测试在迭代的早期实施,侧重于核实软件的最小可测试元素。单元测试通常应用于实施模型中的构件,核实是否已覆盖控制流和数据流,以及构件是否可以按照预期工作。单元测试n

    18、 检验程序最小单位有无错误。检验程序最小单位有无错误。n 一般在编码之后,由开发人员完成。一般在编码之后,由开发人员完成。n 实施效果非常好,但是实施阻力比较大实施效果非常好,但是实施阻力比较大l“不可能出问题不可能出问题”l“小子,我的代码肯定没错小子,我的代码肯定没错”l“天,我这是怎么了,如此简单的错误天,我这是怎么了,如此简单的错误”l“以后绝对不可能了以后绝对不可能了”单元测试的进入条件n 完成单元模块编码完成单元模块编码n 代码编译无错误代码编译无错误n 开发单元纳入承建单位配置受控库开发单元纳入承建单位配置受控库单元测试的内容n 单元功能测试单元功能测试n 模块接口测试模块接口测

    19、试n 局部数据结构测试局部数据结构测试n 路径测试路径测试n 错误处理测试错误处理测试n 边界测试边界测试n 重要模块的性能测试重要模块的性能测试单元测试的成果n 单元测试报告单元测试报告n 测试记录,测试结果分析测试记录,测试结果分析n 软件问题报告单,软件修改报告单软件问题报告单,软件修改报告单n 经修改的代码经修改的代码n 回归测试记录和结果回归测试记录和结果单元测试过程n 驱动程序:用于模拟主程序的运行n 桩模块:用于模拟子程序的运行n 静态分析 对源代码的静态分析:主要分析代码中的类型、引用、参数传递,以及表达式等不用运行就能够发现的错误;另外还有一些容易出错的地方,如空指针赋值、下

    20、标越界等。还可以检查诸如命名规则等编程规范。此项测试在监理的过程中,一般可以通过代码巡查的过程来保证。集成测试n 又称为组装测试或者联合测试又称为组装测试或者联合测试n 在单元测试的基础上进行在单元测试的基础上进行n 将所有模块按概要设计、详细设计的要求进行将所有模块按概要设计、详细设计的要求进行组装。组装。n 在进行集成测试时,必须确定关键模块在进行集成测试时,必须确定关键模块(重要需重要需求,高层控制模块,复杂易错模块,明确性能求,高层控制模块,复杂易错模块,明确性能要求模块要求模块),对关键模块及早进行测试。,对关键模块及早进行测试。n 在做回归测试时,也应集中测试关键模块。在做回归测试

    21、时,也应集中测试关键模块。n 集成测试的目的:在模块组装后查找模块间接集成测试的目的:在模块组装后查找模块间接口的错误口的错误为什么进行集成测试?为什么进行集成测试?一个模块可能对另一个模块产生不利的影响 将子功能合成时不一定产生所期望的主功能 独立可接受的误差,在组装后可能会超过可接受的误差限度 可能会发现单元测试中未发现的接口方面的错误 在单元测试中无法发现时序问题(实时系统)在单元测试中无法发现资源竞争问题集成测试的方法:n 非增式测试:采用一步到位的方法来构造测试:对所有模块进行个别的单元测试后,按程序结构图将各模块联接起来,把联接后的程序当作一个整体进行测试。n 增式测试:把下一个要

    22、测试的模块同已经测试好的模块结合起来进行测试,一次增加一个测试的模块。自顶向下增式测试自顶向下增式测试n 集成步骤:主控模块作为测试驱动,所有与主控模块直接相连的模块作为桩模块;根据集成的方式(深度或广度),每次用一个替换从属的桩模块;在每个模块被集成时,都必须已经进行了单元测试;进行回归测试以确定集成新模块后没有引入错误上述过程从第2步重复进行,直到整个系统结构被集成完成。自底向上增式测试自底向上增式测试工作程序:组装从最底层的模块开始,组合成一个构件,用以完成指定的软件子功能 编制驱动程序,协调测试用例的输入与输出 测试集成后的构件 按程序结构向上组装测试后的构件,同时除掉驱动程序n 集成

    23、测试为一种正式测试过程集成测试为一种正式测试过程n 必须与单元测试协调进行必须与单元测试协调进行n 必须提交完整的测试计划及方案必须提交完整的测试计划及方案采用何种系统组装方法采用何种系统组装方法测试中各模块的连接顺序测试中各模块的连接顺序模块代码编制和测试进度是否与集成测试的顺序一致模块代码编制和测试进度是否与集成测试的顺序一致测试过程中是否需要专门的硬件设备测试过程中是否需要专门的硬件设备计划中应包括:各模块的编制、测试计划表,标明各模计划中应包括:各模块的编制、测试计划表,标明各模块单元测试完成、首次集成测试、集成测试全部完成的块单元测试完成、首次集成测试、集成测试全部完成的日期,需要的

    24、测试用例,期望的测试结果;以及其它人日期,需要的测试用例,期望的测试结果;以及其它人员安排等员安排等 集成测试结束条件n 成功的执行了测试计划中的所有集成测试成功的执行了测试计划中的所有集成测试n 修正了测试中的错误修正了测试中的错误n 修正通过了回归测试修正通过了回归测试n 测试结果通过评审测试结果通过评审集成测试的结果n 集成测试报告集成测试报告n 软件使用说明软件使用说明n 软件问题报告单和软件修改报告单软件问题报告单和软件修改报告单n 修改的源代码修改的源代码监理工作n 集成测试和单元测试一般情况下都是结合执行的。集成测试和单元测试一般情况下都是结合执行的。在进行单元测试和集成测试时,

    25、对测试方案可以不详细要求,在进行单元测试和集成测试时,对测试方案可以不详细要求,监理一般情况下不对单元测试进行全程跟踪,在实际过程中,监理一般情况下不对单元测试进行全程跟踪,在实际过程中,单元测试和集成测试都由承建单位自行实施。单元测试和集成测试都由承建单位自行实施。在必要情况下可以要求承建单位按天提交单元测试报告可以在必要情况下可以要求承建单位按天提交单元测试报告可以对单元测试结果进行抽查对单元测试结果进行抽查可分析测试报告,对错误点在系统测试阶段加以注意,同时,可分析测试报告,对错误点在系统测试阶段加以注意,同时,注意每天测试的缺陷的收敛情况。注意每天测试的缺陷的收敛情况。部分情况下,单元

    26、测试的时候也可以要求做核心单元的性能部分情况下,单元测试的时候也可以要求做核心单元的性能测试。测试。在进行系统及验收测试前,必须要求承建单位提交集成测试在进行系统及验收测试前,必须要求承建单位提交集成测试结果,对集成测试可以抽查。结果,对集成测试可以抽查。测试工具的选择n Junitn PurifyPlusn Rational Robot等等PurifyPlusnPurifyPluslPurifylPureCoveragelQuantifyPurifyPlusn IBM Rational的测试工具包,主要包括:的测试工具包,主要包括:l内存和资源检查工具:内存和资源检查工具:Purifyl性能

    27、瓶颈检查工具:性能瓶颈检查工具:Quantifyl代码覆盖测试工具:代码覆盖测试工具:PureCoveragePurifyn 查找问题查找问题l内存错误内存错误l内存泄露内存泄露n 支持语言支持语言lC,C+lJavalAdan 支持平台支持平台lWindowslUnixnLinuxnSolarisnHP-Unixn 处理类型处理类型lWindows DLLlMFC DLLlVC,VB构件构件lIE,Netscape,Office构构件件lExcel,Word plug-inl基于基于COM的的OLE或或ActiveX构件构件运行信息窗口相同的错误n 缺省状态下,缺省状态下,Purify对同一

    28、类错误统计次数对同一类错误统计次数UMR发生了57次代码覆盖情况点击可排序双击打开代码统计行代码调用情况行调用次数比较运行数据n Run Control-Compare Runs分析内存差异内存差异越大,线条越粗Call Graph概览,可以调节显示范围可以调节显示范围PureCoveragen 功能功能l代码覆盖统计代码覆盖统计n 支持语言支持语言lC,C+lJavalVBl.NETn 支持平台支持平台lWindowslUnixnLinuxnSolarisnHP-Unixn 处理类型处理类型lWindows DLLlMFC DLLlVC,VB构件构件lIE,Netscape,Office构构

    29、件件lExcel,Word plug-inl基于基于COM的的OLE或或ActiveX构件构件lJava applet,class,jarHello的运行选择No函数覆盖率50%行覆盖率31.25%代码行覆盖情况运行的代码未运行的代码Junit的运行结果开发阶段验证活动测试测试.测试应用系统,着重在功能、性能上测试应用系统,着重在功能、性能上.验收测试方案的审核验收测试方案的审核.测试用例的审核测试用例的审核.主要进行系统测试、验收测试主要进行系统测试、验收测试进入条件n 所有的测试的硬件安装、配置和运行已成功通所有的测试的硬件安装、配置和运行已成功通过测试过测试n 所有需要的软件已成功安装、

    30、配置并测试通过所有需要的软件已成功安装、配置并测试通过n 所有测试阶段文档已完成并通过评审所有测试阶段文档已完成并通过评审n 所有上一阶段的测试工作已完成所有上一阶段的测试工作已完成n 单元测试通过单元测试通过n 预测试通过预测试通过监理主要工作n 对测试方案的审核对测试方案的审核n 对测试用例的审核对测试用例的审核n 对测试结果进行抽查对测试结果进行抽查n 最好不旁站功能测试过程最好不旁站功能测试过程n 性能测试过程可以旁站,但要求承建单位应提性能测试过程可以旁站,但要求承建单位应提前进行准备,确保测试过程的顺利前进行准备,确保测试过程的顺利测试方案审核n 对测试计划的细化对测试计划的细化n

    31、 可操作性可操作性 时间时间 人员安排人员安排 测试环境:软、硬件、具体地点测试环境:软、硬件、具体地点 测试的需求覆盖率测试的需求覆盖率 测试的依据和标准,预期的结果测试的依据和标准,预期的结果 测试方法及软件测试方法及软件 集成、验收测试的进入、结束条件集成、验收测试的进入、结束条件 验收需求对测试设计、用例、规程的跟踪验收需求对测试设计、用例、规程的跟踪 测试计划的编制需符合测试计划的编制需符合GB/T 9386标准标准测试用例审核n 按需求的场景、工作流按需求的场景、工作流 基本事件流,备选流基本事件流,备选流1,备选流,备选流2 对每个事件流准备测试用例对每个事件流准备测试用例 测试

    32、的需求覆盖性测试的需求覆盖性n 测试用例:测试用例:标志符标志符 要测试的特性,测试项要测试的特性,测试项 测试方法:输入、输出说明测试方法:输入、输出说明 测试用例信息:环境要求、其它特殊要求测试用例信息:环境要求、其它特殊要求 用例之间的依赖型用例之间的依赖型 通过通过/失败的规则失败的规则系统测试 -确认测试功能测试 容量测试强度测试 安全测试可使用性测试 性能测试资源使用测试 配置测试兼容性测试 安装测试可靠性测试 回归测试 测试 测试n 用户界面测试用户界面测试 符合标准和规范Mac:Macintosh Human Interface GuidelineWindows:Microso

    33、ft Windows User Experience尽量减少用户的工作 直观性 一致性 灵活性 舒适性 正确性 实用性n 功能测试 验证软件是否提供了所期待的服务。包括:“主要”方案-所有的输入是合法的。“辅助”方案-一些或所有的输入是不合法的n 性能测试 响应时间 并发性 吞吐量 处理精度n 强度测试:检查在系统运行环境不正常乃至发生故障的情况下,系统可以运行到何种程度的测试.把输入数据速率提高一个数量级,确定输入功能将如何响应。设计需要占用最大存储量或其它资源,会对磁盘常驻内存的数据过度访问的测试用例进行测试。资源少的情况下发现可能的错误:低内存,磁盘空间不足 共享资源竞争的情况下发现可能

    34、的错误 系统资源 数据库加锁 网络带宽n 容量测试 使软件经受大数据量的考验,以确定达到限制时是否引发软件失败,容量测试是要检验系统的能力最高能达到什么程度。例如,对于编译程序,让它处理特别长的源程序;对于操作系统,让它的作业队列“满员”;对于信息检索系统,让它使用频率达到最大。在使系统的全部资源达到“满负荷”的情形下,测试系统的承受能力。安全性测试n 目标安全性的缺陷很难被发现。大多数的情况下组织能够防止一般性的破坏者。n 例子定义了被保护的资源,权限进行了控制,日志文件和审查追踪是可用的。n 配置测试 检查计算机系统内各个设备或各种资源之间的相互联结和功能分配中的错误。软件配置 硬件配置n

    35、 安装测试 是否能正确安装?初次安装 升级安装 完全安装 定制安装 安装后,操作是否正确?安装测试安装测试n 安装测试的目的不是找软件错误,而是找安装错误。n 安装软件系统时,会有多种选择。要分配和装入文件与程序库布置适用的硬件配置进行程序的联结。n 安装测试是在系统安装之后进行测试。它要检验:用户选择的一套任选方案是否相容;系统的每一部分是否都齐全;所有文件是否都已产生并确有所需要的内容;硬件的配置是否合理。n 功能测试性能测试的方法、软件功能测试性能测试的方法、软件功能测试常使用手动方式完成功能测试常使用手动方式完成部分情况下可使用自动化测试工具部分情况下可使用自动化测试工具测试的主要内容

    36、包括:边界值分析:范围的边界内,最小值,稍高于最小值,正常值,稍低于最大值,最大值 健壮性测试:是边界值分析的一种简单扩展,除了使用五个边界值分析取值,还要通过采用一个略超过最大值的取值,以及一个略小于最小值的取值。最坏情况测试:会产生5n个测试用例 特殊值测试性能测试性能测试中的基本概念 响应时间(Response Time)点击数(Hits)页面请求(Page view)吞吐量(Throughout)并发用户数*(HTML文档大小)/请求时间 并发用户(Concurrency User)资源利用率(Resource Usage)预期性能指标测试用例n 需求来源:-产品设计前的预期参数-项目

    37、对客户保证的性能指数n 用户并发性能测试 核心模块的测试 可以理解为“单元性能测试”针对核心功能模块进行并发用户测试,测试系统是否能够稳定运行主要是针对易独立并发、或者使用频繁的模块通用指标 ProcessorTime:指服务器CPU占用率,一般平均达到70%时,服务就接近饱和;Memory Available Mbyte:可用内存数,如果测试时发现内存有变化情况也要注意,如果是内存泄露则比较严重;Physicsdisk Time:物理磁盘读写时间情况;统计调查结果 事务响应时间不超过4秒,可以接受 事务响应时间大于4秒小于9秒,30%用户会撤消事务 事务响应时间大于8秒小于10秒,60%用户

    38、会撤消事务 事务响应时间超过10秒,超过90%用户会撤消事务性能测试的分类性能测试的分类性能测试类型包括:负载测试:确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。强度测试:强度测试是一种性能测试,在系统资源特别低的情况下软件系统运行情况。容量测试:确定系统可处理同时在线的最大用户数(在用户可接收的范围内)。压力测试:通过确定一个系统的瓶颈或者最大使用极限的测试。疲劳强度测试:系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数,持续执行一段时间业务,通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。大数据量测试 独立

    39、的数据量测试:针对某些系统存储、传输、统计、查询等业务进行大数据量测试 综合数据量测试:和压力性能测试、负载性能测试、疲劳性能测试相结合的综合测试方案n 疲劳强度与大数据量测试 疲劳测试目的:确定系统处理最大工作量的性能。内容:在系统稳定运行下,模拟最大或者恰当的用户数目、长时间运行系统,通过综合分析执行指标和资源监控来分析系统的稳定性。n 大数据量测试分为两种:针对某些系统存储、传输、统计查询等业务进行大数据量的测试,可以通过工具完成;数据库性能测试,可以编写程序和测试工具结合实现n 网络性能测试 主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。测试用户数目与网络带

    40、宽的关系。用例的编写应和用户并发测试结合起来:例如在原有的基础上采用工具来调整网络设置。n 服务器性能测试 测试用例不必独立编写,也可以根据实际需要编写少量的测试用例。系统集成部会完成一部分工作。建议:这部分和前两部分的用例编写结合起来,在用户并发性能测试、疲劳强度与大数据量性能测试时完成对服务器性能的监控。性能测试脚本设计性能测试脚本设计n 准备包含适量数据的测试数据库 书写组成负载的系统事务脚本 书写需要度量响应时间的系统事务脚本 工作量定义的开发(即负载概况的执行)准备自动脚本参数化所需要的测试数据分析与报告测试结果n 响应时间 测量值 最小响应时间 最大响应时间 平均响应时间 95%的

    41、响应时间 响应时间需求与测试结果的比较n 系统的吞吐量 实际事务率和吞吐量 判断与模拟的负载概况是否相一致n 通过图表方式列出响应时间与负载的关系 随着负载的增加性能降低的频率 在可接受的响应时间内能达到的最大吞吐量n 某段时间内资源的使用情况 将资源使用与当时应用负载情况相关联,有助于寻找系统框架中的瓶颈3.测试工具测试驱动工具的功能测试驱动工具的功能n 基本功能 建立网络连接 读取标准输入数据、准备命令行数据或准备传播的消息 承认来自远程服务器的响应 可以配置发送信息的频率n 复杂功能 记录提交到服务器的事务的响应时间 在需要建立成千上百个虚拟客户端的时候,可以复制自己,在不同的实例间同步

    展开阅读全文
    提示  163文库所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
    关于本文
    本文标题:监理工作-软件监理测试工作-参考概要课件.ppt
    链接地址:https://www.163wenku.com/p-5166367.html

    Copyright@ 2017-2037 Www.163WenKu.Com  网站版权所有  |  资源地图   
    IPC备案号:蜀ICP备2021032737号  | 川公网安备 51099002000191号


    侵权投诉QQ:3464097650  资料上传QQ:3464097650
       


    【声明】本站为“文档C2C交易模式”,即用户上传的文档直接卖给(下载)用户,本站只是网络空间服务平台,本站所有原创文档下载所得归上传人所有,如您发现上传作品侵犯了您的版权,请立刻联系我们并提供证据,我们将在3个工作日内予以改正。

    163文库