软件测试基本理论和方法_第1页
软件测试基本理论和方法_第2页
软件测试基本理论和方法_第3页
软件测试基本理论和方法_第4页
软件测试基本理论和方法_第5页
已阅读5页,还剩111页未读 继续免费阅读

下载本文档

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

文档简介

1,CSIA软件测试工程师培训,软件测试基础理论与方法,2,引言,软件测试是保证软件质量的重要技术手段测试理论和测试方法测试过程及测试的管理测试工具,3,测试的原则,原则一:穷尽测试是不可能的原则二:测试工作具有创造性,但很困难原则三:测试旨在防止错误的发生原则四:测试是有风险的原则五:测试需要有计划性原则六:测试需要有独立性,4,软件测试技术基础,6.1、测试的目的6.2、测试的原则6.3、测试的层次结构6.4、测试阶段6.5、测试方法6.6、测试种类6.7、测试自动化6.8、小结,5,1、测试的目的,测试是通过运行程序来发现错误的过程测试可以说明软件存在错误,但不能说明它不存在错误目的:用相对少的测试尽可能多地找到程序中的缺陷,6,2、测试的原则,一个好的测试用例具有较高的发现过去未被发现过的错误的概率,而不应只表明程序运行正常自己不能测试自己编写的程序对期望结果的描述是每个测试用例的必要组成部分杜绝不能重现或匆忙的测试既要编写使用有效输入条件的测试用例,也要编写使用非法输入条件的测试用例深入细致地审查测试结果,7,2、测试的原则,如果一段程序中发现的缺陷数量增加,则意味着有更多未被发现的缺陷的可能性也在增加让最优秀的人员去完成测试保证软件可测试性是软件设计的一个重要目标不要为了测试方便而修改程序测试工作必须在任务建立之初就确定目标,8,3、测试的层次结构,类型,方法,阶段,举例:功能算法正向反向可用性边界,验收测试确认测试集成测试单元测试,白盒黑盒自顶向下自底向上模拟用户操作,9,4、测试阶段,单元测试组装测试确认测试验收测试,10,4.1、单元测试,单元测试的目的是在一个隔离环境中对独立的软件模块进行测试以发现其中的缺陷。,11,4.1、单元测试,12,4.2、集成测试,集成测试的目的是当模块组装后查找模块间接口的错误,13,4.3、确认测试,确认测试的目的是确定软件是否满足软件需求规格说明所提出的所有需求,14,4.4、验收测试,用户参与的确认测试,15,5、测试方法,黑盒测试方法白盒测试方法自顶向下方法自底向上方法模拟用户操作测试方法,16,5.1、黑盒测试方法,黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用。,17,6.5.2、白盒测试方法,白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。,18,6.5.3、自顶向下或自底向上方法,依据模块在模块层次中的位置,对模块组装并测试,属于增量组装测试方法。,19,6.5.4、模拟用户操作测试方法,着重对那些用户可能发现的错误进行测试及修改工作,20,6.6、测试类型,功能测试算法测试正向测试反向测试可使用性测试边界测试平台测试负载/强度测试,21,6.7、自动化测试,6.7.1、属性及优点6.7.2、主要分类6.7.3、实现类型6.7.4、注意的问题,22,6.7.1、属性及优点,速度。例如手工测试Windows计算器,假定平均每5秒钟执行一个测试案例,那么数千个案例需要数小时的时间。而自动化能够以成千上万倍的速度来执行。效率。测试工具减少了执行测试案例的时间,有更多的时间进行测试计划考虑新的测试用例。准确度和精确度。尝试执行百个测试用例之后,注意力就会分散,开始犯错误。测试工具每次执行同样的测试,并毫无差错地检查结果。坚持不懈。测试工具和自动化永远不会累倒或半途而废。,23,6.7.2、主要分类,回放类型自动测试工具代码分析器:复杂度等覆盖分析器内存分析器强度测试工具web测试工具其它测试用例管理、文档管理、bugreporting、配置管理,24,6.7.3、实现类型,宏录制和回放。最基本的测试自动化类型时录制第一次执行测试用例时的键盘和鼠标操作,然后在需要重新执行时回放可编程的宏编写回放系统遵守的简单指令完全可编程的自动测试工具提供编程语言,25,6.7.4、注意的问题,软件变更人眼和直觉是不可替代的验证难以实现容易过分依赖自动化不要花费太多时间使用达不到测试软件目的的测试工具和自动化编写宏、开发工具都属于开发工作,应该遵守要求程序员遵守的相同标准和规范某些工具是侵入式的,可能导致测试的软件不正常失败。,26,6.8、小结,测试的目的测试的原则测试的层次结构测试阶段测试方法测试种类测试自动化,27,软件测试理解,1软件测试活动2测试过程3测试方法4测试类型5测试策略6小结,28,1软件测试活动,测试是从大量的测试用例中选择有限的测试用例发现软件中的大部分缺陷的一种技术好的测试用例的4个特性:检测软件质量的有效性,是否能发现缺陷,或至少可能发现缺陷;可仿效的测试用例可以测试很多内容,因而减少测试用例的数量;经济性,测试用例的执行、分析和调试是否经济测试用例的可修改性,每次软件修改后对测试用例的维护成本,如何实现?,29,测试活动,计划,编制测试计划:标志测试条件(确定测试什么)和测试的优先级,设计,设计测试用例(确定怎么测试),开发,测试开发(设计脚本、数据等),执行,执行测试用例,将测试结果与期望结果进行比较,评估,30,测试活动1计划阶段,内容:人员、进度、资源。测试条件取决于被测试验证的项目或事件。测试条件是被测环境的描述。可以用多种方式描述:如简单的语言,表格项形式或类似于流图的图表形式;标识测试条件的活动最好与开发活动(即V模型左边的活动)并行开展,31,测试活动2设计阶段,内容:设计测试用例、预期结果测试用例(testcase)是按一定顺序执行的与测试目标(testobject,测试理由或目的)相关的一系列测试。测试用例设计将产生许多测试所包括的运行测试的有关信息(如环境要求,也称为先决条件)、输入值、期望结果。期望输出包括应输出或建立的内容,应修改或更新或应删除的内容。期望输出集可以是一个很大的集合。,32,测试活动,测试用例:POS1036先决条件:作为数据输入员注册到定单系统显示的主菜单数据库系统必须含有标准数据集合确保系统中没有其他活跃的新定单活动,33,测试活动3开发阶段,开发测试用例包括:准备测试脚本、测试输入、测试数据以及期望输出。测试脚本(testscript)是具有正规语法的数据和指令的集合,在测试执行自动工具使用中,通常以文件形式保存;必须先完成测试用例的先决条件(precondition),然后再执行测试。测试用例可能要求专门的硬件或软件,如网络环境或打印机等;期望输出可以组成文件形式用于自动工具。对于手动测试,期望输出仅仅只是简单地记录在手工测试过程或脚本中。对于自动测试,其期望输出比设置用于手工测试的期望输出复杂得多。在自动工具中要求每项内容都要拼写正确,而在手工测试中要求没这么严格。测试开发的任何工作可以提前进行(相对V模型左边的活动进行),以后可以节省时间。,34,测试活动4执行阶段,执行测试用例对于手动测试:测试者按事先准备好的手工过程进行测试,测试者输入数据、观察输出、记录发现的问题。对于自动测试:可能只需要启动测试工具,并告诉工具执行哪些测试用例;测试执行只能在软件开发完成后进行,即V模型右边的活动。,35,测试活动5评估阶段,将测试结果与期望输出进行比较应该对每次测试的实际输出进行分析研究,判断软件功能是否正确。验证可以是测试者的主观判断,也可以是将实际输出与期望输出进行严格准确的比较。信息比较,如可以在执行测试时进行显示屏幕上的信息,另一些输出比较,如修改数据库记录,只能在测试执行结束后进行。自动测试一般结合了信息比较的两种方法。,36,软件测试与软件工程模型,V模型介绍,扩展:左边的每一部分还包括评审,也是测试任务。,37,测试设计基于需求分析,缺陷预防:是指各种错误遗留到后续开发阶段之前,运用各种技术和过程来发现和避免这些错误。最有效的测试工作应该开始于需求;对于每一条需求,如果可以设计出一个过程来执行所测试的功能,若输出结果是可以预先知道的,并且能够通过编程或者人工方法加以验证,则称该需求是可测试的;测试人员需要彻底了解产品,只有这样他们才能设计出更出色和更全面的测试计划,测试设计和测试过程和测试用例。,38,测试人员及早介入,避免在项目生命周期中的后续阶段对产品的功能行为不理解了解应用程序的哪些方面对最终用户而言是最关键以及哪些元素的风险最大测试重点放在应用程序中最重要的部分,避免对不经常使用的部分过度测试而对重要的部分又测试不充分。,39,40,测试的生命周期,在软件开发生命周期中,软件是通过迭代来不断加以完善的。在这种环境中,对于每个作为测试目标的工作版本,测试的生命周期还都必须具有一种迭代方法。,41,测试的生命周期,42,测试活动的信息流,被测模块,设,软,系统,客,计,件,其他,户,信,需,元素,参,息,求,与,被测模块,被测模块,单元,测试,单元,测试,单元,测试,集成,测试,确认,测试,系统,测试,验收,测试,已经测,试过的,模块,已集,成的,软件,已确,认的,软件,可交,付的,软件,43,测试阶段的信息流,测试阶段的输入信息有两类:软件配置:这是测试的对象,包括需求说明书设计说明书被测的源程序等。测试配置:包括测试计划测试步骤测试用例(测试数据)具体实施测试的测试程序测试工具等,44,RUP中定义,测试的目的在于:Findinganddocumentingdefectsinsoftwarequality.Generallyadvisingaboutperceivedsoftwarequality.Provingthevalidityoftheassumptionsmadeindesignandrequirementspecificationsthroughconcretedemonstration.Validatingthesoftwareproductfunctionsasdesigned.Validatingthattherequirementshavebeenimplementedappropriately.,45,RUP,Activities活动,46,RUP-2001,Artifacts工件,47,2测试过程,2.1单元测试2.2集成测试2.3系统测试2.4验收测试,48,2.1单元测试,目的:分别完成每个单元的测试任务,以确保每个模块能正常工作。单元测试-RUP单元测试在迭代的早期实施,侧重于核实软件的最小可测试元素。单元测试通常应用于实施模型中的构件,核实是否已覆盖控制流和数据流,以及构件是否可以按照预期工作。这些期望值建立在构件参与执行用例的方式的基础上,参与方式可参见该用例的序列图。实施员在单元的开发期间执行单元测试。实施工作流程对单元测试作出了详细描述。,49,单元测试的考虑,算法和逻辑模块接口数据结构(全局和局部)边界条件独立的路径错误处理,50,单元测试的辅助模块,驱动程序:用于模拟主程序的运行桩模块:用于模拟子程序的运行,51,单元测试的过程,52,2.2集成测试,为什么进行集成测试?一个模块可能对另一个模块产生不利的影响将子功能合成时不一定产生所期望的主功能独立可接受的误差,在组装后可能会超过可接受的误差限度可能会发现单元测试中未发现的接口方面的错误在单元测试中无法发现时序问题(实时系统)在单元测试中无法发现资源竞争问题,集成测试的目的:在模块组装后查找模块间接口的错误,53,集成测试-RUP,执行集成测试是为了确保当把实施模型中的构件集成起来执行用例时,这些构件能够正常运行。测试对象是实施模型中的一个包或一组包。要集成的包通常来自于不同的开发组织。集成测试将揭示包接口规约中不够完全或错误的地方。,54,集成测试的方法,非增式测试:采用一步到位的方法来构造测试:对所有模块进行个别的单元测试后,按程序结构图将各模块联接起来,把联接后的程序当作一个整体进行测试。增式测试:把下一个要测试的模块同已经测试好的模块结合起来进行测试,一次增加测试的模块。,55,非增式测试,56,增式测试,增式测试把单元测试与集成测试结合起来进行,将模块逐步集成起来,逐步完成集成测试。实施方法:自顶向下结合自底向上结合,57,两种集成方法的比较,58,自顶向下增式测试,集成步骤:主控模块作为测试驱动,所有与主控模块直接相连的模块作为桩模块;根据集成的方式(深度或广度),每次用一个替换从属的桩模块;在每个模块被集成时,都必须已经进行了单元测试;进行回归测试以确定集成新模块后没有引入错误上述过程从第2步重复进行,直到整个系统结构被集成完成。,59,自顶向下增式测试,60,自底向上增式测试,工作程序:组装从最底层的模块开始,组合成一个构件,用以完成指定的软件子功能编制驱动程序,协调测试用例的输入与输出;测试集成后的构件按程序结构向上组装测试后的构件,同时除掉驱动程序,61,自底向上增式测试,62,两种集成测试方法的比较,63,讨论,在你的工作中采用了集成测试吗?如何做的?集成测试过程中最关键的问题是什么?,64,2.3系统测试,系统测试实际上是针对系统中各个组成部分进行的综合性检验。尽管每一个检验有着特定的目标,然而所有的检测工作都要验证系统中每个部分均已得到正确的集成,并能完成指定的功能。系统测试-RUP当将软件作为整体运行或实施明确定义的软件行为子集时,即可进行系统测试。这种情况下的目标是系统的整个实施模型。,65,认识系统测试,什么是系统测试为了发现缺陷并度量产品质量,按照系统的功能和性能需求进行的测试一般使用黑盒测试技术一般由独立的测试人员完成对于模块之间交互性比较强的软件,还会有单独的集成测试,用来发现模块接口之间的错误,66,认识系统测试,客户和用户Customerv.s.User都是利益相关者,但是终极关注的是客户客户是衣食父母,不是上帝尊重客户的需求与客户沟通,让他理解你的困难和方案,给他咨询客户是人,人就会犯错误,67,认识系统测试,系统测试的常见内容1、功能测试目标:对产品的功能进行测试,检验是否实现、是否正确实现方法:覆盖产品的功能工具:回归测试时候可以使用工具,68,认识系统测试,系统测试的常见内容2、性能测试目标:对产品的性能进行测试,检验是否达标、是否能够保持方法:覆盖系统的性能需求,一般和负载测试结合使用工具:在需要大访问量时候尤其需要使用工具,69,认识系统测试,系统测试的常见内容3、负载测试目标:在人为设置的高负载(大数据量、大访问量)的情况下,检查系统是否发生功能或者性能上的问题方法:人为生成大数据量,并利用工具模拟频繁并发访问工具:一般需要使用工具,70,认识系统测试,系统测试的常见内容4、压力测试目标:在人为设置的系统资源紧缺情况下,检查系统是否发生功能或者性能上的问题方法:人为减少可用的系统资源,包括:内存、硬盘、网络、CPU占用、数据库反应时间工具:一般需要使用工具,71,认识系统测试,系统测试的常见内容5、疲劳测试目标:在一段时间内(经验上一般是连续72小时)保持系统功能的频繁使用,检查系统是否发生功能或者性能上的问题方法:人为设置不同功能的连续重复操作工具:一般需要使用工具,72,认识系统测试,系统测试的常见内容6、易用性测试目标:检查系统界面和功能是否容易学习、使用方式是否规范一致,是否会误导用户或者使用模糊的信息一般与功能测试结合使用方法:可以采用用户操作、观察(录像)、反馈并评估的方式,73,认识系统测试,系统测试的常见内容7、安装测试目标:检查系统安装是否能够安装所有需要的文件/数据并进行必要的系统设置;检查系统安装是否会破坏其他文件或配置;检查系统安装是否可以中止并恢复现场;检查系统是否能够正确卸载并恢复现场;检查安装和卸载过程的用户提示和功能是否出现错误有时候将安装测试作为功能测试的一部分,74,认识系统测试,系统测试的常见内容8、配置测试目标:在不同的硬件配置下,在不同的操作系统和应用软件环境中,检查系统是否发生功能或者性能上的问题方法:一般需要建立测试实验室,IE4.0测试实验室建立花费了$200万,75,认识系统测试,系统测试的常见内容9、文档测试目标:检查系统的文档是否齐全,检查是否有多余文档或者死文档,检查文档内容是否正确/规范/一致,检查CI是否正确方法:一般由单独的一组测试人员实施,76,认识系统测试,系统测试的常见内容10、安全测试(包括病毒、加密、权限)目标检查系统是否有病毒检查系统是否正确加密检查系统在非授权的内部或外部用户访问或故意破坏时候是否出现错误,77,认识系统测试,系统测试的常见内容11、恢复测试目标:在人为使发生系统灾难(系统崩溃、硬件损坏、病毒入侵等)的情况下,检查系统是否能够恢复被破坏的环境和数据,78,认识系统测试,系统测试的常见内容12、回归测试目标:检查系统变更之后是否引入新的错误或者旧的错误重新出现,尤其是在每次Biuld之后和稳定期测试的时候工具:一般使用工具,一般依赖于测试用例库和缺陷报告库,79,认识系统测试,系统测试的常见内容13、健全测试目标:检查系统的功能和性能是否基本可以正常使用,来确定是否可以继续进行系统测试的其他内容方法:正常安装,并使用正常情况下的测试用例对主要功能进行测试;同时检查系统文档是否齐全,80,认识系统测试,系统测试的常见内容14、交付测试目标:关闭所有缺陷报告,确保系统达到预期的交付标准方法:一般需要结合回归测试,并谨慎处理新出现的Bug交付测试也称为稳定期测试,有时候与系统测试独立划分,81,认识系统测试,系统测试的常见内容15、演练测试目标:在交付给用户之前,利用相似的用户环境进行测试例如:奥运会MIS系统在2008年前用于其他比赛,82,认识系统测试,系统测试的常见内容16、背靠背测试目标:设置一组以上的测试团队,在互相不进行沟通的情况下独立进行相同的测试项目,用来评估测试团队的效果并发现更多的错误开始用于测试外包,现在也用于内部测试,83,认识系统测试,系统测试的常见内容17、度量测试目标:在系统中人为地放入错误(播种),并根据被发现的比例来确定系统中遗留的错误数量开始用于测试外包,现在也用于内部测试,84,认识系统测试,系统测试的常见内容18、比较测试目标:与竞争产品及本产品的旧版本测试同样的内容,来确定系统的优势和劣势严格地说,比较测试属于系统测评的内容BenchMarking是一种特殊的比较测试,85,认识系统测试,系统测试的常见内容实际上,以上18种测试内容并不是都要进行的,而是在制定测试策略和测试计划的时候有不同的侧重点,这与测试目标、测试资源、软件系统特点和业务环境有关。,86,2.4验收测试,验收测试是检验软件产品质量的最后一道工序。验收测试的目的是确保软件准备就绪,并且可以供最终用户用于执行软件的既定功能和任务。验收测试主要在于它突出了客户的作用,这是与前面讨论的各种测试活动不同之处。用户在现场或直接参与测试。验收测试可以重复确认测试中所使用的全部测试或部分测试,或采用完全由用户自己开发的测试。,87,验收测试,正式验收非正式验收或Alpha测试Beta测试选择的策略通常建立在合同需求、组织和公司标准以及应用领域的基础上。某些验收测试(如工厂验收而不是现场验收)是部署软件之前的最后一个测试操作。此时采用后两种测试方法,88,验收测试的范围,明确验收项目,规定验收测试通过的标准;确定测试方法;决定验收测试的组织机构和可供利用的资源;选定测试结果分析方法;制定验收测试计划并进行评审;设计验收测试所用测试用例;审查验收测试准备工作;执行验收测试;分析测试结果;阐明验收测试结论,决定通过验收或是拒绝,89,确认测试,确认测试是检验所开发的软件是否能按顾客提出的要求运行。若能达到这一要求,则认为开发的软件是合格的,确认测试也称为合格性测试,90,测试和测试,通常由用户或其他人(非开发人员和测试人员)来完成,测试:在开发即将完成时对应用进行的测试,此时仍然允许对设计作微小的变动;测试:在开发基本完成时进行,于正式发布之前寻找程序中的错误,91,3测试方法,静态方法和动态方法黑盒测试和白盒测试回归测试方法自顶向下方法和自底向上方法模拟用户操作测试方法自动方法和手工方法,92,静态方法和动态方法,静态方法的主要特征是在用计算机测试源程序时,计算机并不真正运行被测试的程序,只对被测程序进行特性分析。因此,静态方法常称为“分析”,静态分析是对被测程序进行特性分析的一些方法的总称。动态方法的主要特征是计算机必须真正运行被测试的程序,通过输入测试用例,对其运行情况(输入/输出的对应关系)进行分析。,93,黑盒测试,黑盒测试(BlackboxTesting)又称功能测试、数据驱动测试或基于规格说明的测试,是一种从用户观点出发的测试。被测程序被当作一个黑盒,不考虑程序内部结构和内部特性,测试者只知道该程序输入和输出之间的关系或程序的功能,依靠能够反映这一关系和程序功能的需求规格说明书考虑确定测试用例和推断测试结果的正确性。软件的黑盒测试被用来证实软件功能的正确性和可操作性。,94,白盒测试,白盒测试(WhiteboxTesting)又称结构测试、逻辑驱动测试或基于程序的测试。它依赖于对程序细节的严密检验,针对特定条件和/与循环集设计测试用例,对软件的逻辑路经进行测试。在程序的不同点检验“程序的状态”以判定其实际情况是否和预期的状态相一致。软件的白盒测试用来分析程序的内部结构,95,白盒测试,白盒测试要求对某些程序的结构特性做到一定程度的覆盖,或者说是“基于覆盖的测试”。最为常见的程序结构覆盖有:语句覆盖:它要求被测程序的每一可执行语句在测试中尽可能都检验过,这是最弱的逻辑覆盖准则;分支覆盖或判定覆盖:要求程序中所有判定的分支尽可能得到检验;条件覆盖:当判定式中含有多个条件时,要求每个条件的取值均得到检验;判定条件覆盖:同时考虑条件的组合值及判定结果的检验;路径覆盖:只考虑对程序路径的全面检验。取得测试覆盖的方法程序插装,96,黑盒测试与白盒测试的比较,97,回归测试,目标:修改的或增加的部分是正确的没有引起其他部分产生错误应用:增量开发版本控制软件维护,98,回归测试,方法举例:全部再测试(RetestAll)再测试风险用例(RetestRiskyUseCase)按纲要再测试(RetestbyProfile)再测试修改的段(RetestChangedSegments)防火墙内再测试(RetestWithinFirewall),99,模拟用户操作测试方法,基于对用户如何使用被测试软件的了解来开发测试的方法。经验告诉我们,复杂的软件产品有许多错误,但用户一般只能找出这些错误中很少的一部分。为给用户带来最大利益,要着重对那些用户可能发现的错误进行测试和修改工作。,100,4测试类型,(质量维度1)可靠性测试完整性测试:侧重于评估测试对象的强壮性(防止失败的能力),语言、语法的技术兼容性以及资源利用率的测试。该测试针对不同的测试对象实施和执行,包括单元和已集成单元。结构测试:侧重于评估测试目标是否符合其设计和构造的测试。通常对基于Web的应用程序执行该测试,以确保所有链接都已连接、显示正确的内容以及没有孤立的内容。,101,测试类型,(质量维度2)功能测试配置测试:侧重于确保测试对象在不同的硬件和/或软件配置上按预期运行的测试。该测试还可以作为系统性能测试来实施。功能测试:侧重于核实测试对象按计划运行,提供需求的服务、方法或用例的测试。该测试针对不同的测试对象实施和执行,包括单元、已集成单元、应用程序和系统。安装测试:侧重于确保测试对象在不同的硬件和/或软件配置上,以及在不同的条件下(磁盘空间不足或电源中断)按预期安装的测试。该测试针对不同的应用程序和系统实施和执行。安全测试:侧重于确保只有预期的主角才可以访问测试对象、数据(或系统)的测试。该测试针对多种测试对象实施和执行。容量测试:侧重于核实测试对象对于大量数据(输入和输出或驻留在数据库内)的处理能力的测试。容量测试包括多种测试策略,如创建返回整个数据库内容的查询;或者对查询设置很多限制,以至不返回数据;或者返回每个字段中最大数据量的数据条目。,102,测试类型,(质量维度3)性能测试基准测试:一种性能测试,该测试将比较(新的或未知的)测试对象与已知的参照负载和系统的性能。竞争测试:侧重于核实测试对象对于多个主角对相同资源(数据记录、内存等)的请求的处理是否可以接受的测试。负载测试:一种性能测试,用于在测试的系统保持不变的情况下,核实和评估系统在不同负载下操作极限的可接受性。评测包括负载和响应时间的特征。如果系统结合了分布式

温馨提示

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

评论

0/150

提交评论