软件测试培训推荐PPT145.ppt

软件测试培训1培训列表ü软件测试的目的和策略ü测试方法学ü测试的技巧ü测试工具的选择ü软件开发中的测试过程ü实例讲解测试活动在软件工程中的应用2软件测试的目的和策略3典型测试步骤1.计划： 定义目标确定策略确定方法2.执行： 建立环境执行计划3.检查：一步步验证执行完毕？4.循环：没有改正继续执行4谁参与测试？w用户方代表w软件最终使用者w软件开发人员w软件测试人员w高层经理的支持w过程保证人员（SQA）5什么试缺陷？w缺陷：最终产品同用户的期望不一致w缺陷的分类ª错误ª遗漏ª超出需求的部分w缺陷（未触发）VS.错误（应首先解决）6测试的商业意义w降低风险（风险：就是不希望发生的事情的可能性）w测试计划中必须标明商业上的风险w测试人员职责：ª评估商业上的风险ª如实的向管理层汇报项目情况7目前公司内测试组织的等级w测试是一件艺术品，很难掌握w测试是一门手艺，精通很困难w测试使用的是已定义好的测试流程，有规则可寻w测试有较高级的组织形式w世界级的测试组织8测试的职责ª验证在整个软件开发周期中，各个阶段的软件质量是否合格ª验证最终交付给用户的系统是否满足用户的需要，是否符合需求。

ª通过样本测试数据，检查系统在运行过程中的情况9对待可能产生的风险的策略w我们无法消除风险，但是我们可以降低在风险发生时的损失w降低系统风险的最有效的办法就是对其进行有针对性的测试10系统风险列举w如果某部分产生了错误会导致的结果？w未被验证的数据交换如果被接受w如果文件的完整性被破坏w系统是否能被安全恢复（完全恢复成备份时的状态）w是否能暂停系统的运行w进行维护工作时，系统性能是否会下降到不能接受的水平w系统的安全性是否有保证11系统风险列举（继续……）w系统的操作流程是否符合用户的组织策略和长远规划w系统是否可靠，稳定w系统是否易于使用w系统是否便于维护w是否易于与其它系统相连12测试工作量w太少的测试是不负责任，过多的测试是一种犯罪w100％的测试是不可能的，不同的用户采用的测试策略是不同的13缺陷产生的原因w测试原因导致的缺陷：ª测试目标定义错误ª在开发生命周期中，错误的选择了测试介入时期ª选择了低效的测试技术ª测试人员专业知识培训不够，工作低效ª计划不够详细，测试的随意性很大ª测试人员同开发人员沟通困难14续……w软件方面ª使用了不完全的或者不正确的判定标准来设计软件。

ª错误的处理了用户的非法操作ª忽略了对关键数据的输出检查w数据问题ª出现了不完整的数据，不正确的数据，过期的数据15测试效果的好坏是组织级的问题w有效的测试最好由一个独立的团队来实施ª便于确定工作目标ª便于人员的培养与升迁ª利于团队建设ª对质量的忠诚度高ª利于新技术，新方法的产生和推广ª工作职责明确16测试规划w好的测试不是碰巧发生的，而是规划出来的ª时间上ª人员上ª环境上ª技术上ª关系上ª组织能力上ª资金上17结构化测试方法w传统的软件开发生命周期：ª需求，设计，编码，测试，系统维护经验经验：ª测试不应该被局限在单一的阶段ª大量的系统问题产生在软件开发前期ª越早进行测试越有效，投入产出比越高18开发生命周期中的验证活动开发阶段开发阶段验证活动验证活动需求.确定验证步骤.对需求进行评审.产生功能测试用例.确定需求一致性设计.确定设计信息是否足够.准备结构和功能的测试用例.确定设计的一致性编码.为单元测试产生了结构和功能测试的测试用例.进行了足够的单元测试测试.测试应用系统，着重在功能上安装.为测试过的系统进行产品化的工作维护.修改缺陷并重新测试19测试策略w在测试策略中必须标明可能存在的风险，这样在测试后的系统中可以有效的降低被标明的风险发生的可能性。

