测试流程和可行软件测试流程.ppt

1、软件测试流程和可行软件测试流程,从小局部看常用软件测试流程 从大方向看可行的软件测试流程,软件测试活动分布,产品立项,需求分析,概要设计,详细设计,编码&单元测试,集成测试,系统测试,验收测试,产品立项,制定测试计划,测试设计,编写测试用例,测试执行,测试评估,需求阶段测试工作流程图,立项,需求调研（开发与测试共同参与,编写/修改SRS,提交SRS,SRS审核,审核是否通过,提交最终版的SRS,编写需求测试用例,评审需求测试用例,进入概要设计阶段,编写需求 业务、功能、用户,需求评审,需求规格说明书,需求变更,需求变更记录,需求报警,进入概要设计阶段,总体测试计划,系统测试方案,需求跟踪矩阵,

2、需求报警信号,开发的流程,测试的流程（每一步都需要开发的参与）,设计测试的总体流程,概要设计阶段,详细设计阶段,编码阶段,需求说明书 需求变更矩阵 技术规格说明书,测试策略,制定/修改测试计划,制定测试方案,编写/修改测试用例,测试环境搭建/测试脚本编写,结合项目计划开工会讨论测试计划,工会讨论通过,N,Y,开工会评审测试用例,用例评审通过,N,Y,测试阶段图,是否满足测试入口条件,退回,N,是否初测,审视测试环境,是否存在重大问题需要挂起或者退回,退回或挂起项目,接上一阶段,Y,复查BUG,N,测试执行,检查/修改/补充测试用例,结束初测,是否满足测试出口口条件,开发更改bug更新需求,记录

3、测试数据，编写相关报告,N,构建自动化测试代码,接上一阶段,记录测试数据，编写相关报告,可选,Y,建立适合我们的流程：从流程中最重要的东西：逻辑思想,测试调研,收集需求信息,（了解测试需求）,制定测试计划,（了解如何测试，规避风险）,写测试用例/测试执行,（测试工作不可少的部分）,测试报告,（提供可供分析的报告）,测试依据,项目测试计划 需求规格说明书 用户提出的需求书 设计规范以及测试规范,开发的支持,（包括编码规范、 功能接口规范、操作规范、 界面组织及报表格式规范）,新版本软件说明,建立适合我们的流程：结合公司目前产品现状,输入,输出,测试阶段,待测软件版本,软件升级,新增的功能 解决的

4、问题,软件测试任务书,人员 任务 时间,基本功能验证,解决问题的验证,新增功能测试,其他功能测试,测试报告,新产品软件,性能测试,我们的测试需要作什么,测试调研：分析需求的可测性，可构思将来对其测试的方法、原则等，并进行review 制定测试计划：制定总体的测试计划，详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接受标准以及测试人员和测试时间等内容，“测试计划”经过审查通过，才能实施 测试用例设计：根据对具体的北侧系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。 执行测试:按照预定的测试计划和测试方案逐项进行测试,并记录

5、任何与预期目标不符的现象和问题 测试评估 :测试结果进行分析，评估产品是否可以上市 缺陷管理子系统 : 管理缺陷 分析缺陷:为以后工作提供一个量上的指导 项目测试总结: 总结项目完成后 经验，为以后工作提供一个借鉴,遵循的原则,1、在项目发布后发现和修复Bug的成本是需求和设计阶段所需的一百倍！ 2、80%可避免的重复劳动源自于20%的缺陷，其中两大主要来源包括草率的需求定制和象征性的案例设计和开发。 3、大约80%的缺陷来自20%的模块，而约半数的模块是几乎没有缺陷。 4、90%的软件的停工期最多来自于10%的缺陷,1、测试人员提早进入项目 2、善于总结，提交准确的分析报告并善于利用它 3、

6、尽早发现需求上和设计上的缺陷,立项申请,通过评审,计划制定提交审核,需求调研,设计+编码+单元测试,回归bug修改,测试策略,评审后的需求规格说明,回归后测试记录,需求阶段测试工作,定义测试策略,测试覆盖分析,功能测试矩阵,需求变更测试,产生的文档： 测试规格说明书 功能 测试矩阵 需求变更趋势图,产生的文档： 测试报告 缺陷走势图 遗留问题说明书,测试执行阶段,缺陷走势分析,遗留问题分析,开发活动,测试相关入口文件,测试活动,测试产生的记录文件,编写/修改SRS,SRS评审,n,Y,单元测试缺陷记录,遗留问题记录及规避方法,设计+编码+单元测试阶段测试工作,定义测试计划,定义测试方案,编写测试用例,测试环境和数据准备,产生的文档： 测试计划 测试方案 测试用例,适合我们的测试流程,完善测试过程的策略,多管齐下，寻取最优：如何去寻找这个最适合的标准，开发人员先自己拟定一套规范，开发部自己评审过后交给测试人员评审，