【文档说明】软件测试人员培训教程课件.pptx，共(145)页，752.628 KB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-50470.html

以下为本文档部分文字说明：

软件测试培训贺炘hcat@163.net第1页，共145页。培训列表✓软件测试的目的和策略✓测试方法学✓测试的技巧✓测试工具的选择✓软件开发中的测试过程✓实例讲解测试活动在软件工程中的应用第2页，共145页。软件测试的目的和策略第3页，共145页

。典型测试步骤1.计划：定义目标确定策略确定方法2.执行：建立环境执行计划3.检查：一步步验证执行完毕？4.循环：没有改正继续执行第4页，共145页。谁参与测试？用户方代表软件最终使用者软件开发人员软件测试人员高

层经理的支持过程保证人员（SQA）第5页，共145页。什么试缺陷？缺陷：最终产品同用户的期望不一致缺陷的分类错误遗漏超出需求的部分缺陷（未触发）VS.错误（应首先解决）第6页，共145页。测试的商业意

义降低风险（风险：就是不希望发生的事情的可能性）测试计划中必须标明商业上的风险。测试人员职责：评估商业上的风险如实的向管理层汇报项目情况第7页，共145页。目前公司内测试组织的等级测试是一件艺术品，很难掌握。测试是一门手艺，精通很困难。测试使用的是已定义好

的测试流程，有规则可寻。测试有较高级的组织形式。世界级的测试组织。第8页，共145页。测试的职责验证在整个软件开发周期中，各个阶段的软件质量是否合格。验证最终交付给用户的系统是否满足用户的需要，是否符合需求。通过样本测试数据，检查系统在运行过程

中的情况。第9页，共145页。对待可能产生的风险的策略我们无法消除风险，但是我们可以降低在风险发生时的损失。降低系统风险的最有效的办法就是对其进行有针对性的测试。第10页，共145页。系统风险列举如果某部分产生了错误会导致的结果？未

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

统风险列举（继续……）系统的操作流程是否符合用户的组织策略和长远规划系统是否可靠，稳定系统是否易于使用系统是否便于维护是否易于与其它系统相连第12页，共145页。测试工作量太少的测试是不负责任，过多的测试是一种犯罪。100％的测试是不可能的，不同的

用户采用的测试策略是不同的。第13页，共145页。缺陷产生的原因测试原因导致的缺陷：测试目标定义错误在开发生命周期中，错误的选择了测试介入时期选择了低效的测试技术测试人员专业知识培训不够，工作低效计划不够详细，测试的

随意性很大测试人员同开发人员沟通困难第14页，共145页。续……软件方面使用了不完全的或者不正确的判定标准来设计软件。错误的处理了用户的非法操作忽略了对关键数据的输出检查数据问题出现了不完整的数

据，不正确的数据，过期的数据第15页，共145页。测试效果的好坏是组织级的问题有效的测试最好由一个独立的团队来实施。便于确定工作目标便于人员的培养与升迁利于团队建设对质量的忠诚度高利于新技术，新方法

的产生和推广工作职责明确第16页，共145页。测试规划好的测试不是碰巧发生的，而是规划出来的。时间上人员上环境上技术上关系上组织能力上资金上第17页，共145页。结构化测试方法传统的软件开发生命周期：需求，设计，编码，测试，系统维护经验：测试不

应该被局限在单一的阶段大量的系统问题产生在软件开发前期越早进行测试越有效，投入产出比越高第18页，共145页。开发生命周期中的验证活动开发阶段验证活动需求.确定验证步骤.对需求进行评审.产生功能测试用例.确定

需求一致性设计.确定设计信息是否足够.准备结构和功能的测试用例.确定设计的一致性编码.为单元测试产生了结构和功能测试的测试用例.进行了足够的单元测试测试.测试应用系统，着重在功能上安装.为测试过的系统进行产品化的工作维护.修改缺陷并重新测试第19页，共145页。测试策略在测试策略中必须标

明可能存在的风险，这样在测试后的系统中可以有效的降低被标明的风险发生的可能性。测试要素：需要被标明的风险也是我们测试的重点。测试阶段：在整个开发生命周期中，测试工作介入的时期。第20页，共145页。测试要素正确性：数据输入，过程处理和输

