软件测试培训说课材料.ppt

《软件测试培训说课材料.ppt》由会员分享，可在线阅读，更多相关《软件测试培训说课材料.ppt（145页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件测试培训软件测试的目的和策略典型测试步骤1.计划：定义目标确定策略确定方法2.执行：建立环境执行计划3.检查：一步步验证执行完毕？4.循环：没有改正继续执行谁参与测试？w用户方代表w软件最终使用者w软件开发人员w软件测试人员w高层经理的支持w过程保证人员（SQA）什么试缺陷？w缺陷：最终产品同用户的期望不一致w缺陷的分类错误遗漏超出需求的部分w缺陷（未触发）VS.错误（应首先解决）测试的商业意义w降低风险（风险：就是不希望发生的事情的可能性）w测试计划中必须标明商业上的风险。w测试人员职责：评估商业上的风险如实的向管理层汇报项目情况目前公司内测试组织的等级w测试是一件艺术品，很难掌握。w测

2、试是一门手艺，精通很困难。w测试使用的是已定义好的测试流程，有规则可寻。w测试有较高级的组织形式。w世界级的测试组织。测试的职责验证在整个软件开发周期中，各个阶段的软件质量是否合格。验证最终交付给用户的系统是否满足用户的需要，是否符合需求。通过样本测试数据，检查系统在运行过程中的情况。对待可能产生的风险的策略w我们无法消除风险，但是我们可以降低在风险发生时的损失。w降低系统风险的最有效的办法就是对其进行有针对性的测试。系统风险列举w如果某部分产生了错误会导致的结果？w未被验证的数据交换如果被接受w如果文件的完整性被破坏w系统是否能被安全恢复（完全恢复成备份时的状态）w是否能暂停系统的运行w进行

3、维护工作时，系统性能是否会下降到不能接受的水平。w系统的安全性是否有保证系统风险列举（继续）w系统的操作流程是否符合用户的组织策略和长远规划w系统是否可靠，稳定w系统是否易于使用w系统是否便于维护w是否易于与其它系统相连测试工作量w太少的测试是不负责任，过多的测试是一种犯罪。w100的测试是不可能的，不同的用户采用的测试策略是不同的。缺陷产生的原因w测试原因导致的缺陷：测试目标定义错误在开发生命周期中，错误的选择了测试介入时期选择了低效的测试技术测试人员专业知识培训不够，工作低效计划不够详细，测试的随意性很大测试人员同开发人员沟通困难续w软件方面使用了不完全的或者不正确的判定标准来设计软件。错

4、误的处理了用户的非法操作忽略了对关键数据的输出检查w数据问题出现了不完整的数据，不正确的数据，过期的数据测试效果的好坏是组织级的问题w有效的测试最好由一个独立的团队来实施。便于确定工作目标便于人员的培养与升迁利于团队建设对质量的忠诚度高利于新技术，新方法的产生和推广工作职责明确测试规划w好的测试不是碰巧发生的，而是规划出来的。时间上人员上环境上技术上关系上组织能力上资金上结构化测试方法w传统的软件开发生命周期：需求，设计，编码，测试，系统维护经验经验：测试不应该被局限在单一的阶段大量的系统问题产生在软件开发前期越早进行测试越有效，投入产出比越高开发生命周期中的验证活动开发阶段开发阶段验证活动验

5、证活动需求.确定验证步骤.对需求进行评审.产生功能测试用例.确定需求一致性设计.确定设计信息是否足够.准备结构和功能的测试用例.确定设计的一致性编码.为单元测试产生了结构和功能测试的测试用例.进行了足够的单元测试测试.测试应用系统，着重在功能上安装.为测试过的系统进行产品化的工作维护.修改缺陷并重新测试测试策略w在测试策略中必须标明可能存在的风险，这样在测试后的系统中可以有效的降低被标明的风险发生的可能性。测试要素：需要被标明的风险也是我们测试的重点。测试阶段：在整个开发生命周期中，测试工作介入的时期。测试要素w正确性：数据输入，过程处理和输出的正确性（IPO）。w文件完整性：文件被正确使用，

