软件测试基本流程.ppt_第1页
软件测试基本流程.ppt_第2页
软件测试基本流程.ppt_第3页
软件测试基本流程.ppt_第4页
软件测试基本流程.ppt_第5页
已阅读5页,还剩16页未读 继续免费阅读

下载本文档

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

文档简介

软件测试流程培训,SUN,什么是软件测试,软件测试概念 使用人工或自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果于实际结果之间的差别,软件测试原则,1.应及早进行测试并把测试贯穿于整个软件生命周期 2.软件测试应追溯需求 3.测试应由第三方构造 4.穷举测试是不可能的 5.必须确定预期输出结果 6.必须彻底检查每个测试结果 7.充分注意测试中的群集现象,软件生命周期V模型,通过V模型我们可以看出: 软件测试按阶段可分为 单元测试 集成测试 系统测试 验收测试 我们一般进行的测试为系统测试,即将所有系统元素结合在一起,在实际运行环境下对系统进行全面的功能覆盖。,软件测试流程,软件测试一般流程: 1.制定测试计划 2.设计测试方案/用例 3.实施测试 4.测试总结,需求阶段: 根据需求规格说明书输出系统测试计划 详细设计/编码阶段: 评审开发输出的SRS(详细设计说明书) 根据最终SRS输出测试方案/测试用例-评审/修改测试方案/用例 测试阶段(SDV1、SDV2、SDV3): 1.每轮测试前需要做冒烟测试,执行功能Chicklist,确认系统主要功能正确, 如果Chicklist达不到要求,可以要求开发版本打回(最好的办法是提供开发人员一份Chicklist ,要求开发出版本转测前进行自测,保证Chicklist全部通过才转测试),每轮测试结束后进行测试用例的修改/补充工作。 2.SDV1阶段时间最长,要求在此阶段时间内尽量将问题发现,避免以后阶段再出现低级BUG。每轮以用例全部执行完,功能全部覆盖作为结束标准(迭代开发除外)。 3.SDV2或SDV3阶段,在冒烟测试后,系统测试展开前,需要进行上一轮的问题回归测试,以验证开发问题修改情况,并将回归情况进行反馈,系统测试后期一般根据需要会展开交叉测试以及发散性测试等测试策略 *系统测试完成标准以是否满足缺陷率为判定标准 测试结束需要输出测试报告 测试报告以代码量、测试用例数、缺陷数、投入人力/天数为数据依据 测试总结、问题回溯/漏测分析,测试方案/测试用例编写,测试方案设计: 测试方案就是对系统模块的功能进行分析后,设计测试点(正常、异常情况),要求达到对模块功能的的覆盖,指导测试用例的设计 注: 测试方案阶段要求对模块功能实现逻辑进行全面的掌握,包括功能限定,异常情况处理、后台数据处理,涉及到的数据表/字段等 建议和开发多进行沟通,让开发人员对实现逻辑等进行全面说明,并做记录 测试方案设计样式根据各个公司要求进行,一般是写在各个功能的SRS后,测试用例设计: 测试用例设计使用的的测试方法 1.等价类划分 2.边界值法 3.因果图判定表 4.通过测试 5.失败测试 6.错误猜测 7.随机测试 等,测试用例设计的注意点 1.一种情况一条用例,用例设计尽可能细化 2.用例名称要求能简单明了的描述该用例的测试点 3.用例级别要明确,一般主功能正常用例的级别为1级,复杂及异常情况用例可为2、3级 4.预置条件要清楚,对该用例执行所需要满足的条件描述清楚,特别是异常情况用例时。 5.测试步骤尽量详细,要做到让用例设计者以外的人能根据测试步骤顺利执行用例,格式不做强制要求 6.预期结果要明确,对于页面跳转,数据入库等结果要细化,异常操作要有相应提示等。例如用户注册成功后,页面跳转到注册成功页面,出现相应提示信息,哪些表中会有相应用户注册数据,或哪些表中哪个字段值会有何样改变等。 要做到能让用例设计者以外的人执行用例后对于执行的结果有明确清楚的判定标准,测试策略简介,功能测试 性能测试 负载测试 压力测试 容量测试 易用性测试 安装测试 界面测试 配置测试 文档测试 兼容性测试 安全性测试 恢复测试,如何有效的跟踪问题,测试时往往会遇到很多问题阻塞测试进度,或者问题单迟迟得不到解决的情况,此时要求测试人员能发现问题,尽量通过日志进行定位,如无法定位问题所在,应及时找相关开发人员进行问题定位及解决。但是也不能将问题丢给开发作为跟踪的结束,要定时跟踪问题解决情况,并尽量让开发给出解决问题时间点,进行其他方面工作,以避免时间浪费。平时需要和开发保持良好沟通,解决问题会快一点,开发主动性也会相对较高。 对于测试人员来说,要学会定位问题,学会通过日志发现问题,平时在开发人员帮助解决问题时可进行学习,知道问题所在,测试驱动开发,虽然说在项目开发过程中开发人员处于主导地位,但是测试人员是站在用户的角度去评价系统的,测试人员如过发现流程或者设计不合理的地方应及时提出,和开发进行讨论,驱动开发人员修改设计不当的地方。 当开发人员对测试人员提出的意见比较排斥时,不能开发人员说什么,测试人员听什么,要根据情况坚持自己的观点,必要时可找有决策权的人决定是否修改,问题单编写规范,1.问题单标题规则 【模块名】+问题描述 问题描述尽量用简介的语言将问题描述清楚,不宜过长 2.需要有详细的重现步骤,对于概率性出现的问题要尽量重现操作步骤; 3.实际结果或存在问题 4.预期结果或建议 5.最好每个问题能附上图片 注:对于一些突发的问题,尽量截图保留问题页面,再分析是否 为系统问题,问题单级别,致命:系呕吐那个任何一个主要功能完全丧失,数据受到破坏、系统崩 溃、死机等 严重:系统的主要功能部分丧失,数据不能保存,所提供的功能或服务受到明显影响 一般:系统次要功能没有完全实现,但不影响用户使用 建议:不影响功能的,提示信息,易用性方面等,关于Chicklist,作为每次转测试前的冒烟测试(预测试),修要保证转测的系统主要功能完全实现,满足此条件才可进入测试阶段,否则根据Chicklist执行情况,可将包打回给开发。 最好要求开发人员打包后先自行验证Chicklis

温馨提示

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

评论

0/150

提交评论