出的正确性（IPO）。文件完整性：文件被正确使用，恢复和存储的数据正确。授权：特殊的授权可以执行一个特殊的操作。进程追踪：当进程运行中，程序有能力证实进程在正常工作。系统运行的连续性：当有非致命性问题发生后，系统有能力继续运行关键的任务。服务

水平：系统有紧急情况发生时，要求程序的输出结果不经或进行简单的处理后就可以直接使用。权限控制：防止系统被误用（意外或者有意的）第21页，共145页。测试要素(续……)一致性：确保最终设计和用户需求完全一致可靠性：在规定的时间内都可以正常

运转。易于使用：多数人均感觉易于使用。可维护性：可以很容易的定位问题，并且进行修改。可移植性：数据或者程序易于移至到其它系统上。耦合性：系统中的组件可以很容易的联接。性能：系统资源的占用率，响应时间，并发处理操作性：易于操作（Operator）第22页，共145页。确定测试策略

选择并确定测试要素的等级多数情况下选择3～7个确定开发阶段明确商业风险开发人员，重要用户和测试人员通过评审的方式对这些风险达成一致的意见。把风险列表存放在需求矩阵中矩阵中可以将风险同测试用例对应起来。第23页，共14

5页。测试方法学第24页，共145页。测试方法测试策略测试要素测试阶段测试战略简要描述如何在以后的测试活动中实现测试策略第25页，共145页。确定测试战略流水线的概念输入：标准的入口或者是个可执行的程序执行过程：按照工作分配执行检查过程：确定输出符合预定义的标准输出

：符合现存的标准或者是认可的可交付的版本第26页，共145页。QC和QA质量控制验证产品的正确性，当发现与设计不一致的时候进行纠正。质量保证充当支持执行全面质量管理的角色第27页，共145页。测试涉及

的定义和概念缺陷与需求规格说明书不一致的地方。静态检查确保系统按照组织的标准和过程运行，主要依赖于评审和非运行的手段来检查。动态检查在生命周期中进行测试（运行）第28页，共145页。续……静态测试在不运行程序

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

。白盒测试以系统内部结构和相关知识为基础进行测试。第30页，共145页。为什么缺陷很难被找出？看不到看到但是抓不到典型的缺陷类型需求解释有错误用户定义错了需求需求记录错误设计说明有误编码说明有误程序代码有误数据输入有误测试错误问题修改不正确正确的结果是由于其它

的缺陷产生的第31页，共145页。静态测试需求评审设计评审代码走查代码检查第32页，共145页。动态测试单元测试集成测试系统测试用户的验收测试回归测试第33页，共145页。使用静态和动态测试来进行结构和功能测试

测试阶段执行人静态校验动态校验可行性评审开发人员，用户√需求评审开发人员，用户√设计评审开发人员√单元测试开发人员√集成测试开发人员，用户√系统测试开发人员在用户的协助下完成√验收测试用户√第34页，共145页

。确定测试战术的八个步骤确定并且学习测试策略确定项目开发类型确定软件系统类型确定项目范围鉴别战术风险确定开始测试时会遇到的问题建立系统测试计划建立单元测试计划第35页，共145页。确定并学习测试策略在众多的测试策略中那些是重要的

那些风险是最重要的如果软件不能正常运行时，商业上会有什么损失如果软件不能及时完成，商业上会有什么损失谁是最清楚风险影响的人第36页，共145页。确定项目开发类型传统的系统开发交互式开发/原型法系统维护购买/签约/合同软件项目第37页

，共145页。确定软件系统类型模拟数据采集数据显示流程控制决策&辅助协助图形&图象处理数据库管理诊断软件计算机操作系统传感器和信号处理软件开发工具第38页，共145页。确定项目范围新系统的开发会影响那一个商业

领域与现有系统的接口在现有的系统上开发只是修正Bug？重新设计维护？增加新的功能？对其它系统有无影响？为了减小商业上的风险？第39页，共145页。识别在战术上的风险将策略风险分解成战术风险建立测试计划，定位这些风险将风险分布于各个阶段的测试计划中战术风险

的种类结构风险技术风险工作量的风险第40页，共145页。测试开始时应确定的工作需求阶段确定测试策略确定收集了足够的需求产生功能性的测试用例设计阶段确定设计和需求之间的联系确定进行了足够的设计产生结构和功能的测试用例编码阶段确定和设计之间的联系确定拥有执