6、恢复和存储的数据正确。w授权：特殊的授权可以执行一个特殊的操作。w进程追踪：当进程运行中，程序有能力证实进程在正常工作。w系统运行的连续性：当有非致命性问题发生后，系统有能力继续运行关键的任务。w服务水平：系统有紧急情况发生时，要求程序的输出结果不经或进行简单的处理后就可以直接使用。w权限控制：防止系统被误用（意外或者有意的）测试要素(续)w一致性：确保最终设计和用户需求完全一致w可靠性：在规定的时间内都可以正常运转。w易于使用：多数人均感觉易于使用。w可维护性：可以很容易的定位问题，并且进行修改。w可移植性：数据或者程序易于移至到其它系统上。w耦合性：系统中的组件可以很容易的联接。w性能：系

7、统资源的占用率，响应时间，并发处理w操作性：易于操作（Operator）确定测试策略w选择并确定测试要素的等级多数情况下选择37个w确定开发阶段w明确商业风险开发人员，重要用户和测试人员通过评审的方式对这些风险达成一致的意见。w把风险列表存放在需求矩阵中矩阵中可以将风险同测试用例对应起来。测试方法学测试方法w测试策略测试要素测试阶段w测试战略简要描述如何在以后的测试活动中实现测试策略确定测试战略w流水线的概念输入：标准的入口或者是个可执行的程序执行过程：按照工作分配执行检查过程：确定输出符合预定义的标准输出：符合现存的标准或者是认可的可交付的版本QC和QAw质量控制验证产品的正确性，当发现与设

8、计不一致的时候进行纠正。w质量保证充当支持执行全面质量管理的角色测试涉及的定义和概念w缺陷与需求规格说明书不一致的地方。w静态检查确保系统按照组织的标准和过程运行，主要依赖于评审和非运行的手段来检查。w动态检查在生命周期中进行测试（运行）续w静态测试在不运行程序的情况下检查程序的运行情况。w动态测试运行程序代码w测试分类单元测试集成测试（组装测试）系统测试验收测试回归测试续w功能测试测试功能需求w结构测试验证系统架构w黑盒测试在不了解系统结构的情况下以说明书作为基础进行测试。w白盒测试以系统内部结构和相关知识为基础进行测试。为什么缺陷很难被找出？w看不到w看到但是抓不到w典型的缺陷类型需求解释

9、有错误用户定义错了需求需求记录错误设计说明有误编码说明有误程序代码有误数据输入有误测试错误问题修改不正确正确的结果是由于其它的缺陷产生的静态测试w需求评审w设计评审w代码走查w代码检查动态测试w单元测试w集成测试w系统测试w用户的验收测试w回归测试使用静态和动态测试来进行结构和功能测试测试阶段测试阶段执行人执行人静态校验静态校验动态校验动态校验可行性评审开发人员，用户需求评审开发人员，用户设计评审开发人员单元测试开发人员集成测试开发人员，用户系统测试开发人员在用户的协助下完成验收测试用户确定测试战术的八个步骤w确定并且学习测试策略w确定项目开发类型w确定软件系统类型w确定项目范围w鉴别战术风险

10、w确定开始测试时会遇到的问题w建立系统测试计划w建立单元测试计划确定并学习测试策略w在众多的测试策略中那些是重要的w那些风险是最重要的w如果软件不能正常运行时，商业上会有什么损失w如果软件不能及时完成，商业上会有什么损失w谁是最清楚风险影响的人确定项目开发类型w传统的系统开发w交互式开发/原型法w系统维护w购买/签约/合同软件项目确定软件系统类型模拟数据采集数据显示流程控制决策&辅助协助图形&图象处理数据库管理诊断软件计算机操作系统传感器和信号处理软件开发工具确定项目范围w新系统的开发会影响那一个商业领域与现有系统的接口w在现有的系统上开发只是修正Bug？重新设计维护？增加新的功能？对其它系统

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

