项目-测试计划

项目全称测试计划-15-

1．简介1.1测试目的本次测试是针对项目全称进行的系统测试，目的是为判定该系统是否满足《项目全称-需求规格说明书.doc》中规定的功能提供客观的依据。1.2测试目标判定测试开发目标中所要求的系统功能是否具备，执行结果是否正确，明确在用户文档、功能性、可靠性、易用性、可维护性、可移植性、性能和安全性八个方面进行测试。1.3测试范围参照项目全称需求文档及相关的测试类型，在此确定测试范围，规定测试内容。测试内容从商业需求或技术需求中归纳提取，在下表逐条表述。测试范围第1页共1页序号测试分类测试内容1T-UD用户文档评审2T-F功能性测试3T-R可靠性测试4T-U易用性测试5T-M可维护性测试6T-P可移植性测试7T-E性能测试8T-S安全性测试1.4测试环境配置软件环境：终端类别操作系统相关应用软件客户端WindowsXPprofessionalIE6或IE7或IE8服务器WindowsServer2008R2Sunjdk1.6.0_2264bit、apache-tomcat-6.0.2964bit、MicrosoftWindowsSQLserver2008R2、MicrosoftExchangeServer2013、MicrosoftOCS2007硬件环境：终端类别机器型号配置说明客户端DELLOptiPlex380处理器：Intel奔腾双核E5300内存大小：2048M客户端Ipad2处理器：AppleA5处理速度：1GHz服务器DELLPowerEdgeT410处理器：IntelXeonE5504内存大小：4096M1.5测试工具工具名称项目用途工具描述TestDirector测试管理工具TestDirector是全球最大的软件测试工具提供商MercuryInteractive公司生产的企业级测试管理工具，也是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。LoadRunner性能测试工具LoadRunner是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。1.6参考资料1.6.1定义测试策略的定义：T_UD：用户文档评审T_F：功能性测试T_R：可靠性测试T_U：易用性测试T_M：可维护性测试T_P：可移植性测试T_E：性能测试T_S：安全性测试1.6.2文档GB/T11457软件工程术语GB8566计算机软件开发规范GB8567计算机软件产品开发文件编制指南GB/T12505计算机软件配置管理计划规范ISO9001:2008质量管理体系要求项目全称招标文件项目全称合同项目全称-需求规格说明书

2.测试策略2.1功能测试2.1.1类型简介类型介绍：对需求分析说明书中要求的功能进行功能符合性测试。测试目标：对系统中划分出来的主要功能进行测试，确保合理准确地完成需求说明。测试技术：黑盒测试技术，对系统的主要服务功能进行测试。完成标准：主要业务流程能够正确实现业务逻辑。测试范围：全部功能。2.2性能测试2.2.1性能测试类型介绍：合理评测系统性能，确保页面响应时间符合要求。本系统的性能测试包含测试类型有：恢复/容错/可靠性测试、强度/疲劳测试、并发测试、负载/压力测试、容量/大数据量测试测试目标：合理评测系统瓶颈代码部分，确保页面响应时间符合要求。测试技术：性能测试工具LoadRunner完成标准：关键性能测试点全部通过测试，对相应的问题产生合理的数据评测结果。测试范围：主要功能2.2.2安全性测试类型介绍：对软件和数据进行非授权的故意或意外访问的测试，验证系统的安全性满足需求分析说明书。测试目标：系统中涉及到的用户角色权限控制合理。系统网络安全性。数据库的安全保密。测试技术：黑盒测试技术。完成标准：用户角色权限访问符合需求分析说明。系统网络安全和数据库安全符合需求分析说明。测试范围：重点测试现系统网络安全性和数据库的安全保密机制。2.2.3强度测试类型介绍：对功能进行强度测试检查程序对异常情况的抵抗能力。测试目标：定量地增长数据输入率，检查系统平台的反映能力。技术：性能测试工具LoadRunner完成标准：对系统需求分析说明书中指定的功能进行了合理的强度测试。测试范围重点功能。2.2.4疲劳测试类型介绍：对系统进行长时间连续运行测试，并模拟相当的业务量，从而评价系统是否能够满足长时间连续运行的目标。测试目标：按照需求规格说明，设置各种不同业务的混合业务场景，测试长时间运行时系统各项性能指标，考察系统性能指标的变化趋势，统计长时间运行条件下的出错概率。测试技术：性能测试工具LoadRunner。用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。完成标准：根据需求要求功能进行对系统最短连续运行时间的要求的测试关键性能测试点全部通过测试，对相应的问题产生合理的数据评测结果。测试范围重点功能。2.2.5并发测试类型介绍：测试多用户并发访问同一个应用、同一个模块的问题。测试目标：通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。其主要目的是发现系统中可能隐藏的并发访问的问题。关注系统可能存在的并发问题，例如系统中的内容泄漏、线程锁和资源争用方面的问题。测试技术：性能测试工具LoadRunner。完成标准：对系统要求的并发性能点全部通过测试，对相应产生的问题合理的评估结果。测试范围重点功能。2.2.6负载/压力测试类型介绍：在一定约束条件下不断地对系统施加压力，通过测试系统反映出来的所能承受的并发用户量、运行时间、数据量，以确定系统所能承受的处理极限。负载压力测试是性能测试的重要组成部分，负载压力测试包括并发性能测试、疲劳强度测试、大数据量测试等内容。测试目的负载测试是通过逐步增加系统负载，确定测试系统性能的变化。本测试主要用于验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。测试技术：性能测试工具LoadRunner。完成标准：对系统要求的负载/压力全部通过测试，对相应产生的问题合理的评估结果。测试范围：重点功能。2.3用户接口测试2.3.1测试类型简介类型介绍：核实用户与软件之间的交互友好，并符合公司或行业规范。包括易理解性、易学性、易操作性测试目标：系统提供的功能界面能够比较便捷地实现功能需求。界面友好。测试技术：黑盒测试技术完成标准：成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准测试范围：注意用户特定的使用习惯（例如企业色彩等）

