资源预览内容
第1页 / 共89页
第2页 / 共89页
第3页 / 共89页
第4页 / 共89页
第5页 / 共89页
第6页 / 共89页
第7页 / 共89页
第8页 / 共89页
第9页 / 共89页
第10页 / 共89页
亲,该文档总共89页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
主要内容: 软件测试基础 黑盒测试方法 白盒测试方法 软件缺陷管理 2 测试概要 3 软件测试基本流程 1)项目规划阶段:负责从单元测试到系 统测试的整个测试阶段的监控。 2)需求分析阶段:确定测试需求分析、 系统测试计划的制定、评审后的管理。 其中,测试需求分析是对产品生命周期 中测试所需求的资源、配置、及评审; 系统测试计划是依据软件的需求规格说 明书,设计测试用例与测试的实施等。 3)概要设计与详细设计阶段:确保单元 测试、集成测试和系统测试计划完成。 4)编码阶段:该阶段主要由开发人员自 己负责部分的代码测试。在较在的项目 中,将由专人进行编码阶段的测试任务。 5)测试阶段:实施单元、集成、系统、 验收测试,并提交相应的测试报告。 4 软件测试模型 1/4 V模型 强调了在整个软件项目开发中需要经历的若干个测试 级别,并与每一个开发级别对应;忽略了测试的对象 不应该仅仅包括程序,没有明确指出对需求、设计的 测试 5 软件测试模型 2/4 W模型 补充了V模型中忽略的内容,强调了测试计划等工作的先 行和对系统需求和系统设计的测试;与V模型相同,没有 对软件测试的流程进行说明 6 软件测试模型 3/4 H模型 强调测试是独立的,只要测试准备完成,就可以执行测试 7 软件测试模型 4/4 X模型 8 软件测试模型小结 V模型 是软件开发瀑布模型的变种,主要反映测试活动与分析和设计的关系;局 限性:把测试作为编码之后的最后一个活动,需求分析等前期产生的错误 直到后期的验收测试才能发现 W模型 在V模型的基础上,增加千开发阶段的同步测试,形成W模型;测试与开发 同步进行,有利用尽早的发现问题 局限性:仍把开发活动看成是从需求开始到编码结束的串行活动,只有上 一阶段完成后,才可以开始下一阶段的活动,不能支持迭代,自发性以及 变更调整 H模型 在H模型中,软件测试过程活动完全独立,贯穿于整个产品的周期,与其他 流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到 测试执行阶段;软件测试可以进行尽早的进行;软件测试可以根据被测物 的不同而分层次进行 X模型: X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的 编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。 9 软件测试一般步骤 1/2 1、获取需求、功能设计、详细设计规格和其它必须文档 2、获取预算和时间安排需求 3、确定项目相关人员和他们的责任,汇报需求,必须的标准和过程(如 版本过 程、变更过程等) 4、确认应用高风险的部分,设定优先级,确定测试的范围和限制 5、确定测试的方法单元测试、集成测试、功能测试、负荷测试、可 用性测 试等 6、确定环境需求(软件/硬件/通信等) 7、确定测试用具环境(记录/回放工具、覆盖率分析器、测试跟踪、问 题跟踪等 等) 8、确定测试输入需求 9、确定任务,任务责任和相应的工作量 10、设定时间安排估计、时间表、里程碑等 10 软件测试一般步骤 2/2 11、确定输入的等价类、边界值分析、错误类 12、准备测试计划文档和需要的评审 13、写测试用例 14、对测试用例进行必须的评审 15、准备测试环境和测试用具,获取需要的用户手册/参考文 档/配置指导/安装 指导,建立跟踪过程,日志和存档过程,获取测试数据 16、获取和安装软件版本 17、执行测试 18、评价和汇报测试结果 19、跟踪问题和修改 20、如果需要进行再测试 21、在整个生命周期内维护和修改测试计划、测试用例、测 试环境和测试用具 11 测试阶段 单元测试 开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确 冒烟测试 在每日构建完成后,对系统的基本功能进行简单的测试 集成测试 将所有模块按照概要设计说明书和详细设计说明书的要求进行组装 确认测试 确认测试又称有效性测试。在模拟的环境下,运用黑盒测试的方法,验证被测软件是 否满足需求规格说明书列出的需求 系统测试 与硬件、网络、外设、支撑软件、数据以及人员结合在一起,在实际或模拟环境下, 对计算机系统进行测试 验收测试 以用户为主的对核心业务流程进行的测试 回归测试 软件维护阶段对软件修改后进行的测试 12 测试方法 黑盒测试黑盒测试 - 也称功能测试或数据驱动测试,它是在已知 产品所应具有的功能,通过测试来检测每个功能是否都 能正常使用,主要有等价类划分、边值分析、因果图、 错误推测等测试方法。 白盒测试白盒测试 - 也称结构测试或逻辑驱动测试,它是知道产 品内部工作过程,可通过测试来检测产品内部动作是否 按照规格说明书的规定正常进行,按照程序内部的结构 测试程序,检验程序中的每条通路是否都有能按预定要 求正确工作 灰盒测试灰盒测试 - 介于二者之间,关注输出对于输入的正确性, 同时也关注内部表现 13 测试策略 功能测试,界面测试,兼容性测试,分布测试 性能测试,可靠性测试,负载测试,容量测试,压力 测试,可用性测试 易用性测试,安全测试,配置测试,故障恢复测试, 加密测试 数据库测试,值域测试 安装测试,卸载测试,可移植性测试,文挡测试,版 本验证测试,裸机测试。 14 软件测试实施流程与变更控制 制定项目测试计划设计测试用例构建测试环境执行测试是否存在错误回归测试验收测试15 测试计划要素- 1/3 1、标题 2、确定软件的版本号 3、修订文档历史,包括作者、日期和批示 4、目录表 5、文档的目的和适合的读者群 6、测试的目的 7、软件产品概述 8、相关文档列表,例如:需求、设计文档、其他测试计划 等 9、相关的标准或合法需求 10、可跟踪性需求 11、相关的命名规范和标识符规范 12、整个软件项目组织和人员/联系信息/责任 16 测试计划要素- 2/3 13、测试组织和人员/联系信息/责任 14、假设和依赖关系 15、项目风险信息 16、测试优先级和焦点 17、测试范围和限制 19、测试提纲对测试过程的一个分解,通过测试类型、特点、 功能性、过 程、系统、模块等 20、测试环境设置和配置问题 21、数据库设置需求 22、概述系统日志/错误日志/其他性能,有助于描述和汇报问题的 屏幕捕获工具 等 23、有助于测试者跟踪问题根源的具体软硬件工具的论述 24、测试自动化的可能性和概述 17 测试计划要素- 3/3 25、使用的测试工具,包括版本、补丁等 26、使用的项目测试度量 27、报告需求和测试可传递性 28、软件入口和出口准则 29、初始的理性测试阶段和标准 30、测试终止和重新开始的标准 31、人员安排 32、测试地点 33、用到的测试外的组织,他们的目的、责任、可传递性、 联系人和协作问题 34、相关的财产、分类、安全性和许可证问题 35、公开的一些问题 36、附录词汇表、缩略语等 18 测试用例 一个测试用例就是一个文档,描述输入、动作、或者时 间和一个期望的结果,其目的是确定应用程序的某个特 性是否正常的工作。 测试用例就是将软件测试的行为活动,做一个科学化的 组织归纳。 开发测试用例的过程有助于在应用的需求和设计过程中 发现问题。 测试用例是测试工作的指导。 19 为何需要测试用例 软件测试是有组织性、步骤性和计划性的,为了能将软件 测试的行为转换为可管理的、具体量化的模式,需要创建 和维护测试用例。 在开始实施测试之前设计好测试用例,避免盲目测试并提高测试效率, 减少测试的不完全性; 测试用例的使用令软件测试的实施重点突出、目的明确; 根据测试用例的多少和执行难度,估算测试工作量,便于测试项目的时 间和资源管理与跟踪; 减少回归测试的复杂程度 在软件版本更新后只需修正少量的测试用例便可展开测试工作,降低工 作强度、缩短项目周期; 功能模块的测试用例的通用化和复用化则会使软件测试易于开展,并随 着测试用例的不断细化其效率也不断攀升; 根据测试用例的操作步骤和执行结果,可以方便地书写软件测试缺陷报 告; 可以根据测试用例的执行等级,实施不同级别的测试; 为分析软件缺陷和程序模块质量提供依据; 便于大型软件测试项目外包测试指导基础; 20 测试用例示意 测试用例编号ID 测试用例标题 测试的模块 测试输入条件 期望的输出结果 其它说明 ID 类型类型 标题标题 测试步骤测试步骤 期望的结果期望的结果 说明说明 001 登录 输入正确密 码 用户在登录界面输入正确的密 码后,按回车键 程序提示登录成 功 002 登录 输入错误密 码 用户在登录界面输入错误的密 码后,按回车键 程序提示输入密 码错误,请重新 输入 003 登录 不输入的空 密码 用户在登录界面没有输入任何 密码使密码为空后,按回车键 程序提示用户没 有输入密码,请 输入 程序应该告知 用户没有输入 密码,而不是 密码错误 21 测试用例管理 22 主要内容: 软件测试基础 黑盒测试方法 白盒测试方法 软件缺陷管理 23 黑盒测试的概念 黑盒测试又称功能测试、数据驱动测试或基于规 格说明书的测试,是一种从用户观点出发的测试。 测试人员把被测程序当作一个黑盒子。 24 主要测到的错误类型 1)不正确或遗漏的功能; 2)接口、界面错误; 3)性能错误; 4)数据结构或外部数据访问错误; 5)初始化或终止条件错误等等 局限性:用黑盒测试发现程序中的错误,必须在所 有可能的输入条件和输出条件中确定测试数据,来 检查程序是否都能产生正确的输出。但这是不可能 的,因为穷举测试数量太大,无法完成。 25 黑盒测试局限性 用黑盒测试发现程序中的错误,必须在所有可能的 输入条件和输出条件中确定测试数据,来检查程序 是否都能产生正确的输出。但这是不可能的,因为 穷举测试数量太大,无法完成。 假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上 运行。若X、Y取整数,按黑盒方法进行穷举测试: 可能采用的测试数据组: 232232264 如果测试一 组数据需要1毫秒,一年工作365 24小时,完成所有测 试需5亿年。 26 常用黑盒测试方法 等价类划分方法 边界值分析方法 因果图方法 场景法 正交实验设计方法 判定表驱动分析方法 错误推测方法 功能图分析方法 27 等价类划分法 有效等价类 - 是指对于程序的规格说明来说是合理的、有意义的输 入数据构成的集合 无效等价类 - 是指对于程序的规格说明来说是不合理的、没有意义 的输入数据构成的集合 确定等价类的原则 1.在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。 2.在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,则可以确立一个有效等价类和一个无效等价类。 3.在输入条件是一个布尔量的情况下,可以确立一个有效等价类和一个无效等价类。 4.在规定了输入数据的一组值(假定n个),并且程序要对每一个输入 值分别处理的情况下,可以确立n个有效等价类和一个无效等价类。 5.在规定了输入数据必须遵守的规则的情况下,可以确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。 6.在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。 28 边界值分析 根据经验法则,大量的错误是发生在输入或输出范围的 边界上,而不是发生在输入输出范围的内部.因此针对各 种边界情况设计测试用例,可以查出更多的错误。 使用边界值分析方法设计测试用例,首先应确定边界情 况。通常输入和输出等价类的边界,就是应着重测试的 边界情况.应当选取正好等于,刚刚大于或刚刚小于边界 的值作为测试数据,而不是选取等价
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号