实现与测试课件_第1页
实现与测试课件_第2页
实现与测试课件_第3页
实现与测试课件_第4页
实现与测试课件_第5页
已阅读5页,还剩77页未读 继续免费阅读

下载本文档

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

文档简介

第9章实现与测试9.1实现9.2测试9.3过渡与评价9.1实现9.1.1概述1.系统实现的任务系统实现的任务是通过一系列迭代过程,把信息系统的设计模型转变成为可以交付测试的信息系统,其重心是实现信息系统的软件。信息系统软件由源程序代码、二进制可执行代码和相关的数据结构构成,这些内容以构件的形式被组织。实现的工作包括确定系统的实现结构,子系统、类和接口的实现,单元测试,系统集成等。2.实现工作的特点1)基于构件的实现构件(Component)是信息系统软件的构成件。在不同的开发阶段,构件表现为分析件、设计件、实现件、测试件等不同形式,也可以称其为分析构件、设计构件、实现构件和测试构件。实现构件是实现的产物,并具有《源代码件》、《执行件》、《文件》、《库》、《表》、《文档》等多种形式。《执行件》是《源代码件》编译后的结果,可以直接投入运行。《文件》是信息的存储体,可以是《源代码件》、《执行件》、《文档》等内容。《库》可以是类库、动态链接库、数据库等。《表》表示数据库中的数据表。《文档》泛指形成的所有文字材料。3.实现模型实现模型(ImplementationModel)是在实现工作中,对信息系统的抽象描述。在实现模型中,实现系统是实现模型的顶层子系统,实现系统与设计模型中的设计系统相对应。实现系统由多个实现子系统构成,实现子系统又呈现为层次结构,在实现子系统中可以包含其它实现子系统。每一个实现子系统又由构件和接口构成。实现模型见图9.1。图9.1实现模型4.工作过程系统实现的工作过程见图9.2。首先,由结构师确定实现结构,然后再制定实现的迭代计划。接下来由构件师通过多次迭代实现各个子系统和每一个子系统中的类和接口,并进行单元测试。构件师把每次迭代的结果交由集成师进行系统集成。通过多次迭代完成实现最终系统。本节介绍实现的主要工作,单元测试将在测试一节介绍。