行的足够条件产生结构和功能的测试用例第41页，共145页。续……测试阶段确定设计了足够的测试用例测试应用系统已经完成关键资源已经到位安装阶段将测试完成的系统变为产品维护阶段修改和重新测试第42页，共145页。建立计划建立

系统测试计划建立单元测试计划在测试战术上我们要花多长时间？“如果计划作失败了，那就在计划失败”时间花在计划上要比花在重复的测试上有效第43页，共145页。测试的技巧第44页，共145页。测试技巧分类结构测试相对于功能测试动态测试相对于静态测试手工测试相对于自动测试第45页

，共145页。结构测试技巧压力测试执行测试恢复测试操作测试复合性测试（与过程的复合性)安全测试第46页，共145页。压力测试目标模拟出实际用户环境怎么用产生测试数据测试组模拟用户处理被创建的数据例子确定是否

分配了足够的磁盘空间通讯的容量是否足够测试系统过载的情况什么时间使用当关于容量的信息不确定的时候第47页，共145页。性能测试技巧⚫目标–确定系统达到了希望达到的性能水平⚫如何使用–使用软件和硬件的监视器–使用模拟的监控模型，对关心的性能指标进行监控–创建一

个小程序⚫例子–计算通信的时间–单位时间处理的信息量⚫什么时候使用－在程序开发的早期进行第48页，共145页。恢复测试目标当在进行安装或组装操作过程中，文件丢失时或发生意外后系统有能力重新进行操作如何使用程序的安装，运行方式，工具的使用和关键技术经过足够的评估系统开发完毕后，介绍一

下发生失败后的处理过程例子人为的使一个系统在安装或者组装过程中产生错误什么时间去使用当操作的连续性是个重点的时候第49页，共145页。操作测试目标确定计算机的操作文档已经完整如何使用作为计算机正常操作的一部分来执行测试

例子操作的介绍被文档化，操作者被培训什么时候使用预先将程序进行产品化。操作性是系统的一个重要指标的时候。第50页，共145页。复合性测试目标校验程序的开发是否依照已定义的标准，流程和操作方式进行的。如何去使用将文档/程序同标准相比较比较有效的方法是检查过程

例子代码互查（一行一行）什么时候使用依赖于管理的需要第51页，共145页。安全性测试目标安全性的缺陷很难被发现。大多数的情况下组织能够防止一般性的破坏者。如何使用对安全性的需求进行评审分析与安全性有关的处理流程转包给专业的人员例子定义了被保护的资源，权限进行了控

制，日志文件和审查追踪是可用的。什么时间使用当被保护的资源对于组织具有重要的价值的时候第52页，共145页。功能测试技巧需求测试回归测试错误处理测试支持手册的测试系统兼容测试控制性测试并行测试第53页，共145页。需求测试目标用户的

需求可以被实现如何使用创建测试用例和功能检查列表例子建立测试矩阵去证实系统需求均被文档化什么时候使用每一个应用程序都要进行需求测试第54页，共145页。回归测试目标程序修改后，确保功能的正确性如何使用重新测试应用程序中没有改变的部分例子重新执行以前的测试用例什么时间使用

当新的程序有可能影响老的功能的时候第55页，共145页。错误处理测试目标所有可能的错误条件均经过了验证如何使用一组有经验的人员预测在那里会出现问题例子建立一个错误处理的列表什么时候使用贯穿

整个开发生命周期第56页，共145页。支持手册测试目标检验操作过程被文档化了，并且完整了。如何使用对过程有足够的介绍可以协助用户正常使用例子系统在一定的条件下产生一个提示，用户被告知如何采取必要的操作。什么时候使用最佳时机是在安装测试的时候，但

是应该在开发全过程中。第57页，共145页。兼容性测试目标检验当使用适当的参数和数据时，需要的信息可以在两个系统中正确的交换如何使用文件和数据被用来在多系统之间传递。例子典型的由一个系统到另一个系统的数

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

的条件都被保护了。什么时候使用系统测试的一部分第59页，共145页。并行测试目的新版本和老版本同时运行，用以确保新版本的程序运行正确。如何使用需要对两个系统输入相同的数据来运行例子运行新旧两个工资支付系统什么时间使用当对新系