12、术上我们要花多长时间？“如果计划作失败了，那就在计划失败”时间花在计划上要比花在重复的测试上有效测试的技巧测试技巧分类w结构测试相对于功能测试w动态测试相对于静态测试w手工测试相对于自动测试结构测试技巧w压力测试w执行测试w恢复测试w操作测试w复合性测试（与过程的复合性)w安全测试压力测试w目标模拟出实际用户环境w怎么用产生测试数据测试组模拟用户处理被创建的数据w例子确定是否分配了足够的磁盘空间通讯的容量是否足够测试系统过载的情况w什么时间使用当关于容量的信息不确定的时候性能测试技巧l目标确定系统达到了希望达到的性能水平l如何使用使用软件和硬件的监视器使用模拟的监控模型，对关心的性能指标进行监

13、控创建一个小程序l例子计算通信的时间单位时间处理的信息量l什么时候使用 在程序开发的早期进行恢复测试w目标当在进行安装或组装操作过程中，文件丢失时或发生意外后系统有能力重新进行操作w如何使用程序的安装，运行方式，工具的使用和关键技术经过足够的评估系统开发完毕后，介绍一下发生失败后的处理过程w例子人为的使一个系统在安装或者组装过程中产生错误w什么时间去使用当操作的连续性是个重点的时候操作测试w目标确定计算机的操作文档已经完整w如何使用作为计算机正常操作的一部分来执行测试w例子操作的介绍被文档化，操作者被培训w什么时候使用预先将程序进行产品化。操作性是系统的一个重要指标的时候。复合性测试w目标校验

14、程序的开发是否依照已定义的标准，流程和操作方式进行的。w如何去使用将文档/程序同标准相比较比较有效的方法是检查过程w例子代码互查（一行一行）w什么时候使用依赖于管理的需要安全性测试w目标安全性的缺陷很难被发现。大多数的情况下组织能够防止一般性的破坏者。w如何使用对安全性的需求进行评审分析与安全性有关的处理流程转包给专业的人员w例子定义了被保护的资源，权限进行了控制，日志文件和审查追踪是可用的。w什么时间使用当被保护的资源对于组织具有重要的价值的时候功能测试技巧w需求测试w回归测试w错误处理测试w支持手册的测试w系统兼容测试w控制性测试w并行测试需求测试w目标用户的需求可以被实现w如何使用创建测

15、试用例和功能检查列表w例子建立测试矩阵去证实系统需求均被文档化w什么时候使用每一个应用程序都要进行需求测试回归测试w目标程序修改后，确保功能的正确性w如何使用重新测试应用程序中没有改变的部分w例子重新执行以前的测试用例w什么时间使用当新的程序有可能影响老的功能的时候错误处理测试w目标所有可能的错误条件均经过了验证w如何使用一组有经验的人员预测在那里会出现问题w例子建立一个错误处理的列表w什么时候使用贯穿整个开发生命周期支持手册测试w目标检验操作过程被文档化了，并且完整了。w如何使用对过程有足够的介绍可以协助用户正常使用w例子系统在一定的条件下产生一个提示，用户被告知如何采取必要的操作。w什么时

16、候使用最佳时机是在安装测试的时候，但是应该在开发全过程中。兼容性测试w目标检验当使用适当的参数和数据时，需要的信息可以在两个系统中正确的交换w如何使用文件和数据被用来在多系统之间传递。w例子典型的由一个系统到另一个系统的数据交换程序。w什么时候使用当两个应用程序之间的参数有可能发生变化的时候管理能力测试w目标验证数据交换时有足够的审计追踪能力w如何使用关键数据或者有价值的数据w例子从负面来看程序，是否确保了会出错的条件都被保护了。w什么时候使用系统测试的一部分并行测试w目的新版本和老版本同时运行，用以确保新版本的程序运行正确。w如何使用需要对两个系统输入相同的数据来运行w例子运行新旧两个工资支