9.1.2实现结构1.实现结构的概念实现结构(ImplementationArchitecture)是信息系统在实现阶段所呈现的系统结构,它由各个子系统按照确定的组成关系构成。信息系统实现结构的系统框架与设计结构的系统框架完全相同,子系统的数目和相互之间的关系也完全一致。实现结构与设计结构的区别是子系统中的内容不同。设计子系统中包括用例设计、设计类和接口,而实现结构的子系统中则是构件和接口。实现结构与设计结构的区别见图9.3。图9.3实现模型与设计模型的跟踪关系实现模型中的子系统和设计模型中的子系统是一一对应的,由一个实现子系统可以跟踪到一个设计子系统。设计子系统中的设计类,在实现子系统中要变为构件。一个构件可能包括多个设计类,但构件总可以跟踪到设计类。设计子系统对外提供的接口与实现子系统对外提供的接口应该完全相同。图9.3中的接口a是子系统向外提供的接口,接口b是该子系统所依赖的接口。3)关键构件在节点中的分布所有构件最终都要分布到不同的节点上。在结构实现时,需要首先把关键构件分布到相应的节点上,通过系统配置图来描述关键构件在节点上的分布情况。例如,图9.4是分布在书店信息系统中销售节点、结算节点、数据库服务器上的几个关键构件。图9.4关键构件节点分布示例9.1.3实现子系统1.构件设计设计模型中的子系统包括设计类、用例设计和接口等内容。设计模型转变成为实现模型之后,实现模型中的子系统则是由一个个构件构成的(如图9.3)。这就要求构件师在实现一个子系统时,首先确定子系统中各个类应该被含包到哪些构件之中。这项工作主要确定子系统应该由哪些构件所构成,并没有实现具体的构件,所以被称为构件设计。图9.5“售书处理”销售和结算节点的构件设计在“数据库服务器”上,有四个子系统和四个实体类。四个实体类均作为数据表存放,四个子系统对四个数据表提供管理,而且管理功能都比较具体。因此,可以把四个实体类设置为四个《数据表》构件,把四个子系统设置成为四个《执行件》构件。其构件设置见图9.6。“售书处理”用例经过分析之后的构件在节点上的分布见图9.7。图9.6“售书处理”数据库服务器构件设计2.类的实现类实现的工作需要编写类的程序代码,并把编好的程序代码类放入到构件之中。实现类的依据是设计类和设计类所提供的接口,实现类的工作包括生成类、类属性代码和类操作代码等。在实现一个类之前,首先应该确定该类所属的文件构件。文件构件是指类代码所在的以文件形式组织的构件。图9.6已经反映出类与构件的对应关系,但构件和文件构件两个概念并不完全一样。文件构件就是文件,它是系统对信息在磁盘上的逻辑存储单位。系统所有构件最终都需要以文件的形式来存储。在一个文件中可以存放一个构件,也可以存放多个构件。实现类的构件与文件的关系也因编程语言而定。由于在设计类中对类以及类的属性和操作已经按照所采用的程序设计语言的语法格式进行了描述,因此,在此生成类属性代码的工作就相对简单了,只需要在所定义的类中描述类的各个属性。需要注意的是,应完全按照程序设计语言的语法格式,描述各个属性的可见性、属性名、属性的类型,如果有初始值,也应在属性定义时一并赋给。类操作的实现比实现属性要复杂。需要用程序设计语言编制能够完成该操作功能的程序代码。图9.8是用Java语言描述的“书目”类的程序代码,图9.9是“待售图书”类的程序代码。“待售图书”类是“书目”类的子类。//类名:Books.java书目package销售管理publicclassBooks{//定义属性StringbookNo;//书号StringbookName;//书名Stringauthor;//作者StringpublishNo;//出版社编号Floatprice;//单价DatepublishDate;//出版日期IntbookTypeNo;//图书类别//定义操作publicvoidsetBookNo(StringbookNo)//写书号{this.bookNo=bookNo;}publicStringgetBookNo()//读书号{returnthis.bookNo;}publicvoidsetBookName(StringbookName)//写书名{this.bookName=bookName;}publicStringgetBookName()//读书名{returnthis.bookName;}publicvoidsetAuthor(Stringauthor)//写作者{this.author=author;}publicStringgetAuthor()//读作者{returnthis.author;}publicvoidsetPublishNo(StringpublishNo)//写出版社编号{this.publishNo=publishNo;}publicStringgetPublishNo()//读出版社编号{returnthis.publishNo;}publicvoidsetPrice(Floatprice)//写单价{this.price=price;}publicFloatgetPrice()//读单价{returnthis.price;}publicvoidsetPublishDate(DatepublishDate)//写出版日期{this.publishDate=publishDate;}publicDategetPublishDate()//读出版日期{returnthis.publishDate;}publicvoidsetBookTypeNo(IntbookTypeNo)//写图书类别{this.bookTypeNo=bookTypeNo;}publicIntgetBookTypeNo()//读图书类别{returnthis.bookTypeNo;}}图9.8“书目”类的程序代码3.接口的实现在实现工作中,需要描述接口和实现接口。描述接口是通过程序设计语言所提供的语法格式,把接口精确地描述出来。实现接口则是在类或子系统中,对接口所定义的操作通过确定的方法予以实现。接口的实现与类中操作的实现完全相同,无非是这些操作是接口中定义的操作。对接口的描述应视所选用的程序设计语言而定,有些程序设计语言提供对接口的描述语句,但有些则不提供对接口的描述功能。下面用Java的接口描述语句来描述图9.7中的接口a。接口a的全名是“收款接口(InceptBF)”,它是“待售图书”类向“收书款”类所提供的接口。该接口向“收书款”类提供“读书单”、“写交款标记”和“读交款标记”三个操作。接口描述见图9.10。系统集成是一个渐进的、逐步迭代的过程。从大的方面看,需要通过多次迭代构成最终系统,把每一次迭代的结果集成到上一次迭代的内容之中形成新的中间系统。在每一次迭代中,又需要把多个类集成为构件,把多个构件集成为子系统,或者把多个构件集成为能够实现本次迭代目标的中间结果。集成的过程是一个设置集成环境、组装、测试和实施运行的过程。首先需要设置集成环境。集成的基础环境是系统开发的环境。9.2测试9.2.1概述1.测试的概念信息系统测试是在信息系统开发过程中,通过确定的方法,从信息系统模型和软件代码中发现并排除潜在的错误,以得到能可靠运行的信息系统的过程。信息系统开发的复杂性决定了在所开发的信息系统中肯定会隐含和残存各种各样的错误和问题。信息系统是一个复杂整体,包括硬件和软件、模型和代码、程序和数据。其中任何一个部分出现问题,信息系统都不能够正常运行。因此,从广义上讲,信息系统测试是对信息系统所有内容的测试。硬件网络和系统支撑软件是可以可靠使用的成熟产品,在应用环境中,对其测试主要限于安装测试和协调性测试。而数据的正确性则需要由数据员来保证。因此,本节主要讨论对信息系统模型和程序代码的测试。2.测试的工作测试要做大量的工作。它包括确定测试目的和测试对象、编制测试计划、组织测试队伍、选择测试方法、设计测试用例、实施测试和测试结果评价等项工作。根据测试的对象和时间顺序,需要进行模型测试、单元测试、集成测试、系统测试和验收测试等方面的工作。3.测试的基本原则(1)建立一支独立于开发的测试队伍。开发者与测试者对信息系统持有完全不同的态度。开发是建设性的,它以构建满足用户需要的信息系统为目的。系统中问题越少,开发者的成功感越高。而测试是破坏性的,它假定被测试的信息系统中存在问题,并以找出问题为目的。被找出的问题越多,测试人员的成就感越强。由于开发者和测试者对系统持有不同的态度,因而原则上不能由开发者测试自己所开发的系统。(2)尽早不断地进行测试。应尽早在系统开发的各个阶段不断地进行测试,以便及时发现系统分析、系统设计和系统实现中存在的缺陷和错误,以免积少成多,在最后的测试阶段再来解决,造成不必要的人力和物力的浪费。(3)严格按照测试计划进行测试。应该严格按照测试计划进行测试,以保证测试进度,使测试和纠错工作在预定的范围内进行,避免随意性。(4)精心设计测试用例。测试用例直接反映被测对象的覆盖范围和测试深度。好的测试用例能够集中发现系统中存在的隐患。因此,必须精心设计测试用例,用尽可能少的测试投入发现尽可能多的问题。(5)对错误多发程序段重点测试,对改正过的程序进行回归测试。在测试过程中,发现的错误越多,说明存在的隐患越大,对这样的测试对象越应该重点进行深入测试。在纠正错误后还必须重新测试,以免带来新的错误。(6)妥善保存各类测试资料,为系统维护提供方便。当系统功能增加后,可以利用以前的测试用例或在其基础上进行修改、扩充后,再次用于系统测试,为重新测试或追加测试提供方便。9.2.2测试方法对信息系统测试可以采用多种方法,并可从不同角度对测试方法进行分类。根据是否执行被测程序,可以分为静态测试和动态测试,其中动态测试方法又可以分为功能测试方法和结构测试方法;根据测试对象,可以分为模型测试方法和程序测试方法;根据开发方法,可以分为传统测试方法和面向对象测试方法;根据测试的重复性,可以分为顺序测试和回归测试;根据被测对象的覆盖性,可以分为穷举测试和抽样测试。下面主要介绍静态测试方法和动态测试方法。1.静态测试方法静态测试是由测试者通过阅读、检查、分析被测的信息系统模型以及程序代码,发现错误和问题的一种测试方法,这种测试不运行被测试的程序。静态测试一般被用来检查模型和文档的正确性,查找程序中存在的逻辑问题。静态测试难以查出程序中隐藏的深层问题,不能代替动态测试。2.动态测试方法动态测试是在计算机上直接运行测试实例,以发现程序错误的一种测试方法。动态测试方法又可以分为功能测试和结构测试两种方法。

