XXX企业大数据测试用例及报告目录1系统性能指标和测试结果说明 (4)1.1性能测试报告 (4)1.1.1测试目标 (4)1.1.2测试内容 (4)1.1.3测试环境 (4)1.1.4测试过程和结果 (6)1.2TPC-DS测试报告 (9)1.2.1测试目标 (9)1.2.2测试内容 (9)1.2.3测试环境 (11)1.2.4测试过程和结果 (12)1.3量收迁移验证性测试报告 (13)1.3.1测试目标 (13)1.3.2测试内容 (13)1.3.3测试环境 (14)1.3.4串行执行情况 (14)1.3.5并行执行情况 (16)1.3.6生产表数据规模 (17)1.3.7测试结果 (19)1.4某银行性能测试报告 (19)1.4.1测试目标 (19)1.4.2测试内容 (19)1.4.3测试环境 (19)1.4.4测试过程和结果 (20)2系统测试 (32)2.1系统测试方法 (32)2.2系统测试阶段 (33)2.3系统测试相关提交物 (34)1系统性能指标和测试结果说明1.1性能测试报告1.1.1测试目标运营商手机上网记录查询系统案例，以某运营商为例，日均上网记录数近10亿条，每月数据量近9TB，移动互联网用户快速增加，智能终端迅速普及、户均流量显著增长，上网记录数据将进一步猛增，每6个月，流量翻一番，如此大的数据量已经超越了传统关系型数据库可管理的容量上限，关系型数据库上对大规模数据进行操作会造成系统性能严重下降。
通过本测试，验证星环科技成熟稳定的商用Hadoop平台，是否可以有效解决数据采集、加载、存储、查询、分析等问题。
1.1.2测试内容1）存储节点数和存储量验证；2）并发加载数据的效率验证；3）分别选取简单查询（短信话单查询），单表统计（某天某客户通话次数），大表关联统计（统计指定用户的上网记录）三个应用场景验证产品性能。
1.1.3测试环境软硬件环境配置如下：表9-1 服务器配置部署环境如下：表9-2 集群配置网络拓扑情况如下：图9-1 拓扑结构图1.1.4测试过程和结果1）现有HDFS集群已被占用10.5PB，3个副本，压缩率在1/3左右，因此实际HBase 表数据也已经有3.5PB左右。
目前数据存放6个月，每天导入日志数据在21TB左右，每月导入新增日志数据量为630TB，近一个月为常用热数据，数据量增长较快。
2）并发加载数据的效率Transwarp Hyperbase集群每秒平均达到1500万记录/秒，峰值时达到5000万/秒，集群导入性能没有问题。
3）支持并发查询数目：远高于100000请求/秒上网记录查询速度：不高于1秒（含用户访问查询页面的时间）场景一：短信话单查询图9-3 话单查询表场景二：某天某客户通话次数：场景三：关联统计相关测试，统计制定用户的上网记录图9-4 上网记录表1.2TPC-DS测试报告1.2.1测试目标通过国际标准测试TPC-DS测试，验证星环TDH产品符合数据仓库需要，能够满足数仓业务使用要求。
1.2.2测试内容标准事务性能管理委员会(TPC)是目前最知名的数据管理系统评测基准标准化组织。
在过去二十多年间，该机构发布了多款数据库评测基准。
TPC-DS是TPC发布的标准测试场景之一，用于验证数据库产品是否符合数据仓库的业务需要。
TPC-DS采用星型、雪花型等多维数据模式。
它包含7张事实表，17张纬度表平均每张表含有18列。
其工作负载包含99个SQL查询，覆盖SQL99和2003的核心部分以及OLAP。
这个测试集包含对大数据集的统计、报表生成、联机查询、数据挖掘等复杂应用，测试用的数据和值是有倾斜的，与真实数据一致。
可以说TPC-DS是与真实场景非常接近的一个测试集，也是难度较大的一个测试集。
TPC-DS的这个特点跟大数据的分析挖掘应用非常类似。
Hadoop等大数据分析技术也是对海量数据进行大规模的数据分析和深度挖掘，也包含交互式联机查询和统计报表类应用，同时大数据的数据质量也较低，数据分布是真实而不均匀的。
因此TPC-DS 成为客观衡量多个不同Hadoop版本以及SQL on Hadoop技术的最佳测试集。
这个基准测试有以下几个主要特点：1）一共99个测试案例，遵循SQL99和SQL2003的语法标准，SQL案例比较复杂2）分析的数据量大，并且测试案例是在回答真实的商业问题3）测试案例中包含各种业务模型（如分析报告型，迭代式的联机分析型，数据挖掘型等）4）几乎所有的测试案例都有很高的IO负载和CPU计算需求TPC-DS标准测试集99个案例，详见本建议书附录部分《TPC-DS测试集99 query 说明》1.2.3测试环境1.2.4测试过程和结果1.3量收迁移验证性测试报告1.3.1测试目标通过选取多个量收系统典型实际应用场景测试，验证星环TDH产品能够实现量收系统各类功能应用，能够较好的满足量收系统迁移要求。
1.3.2测试内容本文档记载了较为详细的测试案例，内容包括量收系统功能各类型的技术和业务场景，包含六个方向应用。
具体分别是：1）大数据量数据加载，计算及汇总，此方向取“范围段加载ETL”。
2）高并行计算，复杂计算，大表关联，此方向取“收入宽表计算ETL”。
3）大数据量，高并发查询。
此方向取“量收日统计表查询”。
4）Cognos复杂逻辑应用。
此方向取“淡旺季报表统计”。
5）大表的update和delete类SQL计算。
此方向取“营业客户数据加载计算ETL”。
6）Oracle存储过程运算。
此方向取“报刊在Oracle中存储过程”。
1.3.3测试环境表9-5 配置ID Desc硬件配置(8台) CPU：64Intel(R)Xeon(R)********************，内存：64GMemory，硬盘：300GSAS操作系统AsianuxServer4(HiranyaSP4)平台软件transwarp-4.3.2-Final-23543-zh.el6.x86_64.tar.gz Manager:http://10.1.144.36:8180/admin/adminInceptor:http://10.1.144.53:4040/HDFS空间1065GB1.3.4串行执行情况总耗时如下：表9-6 耗时串行执行集群Workload：图9-2 性能展示图11.3.5并行执行情况并行执行总耗时如下：表9-7 耗时并行执行workload：图9-3 性能展示图21.3.6生产表数据规模表9-8 生产表1.3.7测试结果所有六个测试案例，包含存储过程案例，经过较少的脚本修改（脚本修改量小于1%），就能够直接在新的TDH环境中运行，且运行结果正确无误，验证了量收迁移到TDH的技术可行性。
1.4某银行性能测试报告1.4.1测试目标运行某银行数据分析业务，以验证星环Transwarp Data Hub平台的性能指标。
1.4.2测试内容选取某银行高并发的理财查询业务，以及相关业务场景进行测试，包括现有在DB2、DPF、以及Teradata上面的应用，进行性能比对。
1.4.3测试环境测试环境采用5台X86服务器，搭建星环Transwarp Data Hub大数据平台，进行测试。
表9-9 测试表集群部署：表9-10 集群部署1.4.4测试过程和结果数据加载与导入：将文件较为均匀的分到集群的各个机器上，编写HDFS上传脚本，同时向HDFS上传数据，通过记录上传时间和上传文件大小来计算数据并发加载的速度。
测试步骤如下：表9-11 场景1表9-12 场景2表9-12 场景3表9-13 场景4数据挖掘测试使用商户信息表(XWXS_EPOS_MCHNT_INFO)和交易流水表(XWXS_EPOS_TRANS)在RStudio上做了POS机分布建模、用户流失预警与用户聚类三个案例。
北京地区POS机分布建模根据商户信息和交易流水记录为POS机交易建模，生成POS机分布图、POS机刷卡次数热点图、POS机刷卡金额热点图。
根据上面的建模结果，可以为银行决策提供理论依据，主要意义在于：1) 关注刷卡次数多的地区，可以在相关地区增加相应ATM取款机。
2) 关注刷卡金额大的地区，可以在相关地区增加银行服务点。
3) 在刷卡次数多，金额大的地区推广信用卡，增加银行其他业务。
4) 避开消费聚集区，推广投放行银行广告，增加投放效果。
图9-4 刷卡金额密度图图9-5 刷卡次数密度图除此之外，挑选了一批在现有系统中运行时间较长或无法成功运行的业务场景用于TDH的测试。
更新售后客户产品表：表9-14 客户产品表PROC_CUSTPROCFLJRZ.sqlcase_7_1_tdh.sql统计两张交易大表一天的交易信息：表9-15 交易表HARDOOP_TEST.txtcase_7_2_tdh.txt统计两张交易大表一段时间内的交易信息：表9-16 交易表case_7_2_1_tdh.sql更新金融资产月报详细信息表：表9-17 月报表case7_3_sa.sqlcase7_3_tdh.sql更新金融资产月报基础表：表9-18 基础表case7_4_sa.sql case7_4_tdh.sql2系统测试2.1系统测试方法本方案对系统建设过程中及最终的交付过程设计了详细的测试目标，并针对这些目标提供了多种不同的测试方法：1)业务/需求驱动测试：从用户的实际业务需求出发，分析业务目标、业务流程、用户角色、业务规则、业务数据、业务发展等测试对象，针对这些对象确定测试范围、测试方法和策略。
测试是否充分，也是从业务流程和数据来衡量。
软件系统能否充分满足业务需求，是业务/需求驱动测试最关切的问题，基于需求的验证方法、基于用户场景的测试方法。
2)产品质量风险驱动测试：根据产品质量模型：内部质量-->外部质量--> 使用质量来进行测试，强调全生命周期消除产品质量风险，从代码评审、代码复杂度度量等工作开始，对内部质量进行评估以暴露质量风险，然后逐步扩展到系统外部质量、用户使用质量的评估，持续揭示、反馈产品质量主要风险。
3)功能驱动测试：就是从系统功能特性出发，根据软件功能规格设计说明书，针对每个功能进行验证，确定功能运行是否正常，是否和设计保持一致。
一般会将功能进行分解，分为子功能、子功能的子功能，形成功能点列表，针对功能点进行测试用例设计和执行。
4)结构驱动测试：基本类似于：结构化测试、白盒测试。
从程序结构来驱动测试，进行程序结构分析，逐步覆盖程序的各个部分及其关联关系，如基于组件测试、基于接口测试或基于API进行测试；从代码结构进行测试，包括代码行覆盖、分支覆盖、基本路径覆盖等。
结构驱动测试的充分性度量会更客观性，特别是基于代码覆盖率分析，本项目采用相关工具进行则自动化测试。