软件测试培训PPT格式课件下载.ppt

软件测试培训PPT格式课件下载.ppt

《软件测试培训PPT格式课件下载.ppt》由会员分享，可在线阅读，更多相关《软件测试培训PPT格式课件下载.ppt（145页珍藏版）》请在冰豆网上搜索。

就是不希望发生的事情的可能性）w测试计划中必须标明商业上的风险。

w测试人员职责：

评估商业上的风险如实的向管理层汇报项目情况目前公司内测试组织的等级w测试是一件艺术品，很难掌握。

w测试是一门手艺，精通很困难。

w测试使用的是已定义好的测试流程，有规则可寻。

w测试有较高级的组织形式。

w世界级的测试组织。

测试的职责验证在整个软件开发周期中，各个阶段的软件质量是否合格。

验证最终交付给用户的系统是否满足用户的需要，是否符合需求。

通过样本测试数据，检查系统在运行过程中的情况。

对待可能产生的风险的策略w我们无法消除风险，但是我们可以降低在风险发生时的损失。

w降低系统风险的最有效的办法就是对其进行有针对性的测试。

系统风险列举w如果某部分产生了错误会导致的结果？

w未被验证的数据交换如果被接受w如果文件的完整性被破坏w系统是否能被安全恢复（完全恢复成备份时的状态）w是否能暂停系统的运行w进行维护工作时，系统性能是否会下降到不能接受的水平。

w系统的安全性是否有保证系统风险列举（继续）w系统的操作流程是否符合用户的组织策略和长远规划w系统是否可靠，稳定w系统是否易于使用w系统是否便于维护w是否易于与其它系统相连测试工作量w太少的测试是不负责任，过多的测试是一种犯罪。

w100的测试是不可能的，不同的用户采用的测试策略是不同的。

缺陷产生的原因w测试原因导致的缺陷：

测试目标定义错误在开发生命周期中，错误的选择了测试介入时期选择了低效的测试技术测试人员专业知识培训不够，工作低效计划不够详细，测试的随意性很大测试人员同开发人员沟通困难续w软件方面使用了不完全的或者不正确的判定标准来设计软件。

错误的处理了用户的非法操作忽略了对关键数据的输出检查w数据问题出现了不完整的数据，不正确的数据，过期的数据测试效果的好坏是组织级的问题w有效的测试最好由一个独立的团队来实施。

便于确定工作目标便于人员的培养与升迁利于团队建设对质量的忠诚度高利于新技术，新方法的产生和推广工作职责明确测试规划w好的测试不是碰巧发生的，而是规划出来的。

时间上人员上环境上技术上关系上组织能力上资金上结构化测试方法w传统的软件开发生命周期：

需求，设计，编码，测试，系统维护经验经验：

测试不应该被局限在单一的阶段大量的系统问题产生在软件开发前期越早进行测试越有效，投入产出比越高开发生命周期中的验证活动开发阶段开发阶段验证活动验证活动需求.确定验证步骤.对需求进行评审.产生功能测试用例.确定需求一致性设计.确定设计信息是否足够.准备结构和功能的测试用例.确定设计的一致性编码.为单元测试产生了结构和功能测试的测试用例.进行了足够的单元测试测试.测试应用系统，着重在功能上安装.为测试过的系统进行产品化的工作维护.修改缺陷并重新测试测试策略w在测试策略中必须标明可能存在的风险，这样在测试后的系统中可以有效的降低被标明的风险发生的可能性。

测试要素：

需要被标明的风险也是我们测试的重点。

测试阶段：

在整个开发生命周期中，测试工作介入的时期。

测试要素w正确性：

数据输入，过程处理和输出的正确性（IPO）。

w文件完整性：

文件被正确使用，恢复和存储的数据正确。

w授权：

特殊的授权可以执行一个特殊的操作。

w进程追踪：

当进程运行中，程序有能力证实进程在正常工作。

w系统运行的连续性：

当有非致命性问题发生后，系统有能力继续运行关键的任务。

w服务水平：

系统有紧急情况发生时，要求程序的输出结果不经或进行简单的处理后就可以直接使用。

w权限控制：

防止系统被误用（意外或者有意的）测试要素（续）w一致性：

确保最终设计和用户需求完全一致w可靠性：