17、付系统w什么时间使用当对新系统的的运行情况不确定的时候单元测试w关注单元一级w代码分析和测试w功能分析和测试w结构分析和测试w以错误为导向的分析和测试测试要素/测试技巧矩阵测试要素压力执行恢复操作复合性安全性需求回归错误处理手工支持系统兼容管理并行单元可靠性授权文件完整性审查追踪过程连续性继续测试要素压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元服务水平权限控制一致性正确性易用性可维护性兼容性耦合性性能可操作性测试工具的选择测试工具w测试标准w边界值分析w因果图w检查表w代码比较对照w以编译为基础的分析w确认/检查w控制流分析测试工具(继续)w能证明正确性的数据w以覆

18、盖为基础的测试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选择一个可提供的工具测试工具/测试技巧矩阵测试

19、工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元确认测试标准边界值分析因果图检查表代码比较编译分析确认/检查控制流证明正确性的数据测试工具/测试技巧矩阵(继续)测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元以覆盖为基础的测试数据字典数据流分析以设计为基础的功能测试设计评审桌面检查灾难性测试错误猜测执行规则全面的测试测试工具/测试技巧矩阵(继续)测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元实况调查流程图检查使用仪器综合测试设备映射图建模并行操作并行模拟代码互查测试工具/测试技巧矩阵(继续)测试工具压

