软件测试大学教程 9 系统测试-1

上传人:飞*** 文档编号:54362571 上传时间:2018-09-11 格式:PPT 页数:41 大小:525.50KB
返回 下载 相关 举报
软件测试大学教程 9 系统测试-1_第1页
第1页 / 共41页
软件测试大学教程 9 系统测试-1_第2页
第2页 / 共41页
软件测试大学教程 9 系统测试-1_第3页
第3页 / 共41页
软件测试大学教程 9 系统测试-1_第4页
第4页 / 共41页
软件测试大学教程 9 系统测试-1_第5页
第5页 / 共41页
点击查看更多>>
资源描述

《软件测试大学教程 9 系统测试-1》由会员分享,可在线阅读,更多相关《软件测试大学教程 9 系统测试-1(41页珍藏版)》请在金锄头文库上搜索。

1、1/41,第9讲 系统测试 系统测试需求类型与测试类型,2/41,什么是系统测试,系统测试是通过与系统的需求规格作比较,发现软件与系统需求规格不相符合或与之矛盾的地方 将被测软件,作为整个基于计算机系统的一个元素 与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来 在实际运行(使用)环境下,对计算机系统进行的测试 系统测试的目的: 为了发现缺陷并度量产品质量,按照系统的功能和性能需求进行的测试 同时检验系统的文档等各种是否完整、有效 一般使用黑盒测试技术 对于模块之间交互性比较强的软件,还会有单独的集成测试,用来发现模块接口之间的错误 一般由独立的测试人员完成,3/41,系统测

2、试过程,4/41,5/41,系统测试需求获取,系统测试需求所确定的是测试的内容,即测试的具体对象 系统测试需求主要来源于需求工件集 它可能是一个需求规格说明书,或是由前景、用例、用例模型、词汇表、补充说明组成的一个集合 测试需求分析的几条规则 测试需求必须是可观测、可测评的行为 在每个用例或系统的补充需求与测试需求之间不存在一对一的关系 用例通常具有多个测试需求 在需求规格说明书中每一个功能描述将派生一个或多个测试需求 性能描述、安全性描述等也将派生出一个或多个测试需求,6/41,测试需求类型,功能性测试需求 功能性测试需求来自于测试对象的功能性说明 每个用例至少会派生一个测试需求 对于每个用

3、例事件流,测试需求的详细列表至少会包括一个测试需求 对于需求规格说明书中的功能描述,将至少派生一个测试需求,7/41,测试需求类型(续),性能测试需求 性能测试需求来自于测试对象的指定性能行为 性能通常被描述为对响应时间和资源使用率的某种评测 性能需要在各种条件下进行评测,这些条件包括: 不同的工作量和/或系统条件 不同的用例/功能 不同的配置,8/41,测试需求类型(续),性能测试需求(续) 性能需求在补充说明或需求规格说明书中的性能描述部分中说明,如: 时间语句,如响应时间或定时情况 指出在规定时间内必须出现的事件数或用例数的语句 将某一项性能的行为与另一项性能的行为进行比较的语句 将某一

4、配置下的应用程序行为与另一配置下的应用程序行为进行比较的语句 一段时间内的操作可靠性(平均故障时间或 MTTF) 配置或约束 应该为规格说明中反映以上信息的每个语句生成至少一个测试需求,9/41,测试需求类型(续),性能测试需求(续) 性能需要举例: 列出有各种性能要求的功能,如有并发要求的功能及相应的并发要求、有响应时间要求的功能 数据库容量,或指定时间的业务处理量 系统用户容量的需求 如果有机器配置上的要求,则说明相应的机器配置要求 网络环境,如1MADSL或者512K拨号上网环境 系统运行时间,如7x24小时不间断运行,或者可连续运行一周,10/41,测试需求类型(续),性能测试需求(续

5、) 在性能测试前期,重点需要了解以下内容 系统有哪一些重要的功能模块 大约的用户是多少 用户的行为是如何分布的 每个模块的使用频度 大约的数据量 使用什么样的硬件 系统稳定性的要求等等,11/41,测试需求类型(续),其它测试需求 配置测试 安全性测试 容量测试 强度测试 故障恢复测试 负载测试等 可以从非功能性需求中发现与其对应的描述 每一个描述信息可以生成至少一个测试需求,12/41,系统测试策略,测试策略用于说明某项特定测试工作的一般方法和目标 系统测试策略主要针对系统测试需求确定测试类型及如何实施测试的方法和技术 一个好的测试策略应该包括下列内容: 要实施的测试类型和测试的目标 采用的

