功能自动化测试方案-V1.1_第1页
功能自动化测试方案-V1.1_第2页
功能自动化测试方案-V1.1_第3页
功能自动化测试方案-V1.1_第4页
功能自动化测试方案-V1.1_第5页
已阅读5页,还剩19页未读 继续免费阅读

下载本文档

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

文档简介

PAGE质量管理体系建设银行质量管理体系中国建设银行功能自动化测试实施方案建议书(讨论稿)中国建设银行信息技术管理部2006年12月 第23页目录TOC\o"1-5"\h\z\u1 前言 31.1 文档目的 31.2 名词术语 32 功能自动化测试实施原则 52.1 实施原则 52.2 实施功能自动化测试的优缺点 53 实施范围和目标 73.1 实施范围 73.2 实施目标 74 技术方案实施内容 84.1 使用QTP测试的阶段 84.1.1 创建测试或组件 84.1.2 运行测试或组件 84.1.3 分析结果 84.2 使用QTP测试的具体步骤 94.2.1 测试分析准备 94.2.2 录制测试脚本 94.2.3 加强测试脚本 94.2.4 调试脚本 104.2.5 执行测试脚本 104.2.6 分析测试结果 104.2.7 汇报测试缺陷 104.3 准入检查 104.4 测试数据环境与脚本管理 114.5 功能自动化测试复用规范 114.6 功能自动化测试系统部署 134.7 组织管理要求 145 功能自动化测试方法比较 165.1 录制回放技术 165.2 脚本技术 175.3 数据驱动技术 185.4 各种自动测试技术比较 206 实施管理建议 216.1 实施策略建议 216.2 人员组织结构 226.3 实施计划 236.4 交付物 23前言文档目的功能自动化测试方案是为中国建设银行北京开发中心功能测试使用自动化工具,实现以自动化测试为主的目标而编写的技术和实施方案。文档的主要目的是提供自动化测试的技术方案、实施内容、实施步骤,以及关键的技术实现手段等。本文的预期读者为建行测试中心相关人员。名词术语QTP:Mercury公司的功能自动测试工具,是一种企业级的用于检验应用程序是否如期运行的功能性测试工具。通过自动捕获,检测,和重复用户交互的操作,QTP能够辨认缺陷并且确保那些跨越多个应用程序和数据库的业务流程在初次发布就能避免出现故障,并且保持长期可靠运行。MQC:Mercury公司的测试管理工具,用于在广泛的IT系统和应用环境下执行质量保证。它包含一套基于角色的集成应用程序和最佳实践,以及开放式、可伸缩、可扩展的基础架构。QualityCenter设计用于对关键质量活动进行优化和自动化,包括要求、测试和故障管理、功能测试以及业务流程测试。功能测试:功能测试又称正确性测试,它检查软件的功能是否符合规格说明。由于正确性是软件最重要的质量因素,所以其测试也最重要。自动化测试:使用商业提供的自动化测试工具或者自己开发的工具对目标系统进行测试。机器自动执行的测试,替代人完成重复性劳动,但不能完全取代人。自动化测试需要用到测试工具,测试工程师的参与,自动化测试技术可应用于所有的测试阶段业务组件:表示应用程序中单任务的步骤集合。业务组件(也称为组件)在MercuryQualityCenter中由业务流程测试组合为特定的场景以建立业务流程测试。Action:在QTP中Action是一个可以被重复使用的最小单位,当建立一个全新的测试脚本时,测试脚本中只有一个Action名为Action1,可以将整个测试脚本切割成多个Actions,让测试脚本更为模块化且更容易被重复使用。CheckPoint检查点:用来验证脚本执行结果是否达到预期。可以在录制的过程中建立检查点,也可以在录制完成之后再建立检查点。测试对象模型:是一大组对象类型或类,QTP用这些对象类型或类来表示应用程序中的对象。每个测试对象类都有一个可以唯一标识属于该类的对象的属性列表,以及一组QTP可以对其进行录制的方法。测试对象:是QTP在测试或组件中创建的用于表示应用程序中的实际对象的对象。QTP存储有关该对象的信息,这些信息有助于它在运行会话期间标识和检查该对象。运行时对象:是网站或应用程序中的实际对象,在运行会话期间执行针对该对象的方法。功能自动化测试实施原则实施原则功能自动化测试过程中工具不可能完成所有的工作,工具仍然是测试过程中的辅助手段。对于工具主要是解决测试过程中的重复性的工作任务。另外实施自动化的测试,对被测系统也有更高的要求,总结功能自动化测试的实施原则如下:使用自动化工具测试,要求被测系统开发比较稳定,较少发生功能的变更;在自动化测试脚本录制前,被测系统的界面相对稳定;功能测试自动化要求测试数据环境中的测试数据相对充裕,满足多次重复回归测试的要求;要求被测系统的版本运行比较稳定,较少发生测试中止的情况;分期分步骤实施,优先选择产品功能比较稳定的系统进行;完善的、可复用的数据参数、脚本库是一个长期的积累过程。实施功能自动化测试的优缺点功能的自动化测试与手工测试虽然有很多局限,但是同样有其优势,随着自动化测试技术和工具的发展,对于比较稳定的产品的功能测试中,自动化测试占有越来越重要的地位。使用QTP可以加快整个测试的过程,在产品的版本发布之后,可以重复使用测试脚本进行测试,具体来说:自动化测试的优点:提高测试效率,降低测试成本;重复性强的手工劳动独立用自动化实现;快速的回归测试,提高新版本发布的速度和质量;避免人工测试容易犯的错误,如:错误测试,漏测试,多测试等;很容易就实现并发性测试;测试可重用,采用脚本和数据可以很容易实现重用。自动化测试的缺点:规范的测试管理,测试需求,测试用例;不能创造性发现测试脚本没有设计的缺陷;高质量的测试用例;高素质的自动化测试工程师;对测试环境要求比较严格;测试需求变化可能引起大量的测试用例,自动测试脚本的修改、维护。实施范围和目标实施范围工具范围:目前考虑QTP、MQC、TAR、配置管理工具、Excel等工具的使用和集成;持续集成工具暂时先不考虑;系统范围:定位在建行测试中心基础测试环境中的交易类系统;测试阶段的范围:局限在SIT后期、以及上线后的功能回归测试,目前暂不包括LT、内部测试中的功能测试部分。实施目标功能自动化测试系统应该能完成SIT、以及上线后功能的回归测试;方案目标对有界面和无界面的交易测试都能完成,有界面的交易支持如下方式:支持字符终端界面;支持B/S的Web界面;支持C/S的Windows应用程序界面;功能自动化测试方案对目前建行存在的大部分应用系统都可以进行测试;实现自动化脚本录制、自动化脚本执行、自动化缺陷报告和管理。总体实施策略首先从目前建行的系统中选择适合自动化测试的项目和系统;其次确定实施功能自动化测试的阶段和时机;第三从适合的项目中选择适合自动化测试实施的功能和交易。具体实施策略参见第6节的实施管理建议。技术方案实施内容使用QTP测试的阶段使用QTP测试包括三个主要阶段:创建测试或组件创建阶段可以通过在应用程序或网站上录制会话,或者建立对象库并使用关键字驱动功能向关键字视图中手动添加步骤来创建测试或组件。然后,可以使用特殊的测试选项和/或编程语句来修改这些测试或组件。运行测试或组件创建测试或组件后,测试工程师可以运行这些测试或组件。运行测试或组件检查被测系统。运行测试或者组件对录制和编写的脚本进行调试。分析结果运行测试或组件之后,就可以查看测试执行的结果。在“结果”窗口中查看结果。报告在运行会话过程中检测到的缺陷。使用QTP测试的具体步骤测试分析准备在测试前需要先确认被测应用程序是否符合自动化测试的需要,是否满足自动化测试工具的要求。确认测试的范围和测试目标,比如要测试哪些功能、以及测试的时机等。在准备阶段要根据被测系统的业务需要分析被测系统的功能,整理出测试需求和测试数据需求。熟悉被测系统为后期指定测试集做准备。配置QTP工具的设置,为脚本录制做准备。录制测试脚本启动QTP工具的录制功能,手工操作被测系统的应用程序,QTP将自动录制人工的操作过程,并将操作的步骤显示在QTP工具中。对于工具不能录制或者不能识别的界面对象需要手工识别和添加。加强测试脚本在测试脚本中加入检查点,检查点可以是标准检查点、对象检查点、文本检查点、数据库检查点等,以验证应用程序的功能是否正确;将录制的脚本中的固定值(HardCode)以参数取代,使得测试脚本跟测试数据结合;使用逻辑或者条件判断,增加脚本的逻辑以实现对复杂的功能的测试。调试脚本对修改增强完成的脚本进行调试,修改脚本中的逻辑错误,确保测试脚本能够正常顺利执行。对于由于被测系统的功能需求发生变化后,测试脚本需要维护和修改,然后重新进行调试,以保证测试脚本的有效性。执行测试脚本调试完成的测试脚本,将在被测系统的版本上执行测试,检查被测系统的功能是否满足需求。执行脚本一般将脚本导入MQC中管理和定义测试案例执行集,由MQC来调度执行测试脚本。分析测试结果分析测试执行的结果,找出问题所在。如果是刚开始实施自动化测试,分析结果还可以帮助分析和定位测试脚本的正确性。以便提高测试脚本的可靠性。汇报测试缺陷通常QTP工具与MQC工具结合使用,这样QTP发现的缺陷可以自动提交到MQC中对缺陷进行管理和跟踪。准入检查准入检查机制是测试管理中的重要的环节,同时对于实现自动化测试方案中,更是一个重要的机制。准入检查对被测系统的版本、系统功能开发的稳定性等都能够有效验证,保证了自动化测试的顺利执行,同时也减少了自动化测试脚本的维护工作量。准入检查的内容和方式:被测版本静态检查:通过静态检查被测版本的《版本发布单》、版本的文件、版本的部署安装是否正确。被测系统版本验证:通过MQC运行覆盖主要业务功能的脚本案例执行的成功率判断被测系统能否进入自动化测试。测试数据环境与脚本管理QTP可以将测试数据参数化,数据参数与测试脚本相对应,在测试脚本中可以调用这些数据参数,实现同一个脚本可以针对不同的数据执行多遍。可以根据参数的设置实现测试业务流程的多个分支。测试数据的参数化有四种基本方法:使用QTP的DataTable,直接在QTP中将测试数据录入参数表中;使用QTP的正则表达式,根据测试数据的需求,使用正则表达式可以简化DataTable中的重复、序列以及匹配数据;使用外部文件:通过Excel导入QTP中,或者脚本直接访问外部文件的方式得到数据,可以方便实现脚本之间的数据共享;使用外部关系数据库,QTP脚本可以直接访问其他的数据库,从数据库中取测试数据。测试数据与脚本的关系:把自动测试脚本运行所用到的数据以参数取代,脚本运行时从参数表取数据;将数据与脚本分离,便于对数据和脚本的维护管理,便于更新数据以适应新的测试;QTP脚本中的取值参数化,增强脚本的复用程度;环境变量参数化,测试、操作参数的值,应用程序随机值。测试脚本参数化的实现步骤:定义数据表参数;在数据表中建立数据参数值;修改受参数化影响的测试步骤的脚本;运行脚本,调试建立的参数和修改的脚本。功能自动化测试复用规范使用自动化测试工具进行系统功能的自动化测试的一个重要的目的之一就是减少成本,提高效率。因此对测试过程中的成果的复用就是一个重要的需要考虑的内容,幸运的是,目前的很多自动化测试工具都提供了类似复用的功能。针对QTP来说,工具本身提供了对脚本Action的复用、检查点的复用、参数数据的复用以及脚本模板的定制功能。Action的复用:对于需要重复执行的步骤、一些常用的操作,以及一些通用性的操作,比如登录、退出等。一般都录制为单独的Action,存为单独的脚本文件。在需要的地方调用该Action。或者对于已经录制好的脚本,可以使用脚本分拆功能将复用的脚本分拆出来。Action的复用是先录制用于复用的Action脚本,然后对该脚本设置为ReuseableAction,这样该Action可以为其他脚本调用。QTP对Action的调用方式为:复制Action和调用已有的Action两种方式,可以根据实际情况选择。脚本的复用可以减少脚本库中脚本的数量,增强案例库的可维护性。参数数据的复用:QTP的参数化主要有两种方式,一是Global:控制整个Action的运行次数;另一种是CurrentAction的方式,对于一个脚本中有多个Action的情况下,用于控制单一的Action的循环次数。对于参数数据是执行自动化测试的前提,参数数据一般是可以在不同的系统版本的测试或者回归测试中复用率比较高。检查点的复用:每个脚本都需要设定检查点,但有些脚本的检查点可能相同,这时重复设定检查点就会使工作没有实际意义,这时可以设立可重用检查点来解决这个问题。具体设置步骤为:录制脚本,不设立检查点;录制可重用检查点,将QTP录制和运行设置设为录制当前页,开始录制,不录制步骤,直接在录制过程中添加检查点,将这个只有检查点的Action设为可重用Action(ReusableAction);调用可重用检查点,在第一步录制好的脚本中调用这个可重用检查点,首先选中需要添加检查点的步骤,然后选择调用已有的Action。Action模板定制:对于需要在每个Action脚本中包含的信息,比如脚本文件的头注释信息等,可以应用Action模板的方式来规范脚本开发的规范化,也为脚本维护和修改提供了方便。具体操作步骤为:新建一个文本,输入一些新建Action时经常包含的信息,然后保存为ActionTemplate.MST文件;复制该文件到QTP/dat目录下。这样每次新建action都会包含固定的信息。环境部署功能自动化测试环境包括:自动化工具、缺陷管理工具、测试案例管理工具、持续集成工具的协同环境。在该方案中建议的自动化测试工具及其主要功能有:工具名称功能说明QTP测试脚本录制、修改、调试、运行;脚本的检查点、参数设置等。MQC测试脚本的管理、测试集的建立;业务测试流程的执行建立;测试执行、缺陷报告管理、测试分析报告生成。TARTAR主要是结合QTP和QC工作,用于字符终端的功能测试;它是连接QTP和字符终端的测试引擎,为QTP提供“虚拟设备”,方便自动输入。测试数据库为功能自动化测试提供可以复用的测试数据;还可以将测试过程中可以用于复用的数据导入测试数据库中管理维护。测试案例库可以提供一些可以复用的测试案例脚本;还可以对测试过程中可以抽象为公用的脚本统一管理和维护。配置管理库管理测试过程中的脚本的版本、数据的版本等。Excel可以用于准备测试数据,可以从Excel导入QTP的DataTable中,也可以在QTP脚本中直接访问Excel中的数据。QTAddinforMQCQTP与MQC之间的插件,需要单独安装组织管理要求在自动化测试实施过程中,需要相关的角色和人员,不同的角色负责相应的职责,具体需要的人员角色如下:测试经理:制定测试计划;协调各个小组工作、协调行方资源;跟踪测试进度;协商解决测试中的遇到的问题。业务测试工程师:为自动化测试提供业务指导,数据准备。测试分析工程师:搭建测试环境,数据准备;定义脚本的框架,调试脚本框架;分析测试结果,优化测试脚本,配合系统优化。测试脚本开发工程师:根据框架生成测试脚本,数据参数化,添加检查点,执行测试,记录测试结果。开发人员:系统优化,测试过程中问题定位。功能自动化测试方法比较自动化测试技术的发展经历了简单的录制回放、脚本测试和数据测试的阶段,同时也代表了自动化测试技术方法。下面对比这三种自动化测试的技术方法,比较其优缺点。录制回放技术建行测试过程分为测试计划、测试需求分析、测试设计和案例编写、测试执行、测试分析等几个阶段,测试执行和测试问题报告是属于机械的、多次重复的活动,大概要占测试总工作量的80%左右,最适合被自动化,也是首先应该被自动化的。测试案例编写活动也有部分工作可以被自动化,如自动产生脚本框架等。测试执行活动又分为输入数据、执行测试、验证测试数据三个部分,其中工作量最大、实现起来最容易的就是输入数据和执行测试过程的自动化,最初采取的方法就是由计算机记录手工操作的过程和数据,再次执行测试时,根据上次记录内容回放即可,就不需要手工输入了,这就是录制/回放技术,后来,为了实现验证测试数据的自动化,在录制过程后,进行了增强工作,可在脚本中加入同步、检查点,并对部分数据进行参数化,实现初步的数据驱动。使用这种技术,其优点如下:使用简单,不需要深入的工作或计划,可很快启动手工录制工作,可以快速开始自动化,在短时间开发出大量简单的测试,启动成本低使用者不需要了解编程技术(假设不需要修改脚本)对实际执行的操作可以跟踪审计但是,绝大部分采用这种技术进行自动化回归测试的组织都失败了,失败的一个共性的原因是因为这种技术虽然初期启动成本低,但是随着测试过程的进行,后期维护成本非常高,使得不可能使用这种技术构建长期的自动测试系统,具体来说,这种技术存在以下问题:产生自动测试的过程繁琐,效率低:产生可行的自动测试的时间比手工测试长2~10倍一切依赖于录制过程中捕获的内容,故只能测试已经能够正常执行的功能存在录制噪声,产生的脚本是非结构化的,维护工作量巨大脚本、数据和验证条件是捆绑在一起的,任何一个修改,就必须重新录制或者修改脚本易受软件改变的影响,软件改变后必须重新录制脚本和验证条件如果回放时发生了录制脚本时没有发生的事情,将引起整个测试失败正因为以上原因,录制-增强-回放技术只使用于少量特殊情况,如培训演示、只使用一次的测试脚本,界面和操作不变的测试等,对于长期、大量的自动回归测试来说,这种方法是不可行的。脚本技术既然录制回放技术维护工作量巨大,无法使用这种技术构建长期的、大量测试的测试系统,那么如何改进自动回归测试系统的可维护性呢?人们发现,自动回归测试系统本身也是一个软件系统,其基本工作元素就是测试脚本,测试脚本也是一种软件程序代码,也存在各种程序错误,改进自动回归测试系统的可维护性,就是要改善自动测试脚本的可维护性,既然自动回归测试脚本是软件程序,那么就可以使用软件开发的技术来改进自动回归测试脚本的可维护性,这就是结构化的编程方法(当时还没有出现面向对象的技术)。这种结构化的脚本技术又叫功能分解技术,是一种基于任务的技术,其工作原理是根据被测系统需要完成的任务和功能,对这些功能和任务进行分解,采用结构化编程技术完成实现这些功能的脚本,不同测试中执行重复的任务时,使用同一个脚本,当重复任务发生改变时,也只需要修改一个脚本,对该脚本来说,数据与脚本是分离的,可以把数据作为脚本的参数,也可以把需要的输入数据和验证数据放到指定的文件中,由脚本读取。这种技术的特点是发展了“结构良好的、有文档的、健壮的、可维护的”测试能力,测试项目成为工程项目,其关键特征是部分测试脚本已经开始具有可复用性。另外,由于测试脚本包括错误捕获和恢复逻辑,比录制回放技术具有更高的可靠性,可以预知可能发生的错误和意外事件,通过编程进行处理,使自动回归测试能顺利进行。总结起来,这种技术优缺点如下:优点:可维护性较强采用模块化设计,如果业务功能改变,只需要改变1、2个脚本,维护开销低于录制回放技术复杂的测试用例可以通过在一个主脚本中调用业务功能脚本实现对于需要重复执行的测试任务,只需要使用一个脚本,删除了明显的重复,通过把不同的输入/验证数据作为参数,或者放到文件中,使数据与脚本分开,脚本可以被不同用例使用可靠性不存在录制噪声,脚本经过测试后,可靠性比较高意外事件(如弹出菜单、对话框等)可以预先考虑并通过编程解决这种技术虽然维护成本比录制回放技术低,但是还存在一些问题,主要缺点如下:每个功能都需要一个特定的测试脚本,而且大量脚本需要手工编写重复使用的脚本(共享脚本)通常只占被测软件很小的一部分脚本数量增多,增加了更多的文档,管理难度加大数据驱动技术使用脚本技术后,还存在一些的问题,其一,由于脚本技术是一种基于任务的技术,与应用系统的功能是紧密相关的,通常不同的应用系统之间的差异比较大,如一个银行的应用系统和一个税务的应用系统,他们之间可复用的脚本很少。二是由于采用这种技术,大量脚本还是与数据捆绑在一起的,如果数据发生变化,也需要具有编程经验的人员修改脚本,并调试脚本,成本比较高。如何解决这些问题呢?很显然,需要进一步提高共享脚本的数量。通过进一步思考,人们发现任何自动测试的终极目标都是自动完成一套与测试需求相对应的有计划的测试,可以由测试计划驱动测试过程,测试工作的中心是测试数据,而不是测试脚本,测试脚本只是为了传递测试数据,应把测试脚本和测试数据分开,由测试数据来驱动自动回归测试过程,这就是所谓的数据驱动测试或关键字驱动测试,也叫基于动作(Action)的测试或ActionWord方法,与前面说到的数据驱动不同,这里说的数据驱动测试不只是简单把外部数据输入到AUT(ApplicationUnderTest,被测系统)中,数据驱动测试是一种数据被包含在输入数据文件中,并且数据控制自动化测试脚本执行的流程和动作的测试,只有这样,才能实现在不同应用间的复用。这种测试方法要求我们分开测试数据和测试脚本,测试脚本是可以复用的,因此也要求测试脚本是参数化的。具体来说,采用这种技术就是在测试数据中指定测试执行的步骤,以及每个步骤执行时操作的对象、动作和数据,测试脚本的作用就是读入数据,并根据数据的要求执行相应的动作,而面向对象技术的出现,也促进了该技术的发展。另外,由于自动测试脚本本身也是一种软件,也存在逻辑错误和其他各种缺陷,也需要维护,因此,在自动回归测试过程中,除了要维护被测系统相关的代码、数据、文档外,还需要维护自动测试系统本身的脚本、数据和文档,维护成本非常高,因此可以说,创建结构化的、基于组件的测试脚本并使测试脚本与其执行的数据相分离是自动化测试成功的唯一途径。这种技术有多种实现方法,通常都会需要一个框架或引擎,用它来解析输入数据中的动作指令,执行指令要求的动作,而此框架和引擎的好坏,会直接影响自动回归测试系统能否成功。这种方法优缺点分析如下:优点:可维护性使用输入文件的数据控制自动化测试的执行流程和动作在特定框架下,可以非常容易地产生“健壮的”脚本,甚至自动产生数据与脚本分开,数据维护非常简便,输入数据文件格式简单,维护方便,调整数据不需要修改脚本可以借助占位符(变量)允许动态数据输入可靠性不存在录制噪声,基于框架的脚本开发更容易,更健壮意外事件(如弹出菜单、对话框等)可以预先考虑并通过编程解决可复用性:不是为一个应用开发脚本,脚本是封装的,可以在不同应用间复用降低人员要求:只需要一个工具专家,业务人员不需要了解测试工具缺点:需要手工维护大量的表格文件或数据文件,并需要与测试用例、测试脚本保持同步各种自动测试技术比较应该说,这三种技术是对技术实现方法的一种分类,在实际实施自动回归测试系统时,不一定限制在某一种实现技术上,也有可能在一个具体的实施项目中会用到所有三种技术。另外,这三种技术的实现具体细节会根据实际应用环境、实施方法的不同而不同,尤其是脚本技术和数据驱动技术,不同实现方法对自动回归测试系统的影响很大,下表给出了一般性的评价,仅供参考。特性录制回放脚本技术数据驱动技术可维护性低中高可靠性低高高效率低中高可复用性低中高健壮性低高高可移植性低低高易用性高低高实施管理建议实施策略建议考虑到建行系统的特点和自动化测试的适用性,对建行测试中心功能自动化测试实施策略有如下建议:分期实施:实施分为两个阶段,先选择一、两个试点项目实施,试点成熟后再推广到其他的项目中;先易后难:选择的实施对象尽量是非核心的系统或对建行目前

温馨提示

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

评论

0/150

提交评论