测试基础习题答案.docx
- 文档编号:28969329
- 上传时间:2023-07-20
- 格式:DOCX
- 页数:24
- 大小:136.72KB
测试基础习题答案.docx
《测试基础习题答案.docx》由会员分享,可在线阅读,更多相关《测试基础习题答案.docx(24页珍藏版)》请在冰豆网上搜索。
测试基础习题答案
测试基础习题答案
测试基础习题答案
一、填空题
1、软件测试的定义:
软件测试是贯穿整个软件开发生命周期、对软件产品(包括阶段性产品)进行验证和确认的活动过程,其目的是尽快尽早地发现在软件产品中所存在的各种问题。
2、软件测试的狭义论和广义论——静态和动态的测试。
软件测试的辨证论——正向思维和反向思维。
软件测试的风险论——测试是评估,软件测试的经济学观点——为盈利而测试,软件测试的标准论——验证和确认。
3、Spec中英问意思是:
SystemPerformanceEvaluationCorporation,系统性能评估测试
4、验证过程提供证据表明软件相关产品与所有生命周期活动的要求(如正确性、完整性、一致性、准确性等)相一致
5、从标准论来看软件测试,可以定义为软件测试就是“验证(Verification)”和“有效性确认(Validation)”活动构成的整体,即软件测试=V&V。
6、V模型指出,单元和集成测试应检测程序的执行是否满足软件设计的要求;系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标;验收测试确定软件的实现是否满足用户需要或合同的要求。
7、螺旋模型的每一次迭代都包含了以下六个步骤1.决定目标,替代方案和约束2.识别和解决项目的风险3.评估技术方案和替代解决方案4.开发本次迭代的交付物和验证迭代产出的正确性.5.计划下一次迭代6.提交下一次迭代的步骤和方案.
8、测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具
9、什么是软件缺陷:
1. 软件未达到产品说明书标明的功能。
2. 软件出现了产品说明书指明不会出现的错误。
3. 软件功能超出产品说明书指明范围。
4. 软件未达到产品说明书虽未指出但应达到的目标。
5. 软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好
10、缺陷的分类:
文档缺陷、代码缺陷、测试缺陷、三过程缺陷
11、对于缺陷的严重性,可以分为:
非常严重的缺陷、较严重的缺陷、软件一般缺陷、软件界面的细微缺陷
12、缺陷的分类:
代码类缺陷、文档类缺陷
13、缺陷产生的原因:
需求存在问题、设计问题、代码问题、测试人员的错误
14、软件测试的目标:
尽量多的发现缺陷、尽早发现缺陷、预防
15、软件测试的作用是:
找出软件中存在的问题、协助开发人员定位缺陷、预防缺陷的产生
16、常见的软件生命周期模型有:
瀑布模型、RUP模型、W模型等
17、测试工具的优点有:
高效、可重复
18、测试工具的缺点有:
技术要求高、实现难度大、成本高、不能很好的适应变更
19、软件测试的目标:
发现缺陷、尽早发现缺陷、预防缺陷的产生
20、瀑布模型的生命周期为:
需求分析、概要设计、详细设计、编码和测试
21、RUP模型的全称为:
rationalunifiedprocess.
22、RUP模型的阶段分为:
初始化阶段、细化阶段、构造阶段和发布阶段
二、判断题
(×)1、好的测试员不懈追求完美。
(×)2、测试程序仅仅按预期方式运行就行了。
(×)3、不存在质量很高但可靠性很差的产品。
(×)4、软件测试员可以对产品说明书进行测试。
(×)5、可以发布具有配置缺陷的软件产品。
(×)6、所有软件必须进行某种程度的兼容性测试。
(×)7、所有软件都有一个用户界面,因此必须测试易用性。
(×)8、测试组负责软件质量。
(×)9、测试人员可以提高软件质量。
(×)10、开发人员可以进行自测就可以了,不需要测试参与。
(×)11、测试人员只需要发现缺陷就可以了
(×)12、测试人员不能只发现缺陷,还要负责修复缺陷。
(×)13、开发人员不需要对产品进行测试,只负责修改缺陷既可。
(√)14、测试人员要协助开发人员确认缺陷的产生原因。
(√)15、测试人员提出缺陷后,要对缺陷进行定位。
(×)16、缺陷的分为三类:
文档缺陷、代码缺陷、三过程缺陷。
(√)17、代码缺陷:
是指对代码进行同行评审、审计或代码走查过程中发现的缺陷;
(√)18、缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
(√)19、静态测试工具:
直接对代码进行分析,不需要运行代码,也不需要对代码编译链接,生成可执行文件。
(√)20、软件测试就是“验证(Verification)”和“有效性确认(Validation)”活动构成的整体
(×)21、有效实施配置管理,不需要组织架构上的支持活动
(√)22、程序测试是为了发现错误而执行程序的过程
(×)23、发现缺陷数最多的测试人员就是最优秀的测试人员
(×)24、测试人员必须具有开发技术
(×)25、测试人员和开发人员的矛盾是不可调和的
(√)26、测试人员应该与开发人员定期沟通和学习
(√)27、测试人员应该协助开发人员尽快定位问题
(×)28、在开发的早期没有必要介入测试
(×)29、测试越到后期发现缺陷越困难
(×)30、测试越到后期缺陷修复成本越低
(×)31、测试人员技术水平的高低决定了软件质量的优劣
(×)32、如果公司中有了测试部门,开发人员就不需要进行自测了,因为没有必要
(×)33、自动化测试能够比手工测试发现更多的缺陷
(√)34、自动化测试比手工测试的效率更高,所以要大量开展自动化测试
(√)35、自动化测试必须借助测试工作才能完成
(×)36、自动化测试能够发现手工测试发现不了的问题
(×)37、瀑布模型适合于大规模的公司
(×)38、RUP模型适合于小规模的项目
(√)39、瀑布模型适合于小规模的公司,对于较成熟的产品比较适用
(√)40、RUP模型适合于大规模关联关系较松散的项目。
(×)41、越严重的缺陷应该越早修复
(×)42、越严重的缺陷应该越晚修复
(×)43、缺陷程度越高的缺陷,修复优先级也应该越高
(√)44、一般而言缺陷程度较高的缺陷,修复优先级越高,但也有特例
(×)45、测试工程师不会犯错误,只有开发工程师会犯错
(×)46、软件开发完成后进行软件测试
(×)47、使用测试工具,就是进行了有效的测试
(√)48、测试工程师的发展方向有两种,一个是技术方向,另一个是管理方向
(√)49、软件发布后如果发现质量问题,那是软件测试人员的错
(×)50、软件测试要求不高,随便找个人多都行
(×)51、软件自动测试效率高,将取代软件手工测试
(×)52、软件测试是测试人员的事情,与程序员无关
(×)53、项目进度吃紧时少做些测试,时间富裕时多做测试
(×)54、软件测试是没有前途的工作,只有程序员才是软件高手
(×)55、需求-实现-测试,软件测试是开发后期的一个阶段;
(×)56、软件测试对技术要求不高,至少比编程容易得多。
(×)57、测试代码可以随意写
(×)58、测试只要证明软件正确就可以了。
(×)59、测试是枯燥无味的,是缺乏创造力的。
(×)60、存在太多的无法测试的东西
(×)61、自动化测试是万能的。
(×)62、如果软件最后出了问题,肯定都是测试的问题
三、简答题
1、缺陷的严重程度和优先级如何划分?
缺陷的严重程度和优先级通常可按级别划分,各个公司对不同项目的具体表示方式有所不同,具体的级别划分需要软件测试前达成一致。
常用的缺陷严重程度可分为:
致命、严重、一般、较小。
致命是指系统任何一个主要功能完全丧失,或用户数据受到破坏,造成系统崩溃、悬挂、死机或者危机人身安全;严重是指系统的主要功能部分丧失,或数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响;一般是指系统的次要功能没有完全实现,但不影响用户的正常使用;较小是指使操作者不方便或遇到麻烦,但它不影响功能的操作和执行的一些小问题。
常用的缺陷的优先级表示方法可分为:
立即解决、高优先级、正常排队、低优先级。
立即解决是指缺陷导致系统几乎不能使用或者测试不能继续,需立即修复;高优先级是指缺陷严重影响测试,需要优先考虑;正常排队是指缺陷需要正常排队等待修复;而低优先级是指缺陷可以在开发人员有时间的时候再被纠正。
2、缺陷的分类有哪些?
新项目可以从基线提供的定点之中建立。
作为一个单独分支,新项目将与随后对原始项目(在主要分支上)所进行的变更进行隔离。
各开发人员可以将建有基线的构件作为他在隔离的私有工作区中进行更新的基础。
当认为更新不稳定或不可信时,基线为团队提供一种取消变更的方法。
可以利用基线重新建立基于某个特定发布版本的配置,这样也可以重现已报告的错误。
3、在一个团队中为什么要提出软件测试岗位?
1、软件的缺陷等级应如何划分?
(3分)
2、如果能够执行完美的黑盒测试,还需要进行白盒测试吗?
为什么?
(5分)
3、你认为一个优秀的测试工程师应该具备哪些素质?
(3分)
4、产品测试到什么时候就算是足够了?
(2分)
5、测试计划的目的是什么?
(2分)
6、为什么要进行软件测试?
软件测试的目的是什么?
(5分)
7、软件测试应该划分几个阶段?
简述各个阶段应重点测试的点?
各个阶段的含义?
(5分)
8、如何做一名合格的测试人员?
(3分)
9、针对缺陷采取怎样的管理措施?
(5分)
4、测试工程师的工作内容有哪些?
A.规格说明的状态;
B.修改建议的状态;
C.修改批准的报告;
D.产品版本或其修改版的状态;
E.安装、更新或交付的实现报告;
F.用户提供的产品(如操作系统)的状态;
G.有关开发项目历史的报告。
5、测试工程师应该具备哪些技能?
1.熟练掌握软件测试理论和流程、制定测试计划、编写测试策略、测试用例、执行测试,能从多角度发现BUG,以及熟悉BUG的处理流程和对结果进行分析;
2.能够运用多种方法来编写测试用例,如:
等价类划分、边界值、因果图、判定表、业务逻辑流程图、状态迁移图、结果输出域、正交矩阵等;
3.能够熟练掌握一种或几种编程语言,如:
C/C++、JAVA,脚本语言:
VBscrīpt/Javascrīpt、Shell编程;
4.能够熟练掌握一种或几种测试工具,如:
QTP、LoadRunner等,测试管理工具:
QuailtyCenter,还有一些BUG管理工具:
Bugzilla、BugFree、JIRA等;
5.最好是能够掌握性能测试:
如非常熟悉LoadRunner的性能测试流程,比如制定性能测试计划、录制和编辑脚本、场景设计、运行并监控场景、对结果的分析并发现系统的瓶颈;
6.懂开发,并且要对一些主流的开发框架比较熟悉,如:
J2EE;
7.熟悉常用的应用服务器,如:
Weblogic、Tomcat等;
8.熟悉常用的操作系统,如:
Windows系列、Linux,并熟悉Linux下的主要查询命令;
9.熟悉一种或几种数据库,如:
Oracle、SqlServer、MySql等,能够熟练编写常用的SQl语句,掌握存储过程和触发器等,最好是能够对数据库进行调优;
10.要有缺陷预防的意识,因为缺陷越发现的早越好,这个主要是看个人的天赋,有些人天生下来大脑的敏感性比较强,他能够一开始觉察到未来会出现什么风险,如果没有这种天赋,那就只有依靠自己的经验来判断;
11.英语要好,要有比较好的听、说、读、写能力。
6、测试工程师应该具备哪些职业素质
人是测试工作中最有价值也是最重要的资源,没有一个合格的、积极的测试小组,测试就不可能实现。
然而,在软件开发产业中有一种非常普遍习惯,那就是让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作。
这绝对是一种目光短浅的行为,对一个系统进行有效的测试所需要的技能绝对不比进行软件开发需要的少,事实上,测试者将获得极其广泛的经验,他们将遇到许多开发者不可能遇到的问题。
1、沟通能力
一名理想的测试者必须能够同测试涉及到的所有人进行沟通,具有与技术(开发者)和非技术人员(客户,管理人员)的交流能力。
既要可以和用户谈得来,又能同开发人员说得上话,不幸的是这两类人没有共同语言。
和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。
而和开发者谈相同的信息时,就必须将这些活重新组织以另一种方式表达出来,测试小组的成员必须能够同等地同用户和开发者沟通。
2、移情能力
和系统开发有关的所有人员都处在一种既关心又担心的状态之中。
用户担心将来使用一个不符合自己要求的系统,开发者则担心由于系统要求不正确而使他不得不重新开发整个系统,管理部门则担心这个系统突然崩溃而使它的声誉受损。
测试者必须和每一类人打交道,因此需要测试小组的成员对他们每个人都具有足够的理解和同情,具备了这种能力可以将测试人员与相关人员之间的冲突和对抗减少到最低程度。
3、技术能力
就总体言,开发人员对那些不懂技术的人持一种轻视的态度。
一旦测试小组的某个成员作出了一个错误的断定,那么他们的可信度就会立刻被传扬了出去。
一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。
要做到这一点需要有几年以上的编程经验,前期的开发经验可以帮助对软件开发过程有较深入的理解,从开发人员的角度正确的评价测试者,简化自动测试工具编程的学习曲线。
4、自信心
开发者指责测试者出了错是常有的事,测试者必须对自己的观点有足够的自信心。
如果容许别人对自己指东指西,就不能完成什么更多的事情了。
5、外交能力
当你告诉某人他出了错时,就必须使用一些外交方法。
机智老练和外交手法有助于维护与开发人员的协作关系,测试者在告诉开发者他的软件有错误时,也同样需要一定的外交手腕。
如果采取的方法过于强硬,对测试者来说,在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。
6、幽默感
在遇到狡辩的情况下,一个幽默的批评将是很有帮助的。
7、很强的记忆力
一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来,这一能力在测试过程中的价值是无法衡量的。
因为许多新出现的问题和我们已经发现的问题相差无几。
8、耐心
一些质量保证工作需要难以置信的耐心。
有时你需要花费惊人的时间去分离、识别和分派一个错误。
这个工作是那些坐不住的人无法完成的。
9、怀疑精神
可以预料,开发者会尽他们最大的努力将所有的错误解释过去。
测式者必须听每个人的说明,但他必须保持怀疑直到他自己看过以后。
10、自我督促
干测试工作很容易使你变得懒散。
只有那些具有自我督促能力的人才能够使自己每天正常地工作。
11、洞察力
一个好的测试工程师具有“测试是为了破坏”的观点,捕获用户观点的能力,强烈的质量追求,对细节的关注能力。
应用的高风险区的判断能力以便将有限的测试针对重点环节。
7、测试工程师能创造什么价值?
近两年国内IT业对软件测试的重视程度较几年有了很大的提升,但由于历史和现实的原因,软件测试人员在公司内部的受重视程度远不如软件开发人员;
软件测试的价值体现很隐蔽,它属于产品质量把关的工作,本身不直接产生经济效益,由于软件测试的价值体现没有软件开发人员明显,很多企业的领导对软件测试的认识还停留在很肤浅的阶段上;所以在国内的一些软件公司直接就省略掉了软件测试这个环节,或者在软件产品测试方面投入的人力物力比较薄弱,造成产品交付客户使用后,产品本身所带的缺陷和不稳定性为后期的产品质量维护造成了很大的压力和挑战。
如何根据软件企业的特点和规划组建一支有效的测试团队,实现软件测试投入产出比的最大化,在一定的程度上体现软件测试的发展和价值;软件测试是检验软件产品是否满足软件用户需求规格,是发现软件缺陷的有效手段。
软件产品质量是企业的生命,如何保障产品质量是软件测试人员的主要责任,软件测试工作不能保证产品没有缺陷,但可以通过自己的努力确保将产品缺陷率降到最低化。
软件测试是软件工程中必不可少的一个环节,存在就是价值,就有它存在的必要性,虽然在现阶段软件测试在公司内的地位和受重视程度不如开发人员,相信在软件技术日益发展的今天,质量的重要性会越来越受到公司领导的重视,因为产品是服务于客户,客户对产品质量的稳定性要求越来越严格,软件测试的价值也会越来越得到认可。
8、测试工程师如何和开发人员做好沟通?
测试工程师和开发工程师承担的是开发工作的两个不同方面,说得极端一点,一个是创建,一个是破坏,虽然两者的最终目的都是一样的,但在达成目标的方式上却有很大的差异。
因此,在为同一个目标奋斗的过程中,发生冲突也是难免的,但通过下面的一些建议,换个视角看看开发人员的生活和工作,可能很多的冲突就能化解于无形了。
最好的测试人员不是发现最多BUG或是使得最多开发人员不自在的人,而是能够[说服开发人员]修正最多BUG的人),建议大家好好理解这句话。
和开发人员交流的经验归结为
1、要耐心和细心
细心是测试工程师的一个基本素质,测试工程师是对质量负责的人,涉及到质量问题,就不能含糊,因此一定要细心,细心对待每一个可能的BUG、细心对待每一段被你检查的代码,细心对待每一个你撰写的BUG报告,细心对待你发出的每一封邮件。
细心是一种态度,你的态度迟早会感染和你合作的开发人员,而这往往是合作愉快的基础。
2、要懂得尊重对方
开发是一件需要全面和综合考虑的工作,开发工作中,由于各种原因导致程序中出现问题是很正常的现象,作为测试工程师,发现了这些问题并不值得你夸耀,也不能说明你比开发工程师聪明。
一个好的测试工程师一定是懂得尊重开发工程师的人,尊重对方的技术水平,尊重对方的代码。
我接触过的开发人员都是挺和善的,一般来说,对他们最大的尊重就是承认他的专业水平,承认他的代码。
对他们来说,代码就像是自己的孩子一样,因此,记得在合适的时候表达你对他的尊重,赞扬一下他代码的精妙之处。
3、要能设身处地为对方着想
开发工程师一般都处在较大的工作压力下,他的上司直接考核他们的指标很大程度上是已完成的代码,所以在工作任务紧张的时候,对于测试工程师报上来的BUG会拖延解决甚至是推脱,给测试工程师的感觉就是很不合作。
那么在这个时候,就需要设身处地的为对方着想了,每个人都会为自己的工作在内心排定优先级,如果他认为解决你发现的BUG不是重要的事情,那么最大的可能就是你并没有向他解释清楚这个BUG的严重程度。
发现BUG是我们的责任,敦促BUG得到解决是我们更重要的责任,因此,我们可以心平气和地和开发人员坐下来讨论一下BUG的严重程度,和他一起排定BUG的优先级别并确定解决的时间。
4、要有原则
不要忘记,测试工程师需要对产品的质量负责,在这一点上一定要有原则。
测试工程师可以和开发工程师建立良好的个人关系,但在具体的事情上,一定要按照公司的相关流程来处理。
当然,在坚持原则的同时,可以采用一些委婉的表达方式,可以在允许的情况下尽量体谅开发工程师,但请记住,一个有原则的测试工程师才能真正帮助开发工程师,才能赢得开发工程师的尊重。
5、要主动承担
如果开发工程师要求你承担部分不属于你的责任,比如,定位你发现的BUG到代码一级,或者是帮助他编写部分文档和代码,在可能的情况下尽量多承担。
其实都是工作上的事情,有能力的话,多做一点也无妨。
9、软件测试工作的意义是什么?
随着软件应用领域越来越广泛,其质量的优劣也日益受到人们的重视。
软件测试是一个成熟软件企业的重要组成部分,它是软件生命周期中一项非常重要且非常复杂的工作,对软件可靠性保证具有极其重要的意义。
在软件测试过程中,应该应用各种软件测试方法,以保证产品有一个较高较稳定的质量。
根据不同的生产过程进行不同的测试,包括黑盒测试、白盒测试、功能测试、系统测试、压力测试、安装/卸载测试、兼容性测试、α测试、β测试等。
10、如何减少缺陷的产生?
1.在项目发布后发现和修复Bug的成本是需求和设计阶段所需的一百倍!
2.在时下的软件项目中大约有40-50%的人力都是花在可以避免的重复劳动中,避免重复劳动可以显著提高劳动生产率。
3.80%可避免的重复劳动源自于20%的缺陷,其中两大主要来源包括草率的需求定制和象征性的案例设计和开发。
4.大约80%的缺陷来自20%的模块,而约半数的模块是几乎没有缺陷。
5.90%的软件的停工期最多来自于10%的缺陷。
6.同行评审能发现60%的缺陷!
7.有针对性的评审能比无导向性的评审多发现35%的缺陷!
8.个人行为的规范化可以减少缺陷注入率高达75%。
9.在其他因素相同的情况下,开发高可靠性软件每源代码指令的成本投入比开发低可靠性软件要多出近50%。
然而,如果项目需要很高的运行和维护成本,这样的投资是值得的。
10.大约40-50%的用户程序都存在着很大的缺陷。
11、缺陷是如何产生的?
缺陷产生的根本原因可能是由以下方面引起的:
A.编程:
原始编程出错,没有客观原因。
B.修改:
由于修改缺陷而引发的新变更,并且引发的变更与原变更的错误是相关的。
C.培训:
项目组新成员培训不充分,或使用新工具不熟练引起的变更。
D.需求文档:
需求分析文档不明确、不详尽等原因所引起的变更。
E.信息交流:
信息交流不畅,开发成员间沟通不及时引起的变更。
F.外部问题:
所涉及软件模块外部问题引起的变更。
G.其他:
指以上各种原因之外所产生的变更。
H.软件发布后缺陷分析所用缺陷根本原因的的关键字,可以有下几种实例:
I.需求分析:
需求分析不足等原因所引起的变更。
J.系统设计:
软件系统设计种种原因所引起的变更。
K.程序编码:
软件开发阶段中编程错误所引起的变更。
L.维护:
软件发布后程序维护时引起的变更。
M.实施:
实施人员做软件初始化设置或系统参数设置不当等,实施时所引发的变更。
N.用户:
泛指用户不了解业务和软件、不熟悉操作等原因产生的异常问题。
O.数据异常:
运行中不明原因引起的用户数据混乱和异常。
P.升级:
软件版本升级过程发生的问题,包括用户在升级时未按规程操作产生的问题。
Q.外部问题:
所涉及软件外部问题引起的变更,包括属操作系统、数据库软件、第三方软件所引起的问题。
R.错误变更:
错误地提交的变更。
包括无法重现出错、所列现象不是错误的变更。
S.其他:
指以上各种原因之外的变更,包括变更原因不明。
T.测试情况信息项是应用于分析缺陷是如何通过测试关的。
可以有以下几种实例:
U.漏测试:
软件发布前测试时没有被发现的缺陷,也没有对应测试用例。
V.条件冷僻:
缺陷形成条件很冷僻,设计测试用例时很难考虑到。
W.回归测试:
专指那些原先测试时是通过的、不存在错误,后来由于修改其他程序时产生的缺陷。
关键是软件版本或补丁发布前未进行回归测试,因而被漏过。
X.判断标准:
测试时已发现该现象但当时不认为是问题,没提交变更。
Y.已测试:
测试时已发现缺陷并提交变更,但缺陷没解决。
12、软件缺陷的危害有哪些?
软件缺陷是软件开发过程中的副产品,通常缺陷会导致软件产品在某种程度上不能满足客户需求。
因此,妥善处理软件中的缺陷是关系到软件产品质量的根本。
可遗憾的是,并非所有的软件团队都知道如何有效地管理在测试中发现的缺陷。
对于软件测试人员而言,在测试中不能正确表示缺陷的严重程度和优先级,这将会影响到软件缺陷管理的质量,不仅不利于有效的处理软件缺陷,还可能影响到软件缺陷的处理时机。
特别在软件测试的后期,将影响软件是否能够按期发布与否。
近期我在一个测试项目中,由于对缺陷严重程度和优先级缺乏有效处理,最终导致软件验收发布被迫延后。
软件缺陷不只是通常所说程序中存在的错误或疏忽,即俗称的Bug。
其范围更大,除程序外还包括其相关产品:
项目计划、需求规格说明、设计文档、测试用例、用户手册等等中存在的错误和
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 基础 习题 答案