资源描述
.wd.工程名称集成测试方案会签部门及职能 技术部：_ 研发部：_ 测试组：_ 管理者代表：_绝密性绝密阅读者部门全体员工修 改 记 录版本修改原因修改内容发起人生效日期制作人部门日期文件发行管制章批准签名日期审查核准目录1.前言31.1.目的31.2.范围31.3.术语31.4.测试环境41.5.参考文件42.产品描述52.1.功能描述52.2.当前版本53.测试概述53.1.测试目标53.2.测试步骤53.3.测试方法73.4.进入准那么73.5.完毕准那么73.6.考虑事项84.控制和协调84.1.测试用例检查和质量控制84.2.测试流程84.3.开发组和测试组之间程序版本控制95.资源需求和依赖条件105.1.软/硬件依赖条件105.2.测试数据需求105.3.测试人员需求106.进度表101. 前言1.1. 目的本文是描述XXX管理系统的集成测试的大纲文章，主要描述如何进展集成测试活动，如何控制集成测试活动，,集成测试活动的流程以及集成测试活动的工作安排等。保证程序连接起来也能正常的工作，保证程序的完整运行。1.2. 范围本次测试方案主要是针对软件的集成测试：不含硬件，系统测试，以及单元测试需要已经完成单元测试主要的任务是：1.测试在把各个模块连接起来的时候，穿越模块接口的数据是否会丧失；2.测试各个子功能组合起来，能否到达预期要求的父功能；3.一个模块的功能是否会对另一个模块的功能产生不利的影响；4、全局数据构造是否有问题；5、单个模块的误差积累起来，是否会放大，从而到达不可承受的程度。主要测试方法是：使用黑盒测试方法测试集成的功能。并且对以前的集成进展回归测试本文主要的读者对象是：工程负责人，集成部门经理，测试工程师。1.3. 术语软件测试：软件测试是根据软件开发各阶段的规格说明和程序的内部构造而精心设计一批测试用例，并利用这些测试用例运行软件，以发现软件错误的过程。测试方案：测试方案是指对软件测试的对象、目标、要求、活动、资源及日程进展整体规划，以保证软件系统的测试能够顺利进展的方案性文档。测试用例：测试用例指对一项特定的软件产品进展测试任务的描述，表达测试方案、方法、技术和策略的文档；内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。测试对象：测试对象是指特定环境下运行的软件系统和相关的文档。作为测试对象的软件系统可以是整个业务系统，也可以是业务系统的一个子系统或一个完整的部件。测试环境：测试环境指对软件系统进展各类测试所基于的软、硬件设备和配置。一般包括硬件环境、网络环境、操作系统环境、应用服务器平台环境、数据库环境以及各种支撑环境等。1.4. 测试环境序号描述配置1#浏览器IE & Firefox2#输入习惯中文4#操作系统环境Windows XP1.5. 参考文件开场测试需要以下文档：l ?需求方案书?-Requirement Analysisl ?工程方案表?- Project Planl ?软件设计书?-Software Designl ?单元测试报告?-Module Test Reportl ?用户手册?- User Manual开场测试前必须完成的任务：l 软件编码；l 单元测试；完毕时提交的文档：l ?测试方案书?；l ?测试用例?；l ?测试报告?；l ?测试总结?；l ；2. 产品描述2.1. 功能描述参照?需求说明书?、?功能说明书?。2.2. 当前版本系统 版本：1.0。3. 测试概述3.1. 测试目标l 接口：接口提供的功能或者数据正确。l 功能点：验证程序与产品描述、用户文档中的全部说明相对应，一致性。l 流程处理：验证程序与产品描述、用户文档中的全部说明相对应，一致性l 外部接口：验证程序与产品描述、用户文档中的全部说明相对应，一致性l 界面：美观、易用、合理3.2. 测试步骤在本工程中：采取以下几个步骤：1.设计?集成测试设计用例?自底向上集成测试的步骤步骤1: 按照概要设计规格说明，明确有哪些被测模块。在熟悉被测模块性质的根基上对被测模块进展分层，在同一层次上的测试可以并行进展，然后排出测试活动的先后关系，制定测试进度方案步骤2: 在步骤1的根基上，按时间线序关系，将软件单元集成为模块，并测试在集成过程中出现的问题。步骤3: 将各软件模块集成为子系统或分系统。检测各自子系统是否能正常工作。可能需要测试人员开发少量的驱动模块来驱动被测子系统。 步骤4: 将各子系统集成为最终用户系统，测试是否存在各分系统能否在最终用户系统中正常工作。2.集成测试：组织人员按照1中的?集成测试设计用例?测试系统集成度。.测试人员按照测试用例逐项进展测试活动,并且将测试结果填写在测试报告上；测试报告必须覆盖所有测试用例.测试过程中发现Bug，将Bug填写在缺陷记录上发给工程经理；.对应责任人接到工程经理发过来的Bug.对于明显的并且可以立刻解决的Bug，将Bug发给开发人员；对于不是Bug的提交，工程经理通知测试设计人员和测试人员，对相应文档进展修改;对于目前无法修改的,将这个Bug放到下一轮次进展修改； 3.问题反响：反响Bug给开发人员。.开发人员接到发过来的Bug立刻修改，并填写单元测试报告;.测试人员接到工程经理发过来的错误更改信息，应该逐项复测，填写新的测试报告测试报告必须覆盖上一次的测试用例；4.回归测试：重新测试修复Bug后的系统。重复3，直到4回归测试结果到达系统验收标准。.如果复测有问题返回第2步，否那么关闭这项BUG本轮测试中测试用例中有90一次性通过测试,完毕测试任务；本轮测试中发现的错误有95经过修改并且通过再次测试，返回进展新的一轮测试；5.集成测试测试总结报告：完成以上4步后，综合相关资料生成报告。6.进入系统测试3.3. 测试方法3.3.1黑盒测试黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能翻开的黑盒子，在完全不考虑程序内部构造和内部特性的情况下，在程序接口进展测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。3.3.2黑盒测试的方法有：具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。 等价类划分的方法是把程序的输入域划分成假设干局部子集，然后从每个局部中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。该方法是一种重要的，常用的黑盒测试用例设计方法。3.4. 进入准那么l 编码阶段已经审核完成l 单元测试已经完成l 工程经理已经批准了集成测试方案l 测试组已经设计好测试案例，经过测试组组长的检查，并通过工程经理批准l 测试数据已经准备好并经过检查l 测试资源已经到位软件、硬件、人力3.5. 完毕准那么l 测试遇到的所有问题已经记录下来l 所有测试案例都已运行l 90的测试案例已经成功通过l 所有测试案例至少运行了三次，所有错误已经修改l 测试结果已经记录，测试分析报告已经提交工程经理检查3.6. 考虑事项l 单元划分l 模块关联接口l 重要的实行路径l 错误处理l 极端条件l 数据准确性l 基于程序说明的测试案例4. 控制和协调4.1. 测试用例检查和质量控制所有测试用例应该经过工程经理及测试主管的检查。严格按照测试方案时间表执行，如有推迟那么适当调整方案时间，并记录原因。如需求有变动，工程经理负责协调开发与需求人之间进展沟通，对方案及时调整。4.2. 测试流程4.3. 开发组和测试组之间程序版本控制为测试人员提供可执行的软件环境，开发人员负责对其内容的修改。所有开发人员必须在自己的工作站保存最新版本的代码，不得变更测试程序目录下的内容。在修改之前，由开发人员通知测试人员将做哪些修改和修改将影响的功能。5. 资源需求和依赖条件5.1. 软/硬件依赖条件软/硬件名称数量开场日期截至日期说明5.2. 测试数据需求在测试案例运行前，应准备所有需要的测试数据。5.3. 测试人员需求l 测试组组长：研发经理l 测试人员：测试组人员l 测试用例设计人员：测试组人员l 测试数据准备人员：测试组人员l 测试运行人员：测试组人员6. 进度表测试用例工作量负责人方案开场日期方案完毕日期排课功能与课时消耗功能关联4天XXX2012.09.132012.09.16测试用例-排课功能与课时消耗功能关联测试执行步骤工作量负责人方案开场日期方案完毕日期编写用例1天执行用例1天修复bug1天回归测试、测试报告1天
展开阅读全文