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