6、技术 用于评估测试结果和测试是否完成的标准 对测试策略所述的测试工作存在影响的特殊事项,13/41,系统测试类型和目标,确定系统测试策略首先应清楚地说明所实施系统测试的类型和测试的目标 清楚地说明这些信息有助于尽量避免混淆和误解 尤其是由于有些类型测试看起来非常类似,如强度测试和容量测试 测试目标应该表明执行测试的原因 系统测试的测试类型一般包括: 功能测试、性能测试、负载测试、强度测试、容量测试、安全性测试、配置测试、故障恢复测试、安装测试、文档测试、用户界面测试等 其中,功能测试、配置测试、安装测试等在一般情况下是必需的 而其它的测试类型则需要根据软件项目的具体要求进行裁剪,14/41,系

7、统测试环境,软件运行存在三种环境:开发环境、测试环境、用户环境 开发环境往往与用户环境有所差别 一个规划良好的测试环境总很接近于用户环境,但也要兼顾开发环境 测试环境在测试计划和测试用例中事先定义和规划,15/41,系统测试环境(续),建立系统测试环境 确定硬件环境和软件环境 硬件环境指测试必需的服务器、客户端、网络连接设备,以及打印机/扫描仪等辅助硬件设备所构成的环境 软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境 测试环境规划 分析用户环境中哪些配置可能对软件有所影响,在此基础上建立测试环境,16/41,系统测试环境(续),建立系统测试环境(续) 建立测试环境需要考虑

8、计算机平台、操作系统、浏览器、软件支持平台、外围设备、网络环境、数据环境、其他专用环境 建立测试环境的步骤 安装应用程序 安装和开发测试工具 设置专用文件 包括将这些文件与测试所需的数据相对应 建立与应用程序通信的实用程序 配备适当的硬件以及必要的设备,17/41,系统测试的常见内容,1、功能测试 目标 对产品的功能进行测试 检验是否实现 是否正确实现 方法 覆盖产品的功能 工具 回归测试时候可以使用工具,18/41,系统测试的常见内容(续),2、性能测试 目标 对产品的性能进行测试 检验性能是否达标 性能是否能够保持 方法 覆盖系统的性能需求,一般和负载测试结合使用 工具 在需要大访问量时候

9、尤其需要使用工具,19/41,系统测试的常见内容(续),3、负载测试 目标 人为设置高负载(大数据量、大访问量) 检查系统是否发生功能或者性能上的问题 方法 人为生成大数据量,并利用工具模拟频繁并发访问 工具 一般需要使用工具,20/41,系统测试的常见内容(续),4、压力测试 目标 人为设置,使系统资源紧缺 检查系统是否发生功能或者性能上的问题 方法 人为减少可用的系统资源 包括:内存、硬盘、网络、CPU占用、数据库反应时间 工具 一般需要使用工具,21/41,系统测试的常见内容(续),5、疲劳测试 目标 在一段时间内(经验上一般是连续72小时)保持系统功能的频繁使用 检查系统是否发生功能或

10、者性能上的问题 方法 人为设置不同功能的连续重复操作 工具 一般需要使用工具,22/41,系统测试的常见内容(续),6、易用性测试 目标 检查系统界面和功能是否容易学习 使用方式是否规范一致 是否会误导用户或者使用模糊的信息 方法 一般与功能测试结合使用 工具 可采用用户操作、观察(录像)、反馈并评估的方式,23/41,系统测试的常见内容(续),7、安装测试 目标: 检查系统安装是否能够安装所有需要的文件/数据并进行必要的系统设置 检查系统安装是否会破坏其他文件或配置 检查系统安装是否可以中止并恢复现场 检查系统是否能够正确卸载并恢复现场 检查安装和卸载过程的用户提示和功能是否出现错误 有时候

11、将安装测试作为功能测试的一部分,24/41,系统测试的常见内容(续),8、配置测试 目标 设置不同的硬件配置,不同的操作系统和应用软件环境 检查系统是否发生功能或者性能上的问题 方法 一般需要建立测试实验室 IE4.0测试实验室建立花费$200万,25/41,系统测试的常见内容(续),9、文档测试 目标 检查系统的文档是否齐全 检查是否有多余文档或者死文档 检查文档内容是否正确/规范/一致等, 方法 一般由单独的一组测试人员实施,26/41,系统测试的常见内容(续),10、安全测试(包括病毒、加密、权限) 目标 检查系统是否有病毒 检查系统是否正确加密 检查系统在非授权的内部或外部用户访问或故

