【精品】测试计划模板.doc

【精品】测试计划模板 贪吃蛇项目名称测试计划书1.测试背景为了保证贪吃蛇项目测试工作的组织性，提高测试的工作质量和效率，为XX项目测试工作提供完整的测试计划、测试人员工作安排、测试轮次、测试方法、系统功能模块覆盖率以及测试风险分析，确保测试项目平稳有序的运行。 2.测试目标贪吃蛇测试项目的测试目标为?接口程序覆盖率100%，接口错误修改率100%?测试案例的功能覆盖率达100%，执行率达100%?已修改的测试问题回归测试覆盖率达100%?测试记录闭环率达95%3.测试范围?测试计划和设计根据软件需求说明书，制定测试计划，测试方案，包括收集测试方法，测试用例，测试工具等。 ?单元测试根据系统详细设计，制定测试计划，测试方案。 此项由开发人员自测。 ?集成测试将各个模块进行组合测试，保证所有功能和界面都正确。 对产品重点模块进行负载测试，确保软件性能达到软件需求说明书的要求4.测试输出文档文档使用工具提交日期责任人测试计划Word测试经理测试用例QC测试经理缺陷报告QC测试经理测试报告Excel测试经理?项目的测试人员、职位、工作职责角色姓名工作内容测试经理编写测试计划缺陷管理测试结果分析黑盒测试工程师编写测试用例执行测试报告缺陷自动化测试工程师编写脚本自动化测试执行性能测试工程师分析软件功能开发脚本性能测试执行?需要配合的部门与人员角色姓名工作内容开发人员协助搭建测试环境业务人员协助测试人员理解需求，提供业务帮助5.测试工具?测试管理工具为Quality Center、性能测试工具有LoadRunner、功能自动化测试工具为Quick TestProfessional用途工具生产厂商版本测试管理QC HP9.0性能测试LR HP8.1功能自动化QTP HP9.26.测试规模以及工作量分析贪吃蛇项目为大型项目，测试工作包括为测试计划、测试用例的编写、集成测试的执行、性能测试的执行，涉及功能模块较多，业务逻辑较为复杂，预估测试工作量如下所示。 ?测试工作量预估任务阶段人数工作日人日小计备注测试案例编写157105测试执行1523345?功能点分析模块子节点测试人员启动时间XXXX登录及整体架构xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24XXXXXxx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24XXXxx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-24xx-10-247.测试进程1）测试流程表开始编写测试计划浏览测试计划是是计划测试阶段测试计划结束总结编写测试用例浏览测试用例是否测试是否停止是否测试用例阶段测试总结阶段测试执行缺陷记录与分析测试总结冒烟测试通过失败2）测试过程描述a.测试计划阶段?编写测试计划测试经理根据项目计划与项目业务需求说明书创建测试计划，如果此需求发生变化，则将根据变化更新此项目测试计划。 ?评审测试计划?项目经理浏览并评审系统项目测试计划。 ?测试经理负责更新此文档。 ?项目经理负责评审和批准经过更新的文档。 ?项目测试计划的版本为1.0,如果该计划被更新，则版本的序号也随之变更。 ?测试工程师根据测试计划执行测试任务。 b.测试用例阶段?编写测试用例?分析软件需求说明书。 ?测试工程师根据软件需求说明书编写测试用例。 ?冒烟测试用例需要被同时创建。 ?评审测试用例?测试组负责评审测试用例。 ?在发现错误或问题的情况下，该测试用例将会被更新。 ?测试经理负责填写测试用例评审报告。 ?我们将测试用例的最初版本定义为1.0，如果该文件得到更新，其版本也会被同时更新。 c.测试阶段?冒烟测试测试工程师负责根据项目测试用例进行冒烟测试，执行测试用例的实际输出结果是否符合预期结果，我们将此用例标注为通过或者失败，将结果返回给开发部门。 ?系统测试根据项目测试计划和项目测试用例，测试工程师负责执行测试用例?当执行测试用例时1.如果实际输出结果和预期输出结果相同，该用例需要被标注为通过。 2.如果实际输出结果和预期输出结果不同，该用例需要被标注为失败。 3.如果测试时遇到功能性缺陷导致用例不能执行，该测试用例需要被标注为锁定，直到该缺陷被修复，才可以继续执行该测试用例。 4.所有在测试过程发现的缺陷，需要被提交到Quality Center。 ?测试用例在测试过程中将根据需要得到更新。 ?测试经理负责分析测试结果，对测试人员执行的测试用例进行一定比率的内部QC（质量控制）。 ?测试完成时，需得到测试经理的批准。 备注所有的缺陷必须被提交到缺陷处理系统Quality Center。 d.测试总结阶段?分析和总结测试结果?测试经理总结各自的测试工作并在项目测试总结中填写相应的部分内容。 包括测试工具，测试技术，测试体会以及工作质量等。 ?测试经理负责在项目测试总结中分析与总结测试数据，填写包括测试人员工作效率，人力资源消耗，测试过程中经验与教训，评价整个项目过程中的测试质量。 ?测试完成?测试经理负责批准测试完成。 ?所有测试人员在项目测试总结中签名，证明所有任务都已完成。 8.测试进度及时间资源?XX网银项目测试人员数量为15人，测试时间为450个工作日。 测试活动计划开始日期计划结束日期实际开始日期实际结束日期测试计划xx-10-24xx-10-27设计测试用例xx-10-26xx-11-4测试用例评审xx-10-27xx-11-5环境搭建xx-10-27xx-10-28系统测试xx-10-28xx-11-20性能测试xx-11-22xx-12-2测试总结报告xx-11-29xx-12-29.测试轮次安排?XXXX测试项目测试轮次视项目情况而定，通常分为2轮，每轮的工作根据轮次的推进而改变。 测试活动计划开始日期计划结束日期实际开始日期实际结束日期第一轮xx-10-28xx-11-12第二轮xx-11-13xx-11-20测试活动测试内容人员第一轮冒烟测试、功能测试15第二轮缺陷验证、冒烟测试、功能测试、用户界面测试、兼容性测试1510.测试方法1）功能类测试功能类测试是银行项目测试工作中的重点，在各个环节都需要有比较全面的考虑。 先考虑测试案例的组织结构，首先按照功能模块（通常对应系统中的一级菜单）归类，然后针对各功能模块下的每一个具体功能（即有独立页面的功能，简称子功能）再分类，分别设计不同方面的测试案例，案例的组织结构如下“XX模块”“XX叶子功能1”冒烟测试页面要素验证必输项验证输入项检查联动项检查本功能流程测试通过性测试失效性测试“XX叶子功能2”总体规则验证数据流转测试后台线程测试数据流转测试和后台线程测试，这两类案例可考虑根据情况，放在某一模块下，或者单独自成一部份。 对这几类测试，做一个简要的说明名称描述备注冒烟测试对本功能正常的主线流程进行验证而设计的案例此案例专门用来做冒烟测试，通常每个子功能只需提供一条该案例，设计时只需保证该功能的正常操作流程（即仅输入必要的有效数据）通过即可总体规则根据需求文档中提供的总体规则来设计的用例。 主要包括各个功能页面风格的一致性、操作习惯的一致、显示格式的统一等。 通常一个项目的总体规则是固定的，既要保证案例的执行覆盖度，又要避免案例的冗余，所以总体规则可由一个人完成设计，在各个模块下直接复用；测试执行时，可根据需要来进行执行情况的统计。 页面必输项验证执行该功能操作，页面中所必须录入/选择的项目，是否在为空的情况下仍然可以通过提交的检查。 各个页面的必输项不同，要考虑必输项的显示方式，以及非必输项是否也被做了必输限制等。 页面输入项检查主要指在客户端所进行的各类输入数据项的合法性的检查。 这部分案例主要指在客户端能够验证或限制的内容，如数据输入长度限制、是否含有非法字符等。 页面联动项检查主要指页面中多个输入或选择项目之间，根据前一项的结果而对其它项是否产生了约束的检查。 例如，城市的选择，选择了省之后，其下可选择的市，是否进行了列表更新等。 本功能流程测试当前功能本身的操作及数据流程正确性的测试，包括正常流程和异常流程。 例如，执行转账操作，输入正确和错误密码是否得到了正确的正常和异常返回结果；以及显示的返回结果是否与实际结果一致等。 数据流转测试主要指银行端与客户端之间的数据通讯是否准确，以及企业网银授权、审核流程的数据流转是否正确等。 例如，企业网银在银行端设定某种授权模式，在客户端是否正确体现等；或银行端修改了客户信息、发布了客户通知等在客户端是否正确体现等。 后台线程测试验证系统设定的在固定时间自动线程是否正确执行。 例如，系统设定每天凌晨1点，某系统自动从主机同步网点数据进行更新等。 注?“数据流转测试”从名称和范围上难与功能流程测试有明显划分的界限，可根据实际项目情况变更案例类别的名称，或明确规定试用范围；?实际项目中可能仍会有部分案例无法划分在上述的类别中，可根据实际情况进行调整，或单独形成一个补充案例。 例如，主机错误码在网银系统的情况，是由于网银数据库基础数据不完整，也应属于缺陷。 ?“冒烟测试”的案例，仅执行冒烟测试时使用，案例可能会与“本功能流程测试”的案例重复，但此处单独提出，便于测试的执行和统计，不算案例冗余。 2）兼容性测试兼容性测试主要应针对客户端，并且根据客户的要求并结合实际，来提供不同的测试方案，并非要盲目的兼容一切；B/S架构项目兼容性测试的重点，在于浏览器兼容的测试兼容对象测试重点备注操作系统文件证书的导入，移动证书的识别是否正常主要针对Vista系统测试，其他非MS操作系统根据需求以及可提供的驱动程序而定浏览器页面各功能的可用性，界面显示的美观、一致性此为兼容性测试的重点。 通常需要兼容IE 6、IE7Office类文档网银系统中导出或生成的各类数据，使用不同版本的office（包括非MS的office），是否都能够正常打开并准确显示通常以office97以上版本作为测试对象其它主流软件在网银系统的使用过程中，如果同时打开其他主流软件，是否会造成冲突（如QQ、MSN等）此测试仅能对已知的可能不兼容软件进行测试，无法达到全面测试，需要总结实际经验来完善硬件设备网银系统的使用中，对常见的输入设备是否支持良好，尤其在使用特殊控件的位置和独立的客户端系统中（如使用USB键盘等）此测试仅能对已知的可能不兼容设备进行测试，无法达到全面测试，需要总结实际经验来完善3）多语言测试?银行系统的界面中，非简体中文的语言应由用户来提供，或至少需要由用户确认语言使用的准确性；?重点测试，使用非简体中文的语言后，页面内容显示的位置、格式等美观性是否发生了变化，是否在可接受范围内；?多语言测试时，要对系统进行完整测试，以达到系统中各个位置（包括弹出的提示信息、异常时的错误信息等），都能够以相应的语言正确显示。 4）性能测试银行系统中，性能测试主要针对客户端进行测试，不同项目需求，对性能压力的要求有所不同，银行端在无特殊要求下无需进行性能测试。 性能测试的主要应用策略?负载测试不断增加压力，直到超出预期性能指标，或某种资源达到饱和状态。 (1)能找到系统所能承受的压力（在正常指标、资源范围内，如响应时间超过10秒，CPU大于70%） (2)可以配合系统调优?并发测试并发访问同一个应用或模块 (1)主要关注并发访问时，是否内存泄露、死锁、其它资源争用的问题。 (2)“并发用户数”的估算，需要结合实际，并根据特定计算公式得出。 ?疲劳测试较长时间的使系统处于一定压力下，看是否能够稳定运行。 (1)使CPU或其他资源处于较高的利用率下，持续运行一定时间，并关注整体运行状况。 (2)使CPU压力增大，可以等同于小压力情况下更长时间的运行效果，相当于是“压缩时间的测试”。 (一)基准测试测试方法对信贷管理系统的所列功能点进行基准测试，主要用于与响应时间性能指标的对比，以了解系统的整体性能状况。 测试场景对系统所有功能点（功能测试中的所有功能点），使用单个用户通过执行相应业务操作的测试脚本发起各项操作请求，在执行1小时后，初步诊断系统是否存在性能瓶颈，取响应时间的平均值作为测试的基准值。 编号用例需求点用户数量迭代次数迭代间隔执行时间（分钟）Think Time负载生成器量数11-0600121-0600131-0600141-06001 (二)并发测试并发测试的目的是为了验证系统在同一秒级50个用户的并发下，预警展现以及预警处理对系统资源的利用，以及所能达到的响应时间。 测试方法模拟服务器与终端用户之间的网络连接，对Loadrunner的虚拟用户使用512K的带宽限制设置，分别模拟50个用户同时（同一秒级）向同一功能点（单一业务）或多个功能点发出操作请求，测试系统的响应能力，包括响应时间以及CPU、内存、磁盘、网络等资源的使用状况，以验证系统对50个用户并发请求时的支持能力。 1）并发用户数量的设计a极限法根据性能需求，假设目前系统要求最大的并发用户数为50个。 选择不同的访问时间段，给系统50的查询处理并发量，并持续10分钟，在此过程中收集系统资源利用情况和响应时间（TPS,CPU%,Response Time）。 对于同一个场景，可以使用10，20，30，40不同的用户并发量（步进为10）。 b用户趋势分析按照今后N年的用户数量增长和业务增长（30）分析，N年后要达到的用户数量与业务量的并发要求。 假设N年后，最大并发用户数量是65，同时访问系统的最大用户数为1040。 选择不同的访问时间段，以步进为10逐步增加并发交易数量，直至到达最大并发用户数量65，在此过程中收集系统资源利用情况和响应时间（TPS,CPU%,Response Time）。 测试场景对本次性能测试所确定的典型业务功能点，通过Loadrunner模拟50个用户，同时（同一秒级）访问同一个典型业务功能（单一业务）或多个功能点（混合业务），持续10分钟，取响应时间的平均值，同时监测测试系统的各服务器资源使用情况。 ?单一并发测试场景编号用例需求点用户数量迭代次数迭代间隔执行时间Ramp Up持续时间Ramp DownThink Time负载生成器数量150010101250010101350010101?混合并发测试场景编号用例需求点用户数量迭代次数迭代间隔执行时间Ramp Up持续时间Ramp DownThink Time负载生成器数量110010101210010101310010101 (三)系统容量和扩展性测试系统容量测试和扩展性测试的目的是为了验证系统在最优配置下能达到的TPS（事务处理能力）及系统能处理的同时在线的最大用户数，不过测试过程中需要考虑到测试环境和实际生产环境的差异。 测试方法)找出系统的最优配置。 检测各项系统配置（内存、CPU速度、缓存、适配器等）对性能的影响。 选择典型场景测试事务处理能力，度量不同系统配置下的系统事务处理能力，从而确定哪一种设置能够提供理想的性能级别。 在测试过程中一旦发现系统资源利用率不再增长的时候，修改相应的配置参数（如，Oracle的参数设置，软硬件的配置）并继续测试，如果修改之后TPS并没有明显的变化或者系统出错的情况发生，则认为修改前的配置为系统的最优配置。 )在最优配置下测试系统的容量。 考虑性能需求以及N年后的业务增长。 )测试集群数量与可容纳用户数量的实际关系，理论状况下为线性关系。 测试场景 （1）找出系统最优容量，并确定最优配置编号用户数响应时间应用服务器资源使用情况数据库资源使用情况成功率1152303 （2）在最优配置下的系统最大容量（性能拐点）编号用户数响应时间应用服务器资源使用情况数据库资源使用情况成功率1152303 (四)稳定性测试稳定性测试的目的是为了验证系统在一段时间内进行高负载和低负载转换时，系统的承受能力，其是否可以正常运行，发现系统潜在的性能问题。 测试方法通过交叉的进行高压和低压测试服务器负载，连续运行情况下的状况跟踪。 测试时选取混合业务场景，按照一定比例，对混合场景进行配比，并进行一段时间的高压和低压的交替测试，确定交替间隔时间。 高压的标准时是CPU的使用率约在70；而低压的标准是使CPU的使用率约在20。 测试场景选择使用频率较高的功能（不同的功能之间的耦合）组成一个测试用例。 (五)破坏性测试疲劳测试主要测试系统在长时间运行后的处理能力，确定系统是否能够继续安全有效的正常提供服务。 测试方法通过持续不断的调用测试脚本，模拟一定数量的用户发起操作请求，对系统形成一定的压力并长时间运行，通过长时间持续的压力，验证系统在长时间运行后，用户对系统访问操作的成功率是否降低，以找出系统潜在的内存泄漏等问题。 本次性能疲劳测试计划使用800个在线用户，按照业务人员提供的典型业务功能比例进行分配，执行724小时。 测试场景编号场景名称在线总用户数执行时间成功率完成业务数量1疲劳测试800个用户724小时 (六)测试时间表轮次开始日期结束日期性能测试第一轮待定待定第二轮待定待定 (七)性能测试测试进度表编号任务任务启动条件计划启动时间计划结束时间（T）（T+D）1测试环境准备完成测试计划，测试环境、测试数据准备完毕待定2测试案例设计具有软件需求说明书待定2脚本开发功能稳定，性能测试环境准备完毕待定3场景设计测试脚本开发完毕待定4测试执行测试环境搭建完毕、测试脚本开发完毕、场景设计完毕待定5测试总结性能测试执行完毕待定11.测试输入输出标准?测试产品?输入项目业务需求分析说明书?输出项目系统测试计划，项目系统测试用例，项目测试总结?测试规则1）冒烟测试?输入编码已完成。 ?输出所有版本检查测试用例的执行结果必须为通过。 2）系统测试?输入版本检查测试已完成。 ?输出所有等级为1和2的缺陷必须已经被修复，剩余的未修复的等级为3的缺陷数量必须少于3个，剩余的未修复的等级为4缺陷数量必须少于5个。 ?测试用例通过标准如果实际输出结果与期望输出结果相符合，则此用例可以标注为通过，否则就标注为失败。 并将缺陷提交到Quality Center。 ?暂停恢复测试标准1）暂停测试标准如果在测试过程中发现严重的缺陷，导致产品不能正常运行，项目经理和测试经理可以同意暂停测试，其标准如下?测试环境问题。 ?源程序中包含一个或多个导致测试不能继续进行的致命缺陷。 ?架构重新设计，重新开发，需求改变。 2）恢复测试标准严重缺陷被修复后，测试进程可以继续进行，所需标准如下?导致测试暂停的致命缺陷已被修复