在规定的时间内都可以正常运转。

w易于使用：

多数人均感觉易于使用。

w可维护性：

可以很容易的定位问题，并且进行修改。

w可移植性：

数据或者程序易于移至到其它系统上。

w耦合性：

系统中的组件可以很容易的联接。

w性能：

系统资源的占用率，响应时间，并发处理w操作性：

易于操作（Operator）确定测试策略w选择并确定测试要素的等级多数情况下选择37个w确定开发阶段w明确商业风险开发人员，重要用户和测试人员通过评审的方式对这些风险达成一致的意见。

w把风险列表存放在需求矩阵中矩阵中可以将风险同测试用例对应起来。

测试方法学测试方法w测试策略测试要素测试阶段w测试战略简要描述如何在以后的测试活动中实现测试策略确定测试战略w流水线的概念输入：

标准的入口或者是个可执行的程序执行过程：

按照工作分配执行检查过程：

确定输出符合预定义的标准输出：

符合现存的标准或者是认可的可交付的版本QC和QAw质量控制验证产品的正确性，当发现与设计不一致的时候进行纠正。

w质量保证充当支持执行全面质量管理的角色测试涉及的定义和概念w缺陷与需求规格说明书不一致的地方。

w静态检查确保系统按照组织的标准和过程运行，主要依赖于评审和非运行的手段来检查。

w动态检查在生命周期中进行测试（运行）续w静态测试在不运行程序的情况下检查程序的运行情况。

w动态测试运行程序代码w测试分类单元测试集成测试（组装测试）系统测试验收测试回归测试续w功能测试测试功能需求w结构测试验证系统架构w黑盒测试在不了解系统结构的情况下以说明书作为基础进行测试。

w白盒测试以系统内部结构和相关知识为基础进行测试。

为什么缺陷很难被找出？

w看不到w看到但是抓不到w典型的缺陷类型需求解释有错误用户定义错了需求需求记录错误设计说明有误编码说明有误程序代码有误数据输入有误测试错误问题修改不正确正确的结果是由于其它的缺陷产生的静态测试w需求评审w设计评审w代码走查w代码检查动态测试w单元测试w集成测试w系统测试w用户的验收测试w回归测试使用静态和动态测试来进行结构和功能测试测试阶段测试阶段执行人执行人静态校验静态校验动态校验动态校验可行性评审开发人员，用户需求评审开发人员，用户设计评审开发人员单元测试开发人员集成测试开发人员，用户系统测试开发人员在用户的协助下完成验收测试用户确定测试战术的八个步骤w确定并且学习测试策略w确定项目开发类型w确定软件系统类型w确定项目范围w鉴别战术风险w确定开始测试时会遇到的问题w建立系统测试计划w建立单元测试计划确定并学习测试策略w在众多的测试策略中那些是重要的w那些风险是最重要的w如果软件不能正常运行时，商业上会有什么损失w如果软件不能及时完成，商业上会有什么损失w谁是最清楚风险影响的人确定项目开发类型w传统的系统开发w交互式开发/原型法w系统维护w购买/签约/合同软件项目确定软件系统类型模拟数据采集数据显示流程控制决策&

辅助协助图形&

图象处理数据库管理诊断软件计算机操作系统传感器和信号处理软件开发工具确定项目范围w新系统的开发会影响那一个商业领域与现有系统的接口w在现有的系统上开发只是修正Bug？

重新设计维护？

增加新的功能？

对其它系统有无影响？

为了减小商业上的风险？

识别在战术上的风险w将策略风险分解成战术风险建立测试计划，定位这些风险将风险分布于各个阶段的测试计划中w战术风险的种类结构风险技术风险工作量的风险测试开始时应确定的工作w需求阶段确定测试策略确定收集了足够的需求产生功能性的测试用例w设计阶段确定设计和需求之间的联系确定进行了足够的设计产生结构和功能的测试用例w编码阶段确定和设计之间的联系确定拥有执行的足够条件产生结构和功能的测试用例续w测试阶段确定设计了足够的测试用例测试应用系统已经完成关键资源已经到位w安装阶段将测试完成的系统变为产品w维护阶段修改和重新测试建立计划w建立系统测试计划w建立单元测试计划w在测试战术上我们要花多长时间？