12、意破坏时候是否出现错误,27/41,系统测试的常见内容(续),11、恢复测试 目标 人为使系统发生灾难(系统崩溃、硬件损坏、病毒入侵等) 检查系统是否能恢复被破坏的环境和数据,28/41,系统测试的常见内容(续),12、回归测试 定义: 回归测试是一种选择性重新测试 目的是检测系统或系统组成部分在修改期间产生的缺陷 用于验证已进行的修改并未引起不希望的有害效果 或确认修改后的系统或系统组成部分仍满足规定的要求 目标: 检查系统变更之后是否引入新的错误或者旧的错误重新出现,尤其是在每次Biuld之后和稳定期测试的时候 工具: 一般使用工具(特别是自动化测试工具) 一般依赖于测试用例库和缺陷报告库

13、,29/41,系统测试的常见内容(续),13、健全测试 目标 检查系统的功能和性能是否基本可以正常使用 来确定是否可以继续进行系统测试的其他内容 方法 正常安装 并使用正常情况下的测试用例对主要功能进行测试 同时检查系统文档是否齐全,30/41,系统测试的常见内容(续),14、交付测试 目标 关闭所有缺陷报告 确保系统达到预期的交付标准 方法 一般需要结合回归测试,并谨慎处理新出现的Bug 交付测试也称为稳定期测试 有时候与系统测试独立划分,31/41,系统测试的常见内容(续),15、演练测试 目标 在交付给用户之前,利用相似的用户环境进行测试 例如:奥运会MIS系统在2008年前用于其他比赛

14、,32/41,系统测试的常见内容(续),16、背靠背测试 目标 设置一组以上的测试团队,在互相不进行沟通的情况下独立进行相同的测试项目 用来评估测试团队的效果并发现更多的错误 开始用于测试外包,现在也用于内部测试,33/41,系统测试的常见内容(续),17、度量测试 目标 在系统中人为地放入错误(播种),并根据被发现的比例来确定系统中遗留的错误数量 开始用于测试外包,现在也用于内部测试,34/41,系统测试的常见内容(续),18、比较测试 目标 与竞争产品及本产品的旧版本测试同样的内容 确定系统的优势和劣势 严格地说,比较测试属于系统测评的内容 BenchMarking是一种特殊的比较测试,3

15、5/41,系统测试的常见内容(续),前述18种测试内容并不是都要进行的 制定测试策略和测试计划的时候要有不同的侧重点 与测试目标、测试资源、软件系统特点和业务环境有关 前述18种测试最好由独立(第三方)进行测试 进行独立测试的目的 是进一步加强软件质量保证工作 提高软件的质量 对软件产品进行客观评价 进行第三方独立测试通常有以下优点: 1)发挥专业技术优势 2)发挥独立性优势 3)进一步促进承办方的工作,36/41,测试员的效率,测试员的平均效率 平均每个工作日发现3-5个Bug 平均每修正3个Bug,会引进1个新的Bug 平均75%的Bug会在单元测试阶段解决掉 平均20%的Bug会在集成测

16、试和系统测试阶段解决掉 平均5%的Bug会被交付给用户 普通大型民用软件平均错误率5个/10,000LOC 电信/银行/操作系统等软件平均错误率5个/100,000LOC,37/41,测试团队,测试团队一般4-5人 否则应该细分为测试组 测试经理/测试组长 制定测试计划和测试方案 分配测试任务并检查测试进度 代表测试团队与开发、产品、用户沟通 实际测试 测试员 设计测试用例 执行测试用例并填写缺陷报告 检查缺陷处理结果,38/41,测试与开发的比例,与产品大小、复杂度、质量要求相关 目前国内比例平均为1:6 2000年: 全球软件业52000人 利润$300亿 开发人员为10000,测试人员为15000 测试费用占研发费用的60% Exchange2000 程序经理25人;开发人员140人;测试人员350人 Windows2000:$50亿 程序经理250人;开发人员1700人;测试人员3200人 IE4.0 开发时间6个月,测试时间8个月,39/41,系统测试的客观要求,系统测试需要以智力为核心、以系统为框架来实施 智力 逻辑性、灵活性和技巧性 系统 组织性、计划性和流程性,

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 行业资料 > 其它行业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号