平台功能测试规范.docx
- 文档编号:14869990
- 上传时间:2023-06-28
- 格式:DOCX
- 页数:42
- 大小:484.06KB
平台功能测试规范.docx
《平台功能测试规范.docx》由会员分享,可在线阅读,更多相关《平台功能测试规范.docx(42页珍藏版)》请在冰点文库上搜索。
平台功能测试规范
平台功能测试规范
66
平台功能测试规范
目的
本文档的目的在于指导测试人员如何进行冒烟测试,SIT测试,UAT测试,预发布环境测试,生产环境测试以及线上问题处理。
规范测试活动。
以及一些测试活动中常见的问题。
范围
包含的测试活动有冒烟测试,SIT测试,UAT测试,预发布环境测试,生产环境测试,回归测试以及线上问题处理与反馈,可以根据项目或者平台的实际情况对活动进行裁剪。
对象
本文档面向对象为测试人员,实施人员等
1.冒烟测试规范
1.1冒烟测试目的
冒烟测试(SmokeTesting)可以说是一种预测试,软件代码正式编译并交付测试之前,先尽量消除其“表面的”错误,确保软件基本功能符合需求规格说明书要求,减少后期测试开发的负担。
在软件开发过程中,一直有高内聚,低耦合这样的说法,各个功能模块之间的耦合还是存在的,因此一个功能的改动,还是会影响到其他功能模块。
因此在开发人员修复了先前测试中发现的bug后,想知道这个bug的修复是否会影响到其他功能模块,需要做的就是冒烟测试。
1.2冒烟测试定义
冒烟测试是这样的一种测试,不要求覆盖面有多广,但至少要保证覆盖待测产品的绝大部分功能;不要求每个功能都测的很详细,但至少要保证被修复了的bug所属的功能和系统其他骨干功能都是可用的(即这个版本能拿去做系统功能测试了)。
覆盖骨干功能和bug所属功能,却不是简简单单在页面中点几下就行了的。
任何一个项目或者产品,骨干功能都有它的使用场景。
冒烟测试就是要保证这些骨干功能的使用场景都能跑通,如果没跑通,后续的系统测试就没必要了。
1.3冒烟测试方法
1.基于每日构建的冒烟测试
冒烟测试就是在每日build建立后,对系统的基本功能进行简单的测试。
这种测试强调功能的覆盖率,而不对功能的正确性进行验证。
冒烟测试一般用于每日构建(Nightlybuild),构建服务器首先从VSS服务器上,下载最新的源代码,然后编译单元测试,运行单元测试通过后,编译可执行文件,可执行文件若可运行,并能执行最基本的功能,则认为通过了冒烟测试。
●基于每日构建的冒烟测试的优点主要有:
a)进度可见并可以控制到1-2天的细粒度,很容易看到进度的偏差;
b)及早的发现开发BUG和缺陷并分析解决,对开发人员的一种监督和促进,提高软件质量
c)由于将大集成分解到每日构建中的小集成,避免了传统产品集成或集成测试时候出现的严重问题的可能。
d)在项目中宣贯质量意识,强调第一次就把事情做好,而不是等测试来帮你发现问题
●基于每日构建的冒烟测试也存在一些风险和缺陷,具体主要有:
e)给开发人员太大压力,开发每天都在较紧张环境中工作
f)需要额外的测试人力资源和每日构建硬件环境的投入
g)开发人员不能专注,既要分心去修改BUG,又要开发新的功能点
h)对开发负责人要求更好,需要将功能细化到1-2天的有明确输出的功能点
i)发需要投入额外的精力来保证每日构建顺畅
●基于每日构建的冒烟测试适用场景
a)对进度偏差控制和要求很高的项目
b)开发检查点和里程碑制定的很细致的项目
c)采用增量和迭代开发的项目,快速和敏捷开发的项目
2.基于送测版本的冒烟测试
此种方法来源于每日构建和冒烟测试,只是把粒度放大了。
不是做每日build,而是根据版本计划,开发组定期发布送测版本,测试组拿到新的版本先做冒烟测试,测试通过则开始正式测试,不通过就返给开发组。
这种做法的优点可以避免微软的每日build和冒烟测试做法的一些缺陷,同时也会因粒度粗而有自身的缺点,在此就不做详述。
1.4测试实施
1.4.1测试实现过程
1.测试规划阶段:
冒烟测试用例的编写,以及测试执行,都是需要时间成本的,故在最初制作项目计划时,就应该识别该任务,并充分考虑其工作量。
根据项目实际,确定在单元测试,集成测试,系统测试的哪个或哪几个阶段开展冒烟测试,明确准入准出标准。
2.冒烟测试用例设计:
分析系统主要功能和业务流程,编写覆盖这些功能的正向测试用例,推荐使用正交表,运用正交法制定一套测试用例。
如果没有用例就无法跟踪和掌握整个冒烟测试的重点,以及各个版本之间的冒烟对比。
冒烟测试用例应该随着系统的不断扩展而不断扩展,它不应该是一成不变的。
3.冒烟测试执行:
每个版本发布时,根据版本包含的功能特性,评估需要执行的冒烟测试用例
4.冒烟测试结果输出:
冒烟测试执行情况,通过的测试用例数,不通过的测试用例数,据此判断是否开始正式的测试。
5.冒烟测试清单整理
A.整理冒烟测试功能点,根据需求清单,发布清单整理本次版本所有的功能点,作为冒烟功能测试点
B.整理冒烟流程测试用例,根据系统流程,筛选能够覆盖大部分功能的流程作为冒烟测试场景
6.冒烟测试规则
A.冒烟测试时发现冒烟功能不通过,将缺陷提入缺陷管理工具跟踪管理。
B.冒烟测试功能点通过率低于60%时,召开干系人会议,发起退测流程,发起版本申请。
C.冒烟流程测试通过率低于70%时,召开干系人会议,发起退测流程,发起版本申请。
D.开发人员修复完冒烟测试所产生的问题后,重新发起版本送测申请,测试人员对送测版本重新进行冒烟测试
E.冒烟测试时间不得超过2-4个小时。
1.4.2测试要点
1.业务流的测试,保证正常业务链路的通畅
2.工作流的测试,主要是测试流程流转是否正常,至于流程步骤的内容是否正确则不关注。
3.关键功能的测试,至少要保证系统运转,以及一些正常功能实现。
4.重要基本功能的测试,比如对核心业务有影响的一些增删改等
1.4.3测试准入准出
●冒烟测试的入口准则
a)软件版本已经发布
b)冒烟测试计划和测试变更需求和用例通过评审
c)测试环境准备完毕
●冒烟测试的出口准则
a)发现的致命和严重类缺陷为0
b)所有必选测试场景的通过率=100%
c)随即抽取的可选测试场景通过率>80%
1.4.4冒烟测试自动化
冒烟测试可以手动执行,可以考虑自动化执行。
稳定的系统适合自动化冒烟测试,集成过程中的系统适合手工冒烟测试,因为冒烟测试内容在动态变化,变化中的自动化脚本维护工作量比较大。
自动化冒烟测试脚本应当遵循的原则
1.覆盖主要功能;
2.测试脚本要简单、易用和详细说明
3.测试脚本要独立
4.每个测试脚本要尽可能的独立
5.每个测试脚本覆盖的测试点要尽可能的单一
6.测试结果收集:
留存每一次的测试结果,对比一段时间内的测试结果,可以知道产品那些功能点质量不稳定,如果同一个测试点在一段时间内经常不能够测试通过,那么这一部分的代码十分有必要进行review,有可能存在更大的隐患。
1.5冒烟测试进阶
与开发人员协同工作
由于冒烟测试特别关注更改过的代码,因此必须与编写代码的开发人员协同工作。
必须了解以下内容:
1、代码中进行了什么更改。
若要理解该更改,必须理解使用的技术;开发人员可以提供相关说明。
2、更改对功能有何影响。
3、更改对各组件的依存关系有何影响。
在进行冒烟测试前检查代码
在运行冒烟测试前,进行侧重于代码中的所有更改的代码检查。
代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。
冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证,因为如果失败,测试就无法继续。
在干净的调试版本中安装私有二进制文件
由于冒烟测试必须侧重于仅对更新后的二进制文件中的功能更改进行验证,所以必须通过使用被测试文件的调试二进制文件来使测试在干净的测试环境中运行。
注意:
在冒烟测试中,使用不匹配的二进制文件进行测试是一个常见错误。
为了避免此错误,当两个或多个更新后的二进制文件之间存在依赖项时,请在测试版本中包括所有更新后的二进制文件。
否则,测试的结果可能无效。
2.SIT测试规范
2.1SIT测试的定义
SystemIntegrateTest的缩写,即系统整合测试
系统整合测试就是评估产品在其规格范围内的环境下工作,能否完成产品设计规格所需要的功能及与周边设备、应用软件的兼容性。
大致可以分为硬、软件兼容性测试,认证测试。
安装Win/Linux/Unix这些只是系统整合测试的一小部分硬件测试:
所有产品的周边设备,例如CPU、DIMM、storage、NIC、USB等软件测试:
操作系统的安装,驱动的安装,以及配套应用软件的安装及使用等认证测试:
Windows、RedHat、VMWare等。
2.2SIT测试主要内容
2.2.1功能测试
需求验证,恢复性测试(灾难测试,容错测试),接口测试,安装/升级测试,配置测试/兼容性测试,国际化测试,用户文档测试等等
2.2.2非功能测试
性能测试,安全测试,易用性测试,冒烟测试,回归测试,随机测试,硬件系统专有测试(可靠性测试,可生产性测试,可维护性测试)
2.2.3测试方法介绍
2.2.3.1配置测试/兼容性测试
主要包括组网测试和软硬件平台配置测试
组网测试的目的是测试系统是否满足其需求中所支持的所有组网类型和组网规模
软硬件平台配置测试的目的是测试系统是否满足其需求中所支持的不同软硬件平台配置
兼容性测试是指系统适应能力测试,可分为环境兼容性测试和版本兼容性测试
2.2.3.2性能测试
为了验证系统是否达到用户提出的性能指标,同时发现系统中存在的性能瓶颈,起到优化系统的目的
在正常,峰值以及异常负载条件下,测试系统的各项性能指标
2.2.3.3安全性测试
安全测试就是检查系统对外部的非法侵入的抵御能力。
系统安全测试的准则是,测试非法侵入的代价是否超过被保护信息的价值
信息安全与保密不同于人身安全和重大财产损失
在公司的产品研发中,需要重点考虑的是信息安全方面
随着ISO14000/18000的实施,这方面的内容会增多
安全测试主要关注点
主要方法:
1.SQL注入测试
2.权限测试
3.脚本注入测试
4.跨目录测试
5.隐通道测试
常见故障:
1.系统缓冲区溢出,堆栈溢出错误。
2.系统存在密码安全,权限管理,数据安全方面的漏洞,可被轻易的进入并进行非法获取和破坏。
2.2.3.4恢复性测试
检查系统的容错能力,测试系统在遇到系统奔溃,硬件损坏或其他灾难性问题后能否很好的恢复,测试的具体内容包括创建各种可能的灾难状况,测试系统从异常状态恢复到正常状态所需的时间,花费的代价,对周边设备和系统造成的影响,系统恢复的完整性和一致性等
常用的方法
主要是制造系统异常,按系统恢复功能进行恢复操作,直至系统继续正常运行
为了测试系统恢复之后是否运行正常,也可以采用一些自动化测试工具进行回归测试,以提高测试的效率。
常见故障:
1.系统发生异常后无法恢复,造成系统数据被破坏,即重启系统,恢复备份数据也不可行,2.严重的可能造成系统硬件故障
3.系统恢复时间过长,代价过高
4.系统不能完全恢复到原来的正常状态,造成一定损失
5.系统恢复过程对周边设备和环境造成较大影响,无法消除等
2.2.3.5易用性测试
对用户体验度的关注度提高,每个系统上线后产生的事件数作为了易用性评判的主要依据
以用户的角度来对软件界面的易用性,风格,合理性等方面进行评估和测试,通常包括软件的‘界面显示测试’和‘界面功能测试’而界面功能测试主要结合系统功能进行测试。
测试要点和常见的故障
易用性与合理性:
步骤繁琐的操作,比例不协调,摆放凌乱的窗口和控件,层次过多的子窗口和菜单
规范性:
不符合Windows规范的控件设计,与常规Windows操作不符的流程与操作等
容错性:
编辑控件对非法字符,超出边界值的输入处理不当或没有提示,容易造成系统重启,数据删除丢失等的操作没有提示等
帮助:
无帮助信息提供,或者不提供获取帮助的快捷操作
美观与风格:
界面颜色不协调,界面风格与公司相关产品风格不符,与业界通用风格不符,图片,图标等不符合公司UI规范
资源:
界面长时间运行操作造成系统内存耗尽,界面对系统资源独占使用等
2.2.3.6安装升级测试
安装升级测试是以最终用户的角度测试系统的可安装性以及系统是否具有升级或者卸载功能,安装升级测试,需要重点测试系统的软硬件平台的兼容性
主要内容:
1.安装升级基本功能测试
2.卸载测试(可选)
3.平台兼容性测试
4.易用性与合理性测试
5.健壮性测试
常用工具
通常手工进行,可借助录制回放工具进行反复的软件安装测试
常见故障
1.系统的软硬件不能兼容
2.系统软件在不同的平台下安装后不能正常工作
3.系统版本升级后,无法正常工作,系统无法回退到升级前的版本
4.系统的硬件安装不符合用户习惯
5.系统的软硬件安装升级过程和用户文档的叙述不一致,甚至错误,误导最终用户
2.2.3.7文档/帮助测试
各种用户文档和联机帮助系统是软件产品的重要组成部分,保证其正确性也是软件测试工程师的职责,文档/帮助测试的目的在于:
1.提高易用性,使软件用户更容易地学习和使用软件产品
2.提高可靠性,如果用户阅读文档,然后使用软件,最终得不到预期结果,这就是可靠性差
3.降低支持费用,好的文档/帮助通过恰当的解释和引导可以在用户有麻烦或者遇到意外情况时减少请求公司帮助
从用户的角度来测试软件文档是非常有效的方法,仔细阅读,跟随每个步骤,检查每个图形,尝试每个示例,利用这个现实的简单方法,可以找出软件和文档中的缺陷,常用的方法有:
1.评审和审查,检查文档的编辑清晰性
2.动态测试,结合实际程序的使用而使用文档
3.让独立的第三方(如用户)或其他人员(如以前没有接触或者使用过本系统的新手)在程序的使用语境测试文档也十分有效的方法
2.2.3.8随机测试
俗称猴子测试
最好由用户代表进行
公司内部可结合新员工/工程/客服人员培训进行
应该有适当的组织和计划
2.3SIT测试过程
2.3.1项目周期中的SIT测试阶段划分
SIT测试计划阶段
SIT测试设计和编码阶段
SIT测试执行和评估阶段
2.3.2SIT测试计划阶段主要活动
制定SIT测试总体计划
●简述项目,明确测试的范围
●定义测试策略(阶段,类型,技术,标准等)
●编制测试需求
●工作分解和估算
●资源分配
●进度表
●风险识别与应对
SIT测试总体计划评审
批准SIT测试总体计划
系统测试总体计划纳入配置管理
2.3.3SIT测试设计阶段主要活动
SIT测试设计阶段与执行阶段常见的风险
不做测试设计,或者测试过程并未按照SIT测试总体计划的要求来做
测试设计不详细,不是基于可度量的测试策略,例如测试计划覆盖一个集合或者测试需求的一个子集
测试过程没有检验测试需求
测试总体计划中测试策略没有对应性
测试过程不可重复或者不可重用
SIT测试设计和执行阶段度量
需求覆盖率(百分比)=测试覆盖的需求/所有需求*100%
测试用例的数量(条)
自动化测试在SIT测试中的比例(百分比)=采用自动化测试的SIT测试用例数目/全部的测试用例数目*100%
测试用例设计和开发的工作量(人时)
SIT测试文档评审工作量(人时)
2.3.4SIT测试执行和评估阶段主要活动
SIT测试执行阶段与评估阶段常见风险
没有制定系统测试详细计划,测试开始之前测试人员不能明确本次SIT测试活动应测试的测试用例
测试执行不按照SIT测试详细计划的要求来做,不能确保计划要求的测试用例都能的到执行
未对测试的原始数据进行记录
本次SIT测试新的有效测试规程和测试用例并未及时的给予记录和管理
项目组和产品组的压力有可能导致测试人员的测试评估不够客观准确
没有有效利用各种自动化测试手段,手工测试太多。
SIT测试执行和评估阶段常用度量
测试用例通过率(百分比)=本次测试中通过的用例数/实际执行的用例数
测试用例覆盖率(百分比)=本次测试中实际执行的用例数/计划执行的用例数
本次测试中测试通过的SIT测试用例数目
本次测试中测试不通过的SIT测试用例数目
已发现的缺陷数目以及缺陷严重级别
已经解决的缺陷数目以及缺陷等级
遗留的缺陷数目以及缺陷等级
缺陷密度(分布图)
测试工时
SIT测试的需求覆盖率
SIT测试的若干原则
应尽早地开始SIT测试工作
充分注意测试中的缺陷密集现象,即对缺陷比较密集的部分进行重点测试
严格执行测试计划,排除测试的随意性
对测试过程和测试结果进行评价,确保测试过程的有效性
妥善保存测试计划,测试用例,故障统计和最终分析报告,为维护提供方便
对于被测系统要进行正常和异常两方面的测试
在系统测试计划中,要按照资源和项目的要求清晰的定义一个完整的退出准侧,这是一种权衡投入/产出比的原则,测试即不要不充分,也不要过分
2.4SIT准入准出标准
SIT准入标准
系统功能开发完毕,开发部门完成单元测试,保证系统的功能已经实现。
开发部门提供测试版本,并提供相关的版本说明,对发布版本的情况进行概要说明。
系统的单元测试已经完成,并提供单元测试报告。
系统的功能测试已经完成,并提供功能测试报告。
提供独立的SIT测试环境,保证被测版本可以正常运行。
测试版本在SIT测试环境进行连通性测试,确保系统的重要模块以及重要功能点是可以正常运行的。
提供SIT相关测试数据。
在保证系统的单元测试和功能测试已经通过后,再进入系统集成测试(SIT)阶段。
SIT准出标准
最后测试的系统版本沒有严重級別较高的缺陷出現
最后发布的几个测试版本,发现的功能缺陷数量沒有上升趋势
最后测试的系统版本的缺陷数量控制在一定的范围內。
新增功能缺陷少于已有缺陷的千分之二,reopen率少于百分之五(建议)
所有严重級別为Falat、High的缺陷都已经关闭,95%的功能缺陷已经关闭。
最后测试的系统版本发现的缺陷是经過业务(实施)部门确认容许存在
3.UAT测试规范
UAT(User Acceptance Test),用户验收测试,或用户可接受测试,系统开发生命周期方
法论的一个阶段,这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。
它让系统用户决定是否接收系统。
它是一项确定产品是否能够满足合同或用户所规定需求的测试。
这是管理性和防御性控制。
3.1UAT测试目的
本阶段测试是为了测试开发出来的产品是否能够满足用户的需求,因为只有用户实际使用了产品,根据实际体验才能知道产品是否能满足要求。
同时也是为了找出在实际环境中可能出现的一些Bug,并及时修复
3.2UAT测试参与人员
UAT测试顾名思义可以知道测试的主体应该是实际客户,本阶段的测试需要客户直接参与,因为研发、测试甚至PM都不能准备的了解客户实际环境下如何使用产品,所有本阶段的测试参与者主要是实际客户
3.3UAT测试用例
UAT的用例原则上来讲应该是用户自行按照实际使用来设计,但考虑到客户对新系统的不熟悉,可以采用测试人员设计用例,邀请实际客户参与评审的方式来设计用例。
3.4UAT测试范围
测试应该包含安装、环境部署、各个子模块的基本功能等系统一个完成过程中的所有部分(也包含用户手册),同时应该根据用户实际使用环境着重测试客户使用频率高的模块,尽可能将用户常用模块中可能隐藏着的问题发现出来并修改。
3.5UAT测试前提
UAT需要满足一定的条件才能开始,进行UAT的产品理论上来说,必须已经全部开发、测试完毕,代码状态处于冻结状态, 所有测试出来的bug都已经被妥善处理,重大的bug都被解决,并验证通过。
对于一些低级别 bug ,要么决定被写入发布公告中,要么被设置为不需要修改的问题。
在实际项目操作过程中,由于计划进度原因达不到理论状态前提,UAT的效果也达不到应有的效果。
3.6UAT测试策略
UAT测试理论上是用户按照使用手册进行操作,或者安排组织客户培训后让用户操作。
测试过程应该有用户独立完成各个步骤,根据用户要求可以安排研发或测试的人员陪同测试,既能在过程中起到指导帮助作用,也能在测试发现Bug的时候做第一时间的调查分析。
3.7UAT测试通过条件
●成功地执行了测试计划中规定的测试用例;修正了所发现的功能性错误;
●用户肯定测试结果,并通过了专门小组的评审,评审人员应该包含客户、产品经理、项目经理、研发负责人、测试负责人等。
●最后用户在确认书上签字认可测试结果,确认产品能够满足客户需求。
3.8UAT的测试难点以及建议
难点
1. 用例设计无法有限覆盖实际环境:
很多时候UAT测试用例仍然是由测试人员甚至是开发人员设计,他们并不能真正的了解真实客户更多的需求,也无法完全知道用户的真实使用环境,所以设计出来的UAT用例很多时候仍然是系统测试级的用例。
2. 客户对系统不熟悉:
客户在实际测试的时候或多或少还是存在着对系统不熟悉的情况,测试效率不高,进度比较慢;再者很多时候客户不愿意安排人员来进行UAT测试,UAT测试实际上仍然是测试人员完成,由于使用习惯和思维惯性,使得潜在的问题不易发现,造成问题遗漏。
3. 认为UAT可有可无:
因为进入到此阶段本身就意味着开发和测试进入到后期,已经完成了系统测试,认为已经完成了系统测试,系统就没有大的问题,UAT可以不开展了,这样节约系统上线时间,早日带来价值
建议
1.尝试在开发的过程中邀请客户参与,尤其是当重要功能集成好后,应该立即邀请客户参与到测试中来,即可让用户尽早熟悉系统,对产品有一个初步的认识,又可以在用户体验后及时了解用户的需求更新(如易用性),并落实更改。
2. 坚持UAT测试,因为用户在使用系统的时候是为了完成真实任务和工作,是最真实的使用环境和真实的数据,真实环境的真实数据得到的测试结果最真实可靠;同时也能有效的避免研发和测试人员在前期形成的定式思维。
从而能更有效的发现潜在问题。
3. UAT测试一般来讲是上线前最后一次需求确认的机会,一旦系统推广上线后再
发现某些需求不满足或者实现出现了偏差,修改和维护的成本大幅提高,造成时间和费用的双重消耗
4.预发布环境测试规范
4.1预发布定义
预发布指SIT测试,UAT测试通过后,版本发布上线前,在指定环境上,进行冒烟测试,通过后预发布流程结束,这个过程中所要遵循的流程规范。
其中涉及项目经理(版本负责人)、开发主管、测试主管以及配置管理员、QA这5个角色。
4.2角色与职责
项目经理
1.启动版本预发布流程的决策者。
2.版本配套文档清单的检查者。
3.分支打包的执行者。
配置管理员
1. 版本控制和发布环节的协调人。
2. 获取发布版本,负责项目版本配套文件的收集及归档。
3. 测试版本的提供者。
开发主管
1. 与版本相关的输出物清单的提供者;
2. 安装配置手册、迭代版本说明的提供者;
测试主管
1.与开发主管配合执行冒烟测试并使之通过
QA
1.检查项目版本控制及发布流程的规范性。
2.检查项目版本配套文件清单的完整性。
4.3版本预发布工作流程图
4.4预发布流程描述
4.4.1预发布流程进入条件
测试完成SIT测试以及UAT测试,准备进行版本发布上线的一次测试.
4.4.2预发布流程结束条件
预发布环境冒烟测试通过
4.4.3预发布流程步骤
1.预发布环境准备
项目通过开发部内部集成测试后,开发主管通知项目经理代码具备提交测试部测试的条件
1)项目在Jenkins上持续测试通过,内部禅道中的Bug清理完毕(项目经理允许保留的除外)
2)开发主管提交输出物清单,并在清单中标注输出物在SVN上的存储路径(配置文件、数据库脚本、部署所需的文件夹(路径结构)、相关工具等等,程序安装
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 平台 功能 测试 规范