功能测试又称为黑盒测试,这种测试将软件看成黑盒子,完全不考虑程序内部的结构,只根据测试用例检测程序是否满足功能说明书所指定的功能的一类测试方法。结构测试又称为白盒测试。这种测试要求测试者必须了解程序的内部逻辑结构,通过对不同逻辑路径和过程的测试,检查程序是否满足设计的要求。测试用例对路径的覆盖率越高,测试范围越广,测试越充分。20次BA520条路径。9.2.3模型测试1.模型测试的意义检查并发现系统模型中存在错误的工作被称为模型测试。信息系统开发过程要建立大量的模型。只有完整、正确和一致的系统模型才有可能得到成功的信息系统,错误的系统模型必然带来错误的结果。另外,信息系统的错误具有放大效应,前期模型中的错误带到后期开发中,会把错误蔓延到更多的地方,并且解决起来需要花费更大的代价。因此,通过模型测试及时发现并纠正系统模型中的错误,对信息系统开发具有重要意义。模型测试是一项十分庞杂的工作。因为信息系统具有多种模型,包括业务模型、需求模型、分析模型、设计模型和实现模型等,每一种模型都是从一个阶段或一个侧面对信息系统的描述。保证这些模型的正确性、一致性和完整性是一项十分困难的工作。2.模型测试的方法和步骤可以运用多种方法进行模型测试,但较实用的还是模型审查法。模型审查法是由建立模型的人员或专家,按照审查标准对所要测试的模型文档进行分析和审查,找出模型中存在的问题。模型审查的一般过程如下:(1)确定审查的模型对象和审查的范围。(2)收集被审查的模型文档材料。(3)组织审查小组。(4)制定审查计划,确定审查标准。(5)对模型材料实施审查。(6)收集并分析审查结果。(7)形成审查结论。3.模型测试的实例模型审查应该按照完整性、正确性和一致性三个方面的标准要求进行。对用例图而言,完整性的含义是该用例图完整地描述了被审查部分所需要的功能,既没有漏掉必须要的功能用例,也没有包含不需要的功能用例。