20、力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元风险对照表系统控制审计评审打分系统快照特征执行系统日志测试数据产生测试数据跟踪工具程序测试工具/测试技巧矩阵(继续)测试工具压力执行恢复操作完整性安全性需求回归错误处理手工支持系统兼容管理平行单元容量测试走查软件开发生命周期/测试工具对照表测试工具需求设计编码测试安装维护确认测试标准边界值分析因果图检查表代码比较编译分析基础复杂度量测试控制流分析验证、检查正确性数据覆盖测试对照表数据字典软件开发生命周期/测试工具对照表(继续）测试工具需求设计编码测试安装维护数据流分析设计为基础的功能测试设计评审桌面检查灾难性测试错误猜测执行

21、规范全面的测试实况调查流程图检查使用仪器软件开发生命周期/测试工具对照表(继续）测试工具需求设计编码测试安装维护综合测试工具映射图模型并行操作并行模拟代码互查风险列表系统控制审计评审打分系统快照完成特征系统日志软件开发生命周期/测试工具对照表(继续）测试工具需求设计编码测试安装维护测试用例测试用例得产生形式跟踪工具程序容量测试走查测试工具管理w工具管理者的职责对工具负责帮助同事使用这些工具培训工具得使用方法负责同工具的厂家联系每年给出有关工具使用和购买得计划工具得升级工具情况报告w工具管理者得任期不易太长软件的测试过程软件的测试过程w估算w测试计划w需求w设计w编码w测试总结w安装，交付w维护

22、估算估算什么w测试对软件工作量的估算的准确性w测试评估软件系统的状况的准确性w关注点：不准确的估算不适当的开发过程不真实的状态报告对工作量的估算w如何知道对工作量的估算是正确的估算工作量的工具很容易出错对软件工作量的估算需要策略五个一般的方法w猜w加入一些约束条件w以一些数据为基础w模拟进行工作w将一些参数模型化参数模型法w回归模型：将现有的参数与已有的历史数据相拟和。w启发式模型：对历史数据进行观察和解释w现象模型：假设软件开发过程可以依据一些更广泛的可适用的过程解释。模型遵循的共同模式w估算软件的大小w将大小转化成人力的估算，并且作出可能的成本的估算w依据项目的特性进行估算的调整w将整体的

23、估算划分到不同的项目阶段中w估算不包括技巧上面的人力和计算机的运行时间w将以上内容相加对估算进行检验w检验估算模型的合理性w检验模型是否包含了必须的测试要素w检验模型的正确性校验估算模型的正确性w重新进行估算校验输入是否正确校验输入是否合理校验对数据的计算是否合理有效w比较延期的估算是否符合项目实际情况w让谨慎的人来作测试验证工作w对软件中的冗余价值估算影响估算正确与否的因素w软件规模w新设计新代码的比例w复杂程度w设计和编码的困难w使用什么语言w安全性w需求的挥发性续w组织因素项目计划人员开发环境计算机资源人员利用率膨胀因素w估算就是估算，不是保证书软件进展测试w追踪系统的瓶颈工作完成点同配

24、置管理系统紧密的结合如何使用w模块列表w里程碑w工作完成点用计算所有工作的完成度来检查系统工作过程。测试计划开发测试计划w目标详细的描述怎样能成功的完成测试工作，其中应包含必须的资源和实施计划。w可能的不利因素：没有得到足够的培训心里准备不足缺乏测试工具缺乏管理的标准和支持缺乏客户和最终使用者的参与没有足够的时间进行测试对于独立的测试人员过度信任版本改变的太快测试人员处于不受重视的情况中不能说不实施过程w听取各方面的意见和建议w标明项目风险测试要素联系测试矩阵w建立测试计划w对计划进行评审建立测试计划w定义测试目标w开发测试矩阵软件模型结构特性批量测试的阶段和用例为在线系统作概念上的测试脚本软

25、件测试矩阵w定义测试管理测试计划的一般性信息定义测试里程碑定义管理上的检查点w书写测试计划评审测试计划w涉及评审的问题评审测试的开始时间是否会延期有没有抵触评审的角色一段时间内是否很难得到工作的检查信息。更换工具有可能导致他们反感评审工作评审结果可能会影响对个人的工作评价w对于最终成品的检查项目的需求规格说明书软件返工/维护的文档升级后的技术文档被更改的源程序测试计划用户手册（包括在线帮助）续w正式评审中的角色缓和剂（SQA）读者记录者作者检测员w正式评审发现的缺陷应包含的信息起因类型分类级别评审流程w计划和组织w通篇的讲解（可选）w个人准备w评审会议w修订和反复需求阶段的测试测试成本w在软件

26、开发的所有阶段进行测试被设计用来减少测试成本wIBM的数据大约 60个缺陷/千行2/3的缺陷产生在需求和设计阶段w在需求和设计阶段发现的缺陷修正的花费最小w修正系统测试阶段发现的缺陷，花费是以上的10倍w发布产品以后，修正缺陷的花费是原来的100倍生命周期的测试概念w在软件开发过程中持续的进行测试w在尽可能早的阶段点去修正缺陷w需要正式的开发流程来支持w组建测试团队w当开发开始进行的时候，测试就开始进行了需求阶段的测试w准备风险列表确定风险组确定风险w风险分析w风险检查表建立控制目标确定有足够的控制力度分析测试要素w需求的设计是否遵循了已定义的方法w提交了已定义的功能说明w定义了系统界面w已经

27、估计了性能标准w容忍度被预先估计w预先定义了权限规则w需求中预先定义了文件完整性w预先定义了需求的变更流程w预先定义了失败的影响w权限定义需求走查w建立基本规则w选择小组/通报参与者w项目介绍w问题/建议w形成最终报告需求阶段测试w所有的花费都是值得的w大部分缺陷将不会进入到设计&编码阶段w目标需求正确的表现出了用户的需要需求已经被定义和文档化了花费和收益成正比需求的控制被明确有合理的流程可遵循有合理的方法可供选择设计阶段的测试设计阶段的测试w交付的产品输入说明过程说明文件说明输出说明控制说明系统流程图硬件和软件的需求操作手册说明书数据保留的策略设计阶段测试任务w给测试要素打分w分析测试要素w

28、对设计进行评审w检查修改的部分分析测试要素w测试涉及的内容：设计了对数据完整性的控制设计了权限规则设计了对文件完整性的控制设计了审计追踪设计了发生意外情况时的计划设计了如何达到服务水平的方法定义了权限流程定义了完整的方法学设计了保证需求一致性的方法进行了易用性的设计设计是可维护的设计是简单的交互界面设计完毕定义了成功的标准需要同实际操作者沟通对设计进行评审w选择评审组成员w对评审组进行培训w通报项目组w分配足够的时间w只对文档化的事实进行评审w和项目组一起进行评审w对评审形成建议w和项目组对建议一起进行评审w准备正式的报告编码阶段的测试形成的输出w编码说明书w程序文档w计算机程序列表w可执行的

29、程序w程序流程图w操作介绍w单元测试结果测试活动的关注点完成对数据完整性的控制定义完毕授权的规则完成对文件完整性的控制实现审计追踪规划出意外情况发生后的处理计划对系统如何达到预定义的服务水平做了计划完成了对安全问题的处理流程编码工作是依据规定的方法完成的编码与设计相一致（正确性）编码与设计相一致（易用性）代码是可维护的编码与设计相一致（简洁性）编码与设计相一致（耦合性）已开发了操作流程定义出程序成功的标准（性能上）测试的职责w编码是一个纯技术的工作，几乎不需要用户的参与w项目领导者有参与测试的责任w监督过程的有效性建议的测试方式w桌面调试语法上的结构上的功能上的w代码互查建立基本的互查规则选择

30、互查的team对成员进行培训选择互查的方法提供互查的材料w流程图，源程序，典型的处理流程对互查进行必要的管理给出互查结论提供最终的报告编码阶段的测试需解决的问题w系统是可维护的吗？w系统说明是否已经完成了？w编码是否按照既有的标准进行，过程是否易于实践？w是否有足够的测试计划用来评估可执行的程序？w是否编制了足够的文档。测试关注点w在需求，设计，编码阶段多进行一些测试，在系统测试阶段就会少一些问题。w文档测试阶段的测试计划测试用例前期测试的测试结果第三方测试反馈，例如：计算机操作人员正式的测试总结报告典型测试类型w手册，回归，功能点测试w一致性测试（授权）w功能点测试（完整性）w功能点测试（审

31、计，追踪）w覆盖性的测试（测试的连续性）w压力测试（服务水平）w一致性测试（安全性）w依照预先定义的测试方法w功能点测试（正确性）w支持手册的测试（易用性）w检查（可维护性）w灾难性的测试（可携带性）w功能和回归测试（耦合性）w一致性的测试（性能）w操作性的测试（易用性）建议测试方法w测试方法测试用例的概念是简单的建立有效的测试用例是复杂的设计测试文件w测试用例应当包含合法的和非法的输入w每一个动作只进行一次关键操作输入测试数据分析结果尝试将测试文件违反程序的规则进行输入w容量测试的测试工具以大信息量的数据进行输入这是一个昂贵的测试，应根据需要来选择在线系统需要做压力测试测试总结测试报告w目标

32、表示出目前项目的实际状况明确什么是测试做的工作，什么是不作的工作。给出系统的操作性能的评价明确什么时候系统可以进行产品化的工作w关注点测试报告只有真正需要的时候才有用，需要配合市场和管理测试的信息是不充分的（对于评价一个项目来说）测试状况并不能真实的反应个人的状况测试期间数据的收集w有关测试结果的积累数据w测试任务，测试集合和测试事件的描述w缺陷分析由于计划的问题，导致没有发现的缺陷的数据严重的缺陷缺陷类型为什么缺陷没有发现w效果测试报告w报告目前的软件状态功能/测试矩阵功能测试的状态报告，侧重点分析关于功能的工作时间轴期望发现 VS 实际发现的缺陷比没有发现的缺陷和改正的缺陷的差距按照类型分

33、类，没有改正的缺陷的平均值缺陷分类报告测试活动报告最终的报告汇总w各个阶段的项目测试总结报告w继承性测试报告w系统测试报告w确认测试报告安装测试安装阶段的测试准备w安装计划w安装流程图w安装文件和程序清单w测试安装程序给出测试结果w将程序运行的软硬件要求放入产品说明中w对于新操作人员的使用说明书w对于新使用者的操作说明和操作流程w安装过程中的各项可能发生的结果的说明测试关注点w对程序安装的正确性和完整性进行核对w校验产品文件的完整性w安装的审查，追踪被记录w安装之前，该系统已经被证实没有问题w如果安装失败，系统有相应的解决方案w安装过程，进行了权限控制（安全性）w安装遵循一定的方法，步骤w需要

34、的配套程序和数据已经放进了产品中w已交付使用说明w相关文件已经完整(可维护性）w接口已经被合理调整（耦合性）w综合的性能达到了用户要求建议测试工具w测试工具检查表选择测试的范围选择检查表明白这些问题的用意提前测试用户的检查表使用该检查表模拟运行一遍自己向自己汇报一次将有用的信息记录下来评估检查表和检查流程续w测试标准数据的正确性w将程序产品化w向操作者和用户进行讲解w校验检查表和产品的正确性w使用测试标准去检验发生的问题验收测试软件验收流程w定义用户角色w定义验收标准w编制验收计划w执行验收计划w填写验收结论定义用户角色w确定最终用户的范围w确认临时的和最终产品的验收标准w计划每一个验收过程由

35、谁和如何执行w计划资源分配w计划时间分配w准备验收计划w为每一项验收工作给出结论确定验收标准w功能上w性能上w接口质量上w过载后的软件质量w安全性w软件的稳定性编写验收计划w项目描述w用户职责w行政上的流程w验收活动描述w每一个验收项的评审w最终的验收测试步骤执行和结论w执行验收计划验收测试和评审进行管理w验收的结果典型的验收结果w在进入下一个活动之前问题或者变更必须被接受w工作可以继续，但是下次评审之前必须更正w没有任何的更改维护阶段工作重点和目标w两个重要的工作：测试和培训w目标：开发一些测试用例，预先发现一些问题在运行情况发生变化后，预先的修正一些错误编写必要的培训材料对有关的人员进行培

36、训同用户进行接触开发更新测试计划w测试计划要简短，必须在短时间内完成。w只测试变化的部分w两点：测试什么，如何测试w测试要素变化的数据交换变化的程序操作流程用户的操作习惯不同系统之间的互联语言版本安全性备份/恢复编制培训计划w对系统进行概览w对系统假定一些错误，给出处理方法w培训材料对项目内容的陈述用户使用方法对错误列表上的问题给出解释对报告进行解释，并且说明如何使用他们（图标，数据等）对输入数据进行解释反馈w反馈包括：用户反馈和测试反馈，又分成错误和建议。w没有反馈意见，程序很难提高w反馈的类型测试的数量和内容发现的问题数量和分类区分是技术上的还是应用上的问题w将反馈信息重新整理，加入到相关的测试数据中实例讲解测试活动在软件工程中的应用活动阶段分类w需求阶段w设计阶段w编码阶段w集成测试阶段w系统测试阶段w验收测试阶段w产品化发货阶段阶段流程图w总体流程图w需求阶段测试工作流程w设计&编码阶段测试工作流程w集成，系统，验收测试阶段谢谢此课件下载可自行编辑修改，仅供参考！此课件下载可自行编辑修改，仅供参考！感谢您的支持，我们努力做得更好！谢谢感谢您的支持，我们努力做得更好！谢谢