PDE数字档案管理系统V729的测试与管理项目报告.docx
《PDE数字档案管理系统V729的测试与管理项目报告.docx》由会员分享，可在线阅读，更多相关《PDE数字档案管理系统V729的测试与管理项目报告.docx（42页珍藏版）》请在冰点文库上搜索。
PDE数字档案管理系统V729的测试与管理项目报告
项目名称
PDE数字档案管理系统V7.2.9的测试与管理
院系
计算机与软件学院
专业
班级
学号
学生姓名
摘要
档案信息化是档案工作向现代化迈进的必由之路，必须加强档案信息化建设。
建立一套适应本公司业务特点、体现本公司规范化、科学管理水平的档案体系，是企业必须做好的一项基础性工作。
它将为公司各项综合业务、研究工作的开展创造必要条件，对避免和抵御各种风险起到了必备作用。
本论文就是以一个提供给国家机构、各企事业单位等行业的档案管理系统作为解决方案的背景，主要是对档案管理系统的一些重要功能和组成情况进行了测试，包括系统的功能测试、性能测试、缺陷跟踪系统Bug管理等，重点对功能、性能进行了测试。
关键词：
档案管理系统；测试；缺陷
1测试计划
1.1概述
档案管理系统是国家机构、各企事业单位、集团行业等将各自当前生存和发展急需的各种资料和信息等知识及时整理归档，经过深度编研纳入本企业知识管理体系。
为企事业单位的档案现代化管理，提供完整的解决方案，档案管理系统既可以自成系统，为用户提供完整的档案管理和网络查询功能，也可以与本单位的OA办公自动化和DPM设计过程管理，或者与MIS信息管理系统相结合，形成更加完善的现代化信息管理网络。
档案信息化管理越来已走在时代的前列，这一趟列车不会停下来，只会载着更多有梦想的人超越梦想的极限。
在现今信息化高速发展的局面，确保档案信息化管理软件产品的质量安全也是一项得到重视的工作。
如何确保档案软件的质量安全是档案软件测试最主要的工作——包括测试前期的需求确定、测试计划的制定、测试用例的编写与利用测试工具，如QTP来执行系统的测试用例、LoadRunner测试系统的性能、并用专业的缺陷跟踪系统（Mantis）来记录发现的问题以便随后的改正，最后要进行测试结果的管理与反馈，编写测试报告。
因此，做好测试工作是确保档案软件的质量安全，这是一项重要的工作。
1）产品简介
PDE数字档案管理系统V7.2.9产品。
其主要测试内容包括系统管理、档案整理、档案保管、档案统计、档案利用。
系统管理是进行档案管理操作的基础设置如创建元数据、档案库模板、模板里的著录项、全文检索设置、添加档案库等操作，档案整理主要是对档案从收集、整理、鉴定、保管、检索、编研、利用与统计等一系列操作。
此档案管理系统能够很好的管理档案与利用档案，实现档案信息化过程。
2）范围
描述测试的各个阶段，例如：
单元测试、集成测试或系统测试，并说明本计划所针对的测试类型（如功能测试或性能测试）。
简要地列出测试对象中将接受测试或将不接受测试的那些特性和功能。
如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。
列出可能会影响测试设计、开发或实施的所有风险或意外事件。
列出可能会影响测试设计、开发或实施的所有约束。
3）限制条件
本测试计划受限于产品开发人员提交测试的内容和测试完成时间的事实。
根据产品开发完成状况以及修改状况，本测试计划会做出相应修改。
更好的完成系统的覆盖性测试。
1.2约定
1）测试目标
1.测试已完成的PDE数字档案管理系统V7.2.9产品是否达到需求设计的要求，包括：
各个模块的功能点是否实现、档案的业务流程是否正确实现。
2.测试计划中所有方法已执行并通过。
3.测试用例中所有用例已经执行过。
4.Bug数和缺陷率控制在可接收的范围之内。
5.使被测系统满足功能性、易用性、兼容性、可靠性、可测量性、可维护性等方面的需求。
2）接收标准
本节所述的接收标准是指可测试的标准，这个标准以测试组接收测试为限。
3）资源和工具
1.资源
（1）人员：
测试审核人，测试实施人员一名。
2.工具
测试中使用的Bug管理工具为经过改进的Bug管理工具、自动化功能测试工具QTP，性能测试工具JMeter、缺陷跟踪报告工具Mantis。
4）资源和工具
提交的测试按以下要求进行：
表1.1提交测试表
步骤
动作
负责人
相关文档或记录
要求
1
打包、编译
公司开发人员
无
确认可测试
2
审核并提交测试
公司开发人员
经审核的上一级测试报告
测试报告xx审核并签字
3
接收测试
测试人员
经xx审核并签字的上一级测试报告
4
开始测试
测试人员
Bug单、小结
测试小结个人编写个人的内容
5）进度表
进度表是用来描述测试系统的一个过程和测试所用的时间，有重点分级进行测试，方便规划如何去做好自己的毕业设计说明书。
表1.2进度表
测试阶段
完成所需时间
测试人员
阶段完成标志
制定测试需求
3天
涂云
测试需求报告
制定测试计划
3天
涂云
系统测试计划完成
设计测试用例
5天
涂云
系统测试用例完成
测试环境准备
1天
涂云
测试环境搭建完毕
功能测试
7天
涂云
1.执行测试集中的用例
2.编写功能测试报告
性能测试
7天
涂云
完成系统性能测试
跟踪缺陷
4天
涂云
1.缺陷分析报告
项目文档整理
2天
涂云
完成系统测试报告
1.3测试种类及测试标准
1.3.1测试种类
计划完成的类型测试：
功能测试、性能测试、界面测试
1.3.2测试方法及标准
1）功能测试
功能测试阶段在系统集成测试阶段之后进行，主要是验证产品是否正确实现了需求设计文档中的功能。
根据系统需求文档和设计文档对系统进行功能测试。
功能测试主要侧重系统功能的实现与档案业务是否与现实规范符合。
表1.3功能测试说明表
测试目标
系统提供的功能与需求或用户手册相符
完成标准
功能实现，并可以正确执行
所发现的缺陷尽量解决，留下的问题已经进行相应的处理或提供解决的办法
需考虑的特殊事项
注意开发组可能的功能变化和需求变更
注意其中一些重要的功能和实际效果相关，并不是简单的功能实现
注意值域测试时的提示信息
2）性能测试
性能评测是对功能操作过程中的响应时间、事务处理速率、系统在超出最大预期工作量要求、资源不足或资源争用等情况发生时，核实是否满足系统的性能要求。
在本系统测试中性能评测将结合测试工具重点进行。
表1.4性能测试说明表
测试目标
服务器端对界面操作请求的平均响应时间小于5秒
测试技术
借助性能测试工具辅助测试
通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的次数
脚本以单个用户、单个事务为基准，并在多台测试机上运行
完成目标
单个事务或单个用户：
在每个事务所预期或要求的时间范围内成功地完成测试脚本，没有发生任何故障
多个事务或多个用户：
在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。
需要考虑的特殊事项
复杂报表、查询功能，系统维护功能不在此要求范围内
性能测试应该在专用的测试机上或在专用的机时内执行，以便实现完全的控制和精确的评测。
测试中所用的数据库应该是实际大小或相同缩放比例的数据库。
1.4测试重点及顺序
1.4.1预测风险
本次测试过程中，可能出现的风险如下：
1） 非法数据输入
2）模块功能的实现情况
3）重大的需求变更
4） 用户文档不清晰
5）测试人员对软件的熟悉度
7） 并发用户数量太少
1.4.2功能测试重点
这里仅为功能测试重点的描述，具体测试方法以及内容请参见测试用例。
1） 全宗管理：
全宗的创建、删除、修改
2）模板管理：
模板的创建、删除、修改、添加模板著录项、查看模板信息
3） 组织机构管理：
组织机构的创建、删除、修改、添加机构用户
4） 用户管理：
用户的添加（用户信息的填写）、用户角色选择等功能测试
5）权限管理：
设置管理全宗的功能权限与数据权限
6）工作流管理：
常用步骤、工作流定义、工作流规则定义的添加删除，业务流程的正确
7）档案库操作：
档案库的创建、删除、修改（一文一件、传统案卷、工程一文一件、工程案卷）
8）全文检索：
目录检索、全文检索
9）档案统计：
档案库统计、档案库存量统计、档案利用情况统计、档案分类统计、电子借阅统计、实体借阅统计
10）报表编目：
档案的报表设计（案卷封面信息、脊背、全引目录等）
1.5测试提交物
本次测试完成后的提交物：
Ø测试计划
Ø测试用例
Ø功能和性能的测试分析报告
Ø测试Bug报告
Ø测试总结报告
2功能测试
2.1测试用例
功能测试的目的就是对产品的各模块的功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
本次测试主要是对档案管理系统的系统管理端的功能模块进行测试，如全宗管理、角色管理、用户管理、角色用户权限、档案库管理。
主要是根据档案业务有需求来测试其功能的正确性。
2.1.1全局系统管理
2.1.1.1全宗管理
如图2.2所示，是档案管理系统的全宗管理页面，图为添加一个全宗的过程，可设置全宗号、全宗名、上级全宗等，全宗是指国家机关、企事业单位、党政机关等在发展过程中可形成的一个整体。
以这个单位为一个全宗，便于收集企业内部的档案信息，也便于向上级移交本单位的档案信息。
图2.1全宗管理-添加页面
表2.1全宗管理测试用例表
项目名称
PDE数字档案管理系统
编号
TC_AMS_1
模块名称
系统管理-全局系统管理全宗管理
设计人员
涂云
编制时间
2012-03-14
功能特性
全宗的添加、修改和删除功能的实现
测试目的
验证全宗的添加、修改和删除等功能的实现
预置条件
登陆档案管理系统
当前用户具有系统管理-全宗管理的操作权限
编号
相关用例
步骤
用例说明
预期结果
实际结果
（通过/不通过）
备注
XTGL1
Step1
在全宗管理页面点击【添加全宗】按钮-添加全宗
打开添加全宗管理-全宗页面-成功添加公全宗信息
通过
分别执行step2中的输入值以测试系统输入控制
XTGL2
XTGL1
Step1
选择一个已经存在的全宗信息，点击【修改】
打开全宗管理-修改页面-成功修改全宗信息
通过
XTGL3
Step1
选择一个已经存在的全宗信息，点击【删除所选】
1当所选全宗是当前登陆全宗，不能勾选，并给出提示“用户当前登陆全宗，不能删除”；
2当所选全宗下存在子全宗，不能勾选，并给出提示“存在子全宗，不能删除”
通过
Step2
在提示信息中点击【取消】
放弃当前操作
通过
Step3
在提示信息中点击【确定】
成功删除所选信息
通过
2.1.1.2角色管理
图2.3是全宗内角色管理页面，添加一个角色过后，可设置用户所属角色，此角色具有怎样的权限。
通过角色的赋权，可以更好的做到系统的保密性，档案室的领导可赋于工作人员不同的角色权限，则工作人员就只有对档案管理系统指定的操作。
图2.2角色添加页面
表2.2角色管理测试用例表
项目名称
PDE数字档案管理系统
用例编号
TC_AMS_2
模块名称
系统管理-全局系统管理-角色管理
设计人员
涂云
编制时间
2012-03-14
功能特性
系统全局角色用户的设置以及对该角色进行增加用户、赋予权限操作
测试目的
验证系统对全局角色用户权限设置功能的实现
预置条件
登陆档案管理系统
当前用户具有对角色用户权限设置的操作权限
编号
相关用例
步骤
用例说明
预期结果
实际结果
（通过/不通过）
备注
XTGL4
XTGL1
Step1
在角色管理页面点击【添加】
弹出角色管理-添加页面-成功添加角色
通过
XTGL5
XTGL1
Step1
选择一个已经存在的角色，点击【修改】
弹出角色管理-修改页面
通过
XTGL6
Step1
选择一个或者多个已经存在的角色，点击【删除】
弹出提示“确定删除被选择的记录？
”
通过
Step2
在提示信息中点击【取消】
放弃当前操作
通过
Step3
在提示信息中点击【确定】
成功删除所选角色信息
通过
XTGL9
Step1
选择一个已经存在的角色，点击【管理全宗权限】，点击【添加作用全宗】，然后选择角色要作用的全宗，然后点击【保存】
对打钩的全宗选择后，全局角色会作用于该全宗
通过
Step1
选择全宗的【功能权限】
打开功能权限设置页面
通过
Step2
在打开的功能权限设置页面中相应状态的选项卡中勾选当前角色所具有的权限，点击【确定】
成功设定了该角色的功能权限
通过
Step3
在打开的功能权限设置页面上点【取消】
打开的功能权限设置页面被关闭，做的权限赋予操作不能被设定
通过
Step1
选择一个已经存在的角色，点击【管理全宗权限】，对已经选择好的全宗中点击选择【数据权限】
弹出数据权限设置页面
通过
XTGL11
Step1
选择一个已经存在的角色，点击角色后面的【设置角色用户】
进入角色用户页面，显示该角色所包含的所有用户
通过
Step2
点击【添加用户】按钮
进入选择全宗页面
通过
Step3
双击选择一个全宗，或者单击选择，点击【确定】
页面显示该全宗所有用户
通过
Step4
勾选要添加到该角色的用户，点击【确定】
则所选用户添加到该角色的用户
通过
2.1.1.3档案库条目添加
图2.4是在档案库里添加档案条目的页面，在添加条目之前，必须在档案管理系统端进行创建档案库，才可在档案业务端进行档案条目的添加。
图2.3档案条目添加页面
表2.3条目添加测试用例
项目名称
PDE数字档案管理系统
用例编号
TC_AMS_3
模块名称
文件管理---一文一件
设计人员
涂云
编制时间
2012-03-20Tuesday
功能特性
对一文一件条目的登记、原文的操作和条目的移交申请等操作
测试目的
验证一文一件条目的登记、原文的操作和条目的移交申请等操作功能的实现
预置条件
登陆档案管理系统
当前用户具有对文件管理和该文件库的操作权限
编号
相关用例
步骤
用例说明
预期结果
实际结果
（通过/不通过）
备注
WJGL1
Step1
在文件管理页面通过点击页面左侧一文一件库或通过右侧页面档案类别下点击一文一件库
进入到文件管理下一文一件页面
通过
WJGL2
XTGL1
Step1
点击【添加目录】
进入一文一件文件添加条目页面-成功添加档案条目
通过
以下的操作必须拥有相应的权限，没有权限的看不到相应的按钮
WJGL3
Step1
选择一条已经存在的条目，点击【修改目录】
进入修改条目页面-成功修改档案条目
通过
WJGL4
Step2
选择一条或者多条已经存在的条目，点击【删除目录】
弹出提示“确定删除所选记录？
”
通过
2.2用例的执行
QTP是一种基于GUI的功能自动化的测试工具，进入QTP主界面后，要先设置Windows应用程序的录制和运行界面中，分别创建Action，对于档案管理系统的录制，是事先把档案管理系统的页面打开，然后按Record进行录制脚本，Stop停止录制脚本，Run回放录制的脚本。
脚本的录制（回放）是根据所写的测试用例进行录制：
1）添加全宗脚本的录制
图2.4全宗管理-添加全宗脚本
2）添加角色脚本的录制
图2.5角色管理-添加脚本
3）添加目录脚本
图2.8一文一件档案库-条目的添加脚本
图2.9档案库-条目添加回放结果图
2.3功能测试分析
MercuryQuickTest是企业级自动化测试工具，目前已经被惠普公司收购，正式改名为HPQuickTestProfessionalsoftware，最新的版本为HPQuickTestProfessional11.0。
HPQuickTestProfessional提供符合所有主要应用软件环境的功能测试和回归测试的自动化，采用关键字驱动的理念以简化测试用例的创建和维护，它让用户可以直接录制屏幕上的操作流程，自动生成功能测试或者回归测试用例，专业的测试者也可以通过提供的内置脚本和测试环境来取得对测试和对象属性的完全控制。
QTP是一种基于GUI的功能自动化的测试工具，QTP是QuickTestProfessional的简称。
使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一个软件的新版本，因此在测试前要考虑好如何对应用程序进行测试，例如要测试哪些功能、操作步骤、输入数据和期望的输出数据等。
在QTP脚本录制和编写时确保每个功能可以单独的运行测试，所以我将每个功能作为一个Test，本次测试使用的是QTP11.0版本的。
由于使用的是公司的一套成熟的档案系统，特别在功能上，功能都符合需求文档中的要求。
所以，在作功能测试时并没有什么缺陷。
3性能测试
3.1测试工具
ApacheJMeter是100％的Java桌面应用程序。
用于对软件做压力测试，它最初被设计用于Web应用测试但后来扩展到其他测试领域。
它可以用于测试静态和动态资源例如静态文件、Java小服务程序、CGI脚本、Java对象、数据库，FTP服务器,等等。
JMeter可以用于对服务器、网络或对象模拟巨大的负载，来在不同压力类别下测试它们的强度和分析整体性能。
另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。
为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。
Apachejmeter可以用于对静态的和动态的资源（文件，Servlet，Perl脚本，java对象，数据库和查询，FTP服务器等等）的性能进行测试。
它可以用于对服务器，网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。
你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。
1）设置步骤:
1.右击“测试计划”选择“添加—线程组”线程数:
并发用户数
Ramp-UpPeriod（inseconds）:
在所设定的时间短内所有的用户创建成功。
2.线程组——添加配置文件——HTTPCookie管理器
3.线程组——添加配置文件——HTTP请求默认值（端口号：
8085IP:
localhost）
4.线程组——添加Sampler——HTTP请求（路径：
AMS/login.jsp
方法：
POST添加名称：
useNamepde添加名称：
passWord888）
所设置的如下图所示:
图3.1设置路径界面图
3.2测试用例
下面是系统性能测试的具体用例，用例对系统业务端C/S部分进行数据测试.
用例名称：
系统C/S测试用例
用例编号：
PDE_AMS_PERFORMANCE_001
用例设计人：
涂云
测试人员：
涂云
测试时间：
2012-6-4
测试模块：
系统登陆
测试目的：
本次测试通过正常用户数登录系统并且执行数据操作来验证系统各方面的基准性能指标。
测试流程：
用户登录系统CS端，打开档案库，进行数据操作
具体用例：
◆模拟20用户进行并发操作，测试内容包括：
系统登录、目录检索、全文检索。
◆模拟50用户进行并发操作，测试内容包括：
系统登录、目录检索、全文检索。
◆模拟100用户进行并发操作，测试内容包括：
系统登录、目录检索、全文检索。
测试项目
测试结果
测试点
数据量
响应时间
服务器吞吐量
资源占用率
多用户并发登录
20用户
209S
200M
7.7%
50用户
161S
200M
11%
100用户
270S
200M
14.7%
50个并发用户数的执行场景，右击“测试计划”选择“添加—线程组”，在并发用户数填：
50，在Ramp-UpPeriod（inseconds）：
10
图3.250个并发用户数的运行界面
3.3性能测试分析
1）名词定义
a.吞吐量是服务器每分钟处理的请求数。
b.样本数目是总共发送到服务器的请求数。
c.最新样本是代表时间的数字,是服务器响应最后一个请求的时间。
d.平均值是总运行时间除以发送到服务器的请求数。
e.中间值是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。
2）图表说明
表2.2参数表
Label
#Samples
Average
Median
90%Line
KB/Sec
HTTP请求
75
11
5
9
22.362分钟
总体
75
11
5
9
22.362分钟
图表含义说明如下：
Label：
说明是请求类型，如Http，FTP等请求。
#Samples：
也就是图形报表中的样本数目，总共发送到服务器的样本数目。
Average：
也就是图形报表中的平均值，是总运行时间除以发送到服务器的请求数。
Median：
也就是图形报表中的中间值，是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。
90%line：
是指90%请求的响应时间比所得数值还要小。
Throughput:
也就是图形报表中的吞吐量，这里是服务器每单位时间处理的请求数，注意查看是秒或是分钟。
3）性能测试分析
平均响应时间是我们性能测试的一个重要衡量指标，但是在测试中，特别是在聚合报告中，得出的90%Line,，我认为90%Line等同于的90%响应时间,这个数值对我们性能测试分析也很有参考价值。
90%响应时间是说在发送的请求中，90%的用户响应时间都比得到的数值上要短，同时说明，一个系统在应用时，90%的用户响应时间都能达到这个数值，那么就为系统性能分析提供了很好的参考价值。
4缺陷跟踪管理
在使用Mantis之前，一定要配置安装EasyPHP、Mantis、Mysql。
这三个要进行配置，配置正确了，才可以正常使用。
配置成功后，即可登陆Mantis
图4.1Mantis的登陆界面
1）管理全局配置
全局配置是用来配置运行的平台的，把自己电脑的配置设置在下面的图中，如图3.2.
图4.2全局配置
2）项目管理
项目管理是先设置项目酒店管理系统，然后分别设置子项目：
房间状况管理、添加房间信息。
然后对于所添加的项目进行说明如下图3.3.
图4.3项目管理
3）报告问题
因为，所用的测试系统是公司已完整开发的一套系统程序，所以，在我测试时，系统的功能、性能已基本稳定。
报告的问题是根据我所写的测试用例进行的功能测试所发现的缺陷，而在测试用例当中根据测试所发现的缺陷，只是一些细节的问题，不足以定为缺陷，发现的细节问题用mantis缺陷管理工具记录的，图3.4只是举例，如发现缺陷就可在Mantis中的此页面上进行报告问题。
如下图4.3所示：
图4.3报告问题
4）查询问题
方便查询就如图4.4的查
升级会员 