第08章软件测试流程和分类理论课论文资料.ppt

第08章软件测试流程和分类理论课论文资料.ppt

  1. 1、本文档共39页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
第08章软件测试流程和分类理论课论文资料

*/39 软件测试的分类——按策略 动态测试的两种方法 黑盒测试和白盒测试 动态测试的特点 实际运行被测试程序,取得程序运行的真实情况、动态情况,进而进行分析 必须生成测试数据来运行程序,测试质量依赖于测试数据 生成测试数据、分析测试结果工作量大,使开展测试工作费时、费力、费人 动态测试中涉及多方面工作,人员多、设备多、数据多,要求有较好的管理和工作流程 */39 软件测试的分类——按策略 黑盒测试与白盒测试 黑盒测试又称功能测试、数据驱动测试或基于规格说明书的测试 */39 软件测试的分类——按策略 白盒测试又称结构测试、逻辑驱动测试或基于程序本身的测试,是根据程序的内容来设计测试数据(见王立福软件工程6章PPT8) 白盒测试是基于覆盖率的测试 常见的程序结构覆盖如下: 语句覆盖:每条语句至少被执行一次 分支(判断)覆盖:每条分支至少走查过一次 条件覆盖: 分支(判断)/条件覆盖: 路径覆盖:使程序沿所有可能的路径执行 */39 软件测试的分类——按策略 手工测试与自动测试 自动测试优点 节约大量时间 处理精确的事务 大数据量事务 并发事务 自动测试局限 产品本身不稳定 开发、维护脚本工作量大、费用高 人才缺乏 成熟的自动测试机制:可以在机器空闲的时候通过“按钮”触发执行夜间测试 */39 软件测试的分类——按策略 冒烟测试 在版本下来投入正式测试之前,对一些重点部分功能进行确认,以决定此版本是否进入正式测试阶段 回归测试 过一段时间以后再回过头来对以前修复过的缺陷重新进行测试,看该缺陷是否会重新出现。 欧洲阿里亚娜5型火箭 */39 黑盒测试与白盒测试 静态测试与动态测试 手工测试与自动测试 冒烟测试 回归测试 软件测试的分类——按策略小结 */39 单元测试 集成测试 系统测试 验收测试 软件测试的分类——按阶段 */39 软件测试的分类——常见测试方法 功能测试 性能测试 压力测试 负载测试 易用性测试 安装/卸载测试 界面测试 配置测试 文档测试 兼容性测试 安全性测试 恢复测试 功能性测试:又称正确性测试,检查软件的功能是否符合规格说明 检查系统是否满足在需求说明书中规定的功能,主要测试软件处理事务的速度,通常使用自动化测试工具 获取系统正确运行的极限,检查系统在瞬间峰值负荷下正确执行的能力 用于检查系统在使用大量数据的时候正确工作的能力,即检查系统的能力最高能达到什么程度 满足用户需求的最基本测试,包括:窗口测试、菜单和鼠标测试、数据项测试 检查计算机系统内各个设备或各种资源之间的相互连接和功能分配中的错误 检查文档的正确性、完备性和可理解性 验证软件产品在不同版本之间的兼容性,包括:向下兼容和交错兼容 检查系统对非法侵入的防范能力,检验系统中已经存在的系统安全性、保密性措施是否发挥作用,有无漏洞 检查系统的容错能力 从使用的合理性和方便性角度对软件系统进行检查,发现人为因素或使用上的问题 对软件的全部、部分或升级安装/卸载处理过程的测试 */39 本章内容总结 通过本章的学习: 了解软件测试流程 了解软件测试分类 * * * * * * 案例:测试汽车的车灯是否正常 用黑盒测试的方法:打开开关看看对应的车灯是否打开,亮度是否正常。 用白盒测试的方法:除了检查线路是否连通外,还要分析布线是否合理的因素。 * * 测试计划与软件缺陷 第八章 软件测试流程和分类 */39 上一章内容回顾 软件生命周期(瀑布模型、螺旋模型) 软件测试生命周期 测试计划内容 */39 本章学习目标 了解软件测试流程 了解软件测试分类 */39 内容进度 软件测试流程 软件测试分类 */39 软件测试流程 软件测试流程图(需求阶段) */39 需求阶段——产品基本情况调研 目的 重点描述如何使测试建立在客观的基础上,定义测试的策略,测试的配置, 粗略的估计测试大致需要的周期和最终测试报告递交的时间。 变更 说明有可能会导致测试计划变更的事件。包括测试工具改进了,测试的环境改变了,或者是添加了新的功能。 技术结构 可以借助画图,将要测试的软件划分成几个组成部分,规划成一个适用于测试的完整的系统,包括数据是如何存储的,如何传递的(数据流图),每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求,比如运行平台、需要什么样的数据库等等。 产品规格 就是制造商和产品版本号的说明。 测试范围 简单的描述如何搭建测试平台以及测试的潜在的风险。 项目信息 说明要测试的项目的相关资料,如:用户文档,产品描述,主要功能的举例说明。 */39 需

文档评论(0)

seunk + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档