统的的运行情况不确定的时候第60页，共145页。单元测试关注单元一级代码分析和测试功能分析和测试结构分析和测试以错误为导向的分析和测试第61页，共145页。测试要素/测试技巧矩阵测试要素压力执行恢复操作复合性安全性需求回归错误处理手工支持系统兼容管理并

行单元可靠性√√√√√授权√√√文件完整性√√√√审查追踪√√√过程连续性√√√√第62页，共145页。继续……测试要素压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元服务水平√√√权限控制√一致性√√√√正确性√√

√√√√√√易用性√√√√可维护性√√兼容性√√耦合性√√√性能√√√√可操作性√√第63页，共145页。测试工具的选择第64页，共145页。测试工具测试标准边界值分析因果图检查表代码比较对照以编译为基础的分析确认/检查控制流分析第65页，共145页。测试工具(继续

……)能证明正确性的数据以覆盖为基础的测试数据字典数据流分析以设计为基础的功能测试设计评审桌面检查灾难性测试第66页，共145页。测试工具(继续……)错误猜测执行的规则全面的测试实况调查

流程图检查,视察使用仪器设备综合测试设备映射图第67页，共145页。测试工具(继续……)建模并行操作并行模拟代码互查风险矩阵系统控制的评审得分快照(把系统一个时刻的情况保存下来)第68页，共145页。测试工具(继续……)完成特征系统日志测试用例测试用例的产生

形式跟踪工具程序容量的测试走查(讲解开发思路)第69页，共145页。选择和使用测试工具按照用途选择匹配的工具在适当的生命周期选择工具按照测试人员的实际技能选择匹配的工具选择一个可提供的工具第70页，共145页。测试工具/

测试技巧矩阵测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元确认测试标准√√√√边界值分析√√因果图√√√√√检查表√√√√√√√√√√√√代码比较√√编译分析√√确认/检查√√√√√√√√√控制流√证明正确性的数据√√√√√√第71页

，共145页。测试工具/测试技巧矩阵(继续)测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元以覆盖为基础的测试√数据字典√√数据流分析√以设计为基础的功能测试√设计评审√桌面检查√√√√√灾难性测试√√√错误猜测√√√√√√√√√√√√

执行规则√全面的测试√√√√√√√第72页，共145页。测试工具/测试技巧矩阵(继续)测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元实况调查√√√√√√√流程图√√√√√检查√√√√√√√√√√√√√使用仪器√√√√√√√综合测试设备√√√√√√√√映射图√建

模√并行操作√并行模拟√代码互查√√√√√第73页，共145页。测试工具/测试技巧矩阵(继续)测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元风险对照表√√系统控制审计评审√√√打分√系统快照√特征执行√系统日志√√√√√√√测试数据√√√√√√产生测试数据√

√√√√√跟踪√工具程序√√√第74页，共145页。测试工具/测试技巧矩阵(继续)测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元容量测试√走查√√√√√第75页，共145页。软件开发生命周期/测试工具对照表测试工具需求设计编码测试安装维护确认测试标准

