《《软件测试培训》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《软件测试培训》PPT课件.ppt（145页珍藏版）》请在三一办公上搜索。
1、软件测试培训,火龙果软件（）北京：上海：深圳：,培训列表,软件测试的目的和策略测试方法学测试的技巧测试工具的选择软件开发中的测试过程实例讲解测试活动在软件工程中的应用,软件测试的目的和策略,典型测试步骤,1.计划：定义目标确定策略确定方法2.执行：建立环境执行计划3.检查：一步步验证执行完毕？4.循环：没有改正继续执行,谁参与测试？,用户方代表软件最终使用者软件开发人员软件测试人员高层经理的支持过程保证人员（SQA）,什么试缺陷？,缺陷：最终产品同用户的期望不一致缺陷的分类错误遗漏超出需求的部分缺陷（未触发）VS.错误（应首先解决）,测试的商业意义,降低风险（风险：就是不希望发生的事情的可能性
2、）测试计划中必须标明商业上的风险。测试人员职责：评估商业上的风险如实的向管理层汇报项目情况,目前公司内测试组织的等级,测试是一件艺术品，很难掌握。测试是一门手艺，精通很困难。测试使用的是已定义好的测试流程，有规则可寻。测试有较高级的组织形式。世界级的测试组织。,测试的职责,验证在整个软件开发周期中，各个阶段的软件质量是否合格。验证最终交付给用户的系统是否满足用户的需要，是否符合需求。通过样本测试数据，检查系统在运行过程中的情况。,对待可能产生的风险的策略,我们无法消除风险，但是我们可以降低在风险发生时的损失。降低系统风险的最有效的办法就是对其进行有针对性的测试。,系统风险列举,如果某部分产生了
3、错误会导致的结果？未被验证的数据交换如果被接受如果文件的完整性被破坏系统是否能被安全恢复（完全恢复成备份时的状态）是否能暂停系统的运行进行维护工作时，系统性能是否会下降到不能接受的水平。系统的安全性是否有保证,系统风险列举（继续）,系统的操作流程是否符合用户的组织策略和长远规划系统是否可靠，稳定系统是否易于使用系统是否便于维护是否易于与其它系统相连,测试工作量,太少的测试是不负责任，过多的测试是一种犯罪。100的测试是不可能的，不同的用户采用的测试策略是不同的。,缺陷产生的原因,测试原因导致的缺陷：测试目标定义错误在开发生命周期中，错误的选择了测试介入时期选择了低效的测试技术测试人员专业知识培
4、训不够，工作低效计划不够详细，测试的随意性很大测试人员同开发人员沟通困难,续,软件方面使用了不完全的或者不正确的判定标准来设计软件。错误的处理了用户的非法操作忽略了对关键数据的输出检查数据问题出现了不完整的数据，不正确的数据，过期的数据,测试效果的好坏是组织级的问题,有效的测试最好由一个独立的团队来实施。便于确定工作目标便于人员的培养与升迁利于团队建设对质量的忠诚度高利于新技术，新方法的产生和推广工作职责明确,测试规划,好的测试不是碰巧发生的，而是规划出来的。时间上人员上环境上技术上关系上组织能力上资金上,结构化测试方法,传统的软件开发生命周期：需求，设计，编码，测试，系统维护经验：测试不应该
5、被局限在单一的阶段大量的系统问题产生在软件开发前期越早进行测试越有效，投入产出比越高,开发生命周期中的验证活动,测试策略,在测试策略中必须标明可能存在的风险，这样在测试后的系统中可以有效的降低被标明的风险发生的可能性。测试要素：需要被标明的风险也是我们测试的重点。测试阶段：在整个开发生命周期中，测试工作介入的时期。,测试要素,正确性：数据输入，过程处理和输出的正确性（IPO）。文件完整性：文件被正确使用，恢复和存储的数据正确。授权：特殊的授权可以执行一个特殊的操作。进程追踪：当进程运行中，程序有能力证实进程在正常工作。系统运行的连续性：当有非致命性问题发生后，系统有能力继续运行关键的任务。服务
6、水平：系统有紧急情况发生时，要求程序的输出结果不经或进行简单的处理后就可以直接使用。权限控制：防止系统被误用（意外或者有意的）,测试要素(续),一致性：确保最终设计和用户需求完全一致可靠性：在规定的时间内都可以正常运转。易于使用：多数人均感觉易于使用。可维护性：可以很容易的定位问题，并且进行修改。可移植性：数据或者程序易于移至到其它系统上。耦合性：系统中的组件可以很容易的联接。性能：系统资源的占用率，响应时间，并发处理操作性：易于操作（Operator）,确定测试策略,选择并确定测试要素的等级多数情况下选择37个确定开发阶段明确商业风险开发人员，重要用户和测试人员通过评审的方式对这些风险达成一
7、致的意见。把风险列表存放在需求矩阵中矩阵中可以将风险同测试用例对应起来。,测试方法学,测试方法,测试策略测试要素测试阶段测试战略简要描述如何在以后的测试活动中实现测试策略,确定测试战略,流水线的概念输入：标准的入口或者是个可执行的程序执行过程：按照工作分配执行检查过程：确定输出符合预定义的标准输出：符合现存的标准或者是认可的可交付的版本,QC和QA,质量控制验证产品的正确性，当发现与设计不一致的时候进行纠正。质量保证充当支持执行全面质量管理的角色,测试涉及的定义和概念,缺陷与需求规格说明书不一致的地方。静态检查确保系统按照组织的标准和过程运行，主要依赖于评审和非运行的手段来检查。动态检查在生命
8、周期中进行测试（运行）,续,静态测试在不运行程序的情况下检查程序的运行情况。动态测试运行程序代码测试分类单元测试集成测试（组装测试）系统测试验收测试回归测试,续,功能测试测试功能需求结构测试验证系统架构黑盒测试在不了解系统结构的情况下以说明书作为基础进行测试。白盒测试以系统内部结构和相关知识为基础进行测试。,为什么缺陷很难被找出？,看不到看到但是抓不到典型的缺陷类型需求解释有错误用户定义错了需求需求记录错误设计说明有误编码说明有误程序代码有误数据输入有误测试错误问题修改不正确正确的结果是由于其它的缺陷产生的,静态测试,需求评审设计评审代码走查代码检查,动态测试,单元测试集成测试系统测试用户的验
9、收测试回归测试,使用静态和动态测试来进行结构和功能测试,确定测试战术的八个步骤,确定并且学习测试策略确定项目开发类型确定软件系统类型确定项目范围鉴别战术风险确定开始测试时会遇到的问题建立系统测试计划建立单元测试计划,确定并学习测试策略,在众多的测试策略中那些是重要的那些风险是最重要的如果软件不能正常运行时，商业上会有什么损失如果软件不能及时完成，商业上会有什么损失谁是最清楚风险影响的人,确定项目开发类型,传统的系统开发交互式开发/原型法系统维护购买/签约/合同软件项目,确定软件系统类型,模拟数据采集数据显示流程控制决策&辅助协助图形&图象处理数据库管理诊断软件计算机操作系统传感器和信号处理软件
10、开发工具,确定项目范围,新系统的开发会影响那一个商业领域与现有系统的接口在现有的系统上开发只是修正Bug？重新设计维护？增加新的功能？对其它系统有无影响？为了减小商业上的风险？,识别在战术上的风险,将策略风险分解成战术风险建立测试计划，定位这些风险将风险分布于各个阶段的测试计划中战术风险的种类结构风险技术风险工作量的风险,测试开始时应确定的工作,需求阶段确定测试策略确定收集了足够的需求产生功能性的测试用例设计阶段确定设计和需求之间的联系确定进行了足够的设计产生结构和功能的测试用例编码阶段确定和设计之间的联系确定拥有执行的足够条件产生结构和功能的测试用例,续,测试阶段确定设计了足够的测试用例测试
11、应用系统已经完成关键资源已经到位安装阶段将测试完成的系统变为产品维护阶段修改和重新测试,建立计划,建立系统测试计划建立单元测试计划在测试战术上我们要花多长时间？“如果计划作失败了，那就在计划失败”时间花在计划上要比花在重复的测试上有效,测试的技巧,测试技巧分类,结构测试相对于功能测试动态测试相对于静态测试手工测试相对于自动测试,结构测试技巧,压力测试执行测试恢复测试操作测试复合性测试（与过程的复合性)安全测试,压力测试,目标模拟出实际用户环境怎么用产生测试数据测试组模拟用户处理被创建的数据例子确定是否分配了足够的磁盘空间通讯的容量是否足够测试系统过载的情况什么时间使用当关于容量的信息不确定的时
12、候,性能测试技巧,目标确定系统达到了希望达到的性能水平如何使用使用软件和硬件的监视器使用模拟的监控模型，对关心的性能指标进行监控创建一个小程序例子计算通信的时间单位时间处理的信息量什么时候使用 在程序开发的早期进行,恢复测试,目标当在进行安装或组装操作过程中，文件丢失时或发生意外后系统有能力重新进行操作如何使用程序的安装，运行方式，工具的使用和关键技术经过足够的评估系统开发完毕后，介绍一下发生失败后的处理过程例子人为的使一个系统在安装或者组装过程中产生错误什么时间去使用当操作的连续性是个重点的时候,操作测试,目标确定计算机的操作文档已经完整如何使用作为计算机正常操作的一部分来执行测试例子操作的
13、介绍被文档化，操作者被培训什么时候使用预先将程序进行产品化。操作性是系统的一个重要指标的时候。,复合性测试,目标校验程序的开发是否依照已定义的标准，流程和操作方式进行的。如何去使用将文档/程序同标准相比较比较有效的方法是检查过程例子代码互查（一行一行）什么时候使用依赖于管理的需要,安全性测试,目标安全性的缺陷很难被发现。大多数的情况下组织能够防止一般性的破坏者。如何使用对安全性的需求进行评审分析与安全性有关的处理流程转包给专业的人员例子定义了被保护的资源，权限进行了控制，日志文件和审查追踪是可用的。什么时间使用当被保护的资源对于组织具有重要的价值的时候,功能测试技巧,需求测试回归测试错误处理测
14、试支持手册的测试系统兼容测试控制性测试并行测试,需求测试,目标用户的需求可以被实现如何使用创建测试用例和功能检查列表例子建立测试矩阵去证实系统需求均被文档化什么时候使用每一个应用程序都要进行需求测试,回归测试,目标程序修改后，确保功能的正确性如何使用重新测试应用程序中没有改变的部分例子重新执行以前的测试用例什么时间使用当新的程序有可能影响老的功能的时候,错误处理测试,目标所有可能的错误条件均经过了验证如何使用一组有经验的人员预测在那里会出现问题例子建立一个错误处理的列表什么时候使用贯穿整个开发生命周期,支持手册测试,目标检验操作过程被文档化了，并且完整了。如何使用对过程有足够的介绍可以协助用户
15、正常使用例子系统在一定的条件下产生一个提示，用户被告知如何采取必要的操作。什么时候使用最佳时机是在安装测试的时候，但是应该在开发全过程中。,兼容性测试,目标检验当使用适当的参数和数据时，需要的信息可以在两个系统中正确的交换如何使用文件和数据被用来在多系统之间传递。例子典型的由一个系统到另一个系统的数据交换程序。什么时候使用当两个应用程序之间的参数有可能发生变化的时候,管理能力测试,目标验证数据交换时有足够的审计追踪能力如何使用关键数据或者有价值的数据例子从负面来看程序，是否确保了会出错的条件都被保护了。什么时候使用系统测试的一部分,并行测试,目的新版本和老版本同时运行，用以确保新版本的程序运行
16、正确。如何使用需要对两个系统输入相同的数据来运行例子运行新旧两个工资支付系统什么时间使用当对新系统的的运行情况不确定的时候,单元测试,关注单元一级代码分析和测试功能分析和测试结构分析和测试以错误为导向的分析和测试,测试要素/测试技巧矩阵,继续,测试工具的选择,测试工具,测试标准边界值分析因果图检查表代码比较对照以编译为基础的分析确认/检查控制流分析,测试工具(继续),能证明正确性的数据以覆盖为基础的测试数据字典数据流分析以设计为基础的功能测试设计评审桌面检查灾难性测试,测试工具(继续),错误猜测执行的规则全面的测试实况调查流程图检查,视察使用仪器设备综合测试设备映射图,测试工具(继续),建模并
17、行操作并行模拟代码互查风险矩阵系统控制的评审得分快照(把系统一个时刻的情况保存下来),测试工具(继续),完成特征系统日志测试用例测试用例的产生形式跟踪工具程序容量的测试走查(讲解开发思路),选择和使用测试工具,按照用途选择匹配的工具在适当的生命周期选择工具按照测试人员的实际技能选择匹配的工具选择一个可提供的工具,测试工具/测试技巧矩阵,测试工具/测试技巧矩阵(继续),测试工具/测试技巧矩阵(继续),测试工具/测试技巧矩阵(继续),测试工具/测试技巧矩阵(继续),软件开发生命周期/测试工具对照表,软件开发生命周期/测试工具对照表(继续）,软件开发生命周期/测试工具对照表(继续）,软件开发生命周期
18、/测试工具对照表(继续）,测试工具管理,工具管理者的职责对工具负责帮助同事使用这些工具培训工具得使用方法负责同工具的厂家联系每年给出有关工具使用和购买得计划工具得升级工具情况报告工具管理者得任期不易太长,软件的测试过程,软件的测试过程,估算测试计划需求设计编码测试总结安装，交付维护,估算,估算什么,测试对软件工作量的估算的准确性测试评估软件系统的状况的准确性关注点：不准确的估算不适当的开发过程不真实的状态报告,对工作量的估算,如何知道对工作量的估算是正确的估算工作量的工具很容易出错对软件工作量的估算需要策略五个一般的方法猜加入一些约束条件以一些数据为基础模拟进行工作将一些参数模型化,参数模型法
19、,回归模型：将现有的参数与已有的历史数据相拟和。启发式模型：对历史数据进行观察和解释现象模型：假设软件开发过程可以依据一些更广泛的可适用的过程解释。,模型遵循的共同模式,估算软件的大小将大小转化成人力的估算，并且作出可能的成本的估算依据项目的特性进行估算的调整将整体的估算划分到不同的项目阶段中估算不包括技巧上面的人力和计算机的运行时间将以上内容相加,对估算进行检验,检验估算模型的合理性检验模型是否包含了必须的测试要素检验模型的正确性,校验估算模型的正确性,重新进行估算校验输入是否正确校验输入是否合理校验对数据的计算是否合理有效比较延期的估算是否符合项目实际情况让谨慎的人来作测试验证工作对软件中
20、的冗余价值估算,影响估算正确与否的因素,软件规模新设计新代码的比例复杂程度设计和编码的困难使用什么语言安全性需求的挥发性,续,组织因素项目计划人员开发环境计算机资源人员利用率膨胀因素估算就是估算，不是保证书,软件进展测试,追踪系统的瓶颈工作完成点同配置管理系统紧密的结合如何使用模块列表里程碑工作完成点用计算所有工作的完成度来检查系统工作过程。,测试计划,开发测试计划,目标详细的描述怎样能成功的完成测试工作，其中应包含必须的资源和实施计划。可能的不利因素：没有得到足够的培训心里准备不足缺乏测试工具缺乏管理的标准和支持缺乏客户和最终使用者的参与没有足够的时间进行测试对于独立的测试人员过度信任版本改
21、变的太快测试人员处于不受重视的情况中不能说不,实施过程,听取各方面的意见和建议标明项目风险测试要素联系测试矩阵建立测试计划对计划进行评审,建立测试计划,定义测试目标开发测试矩阵软件模型结构特性批量测试的阶段和用例为在线系统作概念上的测试脚本软件测试矩阵定义测试管理测试计划的一般性信息定义测试里程碑定义管理上的检查点书写测试计划,评审测试计划,涉及评审的问题评审测试的开始时间是否会延期有没有抵触评审的角色一段时间内是否很难得到工作的检查信息。更换工具有可能导致他们反感评审工作评审结果可能会影响对个人的工作评价对于最终成品的检查项目的需求规格说明书软件返工/维护的文档升级后的技术文档被更改的源程序
22、测试计划用户手册（包括在线帮助）,续,正式评审中的角色缓和剂（SQA）读者记录者作者检测员正式评审发现的缺陷应包含的信息起因类型分类级别,评审流程,计划和组织通篇的讲解（可选）个人准备评审会议修订和反复,需求阶段的测试,测试成本,在软件开发的所有阶段进行测试被设计用来减少测试成本IBM的数据大约 60个缺陷/千行2/3的缺陷产生在需求和设计阶段在需求和设计阶段发现的缺陷修正的花费最小修正系统测试阶段发现的缺陷，花费是以上的10倍发布产品以后，修正缺陷的花费是原来的100倍,生命周期的测试概念,在软件开发过程中持续的进行测试在尽可能早的阶段点去修正缺陷需要正式的开发流程来支持组建测试团队当开发开
23、始进行的时候，测试就开始进行了,需求阶段的测试,准备风险列表确定风险组确定风险风险分析风险检查表建立控制目标确定有足够的控制力度,分析测试要素,需求的设计是否遵循了已定义的方法提交了已定义的功能说明定义了系统界面已经估计了性能标准容忍度被预先估计预先定义了权限规则需求中预先定义了文件完整性预先定义了需求的变更流程预先定义了失败的影响权限定义,需求走查,建立基本规则选择小组/通报参与者项目介绍问题/建议形成最终报告,需求阶段测试,所有的花费都是值得的大部分缺陷将不会进入到设计&编码阶段目标需求正确的表现出了用户的需要需求已经被定义和文档化了花费和收益成正比需求的控制被明确有合理的流程可遵循有合理
24、的方法可供选择,设计阶段的测试,设计阶段的测试,交付的产品输入说明过程说明文件说明输出说明控制说明系统流程图硬件和软件的需求操作手册说明书数据保留的策略,设计阶段测试任务,给测试要素打分分析测试要素对设计进行评审检查修改的部分,分析测试要素,测试涉及的内容：设计了对数据完整性的控制设计了权限规则设计了对文件完整性的控制设计了审计追踪设计了发生意外情况时的计划设计了如何达到服务水平的方法定义了权限流程定义了完整的方法学设计了保证需求一致性的方法进行了易用性的设计设计是可维护的设计是简单的交互界面设计完毕定义了成功的标准需要同实际操作者沟通,对设计进行评审,选择评审组成员对评审组进行培训通报项目组
25、分配足够的时间只对文档化的事实进行评审和项目组一起进行评审对评审形成建议和项目组对建议一起进行评审准备正式的报告,编码阶段的测试,形成的输出,编码说明书程序文档计算机程序列表可执行的程序程序流程图操作介绍单元测试结果,测试活动的关注点,完成对数据完整性的控制定义完毕授权的规则完成对文件完整性的控制实现审计追踪规划出意外情况发生后的处理计划对系统如何达到预定义的服务水平做了计划完成了对安全问题的处理流程编码工作是依据规定的方法完成的编码与设计相一致（正确性）编码与设计相一致（易用性）代码是可维护的编码与设计相一致（简洁性）编码与设计相一致（耦合性）已开发了操作流程定义出程序成功的标准（性能上）,
26、测试的职责,编码是一个纯技术的工作，几乎不需要用户的参与项目领导者有参与测试的责任监督过程的有效性,建议的测试方式,桌面调试语法上的结构上的功能上的代码互查建立基本的互查规则选择互查的team对成员进行培训选择互查的方法提供互查的材料流程图，源程序，典型的处理流程对互查进行必要的管理给出互查结论提供最终的报告,编码阶段的测试需解决的问题,系统是可维护的吗？系统说明是否已经完成了？编码是否按照既有的标准进行，过程是否易于实践？是否有足够的测试计划用来评估可执行的程序？是否编制了足够的文档。,测试关注点,在需求，设计，编码阶段多进行一些测试，在系统测试阶段就会少一些问题。文档测试阶段的测试计划测试
27、用例前期测试的测试结果第三方测试反馈，例如：计算机操作人员正式的测试总结报告,典型测试类型,手册，回归，功能点测试一致性测试（授权）功能点测试（完整性）功能点测试（审计，追踪）覆盖性的测试（测试的连续性）压力测试（服务水平）一致性测试（安全性）依照预先定义的测试方法功能点测试（正确性）支持手册的测试（易用性）检查（可维护性）灾难性的测试（可携带性）功能和回归测试（耦合性）一致性的测试（性能）操作性的测试（易用性）,建议测试方法,测试方法测试用例的概念是简单的建立有效的测试用例是复杂的设计测试文件测试用例应当包含合法的和非法的输入每一个动作只进行一次关键操作输入测试数据分析结果尝试将测试文件违反
28、程序的规则进行输入容量测试的测试工具以大信息量的数据进行输入这是一个昂贵的测试，应根据需要来选择在线系统需要做压力测试,测试总结,测试报告,目标表示出目前项目的实际状况明确什么是测试做的工作，什么是不作的工作。给出系统的操作性能的评价明确什么时候系统可以进行产品化的工作关注点测试报告只有真正需要的时候才有用，需要配合市场和管理测试的信息是不充分的（对于评价一个项目来说）测试状况并不能真实的反应个人的状况,测试期间数据的收集,有关测试结果的积累数据测试任务，测试集合和测试事件的描述缺陷分析由于计划的问题，导致没有发现的缺陷的数据严重的缺陷缺陷类型为什么缺陷没有发现效果,测试报告,报告目前的软件状
29、态功能/测试矩阵功能测试的状态报告，侧重点分析关于功能的工作时间轴期望发现 VS 实际发现的缺陷比没有发现的缺陷和改正的缺陷的差距按照类型分类，没有改正的缺陷的平均值缺陷分类报告测试活动报告,最终的报告汇总,各个阶段的项目测试总结报告继承性测试报告系统测试报告确认测试报告,安装测试,安装阶段的测试准备,安装计划安装流程图安装文件和程序清单测试安装程序给出测试结果将程序运行的软硬件要求放入产品说明中对于新操作人员的使用说明书对于新使用者的操作说明和操作流程安装过程中的各项可能发生的结果的说明,测试关注点,对程序安装的正确性和完整性进行核对校验产品文件的完整性安装的审查，追踪被记录安装之前，该系统
30、已经被证实没有问题如果安装失败，系统有相应的解决方案安装过程，进行了权限控制（安全性）安装遵循一定的方法，步骤需要的配套程序和数据已经放进了产品中已交付使用说明相关文件已经完整(可维护性）接口已经被合理调整（耦合性）综合的性能达到了用户要求,建议测试工具,测试工具检查表选择测试的范围选择检查表明白这些问题的用意提前测试用户的检查表使用该检查表模拟运行一遍自己向自己汇报一次将有用的信息记录下来评估检查表和检查流程,续,测试标准数据的正确性将程序产品化向操作者和用户进行讲解校验检查表和产品的正确性使用测试标准去检验发生的问题,验收测试,软件验收流程,定义用户角色定义验收标准编制验收计划执行验收计划
31、填写验收结论,定义用户角色,确定最终用户的范围确认临时的和最终产品的验收标准计划每一个验收过程由谁和如何执行计划资源分配计划时间分配准备验收计划为每一项验收工作给出结论,确定验收标准,功能上性能上接口质量上过载后的软件质量安全性软件的稳定性,编写验收计划,项目描述用户职责行政上的流程验收活动描述每一个验收项的评审最终的验收测试步骤,执行和结论,执行验收计划验收测试和评审进行管理验收的结果典型的验收结果在进入下一个活动之前问题或者变更必须被接受工作可以继续，但是下次评审之前必须更正没有任何的更改,维护阶段,工作重点和目标,两个重要的工作：测试和培训目标：开发一些测试用例，预先发现一些问题在运行情
32、况发生变化后，预先的修正一些错误编写必要的培训材料对有关的人员进行培训同用户进行接触,开发更新测试计划,测试计划要简短，必须在短时间内完成。只测试变化的部分两点：测试什么，如何测试测试要素变化的数据交换变化的程序操作流程用户的操作习惯不同系统之间的互联语言版本安全性备份/恢复,编制培训计划,对系统进行概览对系统假定一些错误，给出处理方法培训材料对项目内容的陈述用户使用方法对错误列表上的问题给出解释对报告进行解释，并且说明如何使用他们（图标，数据等）对输入数据进行解释,反馈,反馈包括：用户反馈和测试反馈，又分成错误和建议。没有反馈意见，程序很难提高反馈的类型测试的数量和内容发现的问题数量和分类区分是技术上的还是应用上的问题将反馈信息重新整理，加入到相关的测试数据中,实例讲解测试活动在软件工程中的应用,活动阶段分类,需求阶段设计阶段编码阶段集成测试阶段系统测试阶段验收测试阶段产品化发货阶段,阶段流程图,总体流程图需求阶段测试工作流程设计&编码阶段测试工作流程集成，系统，验收测试阶段,谢谢,
