新华人寿渠道管理系统性能测试报告_第1页
新华人寿渠道管理系统性能测试报告_第2页
新华人寿渠道管理系统性能测试报告_第3页
新华人寿渠道管理系统性能测试报告_第4页
新华人寿渠道管理系统性能测试报告_第5页
已阅读5页,还剩42页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

新华人寿渠道管理系统性能测试报告新华人寿渠道治理系统性能测试报告2010年5月21日文档信息文档标题新华人寿渠道治理系统性能测试报告版本号v1.1版本日期2010-5-14打印日期文件名新华人寿渠道治理系统性能测试报告归档名目治理人员审批信息姓名部门/角色意见日期修改历史版本日期修改说明修改人1.02010-5-14草稿1.12010-5-20初稿

名目1. 概述 51.1项目背景 51.2测试目的 52. 测试范畴 62.1测试目标 62.2业务模型 63. 测试环境 83.1系统架构图 83.2测试环境机器配置表 84. 测试方法 94.1基准测试 94.2单交易负载测试 94.3混合场景负载测试 93.4性能测试案例设计 103.4.1系统登录 103.4.2人员信息查询 103.4.3销售团队查询 113.4.4网点信息查询 113.4.5人员差不多信息爱护 123.4.6销售团队信息爱护 123.4.7网点差不多信息爱护 133.5性能测试场景设计 133.5.1系统登录 133.5.2人员信息查询 143.5.3销售团队查询 143.5.4网点信息查询 143.5.5人员差不多信息爱护 143.5.6销售团队信息爱护 153.5.7网点差不多信息爱护 153.5.8混合场景负载测试 155. 测试打算 176. 测试结果 186.1基准测试 186.1.1系统登录 186.1.2人员查询 186.1.3团队查询 186.1.4网点查询 196.1.5人员爱护 196.1.6团队爱护 196.1.7网点爱护 196.2单交易负载测试 196.2.1系统登录 196.2.2人员查询 266.2.3团队查询 316.2.4网点查询 326.2.5人员爱护 336.2.6团队爱护 336.2.7网点爱护 346.3混合场景负载测试 396.4其他负载测试 416.4测试结论与建议 42结论 42建议 437. 附件1: 45概述1.1项目背景本系统的目标是使渠道业务日常治理电子化、简单化,对各渠道业务进展提供强大的后台数据支持。现时期公司迅速进展,业务迅速扩张,业务拓展模式不断创新。公司的销售渠道涉及到个人营销保险、团体保险、银行保险、至尊理财、营销保险等多个领域,由于各个领域的保险特点不同、治理方法也出现出多样性。需要的是一套能够处理并突出表达各个保险领域的特性的销售治理系统,从治理角度动身对销售的各个时期进行操纵,对销售人员进行治理,为销售人员提供从培训、售前、售后以及佣金结算等一系列完整的服务支持。为达到这一目标,需要利用现代的信息处理技术和科学手段,全面实现销售治理中的各项要求,通过运算机辅助实现治理的科学化、规范化、系统化与自动化,与业务系统一起建立一套完整的保险治理系统和网络。1.2测试目的通过模拟,在测试环境上尽量真实再现新华人寿银代渠道销售治理系统生产环境的日常业务量高峰时的场景。通过结果分析,查看哪些业务显现响应时刻长,交易失败的情形。查看新华人寿银代渠道销售治理系统是否符合设计的性能要求。测试范畴2.1测试目标性能测试是针对系统并发处理能力、交易响应时刻等性能指标所进行的测试。目的是在尽可能模拟生产环境的前提下,单一渠道方面的性能,实现以下目标(相关指标参考合同附件):模拟系统在实际生产环境下峰值时的系统处理能力及性能表现。检测软件中的问题:通过并发测试执行,揭示程序中的隐含的问题或冲突,从而修复系统中的薄弱环节。通过对各项测试及监控结果的综合分析,发觉、定位性能瓶颈,为改善系统性能提供整体优化方案,为后期性能调优提供参考依据。保证在生产环境的业务和用户量下,性能满足业务人员操作需求,要紧需求如下:日常平均在线用户数500人,高峰期在线用户数700人。注:目前核心业务系统有效用户数:24045,核心业务系统日常在线用户数平均为2.6K,高峰期在线用户数为3.6K,渠道系统按照核心系统用户数量的20%运算,因此平均在线用户数量为500,高峰为700。薪资考核运算效率:考核运算、薪资运算均能够在2-4小时内完成。其他操作时效要求如下:提交信息爱护,系统应在2秒内响应。按照机构号或人员编码查询信息详情,系统应在2秒内响应。按照条件查询清单,系统应在15-30秒内响应。按照条件生成统计报表,依照复杂性,系统响应时刻不同,最慢应在5分钟内响应。按分支机构进行考核确认,系统应在15分钟内完成。2.2业务模型序号业务模块业务名称类型数据量平均用户数最大用户数响应时刻1系统登录系统登录登录5007005秒2人员治理人员查询查询4000050070030秒3网点治理网点信息查询查询300050070030秒4团队治理销售团队查询查询300050070030秒5人员治理人员修改交易5007005秒6网点治理网点修改交易5007005秒7团队治理团队修改交易5007005秒8薪资考核普处理批处理治理批处理5006002-4小时注:业务模型选择参考了运维部门提供的菜单使用频率参考此处需要对性能场景设计,先做个简单说明。30并发的测试场景,以登录为例,每个并发用户,迭代登录20次,也确实是说30并发,在1.5分钟内前后共有30*20=600人次登录系统,40并发场景,在2分钟内有40*20=800人次登录,50并发场景,在2.5分钟内有50*20=1000人次登录。测试环境3.1系统架构图3.2测试环境机器配置表系统服务器配置操作系统及安装软件台数应用服务器应用服务器服务器:1*2.6G双核2G内存320G硬盘1电源Redhatnash5.1.19.6JDK1.JBoss41销售治理平台数据库和元数据数据库数据库服务器服务器:1*2.6G双核4G内存320G硬盘1电源Redhatnash5.1.19.6Oracle10g1测试方法4.1基准测试测试环境确认之后,对业务模型中涉及的每种业务(系统登录、人员查询、团队查询、网点查询、人员爱护、网点爱护、团队爱护)做基准测试。目的是检查业务本身是否存在性能缺陷。同时为今后的混合场景负载测试性能分析提供参考依据。场景设置:编写测试客户端向新华人寿银代渠道销售治理系统应用服务器发送业务要求并接收返回结果的脚本,在系统无压力情形下运行10次迭代,每次迭代间等待1秒,取业务的平均响应时刻作为衡量指标。4.2单交易负载测试单交易负载测试是对业务模型中涉及的每种业务(系统登录、人员查询、团队查询、网点查询、人员爱护、网点爱护、团队爱护)加上一定量的负载,进行测试以猎取该交易的性能指标。目的是为了验证这些典型交易是否存在并发问题,并猎取其响应时刻,作为混合场景测试中业务模型配比的参考。场景设置:制作单个交易的性能测试脚本,在负载测试工具中设置并发用户数等于30、40、50,每秒登陆10个用户,迭代20次,每次迭代等待1秒,忽略摸索时刻,猎取平均响应时刻。30并发=600人次,40并发=800人次,50人次=1000人次。4.3混合场景负载测试混合场景负载测试是按照业务模型的约定,在一定量的并发情形下测试以下指标:业务的平均交易响应时刻、应用服务器、数据库服务器的资源使用情形、交易正确率等。通过性能测试,能够模拟实际生产环境中在业务处理高峰期实物资产治理系统的压力情形,得到现在的实物资产治理系统性能表现数据,为系统的实际上线运行提供可靠的参考。 场景设置:按照业务模型比例设置测试场景,设置并发量60,每1秒登陆10个用户,忽略摸索时刻,每次运行测试15分钟,每次迭代间等待1秒,收集系统性能变化曲线。4.4性能测试案例设计4.4.1系统登录系统登录脚本名称系统登录程序版本用例编号XH-XTDL-01子系统测试目的测试用户登录的并发能力及系统响应时刻。专门说明目标产生大压力,忽略全部摸索时刻。前提条件应用程序差不多部署,同时存在不同身份的系统使用用户步骤操作是否设置集合点是否设定事务事务名称说明1打开登录页否否2输入用户名、密码、选择机构否否3点击“登录”按钮是是登录设置检查点4登陆后展现页面信息否否5注销用户否是注销编制人员编制日期2010-4.4.2人员信息查询人员信息查询脚本名称人员查询程序版本用例编号XH-RYCX-02子系统测试目的测试人员信息查询功能系统响应时刻。专门说明目标产生大压力,忽略全部摸索时刻。前提条件应用程序差不多部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2选择人员治理人员信息治理人员信息查询否是进入人员查询菜单3输入查询条件否是录入人员查询条件4点击“查询”按钮否是人员查询5勾选需要查询的人员记录,点击明细按钮否是人员明细设置检查点编制人员编制日期2010-4.4.3销售团队查询销售团队查询明细脚本名称销售团队查询程序版本用例编号XH-TDCX-03子系统测试目的测试销售团队查询功能的系统响应时刻。专门说明目标产生大压力,忽略全部摸索时刻。前提条件应用程序差不多部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2选择销售团队治理销售团队查询明细否是进入团队查询菜单3点选查询条件否是录入团队查询条件4点击“查询”按钮否是团队查询5勾选需要记录,点击销售团队明细按钮否是团队明细设置检查点编制人员编制日期2010-04-134.4.4网点信息查询网点差不多信息查询脚本名称网点信息查询程序版本用例编号XH-WDMX-04子系统测试目的测试网点差不多信息爱护系统响应时刻。专门说明目标产生大压力,忽略全部摸索时刻。前提条件应用程序差不多部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2进入菜单:银保渠道网点治理网点信息爱护否是进入网点查询菜单3输入查询条件否是录入网点查询条件4点击“查询”按钮否是网点查询5点击“明细”按钮否是网点明细编制人员编制日期2010-4.4.5人员差不多信息爱护人员差不多信息爱护脚本名称人员入司程序版本用例编号XH-RYRS-05子系统测试目的测试人员入司的系统响应时刻。专门说明目标产生大压力,忽略全部摸索时刻。前提条件应用程序差不多部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2进入菜单:银保渠道人员治理人员信息治理人员信息爱护否是进入人员新增菜单3点击新增按钮否是进入人员修改界面设置检查点4录入或者选录人员信息否是人员信息录入5点击“新增”按钮否是人员入司编制人员编制日期2010-4.4.6销售团队信息爱护销售团队信息爱护脚本名称团队新增程序版本用例编号XH-TDXZ-06子系统测试目的测试团队新增的系统响应时刻。专门说明目标产生大压力,忽略全部摸索时刻。前提条件应用程序差不多部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2进入菜单:银保渠道销售团队治理销售团队爱护否是进入团队爱护菜单3点击新增按钮否是进入团队新增界面4录入或者选录团队信息团队信息录入5点击“新增”按钮否是团队新增编制人员编制日期2010-4.4.7网点差不多信息爱护网点差不多信息爱护脚本名称网点新增程序版本用例编号XH-WDWH-07子系统测试目的测试网点差不多信息爱护系统响应时刻。专门说明目标产生大压力,忽略全部摸索时刻。前提条件应用程序差不多部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2进入菜单:网点治理网点信息爱护否是进入网点爱护菜单3点击新增按钮否是进入网点新增界面设置检查点4填选网点信息否是填写网点信息5点击新增按钮否是网点新增编制人员编制日期2010-04-134.4.8薪资考核批处理网点差不多信息爱护脚本名称薪酬运算程序版本用例编号XH-XZKH-20子系统测试目的测试薪资考核系统响应时刻。专门说明通过前台操作,对系统造成负载压力前提条件应用程序差不多部署步骤操作是否设置集合点是否设定事务事务名称说明1登录系统否否2进入菜单:银保渠道批处理治理薪酬运算申请否是进入薪酬运算菜单3选择部门、月份否是选择薪酬运算条件4点击申请按钮否是薪酬运算申请编制人员编制日期2010-05-244.5性能测试场景设计4.5.1系统登录序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1系统登录基准测试系统登录110001002系统登录30并发系统登录302001011003系统登录40并发系统登录402001011004系统登录50并发系统登录502001011004.5.2人员信息查询序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1人员查询基准测试人员查询110001002人员查询30并发人员查询302001011003人员查询40并发人员查询402001011004人员查询50并发人员查询502001011004.5.3销售团队查询序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1团队查询基准测试团队查询110001002团队查询30并发团队查询302001011003团队查询40并发团队查询402001011004团队查询50并发团队查询502001011004.5.4网点信息查询序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1网点查询基准测试网点查询110001002网点查询30并发网点查询302001011003网点查询40并发网点查询402001011004网点查询50并发网点查询502001011004.5.5人员差不多信息爱护序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1人员入司基准测试人员入司110001002人员入司30并发人员入司302001011003人员入司40并发人员入司402001011004人员入司50并发人员入司502001011004.5.6销售团队信息爱护序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1团队新增基准测试团队新增110001002团队新增30并发团队新增302001011003团队新增40并发团队新增402001011004团队新增50并发团队新增502001011004.5.7网点差不多信息爱护序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1网点新增基准测试网点新增110001002网点新增30并发网点新增302001011003网点新增40并发网点新增402001011004网点新增50并发网点新增502001011004.5.8薪资考核运算测试序号场景名称场景说明执行脚本用户总数循环数量操作间隔查询时刻一次查询二次查询三次查询四次查询1薪资考核基准测试薪资考核11051015202薪资考核30并发运算薪资考核301030601202403薪资考核40并发运算薪资考核401030601202404薪资考核50并发运算薪资考核50103060120240注:薪酬运算场景比较专门,运算完成时没有在前台提示,因此才用roadrunner前台提交运算申请,记录开始时刻;通过去数据库查询或者在前台界面查询运算结果,直到查询出需要的所有结果,记录时刻。终止时刻-开始时刻约为薪资考核运算所用时刻。所有运算应该在4小时之内完成运算。4.5.9混合场景负载测试由于压力演示环境并发用户适量限制,混合场景设置为60人并发混合场景,要紧是测试使用频率最高查询功能。序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1系统登录60并发系统登录0运行15分钟01150人员查询人员查询30团队查询团队查询20网点查询网点查询10人员修改人员修改0网点修改网点修改0团队修改团队修改0薪酬运算薪酬运算前台提交运算申请,后台一直运行注:薪酬运算场景比较专门,运算完成时没有在前台提示,因此才用roadrunner前台提交运算申请,后台一直运行运算,作为负载。测试打算内容开始日期终止日期人力资源金涛李勇君王利鹏测试环境和版本确认2010-4-122010-4-12测试方案编写与评审2010-4-132010-4-16测试数据预备2010-5-072010-5-10测试脚本开发2010-5-102010-5-11测试场景设置2010-5-122010-5-13测试执行2010-5-122010-5-13测试结果分析2010-5-142010-5-14测试报告编写2010-5-142010-5-14系统调优后测试2010-5-172010-5-20修改测试报告2010-5-202010-5-21报告评审2010-5-242010-5-25测试结果6.1基准测试6.1.1系统登录6.1.2人员查询6.1.3团队查询平均响应时刻6.1.4网点查询6.1.5人员爱护待测6.1.6团队爱护待测6.1.7网点爱护6.2单交易负载测试6.2.1系统登录平均响应时刻(单位:秒)30人并发:40人并发:50人并发响应时刻分析:基准响应时刻为:0.675s,在单交易负载测试环境下,30并发系统响应时刻为3.386s,40并发系统响应时刻为4.82s;50并发用户系统响应时刻为6.002s。30并发、40并发,响应时刻小于5秒,符合测试目标;50登录响应时刻大于测试目标要求时刻。CPU利用率(单位:百分比)30人并发:40人并发:50人并发CPU利用率分析:在负载测试过程中,随着压力的增大,应用服务器使用:30并发情形下,应用服务器cpu使用率为峰值80%,平均使用率77%,在正常范畴之内;40并发情形下,应用服务器cpu使用率为峰值100%,平均使用率81%,处以满负荷运行;50并发情形下,应用服务器cpu使用率为峰值89%,平均使用率78%,处以满负荷运行;数据库服务器cpu使用率,峰值均未超过50%,平均值均为超过35%,使用正常;内存应用服务器物理内存使用情形如图,物理内存容量为2G,闲暇约为50M。数据库服务器物理内存使用情形如图,物理内存容量为4G,运行负载时闲暇最大约为500M,最小为0;吞吐量(单位:字节/秒):30人并发:40人并发50人并发吞吐量分析:30人并发吞吐量平均约为9.2M/S,峰值约为14.5M/S,;40人并发吞吐量平均约为9.7M/S,峰值约为16.5M/S,50人并发吞吐量平均约为8.8M/S,峰值约为17M/S,由此可见30~40并发之间,随着用户并发数增加平均吞吐量呈上升趋势,40~50并发并发用户数量增加了,平均吞吐量反而有所减小,由于并发用户超过系统响应能力,因此系统在现有环境下的处理能力约为9.5M/S。处理事务数量(单位:个/秒)30并发40并发:50并发:处理事务数量分析:30并发处理事务量6.3个/秒,40并发处理事务量10.4个/秒,50并发处理事务量6个/秒,由此可见,40并发系统处理能力最高。6.2.2人员查询平均响应时刻(单位:秒)30人并发:40人并发:50人并发响应时刻分析:基准响应时刻为:0.286s,在单交易负载测试环境下,30并发系统响应时刻为5.086s,40并发系统响应时刻为6.371s;50并发用户系统响应时刻为8.133s。系统在15-30秒之内返回结果,完成测试目标要求。CPU利用率(单位:百分比)30人并发:40人并发:50人并发CPU利用率分析:在负载测试过程中,随着压力的增大,应用服务器的CPU成为系统瓶颈。30并发情形下,应用服务器cpu使用率为峰值99%,平均使用率84%,处以满负荷运行;40并发情形下,应用服务器cpu使用率为峰值99%,平均使用率86%,处以满负荷运行;50并发情形下,应用服务器cpu使用率为峰值99%,平均使用率85%,处以满负荷运行;数据库服务器cpu使用率,峰值均未超过60%,平均值均约为超过35%,使用正常;吞吐量(单位:字节/秒):30人并发:40人并发50人并发吞吐量分析:30人并发吞吐量平均约为7.5M/S,峰值约为10M/S,;40人并发吞吐量平均约为7.7M/S,峰值约为14.5M/S,50人并发吞吐量平均约为7.7M/S,峰值约为10M/S,由此可见系统在现有环境下,处理能力约为7.6M/S。处理事务数量(单位:个/秒)30并发40并发:50并发:6.2.3团队查询平均响应时刻(单位:秒)30人并发:40人并发:50人并发响应时刻分析:基准响应时刻为:0.118s,在单交易负载测试环境下,30并发系统响应时刻为1.355s,40并发系统响应时刻为1.681s;50并发用户系统响应时刻为2.101s。系统在15-30秒之内返回结果,完成测试目标要求。团队查询其他参数结果类似于人员查询。6.2.4网点查询平均响应时刻(单位:秒)30人并发:40人并发:50人并发响应时刻分析:基准响应时刻为:0.19s,在单交易负载测试环境下,30并发系统响应时刻为2.988s,40并发系统响应时刻为3.509s;50并发用户系统响应时刻为4.832s。系统在15-30秒之内返回结果,完成测试目标要求。网点查询其他参数结果类似于人员查询。6.2.5人员爱护待测6.2.6团队爱护待测6.2.7网点爱护平均响应时刻(单位:秒)30人并发:40人并发:50人并发响应时刻分析:基准响应时刻为:0.208s,在单交易负载测试环境下,30并发系统响应时刻为0.594s,40并发系统响应时刻为1.5s;50并发用户系统响应时刻为1.35s。网点新增系统响应时刻小于5秒,符合测试目标。CPU利用率(单位:百分比)30人并发:40人并发:50人并发吞吐量(单位:字节/秒):30人并发:40人并发50人并发吞吐量分析:30人并发吞吐量平均约为7.5M/S,峰值约为12.5M/S,;40人并发吞吐量平均约为8.5M/S,峰值约为13M/S,50人并发吞吐量平均约为7M/S,峰值约为10M/S,由此可见30~40并发之间,随着用户并发数增加,吞吐量呈上升趋势,40~50并发并发用户数量增加了,吞吐量反而有所减小。处理事务数量(单位:个/秒)30并发40并发:50并发:6.3混合场景负载测试平均响应时刻(单位:秒):CPU利用率吞吐量(单位:字节/秒):混合场景结果:混合查询场景60用户并发,人员查询响应时刻为:4.069s,网点查询响应时刻为:3.672s,团队查询响应时刻为:3.266s,系统在15-30秒之内查询出结果,完成测试目标要求。应用服务器cpu峰值使用率为99%,平均使用率为88%,满负载工作;数据库服务器cpu峰值使用率为70%,平均使用率为20%,工作在正常范畴;6.4其他负载测试测试场景设置如下:序号场景名称场景说明执行脚本用户总数循环数量操作间隔并发发出间隔循环间隔退出间隔同步点1系统登录100并发系统登录0运行15分钟01150人员查询人员查询40团队查询团队查询30网点查询网点查询30人员修改人员修改0网点修改网点修改0团队修改团队修改0响应时刻如下:系统后台报专门,错误日志如下图。需要对系统进行调优。6.4测试结论与建议结论在目前测试环境下(以混合场查询景为例)。应用服务器cpu和物理内存容量成为系统瓶颈。对系统施加压力时,cpuqueuelength(排队进程)队列平均长度在5~10,使用率达到80%以上,现有双核cpu不能及时处理并发要求,形成系统瓶颈,需要升级。内存方面,物理内存闲暇约50M,若要并发处理更多用户,需要升级。数据库服务器物理内存成为系统瓶颈。数据库受内存制约,物理内存剩余80M,形成系统瓶颈,需要升级。Cpu使用率峰值未超过55%,平均使用率在50%,进程有排队现象(QueueLenght),若需要处理更大数量的并发,建议增加cpu数量,增强并发处理能力。综上,应用服务器和数据库服务器,对系统性能都有所制约。建议依照本次性能测试结果,对系统提出以下改进性能的建议:关于测试环境:建议对现有硬件经行升级。参考配置见HYPERLINK附件1;现有服务器部署于百兆局域网内,100M带宽的实际传输速度为于12M左右,本次测试使用10M,假如需要处理更大量的并发要求,服务器需要部署在千兆网内,服务器网卡使用100/1000M网卡。应用服务器压力较大,若使用范畴是是全国范畴,建议考虑负载均衡;关于程序:100用户并发查询,jboss后台报专门日志,需要优化应用服务器打开文件数。HYPERLINK详见:6.4其他负载测试需要优化程序war包数据连接数;需要优化数据库连接数,以oracle为例需要调整processes和sessions;需要对数据库查询优化名称30并发40并发响50并发60并发混合人员查询5.0866.3718.1334.069(50%)团队查询1.3551.6812.1013.672(33%)网点查询2.9883.5094.8323.266(17%)

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论