EBMV1.0测试计划.doc

EBMV1.0 测试策略一、简介1. 目的本测试报告为EBMV项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求。预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。2. 范围本系统定位于一个能够满足中小型软件研发团队对软件缺陷进行跟踪和处理的缺陷信息管理系统。本系统分为两大子系统：系统管理和缺陷管理。系统管理的主要完成系统初始化设置和系统信息管理等在内的相关任务，包括设置EBM系统本身初始化所需的各种参数、登记和维护项目基本信息、被测软件相关的各项参数、系统用户信息、用户密码管理等。缺陷管理主要完成缺陷管理相关的信息记录、流程控制、缺陷查询和统计等任务，包括对缺陷跟踪中每一步骤提交、审核、定位、修改、验证和关闭等的处理、记录缺陷处理的历史信息、提供缺陷查询功能和缺陷统计功能、根据缺陷数据库，生成管理和跟踪缺陷所需要的各种统计报表以帮助用户对项目缺陷进行统计和管理。本系统适合跟踪和管理在软件研发过程发现的缺陷信息，不适合软件发布后，由用户发现缺陷的跟踪和管理。二、测试综述1. 测试过程定义为了配合测试教学，将EBMV 1.0 测试过程分为单元测试、集成测试、系统测试三个级别。单元测试是基于代码的测试，集成测试进行和单元之间的交互测试，系统测试主要验证整个软件系统的业务流程是否符合要求a) EBMV 1.0 的单元测试包括如下具体活动：l 开发单元测试计划和测试用例。l 单元测试计划和用例评审l 规划单元测试环境，包括搭建和制定环境维护策略l 执行单元测试l 提交缺陷问题报告单并进行回归测试l 编写单元测试报告l 单元测试报告评审l 单元测试阶段资产基线l 单元测试阶段审计b) EBMV 1.0 的集成测试包括如下具体活动：l 开发集成测试计划和测试用例。l 集成测试计划和用例评审l 规划集成测试环境，包括搭建和制定环境维护策略l 执行集成测试l 提交缺陷问题报告单并进行回归测试l 编写集成测试报告l 集成测试报告评审l 集成测试阶段资产基线l 集成测试阶段审计c) EBMV 1.0 的系统测试包括如下具体活动： l 开发系统测试计划和测试用例。l 系统测试计划和用例评审l 规划系统测试环境，包括搭建和制定环境维护策略l 执行系统测试l 提交缺陷问题报告单并进行回归测试l 编写系统测试报告l 系统测试报告评审l 系统测试阶段资产基线l 系统测试阶段审计EBMV 1.0 的单元测试和集成测试由代码的相关开发人员承担，系统测试由测试工程师承担。为确保各类测试活动尤其是测试执行活动的顺利展开，在测试级别周期不超过一周的情况下，相关责任人每天必须提交测试日报。在测试级别周期超过一周的情况下，如果进度正常，相关责任人提交周报；如果进度滞后，从接到测试经理通知开始，相关责任人提交日报。2. 测试活动当进度、质量和成本之间出现矛盾时，对于高优先级别的测试对象以质量为重，保证各类资源的供给。对于低优先级别的测试对象以进度为主，低级别测试用例可不执行但必须标注。另外，为了减轻桩和驱动代码的开发，可以考虑集成测试可以个单元测试合并。在测试期间产生的无法调解的冲突全部提请CCB进行裁决。三、单元测试策略单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。 单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。1. 入口准则下列条件满足时，EBMV 1.0 的单元测试正式开始：l 被测代码走读通过。l 代码基线完成。l 单元测试计划和用例开发完毕通过评审。2. 出口准则下列条件满足时，EBMV 1.0 的单元测试可以结束：l 所有测试用例执行完毕，被测代码达到100% 分支覆盖。l 发现缺陷每千行代码5个且处于各种状态的缺陷呈收敛趋势。l 所有提交缺陷修改完毕并且通过回归测试。l 单元测试报告开发完毕通过评审并获得批准。3. 测试质量要求1) 覆盖率单元测试必须达到100%语句覆盖，100%分支覆盖并提供相应的覆盖报告。2) 覆盖策略在单元测试过程中，采用测试工具PuerCoverage 收集覆盖信息以提供覆盖率的客观说明。如果现有测试用例无法达到覆盖指标时，可增加测试用例或者提请测试经理说明无法到达覆盖指标要求的原因并获得批准。3) 缺陷处理流程EBMV 1.0 的单元测试和集成测试由代码的相关开发人员承担，发现缺陷原则上由开发人员本人修正。要求开发工程师发现自己的每个缺陷必须提交，缺陷修改完成也必须验证，所有监控环节均分为开发人员自身，即自己提交缺陷、自己审核、自己验证，杜绝出现现修改代码后补交缺陷报告单的情况。4. 需要的软件工具l Eclipse 3.2 及以上版本用于代码修改。l Mysql 6.0 数据库。l JUnit 3.8/4.3.1 用于测试脚本实现。l PuerCoverage 用于手机覆盖信息l Purify用于内存检测5. 人力资源和硬件资源EBMV 1.0 单元测试人员2人，既表现层、业务逻辑层和数据库层代码的开发人员，测试环境使用开发工程师自己开发的环境6. 被测试对象依赖关系由于各个类之间独立测试，五依赖关系。l 集成测试策略集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。1. 入口准则下列条件满足时，EBMV 1.0 的集成测试正式开始：l 单元测试结束报告已提交。l 单元测试代码基线。l 单元测试计划和用例开发完毕通过评审。l 测试环境准备完毕，人员到位。2. 出口准则下列条件满足时，EBMV 1.0 的集成测试可以结束：l 所有测试用例执行完毕，所有消息均被覆盖。l 发现缺陷每千行代码2个。l 处于各种状态的缺陷呈收敛趋势。l 集成测试报告已提交并审批通过。3. 测试质量要求1) 覆盖率每个功能在表示层、业务逻辑层和数据库层上的接口必须达到100%的交互语句覆盖。2) 覆盖策略通过提供包含被测试接口及其测试用例的跟踪矩阵判读是否达到100%覆盖。3) 缺陷处理流程由于集成测试也是由开发人员自己进行，因此在集成测试阶段其处理流程和单元测试阶段相同。4. 需要的软件工具l Eclipse 3.2 及以上版本用于代码修改。l Mysql 6.0 数据库。l JUnit 3.8/4.3.1 用于测试脚本实现。5. 人力资源和硬件资源EBMV 1.0 集成测试人员2人，既表现层、业务逻辑层和数据库层代码的开发人员，测试环境使用开发工程师自己开发的环境l 系统测试策略系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。对象不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。1. 入口准则下列条件满足时，EBMV 1.0 的系统测试正式开始：l 集成测试结束报告已提交。l 集成测试代码基线。l 系统测试项全部通过。l 系统测试计划和用例开发完毕并通过评审。2. 出口准则下列条件满足时，EBMV 1.0 的系统测试可以结束：l 达到100%功能覆盖和100%典型用户使用场景覆盖。l 发现缺陷数目不超过每千行代码3个。l 处于各种状态的缺陷呈收敛趋势。l 缺陷修改完毕并经过回归测试验证。l 系统测试报告已提交并通过评审并获得批准。3. 测试质量要求1) 覆盖率EBMV 1.0测试必须达到100%功能覆盖和100%典型用户使用场景覆盖。2) 覆盖策略通过需求跟踪矩阵判和用户使用场景测试跟踪矩阵是否达到100%覆盖。3) 缺陷处理流程EBMV 1.0 系统测试由测试工程师承担，系统测试中发现的缺陷由相应的开发人员负责修改，缺陷的审核人为项目经理，指派缺陷的定位和修改人采用相关代码开发人员优先的原则，缺陷修改后缺陷提交人验证并确认修改。4. 人力资源和硬件资源EBMV 1.0 系统测试约需要3名测试人员和2名开发人员，测试人员其中一人负责测试计划，两人负责测试设计、实现、执行和报告工作，开发人员负责修改在系统测试阶段发现的缺陷。l 相关约定1. 缺陷严重级别说明缺陷严重性级别是站在用户使用系统的角度，根据发现缺陷对正常使用系统的影响程度对缺陷的分级方法。为了达成一致理解，在EBMV 1.0 系统测试中，将缺陷分为“致命”、“严重”、“建议”四个等级。严重级别说明致命导致