ª测试要素：需要被标明的风险也是我们测试的重点ª测试阶段：在整个开发生命周期中，测试工作介入的时期20测试要素w正确性：数据输入，过程处理和输出的正确性（IPO）w文件完整性：文件被正确使用，恢复和存储的数据正确w授权：特殊的授权可以执行一个特殊的操作w进程追踪：当进程运行中，程序有能力证实进程在正常工作w系统运行的连续性：当有非致命性问题发生后，系统有能力继续运行关键的任务w服务水平：系统有紧急情况发生时，要求程序的输出结果不经或进行简单的处理后就可以直接使用w权限控制：防止系统被误用（意外或者有意的）21测试要素(续……)w一致性：确保最终设计和用户需求完全一致w可靠性：在规定的时间内都可以正常运转w易于使用：多数人均感觉易于使用w可维护性：可以很容易的定位问题，并且进行修改w可移植性：数据或者程序易于移至到其它系统上w耦合性：系统中的组件可以很容易的联接w性能：系统资源的占用率，响应时间，并发处理w操作性：易于操作（Operator）22确定测试策略w选择并确定测试要素的等级ª多数情况下选择3～7个w确定开发阶段w明确商业风险ª开发人员，重要用户和测试人员通过评审的方式对这些风险达成一致的意见。

w把风险列表存放在需求矩阵中ª矩阵中可以将风险同测试用例对应起来23测试方法学24测试方法w测试策略ª测试要素ª测试阶段w测试战略ª简要描述如何在以后的测试活动中实现测试策略25确定测试战略w流水线的概念ª输入：标准的入口或者是个可执行的程序ª执行过程：按照工作分配执行ª检查过程：确定输出符合预定义的标准ª输出：符合现存的标准或者是认可的可交付的版本26QC和QAw质量控制ª验证产品的正确性，当发现与设计不一致的时候进行纠正w质量保证ª充当支持执行全面质量管理的角色27测试涉及的定义和概念w缺陷ª与需求规格说明书不一致的地方w静态检查ª确保系统按照组织的标准和过程运行，主要依赖于评审和非运行的手段来检查w动态检查ª在生命周期中进行测试（运行）28续……w静态测试ª在不运行程序的情况下检查程序的运行情况w动态测试ª运行程序代码w测试分类ª单元测试ª集成测试（组装测试）ª系统测试ª验收测试ª回归测试29续……w功能测试ª测试功能需求w结构测试ª验证系统架构w黑盒测试ª在不了解系统结构的情况下以说明书作为基础进行测试w白盒测试ª以系统内部结构和相关知识为基础进行测试30为什么缺陷很难被找出？w看不到w看到但是抓不到w典型的缺陷类型ª需求解释有错误ª用户定义错了需求ª需求记录错误ª设计说明有误ª编码说明有误ª程序代码有误ª数据输入有误ª测试错误ª问题修改不正确ª正确的结果是由于其它的缺陷产生的31静态测试w需求评审w设计评审w代码走查w代码检查32动态测试w单元测试w集成测试w系统测试w用户的验收测试w回归测试33使用静态和动态测试来进行结构和功能测试34确定测试战术的八个步骤w确定并且学习测试策略w确定项目开发类型w确定软件系统类型w确定项目范围w鉴别战术风险w确定开始测试时会遇到的问题w建立系统测试计划w建立单元测试计划35确定并学习测试策略w在众多的测试策略中那些是重要的w那些风险是最重要的w如果软件不能正常运行时，商业上会有什么损失w如果软件不能及时完成，商业上会有什么损失w谁是最清楚风险影响的人36确定项目开发类型w传统的系统开发w交互式开发/原型法w系统维护w购买/签约/合同软件项目37确定软件系统类型模拟数据采集数据显示流程控制决策&辅助协助图形&图象处理数据库管理诊断软件计算机操作系统传感器和信号处理软件开发工具38确定项目范围w新系统的开发ª会影响那一个商业领域ª与现有系统的接口w在现有的系统上开发ª只是修正Bug？ª重新设计维护？ª增加新的功能？ª对其它系统有无影响？ª为了减小商业上的风险？39识别在战术上的风险w将策略风险分解成战术风险ª建立测试计划，定位这些风险ª将风险分布于各个阶段的测试计划中w战术风险的种类ª结构风险ª技术风险ª工作量的风险40测试开始时应确定的工作w需求阶段ª确定测试策略ª确定收集了足够的需求ª产生功能性的测试用例w设计阶段ª确定设计和需求之间的联系ª确定进行了足够的设计ª产生结构和功能的测试用例w编码阶段ª确定和设计之间的联系ª确定拥有执行的足够条件ª产生结构和功能的测试用例41续……w测试阶段ª确定设计了足够的测试用例ª测试应用系统已经完成ª关键资源已经到位w安装阶段ª将测试完成的系统变为产品w维护阶段ª修改和重新测试42建立计划w建立系统测试计划w建立单元测试计划w在测试战术上我们要花多长时间？ª“如果计划作失败了，那就在计划失败”ª时间花在计划上要比花在重复的测试上有效43测试的技巧44测试技巧分类w结构测试相对于功能测试w动态测试相对于静态测试w手工测试相对于自动测试45结构测试技巧w压力测试w执行测试w恢复测试w操作测试w复合性测试（与过程的复合性)w安全测试46压力测试w目标ª模拟出实际用户环境w怎么用ª产生测试数据ª测试组模拟用户处理被创建的数据w例子ª确定是否分配了足够的磁盘空间ª通讯的容量是否足够ª测试系统过载的情况w什么时间使用ª当关于容量的信息不确定的时候47性能测试技巧l目标–确定系统达到了希望达到的性能水平l如何使用–使用软件和硬件的监视器–使用模拟的监控模型，对关心的性能指标进行监控–创建一个小程序l例子–计算通信的时间–单位时间处理的信息量l什么时候使用－ 在程序开发的早期进行48恢复测试w目标ª当在进行安装或组装操作过程中，文件丢失时或发生意外后系统有能力重新进行操作w如何使用ª程序的安装，运行方式，工具的使用和关键技术经过足够的评估ª系统开发完毕后，介绍一下发生失败后的处理过程w例子ª人为的使一个系统在安装或者组装过程中产生错误w什么时间去使用ª当操作的连续性是个重点的时候49操作测试w目标ª确定计算机的操作文档已经完整w如何使用ª作为计算机正常操作的一部分来执行测试w例子ª操作的介绍被文档化，操作者被培训w什么时候使用ª预先将程序进行产品化。