3．人员安排

角色人员职责项目经理项目经理姓名评审并批准项目计划及有关报告；组织并确保团队工作；控制项目执行；评估项目绩效；与有关人员进行沟通。测试经理张明利项目计划编制；协调并实施项目计划中确定的活动；识别测试环境需求；负责设计测试用例；为其他人员提供技术支持。测试人员郑海艳、秦建青王大伟、吕波、崔延、陈芳执行测试活动；在项目计划制订阶段，识别项目活动，估计每项活动所需的时间。环境准备人员王大伟秦建青提供资源保障；建立并维护测试环境。质量保证人员QA姓名确定项目质量目标；制订并实施质量计划；监督、指导项目活动的执行过程。

4．时间安排事件开始时间结束时间制定测试计划2013年5月30日2013年6月4日测试计划报审2013年6月4日2013年6月10日编写测试用例2013年6月10日2013年6月17日测试用例评审、修改2013年6月17日2013年6月20日第一批模块测试2013年6月20日2013年7月3日第一批模块总结2013年7月3日2013年7月4日第二批模块测试2013年7月4日2013年7月18日第二批模块总结2013年7月18日2013年7月19日第三批模块测试2013年7月19日2013年8月2日第三批模块总结2013年8月2日2013年8月5日系统bug回归测试2013年8月5日2013年8月9日测试报告报审2013年8月9日2013年8月15日系统测试完成2013年8月15日2013年8月15日

