您的位置:首页 > PPT课件 > 大学437.com必赢 > 关于软件质量保证ppt

关于软件质量保证ppt下载

素材编号:
210659
素材授权:
免费下载
素材格式:
ZIP/RAR
素材上传:
weishenhe
上传时间:
2017-12-21
素材大?。?/dt>
401.50 MB
素材类别:
大学437.com必赢
网友评分:

437.com必赢 www.tornecasals.com 素材预览

关于软件质量保证ppt

关于软件质量保证ppt免费下载是由PPT宝藏(437.com必赢 www.tornecasals.com)会员weishenhe上传推荐的大学437.com必赢, 更新时间为2017-12-21,素材编号210659。

这是一个关于关于软件质量保证ppt,主要介绍软件质量保证、背景问题、软件质量保证的要素、软件质量保证的要素?;队慊飨略毓赜谌砑柿勘Vpt哦。仅仅嘴角上说“软件质量重要”是不够的。必须(1)明确给出你所说的“软件质量”的涵义;(2)提出一组活动,这些活动将有助于保证每个软件工程工作产品表现出高质量;(3)对每个软件项目实施质量控制和质量保证活动;(4)运用度量技术来制定软件过程改进策略,进而提高最终产品的质量。

软件工程 第十三章 软件质量保证软件质量保证仅仅嘴角上说“软件质量重要”是不够的。必须(1)明确给出你所说的“软件质量”的涵义;(2)提出一组活动,这些活动将有助于保证每个软件工程工作产品表现出高质量;(3)对每个软件项目实施质量控制和质量保证活动;(4)运用度量技术来制定软件过程改进策略,进而提高最终产品的质量。如果软件团队在每个软件工程活动中都强调质量,则会减少返工量,进而降低成本,更重要的是可以缩短面市时间。软件质量保证在软件质量保证活动启动前,必须按照多种不同的抽象层次来定义“软件质量”。理解了质量的涵义之后,软件团队必须确定一组SQA活动来过滤掉工作产品中的错误,以免这些错误再继续传播下去。为了制定软件团队的SQA策略,需要建立“软件质量保证计划”。在建模、编码阶段,主要的SQA工作产品是技术评审的输出;在测试阶段,主要的SQA工作产品是制定的测试计划和测试规程。也可能产生其他与过程相关的工作产品。软件质量保证 [Cro79]质量管理的问题不在于人们不知道什么是质量,而在于人们自认为知道什么是质量…… 每个人都需要质量,每个人都觉得自己理解它,每个人都认为只要顺其自然就可以。当然,大多数人都认为这一领域的问题都是由他人引起的。[Cro79] 有些软件开发者仍然相信软件质量是在编码完成之后才应该开始担心的事情。这是完全错误的!软件质量保证是适用于整个软件过程的一种普适性活动。软件质量保证软件质量保证(SQA)包括:(1)SQA过程,(2)具体的质量保证和质量控制任务(包括技术评审和多层次测试策略);(3)有效的软件工程实践(方法和工具);(4)对所有软件工作产品及其变更的控制;(5)保证符合软件开发标准的规程;(6)测量和报告机制。本章侧重于管理问题和特定的过程活动,使软件组织确保“在恰当的时间以正确的方式做正确的事情”的具体活动。背景问题在20世纪以前,质量控制只由生产产品的工匠承担。随着时间推移,大量生产技术逐渐普及,质量控制由生产者之外的其他人承担。第一个正式的质量保证和质量控制方案于1916年由贝尔实验室提出,此后迅速风靡整个制造行业。在20世纪40年代,出现了更多正式的质量控制方法,这些方法都将测量和持续的过程改进作为质量管理的关键成分。背景问题软件开发质量保证的历史同步于硬件制造质量的历史。在计算机发展的早期,质量保证只由程序员承担。软件质量保证的标准是20世纪70年代首先在军方的软件开发合同中出现的,此后迅速传遍整个商业界的软件开发中。软件质量保证就是为了保证软件高质量而必需的“有计划的、系统化的行动模式”。对软件来说,各个参与者都对软件质量负有责任——包括软件工程师、项目管理者、客户、销售人员和SQA小组成员。软件质量保证的要素软件质量保证涵盖了广泛的内容和活动,这些内容和活动侧重于软件质量管理,可归纳为:标准:IEEE、ISO及其他标准化组织制定了一系列广泛的软件工程标准和相关文件。标准可能是软件工程组织自愿采用的,或者是客户或其他利益相关者责成采用的。软件质量保证的任务是要确保遵循所采用的标准,并保证所有的工作产品符合标准。软件质量保证的要素评审和审核:技术评审是由软件工程师执行的质量控制活动,目的是发现错误。审核是一种由SQA人员执行的评审,意图是确保软件工程工作遵循质量准则。测试:软件测试是一种质量控制功能,它有一个基本目标——发现错误。SQA的任务是要确保测试计划适当和实施有效,以便最有可能实现软件测试的基本目标。错误/缺陷的收集和分析:改进的唯一途径是衡量如何做。软件质量保证人员收集和分析错误和缺陷数据,以便更好地了解错误是如何引入的,以及什么样的软件工程活动最适合消除它们。软件质量保证的要素变更管理:变更是对所有软件项目最具破坏性的一个方面。如果没有适当的管理,变更可能会导致混乱,而混乱几乎总是导致低质量。软件质量保证确保进行足够的变更管理实践。教育:每个软件组织都想改善其软件工程实践。改善的关键因素是对软件工程师、项目经理和其他利益相关者的教育。软件质量保证组织牵头软件过程改进,并是教育计划的关键支持者和发起者。供应商管理:可以从外部软件供应商获得三种类型的软件:(1)简易包装软件包;(2)定制外壳;(3)合同软件。软件质量保证组的任务是,通过建议供应商应遵循的具体的质量做法,并将质量要求作为与任何外部供应商签订合同的一部分,确保高质量的软件成果。软件质量保证的任务、目标和度量软件质量保证是由与两个不同人群相联系的多种任务组成——这两个人群分别是做技术工作的软件工程师和负有质量策划、监督、记录、分析和报告责任的软件质量保证组。软件工程师通过采用可靠的技术方法和措施,进行技术评审,并进行周密计划的软件测试来获得质量。软件质量保证的要素安全管理:随着网络犯罪和新的关于隐私的政府法规的增加,每个软件组织应制定政策,在各个层面?;な?,建立防火墙?;eb应用系统,并确保软件在内部没有被篡改。软件质量保证确保应用适当的过程和技术来实现软件安全。安全:因为软件几乎总是人设计系统的关键组成部分,潜在缺陷的影响可能是灾难性的。软件质量保证可能负责评估软件失效的影响,并负责启动那些减少风险所必需的步骤。风险管理:尽管分析和减轻风险是软件工程师考虑的事情,但是软件质量保证组应确保风险管理活动适当进行,且已经建立风险相关的应急计划。软件质量保证任务编制项目质量保证计划。参与项目的软件过程描述的编写。评审软件工程活动,以验证是否符合规定的软件过程。审核指定的软件工作产品以验证是否遵守作为软件过程一部分的那些规定。确保根据文档化的规程记录和处理软件工作和工作产品中的偏差。记录各种不符合项并报告给高层管理人员。目标、属性和度量需求质量。需求模型的正确性、完整性和一致性将对所有后续工作产品的质量有很大的影响。软件质量保证必须确保软件团队严格评审需求模型,以达到高水平的质量。设计质量。软件团队应该评估设计模型的每个元素,以确保设计模型显示出高质量,并且设计本身符合需求。SQA寻找能反映设计质量的属性。代码质量。源代码和相关的工作产品必须符合本地的编码标准,并显示出易于维护的特点。SQA应该找出那些合理分析代码质量的属性。质量控制有效性。软件团队应使用有限的资源,在某种程度上最有可能得到高品质的结果。SQA分析在评审和测试上的资源分配,评估是否以最有效的方式进行分配的。 软件质量保证的形式化方法一个计算机程序可以看做是一个数学对象,每一种程序设计语言都有一套定义严格的语法和语义,而且软件需求规格说明也有严格的方法。如果需求模型和程序设计语言都以严格的方式表示,就可以采用程序正确性证明来说明程序是否严格符合它的规格说明。统计软件质量保证统计质量保证反映了一种在产业界不断增长的趋势:质量的量化。对于软件而言,统计质量保证包含以下步骤: 1.收集软件的错误和缺陷信息,并进行分类。 2.追溯每个错误和缺陷形成的根本原因。 3.使用Pareto原则(80%的缺陷可以追溯到所有可能原因的20%),将这20%原因分离出来。 4.一旦找出这些重要的少数原因,就可以开始纠正引起错误和缺陷的问题。一个普通的例子假定软件开发组织收集了为期一年的错误和缺陷信息,其中有些错误是在软件开发过程中发现的,另外一些(缺陷)则是在软件交付给最终用户之后发现的。尽管发现了数以百计的不同问题,所有问题都可以追溯到下述原因中的一个(或几个):不完整或错误的规格说明(IES)。与客户交流中所产生的误解(MCC)。故意违背规格说明(IDS) 。违反程序设计标准(VPS)。数据表示有错(EDR)。构件接口不一致(ICI)。设计逻辑的错误(EDL)。不完整或错误的测试(IET)。不准确或不完整的文档(IID)。将设计转换为程序设计语言实现时的错误(PLT)。不清晰或不一致的人机界面(HCI)。其他(MIS)。一个普通的例子为了使用统计质量保证方法,需要建一张如图13-2所示的表格。表中显示IES、MCC和EDR是造成所有错误的53%的“重要的少数“原因。但是需要注意,在只考虑严重错误时,应该将IES、EDR、PLT和EDL作为“重要的少数”原因。一旦确定了这些重要的少数原因,软件开发组织就可以开始采取改正行动了。改正行动主要是针对“重要的少数"。随着这些“重要的少数"原因不断改正,新的“重要的少数”原因将提到改正日程上来。 统计软件质量保证改正行动主要是针对“重要的少数”。随着这些“重要的少数”原因不断改正,新的“重要的少数”原因将提到改正日程上来。已经证明统计软件质量保证技术确实使质量得到了提高。在某些情况下,应用这些技术后,软件组织已经取得每年减少50%缺陷的好成绩。统计SQA及Pareto原则的应用可以用一句话概括:将时间用于真正重要的地方,但是首先你必须知道什么是真正重要的!软件工程中的六西格玛六西格玛是目前产业界应用最广泛的基于统计的质量保证策略。20世纪80年代在摩托罗拉公司最先普及,六西格玛策略“是严格且规范的方法学,它运用数据和统计分析,通过识别和消除制造以及服务相关过程中的‘缺陷’来测量和改进企业的运转状况”。六西格玛一词来源于6个标准偏差——每百万个操作发生3.4个偏差,它意味着非常高的质量标准。软件工程中的六西格玛六西格玛方法学有3个主要的核心步骤:定义:通过与客户交流来定义客户需求、可交付的产品及项目目标。测量:测量现有的过程及其产品,以确定当前的质量状况(收集缺陷度量信息)。分析:分析缺陷度量信息,并挑选出重要的少数原因。软件工程中的六西格玛如果某个现有软件过程是适当的,只是需要改进,六西格玛还需要另外两个核心步骤:改进:通过消除缺陷根本原因的方式来改进过程??刂疲嚎刂乒桃员Vひ院蟮墓ぷ鞑换嵩僖肴毕菰?。以上3个核心步骤和另外两个附加步骤有时叫做DMAIC方法。软件工程中的六西格玛如果某组织正在开发软件过程,则需要增加下面两个核心步骤:设计:设计过程,以达到(1)避免缺陷产生的根本原因;(2)满足客户需求。验证:验证过程模型是否确实能够避免缺陷,并且满足客户需求。上述步骤有时称为DMADV方法。软件可靠性软件可靠性是指在特定环境和特定时间内,计算机程序正常运行的概率。失效意味着与软件需求的不符。失效可能仅仅是令人厌烦的,也可能是灾难性的。有的失效可以在几秒钟之内得到纠正,有的则需要几个星期甚至几个月的时间才能纠正。让问题更加复杂的是,纠正一个失效事实上可能会引入其他的错误,而这些错误最终又会导致其他的失效??煽啃院涂捎眯缘牟饬靠悸腔诩扑慊南低呈?,可靠性的简单测量是”平均失效间隔时间“MTBF: MTBF=MTTF+MTTR 其中MTTF和MTTR分别是”平均失效时间“和”平均维修时间“。 MTBF可能会产生问题的原因有两个:(1)它突出了失效之间的时间跨度,但不会为我们提供一个凸显的失效率;(2)MTBF可能被误解为平均寿命,即使这不是它的含义??煽啃院涂捎眯缘牟饬靠煽啃粤硪桓隹裳〉暮饬渴鞘剩‵IT)——一个部件每10亿机时发生多少次失效的统计测量。1FIT相当于每10亿机时发生一次失效。软件可用性是指在某个给定时间点上程序能够按照需求执行的概率。定义为: 可用性=MTTF/(MTTF+MTTR)*100% 软件安全软件安全是一种质量保证活动,它主要用来识别和评估可能对软件产生负面影响并促使整个系统失效的潜在灾难。如果能够在软件过程的早期阶段识别出这些灾难,就可以指定软件设计特性消除或控制这些潜在的灾难。建模和分析过程可以视为软件安全的一部分??际?,根据危险程度和风险高低对灾难进行识别和分类。软件安全一旦识别出这些系统级的灾难,就可以运用分析技术来确定这些灾难的严重性和概率。为了达到高效,应该将软件置于整个系统中进行分析。例如,一个微小的用户输入错误有可能会被软件错误放大,产生将机械设备置于不正确位置的控制数据,此时当且仅当外部环境条件满足时,机械设备的不正确位置将引发灾难性的失效。软件安全一旦完成了灾难识别和分析,就可以进行软件中与安全相关的需求规格说明了。在规格说明中包括一张不希望发生的事件清单,以及针对这些事件所希望产生的系统响应。这样就指明了软件在管理不希望发生的事件方面应起的作用。尽管软件可靠性和软件安全彼此紧密相关,但是弄清它们之间的微妙差异非常重要。软件可靠性使用统计分析的方法来确定软件失效发生的可能性,而失效的发生未必导致灾难或灾祸。软件安全则考察失效导致灾难发生的条件。也就是说,不能在真空中考虑失效,而是要在整个计算机系统及其所处环境的范围内加以考虑。 ISO9000质量标准质量保证体系可以定义为:用于实现质量管理的组织结构、责任、规程、过程和资源。创建质量保证体系的目的是帮助组织以符合规格说明的方式,保证组织的产品和服务满足客户的期望。这些体系覆盖了产品整个生命周期的多种活动,包括计划、控制、测量测试和报告,并在产品的开发和制造过程中改进质量等级。 ISO9000质量标准某个公司要登记成为ISO9000质量保证体系中的一种模式,该公司的质量体系和实施情况应该由第三方的审核人员仔细检查,查看其是否符合标准以及实施是否有效。成功注册之后,这个公司将获得由审核人员所代表的注册登记实体颁发的证书。此后每半年进行一次监督审核,以此保证该公司的质量体系持续符合标准。 ISO9000质量标准 ISO9001:2000中描述的质量要求涉及管理者责任、质量体系、合同评审、设计控制、文件和资料控制、产品标识与可追溯性、过程控制、检验和试验、纠正及预防措施、质量记录的控制、内部质量审核、培训、服务以及统计技术等主题。软件组织要登记为ISO 9001:2000认证,就必须针对上述每个方面的质量要求制定相关的政策和规程,并且有能力证明组织活动的确是按照这些政策和规程实施的。 SQA计划 SQA计划为软件质量保证提供了一张路线图。该计划由SQA小组制定,作为各个软件项目中SQA活动的模板。 IEEE公布的标准建议SQA计划应包括:(1)计划的目的和范围;(2)SQA覆盖的所有软件工程工作产品的描述;(3)应用于软件过程中的所有适用的标准和习惯做法;(4)SQA活动和任务(包括评审和审核)以及它们在整个软件过程中的位置;(5)支持SQA活动和任务的工具和方法;(6)软件配置管理的规程;(7)收集、?;ず臀に蠸QA相关记录的方法;(8)与产品质量相关的组织角色和责任。产品度量框架测量是任何工程过程的一个关键环节。使用测度以较好地理解所创建模型的属性,评估所制造工程产品或系统的质量。但是,与其他工程学科不同,软件工程并不是建立在基本的物理定量定律上。直接测度在软件世界是不常见的。由于软件测度与度量经常是间接得到的,因此有广泛的争论空间。产品度量框架软件业界的一些人始终在争论:软件是不可测量的,或者说,测量的尝试应该推迟,直到我们对软件以及用于描述软件的属性有较好的理解。这种说法是错误的!虽然计算机软件产品度量往往并不是绝对的,但产品度量为我们提供了一种基于一组明确规定的规则来评价质量的系统方法。同时,产品度量为软件工程师对软件产品提供了现场而不是事后的理解。这使软件工程师能够在潜在问题变成灾难性的错误之前发现和纠正它们。 产品度量框架测量将数字或符号赋给现实世界中的实体属性。为达到这个目标,需要一个包含统一规则的测量模型。尽管测量理论及其在计算机软件中的应用等主题超出了本书的讨论范围,但是,为测量软件的产品度量建立一个基本框架和一组基本原则是值得的。测度、度量和指标尽管测量、测度和度量这三个术语常??梢曰セ皇褂?,但注意到它们之间的细微差别是很重要的。 “测度”一词可用作名词,也可用作动词。在软件工程中,“测度”为产品或过程的某些属性的程度、数量、维数、容量或大小提供量化的指示。而“测量”是确定测度的动作。度量在《IEEE标准词汇表》中定义为:度量是一个系统、构件或过程具有给定属性的量化测量程度。测度、度量和指标当收集了一个数据点,就已建立了一个测度。收集一个或多个数据点,由此产生测量。软件的度量以某种方式与单个测度相关。软件工程师收集测度并开发度量以便获得指标。一个指标是一个度量或多个度量的组合,它提供了对软件过程、软件项目或产品本身的深入理解。指标提供的理解使项目经理或软件工程师能够调整过程、项目或产品以使其变得更好。产品度量的挑战在过去的30年中,许多研究人员试图开发一种能为软件复杂性提供全面测量的度量。尽管已提出了许多复杂性测量,但每种方法都对什么是复杂性以及哪些系统属性导致复杂性持有不同的看法。然而,仍有必要去测量和控制软件的复杂度。若这个质量度量的单一值难以获取的话,针对不同内部程序属性开发测度应该是可能的。这些测量和由此产生的度量可用作分析模型和设计模型的独立指标。测量原则产品度量的作用主要包括:(1)辅助分析模型和设计模型的评估;(2)提供过程设计和源代码复杂性的指示;(3)方便更有效测试的设计。[ROC94]提出一个能用以下五个活动描述的测量过程:公式化:导出适合于所考虑软件表示的测量和度量。收集:用于导出公式化度量所需数据的积累机制。分析:度量的计算和数学工具的使用。解释:为获得对表示的质量的理解而评价度量。反?。捍佣缘萁桓砑哦拥牟范攘康慕馐椭谢竦媒ㄒ?。测量原则软件度量仅当被有效地特征化和确认以证明它们的价值时才是有用的。提出了许多度量特征化的确认原则,其中一些有代表性的原则如下:度量应该具有引人的数学特性。当度量代表一个软件特征时,当正向品质出现时特征值提高,当不理想品质出现时特征值下降。度量值应该以同样的方式增加或减小。每种度量在发布或用于做决策之前,应该在广泛的环境中根据经验加以确认。测量原则尽管公式化、特征化和确认是关键的,但收集和分析是驱动测量过程的活动。[ROC94]为这些活动提供了以下指导原则:(1)只要有可能,数据的收集与分析应能自动化地进行;(2)应该使用有效的统计技术以建立内部产品属性与外部质量特性之间的关系;(3)应该为每个度量建立解释性指导原则和推荐建议。面向目标的软件测量目标/问题/度量(GQM)范型是由Basili和Weiss开发的,这种技术用于为软件过程的任何部分识别出有意义的度量。GQM强调了以下要求:(1)确定特定过程活动的明确的测量目标或将要评估的产品特性;(2)定义一组必须回答的问题以达到目标;(3)确定被良好公式化的度量以帮助回答这些问题。面向目标的软件测量目标定义??榭捎糜诙ㄒ迕扛霾饬磕勘?。模板采取以下形式: 在…{进行测量的环境}…环境中,从…{对测量感兴趣的人}…的角度,关于…{活动或属性被考虑的方面}…的方面,为…{分析的总体目标}…目的,分析…{将要测量的属性和活动名}…。面向目标的软件测量考虑SafeHome软件体系结构,目的是评估体系结构构件,涉及方面为使SafeHome具有较强可扩展性的能力,视角为完成该工作的软件工程师,环境为后续三年的产品改进。面向目标的软件测量明确定义了测量目标之后,形成一组问题?;卮鹫庑┪侍庥兄谌砑哦?或其他共利益者)确定是否已达到测量目标??赡芑嵛实降奈侍馊缦拢?Q1:体系结构构件是否将以功能与数据分开的方式描述? Q2:每个构件的复杂性是限定在一定的范围内以便于修改与扩展吗? 每个问题都应该利用一个或多个测度和度量以量化的方式回答。有效软件度量的属性 [EjI91]定义了一组有效软件度量所应具有的属性。导出的度量及导出度量的测度应该是:简单的和可计算的。在经验上和直觉上有说服力。一致的和客观的。单位与量纲的使用是一致的。编程语言的独立性。高质量反馈的有效机制?;诠δ艿亩攘抗δ艿?FP)度量可用做测量系统交付功能的有效手段。利用历史数据,功能点度量可用于:(1)估算设计、编码和测试软件所需开销或工作量;(2)预告测试期间将遇到的错误数;(3)预测实现系统中的构件数和(或)预计的源代码行数?;诠δ艿亩攘坷没谌砑畔⒂蚩墒牟舛群腿砑丛有云拦赖木楣叵道醇扑愎δ艿?。信息域的值用下列方式定义:外部输入数(EI)。每个外部输入源于一个用户,或从另一个应用系统中传送过来;它提供了面向不同应用系统的数据或控制信息。外部输出数(EO)。每个外部输出从应用系统中导出,并为用户提供信息。外部查询数(EQ)。一个外部查询定义为一个在线输入。其结果是以在线输出的方式产生某个即时软件响应。内部逻辑文件数(ILF)。每个内部逻辑文件是驻留在应用系统边界之内的数据逻辑分组,它通过外部输入来维护。外部接口文件数(EIF)。每个外部接口提驻留在应用系统外部的数据逻辑分组,但它为该应用系统提供有用的信息?;诠δ艿亩攘恳坏┦占苏庑┦?,就完成了图13-3所示的表,且复杂度的值与每个计数相关。利用功能点方法的组织制定标准以确定表内某个特定的栏目是简单、中等还是复杂。不过,复杂度的确定毕竟有一定的主观性。利用下面的关系式计算功能点FP: FP=总计*[0.65+0.01*∑(Fi)] 基于功能的度量 Fi(i=1~14)是值调整因子(VAF),它基于对下列问题的回答来确定: 1.系统需要可靠的备份和恢复吗? 2.需要专门的数据通信从应用系统中传输信息或将信息传输到应用系统吗? 3.存在分布处理功能吗? 4.性能是关键的吗? 5.系统将运行在一个现有的、紧张使用的操作环境吗? 6.系统需要在线数据项吗? 7.在线数据项需要对多个屏幕或操作建立输入事务吗? 8.ILF在线更新吗? 9.输入、输出、文件或查询复杂吗? 10.内部处理复杂吗? 11.所设计的代码是可复用的吗? 12.转换与安装包括在设计中吗? 13.系统是为不同组织中的多个安装而设计的吗? 14.应用系统是为便于变更和易于为用户使用而设计的吗?每个问题可用从0(不重要或不适用)到5(绝对必需)间的数值来回答。公式中的常量值和应用于信息域计数的加权因子是由经验确定的。 SafeHome实例为确定用以计算功能点度量所需的一组关键信息域测度,需要对数据流图加以评估。图中显示了3个外部输入——密码、紧急按钮和启动/关闭;以及两个外部查询——区域查询与传感器查询。同时,给出了一个内部逻辑文件——系统配置文件;两个外部输出——消息与传感器状态;4个外部接口文件——测试传感器、区域设置、启动/关闭和报警。这些数据及相应的复杂度在图13-5中给出。 FP=50*[0.65+(0.01*46)]=56 小结作业 P255 2,6,10,14

上一页:关于软件工程介绍ppt模板1 下一页:软件工程教学课件PPT

关于软件质量保证ppt

下载地址

关于软件质量保证ppt

优秀PPT

PPT分类Classification

Copyright:2009-2015 www.tornecasals.com Corporation,All Rights Reserved PPT宝藏 版权所有

437.com必赢下载 粤ICP备13028522号

新闻 网页 音乐 贴吧 图片

互联网www.sogou.com