项目管理集成测试计划.docx
《项目管理集成测试计划.docx》由会员分享，可在线阅读，更多相关《项目管理集成测试计划.docx（16页珍藏版）》请在冰豆网上搜索。
项目管理集成测试计划
RichWay项目管理系统
集成测试计划
北京江河瑞通技术发展有限公司
二○一○年十月
编制
谢丽芬
日期
2010-10-20
校对
日期
审批
日期
1简介
1.1目的
编写《RichWay项目管理系统》的这一“集成测试计划”文档有助于实现以下目标：
▪明确系统集成测试的测试方法、工作量及使用资源
▪明确系统集成的范围、集成环境及集成过程中的风险
▪指导《系统集成测试用例》的设计和编写
▪明确用于验证系统集成测试结果的验证标准
▪明确系统集成测试的工作流程及异常问题的解决办法
本文主要的读者对象是：
项目经理，测试经理、测试人员。
1.2背景
随着北京江河瑞通公司业务的发展，公司的项目越来越多，公司领导已经无法通过以前的方式（如问讯）来了解各个项目进度，甚至部门经理无法了解本部门多个项目的进展情况，不知道项目的完成了多少，不知道项目何时能完成，不知道项目是否已经超过合同规定的期限，所以现在需要建设一个项目管理系统将公司的项目信息管理起来，让公司领导和相关负责人随时可以查询项目进展情况，并根据项目的进展情况对项目开发进行适当的调整。
另外公司的各类项目文档资料，公共技术资料依然不能有效的共享，主要是缺乏一个适合公司使用的，有效的文档管理工具。
公司已经决定按照CMMI流程运作软件项目，CMMI的成果（主要是文档）的管理和监督也缺乏一个有效的文档管理工具。
要做到上述的文档容易归档、容易查找，所以还要形成一套文档管理系统，用于管理公司项目文档和公共文档。
同时还要考虑该系统将会根据公司业务的发展，不断地扩展功能，系统需要能根据公司的业务调整灵活调整系统的业务流程，所以该系统的设计需要具备灵活性和可扩充性。
1.3术语和缩略语
测试用例：
测试用例指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略的文档；内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。
测试对象：
测试对象是指特定环境下运行的软件系统和相关的文档。
作为测试对象的软件系统可以是整个业务系统，也可以是业务系统的一个子系统或一个完整的部件。
测试环境：
测试环境指对软件系统进行各类测试所基于的软、硬件设备和配置。
一般包括硬件环境、网络环境、操作系统环境、应用服务器平台环境、数据库环境以及各种支撑环境等。
1.4参考资料
《RichWay软件项目管理系统需求规格说明书》
《RichWay软件项目管理系统产品设计说明书》
《RichWay软件项目管理系统单元测试报告》
1.5约束
1、开始测试前必须完成的任务：
软件编码
单元测试
2、结束时提交的文档：
《测试用例》
《测试报告》
2范围
本次测试计划主要是针对RichWay项目管理系统的集成测试：
不含硬件，系统测试，以及单元测试（需要已经完成单元测试）。
主要的任务是：
1、测试在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
2、测试各个子功能组合起来，能否达到预期要求的父功能；
3、一个模块的功能是否会对另一个模块的功能产生不利的影响；
4、全局数据结构是否有问题；
5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。
主要测试方法是：
使用黑盒测试方法测试集成的功能。
并且对以前的集成进行回归测试。
3集成的策略
3.1进入标准
编码完成，单元测试完成。
测试计划完成，时间表以及人员安排到位。
3.2集成元素
1、子系统集成：
项目管理：
主要指对项目基本信息的管理。
公共文档管理：
文档管理用于管理公司的公共文档（如CMMI模板、参考文档、技术文档），做到文档易于归档，易于检索，易于共享。
项目文档管理：
项目文档管理用于管理和项目相关的文档，如前期文档、需求文档、设计文档和测试文档。
项目文档可以按照项目、项目类别、文档类别来检索文档，项目文档在管理上会根据不同人的参与情况以及人员角色进行文档检索、查看权限的管理。
2、功能集成：
有关增加，删除，修改，查询各个数据的操作。
3、数据集成：
数据传递是否正确，对于传入值的控制范围是否一致等等
3.3集成策略
本系统的集成测试采用自底向上的集成（Bottom-UpIntegration）的方式。
自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。
因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。
选择这种集成方式，管理方便、测试人员能较好地锁定软件故障所在位置。
集成测试中的主要步骤：
（1）制定审核测试计划
（2）制定和审核测试用例
（3）进行测试活动
（4）书写测试报告
如下表:
活动
输入
输出
职责
制定集成测试计划
设计模型
集成构建计划
集成测试计划
制定测试计划
设计集成测试
集成测试计划
设计模型
基础测试用例
测试过程
集成测试用例测试过程
实施集成测试
集成测试用例
测试过程
工作版本
测试脚本
测试过程
编制测试代码更新测试过程
测试驱动（底向上）
编制驱动或桩
执行集成测试
测试脚本
工作版本
测试结果
测试并记录结果
评估集成测试
集成测试计划
测试结果
测试报告
会同开发人员评估测试结果,得出测试报告
表1
3.4集成顺序
3.4.1软件集成顺序
集成顺序：
自底向上，先子模块，再子系统（顶级模块）。
3.4.2子系统集成顺序
功能集成：
先查找，后增加，删除，修改。
子系统集成：
先项目管理模块，后项目文档管理、公共文档管理等。
4测试策略
4.1测试步骤
在本项目中：
采取以下几个步骤：
1、编写《集成测试用例》
自底向上集成测试的步骤
步骤1:
按照概要设计规格说明，明确有哪些被测模块。
在熟悉被测模块性质的基础上对被测模块进行分层，在同一层次上的测试可以并行进行，然后排出测试活动的先后关系，制定测试进度计划。
步骤2:
在步骤1的基础上，按时间线序关系，将软件单元集成为模块，并测试在集成过程中出现的问题。
这里，可能需要测试人员开发一些驱动模块来驱动集成活动中形成的被测模块。
对于比较大的模块，可以先将其中的某几个软件单元集成为子模块，然后再集成为一个较大的模块。
步骤3:
将各软件模块集成为子系统（或分系统）。
检测各自子系统是否能正常工作。
同样，可能需要测试人员开发少量的驱动模块来驱动被测子系统。
步骤4:
将各子系统集成为最终用户系统，测试是否存在各分系统能否在最终用户系统中正常工作。
2、集成测试：
组织人员按照1中的《集成测试用例》测试系统集成度。
①测试人员按照测试用例逐项进行测试活动，并且将测试结果填写在测试报告上；（测试报告必须覆盖所有测试用例）
②测试过程中发现Bug，将Bug填写在bugzilla上发给项目经理；（Bug状态NEW）
③对应责任人接到bugzilla发过来的Bug。
④对于明显的并且可以立刻解决的Bug，将Bug发给开发人员；（Bug状态ASSIGNED）对于不是Bug的提交，项目经理通知测试人员，对相应文档进行修改；（Bug状态RESOLVED，决定设置为INVALID）；对于目前无法修改的,将这个Bug放到下一轮次进行修改；（Bug状态RESOLVED，决定设置为REMIND）
3、问题反馈：
反馈Bug给开发人员。
①开发人员接到发过来的Bug立刻修改;（Bug状态RESOLVED，决定设置为FIXED）
②测试人员接到bugzilla发过来的错误更改信息，应该逐项复测，填写新的测试报告（测试报告必须覆盖上一次中所有REOPENED的测试用例）；
4、回归测试：
重新测试修复Bug后的系统。
重复3，直到4回归测试结果到达系统验收标准。
①如果复测有问题返回第2步（Bug状态REOPENED），否则关闭这项BUG（Bug状态CLOSED）
本轮测试中测试用例中有90％一次性通过测试，结束测试任务；
本轮测试中发现的错误有95％经过修改并且通过再次测试（即Bug状态CLOSED），返回进行新的一轮测试；
5、集成测试测试总结报告：
完成以上4步后，综合相关资料生成报告。
6、进入系统测试，ALPHA测试，BETA测试
如下图:
图2.流程图
4.2测试要点
1、功能点：
根据用户文档列出所有功能点，检验其正确性；
2、接口：
根据用户文档列出所有接口，检验其正确性；
3、流程处理：
根据用户文档列出所有流程，检验其正确性；
4、外部接口：
根据用户文档列出所有外部接口，检验其正确性；
4.3测试类型
4.3.1功能测试
按照相关文档，结合需求，代码设计，测试各个功能模块是否能实现相应功能。
测试目标
确保测试的功能正常，其中包括导航、数据输入、处理、检索、流程控制等功能。
技术
利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：
在使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警告消息。
各业务规则都得到了正确的应用。
完成标准
全部设计功能均已实现、接口之间数据传输准确无误、流程控制符合要求。
需考虑的特殊事项
4.3.2用户界面测试
按照相关文档，结合需求，代码设计，测试各个功能模块是否能实现相应功能。
测试目标
核实以下内容：
通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动）的使用窗口的对象和特征（例如，菜单、大小、位置、状态和中心）都符合标准。
技术
为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。
完成标准
成功地核实出各个窗口都与基准版本保持一致，或符合可接受标准。
需考虑的特殊事项
各模块根据用户权限有访问限制。
4.3.3性能测试
性能评测是对功能操作过程中的响应时间、事务处理速率、系统在超出最大预期工作量要求、资源不足或资源争用等情况发生时，核实是否满足系统的性能要求。
测试目标
客户端对普通界面操作请求的平均响应时间小于3秒
客户端对图表图形界面操作请求的平均响应时间小于5秒
系统在应用服务器几乎没有可使用内存时不会崩溃
数据库连接池达到最大限制时系统能够正常运行
系统在网络带宽不足时能够正常运行
技术
借助性能测试工具辅助测试
通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的次数
脚本以单个用户、单个事务为基准，并在多台测试机上运行
完成标准
单个事务或单个用户：
在每个事务所预期或要求的时间范围内成功地完成测试脚本，没有发生任何故障
多个事务或多个用户：
在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。
需考虑的特殊事项
复杂报表、查询功能，系统维护功能不在此要求范围内
性能测试应该在专用的测试机上或在专用的机时内执行，以便实现完全的控制和精确的评测。
测试中所用的数据库应该是实际大小或相同缩放比例的数据库。
4.3.4容量测试
容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。
测试目标
系统支持10年在线数据表示（按100人，每人每天产生1KB数据量计算）。
数据库磁盘空间是否能够支持10年在线数据的预期最大量
网络带宽是否能够支持100人同时在线传输大数据量的情况
技术
通过人均每日数据量、时间和在线人数计算最大的数据总量
通过人均传输数率、在线人数计算最大带宽使用情况
完成标准
所计划的测试已全部执行，而且在达到或超出指定的系统限制时没有出现任何软件故障。
需考虑的特殊事项
时间段对在线数据量和传输数据量的影响
4.3.5安全性和访问控制测试
在《RichWay项目管理系统》中，系统的安全性和访问权限有严格的要求。
因此，本系统集成测试阶段的安全性和访问控制将如下进行：
测试目标
应用程序级别的安全性：
不同用户只能访问其所属用户类型已被授权访问的那些功能或数据。
未被授予系统访问权限的用户无法登陆应用系统并执行操作。
系统级别的安全性：
系统运行在内部局域网，不允许从外网访问。
只有被授予管理权限的角色可以检查或更改应用服务器及数据库服务器等的配置。
技术
应用程序级别的安全性：
确定并列出各用户类型及其被授权访问的功能或数据。
为各用户类型创建测试，并通过创建各用户类型所特有的事务来核实其权限。
修改用户类型并为相同的用户重新运行测试。
对于每种用户类型，确保正确地提供或拒绝了这些附加的功能或数据。
系统级别的访问：
不为应用服务器配置外网IP地址或在防火墙做设置。
完成标准
各种已知的用户类型都可访问相应的功能或数据，而且所有事务都按照预期的方式运行，并在先前的应用程序功能测试中运行了所有的事务。
需考虑的特殊事项
由于此测试可能是网络管理或系统管理的职能，可能会不需要执行此测试。
5测试准则
5.1集成测试通过标准
5.1.1模块通过标准
接口：
接口提供的功能或者数据正确。
功能点：
验证程序与产品描述、用户文档中的全部说明相对应，一致性。
流程处理：
验证程序与产品描述、用户文档中的全部说明相对应，一致性。
外部接口：
验证程序与产品描述、用户文档中的全部说明相对应，一致性。
5.1.2集成测试通过标准
首先，《集成测试用例》中所设计的功能测试用例必须全部通过，性能及其他类型测试用例通过90%以上。
在未通过的测试用例中，不能含有‘系统崩溃’和‘严重错误’错误，‘一般错误’小于5%。
测试结果与测试用例中期望的结果一致，测试通过，否则标明测试未通过。
▪测试回归申请结束
测试人员提出申请这轮测试结束，提交测试经理；
测试经理召集本组人员开会讨论；
讨论通过，进行下一轮测试，并且部署下一轮测试的注意事项，流程等内容；
如果发现这轮测试目前还存在问题没有解决，延期下一轮测试时间，讨论下一步工作应该如何进行。
▪测试结果申请结束
测试人员提出申请测试结束，提交测试经理；
测试经理召集本组人员开会讨论；
讨论通过，结束测试任务；
如果发现目前测试还存在问题没有解决，延期测试结束时间，并且讨论下一步工作应该如何进行。
5.2挂起、恢复和退出条件
5.2.1挂起
进入第一轮测试，测试人员大体了解一下产品情况，如果在一小时之内发现5个以上（含5个）操作性错误，或者3个以上（含3个）功能性错误，则冒烟测试未通过，退回单元测试组测试；
遇到有项目优先级更高的集成测试任务；
遇到有项目优先级更高的集成任务；
在测试复测过程中发现产品无法运行下去；
人员，设备不足；
重大突发紧急情况；
5.2.2恢复
符合进入集成测试条件（一小时之内发现5个以下（不含5个）操作性错误，或者3个以下（不含3个）功能性错误）通过冒烟测试；
项目优先级更高的集成测试任务暂告完成；
项目优先级更高的集成任务暂告完成；
复测过程中产品可以运行下去；
人员，设备到位；
突发事件处理完成；
5.2.3退出
项目因故终止；
不可抗力：
合同专用条款中约定等级以上的自然灾害也属不可抗力；
其他原因的测试工作频频被挂起或者挂起后迟迟恢复不了，并过了客户要求的时期。
6测试环境
6.1测试环境
序号
条目
目的/
用途
规格要求
数量
获取方式/
最晚到位时间
备注
1
测试服务器
搭建
测试
环境
内存：
4G；
硬盘：
250G；
CPU：
2.53GHZ
1
公司测试
服务器
操作系统：
Windows2003
数据库：
Oracle10g
Java服务：
Tomcat6.0+JDK1.5
2
测试人员用电脑
内存：
2G；
硬盘：
250G；
CPU：
2.53GHZ
公司标配
操作系统：
WindowsXP/2003
浏览器：
IE5.0及以上
6.2测试工具
类型
工具
产商/自产
版本
测试管理工具
bugzilla
性能测试工具
LoadRunner
Mercury
8.1
项目管理
Project
Microsoft
2003
数据库管理工具
Oracle10g
其他工具
Word
7测试人员
7.1角色划分
测试人员分为以下角色：
测试经理：
对整个项目组负责。
测试设计和执行组：
进行测试用例的设计和测试工作的执行。
将整个系统按照模块进行划分。
为了使每一个测试人员对自己测试模块的。
每一个模块的设计和执行为同一个人。
技术支持组：
测试工作的平台，包括测试用的各类数据库的维护；系统运行环境的搭建。
7.2人员安排
测试经理：
谢丽芬
参与单元测试和集成测试的开发人员：
郑冰，王利维，吴谢平，李德云
测试设计和执行组：
陈杰，彭文蕾
8进度计划
序号
任务
负责人
开始时间
终止时间
输出
1
编写集成测试计划
谢丽芬
《集成测试计划》
2
编写集成测试用例
陈杰
《集成测试用例》
3
测试用例评审
谢丽芬
4
执行集成测试
陈杰、彭文蕾
5
BUG反馈及修改
6
回归测试
陈杰、彭文蕾
7
编写集成测试总结
陈杰、彭文蕾
2011-01-23
2011-01-25
《集成测试总结报告》
9风险和应急
可能出现的问题
对项目的影响
解决办法
测试文件中无大容量文件
不能模拟大文件上传情况
暂时用视频文件代替
升级会员 