操作性是系统的一个重要指标的时候50复合性测试w目标ª校验程序的开发是否依照已定义的标准，流程和操作方式进行的w如何去使用ª将文档/程序同标准相比较ª比较有效的方法是检查过程w例子ª代码互查（一行一行）w什么时候使用ª依赖于管理的需要51安全性测试w目标ª安全性的缺陷很难被发现ª大多数的情况下组织能够防止一般性的破坏者w如何使用ª对安全性的需求进行评审ª分析与安全性有关的处理流程ª转包给专业的人员w例子ª定义了被保护的资源，权限进行了控制，日志文件和审查追踪是可用的w什么时间使用ª当被保护的资源对于组织具有重要的价值的时候52功能测试技巧w需求测试w回归测试w错误处理测试w支持手册的测试w系统兼容测试w控制性测试w并行测试53需求测试w目标ª用户的需求可以被实现w如何使用ª创建测试用例和功能检查列表w例子ª建立测试矩阵去证实系统需求均被文档化w什么时候使用ª每一个应用程序都要进行需求测试54回归测试w目标ª程序修改后，确保功能的正确性w如何使用ª重新测试应用程序中没有改变的部分w例子ª重新执行以前的测试用例w什么时间使用ª当新的程序有可能影响老的功能的时候55错误处理测试w目标ª所有可能的错误条件均经过了验证w如何使用ª一组有经验的人员预测在那里会出现问题w例子ª建立一个错误处理的列表w什么时候使用ª贯穿整个开发生命周期56支持手册测试w目标ª检验操作过程被文档化了，并且完整了。