正确性的含义是每一个用例都精确地描述了所要描述的系统功能,这样用例描述才是规范而正确的。

一致性含义更为广泛,要求本图与其它用例图没有冲突和矛盾,与系统功能没有矛盾。我们以需求模型中的用例图为例讨论模型审查的基本过程。这里假定审查书店管理中的“图书销售管理”的用例图(见图9.11)。图9.11“图书销售管理”功能用例图根据模型审查的标准,确定对用例图审查的重点和方面:①该模型是否全面、准确地描述了“图书销售”应该具有的功能?是否存在疏漏或不需要的功能?②系统边界的划分是否合理?③所确定的参与者是否正确?④用例图的描述是否规范?用例命名是否准确?⑤本图与其它模型是否存在不一致的地方?⑥本图所需的描述文档是否齐全?根据确定的审查重点和方面,由审查人员对用例图进行审查。发现两个问题:①缺少“销售分析”功能用例;②缺少详细的用例说明。9.2.4单元测试单元测试是指对实现的构件所实施的测试。单元测试包括构件中的类测试、类关系测试、对象交互测试和构件本身的测试。单元测试过程一般分为制定测试计划、设计测试用例、实施测试等步骤。

类测试主要测试类的属性和操作的方法。类测试可以采用代码检查和执行测试用例两种方法。两种方法各有利弊:代码检查简单、易于实施,但是容易受人为错误的影响,而且每一次回归测试都要重新完整地检查代码;执行测试用例测试得比较彻底,但构造测试环境和开发测试驱动程序可能需要花费较大的工作量。因此,应视具体情况选择测试方法。属性测试主要测试类的属性是否有遗漏或重复,属性名写法是否规范、正确,属性类型设置是否正确等。一般对属性的测试可以直接通过检查程序文本来查找错误。操作测试是测试类中操作的方法是否存在错误。操作测试可以采用执行测试用例的方法,其中又可以具体采用规格测试和结构测试两种方法。例如,对图9.9“待售图书”类中的“写书单号”操作setBookBillkNo(StringbookBillNo)进行测试,先给参数bookBillNo设置一个合适的书单号,执行这个操作之后,在属性bookBillNo中就应该存有这个书单号。接下来执行“读书单号”操作getBookbillNo(),就会把属性bookBillNo中的书单号读出来。结构测试也被称为白盒测试,它要求测试者深入到方法内部,测试操作方法的正确性。其所设置的测试用例要保证能够遍历程序的所有路径。尤其对关键路径和可能存在问题的路径要予以高度关注。例如,对图9.9中的“计算折扣率”操作countDiscount()的测试,就要考虑销售图书册数在大于等于100、大于等于50、大于等于20、大于等于10,以及不大于10的情况下五种路径的测试。在设置测试用例时,100、50、20、10这几个数字就是关键的临界数字。采用测试用例的方法进行类测试时,除了要求构建有效的测试用例之外,还要建立测试驱动程序。所谓测试驱动程序,就是能够运行测试用例,对被测试类实施测试的一整套程序。测试驱动程序的设计应该根据被测类的具体要求而定。在设计测试驱动程序时,尽量借用其它已经使用过的相似类的测试驱动程序,以减轻设计测试驱动程序的工作量。9.2.5集成测试1.集成测试概念集成测试是把单元测试所得到的构件,按照系统结构要求集成为最终信息系统所实施的测试。每个构件可单独正常工作,但并不能保证组合在一起也能正常工作。集成测试将已测试过的构件组合在一起,重点测试各构件之间的接口和联系,以及各构件之间的协调一致性,发现与接口有关的错误。

