整体信息化项目测试工作培训1.0(1)

1管理咨询和整体信息化项目测试工作培训-2-21、软件开发组织流程2、软件开发测试流程3、软件测试工作方法4、测试工作注意事项培训提纲：-3-项目生命周期及流程项目生命周期中的八个阶段项目启动阶段需求分析阶段概要设计阶段详细设计阶段编码和单元测试阶段集成测试阶段确认测试阶段初步验收与上线阶段项目管理活动项目的跟踪和里程碑评审阶段评审项目变更配置管理基线管理角色职责产生文档与记录项目三大产品运行程序文档（管理文档、技术文档）源代码-4-项目生命周期及流程立项及计划阶段项目实施阶段售前人员向项目经理移交售前系列文档：《点对点应答书》、《技术方案建议书》等启动会议计划评审通过？NO修改概要设计评审通过?需求分析编码软件概要设计程序员单元测试需求分析评审通过？集成/确认测试会议纪要需求规格说明书评审报告/记录评审报告/记录修改NONOYESYES修改概要设计说明书YES评审报告/记录代码/可执行程序测试用例测试记录集成/确认测试计划集成/确认测试用例集成/确认测试报告初验结项提交文档转入维护期文档撰写用户手册维护手册......初验报告数据库验收结项阶段立项项目综合计划软件质量保证计划软件配置管理计划详细设计评审通过?软件详细设计NO修改详细设计说明书评审报告/记录-5-项目生命周期中的八个阶段项目启动阶段-6-项目生命周期中的八个阶段需求分析阶段-7-项目生命周期中的八个阶段概要设计阶段-8-项目生命周期中的八个阶段详细设计阶段概要设计详细设计编码和单元测试整合详设阶段评审里程碑评审工作产品纳入配置管理建立设计标准与培训-9-项目生命周期中的八个阶段编码和单元测试阶段-10-项目生命周期中的八个阶段集成测试阶段-11-项目生命周期中的八个阶段确认测试阶段-12-项目生命周期中的八个阶段初步验收与上线阶段-13-项目管理活动项目的跟踪和里程碑评审项目的跟踪乙方项目经理每周编写并将《项目经理周报》，甲方各业务小组联络员每周编写并将《项目小组周报》提交给项目指挥中心办公室。指挥中心办公室工作人员每周对所有项目进行跟踪，填写《项目实施进度监控表》。收集、汇总所有项目的《项目经理周报》和《项目小组周报》，上交甲方项目经理审批，并将反馈的问题直接反映给各项目业务小组和乙方项目经理。里程碑控制项目指挥中心在项目综合计划中定义项目的里程碑，并按照公司工程项目管理办法中关于里程碑控制的部分进行里程碑管理，在项目进行到里程碑处进行里程碑的评审，形成《里程碑报告》。建议大型项目至少应在需求分析阶段、详细设计阶段后设立里程碑。-14-项目管理活动阶段评审项目在各阶段对产生的技术文档应进行阶段评审。评审流程为：评审前，先确定评审人员，明确评审组组长，为评审人员分配任务，确定每个评审人员的侧重点。根据工作产品的规模，提前1～4天将待评审的工作产品、相关的标准和检查单、相关的前阶段工作产品、评审会议的日期、地点和议程安排等提交和通知各评审人员。评审人员在个人审查过程中，详细填写个人评审记录或代码审查记录，包括发现问题、花费工作量等。评审时，由评审组组长按会议议程主持评审会，参加评审人员提出评审建议，会议主要目的是确定问题，而不是解决问题，但要明确问题解决人、解决时间和验证人，由指定记录人员记录。根据问题情况，评审组长总结评审意见，由指定人员形成评审报告。评审后，文档撰写人根据评审报告中的问题记录表修改文档，评审组织单位指定人员验证文档修改情况，直到问题关闭。-15-项目管理活动项目变更设备或材料、费用预算、项目实施进度、项目范围项目经理负责设备或材料、费用预算、项目实施进度、项目工范围变更。其它变更未引起设备、费用、进度的变更时，由于用户要求、设计更改等原因引起的需求规格说明书、概要设计说明书等技术文档变更无需通过公司办理变更手续。内部变更流程为：提交变更项目组成员可通过填写《内部变更表》向项目经理提交变更。审批变更一般情况由项目经理审批变更，若变更的工作产品在更改前已经纳入基线，质量和配置人员应该参与审批。实施变更软件项目经理指派软件项目组成员实施变更，包括从‘受控库’检出需修改的文档/程序；将变更历史（如：变更日期、新版本号、变更号、修改人及变更内容等）记录在文档/程序内，程序的变更历史也可记录在‘程序变更记录’；实施人应在必要时进行回归测试，以确保变更前已被测试的模块/程序依然符合需求，同时变更的测试记录也应保留；更改完毕后，实施人通知软件项目经理。验证变更项目经理应指派软件项目组成员验证变更，包括变更是否依照‘内部变更表格’实施；测试结果（若有）是否满意；若更改没有通过验证，验证人应通知实施人修正变更。完成变更若更改通过验证，验证人应通知配置人员，将更改的文档/程序重新纳入‘受控库’和重建基线；且配置人员将《内部变更表格》中的状态改为‘结束’。-16-项目管理活动配置管理类型版本号修改软件配置项由组织内生成的M.N：从1.0开始超过或等于40%的修改：‘M.N’改为‘M+1.0’少于40%的修改：‘M.N’改为‘M.N+1’由组织外提供的软件配置项保留外来的版本号-文档名称与编号项目产生的文档可参照工程项目管理办法进行命名与编号,程序可按照软件项目组立项时所使用的名称来命名程序的名称。版本号按照下述内容，规定软件产品包的标识。配置管理项目的配置管理可有保存、受控两种形式。管理体系文档模板及记录、使用的标准与规范等应保存在相应库中，项目计划与技术文档在通过评审后应经项目经理审核修改情况再通知配置管理员，配置管理员对文档编号、版本号核实无误后置于受控库受控。-17-项目管理活动基线管理基线的设置项目根据其需要设置相应基线，如：立项—功能基线；需求分析—分配基线；详细设计—设计基线；集成测试—测试基线；确认测试—产品基线。项目对基线的设置记录在《软件配置管理计划》中，基线设置需要经过项目指挥中心批准。基线审计(1)软件配置人员应在建立基线之前(若没有设立基线：在确认测试之后，交付产品之前)进行基线审计：a.以《软件配置管理计划》和变更记录为基础，检查软件基线与其配置项，以验证软件基线和配置项与计划和更改是一致的；b.在软件项目组的协助下，检查需求追溯矩阵、测试计划和测试记录，以验证实现的功能是否一致和完备、功能是否被测试和测试结果是否满意。c.以《软件配置管理计划》为基础，验证配置库的结构、权限设置和设施是否与定义一致。(2)软件配置人员将审计结果记录在《软件基线审计报告》，并发送给软件项目经理、软件质量管理人员和需采取措施的人员。软件配置人员跟踪所需采取的措施直至结束。-18-项目管理活动角色职责职责角色负责活动参与活动决策相关组负责人定期（每周）审阅项目情况、解决项目问题批准SDP及其变更项目经理主持启动会议评审AR制订SDP计划评审阶段评审里程碑评审项目总结项目成员技术活动（包括需求分析、概要设计、详细设计等）启动会议评审AR制订SDP计划评审阶段评审里程碑评审项目总结配置管理员制订SCMP建立配置库使工作产品受控基线审计同项目成员SCCB批准SCMP批准基线变更质量保证员制订SQAP评审技术与管理活动审计各计划、文档启动会议制订SDP-19-项目管理活动产生的文档《需求规格说明书》《概要设计说明书》《详细设计说明书》《项目开发计划》《项目开发总结》《确认测试计划》《集成测试计划》《确认测试报告》《集成测试报告》《试运行问题报告》《验收报告》《用户手册》《维护手册》《操作手册》《培训手册》-20-软件项目三大产品运行程序文档（管理文档、技术文档）源代码-21-软件开发中四大测试单元测试集成测试确认测试验收测试测试的对象单元测试－＞详细设计集成测试－＞概要设计确认测试－＞需求分析验收测试－＞合同协议四大测试流程单元测试流程集成测试流程确认测试流程验收测试流程测试文档模板测试计划测试方案测试用例测试报告-22-软件开发中四大测试单元测试：也称模块测试，这是针对软件设计的最小单位—模块进行正确性检验的测试工作，其目的在于发现各模块内部可能存在的语法错误和逻辑错误等各种差错。集成测试：也称组装测试，集成测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。确认测试：也称合格性测试，用于检验所开发的软件是否按用户要求运行，是为验证软件系统符合需求规格说明而进行的测试。验收测试：为确定软件系统是否满足验收标准以及使客户决定是否接受而进行的交付测试。交付物有当前运行的可执行程序，与运行程序相对应的源代码和文档（技术文档、管理文档）-23-测试的对象从左图可以看出，测试级别与各阶段文档存在V型图关系，故各测试计划的编制时间为：单元测试—详细设计之后；集成测试—概要设计之后；确认测试—需求分析之后；验收测试—立项时。测试计划可参照《集成测试计划》、《确认测试计划》模板进行编制，并按照阶段评审流程进行评审，具体评审内容参照《**软件开发管理流程》。建立测试环境按照项目计划中对测试环境的要求建立测试环境，具体要求包括：系统运行所需要的软件环境与硬件环境（如：服务器与客户端硬盘、内存、CPU大小等）。-24-四大测试流程单元测试流程-25-四大测试流程集成测试流程-26-四大测试流程确认测试流程-27-四大测试流程验收测试流程程序员项目经理测试人员①提交产品（现场运行版本程序、源代码、文档）用户②搭建测试环境，对源代码格式和注释进行检查③调整格式、完善注释，并进行编译④对其进行测试，填写测试问题表，如果仍有问题则转③，否则将问题表提交给项目经理。⑤检查源代码和编译后的程序，确认没有问题⑥再次对源代码格式和注释进行检查，并进行测试和编译，在测试环境下进行全部功能测试⑦对文档资料进行验收⑤有问题进行补充完善⑧经双方项目经理进一步检查核实，符合要求后，签字确认-28-测试文档模板测试计划测试方案测试用例测试报告-29-测试方式黑盒测试方式白盒测试方式测试的方法黑盒测试方法白盒测试方法强度压力系统联调测试职责分工单元测试职责与分工集成测试职责与分工确认测试职责与分工验收测试职责与分工-30-黑盒测试方式黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。白盒测试方式白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：1）保证一个模块中的所有独立路径至少被使用一次；2）对所有逻辑值均需测试true和false；3）在上下边界及可操作范围内运行所有循环；4）检查内部数据结构以确保其有效性。测试方式-31-测试方式黑盒测试与白盒测试的区别黑盒测试：对已知产品的五大需求进行测试，证明系统实现功能、性能、数据、接口和运行环境是否符合要求；白盒测试：对已知产品内部工作流程，通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。软件黑盒测试意味着测试要在软件界面上进行各项操作，这种方法是把测试对象看做一个黑盒子，测试人员完全不用考虑程序内部逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序功能是否符合功能说明黑盒测试叫功能测试或数据驱动测试，黑盒测试主要发现以下几类错误：1、是否有不正确或遗漏的功能？2、在接口上，输入是否能正确接受？能否输出正