√√边界值分析√√因果图√√检查表√√√√√√代码比较√编译分析√基础复杂度量测试√√控制流分析√验证、检查√√√√√√正确性数据√√覆盖测试对照表√√数据字典√第76页，共145页。软件开发生命周期/测试工具对照表(继续）测试工具需求设计编码测试安装维护数据流分析√设计为

基础的功能测试√√设计评审√桌面检查√√√√灾难性测试√√错误猜测√√√√√√执行规范√全面的测试√实况调查√√√√√√流程图√√√检查√√√√√√使用仪器√√√第77页，共145页。软件开发生命周期/测试工具对照表(继续）测试工具需求设计编码

测试安装维护综合测试工具√映射图√模型√√并行操作√并行模拟√代码互查√√√√√√风险列表√√系统控制审计评审√打分√√系统快照√完成特征√系统日志√√√第78页，共145页。软件开发生命周期/测试工具对照表(继

续）测试工具需求设计编码测试安装维护测试用例√√√√测试用例得产生形式√√跟踪√√工具程序√√√容量测试√走查√√√第79页，共145页。测试工具管理工具管理者的职责对工具负责帮助同事使用这些工具培训工具得使用方法负

责同工具的厂家联系每年给出有关工具使用和购买得计划工具得升级工具情况报告工具管理者得任期不易太长第80页，共145页。软件的测试过程第81页，共145页。软件的测试过程估算测试计划需求设计编码测试总结安装，交付维护第

82页，共145页。估算第83页，共145页。估算什么测试对软件工作量的估算的准确性测试评估软件系统的状况的准确性关注点：不准确的估算不适当的开发过程不真实的状态报告第84页，共145页。对工作量的估算如何知道对工作量的估算是正确的估算工作量的工具很容易出错对软件工

作量的估算需要策略五个一般的方法猜加入一些约束条件以一些数据为基础模拟进行工作将一些参数模型化第85页，共145页。参数模型法回归模型：将现有的参数与已有的历史数据相拟和。启发式模型：对历史数据进行观察和解释现象模型：假设软件开发过程

可以依据一些更广泛的可适用的过程解释。第86页，共145页。模型遵循的共同模式估算软件的大小将大小转化成人力的估算，并且作出可能的成本的估算依据项目的特性进行估算的调整将整体的估算划分到不同的项目阶段中估

算不包括技巧上面的人力和计算机的运行时间将以上内容相加第87页，共145页。对估算进行检验检验估算模型的合理性检验模型是否包含了必须的测试要素检验模型的正确性第88页，共145页。校验估算模型的正确性重新进行估

算校验输入是否正确校验输入是否合理校验对数据的计算是否合理有效比较延期的估算是否符合项目实际情况让谨慎的人来作测试验证工作对软件中的冗余价值估算第89页，共145页。影响估算正确与否的因素软

件规模新设计新代码的比例复杂程度设计和编码的困难使用什么语言安全性需求的挥发性第90页，共145页。续……组织因素项目计划人员开发环境计算机资源人员利用率膨胀因素估算就是估算，不是保证书第91页，共

145页。软件进展测试追踪系统的瓶颈工作完成点同配置管理系统紧密的结合如何使用模块列表里程碑工作完成点用计算所有工作的完成度来检查系统工作过程。第92页，共145页。测试计划第93页，共145页。开发测试计划目标详细的

描述怎样能成功的完成测试工作，其中应包含必须的资源和实施计划。可能的不利因素：没有得到足够的培训心里准备不足缺乏测试工具缺乏管理的标准和支持缺乏客户和最终使用者的参与没有足够的时间进行测试对于独立的测试人员过度信任版本改变的太快测试人员

处于不受重视的情况中不能说不第94页，共145页。实施过程听取各方面的意见和建议标明项目风险测试要素联系测试矩阵建立测试计划对计划进行评审第95页，共145页。建立测试计划定义测试目标开发测试矩阵软件模型结构特性

批量测试的阶段和用例为在线系统作概念上的测试脚本软件测试矩阵定义测试管理测试计划的一般性信息定义测试里程碑定义管理上的检查点书写测试计划第96页，共145页。评审测试计划涉及评审的问题评审测试的开始时间是否会延期有没有抵触评审的角

色一段时间内是否很难得到工作的检查信息。更换工具有可能导致他们反感评审工作评审结果可能会影响对个人的工作评价对于最终成品的检查项目的需求规格说明书软件返工/维护的文档升级后的技术文档被更改的源程序测试计划用户手册（包括在线帮助）第97页，共145页。续……正式评

审中的角色缓和剂（SQA）读者记录者作者检测员正式评审发现的缺陷应包含的信息起因类型分类级别第98页，共145页。评审流程计划和组织通篇的讲解（可选）个人准备评审会议修订和反复第99页，共145页。需求阶段的测试第100页，共145页

。测试成本在软件开发的所有阶段进行测试被设计用来减少测试成本IBM的数据大约60个缺陷/千行2/3的缺陷产生在需求和设计阶段在需求和设计阶段发现的缺陷修正的花费最小修正系统测试阶段发现的缺陷，花费是以上的10倍发布产品以后，修正缺

陷的花费是原来的100倍第101页，共145页。生命周期的测试概念在软件开发过程中持续的进行测试在尽可能早的阶段点去修正缺陷需要正式的开发流程来支持组建测试团队当开发开始进行的时候，测试就开始进行了第102页，共145页。需求阶段的测试

准备风险列表确定风险组确定风险风险分析风险检查表建立控制目标确定有足够的控制力度第103页，共145页。分析测试要素需求的设计是否遵循了已定义的方法提交了已定义的功能说明定义了系统界面已经估计了性能标准容忍度被预先估计预先定义了权限规则需求中预先定义了文件完整性

预先定义了需求的变更流程预先定义了失败的影响权限定义第104页，共145页。需求走查建立基本规则选择小组/通报参与者项目介绍问题/建议形成最终报告第105页，共145页。需求阶段测试所有的花费都是值得的大部分缺陷将不

会进入到设计&编码阶段目标需求正确的表现出了用户的需要需求已经被定义和文档化了花费和收益成正比需求的控制被明确有合理的流程可遵循有合理的方法可供选择第106页，共145页。设计阶段的测试第107页，共145页。

设计阶段的测试交付的产品输入说明过程说明文件说明输出说明控制说明系统流程图硬件和软件的需求操作手册说明书数据保留的策略第108页，共145页。设计阶段测试任务给测试要素打分分析测试要素对设计

进行评审检查修改的部分第109页，共145页。分析测试要素测试涉及的内容：设计了对数据完整性的控制设计了权限规则设计了对文件完整性的控制设计了审计追踪设计了发生意外情况时的计划设计了如何达到

服务水平的方法定义了权限流程定义了完整的方法学设计了保证需求一致性的方法进行了易用性的设计设计是可维护的设计是简单的交互界面设计完毕定义了成功的标准需要同实际操作者沟通第110页，共145页。对设计进行评审选择评审组成员对评审组进行培训通报

项目组分配足够的时间只对文档化的事实进行评审和项目组一起进行评审对评审形成建议和项目组对建议一起进行评审准备正式的报告第111页，共145页。编码阶段的测试第112页，共145页。形成的输

出编码说明书程序文档计算机程序列表可执行的程序程序流程图操作介绍单元测试结果第113页，共145页。测试活动的关注点完成对数据完整性的控制定义完毕授权的规则完成对文件完整性的控制实现审计

追踪规划出意外情况发生后的处理计划对系统如何达到预定义的服务水平做了计划完成了对安全问题的处理流程编码工作是依据规定的方法完成的编码与设计相一致（正确性）编码与设计相一致（易用性）代码是可维护的编码与设计相一

致（简洁性）编码与设计相一致（耦合性）已开发了操作流程定义出程序成功的标准（性能上）第114页，共145页。测试的职责编码是一个纯技术的工作，几乎不需要用户的参与项目领导者有参与测试的责任监督过程的

有效性第115页，共145页。建议的测试方式桌面调试语法上的结构上的功能上的代码互查建立基本的互查规则选择互查的team对成员进行培训选择互查的方法提供互查的材料流程图，源程序，典型的处理流程对互查进行必要的管理给出互查结论提供最终的报告第116页，共145页。编

码阶段的测试需解决的问题系统是可维护的吗？系统说明是否已经完成了？编码是否按照既有的标准进行，过程是否易于实践？是否有足够的测试计划用来评估可执行的程序？是否编制了足够的文档。第117页，共145页。测试关注点在需求，设计，编码阶段多进行一些测试，在系统测试阶段就会

少一些问题。文档测试阶段的测试计划测试用例前期测试的测试结果第三方测试反馈，例如：计算机操作人员正式的测试总结报告第118页，共145页。典型测试类型手册，回归，功能点测试一致性测试（授权）功能点测试（完整性）功能点测

试（审计，追踪）覆盖性的测试（测试的连续性）压力测试（服务水平）一致性测试（安全性）依照预先定义的测试方法功能点测试（正确性）支持手册的测试（易用性）检查（可维护性）灾难性的测试（可携带性）功能和回归测试（耦合性）一致性的测试（

性能）操作性的测试（易用性）第119页，共145页。建议测试方法测试方法测试用例的概念是简单的建立有效的测试用例是复杂的设计测试文件测试用例应当包含合法的和非法的输入每一个动作只进行一次关键操作输入测试数据分析结果尝试将测试文件违反程序的规则进行输入容量测试的测试工具

以大信息量的数据进行输入这是一个昂贵的测试，应根据需要来选择在线系统需要做压力测试第120页，共145页。测试总结第121页，共145页。测试报告目标表示出目前项目的实际状况明确什么是测试做的工作，什么是不作的工作。

给出系统的操作性能的评价明确什么时候系统可以进行产品化的工作关注点测试报告只有真正需要的时候才有用，需要配合市场和管理测试的信息是不充分的（对于评价一个项目来说）测试状况并不能真实的反应个人的状况第122页，共145页。测试期间数据的收集有关测试结果的积累数据

测试任务，测试集合和测试事件的描述缺陷分析由于计划的问题，导致没有发现的缺陷的数据严重的缺陷缺陷类型为什么缺陷没有发现效果第123页，共145页。测试报告报告目前的软件状态功能/测试矩阵功能测试的状态报

告，侧重点分析关于功能的工作时间轴期望发现VS实际发现的缺陷比没有发现的缺陷和改正的缺陷的差距按照类型分类，没有改正的缺陷的平均值缺陷分类报告测试活动报告第124页，共145页。最终的报告汇总各个阶段的项目测试总结报告继承性测试报告系统测试报告确认测试报告第125页，共145页

。安装测试第126页，共145页。安装阶段的测试准备安装计划安装流程图安装文件和程序清单测试安装程序给出测试结果将程序运行的软硬件要求放入产品说明中对于新操作人员的使用说明书对于新使用者的操作说明和操作流程安装过程中的各项可能发生

的结果的说明第127页，共145页。测试关注点对程序安装的正确性和完整性进行核对校验产品文件的完整性安装的审查，追踪被记录安装之前，该系统已经被证实没有问题如果安装失败，系统有相应的解决方案安装过程，进行了权限控制（安全性）

安装遵循一定的方法，步骤需要的配套程序和数据已经放进了产品中已交付使用说明相关文件已经完整(可维护性）接口已经被合理调整（耦合性）综合的性能达到了用户要求第128页，共145页。建议测试工具测试工具检查表选

择测试的范围选择检查表明白这些问题的用意提前测试用户的检查表使用该检查表模拟运行一遍自己向自己汇报一次将有用的信息记录下来评估检查表和检查流程第129页，共145页。续……测试标准数据的正确性将程序产品化向操作者和

用户进行讲解校验检查表和产品的正确性使用测试标准去检验发生的问题第130页，共145页。验收测试第131页，共145页。软件验收流程定义用户角色定义验收标准编制验收计划执行验收计划填写验收结论第132页，共145页。定义用户角色确定最终用户的范围确认临时的和最终产品

的验收标准计划每一个验收过程由谁和如何执行计划资源分配计划时间分配准备验收计划为每一项验收工作给出结论第133页，共145页。确定验收标准功能上性能上接口质量上过载后的软件质量安全性软件的稳定性第134页，共145页。编写验收计划项目

描述用户职责行政上的流程验收活动描述每一个验收项的评审最终的验收测试步骤第135页，共145页。执行和结论执行验收计划验收测试和评审进行管理验收的结果典型的验收结果在进入下一个活动之前问题或者变更必须被接受工作可以继续，但是下次评审之前必须更正没有任何的更

改第136页，共145页。维护阶段第137页，共145页。工作重点和目标两个重要的工作：测试和培训目标：开发一些测试用例，预先发现一些问题在运行情况发生变化后，预先的修正一些错误编写必要的培训材料对有关的人员进行培训同用户进行接触第138页，共145页。开发更新测试计划测试

计划要简短，必须在短时间内完成。只测试变化的部分两点：测试什么，如何测试测试要素变化的数据交换变化的程序操作流程用户的操作习惯不同系统之间的互联语言版本安全性备份/恢复第139页，共145页。编制培训计划对系统进行概览对系统假定一些错误，给出处理方法

培训材料对项目内容的陈述用户使用方法对错误列表上的问题给出解释对报告进行解释，并且说明如何使用他们（图标，数据等）对输入数据进行解释第140页，共145页。反馈反馈包括：用户反馈和测试反馈，又分成错误和建议。没有反馈意见，程

序很难提高反馈的类型测试的数量和内容发现的问题数量和分类区分是技术上的还是应用上的问题将反馈信息重新整理，加入到相关的测试数据中第141页，共145页。实例讲解测试活动在软件工程中的应用第142页，共145页。活动阶段分类需求阶段设计阶段编码

阶段集成测试阶段系统测试阶段验收测试阶段产品化发货阶段第143页，共145页。阶段流程图总体流程图需求阶段测试工作流程设计&编码阶段测试工作流程集成，系统，验收测试阶段第144页，共145页。谢谢第145页，共145页。