绿盟科技.docx
- 文档编号:8663099
- 上传时间:2023-02-01
- 格式:DOCX
- 页数:11
- 大小:25.86KB
绿盟科技.docx
《绿盟科技.docx》由会员分享,可在线阅读,更多相关《绿盟科技.docx(11页珍藏版)》请在冰豆网上搜索。
绿盟科技
软件测试
摘要:
计算机技术已经越来越广泛地应用于国民经济和国防建设各个部门,以不可阻挡之势渗透到人们工作和生活的各个领域,尤其在航天航空核能通信交通金融等一些关键领域中,计算机的作用更加至关重要。
同时,他们对计算机软件的可靠性和安全性也有严格的要求。
近年来,由于软件错误而造成的经济损失导致严重后果的事例屡见不鲜,因此,如何保证软件产品的质量和可靠性就成为人们必须解决的一个重要问题,而软件测试便是保证软件质量的一个重要手段。
据统计,在国外的软件开发中,开发费用的近一半甚至更多要用于软件测试,由此也可以看出软件测试在软件开发中的重要地位。
本文的主要结果详略恰当地给出了软件测试地方法与策略。
进行一次完整的软件测试过程,并完成测试过程的基础撰写。
其中包括根据所选系统拟出了测试计划并设计出了一大批测试用例,测试分析报告。
关键字:
软件测试;文档;bug
前言
随着信息技术全球化的深入发展,我国的软件产业将不可避免地融入全球软件产业。
一方面,更多的大型跨国软件公司加大对中国市场的投入,对产品和服务本地化的需求快速增加。
另一方面,越来越多的国内大型的软件公司正加速国际化发展的步伐,他们逐步走出国门,加入全球竞争行列。
软件质量表示软件符合用户的使用要求的程度,这种程度不仅表现在软件产品自身的功能性和性能方面,也表现在软件的国际化和本地化的能力等方面。
软件企业只有提高软件质量,不断改进质量管理地方法和流程,提供具有符合国际市场和用户要求的高质量软件产品,才具备进军国际市场的实力。
提高软件测试在软件生命周期中的地位是保证软件质量的关键,做好软件测试工作是解决软件质量的根本吗,为了保证国际化软件的产品质量,进行有效的国际化测试成为必不可少的生产过程。
由于目前我国软件企业的规模普遍较小,而且主要面向国内用户市场,对软件国际化和本地化发展战略和实现技术认识不足,重视不够,特别是在保证国际化软件的质量和测试技术方面,与国外同行先比还存在较大差距。
国内软件测试成熟度不高,特别在国际化软件测试方面滞后,在一定程度上,影响着我国软件在国际市场上的竞争力,也影响着我们承接软件外包服务的规模。
因此,探讨和研究软件测试技术,成为摆在国内软件界的新课题。
第一章软件测试的必要性和需求分析
1.1软件测试的必要性
软件测试的意义在于:
(1)发现软件错误;
(2)有效定义和实现软件成分由底层到高层的组装过程;
(3)实现软件是否满足任务书和系统定义文档所规定的技术要求;
(4)为软件质量模型的建立提供依据。
软件测试的目的,第一是确认软件的质量,其一方面的确认软件做了你所期望的事情,另一方面是确认软件以正确的方式来做这个事件。
第二是提供信息,比如提供给开发人员或程序经历的反馈信息,为风险评估所准备的信息。
第三软件测试不仅是在软件产品本身,而且还包括软件开发的过程。
如果一个软件产品开打完成后发现很多问题,这说明此软件开发过程很可能是有缺陷的。
因此软件测试的第三个目的是保证整个软件开发过程是高质量的。
软件质量是有几个方面来衡量,在正确的时间用正确方法把一个工作做正确。
符合一些应用标准的要求,比如不同的国家的用户不同的操作习惯和要求,项目工程中的可维护性可测试性的要求。
质量本身就是软件达到最开始所设定的要求,而代码的优美或精巧的技巧并不代表软件的高质量。
质量也代表着它符合客户的需求。
作为软件测试这个行业,最重要的一件事就是从客户的需求出发,从客户的角度去看产品,客户会怎么去使用这个产品,使用过程中会遇到什么样的问题。
只有这些问题都解决了,软件产品的质量才可以说是上去了。
总之,它的目标就是确保软件的质量。
1.2软件测试需求分析
理论上,软件测试需求是缘于软件需求的,而软件需求又是源于用户需求的。
然而,有些时候在分析软件测试需求时并不存在已经文档化的软件需求规格说明。
在这种情况下,要分析软件测试需求可能仍然要追溯到用户需求,由于后者涉及需求工程中的专门中的专门知识,本文不做细述;这里重点讨论前者。
在一个规范化的软件需求规格说明中,用户需求是有更高的业务需求细化而成,他通常描述了用户使用该软件系统会涉及到不同的执行路径.工作逻辑以及所预期的处理结果。
在UML表示方法中,用户需求通常通过USECASE来进行刻画。
接下来用户需求将进一步转化为三类需求项,及功能需求性能需求项和月塑性需求项。
这三类需求向就是通常意义上的软件需求项。
管理这三类需求向的矩阵被称为需求矩阵。
理论上,在测试资源许可并且确有必要的前提下,测试的使命将试样整合确认待开发的软件及其中间的产品满足需求矩阵的各个需求项。
然而,几乎没有几个公司或开发团队能够提供这类测试所需的诸多的资源,此时,一种可行的策略是将待测试的软件需求项按照优先关系进行排序,以帮助测试经理决策在既定资源的情况下,应该如何统筹安排测试工作。
软件测试需求项是测试需求分析的起点,这一点在工程实践中并不绝对。
对于不用阶段的测试,测试需求开发的所涉及的工作内容和方法都会略有差异。
例如,可如果是一个验收测试,那么,除了个别的需求需要做进一步明确外,几乎可以检测是需求等同于用户需求和业务需求;又如,如果是系统测试,除了需要对不具备可测试性的软件需求项进一步开发外,几乎可以对软件需求和测试需求不作区分。
再如,如果是集成测试,测试需求应该是从概要设计规格说明中到导出。
如果上不存在该要实际规格说明,就需要从软件需求规格说明出发,与软件设计人员协同工作,集体定出构成系统的各个模块子系统分系统的功能性能约束性以及相互接口关系。
根据协同工作的结果,如果项目不存在概要设计规格说明,急需要从概要设计规格说明出发,与软件设计人员明确给个模块内部的对象属性与方法以及对象与对象间的通信关系。
根据此结果,进一步开发相应的测试需求,。
相应地,上一节所说的对软件需求项进行优先关系排序在实践中要变通地理解为对策试需求进行优先关系排序。
例如为了保证系统能够长期安全稳定可靠高效的运行,机票预订系统应该满足以下的性能需求
机票预订系统的数据需求包括如下几点:
(1)数据录入和处理的准确性和实用性
数据输入是否准确处理的前提,错误的输入会导致系统输出的不正确和不实用,从而使系统的工作失去意义。
数据的输入来源是手工输入。
手工输入要通过系统上的安排系统具有容错性,并且对操作人员要进行系统的培训。
在系统中,数据的输入往往是大量的,因此系统要有一定的处理能力,以保证迅速的处理数据。
(2)由于系统的数据是共享的,在不同的旅行社中,机票是共享数据,所以如何保证这些数据的一致性,是系统必须解决的问题。
要解决之一问题,要有一定的人员维护数据的一致性,在数据输入处控制数据的去向,并且要求对数据库的数据完整性进行严格的约束。
对于输入的数据,要为其定义完整性规则,如果不能符合完整性约束,系统应该拒绝数据。
(3)数据的共享和独立性
整个机票预订系统的数据是共享的。
然而,从系统开发的角度上看,共享会给设计和调试是带来困难。
因此,应该提供灵活的配置,是各个分系统能够独立运行,而通过人工干预的手段进行系统数据的交换。
这样,也能提供系统的强壮性。
第二章软件测试的方法
软件BUG的存在迫使人们进行软件测试。
软件测试实质上是为了发现程序中的错误而执行性程序的过程。
软件的内部测试狭义的概念是由软件开发部门自我组织的,在部门内部进行的软件测试;而广义上的软件的内部测试是指在向用户发布正式版本之前进行的软件测试。
这个过程通常由单元测试,集成测试.验收测试.平行运行测试构成,通常需要设计完整的测试方案。
2.1白盒测试
白盒测试也称结构测试或逻辑驱动测试,它是按照程序内部的结构测试程序,通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。
这一方法是把测试对象看作一个打开的盒子,测试人员依据程序内部逻辑结构相关信息,设计或选择测试用例,对程序所有逻辑路径进行测试,通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。
采用什么方法对软件进行测试呢?
常用的软件测试方法有两大类:
静态测试方法和动态测试方法。
其中软件的静态测试不要求在计算机上实际执行所测程序,主要一些人工的模拟技术对软件进行分析和测试;而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序,而达到发现程序错误的过程。
白盒测试的测试方法有代码检查法,静态结构分析法静态质量度量法逻辑覆盖法基本路径测试法域测试符号测试路径覆盖程序变异。
白盒测试的覆盖标准有逻辑覆盖循环覆盖和基本路径测试。
其中逻辑覆盖包括语句覆盖判定覆盖条件覆盖判定/条件覆盖、条件组合覆盖和路径覆盖.
六种路径覆盖标准:
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。
语句覆盖每条语句至少执行一次。
判定覆盖每个判定的每个分支至少执行一席。
条件覆盖每个判定的每个条件应取到各种可能的值。
判定/条件覆盖同时满足判定覆盖条件覆盖。
条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
路径覆盖使程序中每一条可能的路径至少执行一次。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
“白盒”法是穷举路经测试。
在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。
贯穿程序的独立路径是天文数字。
但即使每条路径都测试了仍然可能有错误。
第一,穷举路径测试决不能查出程序违反了设计规范,及程序本身是错误的程序。
第二,穷举路经测试不可能查出程序中因遗漏路径而出错。
第三,穷举路经测试可能发现不了一些数据相关的错误。
白盒测试三步法:
一、根据代码的功能,人工设计测试用了进行基本的功能测试;二、统计白盒覆盖率,为未覆盖的白盒单位设计测试用例,实现完整的白盒覆盖,比较理想的覆盖率是实现%100语句、条件、分支、路径覆盖;三、自动生成大量的测试用例,捕捉”程序员未处理某些特殊输入"形成的错误。
2.2黑盒测试
黑盒测试也称功能测试或数据驱动测试,它是在已知产品所具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看做一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,他只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息,并且保持外部信息的完整性。
黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等,主要用于软件确认测试。
“黑盒”法着眼于程序的外部结构、不考虑内部逻辑结构。
针对软件界面和软件功能进行测试。
“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序所以错误。
实际上测试情况有无穷多个,人们不仅要测试所以合法的输入,而且还要对那些不合法但是可能的输入进行测试。
黑盒测试注重与测试软件的功能需要,主要试图发现下列几类错误。
1、功能不正确或遗漏;
2、界面错误;
3、数据库访问错误;
4、性能错误;
5、初始化和终止错误等。
从理论上讲,黑盒测试只有采用穷举输入测试,把所有可能的输入都作为测试情况考虑,才能查出程序中所有的错误。
实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但可能的输入进行测试,通过制定测试案例指导测试的实施,保证软件测试有组织、按步骤,以及有计划地进行。
黑盒测试行为必须能够加以量化,才能真正保证软件质量,而测试用例就是将测试行为具体量化,才能真正保证软件质量,而测试用例就是将测试行为具体量化的方法之一。
具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交式样设计法、功能图法等。
第三章软件测试计划
软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。
对于验证产品的可接受程度编写测试计划文档是一种有用的方式。
详细的测试计划可以帮助测试项目组织外的人了解为什么和如何验证产品。
他非常有用但是测试项目组织外的人却很少去读它。
以下几节对机票预定系统这个项目作了分析。
3.1机票预定系统的运行要求
机票预定系统中的各个子系统的硬件和软件的配置如下:
1、服务器端子系统的运行要求:
系统软件:
windowNTServer
数据库管理系统:
SOLServer
硬件要求:
PentiumIII450以上,258MRAM,14GHD
2、客户端子系统的运行要求:
系统软件:
WindowNTWorkstation
数据库管理系统:
SQLServer
硬件要求:
Pentium133以上,32MRAM,4.3GHD
3.2建立机票预定系统的约束
1、Client/Server结构总体设计方案对它的约束
机票预定系统作为Client/Server结构的一个应用系统,不可避免的要受到Client/Server结构的约束。
在其实施的各个阶段都要服从它的一些规划,包括功能设计、系统配置和计划。
同时,由于信息的共享,机票预订系统还受到其他系统的信息约束
2、人力、资金、时间的约束
机票预定工程实施的目标就是要带给航空公司看得见的效益,其开发过程中也要考虑到人力、资金和时间的约束。
因此,在设计中,重点是销售系统中的方便快捷,提供给旅客以优质高效的服务,并提高销售的效率和便捷,为航空公司带来良好的效益。
计算机技术和产品的发展日新月异,将会给信息处理带来更多手段,同时也会带来更加丰富的信息表达形式。
例如图像和语音技术的进步,多媒体技术的发展,这些都要求系统在设计时考虑技术变化的可能性,为可能的变化预留一定的系统处理能力。
第四章写用例
4.1测试用例是软件测试的核心
软件测试的重要性是毋庸置疑的。
但如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标。
每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
影像软件测试的因素很多,例如软件本身的复杂程度、开发人员的素质、测试方法和技术的运用等等。
因为有些因素是客观存在的,无法避免。
有些因素则是波动的、不稳定的,例如开发团队是流动的,有经验的走了,新人不断补充进来;一个具体的人工作也受情绪的影响,等等。
如何保障软件测试质量的稳定?
有了测试用例,无论是谁来测试,参照测试用例实施,都能保障测试的质量。
可以把人为因素的影响减少到最小。
即使最初的测试用例考虑不周全,随着测试的进行和软件版本更新,也将日趋完善。
因此测试用例的设计和编制是软件测试活动最重要的。
测试用例是测试工作的指导,是软件测试的必须遵守的准则,更是软件测试质量稳定的根本保障。
4.2什么叫测试用例
测试用例(TestCase)目前没有经典的定义。
比较通常的说法是:
指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略,内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。
不同类型的软件,测试用例是不同的。
不同于诸如系统、工具、控制、游戏软件,管理软件的用户性需求更加不统一,变化更大、更快。
笔者主要从事企业管理软件的测试。
因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。
测试用例更趋于是针对软件的产品的功能、业务规则和业务处理所涉及的测试方案。
对软件的每个软件的特定功能或运行操作路径的测试构成了一个个测试用例。
4.3编写测试用例
1、测试用例文档
编写测试用例文档应有文档模板,须符合内部的规范要求。
测试用例文档将受制于测试用例管理软件的约束。
软件产品或软件开发项目的测试用例一般以该产品的软件模板或子系统为单位,形成以更测试用例文档,但并不是绝对的。
测试用例文档有简介和测试用例两部分组成。
简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。
测试用例部分逐一列示各种测试用例。
每个具体的测试用例都将包括下列详细信息:
用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果、出口准则、注释等。
以上内容涵盖了测试用例的基本元素:
测试索引、测试环境、测试输入、测试操作、预期结果、评价标准。
2、测试用例的设置
我们早期的测试用例是按照功能设置用例。
后来引进了路径分析法,按路径设置用例。
目前演变为按功能、路径混合模式设置用例。
3、按功能测试是最简洁的,按用例规约便利测试的每一功能。
对于复杂操作的程序模块,其各功能的实施是相互影响、紧密相关、环环相扣的,可以演变出数量繁多的变化。
没有严密的逻辑分析,产生遗漏在所难免。
路径分析是一个很好的方法,其最大的优点是在有可以避免漏测试。
为提高测试效率,软件测试以大力发展自动测试。
自动测试的中心任务是编写测试脚本。
如果说软件工程中软件编程必须有规格说明书,那么测试脚本的设计规格说明书就是测试用例。
4、评估测试结果的度量基准
完成测试实施后需要对测试结果进行评估,并且编制测试报告,判断软件测试是否完成,衡量测试质量需要一些量化的结果。
例:
测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少,等等。
以前统计基准是软件模块或功能点,显得过于粗糙。
采用测试用例做度量基准更加准确、有效。
5、通过收集缺陷,对比测试用例和缺陷数据库,分析确认是漏测还是缺陷复现。
漏测反映了测试用例的不完善,应立即补充相应的测试用例,最终达到逐步完善软件质量。
而已有相应测试用例,则反映实施测试或变更存在问题。
如下为机票预定系统的一个测试用例:
第五章测试执行
5.1测试的执行
测试计划是指导测试用例设计、测试执行的纲领性文件,是成功测试的前提和必要条件,测试用例设计师测试工作的核心,测试用例的成功设计及预示着完成了一半的测试任务,但是测试执行是测试计划和测试用例实现的基础,严格的测试执行是测试工作不会半途而废;
而且测试执行也是非常现实的,对每一个测试人员都是一种考验,一方面要创造性思维,另方面要做到一丝不苟。
前面我们谈到软件测试执行的策略,但这些策略也需要带到实习和监控,最终才能达到测试的目标。
虽然我们都认为,有效的测试计划是指导测试用例设计、测试执行的指导性文件、是成功测试的前提和必要条件,测试用例设计是测试工作的核心测试用例的成功设计已经完成了一半的测试任务,但是测试的执行是基础,是测试计划和测试用例实现的基础,严格的测试执行使测试工作不会半途而废。
而且,测试执行管理相对复杂些,在整个测试执行阶段中,我们需要面对一系列问题,如:
1如何确保测试环境满足测试用例所描述的要求?
2如何保证每个测试人员清楚自己的测试任务和要达到的目标?
3如何保证每个测试用例得到百分之百的执行?
4如何保证所报告的软件缺陷正确、描述清楚、没有漏掉信息?
5如何在验证BUG或新功能于回归测试值之间寻找平衡
6如何跟踪Bug处理的进度使严重的Bug及时得到解决?
要实现上述目标,得到一个真实、符合要求的执行过程,需要很好的全程跟踪测试过程、过程度量和评审、借助有效的测试管理系统等来实现。
如:
机票预定系统的测试执行情况:
1客户机接受信息模块测试
客户机接受用户输入的各种数据然后经网络传送给服务器。
2、客户输出信息模块测试
客户机输出为打印账单或机票,和确认或出错信息。
3、网络接收和发送模块结构测试
接受由服务器程序经网络传送到客户机的数据包,他是程序与网络的接口。
经解码后发送数据给服务数据库。
4、服务器模块测试
测试数据库的安全性,可靠性、健壮性、效率。
5各模块之间的接口测试
对各模块之间的接口进行测试
6系统测试
用黑盒法对系统进行各类功能测试。
测试机构人员:
人员主要有个程序模块的软件开发人员和某某航空公司的有关负责人共同支持。
5.2常用测试工具简介
WinRunner:
企业级功能测试工具,自动录制、检测和回放用户的应用操作,有效的帮助测试人员对复杂的企业级应用的不同发布版本进行测试,提高工作效率和质量,确保平台的、复杂的企业级应用无故障发布及长期稳定运行
loadRunner:
预测系统行为和性能的负载测试工具。
通过以模拟上千万用户实施并发伏在及时性能检测的方式来确认和查找问题,能对整个企业架构进行测试。
能最大限度的缩短测试时间,优化性能和加速应用系统的发布周期。
6.1什么是BUG
所谓bug也就是进行某一输入后,软件输出是错误的或者不是我们所期望的结果。
bug在英语中是臭虫的意思。
在以前的大型机器中,经常出现有些臭虫破坏了系统的硬件结构,导致硬件运行出现问题,甚至崩溃。
时间长了,bug被引申为错误的意思,什么地方出了问题,就说什么地方除了bug。
提交bug时描述的越详细越好。
随着测试管理工具的完善、利用,提交bug时很多项系统已经帮我们自动实现了,如提交姓名、提交日期等。
但有些项仍需要我们自己填写。
如摘要、操作步骤、预期结果、输出结果等。
评价测试质量的目标可以有
6.2测试人员提交BUG技巧
首先,确保你所发现问题确实是一个bug,不要出现因为测试人员操作错误或配置错误所引起的“bug”,这样会降低你在开发人员心中的可信度。
在测试的时候,如果发现测试的实际结果与预期测试结果不符时,不要马上上报bug,先想想会在什么地方出现错误。
作为专业的测试人员,应该能够对出现的问题进行跟踪,确认了在配置、操作没有错误的前提下通过追踪分心确认所测试的业务流程确实存在bug,并能大概对bug产生的原因进行定位。
测试人员,需要做到专业,尽量少给开发找麻烦,不要制造实际上不不能在的bug。
确认所发现问题是一个bug之后,按照测试步骤再执行一次,确保bug是可重现的而不是随机的。
如果bug不能重现,应该尽量找到bug重现的规律,在一些比较难重现的问题可以找开发配合一起查找原因,如果还是无法重现则需要在bugreport中对出现的问题描述清楚并说明出现随机性。
在开发对bug进行修改之后,测试需要抱着怀疑的态度认真地对问题进行验证,需要严格按照测试步骤来进行测试,检查开发是否已经正确修改好所出现的问题,以及开发对bug进行了修复之后是否会引进新的问题。
不要相信开发说“已经修改好了,肯定没问题了”就不对问题进行细致的检查了,如果开发修改的不彻底,问题仍然存在的,或者可能会由于开发在修改bug的时候忽略了另一些细节导致了心bug的出现。
尽量不要再关闭bug之后,才发现这个问题还没有彻底修改;也不要出现bug关闭之后,出现了新的bug。
测试对bug进行验证确认已经修改好之后,关闭bug。
在关闭的时候,应该对bug最终修改结果进行简要描述,如果bug的修改引起配置或数据库或业务流程的变更,也需要在bug关闭描述中进行说明。
第七章开发修改
软件开发中测试以及修改不够的基本流程:
一测试人员发现问题后,记录bug出现位置,截图,时间,能否重演等。
对于不慎紧急的问题先归档,等待处理。
二在例会或者讨论会上提出所出现的问题,经过项目负责人支持商讨之后决定是否修改。
若修改则有该功能模块的开发人员查找产生bug原因,并写分析报告。
三、在例会或者讨论会上由开发人员提出已明确产生原因的bug列表和分析报告,并经由项目负责人商讨确定是否修改,并制定修改计划。
四、修改人按照计划修改,并书写修改报告。
五、修改后的版本交友测试人员测试,并记录测试结果。
六如果测试通过,则发布新版本,否则从第一步重复。
第八章回归测试
8.1什么是回
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 科技