版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
1、软件测试 -概述主题 涂磊 2012.7.5课程目标v了解软件测试工程师的职业要求及特点v掌握软件测试的基本概念 v熟悉常用的软件测试类型v熟悉软件测试的基本工作过程v了解常用的软件测试用例方法课程内容v软件测试背景v什么是软件测试v软件测试的基本工作过程v测试用例及其设计方法软件的定义 公认的软件定义由三部分组成: 1、运行中能提供所希望的功能和性能的指令集 (即程序)。 2、使程序能够正确运行的数据结构。 3、描述整个程序研发过程、方法所用的文档。软件缺陷是什么? 软件未达到产品说明书标明的功能。 软件出现了产品说明书指明不会出现的错误。 软件功能超出产品说明书指明范围。 软件未达到产品说
2、明书虽未指出但应达到的目标。 软件测试员认为软件难以理解、不易使用、运行速度缓慢, 或者最终用户认为不好。软件缺陷的产生需求错误缺乏交流设计错误文档缺乏缺陷软件复杂开发编码时间压力Requirem ents5 6 %D esign2 7 %O ther1 0 %C ode7 %错误定位费用分析错误定位费用分析Requirem ents82%D esign13%O ther4%C ode1%James Martin:超过50%的缺陷由不完善的、不正确的、不准确的和/或不明确的需求所引起James Martin:80%以上的用于定位软件错误的费用是基于软件系统需求定义的错误软件缺陷错误分析阶段需求
3、设计编码单元测试验收测试交付后维护纠正费件缺陷的维护费用软件测试贯穿整个项目周期概念方案开发验证发布启动启动项目项目制定产品测试策略制定产品测试计划持续跟踪监控产品测试计划优化产品测试计划测试测试软件测试人员应具备的能力1、探索精神:软件测试人员不会害怕进入陌生环境。2、故障排除能手:软件测试人员善于发现问题的症结,喜欢猜谜。3、不懈努力:软件测试人员总是不停尝试。他们可能会碰到转瞬即逝或者难以重建的软件缺陷;他们不会心存侥幸,而是尽一切可能去寻找。4、创造性:想出富有创意甚至超常的手段来寻找软件缺陷。5、追求完美:力求完美,但是知道某些目标无法企及时,不去苛求,而是
4、尽力接近目标。6、判断准确:软件测试人员要决定测试内容、测试时间,以及看到的问题是否算作真正的缺陷。7、老练稳重:软件测试员不害怕坏消息。8、说服力:软件测试员要善于表达观点,表明软件缺陷为何必须修复,并通过实际演示力陈述观点。软件测试人员职业发展方向课程内容v软件测试背景v什么是软件测试v软件测试的基本工作过程v测试用例及其设计方法软件测试定义软件测试(Software testing)是软件生存期中的一个重要阶段,是软件质量保证的关键步骤。通俗地讲,软件测试就是在软件投入运行前,对软件需求分析、设计规格说明和编码进行最终复审的活动。1983年IEEE提出的软件工程术语中给软件测试下的定义是
5、:“使用人工或自动的手段来运行或测定某个软件系统或系统部件的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。软件测试的对象 软件测试不等于程序测试,软件测试贯穿于软件定义和开发的整个期间。需求分析,概要设计,详细设计,以及程序编码等各个阶段所得到的文档,包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序,都是软件测试的对象。软件测试=程序+文档+数据软件测试的目的 从用户(测试人员或QC)的角度出发,普遍希望通过软件测试暴露软件中隐藏的错误和缺陷,以考虑是否可接受该产品。 从软件开发者的角度出发,则希望测试成为表明软件产品中不存在错误的过程,验证该软件
6、已正确地实现了用户的要求,确立人们对软件质量的信心。 测试的目的就是发现软件中的各种缺陷 以较少的用例、时间和人力找出软件中的各种错误和缺陷,以确保软件的质量最终目的是确保软件的功能符合用户的需求,把尽可能多的问题在发布或交付前发现并改正:-确保软件完成了它所承诺或公布的功能-确保软件满足性能的要求-确保软件是健壮的和适应用户环境的软件测试的目的软件测试的两个重要原则Good-enough原则 Zero-bug & Good-enough 投入 & 产出Pareto原则(二八原则) 研发测试:80% BUG 系统测试:80% BUG 用户使用:5% BUG软件测试的原则 测试的
7、目的在于发现错误 ,应尽早地和不断地进行测试 测试只能证明软件存在缺陷,不能证明软件不存在缺陷 测试不是为了证明程序是正确的,而是应从软件包含有缺陷和故障这个假定去进行测试活动。 测试可以使软件中缺陷降低到一定程度,而不是彻底消灭 充分注意测试中的群集现象经验表明,测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。 所有的测试都应可追溯到客户需求 穷举测试是不可能的 严格执行测试计划,排除测试的随意性。 应当对每一个测试结果做全面检查。 妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便。软件测试的分类名称说明黑盒测试基于软件需求,而不是基于软件内部设计和程序实现的测
8、试方式。白盒测试基于软件内部设计和程序实现的测试方式。单元测试主要测试软件模块的源代码。一般由开发人员而非独立测试人员来执行,因为测试者需要懂得该单元的设计与程序实现,测试者可能需要编写额外的测试驱动程序。集成测试将一些“构件”集成一起时,测试它们能否正常运行。这里“构件”可以是程序模块、客户机服务器程序等等。功能测试测试软件的功能是否符合功能性需求,通常采用黑盒测试方式。一般由独立测试人员执行。系统测试测试软件系统是否符合所有需求,包括功能性需求与非功能性需求。一般由独立测试人员执行,通常采用黑盒测试方式。回归测试指错误被修正后或软件功能、环境发生变化后进行的重新测试。回归测试的困难在于不好
9、确定哪些内容应当被重新测试。验收测试由客户或最终用户执行,测试软件系统是否符合需求规格说明书。软件测试的分类名称说明负载测试测试软件系统的最大负载,超出此负载软件可能会失常。压力测试概念上与负载测试相似,叫法不同。性能测试测试软件在各种状况下的性能,如在正常或最大负载下的状况。易用性测试测试软件是否易用,主观性比较强。一般要根据很多用户的测试反馈信息,才能评价易用性。安装与反安装测试测试软件在“全部、部分、升级”等状况下的安装/反安装过程。恢复测试测试该系统从故障中恢复过来的能力。安全性测试测试该系统防止非法侵入的能力。兼容性测试测试该系统与其它软件硬件兼容的能力。比较测试通过与同类产品比较,
10、考察该系统的优点、缺点。Alpha 测试一种先期的用户测试,此时系统刚刚开发完成。Beta测试一种后期的用户测试,此时系统已经通过内部测试,大部分错误已经改正,即将正式发行。软件测试的分类和比较 测试方式n白盒测试:关心软件内部设计和程序实现,主要测试依据是设计文档n黑盒测试:不关心软件内部,只关心输入输出,主要测试依据是需求文档(SRS) 软件测试的分类和比较测试方式特征依据测试人员测试驱动程序黑盒测试只关心软件的外部表现,不关心内部设计与实现。又叫做功能测试或数据驱动测试。软件需求任何人(包括开发人员、独立测试人员和用户)一般无需编写额外的测试驱动程序白盒测试关注软件的内部设计与实现,要跟
11、踪源代码的运行。又叫结构测试或逻辑驱动测试。设计文档由开发人员兼任测试人员的角色需要编写额外的测试驱动程序 测试阶段 单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程,体现了“分而治之”的思想。 单元测试的粒度最小,一般由开发小组采用白盒方式来测试,主要测试单元是否符合“设计”。 集成测试界于单元测试和系统测试之间,起到“桥梁作用”,一般由开发小组采用白盒加黑盒的方式来测试,既要验证“设计”又要验证“需求”。 系统测试的粒度最大,一般由独立测试小组采用黑盒方式来测试,主要测试系统是否符合“需求规格说明书”。 验收测试与系统测试非常相似,主要区别是测试
12、人员不同,验收测试由用户执行。 软件测试的分类和比较软件测试的内容测试内容n接口与路径测试。 n功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试 测试阶段 主要依据 测试人员、测试方式 主要测试内容 单元测试单元测试系统设计文档系统设计文档由开发小组执行白盒测由开发小组执行白盒测试试 接口测试、路径测试接口测试、路径测试 集成测试集成测试系统设计文档系统设计文档需求文档需求文档由开发小组执行白盒测由开发小组执行白盒测试和黑盒测试试和黑盒测试 接口测试、路径测试接口测试、路径测试功能测试、性能测试功能测试、性能测试 系统测试系统测试需求文档需求文档
13、由独立测试小组执行黑由独立测试小组执行黑盒测试盒测试 功能测试、健壮性测试、性能测功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、试、用户界面测试、安全性测试、压力测试、可靠性测试、安装压力测试、可靠性测试、安装/ /反安装测试反安装测试 验收测试验收测试需求文档需求文档由用户执行黑盒测试由用户执行黑盒测试 课程内容v软件测试背景v什么是软件测试v软件测试的基本过程v测试用例及其设计方法用户需求用户需求软件需求软件需求概要概要设计设计详细设计详细设计编码实现编码实现单元测试单元测试集成测试集成测试系统测试系统测试验收测试验收测试准备计划验证验证准备计划验证验证准备计划验证验证软件测试
14、的V模型软件需求文档系统测试计划集成测试计划单元测试报告集成测试报告系统测试报告验收测试报告螺旋式测试过程Plan /Analysis计划计划/分析分析Design设计设计Coding编码编码Test/Deliver测试测试/交付交付Test Case Design测试用例设计测试用例设计Test Development测试开发、环境测试开发、环境搭建搭建Test Planning测试测试计划计划Test Execution/Evaluation测试执行测试执行/评估评估一个规范化的软件测试过程包括以下基本的测试活动-拟定软件测试计划、方案-设计和生成测试用例、准备测试数据-执行测试,记录原始
15、数据,对缺陷进行管理-生成软件测试报告、缺陷的统计和报表软件测试过程与整个软件开发过程基本上是平行进行的一个开发机构还应当制定软件测试规程,按照软件工程的规范,定义各项活动的目标和详细过程 软件测试基本过程软件测试基本过程 测试报告填写 确定测试要求 制定测试计划 双方确定测试计划 有修改 确认过过 制定测试方案 安排项目进度 培训测试人员 建立测试环境 编写测试用例 执行测试计划 检测并在数据库中记录缺陷 未完成 回归测试 完成 向用户提交缺陷列表 测试报告填写 开发人员修正错误 客 户 是 否 课程内容v 软件测试背景v什么是软件测试v软件测试的基本工作过程v测试用例及其设计方法为什么需要
16、测试用例 所谓的测试用例就是将软件测试的行为活动,做一个科学化的组织归纳。软件测试是有组织性、步骤性和计划性的,而设计软件测试用例的目的,就是为了能将软件测试的行为转换为可管理的模式。 软件测试是软件质量管理中最实际的行动,同时也是耗时最多的一项。基于时间因素的考虑,软件测试行为必须能够加以量化,才能进一步让管理阶层掌握所需要的测试过程,而测试用例就是将测试行为具体量化的方法之一。什么是测试用例为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据,称之为测试用例。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。 测试用例是为特定的目的而设计的一组
17、测试输入、执行条件和预期的结果我们不可能进行穷举测试,为了节省时间和资源、提高测试效率,必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。一个好的测试用例是在于它能发现至今未发现的错误。测试用例是执行的最小实体测试用例的基本要素目的 前提条件 输入数据或动作 期望的响应 各种环境设置 对应的需求测试用例的代表性: 能够代表并覆盖各种合理的和不合理的、合法的和非法的、 边界的和越界的以及极限的输入数据、操作和环境设置等。测试结果的可判定性: 即测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果。测试结果的可再现性: 即对同样的测试用例,系统的执行结
18、果应当是相同的。测试用例的基本准则黑盒测试用例的设计方法名称说明等价类分析法是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例;包括有效等价、无效等价等边界值分析法边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,其测试用例来自等价类的边界。包括数值的边界值、字符边界值、其他边界值等。场景法现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行名称说明错误推测法基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。判定表驱动法判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。由条件桩、动作桩、条件项、动作项组成正交试验设计法正交实验设计法是通过正交试验
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
评论
0/150
提交评论