w如何使用ª对过程有足够的介绍ª可以协助用户正常使用w例子ª系统在一定的条件下产生一个提示，用户被告知如何采取必要的操作w什么时候使用ª最佳时机是在安装测试的时候，但是应该在开发全过程中57兼容性测试w目标ª检验当使用适当的参数和数据时，需要的信息可以在两个系统中正确的交换w如何使用ª文件和数据被用来在多系统之间传递w例子ª典型的由一个系统到另一个系统的数据交换程序w什么时候使用ª当两个应用程序之间的参数有可能发生变化的时候58管理能力测试w目标ª验证数据交换时有足够的审计追踪能力w如何使用ª关键数据或者有价值的数据w例子ª从负面来看程序，是否确保了会出错的条件都被保护了w什么时候使用ª系统测试的一部分59并行测试w目的ª新版本和老版本同时运行，用以确保新版本的程序运行正确w如何使用ª需要对两个系统输入相同的数据来运行w例子ª运行新旧两个工资支付系统w什么时间使用ª当对新系统的的运行情况不确定的时候60单元测试w关注单元一级w代码分析和测试w功能分析和测试w结构分析和测试w以错误为导向的分析和测试61测试要素/测试技巧矩阵62继续……63测试工具的选择64测试工具w测试标准w边界值分析w因果图w检查表w代码比较对照w以编译为基础的分析w确认/检查w控制流分析65测试工具(继续……)w能证明正确性的数据w以覆盖为基础的测试w数据字典w数据流分析w以设计为基础的功能测试w设计评审w桌面检查w灾难性测试66测试工具(继续……)w错误猜测w执行的规则w全面的测试w实况调查w流程图w检查,视察w使用仪器设备w综合测试设备w映射图67测试工具(继续……)w建模w并行操作w并行模拟w代码互查w风险矩阵w系统控制的评审w得分w快照(把系统一个时刻的情况保存下来)68测试工具(继续……)w完成特征w系统日志w测试用例w测试用例的产生形式w跟踪w工具程序w容量的测试w走查(讲解开发思路)69选择和使用测试工具w按照用途选择匹配的工具w在适当的生命周期选择工具w按照测试人员的实际技能选择匹配的工具w选择一个可提供的工具70测试工具/测试技巧矩阵71测试工具/测试技巧矩阵(继续)72测试工具/测试技巧矩阵(继续)73测试工具/测试技巧矩阵(继续)74测试工具/测试技巧矩阵(继续)75软件开发生命周期/测试工具对照表76软件开发生命周期/测试工具对照表( 继续）77软件开发生命周期/测试工具对照表( 继续）78软件开发生命周期/测试工具对照表( 继续）79测试工具管理w工具管理者的职责ª对工具负责ª帮助同事使用这些工具ª培训工具得使用方法ª负责同工具的厂家联系ª每年给出有关工具使用和购买得计划ª工具得升级ª工具情况报告w工具管理者得任期不易太长80软件的测试过程81软件的测试过程w估算w测试计划w需求w设计w编码w测试总结w安装，交付w维护82估算83估算什么w测试对软件工作量的估算的准确性w测试评估软件系统的状况的准确性w关注点：ª不准确的估算ª不适当的开发过程ª不真实的状态报告84对工作量的估算w如何知道对工作量的估算是正确的ª估算工作量的工具很容易出错ª对软件工作量的估算需要策略ª五个一般的方法w猜w加入一些约束条件w以一些数据为基础w模拟进行工作w将一些参数模型化85参数模型法w回归模型：将现有的参数与已有的历史数据相拟和。

w启发式模型：对历史数据进行观察和解释w现象模型：假设软件开发过程可以依据一些更广泛的可适用的过程解释86模型遵循的共同模式w估算软件的大小w将大小转化成人力的估算，并且作出可能的成本的估算w依据项目的特性进行估算的调整w将整体的估算划分到不同的项目阶段中w估算不包括技巧上面的人力和计算机的运行时间w将以上内容相加87对估算进行检验w检验估算模型的合理性w检验模型是否包含了必须的测试要素w检验模型的正确性88校验估算模型的正确性w重新进行估算ª校验输入是否正确ª校验输入是否合理ª校验对数据的计算是否合理有效w比较延期的估算是否符合项目实际情况w让谨慎的人来作测试验证工作w对软件中的冗余价值估算89影响估算正确与否的因素w软件规模w新设计新代码的比例w复杂程度w设计和编码的困难w使用什么语言w安全性w需求的挥发性90续……w组织因素ª项目计划ª人员ª开发环境ª计算机资源ª人员利用率ª膨胀因素w估算就是估算，不是保证书91软件进展测试w追踪系统的瓶颈ª工作完成点ª同配置管理系统紧密的结合ª如何使用w模块列表w里程碑w工作完成点ª用计算所有工作的完成度来检查系统工作过程92测试计划93开发测试计划w目标ª详细的描述怎样能成功的完成测试工作，其中应包含必须的资源和实施计划。

w可能的不利因素：ª没有得到足够的培训ª心里准备不足ª缺乏测试工具ª缺乏管理的标准和支持ª缺乏客户和最终使用者的参与ª没有足够的时间进行测试ª对于独立的测试人员过度信任ª版本改变的太快ª测试人员处于不受重视的情况中ª不能说不94实施过程w听取各方面的意见和建议w标明项目风险ª测试要素ª联系测试矩阵w建立测试计划w对计划进行评审95建立测试计划w定义测试目标w开发测试矩阵ª软件模型ª结构特性ª批量测试的阶段和用例ª为系统作概念上的测试脚本ª软件测试矩阵w定义测试管理ª测试计划的一般性信息ª定义测试里程碑ª定义管理上的检查点w书写测试计划96评审测试计划w涉及评审的问题ª评审测试的开始时间是否会延期ª有没有抵触评审的角色ª一段时间内是否很难得到工作的检查信息ª更换工具有可能导致他们反感评审工作ª评审结果可能会影响对个人的工作评价w对于最终成品的检查ª项目的需求规格说明书ª软件返工/维护的文档ª升级后的技术文档ª被更改的源程序ª测试计划ª用户手册（包括帮助）97续……w正式评审中的角色ª缓和剂（SQA）ª读者ª记录者ª作者ª检测员w正式评审发现的缺陷应包含的信息ª起因ª类型ª分类ª级别98评审流程w计划和组织w通篇的讲解（可选）w个人准备w评审会议w修订和反复99需求阶段的测试100测试成本w在软件开发的所有阶段进行测试ª被设计用来减少测试成本wIBM的数据ª大约 60个缺陷/千行ª2/3的缺陷产生在需求和设计阶段w在需求和设计阶段发现的缺陷修正的花费最小w修正系统测试阶段发现的缺陷，花费是以上的10倍w发布产品以后，修正缺陷的花费是原来的100倍101生命周期的测试概念w在软件开发过程中持续的进行测试w在尽可能早的阶段点去修正缺陷w需要正式的开发流程来支持w组建测试团队w当开发开始进行的时候，测试就开始进行了102需求阶段的测试w准备风险列表ª确定风险组ª确定风险w风险分析w风险检查表ª建立控制目标ª确定有足够的控制力度103分析测试要素w需求的设计是否遵循了已定义的方法w提交了已定义的功能说明w定义了系统界面w已经估计了性能标准w容忍度被预先估计w预先定义了权限规则w需求中预先定义了文件完整性w预先定义了需求的变更流程w预先定义了失败的影响w权限定义104需求走查w建立基本规则w选择小组/通报参与者w项目介绍w问题/建议w形成最终报告105需求阶段测试w所有的花费都是值得的w大部分缺陷将不会进入到设计&编码阶段w目标ª需求正确的表现出了用户的需要ª需求已经被定义和文档化了ª花费和收益成正比ª需求的控制被明确ª有合理的流程可遵循ª有合理的方法可供选择106设计阶段的测试107设计阶段的测试w交付的产品ª输入说明ª过程说明ª文件说明ª输出说明ª控制说明ª系统流程图ª硬件和软件的需求ª操作手册说明书ª数据保留的策略108设计阶段测试任务w给测试要素打分w分析测试要素w对设计进行评审w检查修改的部分109分析测试要素w测试涉及的内容：ª设计了对数据完整性的控制ª设计了权限规则ª设计了对文件完整性的控制ª设计了审计追踪ª设计了发生意外情况时的计划ª设计了如何达到服务水平的方法ª定义了权限流程ª定义了完整的方法学ª设计了保证需求一致性的方法ª进行了易用性的设计ª设计是可维护的ª设计是简单的ª交互界面设计完毕ª定义了成功的标准ª需要同实际操作者沟通110对设计进行评审w选择评审组成员w对评审组进行培训w通报项目组w分配足够的时间w只对文档化的事实进行评审w和项目组一起进行评审w对评审形成建议w和项目组对建议一起进行评审w准备正式的报告111编码阶段的测试112形成的输出w编码说明书w程序文档w计算机程序列表w可执行的程序w程序流程图w操作介绍w单元测试结果113测试活动的关注点ª完成对数据完整性的控制ª定义完毕授权的规则ª完成对文件完整性的控制ª实现审计追踪ª规划出意外情况发生后的处理计划ª对系统如何达到预定义的服务水平做了计划ª完成了对安全问题的处理流程ª编码工作是依据规定的方法完成的ª编码与设计相一致（正确性）ª编码与设计相一致（易用性）ª代码是可维护的ª编码与设计相一致（简洁性）ª编码与设计相一致（耦合性）ª已开发了操作流程ª定义出程序成功的标准（性能上）114测试的职责w编码是一个纯技术的工作，几乎不需要用户的参与w项目领导者有参与测试的责任w监督过程的有效性115建议的测试方式w桌面调试ª语法上的ª结构上的ª功能上的w代码互查ª建立基本的互查规则ª选择互查的teamª对成员进行培训ª选择互查的方法ª提供互查的材料w流程图，源程序，典型的处理流程ª对互查进行必要的管理ª给出互查结论ª提供最终的报告116编码阶段的测试需解决的问题w系统是可维护的吗？w系统说明是否已经完成了？w编码是否按照既有的标准进行，过程是否易于实践？w是否有足够的测试计划用来评估可执行的程序？w是否编制了足够的文档。

117测试关注点w在需求，设计，编码阶段多进行一些测试，在系统测试阶段就会少一些问题w文档ª测试阶段的测试计划ª测试用例ª前期测试的测试结果ª第三方测试反馈，例如：计算机操作人员ª正式的测试总结报告118典型测试类型w手册，回归，功能点测试w一致性测试（授权）w功能点测试（完整性）w功能点测试（审计，追踪）w覆盖性的测试（测试的连续性）w压力测试（服务水平）w一致性测试（安全性）w依照预先定义的测试方法w功能点测试（正确性）w支持手册的测试（易用性）w检查（可维护性）w灾难性的测试（可携带性）w功能和回归测试（耦合性）w一致性的测试（性能）w操作性的测试（易用性）119建议测试方法w测试方法ª测试用例的概念是简单的ª建立有效的测试用例是复杂的ª设计测试文件w测试用例应当包含合法的和非法的输入w每一个动作只进行一次关键操作ª输入测试数据ª分析结果ª尝试将测试文件违反程序的规则进行输入w容量测试的测试工具ª以大信息量的数据进行输入ª这是一个昂贵的测试，应根据需要来选择ª系统需要做压力测试120测试总结121测试报告w目标ª表示出目前项目的实际状况ª明确什么是测试做的工作，什么是不作的工作。

ª给出系统的操作性能的评价ª明确什么时候系统可以进行产品化的工作w关注点ª测试报告只有真正需要的时候才有用，需要配合市场和管理ª测试的信息是不充分的（对于评价一个项目来说）ª测试状况并不能真实的反应个人的状况122测试期间数据的收集w有关测试结果的积累数据w测试任务，测试集合和测试事件的描述w缺陷分析ª由于计划的问题，导致没有发现的缺陷的数据ª严重的缺陷ª缺陷类型ª为什么缺陷没有发现w效果123测试报告w报告目前的软件状态ª功能/测试矩阵ª功能测试的状态报告，侧重点分析ª关于功能的工作时间轴ª期望发现 VS 实际发现的缺陷比ª没有发现的缺陷和改正的缺陷的差距ª按照类型分类，没有改正的缺陷的平均值ª缺陷分类报告ª测试活动报告124最终的报告汇总w各个阶段的项目测试总结报告w继承性测试报告w系统测试报告w确认测试报告125安装测试126安装阶段的测试准备w安装计划w安装流程图w安装文件和程序清单w测试安装程序给出测试结果w将程序运行的软硬件要求放入产品说明中w对于新操作人员的使用说明书w对于新使用者的操作说明和操作流程w安装过程中的各项可能发生的结果的说明127测试关注点w对程序安装的正确性和完整性进行核对w校验产品文件的完整性w安装的审查，追踪被记录w安装之前，该系统已经被证实没有问题w如果安装失败，系统有相应的解决方案w安装过程，进行了权限控制（安全性）w安装遵循一定的方法，步骤w需要的配套程序和数据已经放进了产品中w已交付使用说明w相关文件已经完整(可维护性）w接口已经被合理调整（耦合性）w综合的性能达到了用户要求128建议测试工具w测试工具检查表ª选择测试的范围ª选择检查表ª明白这些问题的用意ª提前测试用户的检查表ª使用该检查表模拟运行一遍ª自己向自己汇报一次ª将有用的信息记录下来ª评估检查表和检查流程129续……w测试标准ª数据的正确性w将程序产品化w向操作者和用户进行讲解w校验检查表和产品的正确性w使用测试标准去检验发生的问题130验收测试131软件验收流程w定义用户角色w定义验收标准w编制验收计划w执行验收计划w填写验收结论132定义用户角色w确定最终用户的范围w确认临时的和最终产品的验收标准w计划每一个验收过程由谁和如何执行w计划资源分配w计划时间分配w准备验收计划w为每一项验收工作给出结论133确定验收标准w功能上w性能上w接口质量上w过载后的软件质量w安全性w软件的稳定性134编写验收计划w项目描述w用户职责w行政上的流程w验收活动描述w每一个验收项的评审w最终的验收测试步骤135执行和结论w执行验收计划ª验收测试和评审进行管理w验收的结果ª典型的验收结果w在进入下一个活动之前问题或者变更必须被接受w工作可以继续，但是下次评审之前必须更正w没有任何的更改136维护阶段137工作重点和目标w两个重要的工作：测试和培训w目标：ª开发一些测试用例，预先发现一些问题ª在运行情况发生变化后，预先的修正一些错误ª编写必要的培训材料ª对有关的人员进行培训ª同用户进行接触138开发更新测试计划w测试计划要简短，必须在短时间内完成。

w只测试变化的部分w两点：测试什么，如何测试w测试要素ª变化的数据交换ª变化的程序ª操作流程ª用户的操作习惯ª不同系统之间的互联ª语言版本ª安全性ª备份/恢复139编制培训计划w对系统进行概览w对系统假定一些错误，给出处理方法w培训材料ª对项目内容的陈述ª用户使用方法ª对错误列表上的问题给出解释ª对报告进行解释，并且说明如何使用他们（图标，数据等）ª对输入数据进行解释140反馈w反馈包括：用户反馈和测试反馈，又分成错误和建议w没有反馈意见，程序很难提高w反馈的类型ª测试的数量和内容ª发现的问题数量和分类ª区分是技术上的还是应用上的问题w将反馈信息重新整理，加入到相关的测试数据中141实例讲解测试活动在软件工程中的应用142活动阶段分类w需求阶段w设计阶段w编码阶段w集成测试阶段w系统测试阶段w验收测试阶段w产品化发货阶段143阶段流程图w总体流程图w需求阶段测试工作流程w设计&编码阶段测试工作流程w集成，系统，验收测试阶段144谢谢145。