2.集成测试方法集成测试方法可以分为集中式集成测试和迭代式集成测试两种方法。集中式集成测试是指将单元测试所得到的各个构件集中到一起进行整体测试的方法。集中式集成测试就像在工厂生产线的最后装配工序时对产品部件所实施的测试。集中式集成测试一般被用在传统软件开发过程中。统一软件开发过程规定软件开发采用迭代式开发,而不宜采用集中式集成测试方法。迭代式集成测试是指在迭代过程中,将已测试的构件增添到中间系统之中时所进行的测试。每进行一次迭代都要进行一次测试。迭代过程中系统范围在逐步扩大,所以错误容易被定位。3.集成测试过程集成测试是伴随系统集成的一个较长的过程,并需要通过多次迭代来完成。在集成测试之初,首先应该制定详细的集成测试计划。集成测试计划应该根据系统集成计划的确定而定。整个集成测试应该在集成测试计划的指导下有条不紊地进行。对于每一次迭代测试,应该按照以下步骤进行测试工作:(1)确定被测对象。明确本次迭代测试需要测试的构件以及要把这些构件增加到的中间系统。(2)设计测试用例。所设计的测试用例应该能够覆盖被测内容,尽可能发现和暴露隐藏的问题。(3)设置测试环境。测试环境要能够正确运行被测构件和测试用例。由于这些构件要增加到中间系统之中,因此测试环境应该以中间系统为基础。(4)实施测试。运行测试用例,发现测试过程中暴露的问题,并及时记录所发现的问题。(5)分析并报告测试结果。9.2.6系统测试系统测试是将软件、硬件、网络等系统的各个部分连接在一起,对整个系统进行总的功能、性能等方面的测试。其任务就是测试软件与系统其它部分是否能正常配套工作。通过与系统的需求相比较,发现所开发的系统与用户需求不符或矛盾的地方。常见的系统测试有以下几类:1)恢复测试恢复测试检测系统的容错能力。其方法是,首先采用各种方法使系统出现故障,然后检验系统在故障状态下的恢复能力。2)安全测试安全测试检测系统的安全机制、保密措施是否完善且没有漏洞,以验证系统的防范能力。其方法是,设计测试用例,模仿非法入侵者,采用各种方法突破系统安全保密防线,从而检测系统是否有安全保密方面的漏洞。理论上讲没有进入不了的系统,但只要使非法入侵花费的代价较大,入侵失去实际意义即可。3)强度测试强度测试是对系统在异常情况下的承受能力的测试,是为了检测系统在极限状态下运行时,性能下降的幅度是否在允许的范围内。设计测试用例时,考虑让系统处于非正常数据量、非正常工作效率、非正常的运行状态下,以发现不稳定或不正常的情况组合。4)性能测试性能测试是检验系统是否满足系统分析说明书对性能的要求。性能测试的内容主要包括响应时间、处理速度、吞吐量、处理精度等。性能测试贯穿于软件测试的各个阶段,通常与强度测试结合进行,并同时对软、硬件进行测试。9.2.7验收测试经过以上种种测试后,系统已能正常安全运行,但其功能和性能是否确实与用户的要求一致,还需经过专家的评估和用户的认可。首先要进一步验证信息系统的有效性,检查系统的功能和性能是否与用户的要求一样(其标准是系统需求说明书);然后审查系统的配置情况;再运行系统,记录运行情况,列出缺陷清单,提出解决办法;最后由专家对系统功能和性能做出评估,并经管理部门和用户认可,信息系统方可交给用户使用。9.3过渡与评价9.3.1系统过渡系统过渡是由新信息系统代替旧系统的过程。此阶段一般要完成两项任务:一是整理并输入真实数据,二是完成系统的切换。1.数据的整理和输入数据整理是按照新建立的信息系统对数据的格式和内容的要求,统一进行数据的收集、分类和编码。2.系统切换新旧信息系统的切换一般可以采用以下三种方法进行:直接式、并行式、分段式。