“如果计划作失败了，那就在计划失败”时间花在计划上要比花在重复的测试上有效测试的技巧测试技巧分类w结构测试相对于功能测试w动态测试相对于静态测试w手工测试相对于自动测试结构测试技巧w压力测试w执行测试w恢复测试w操作测试w复合性测试（与过程的复合性）w安全测试压力测试w目标模拟出实际用户环境w怎么用产生测试数据测试组模拟用户处理被创建的数据w例子确定是否分配了足够的磁盘空间通讯的容量是否足够测试系统过载的情况w什么时间使用当关于容量的信息不确定的时候性能测试技巧l目标确定系统达到了希望达到的性能水平l如何使用使用软件和硬件的监视器使用模拟的监控模型，对关心的性能指标进行监控创建一个小程序l例子计算通信的时间单位时间处理的信息量l什么时候使用在程序开发的早期进行恢复测试w目标当在进行安装或组装操作过程中，文件丢失时或发生意外后系统有能力重新进行操作w如何使用程序的安装，运行方式，工具的使用和关键技术经过足够的评估系统开发完毕后，介绍一下发生失败后的处理过程w例子人为的使一个系统在安装或者组装过程中产生错误w什么时间去使用当操作的连续性是个重点的时候操作测试w目标确定计算机的操作文档已经完整w如何使用作为计算机正常操作的一部分来执行测试w例子操作的介绍被文档化，操作者被培训w什么时候使用预先将程序进行产品化。

操作性是系统的一个重要指标的时候。

复合性测试w目标校验程序的开发是否依照已定义的标准，流程和操作方式进行的。

w如何去使用将文档/程序同标准相比较比较有效的方法是检查过程w例子代码互查（一行一行）w什么时候使用依赖于管理的需要安全性测试w目标安全性的缺陷很难被发现。

大多数的情况下组织能够防止一般性的破坏者。

w如何使用对安全性的需求进行评审分析与安全性有关的处理流程转包给专业的人员w例子定义了被保护的资源，权限进行了控制，日志文件和审查追踪是可用的。

w什么时间使用当被保护的资源对于组织具有重要的价值的时候功能测试技巧w需求测试w回归测试w错误处理测试w支持手册的测试w系统兼容测试w控制性测试w并行测试需求测试w目标用户的需求可以被实现w如何使用创建测试用例和功能检查列表w例子建立测试矩阵去证实系统需求均被文档化w什么时候使用每一个应用程序都要进行需求测试回归测试w目标程序修改后，确保功能的正确性w如何使用重新测试应用程序中没有改变的部分w例子重新执行以前的测试用例w什么时间使用当新的程序有可能影响老的功能的时候错误处理测试w目标所有可能的错误条件均经过了验证w如何使用一组有经验的人员预测在那里会出现问题w例子建立一个错误处理的列表w什么时候使用贯穿整个开发生命周期支持手册测试w目标检验操作过程被文档化了，并且完整了。

w如何使用对过程有足够的介绍可以协助用户正常使用w例子系统在一定的条件下产生一个提示，用户被告知如何采取必要的操作。

w什么时候使用最佳时机是在安装测试的时候，但是应该在开发全过程中。

兼容性测试w目标检验当使用适当的参数和数据时，需要的信息可以在两个系统中正确的交换w如何使用文件和数据被用来在多系统之间传递。

w例子典型的由一个系统到另一个系统的数据交换程序。

w什么时候使用当两个应用程序之间的参数有可能发生变化的时候管理能力测试w目标验证数据交换时有足够的审计追踪能力w如何使用关键数据或者有价值的数据w例子从负面来看程序，是否确保了会出错的条件都被保护了。

w什么时候使用系统测试的一部分并行测试w目的新版本和老版本同时运行，用以确保新版本的程序运行正确。

w如何使用需要对两个系统输入相同的数据来运行w例子运行新旧两个工资支付系统w什么时间使用当对新系统的的运行情况不确定的时候单元测试w关注单元一级w代码分析和测试w功能分析和测试w结构分析和测试w以错误为导向的分析和测试测试要素/测试技巧矩阵测试要素压力执行恢复操作复合性安全性需求回归错误处理手工支持系统兼容管理并行单元可靠性授权文件完整性审查追踪