5．系统测试5.1测试方法在此规定用于项目全称测试的测试方法。功能测试主要采用手动测试方法，对软件产品进行黑盒测试。性能测试主要采用自动测试方法，使用工具为LoadRunner。5.2测试启动条件在此规定，在开始进行测试时必需满足的条件。这些条件涉及：测试计划、测试流程、测试进度的制订已完成，并经过严格评审；缺陷跟踪与管理系统已搭建；测试所需的资源已经到位；测试组人员配置合理，测试人员的工作技能符合测试要求；测试所需的软、硬件和操作系统等测试环境准备完毕。5.3测试用例开发根据测试范围规定的内容，逐条设计测试需求及完成该测试需求的测试过程、测试条件，构造本次测试的测试用例，编写决策树。5.3.1用户文档表1用户文档第1页共1页测试需求测试过程说明过程标引完整性软件使用所需信息产品描述中说明的所有功能程序中用户可调用的所有功能说明产品描述中给出的所有边界值软件安装所需要的信息软件维护所需要的信息正确性文档中所有信息正确，没有歧义和错误的表达一致性文档自身内容或相互之间以及与产品描述之间，相互不矛盾，且术语一致用户手册和操作手册与软件实际运行情况相符易理解程度文档对正常使用其产品的一般用户是容易理解的易浏览程度用户文档易于浏览，相互关系明确用户文档有目录表或索引表5.3.2功能性表2功能表现第1页共1页测试需求测试过程说明过程标引功能点根据用户文档列出所有功能点，检验其正确性验证程序与产品描述、用户文档中的全部说明相对应，一致性5.3.3可靠性表3可靠性第1页共1页测试需求测试过程说明过程标引成熟性使用的容量达到规定的极限时,系统不能崩溃、不能异常退出也不丢失数据试图使用的容量超出规定极限时，系统不能崩溃、不能异常退出也不丢失数据产品描述中列出的其他程序或用户造成的错误输入时，系统不能崩溃也不丢失数据输入用户文档中明确规定的非法指令时，系统不能崩溃也不丢失数据不会因掉电、异常退出、网络异常中断等原因而使软件或数据遭到破坏容错性能屏蔽用户的误操作对错误有正确提示输入错误数据时，系统不能崩溃、不能异常退出也不丢失数据有错误操作时，系统不能崩溃、不能异常退出也不丢失数据易恢复性系统运行失效后，应能较快重建系统数据校验机制应对数据项之间的逻辑关系进行校验，保证数据的有效性应保证数据的完整性和一致性，不会因删除或反复的更新而被破坏或留下垃圾数据对不符合要求的输入数据，系统应使用中文给出简洁、准确的提示信息，必要时应给出帮助5.3.4易用性表4易用性第1页共1页测试需求测试过程说明过程标引易理解性通过选择适当的术语、图形表示、背景信息和帮助，帮助用户理解、使用出错消息中提供差错产生的原因和纠正的详细信息易浏览性数据媒体具有产品标识，可辨别编号或文本具有必要的信息，指导用户使用程序输入、输出设计规矩，输出结果应简洁、直观、美观、方便阅读、易懂和使用人机界面简洁、美观、实用，风格相对一致，符合办公习惯在界面、人机交互、输出中的用语应与业务用语一致易操作性具有严重后果的功能执行可逆，或者给出明显警告，执行前要求确认软件操作简便，系统支持标准的鼠标、键盘操作，支持鼠标的单击、双击和右键操作，支持快捷键操作提供辅助输入手段（如选择输入、默认值等），数据检索方便、灵活根据用户熟练程度（外行、初学、熟练）和使用频度，能提供不同的操作方式或用户界面5.3.5可维护性表5可维护性第1页共1页测试需求测试过程说明过程标引易分析性系统可以正确判断缺陷或失效原因对于软件运行错误，应当提示清晰，为用户和系统管理员自己解决问题提供可能易改变性对相关配置文件、库、表的参数可以提供方便的修改对于非程序内部错误，由数据元素属性设置、控制规则不当而引起的软件运行错误，软件应为系统管理员提供自行修正的手段软件应充分考虑在设计环境与适用范围下不同用户的要求，为用户进行本地化配置提供手段稳定性系统在测试过程中运行稳定5.3.6可移植性表6可移植性第1页共1页测试需求测试过程说明过程标引适应性软件可适应不同的规定环境（如：不同的网络环境）兼容性硬件设备兼容性软件（如：操作系统、数据库、WEB服务器等）兼容性5.4测试过程ID命名规则测试用例ID由四部分组成表示，左起第一部分字符表示项目名称，第二部分字符表示文档类型，第三部分字符表示模块名称，第四部分数字表示测试用例编号。5.5评审测试计划由项目经理、技术经理和质量保证人员进行评审。6．测试执行根据测试计划中相关测试环境的内容，检查测试环境（包括硬件及软件），确保测试环境符合要求；对于测试用例的描述信息，按测试意图对每一个测试用例设计操作流程中重要环节的动作、输入数据和预期的反映（注：此流程可不必详细到每一个具体的步骤，但应确保测试执行人员可以据此信息顺利执行，而不必询问测试用例的开发人员）；执行测试活动，并记录所使用的机器及执行日期，对于每个测试用例还应记录关键操作步骤、输入数据以及任何与测试人员预期结果不符的系统响应；每个测试用例执行完毕后，视具体情况对系统进行备份或根据备份数据对系统进行恢复。7．缺陷管理依照设计好的测试用例对产品进行测试，将发现的缺陷，包括功能、界面，按照用例中的测试号分别记录，保证各类缺陷记录的维护、分配和修改。7.1缺陷报告使用TD管理工具对缺陷进行跟踪和管理，项目完成时所提交的报告包括如下内容：缺陷ID；项目名称；样品版本；测试平台；操作系统；功能模块名；缺陷优先级；可重现性；提交人；确认人；缺陷问题摘要；缺陷详细描述。7.2缺陷状态Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed、Closed及Rejected等New为测试人员新问题提交所标志的状态。Open为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。Bug解决中的状态，由任务分配人改变。对没有进入此状态的Bug，程序员不用管。Postponed延后。由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug。Fixed为开发人员修改问题后所标志的状态，修改后还未测试。Rejected开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。由Bug分配人或者开发人员来设置。Reopen为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误。由测试人员改变。Closed为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。7.3缺陷严重级别Bug严重级别