资源描述
软件测试方法和技术第17章软件测试项目管理,顾进广,Ph.D.,Professor,simon,本章要解决的问题,软件项目的测试过程管理;软件自动化解决方案和实施;软件项目的测试资源分配和进度控制;软件测试工作和产品质量的风险评估和控制;软件版本定义、测试范围变化的控制等;软件构建和发布等监控。,第17章软件测试项目管理,17.1测试项目管理的特点17.2如何做好测试项目管理17.3软件测试项目的过程管理17.4测试项目的资源管理17.5测试项目的进度管理17.6测试项目的风险管理17.7软件测试文档的管理,17.1测试项目管理的特点,软件测试存在较大风险,质量标准定义不准确、任务边界模糊软件测试项目的变化控制和预警分析要求高。软件测试管理要求更严格和细致测试任务的分配难测试要求人力资源十分稳定测试人员在待遇、地位可能受到一些不公正的待遇,17.2如何做好测试项目管理,测试项目的管理原则测试计划先行建立优先级依靠团队的能力建立客观的评价标准软件测试项目管理者的责任,17.3软件测试项目的过程管理,17.3.1测试的目标和准则17.3.2测试计划内容17.3.3测试项目的计划过程17.3.4制定有效的测试计划17.3.5测试策略的确定17.3.6测试设计和开发17.3.7测试执行,17.3.1测试的目标和准则,确定测试目标为测试各项活动制定一个现实可行的、综合的计划;为项目实施建立一个组织模型,并定义测试项目中每个角色的责任和工作内容;开发有效的测试模型,能正确地验证被测试的软件系统;确定所需要的时间和资源,以保证其可获得性、有效性;确立每个测试阶段进/出标准;识别出测试活动中各种风险。制定有效的测试策略,保证项目测试任务按时完成,测试进入的准则,清楚了解项目的整体计划框架;完成需求规格说明书评审;技术知识或业务知识的储备;标准环境技术设计文档是测试用例设计的重要参考资料;足够的资源;人员组织结构、成员及其责任已确定。,17.3.2测试计划内容,软件测试计划是指导测试过程的纲领性文件,描述测试活动的范围、方法、策略、资源、任务安排和进度等,并确定测试项、哪些功能特性将被测试、哪些功能特性将无需测试,识别测试过程中的风险。内容主要集中在测试目标和需求说明、测试工作量估算、测试策略、测试资源配置、进度表、测试风险等,IEEE8291998:测试计划内容,测试计划标识符(文档编号)项目总体情况简介;测试项(testitem);需要测试的功能;方法(策略);不需要测试的功能;测试项通过/失败的标准;测试中断和恢复的规定;,测试完成所提交的材料;测试任务;测试环境要求;测试人员职责;人员安排与培训需求;进度表;潜在的问题和风险;审批,17.3.3测试项目的计划过程,计划初期是收集项目各类信息,理解用户的真正需求确定测试需求和测试范围起草计划。内部审查。计划讨论和修改。测试计划的多方审查。测试计划的定稿和批准。测试计划的跟踪。,测试周期,MRD/PRD/UISign-off,Eng.PlanSign-off,Eng.SpecSign-off,TestPlanSign-off,ProductReview,CodeFreeze,TestCaseSign-off,CodeComplete,验收测试,QA创建TestPlan,QA,QA创建TestCases,功能测试,写/审查Spec,系统测试,单元测试,PRD/UI审查,QA,测试范围的确立,优先级最高的需求功能新功能和编码改动较大(提高性能表现)的旧功能运用有效的测试技术去提高测试效果经常容易出现问题部分的功能一些经常被用户使用的功能和配置,风险评估,测试小组开始项目测试时,硬件资源没有按时配备或仍然不足开始项目测试时,软件产品编码没有按计划完成开始项目测试时,测试用例没有准备好缺少按计划参加项目测试的测试人员在项目测试过程中,需求总是不停地改动当项目测试进行时,在设计说明书中被定义的功能总是不停地被修改,测试计划的创建和评审,17.3.4制定有效的测试计划,确定测试项目的任务,清楚测试范围和测试目标尽量识别出各种测试风险,制定出相应的对策让所有合适的相关人员参与测试项目的计划制定客观、准确、留有余地;制定测试项目的输入、输出和质量标准识别出可变因素,建立变化处理和控制的流程规则不要忽视技术上的问题要对测试的公正性、遵照的标准做一个说明测试计划应简洁、易读并有所侧重,测试输入/输出标准,测试的输入标准整体项目计划框架;需求规格说明书;技术知识或业务知识标准环境设计文档;足够的资源人员组织结构测试的输出标准测试执行标准Bug描述和处理标准文档标准和模板测试分析、质量评估标准等,17.3.5测试策略的确定,要使用的测试技术和工具测试完成标准影响资源分配的特殊考虑输入、输出和过程;基于测试技术的测试策略基于测试方案的综合测试策略,测试策略的概念,测试策略通常是描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试(如单元测试、集成测试、系统测试)以及每个阶段内进行的测试种类(如功能测试、性能测试、压力测试等),以确定合理的测试方案使得测试更有效。,影响测试策略的因素,1、测试完成的标准标准的高低对策略确定有着重要的影响。比如该软件的应该用场合为军用,这将对软件的可靠性、安全性要求非常高,但如果是用于小型商场的收费系统由于是内部使用,主要考虑其计算的准确与精度及复杂统计与报表生成等方面准确性与易用性。2、资源状况参与测试的人、测试中所需要的软件平台(如操作系统甚至会涉及到第三方的一些应用软件)及测试可能用到的相关硬件设备(如计算机,网络硬件其它外设等),阶段通过/失败的标准,制定测试策略,全面细致地了解产品的项目信息:应用领域,测试范围,市场需求,产品的特点和主要功能,技术架构基于模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素对产品的影响,公正客观地开展测试计划根据程序的重要性和一旦发生故障将造成的损失,来确定它的测试等级和测试重点认真研究测试策略,以便能使用尽可能少的有效测试用例,发现尽可能多的程序错误,因为一次完整的软件测试过后,如果程序中遗漏的错误过多并且很严重,则表明本次测试是失败的,是不足的;而测试不足意味着让用户承担隐藏错误带来的危险.同时反过来说,如果过度测试,则又会浪费许多宝贵的资源.找到一个最佳平衡点。,17.3.6测试设计和开发,高层次的设计vs.低层次的设计测试技术方案、测试用例、测试环境等设计非正式的审查vs.正式的审查自动化测试脚本的设计与开发,17.3.7测试执行,如何确保测试环境设置正确并满足测试用例所描述的要求?如何保证每个测试人员清楚自己的测试任务?如何保证所有测试用例得到百分之百的执行?如何保证所报告的Bug正确、描述清楚、没有漏掉信息?如何在验证Bug和对新功能的测试上寻找平衡?如何跟踪Bug处理的进度使严重的Bug及时得到解决?,不同测试阶段的执行要点,代码审查,确保测试人员参与代码的会审单元测试一般由程序员自己做集成测试应尽早进行、持续进行功能测试的交叉进行,从用户的角度出发,尽量挖掘和模拟各种使用情景(特殊场合或边界条件)系统测试:方案可行、工具有效、环境正确获得用户的反馈,其它管理要点,测试用例执行,如跟踪曲线、系统的详细记录Bug的跟踪和管理和项目组外部人员的沟通测试执行结束,测试执行阶段(3,example),17.4软件测试项目的资源管理,人力资源管理测试环境资源工作量的估计,17.5测试项目的进度管理,17.5.1测试项目的里程碑和关键路径17.5.2测试项目进度的特性及外在关系17.5.3测试项目进度的管理方法和工具,测试项目的里程碑,测试项目进度的特性及外在关系,进度与质量关系进度与成本的关系,测试进度的S曲线法,进度S曲线法通过对计划中的进度、尝试的进度与实际的进度三者对比来实现的,其采用的基本数据主要是测试用例或测试点的数量,测试进度的NOB曲线法,NOB,NumberofOpenBug,17.6测试项目的风险管理,17.7软件测试文档的管理,文档的分类管理文档的格式和模板管理文档的一致性管理文档的存储管理,软件测试误区,误区一:如果发布出去的软件有质量问题,都是软件测试人员的错误区二:软件测试技术要求不高,至少比编程容易多了误区三:有时间就多测试一些,来不及就少测试一些误区四:软件测试是测试人员的事,与开发人员无关误区五:根据软件开发瀑布模型,软件测试是开发后期的一个阶段,软件测试的原则,所有测试的标准都是建立在用户需求之上。软件测试必须基于“质量第一”的思想去开展各项工作,当时间和质量冲突时,时间要服从质量。事先定义好产品的质量标准,只有有了质量标准,才能根据测试的结果,对产品的质量进行分析和评估。软件项目一启动,软件测试也就是开始,而不是等程序写完,才开始进行测试。穷举测试是不可能的。甚至一个大小适度的程序,其路径排列的数量也非常大,因此,在测试中不可能运行路径的每一种组合。,软件测试的原则(2),第三方进行测试会更客观,更有效。软件测试计划是做好软件测试工作的前提。测试用例是设计出来的,不是写出来的,所以要根据测试的目的,采用相应的方法去设计测试用例,从而提高测试的效率,更多地发现错误,提高程序的可靠性。对发现错误较多的程序段,应进行更深入的测试。一般来说,一段程序中已发现的错误数越多,其中存在的错误概率也就越大。重视文档,妥善保存一切测试过程文档(测试计划、测试用例、测试报告等),作业,思考题2,3,Q&A,
展开阅读全文