1、1 概述 11.1 文档目的 11.2 读者对象 12 测试目标及背景 12.1 项目简介 12.2 测试对象 12.3 测试目的 12.4 测试内容 13 测试环境 23.1 国家级应用及数据库 23.2 省级应用及数据库 23.3 省级应用及数据库 23.4 应用及数据库 23.5 应用及数据库 33.6 应用及数据库 33.7 应用及数据库 33.8 测试环境偏差 34 测试工作安排 34.1 测试成员及职责 34.2 人员工作安排概况 45 测试过程分解 46 测试结果及分析 46.1 测试结果 46.2 结果分析 81、 制度管理： 82、 调查对象管理：3、 数据录入修改：4、 审
2、核关系：5、 数据汇总：6、 数据查询：7、 数据管理 2个问题 88、 系统管理：9、 性能问题是个最大的问题，也是以后我们以后测试的重点。 910、 上报数据按条件导出上报，测试不充分。. 911、 元数据库2个问题：7 测试结论 91 概述1.1 文档目的第二次全国经济普查数据处理系统的原型测试工作，对第二次全国经济普查数据处理系统软件测试过程中各项数据进行统计分析，使第二次全国经济普查数据处理能够顺利进行,保证数据的准确性,也为了保证测试工作的针对性,正确性, 从而找出软件过程的不足和缺陷，进行持续的改进,特编写此文档。1.2 读者对象项目管理人员、开发人员、测试人员、文档管理人员2
3、测试目标及背景2.1 项目简介第二次全国经济普查数据处理系统是基于元数据再设计、制度管理、调查对象管理、数据录入修改、数据审核、数据汇总、数据查询、数据管理、系统管理于一体的数据处理系统。2.2 测试对象第二次全国经济普查数据处理系统：制度管理、调查对象管理、数据录入修改、数据审核、数据汇总、数据查询、数据管理、系统管理等模块的测试。2.3 测试目的保证第二次全国经济普查数据处理系统能按时按量提交给客户使用。2.4 测试内容应用程序部署是否正常数据库部署是否正常服务能否正常应用单机版的安装包能否正常安装软件是否可以正常卸载或更新制度导入制度导出制度再设计制度发布报表发布数据录入数据保存数据修改
4、数据查询数据审核审核错误列表查看数据汇总本级数据导出上报数据导出数据清空本级数据导入上报数据接收再设计流程非再设流程元数据库系统测试3 测试环境3.1 国家级应用及数据库服务器 IP地址说明备注应用服务器10.6.99.121WebLogic端口号7008数据库服务器10.6.99.118Oracle 10g用户名 jp2dataqa4 jp2metaqa43.2 省级应用及数据库端口号7002用户名 jp2dataqa2 jp2metaqa23.3 省级应用及数据库端口号7005用户名 jp2dataqa3 jp2metaqa33.4 应用及数据库 10.6.99.250（51）Tomcat
5、端口号 9080用户名 jp2data jp2meta 3.5 应用及数据库 10.4.17.7端口号9080Oracle10g XE jp2meta3.6 应用及数据库10.4.17.33.7 应用及数据库人员单机张立娟、李志宏、詹改霞3.8 测试环境偏差 没有乡镇级版本（Sqlserver）4 测试工作安排4.1 测试成员及职责职位名称人员组成职责测试负责人组织协调测试小组具体工作。测试人员郭玉鹏负责具体测试工作，包括测试用例编写，执行测试，提交测试记录唐焕维贾文庆郝永丽刘亮李端董贵平李志宏桂琼宇张航舰詹改霞张丽娟4.2 人员工作安排概况具体测试计划见VSS编号任务内容时间人员安排1普查软
6、件测试2008-11-06 -2008-12-16李超、贾文庆、郭玉鹏、唐焕维、郝永丽、刘亮、李端、张航舰、董贵平、桂琼宇、詹改霞、张丽娟、李志宏5 测试过程分解目前主要是按模块进行分解：制度管理、调查对象管理、数据录入修改，数据审核，数据汇总，数据查询，数据管理，系统管理6 测试结果及分析6.1 测试结果 性能测试结果： 测试环境一：应用服务：10.6.99.121 WebLogic 数据库 ：10.6.99.118 Oracle1、 批量审核性能问题。2、 批量汇总性能问题。3、 制度覆盖导入的性能问题。4、 展开数据处理地很慢。5、 本级数据导入200万数据，6个小时还没有结束。 测试环
7、境二：数据审核测试结果：表名数据量审核关系条数总体时间平均值1602（b1）103177423690.003102990.229621601（b1）4873829330.000813230.0601789602（b2）15590835140.000304580.0225389601（b2）22048738010.0002329610.0172391602（c1）1008623490.0031472580.2328971601（c1）6144619790.0004352320.0322071602（c2）1012129820.5445580720.2946349601（c2）6147823420
8、.0005147960.0380949602（e1）1030623500.0030813850.2280225601（e1）6185429790.0006508350.0481618601（e2）6261329800.0006431610.047594602（e2）1019821250.0028158670.2083742601（e3）6161929400.0006447640.0477126602（e3）1013623340.0031117340.2302684601（e4）6164410530.0002308370.017082602（e4）1027123400.0030787290.22
9、78259测试环境三： 数据库和应用服务器 oracle 10g 和 Tomcat 10.6.99.1201、 200万数据重名重码审核用了10分钟最后客户端IE出现内存错误。2、 重名重码审核出的结果11960，导出用了7分钟。3、 本级数据导出200万数据，目前速度是1小时20分钟。4、 导出本级数据每秒500条。测试数据200万 用1小时10分钟。5、 Csv 文件200万本级导出数据下载下来解压失败。海南培训测试环境： 数据库和应用服务器 Oracle 10g 和 Tomcat1、80用户在线，其中70用户在线录数（乡镇级别用户），6个用户做批量汇总（省级用户），4个用户浏览（国家级用
10、户）。脚本跑半个小时左右 tomcat抛 outofmemory错，系统崩溃。2、30乡镇级别用户在线录数，4国家级别在线浏览，2国家级用户手工点击批量审核，2国家级用户手工点击批量汇总，系统运行1小时左右宕机，outofmemory。 3、录数审核汇总混合操作3.1、用户在线（1）30用户在线录数（乡镇级）。（2）4用户在线浏览，点击b1和b2专业展开操作（国家级）。（3）6用户批量汇总（省级）。（4）2国家级用户手工点击批量审核，2国家级用手工点击批量汇总。3.2、现象（1）脚本运行时系统响应较慢，批量汇总全选，批量审核全选，数据导出的全选，专业下有大数据的展开（40万），查看单位名录管理
11、中具体表的数据，大概需要150s左右。（2）表中有大数据（100万）查询时500s左右。（3）脚本运行半小时左右宕机，tomcat日志显示outofmemory。4、 系统宕机（tomcat日志有outofmemory）（1） 初步定位系统宕机的原因为：国家级别用户在大数量（220万）下批量审核和批量汇总会引起系统死机。 5、场景四：（脚本运行十小时系统没宕机）5.1、80用户在线（1）70用户在线录数（乡镇级）（2）4用户在线浏览，点击b1和b2专业展开操作（国家级）（3）6用户批量汇总（省级）5.2、现象：（1）脚本运行时系统响应较慢，批量汇总全选，批量审核全选需500s（2）数据导出全选
12、，专业全选需500s左右（3）有大数据专业的展开（40万），500s左右（4）查看单位名录管理中具体表的数据240s左右（5）601表保存120s左右（6）空专业展开需45s左右（7）基层数据查询需450s左右5.3、结果：（1） 系统没有宕机（2） 表的submit事务失败比较多（工具设置发送请求超过120s服务器不响应就为超时失败）（3） 服务器处理事务能力低下，tps为0.1或者为0（tps为每秒事务处理数），服务器硬件资源没有长时间饱和。（4） 根据场景一三和场景二四，国家级别用户做批量审核和汇总（库中共220万数据），系统会宕机（outofmemory）（5） 根据场景四可以看出多用
13、户（80用户）在线操作时，系统响应能力低下（查询，列表的展开，专业的全选等操作，具体时间请看每个场景中时间统计），系统响应时间超出了正常能接受的范围，服务器cpu资源未长时间饱和，memory使用过高。（6） 多用户在线操作时，601表保存操作耗时过长需要优化（80用户时120s）（7） B1专业602-1发生过丢数现象（整条记录丢失），脚本运行时发现此表保存数比较其他表少。脚本中设置每运行一次脚本每个表中录入数一样多 6、 单机版：Tomcat 和Oracle XE1、 Oracle XE 下的汇总问题。 第二次经济普查软件到2008-12-16日之前还存在78 BUG，其严重级别不同。 B
14、locker 19个、Critical 28个、Major 21个、Minor 和Trivial 13个6.2 结果分析存在有一个后台错误。覆盖导入制度40分钟。存在3个问题。存在15个问题。存在10个问题，问题都很明显必需修。综合表表间审核关系还没有测试，因为目前系统还没有作。审核性能存在性能问题，并且这方面的测试还需要加强。在4个问题。一个是性能问题，汇总部分的循环表打开很慢，存在10钟的情况。希望尽快提高性能。汇总按条件汇总测试现在并不充分，因为正常的2008-12-15号还在调试E679汇总中。这部分还需要详细测试。存在4个问题7、 数据管理 2个问题 存在2个问题。.7 测试结论 软件现有和潜在问题很多，站在测试的角度测试不通过。主要是因为：再设计测试并不充分，还有元数据管理这个分支的代码被微软的成员提交过代码，现在测试很仓促。频繁发包对于测试进程受到了很大影响，一天一个包，一天2个包，问题重复出现，bug引出的bug，比如：就说最近的一个（根据组织机构代码调入清查数据，在2008-12-15日的最后一个版本之前还是可以的，之后版本就不能工作了），2008-12-15 发了4个版本，新增功能提交过来都存在很多问题，基本上没有一个没问题的新功能提交过来。直至今日数据库和制度在调整内容，并且软件还有新功能增加。
