学生作品DE档案管理系统测试项目报告.docx
《学生作品DE档案管理系统测试项目报告.docx》由会员分享，可在线阅读，更多相关《学生作品DE档案管理系统测试项目报告.docx（23页珍藏版）》请在冰豆网上搜索。
学生作品DE档案管理系统测试项目报告
TPMKstandardizationoffice【TPMK5AB-TPMK08-TPMK2C-TPMK18】
学生作品DE档案管理系统测试项目报告
《软件测试》课程项目库学生作品
项目名称
PDE档案管理系统测试
院系
计算机与软件学院
专业
软件技术（测试）
班级
软件0931
学号
0902343320
学生姓名
季晓琴
1摘要
随着社会的的不断进步，档案信息化的竞争也愈来愈激烈，要想在竞争中取得优势，必须在经营管理、产品服务等方面提高管理意识。
本设计就是以一个提供档案的管理系统作为解决方案的背景，本文主要是对电子档案管理系统的一些基本功能和组成情况进行了测试，包括系统的功能测试和性能测试，并对功能测试和性能测试进行了分析与总结。
构成了对一个完整的电子档案管理系统的测试。
将使用QTP11功能测试、Jmeter性能测试工具、mantis缺陷跟踪管理工具辅助测试，尽可能的发现该系统中存在的功能上的缺陷，和分析该系统的性能指标。
关键词：
电子档案管理；功能测试；性能测试；缺陷报告
1测试计划
1.1概述
电子档案管理业是一个前景广阔而又竞争激烈的行业。
由于我国的电子档案管理业迅速发展。
由于社会的不断发展，人们对档案管理系统的需求也越来越多，为了提高各单位的档案管理工作效率、提高档案查找的准确率、加快检索速度，促进档案管理的规范化和正规化，档案管理系统的发展成为了必要。
档案管理系统是一套功能强大、操作简便、使用的自动化管理软件，包括用户管理、系统参数设置、档案数据录入（分为文件录入和案卷录入两部分）、案卷数据查询（分为文件查询和案卷查询两部分）、借阅管理、数据维护（分为数据备份和数据操作）、操作日志查看、报表打印等。
可以用于一般的档案室，也可以应用于网络中的办公系统、进行联网操作。
信息系统的流行也避免不了有时会出现系统功能和性能上的缺陷，而如何去测试好这个系统也成为了关键。
一般都要事先写好测试计划和测试设计阶段主要进行的文档审查和测试需求分析、设计测试用例和运用测试工具去测试系统，缺陷报告等；在测试执行活动阶段主要进行测试范围控制、配置管理等。
针对一个电子档案管理系统，组织和管理该系统测试流程的所有阶段是很重要的,所以运用自动化测试工具去测试这个系统，也避免复杂的人工测试减少了时间，并提高了效率。
找到了缺陷也防止了系统投入了市场，出现问题了再改，这样就会损失很大，所以测试也是一件很重要的事情。
1）产品简介
本次开发是基于WEB网上的电子档案管理系统，本系统的功能包括档档案的收集、整理、归档、保管、统计、借鉴、利用而设计的一个管理系统。
2）范围
描述测试的各个阶段，例如：
单元测试、集成测试或系统测试，并说明本计划所针对的测试类型（如功能测试或性能测试）。
简要地列出测试对象中将接受测试或将不接受测试的那些特性和功能。
如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。
列出可能会影响测试设计、开发或实施的所有风险或意外事件。
列出可能会影响测试设计、开发或实施的所有约束。
3）限制条件
本测试计划受限于产品开发人员提交测试的内容和时间的事实。
根据开发人员提交模块的实际情况，本计划会做出相应修改。
1.2约定
1）测试目标
电子档案管理系统的目的是：
1.测试已实现的产品是否达到设计的要求，包括：
各个功能点是否以实现，业务流程是否正确。
2.产品规定的操作和运行稳定。
3.Bug数和缺陷率控制在可接收的范围之内。
2）接收标准
本节所述的接收标准是指可测试的标准，这个标准以测试组接收测试为限。
3）资源和工具
1.资源
（1）测试服务器：
稳定的测试服务器，IP地址为:
192.168.115.1。
（2）人员：
测试人员一名
2.工具
测试中使用的Bug管理工具为经过改进的Bug管理工具、自动化功能测试工具QTP，性能测试工具JMeter、缺陷报告工具mantis。
4）资源和工具
开发人员提交的测试按以下要求进行：
表1.1提交测试表
步骤
动作
负责人
相关文档或记录
要求
1
打包、编译
开发人员
无
确认可测试
2
审核并提交测试
开发组长
经审核的上一级测试报告
测试报告审核并签字
3
接收测试
测试人员
经xx审核并签字的上一级测试报告
4
开始测试
测试人员
Bug单、小结
测试小结个人编写个人的内容
5）进度表
进度表是用来描述我测试系统的一个过程和一般所用的时间，这样也更好的让我明白某个模块所要用的时间，方便规划如何去做好自己的毕业设计说明书。
表1.2进度表
项目名称
完成需要时间
项目验收和作业文件
备注
一、指定测试需求
1.定义测试范围
2.创建需求
3.编写详细信息需求
4.分析需求指定
3天
1.测试需求报告
二、计划测试
1.定义测试策略
2.定义测试主题
3.定义测试
4.创建需求范围
5.设计测试步骤
6.自动化测试
7．分析测试计划
7天
1.建立测试脚本
2.测试计划报告
三、运行测试
1.创建测试集
2.计划运行
3.运行测试
4.分析测试结果
7天
1.执行测试集中的测试
2.运行测试报告
四、跟踪缺陷
1.添加缺陷
2.查看新缺陷
3.测试新的内部版本
4.分析缺陷数据
2天
1.缺陷分析报告
五、项目文档整理
1天
整理资料
1．3测试种类及测试标准
测试种类
计划完成的类型测试：
功能测试、性能测试、界面测试
测试方法及标准
1）功能测试
功能测试是用来测试系统的功能否实现。
这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。
这种类型的测试基于黑盒方法，即通过图形用户界面（GUI）与应用程序交互并分析输出结果来验证应用
程序及其内部进程。
以下列出的是每个应用程序推荐的测试方法概要：
表1.3功能测试说明
测试目标：
确保测试对象的功能正常，其中包括注册、数据输入、处理和检索等。
方法：
利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：
在使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警告消息。
各业务规则都得到了正确的应用。
完成标准：
所计划的测试已全部执行。
所发现的缺陷已全部解决。
需考虑的特殊事项：
确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）
2）性能测试
本次性能测试，重点模拟客户进行多用户测试。
压力测试有一条8：
2原则。
及百分之八十的业务量在百分之二十的时间内输入。
例如:
正常访问同一个页面，根据并发用户数的不同，来分析页面登录的情况，是不是访问的时间很长，或者超过一般等待的时间。
表1.4性能测试说明
测试目标：
确保测试系统的性能指标。
方法：
利用设置的数据对于自动化性能工具进行测试。
完成标准：
所计划的测试已全部执行。
所发现的缺陷已全部解决。
需考虑的特殊事项：
确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）。
1.4测试重点及顺序
预测风险
本次测试过程中，可能出现的风险如下：
1）bug的修复情况
2）模块功能的实现情况
3）系统整体功能的实现情况
4）代码的编写质量
5）人员经验以及对软件的熟悉度
6）开发人员、测试人员关于项目约定的执行情况
7）人员调整导致研发周期延迟
8）开发时间的缩短导致某些测试计划无法执行
测试重点
这里仅为功能测试重点的描述，具体测试方法以及内容请参见测试用例。
1）管理员登录：
跳转页面并登录成功
2）档案管理：
跳转页面中点击添加，删除，修改，明细等按钮，页面成功保存添加的条目
3）档案移交：
选中多条条目进行档案移交，移交成功，被移交的档案条目全部转移到接收档案的档案库中
4）电子借阅：
普通用户在档案网站申请电子借阅，通过审批，申请人能查看原文了
1.5暂停标准和再启动要求
1）软件系统在进行单元、集成、确认、系统、安装、验收测试时，发现一级错误（大于等于1）、二级错误（大于等于2）暂停测试返回开发。
2）软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。
3）软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据。
4）如有新的项目需求，则在原测试计划下做相应的调整。
5）若开发暂停，则相应测试也暂停，并备份暂停点数据。
6）若项目中止，则对已完成的测试工作做测试活动总结。
7）项目再启动时，测试进度重新安排或顺延。
1.6测试提交物
本次测试完成后的提交物：
测试计划
测试用例
功能和性能的测试分析
测试总结报告
2
功能测试
2.1测试用例
功能测试的目的:
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
拿电子档案管理系统来说能是测试添加信息、检索信息和页面的跳转能否成功等功能。
收集档案主要是指档案员或兼职档案员对档案的收集即添加，或者导入档案。
下面是档案管理系统的测试用例。
表2.1档案管理测试用例
项目名称
PDE档案管理系统测试
程序版本
P7.2.9
模块名称
档案管理模块
功能特性
档案管理系统实现档案的收集，整理，移交，统计，保管以及利用功能
测试目的
使系统更加完美
用例编号
相关用例
用例说明
预期结果
实际结果
（通过/不通过）
备注
1
条目添加
点击添加按钮
页面弹出添加条目的界面
通过
简单的功能测试
2
条目删除
选中条目，点击删除
页面少一条我们选中的条目
通过
简单的功能测试
3
条目修改
弹出所选条目的信息的界面，修改后，能显示修改之后的信息
页面条目减少一条
通过
简单的功能测试
4
条目明细
页面弹出所选条目的信息的界面
页面显示信息正确
通过
简单的功能测试
2.2测试执行
2.2.1系统登录界面的测试
下图是PDE档案管理系统的登录界面，用户名是pde，密码是888。
图2.2.1用户登录界面
用户登录运行的代码：
2.2.2条目添加的测试
下图是档案条目添加的界面，主要给档案员和兼职档案员录入条目，收集档案用的。
图2.2.2条目添加的界面
2.2.3条目添加的执行代码
下面的这段代码是进行档案添加录制时的代码：
图2.2.2条目添加运行结果
2.2.4档案移交的测试
下图是档案移交的界面图，就是档案从文件整理状态移交到整理编目状态，或是从整理编目状态移交到档案管理状态
图2.2.3整理编目状态下的条目
图2.2.3档案移交时的录制代码
图2.2.4档案移交录制结果
2.3测试总结与分析
本系统进行测试过程中所发现问题总数为：
0
合格率=测试通过案例数/使用测试案例总数×100％=100%
测试完成率=使用案例数/设计案例总数×100％=100%
覆盖分析主要是针对系统需求说明书中所有需求/功能的测试状况进行统计和分析。
需求覆盖率=需求用例总数/需求规格说明书中的需求数×100％=100%
测试覆盖率是指所有需求/功能用例个数的执行总数与测试用例中设计的需求/功能的用例总数之百分比，并指出未执行的用例总数并列出未执行的原因。
测试覆盖率=需求用例总数/执行用例总数×100％=100%
本次测试整体测试结果如下：
本次测试目标基本完成，测试用例执行率为100%；测试需求覆盖率为100%；
3
性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
下面的测试是模拟单个用户进行操作，所有档案条目均在当前页显示。
数据操作测试包括：
数据导入、数据导出、数据状态调整（归入整编、归档、取消归档）、数据整理（生成/清除档号）、批量替换/修改、批量原文挂接、批量删除、批量装盒、批量自动组卷、批量自动关联、批量数据鉴定/取消鉴定、并发进入大数据量档案库、刷新流水号/生成序号、批量保存数据到其他档案库、多用户并发登录、多用户并发进行全文检索、多用户并发进行条目检索、多组织机构下用户检索、大数据量跨全宗移交、批量数据打包、跨库检索、全宗数量、用户数量、数据字典。
数据操作测试初始数据量为3000条/库；步进为3000条/库；满载数据量为9000条/库，条目加挂原文。
3.1测试用例
用例名称：
系统C/S测试用例
用例编号：
PDE_AMS_PERFORMANCE_001
测试时间：
2012-05-20
测试模块：
打开档案库，数据操作
测试目的：
本次测试通过正常用户数登录系统并且执行数据操作来验证系统各方面的基准性能指标。
测试流程：
用户登录系统CS端，打开档案库，进行数据操作
测试点
数据量
响应时间
服务器吞吐量
资源占用率
数据导入
3000条
115S
200M
8%
6000条
283S
200M
11%
9000条
402S
200M
31%
数据导出
3000条
13S
200M
1%
6000条
28S
200M
2%
9000条
44S
200M
4%
数据状态调整（归入整编、归档、取消归档）
3000条
314S
200M
4%
6000条
855S
200M
5%
9000条
1184S
200M
10%
3.2测试执行
3.2.1登录
场景设置：
组名
脚本
虚拟用户数
运行时设置
Group1
网站登陆
50,80
每隔10秒运行5个用户；
无思考时间；
50或80用户峰值运行一分钟；
50个用户并发
具体数据：
以下数据均过滤掉了thinktime。
图3.2.1（a）50用户事务响应时间
图3.2.1（b）50用户事务数据吞吐量
图3.2.1（c）50用户应用服务器CPU占用率
80个用户并发
图3.2.1（d）80用户事务响应时间
图3.2.1（e）80用户事务数据吞吐量
图3.2.1（f）80用户应用服务器CPU占用率
3.2.2目录检索
场景设置：
组名
脚本
虚拟用户数
运行时设置
Group2
目录检索
50,80
每隔10秒运行5个用户；
无思考时间；
50或80用户峰值运行一分钟；
50个用户并发
具体数据：
以下数据均过滤掉了thinktime。
图3.2.2（a）50用户事务响应时间
图3.2.2（b）50用户事务数据吞吐量
图3.2.2（c）50用户应用服务器CPU占用率
80个用户并发
图3.2.2（d）80用户事务响应时间
图3.2.2（e）80用户事务数据吞吐量
图3.2.2（f）80用户事务数据吞吐量
3.2.3全文检索
场景设置：
组名
脚本
虚拟用户数
运行时设置
Group3
目录检索
50,80
每隔10秒运行5个用户；
无思考时间；
50或80用户峰值运行一分钟；
50个用户并发
具体数据：
以下数据均过滤掉了thinktime。
图3.2.3（a）50用户事务响应时间
图3.2.3（b）50用户事务数据吞吐量
图3.2.3（c）50用户应用服务器CPU占用率
80个用户并发
图3.2.3（d）80用户事务数据响应时间
图3.2.3（e）80用户事务数据吞吐量
图3.2.3（f）80用户应用服务器CPU占用率
3.3测试结果及分析
网站部分对于登录、目录检索、全文检索三个功能点的要求，分别进行了用户的并发操作，其中由于网络连接与网段影响等因素，可能对测试结果带来偏差。
测试过程中，系统大约可支持40个用户数的并发，且不存在报错，并以此可估算出可支持的最大在线用户数，具体并发量估算过程如下：
常用的确定并发用户数的公式是：
C=nL/T=活动用户数×操作时间/系统运行时间，按照这个公式反推过来，活动用户数=系统运行时间×并发用户数/操作时间，各个功能点若当前最大并发用户数为40，完成一次操作的平均时间为10s，场景运行时间为1分钟，那么系统活动用户数可估算为：
1×60×40/10=240，即目前系统理论可支持大约240个活动用户。
进入大数据量档案库（3000条目）时，进行数据编辑（添加、修改、删除）系统反映非常慢，批量修改时任务处理时间超过10分钟，批量删除时任务处理时间超过15分钟，超过用户可接受范围，需要进行分页显示及功能优化。
进行大数据量（3000条目）批量关联或批量组卷，任务处理时间均超过1分钟，数据整理以及大数据量下（3000条目）原文挂接时，任务处理时间超过10分钟，系统响应时间过慢，无法接受。
进行大数据量（3000条目）数据导入或者批量数据删除时，系统响应时间很长，数据导入超过2分钟，数据删除超过15分钟，无法接受，同时在上述操作运行过程中，系统容易出现假死现象，等待上述操作结束后，即可正常使用系统，同时，若在假死状态对系统进行操作，会导致系统崩溃。
在大数据量下进行操作时，若系统崩溃则可能导致：
档案库中已存在的数据丢失，档案库无法打开等其他未知错误。
网站登录：
50个并发用户进行登录测试时，系统在测试初期响应速度过慢，导致初始用户报错，在运行一段时间后，系统将可以正常运行，网站端可以正常进行访问，通过多次测试发现，网站利用端在进行压力测试时最多可支持40用户进行操作，当使用80个并发用户进行登录测试时，系统在正常运行用户数超过40时则会出现报错。
目录检索：
50用户进行并发目录检索时，web服务器监视资源值波动过大，存在相应稳定隐患，同时通过50用户目录检索以及80用户目录检索数据吞吐量测试截图进行比较，可以发现系统在与web服务器进行交互时需要较高的网络环境进行支持，否则就会出现数据吞吐量在一定时间内波动超过可接受范围的值的现象出现。
全文检索：
全文检索部分50用户进行并发性能测试时失败用户数较多，同时通过服务器数据监控图可以看出在多用户并发进行全文检索时需要占用大量服务器资源，服务器在大压力下对于全文检索响应过慢，有可能导致在一定时间内数据量的暴增，从而使服务器无法处理，导致web服务器瘫痪。
综上所述，以上小结及此次压力测试结果仅作为客观依据，可根据档案生产系统今后实际使用情况进行参考。
4
测试总结
4.1测试目的
测试的目的是发现现有系统还存在的问题，因此测试人员，通过卫生高级专业技术资格网上申报系统的熟练操作了解该系统的基本功能和操作流程，通过对该系统的界面、功能、性能的测试，发现该系统还存在的一些缺陷。
4.2测试概述
1）系统概述
本次测试的是基于档案管理系统的功能和性能的测试，这个系统功能包括条目的管理、条目修改，条目删除，条目移交，条目借阅等功能，是适用于一些档案馆的管理，这样就不用人工繁琐的去登记。
2）文档概述
本文档用于对档案管理系统的软件的测试工作阶段成果的描述。
包括对软件测试的整体描述，软件测试的分类和级别，软件测试的过程描述，软件测试的结果等内容。
运用了自动化测试工具，功能测试QTP,性能测试Jmeter,而功能测试就是测试这些功能有没有缺陷，性能测试测试用户数同时请求下响应时间。
4.3测试总结和建议
1）测试总结
本次测试对档案管理系统软件进行了功能和性能的测试。
在测试过程中针对发现的软件缺陷进行了初步分析，并提交程序设计人员对原软件中可能存在的问题进行考查。
在软件测试中首先根据软件测试的规范进行考核，将书写规范，注释等基础问题首先解决，其次考核软件测试中的问题是否存在设计上的逻辑缺陷，如果存在设计缺陷则应分析该缺陷的严重程度以及可能引发的故障。
软件开发人员在以上基础上对软件的不足做出相应的修改，同时通过软件回归测试验证软件修改后能够得到的改善结果。
2）测试结果
在两个阶段测试过程中共发现软件缺陷0个。
因测试条件所限，未能进行软件的确认测试和系统测试。
3）评估和建议
a软件编码规范化评估
经过回归测试，未残留的软件编码规范性缺陷。
软件代码文本注释率约为42%，代码注释充分，有利与代码的理解和维护。
b改进建议
（1）建议在软件开发项目中全面实施软件工程化，加强软件开发的管理工作。
（2）建议进一步加强软件需求规格说明、软件设计文档编制以及编写代码的规范化。
特别是应该将系统中的硬件研制和软件研制分别管理，软件文档编制的种类和规格按照相关标准执行。
（3）尽早开展软件测试工作。
在软件研制计划安排上给软件测试留有必要的时间，在资源配置上给软件测试必要的支撑。
（4）建议结合系统联试，开展软件的确认和系统测试。
4.4测试记录
1）测试时间：
2012年5月15日至2012年5月20日。
2）地点：
（略）。
3）硬件配置：
P4CPU/2.0G，内存256M，硬盘1G
4）软件配置：
Wondowsxp，
5）所有测试相关活动的日期和时间、测试操作人员等记录见软件测试记录文档。
谢辞
本项目设计在指导老师的悉心指导和严格要求下已完成，从课题选择到具体的写作过程，项目报告初稿与定稿无不凝聚着老师的心血和汗水，在项目测试期间，老师为我提供了种种专业知识上的指导和一些富于创造性的建议。
在此向老师表示深深的感谢和崇高的敬意！
参考文献
[1]武剑洁，陈传波.《软件测试技术基础》.武汉：
华中科技大学出版社，2008.10
[2]陈能技.《QTP自动化测试实践》.北京：
电子工业出版社，2008.6
[3]刘冰，瞿中.《软件工程实践教程》.北京：
机械工业出版社，2009.1
[4]陈绍英.《LoadRunner性能测试实战》.北京：
电子工业出版社，2007.9
[5]高楼.《软件测试项目实战》.北京：
电子工业出版社，2010.4
[6]黄晓磊.《软件测试原理、技术及工具》.北京：
清华大学出版社，2011.3
[7]王峰.《计算机软件测试》.北京：
机械工业出版社，2008.5
[8]张克东.《软件工程与软件测试自动化教程》.北京：
电子工业出版社，2009.5
[9]许育诚.《软件测试与质量管理》.北京：
电子工业出版社，2010.7
附录
用户登录的测试用例：
用户编号
操作
预期结果
实际结果
缺陷原因
1
输入正确的用户名，错误的密码
不能登录
不能登录
成功无缺陷
2
输入错误的用户名，错误的密码
不能登录
不能登录
成功无缺陷
3
输入错误的用户名，正确的密码
不能登录
不能登录
成功无缺陷
4
输入正确的用户名，正确的密码
正常登录
进入系统
成功无缺陷
用户登录的界面：
用户登录的执行代码：
Window（"北京量子伟业时代信息技术有限公司"）.WinObject（"pde"）.Click114,9
Window（"北京量子伟业时代信息技术有限公司"）.WinObject（"pde"）.Type"pde"
Window（"北京量子伟业时代信息技术有限公司"）.WinObject（"pde"）.TypemicTab
Window（"北京量子伟业时代信息技术有限公司"）.W
升级会员 