[精品]测试计划.doc

精品测试计划 MA0601测量审核样品测试计划编制年月日审核年月日批准年月日文档基本信息序号名称详细信息1文档名称Xxxx测试计划2文档编号3建立日期xx-6-194创建人5密级普通6软件Microsoft officexx修订历史记录版本日期AMD修订者说明V1.0xx-6-19A建立添加（A-添加，M-修改，D-删除）文档审批信息序号审批人角色审批日期签字备注1引言1.1目的本测试计划介绍并进一步说明完成“MA0601能力验证样品”功能测试的策略和方法。 提供系统化、规范化、工程化、实用化测试，尽早发现故障，测试工程师可以利用这个测试计划来了解和执行测试活动，测试经理利用测试计划进行测试管理。 本文档定义了测试的具体职责和活动，并描述了测试类型和测试范围。 ?通过测试，发现软件错误?验证软件是否满足软件设计和合同书所规定的技术要求?检查软件对错误操作的处理能力?为软件可靠性与安全性的评估提供依据1.2背景1.3范围用于指导“MA0601测量审核样品“的功能性测试1.4参考资料 1、MA0601测量审核样品软件需求规格说明书.doc中国航天工程咨询中心软件测评实验室xx年9月 2、MA0601测量审核作业指导书.doc中国航天工程咨询中心软件测评实验室xx年9月2测试需求2.1功能测试需求项序号功能点1软件的安装2班级学生成绩管理3年级学生成绩查询4参数设置于库操作3测试类型3.1功能测试对于功能测试采用手工测试方法，利用黑盒测试技术，测试软件功能是否与软件需求规格说明书中的描述一致，是否实现了软件需求规格说明书中描述的功能。 测试目标确保测试对象的功能正常方法.测试策略设计和执行测试用例等，以核实以下内容:?在使用有效数据时得到预期的结果?在使用无效数据时显示相应的错误信息或警告信息?各业务规则都得到了正确的应用完成标准?所有测试用例执行完毕?测试到了计划的结束日需考虑的特殊事项重点采用等价类划分法、边界值分析法准备有效的和无效的数据来无3.2工具测试文档及缺陷提交管理等工具版本测试管理缺陷跟踪性能测试项目管理4测试资源4.测试资源4.1硬件资源需求4.2软件资源需求4.3测试环境需求4.4测试人员需求4.5其他(仪器、服务器等)4.1测试人员和职责以下列出测试参与角色测试经理责任人*职责计划完成时间制定测试计划提供技术指导获取适当资源搭建测试环境设计测试用例实施测试用例执行测试记录测试结果记录问题缺陷编写测试报告测试设计员*测试工程师*4.2测试环境测试环境硬件环境软件环境测试辅助工具5项目里程碑里程碑任务工作量开始日期结束日期制定测试计划设计测试执行测试评估报告6可交付的工件测试计划、测试报告、问题报告、测试用例7风险5.风险评估5.1人力方面;5.2时间方面;5.3环境方面;5.4资源方面5.5部门合作方面6.其他内容除以上内容有关项外，还要包括测试计划制定者、日期、修改记录、评审人员(开发负责人/测试负责人/项目经理)等信息。 1.补充实施计划6.1.工作量估计根据工作内容和项目任务对包括测试设计的工作量、测试执行和测试总结的工作量，以人月或人日计，并详细注释测试设计、测试执行和测试总结工作所占的比重。 软件测试工作量应为开发工作量的30%-40%为宜。 工作阶段所需工作日占项目的比例测试规划阶段5天20%测试设计阶段7天30%测试实施阶段7天30%测试执行阶段3天15%测试总结阶段2天5%6.2.人员需求及安排下表列出了在此测试活动的人员安排角色人员具体职责/备注测试经理杨建国负责监督其他人员工作及处理事项测试设计杨建国负责软件开发的测试程序测试人员杨建国负责测试软件的可实用性6.3.进度安排下表列出了测试的时间安排项目里程碑开始时间结束时间输出要求/备注测试规划xx.07.10xx.07.15完成测试准备阶段测试设计xx.07.16xx.07.23需要完成测试的设计阶段测试设计实施xx.07.24xx.07.31按照测试的设计进行实施测试执行xx.08.01xx.08.03开始进行测试的执行阶段测试总结xx.08.04xx.08.06测试总结阶段6.4.其他资源需求及安排软件测试安排如下1.软件开发人员即程序员应当避免测试自己的程序，不管是程序员还是开发小组都应当避免测试自己的程序或者本组开发的功能模版。 若条件允许，应当由独立于开发组和客户的第三方测试组或测试机构来进行软件测试。 但这并不是说程序员不能测试自己的程序，而且更加鼓励程序员进行调试，因为测试由别人来进行可能会会更加有效、客观，并且容易成功，而允许程序员自己调试也会更加有效和针对性。 2.应尽早地和不断地进行软件测试，应当把软件测试贯穿到整个软件开发的过程中，而不应该把软件测试看作是其过程中的一个独立阶段。 因为在软件开发的每一环节都有可能产生意想不到的问题，其影响因素有很多，比如软件本身的抽象性和复杂性、软件所涉及问题的复杂性、软件开发各个阶段工作的多样性，以及各层次工作人员的配合关系等。 所以要坚持软件开发各阶段的技术评审，把错误克服在早期，从而减少成本，提高软件质量。 3.对测试用例要有正确的态度第一，测试用例应当由测试输入数据和预期输出结果这两部分组成；第二，在设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的输入条件。 因为软件投入实际运行中，往往不遵守正常的使用方法，却进行了一些甚至大量的意外输入导致软件一时半时不能做出适当的反应，就很容易产生一系列的问题，轻则输出错误的结果，重则瘫痪失效！因此常用一些不合理的输入条件来发现更多的鲜为人知的软件缺陷。 4.人以群分，物以类聚，软件测试也不例外，一定要充分注意软件测试中的群集现象，也可以认为是“80-20原则”。 不要以为发现几个错误并且解决这些问题之后，就不需要测试了。 反而这里是错误群集的地方，对这段程序要重点测试，以提高测试投资的效益。 5.严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作。 6.应当对每一个测试结果进行全面检查。 一定要全面地、仔细地检查测试结果，但常常被人们忽略，导致许多错误被遗漏。 7.妥善保存测试用例、测试计划、测试报告和最终分析报告，以备回归测试及维护之用。 在遵守以上原则的基础上进行软件测试，可以以最少的时间和人力找出软件中的各种缺陷，从而达到保证软件质量的目的。 6.5.可交付工件确认测试应交付的文档有确认测试分析报告最终的用户手册和操作手册项目开发总结报告。 7.风险管理本章详细描述本次测试所面临的风险（如人力资源风险、测试技术风险、测试资源风险、质量保证风险等）及相应的建议解决办法。 下表是一些具有共性的软件项目风险的清单，以供参考风险种类描述没有详细设计说明书设计方面分析业务逻辑，在不清楚的地方及时与开发人员沟通统一的界面设计不规范设计方面与项目负责人确认测试标准需求变更开发开发方面建议将需求变更形成文档，对没有文档的需求变更人力资源测试本身保证稳定的人员安排硬件资源测试本身先分析测试所需硬件资源，及时申请，保证测试工作顺利进行版本控制测试本身严格控制版本，BUG以版本为单位进行提交测试时间不足测试本身动员测试人员完成测试任务，必要时，应给予相应物质奖励下表列出了一些风险的分析表。 分析表必须按影响的程度来排序。 实践中，必须参照项目过程的、开发组的、以及公司的详细具体的情况来制定。 并且，随着时间的推移和环境的变化，必须随时更