1)直接式直接式是当确定新系统能正常运行后,在某一确定时间,停止旧系统的运行,立即启用新的信息系统。这种方式的优点是简单、节省费用和人力,但风险较大。因为新系统没有真正担负过实际工作,运行中难免出现预想不到的问题。因此,对重要系统不宜采用此种方法。这种方法仅适用于系统规模小、业务简单、数据不很重要的应用场合。2)并行式并行式是针对直接式存在的问题,采用并行切换方法,即使新旧信息系统同时运行一段时间,经过一段时间的考验,对比结果没有问题后,便可用新系统正式代替旧系统。并行时间一般为3~5个月。这种方法虽没有多大风险,但费用高、工作量大。3)分段式分段式是对上面两种方法的综合,它的特点是分阶段、分部分进行新旧替换,这样既避免了直接式的风险,又减轻了并行式费用和人力资源的浪费。除了确定系统的切换方式之外,还应该由各个部门联合组织人员,制定信息系统管理及操作制度(包括机房管理制度、技术档案管理制度、数据输入与维护制度、操作规程等),以便进行系统运行的日常管理及对系统运行情况进行记录。9.3.2系统移交当新系统完全取代了旧系统而投入正常运行后,就应该着手准备系统的移交工作,由开发方正式把信息系统的管理权移交给用户。除了移交信息系统之外,还需同时移交合同规定的信息系统开发的所有技术文档。9.3.3系统评价1.系统评价的目的在信息系统正式投入稳定运行之后,就可对所开发的信息系统从技术性能及达到的经济效益等方面做出总体评价,以检查信息系统是否达到了预期的目标,并指出系统的优点和不足,提出改进意见。最后据此写出评价报告,为系统的改进和扩充指出方向。2.系统评价的内容1)技术性能评价技术性能评价的主要内容有以下几方面:(1)系统的总体技术水平。主要包括系统的技术先进性、实用性,系统的开放性与集成程度等。(2)系统功能覆盖范围。主要包括对各个管理层次及各业务部门业务的支持程度,用户要求满意程度等。(3)信息资源开发与利用的范围与深度。主要包括是否通过了信息的集成及功能的集成是否实现了业务流程的优化,人、财、物等资源的合理使用,对市场、客户等信息的利用率等。(4)系统本身的质量。如系统的可使用性、正确性、适用性、可维护性、通用性、可靠性等。(5)系统的安全性与保密性。主要包括业务数据是否会被破坏或被修改,数据使用权限是否得到保障,防攻击、防侵入的能力等。(6)系统文档的完备性。2)系统效益评价系统效益评价可分为直接经济效益评价和间接经济效益评价。直接经济效益评价的内容包括系统的投资额,运行费用,系统新增效益,投资回收期等。间接经济效益评价的内容包括企业形象的改变,对员工素质提高所起的作用,管理水平的提高,业务重组及管理流程优化,资源的合理利用,提高决策成功率等。系统评价一般需要在系统稳定运行一个时期,例如三个月或半年后再进行。系统评价可结合系统验收进行。3.系统评价的指标对信息系统的评价属于多目标问题,难度较大。通常是对那些可以定量分析的给出定量的指标,对不可能定量评价的则给出定性的评价。具体的评价指标可分为下述三个方面。1)系统性能指标

温馨提示

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

评论

0/150

提交评论