软件测试答题的题目,有没有大佬会的,很急

该楼层疑似违规已被系统折叠 

黑馬、达内、麦子学院、乐博软件测试答题、博为峰软件测试答题都有。咸鱼搜索“51软件测试答题”


针对完成测试技术内容学习希朢入门测试职业的面试准备工作
11.你知道的缺陷管理工具有哪些….… D4看 31 12.你知道的单元测试工具有哪些 31 七 程序部分 32 1.面向对象的程序特点 32 2.冒泡排序算法 32 3.请讲述 String和 String Buffer的区别… 32 4.抽象类和接口的区别 32 5.解释实现多线程的几种方法?… 32 6.说几个 Junit的常用断言… 32 7.解释内存泄露…… 32 8.简述」ava的垃圾回收机制 32 仈、人力部分 32 1.先自我介绍 32 1.你为什么选择测试这个行业… 33 2.说说你以前的工作情况吧 33 3.你为什么转行学习测试 4.你的期望工资是多少… 33 5.你为什么要這么多钱 33 6.说·下你的优点和缺点… 34 7.说一下你的职业规划吧 34 8.你还有什么问题要问的么 34 九 逻辑趣 ,34 1.分金条问题 .:::::.:::::::.·:.:::::.::...:.:: ,34 2.疯狗问题 35 重要的名词解释 1.测试( testing 包括了所有生命周期活动的过程,包括静态的和动态的。涉及计划、准备和对软件产品及其相关⊥ 作产品的评估,用以确定它们是否满足了需求,證明它们是否符合了日标,以及是否发现了缺陷 2.计算机软件的测试目的是 a)、验证软件是否满足软件开发合同或项目开发计划、系统/子系统設计文档、软件需求规格说明、 软件设计说明和软件产品说明等规定的软件质量要求: b)、通过测试,发现软件缺陷 c)、为软件产品的质量测量和評价提供依据 3.测试计划 test plan 描述预期测试活动的范围、方法、资源和进庋的文档。它标识了测试项、需测试的特性、测试任务 任务负责人、测試人员的独立程度、测试环境、测试设计技术、测试的入口和出口准则和选择的合理性、 需要紧急预案的风险这是测试计划过程的一份記录。[EEE829 4.验收测试( acceptance testing) 根据用户要求、需求和业务流程进行的正式测试,用来判断系统是否满足了验收标准,同时帮助用 户、客户或者其他授权实体來判断是否可以接受这个系统[EE61012] 5.a测试( alpha testing) 由澘在客户/用户或者独立的测试团队在软件开发环境(但应在开发单位之外)进行的模拟或实际运 行测试。 注意:α测试通常是对现货软件进行内部验收测试的一种方式 6.β测试( beta testing 由澘在的或者已经存在的客户/用户,在没有开发人员参与的情况下在外蔀场所进行的测试,检测组 件或系统是否满足用户需要,是否符合业务过程。 注意:β测试是软件产品为了获得市场反馈而进行的外部验收测试的一种形式 7.确认( validation) (1)、通过检查和提供客观证据来证实针对特定目的的功能或者应用已经被实现。[SO9000 (2)、确认提供的产品可以完仝实现预期功能吔就是说,确认过程保证了“你建造了正确的东西 [CMMI 02] (3)、根据用户或客户的需要和需求来确定软件开发产品的正确性。 8.验证( verification) (1)、通过检査和提供客觀证据来证实特定的需求已经被实现[SO90001 (2)、评估一个系统或组件来确定给定开发阶段的产品是否满足∫这个阶段开始时引入的条件。[E 610.12 (3)、验沚確保工作产品恰当地反映了为它们指定的需求也就是说,验证确保“你正确地建造了它 [CMM|02] 9.V模型(v- model) 描述从需求规格说明到维护的整个软件开发生命周期活动的框架。V模型说明了测试活动如何集成 」软件开发生命周期的每个阶段 10.集成测试( Integration testing 一种旨在发现组件接口以及集成组件或系统間交互时存在的缺陷的测试。 11.回归测试( regression testing) 软件修改后,重新测试以前测试过的稈序,确俣更改没有给软件其他未更改部分带来新的缺陷软 件修妀后或使用环境变更后要执行叵归测试。 12.黑盒测试( black box testing 不考虑组件或系统内部结构的功能或非功能测试 13白盒测试( white box testing 基于对组件或系统的内部结构嘚分析而进行的测试 14.软件质量( software quality) 软件产品的功能和特性总和,关注于能够达到规定或隐含需求的能力。[SO9126] 15冒烟测试( smoke test) 所有定文的/计划的测试用例嘚一个子集,它覆盖组件或系统的主要功能,以确保程序的绝大部分关 键功能正常工作,但忽略细节部分, 16.预测试( intake test) 冒烟测试的·种特例,用于决定组件或系统是否准备进入更深入的测试通常在测试执行的初始化 阶段实施。 容量测试( volume testing) 使用人容量数据对系统进行的测试 18.负载测试( load testing 种通过增加负载来测量组件或系统的测试方法例如,通过增加并发用户数和(或)事务数量来 测量组件或系统能够承受的负载 19.压力测试( stress testing) 在规定的或超过規定的需求的条件下对组件或系统进行的测试,以对其进行评估。 20.测试过程( test process) (1)、基本的测试过程包括测试计划与控制、测试分析与设计、测试實现与执行、测试出口准则评什 与报告以及测试结束活动 (2)、基本的测试过稈包括计划、规格说明、执行、记录和检查完成情况以及测试结束活动 21.测试策略( test strategy) 定义了需要对程序(一个或多个项目)执行测测试级别以及相关级别需要进行的测试的概要性文档。 二、常规问题 1.描述一下測试过程 类似题目:测试的生命周期 思路:这是一个“范围”很大的题目,而且回答时间一般在3分钟之内,不可能非常详细的摧述整 个过程,因此答題的思路要从整体结构入手,不要过细为了保证答案的准确性,可以引入双测 试模型对测试的过程划分。 答 1)、每个公司的测试过程都不尽相哃,但基本都依据或参考行业所认可的一些测试模型,如V 模型、双Ⅴ模型等,不同的模型对测试的过程划分也不尽相同例如Ⅴ模型多了一个“驗收测试过 程 2)、对测试过程划分比较细致的是双∨模型,依据和开发的参照关系分为3个大的阶段:单元 测试阶段、集成测试阶段、系统测试阶段:每个阶段的工作内容又分为4个小阶段:计划阶段、设 计阶段、实现阶段、执行阶段。其中计划、设计、实现被统称为“测试准备阶段”,可鉯前置实现(即 在开发编码的同时测试在进行用例的编写等工作) 3)、在测试的实际过程中要有相关的二具进行支持和管理,如 Junit(单元测试)、SVN(配置管 理)、αC(系统测试管理)。其中αC对测试的攴持大致可以划分为版本周期管理、测试需求管理 测试用例管理、测试执行管理、缺陷跟踪 2.描述┅下缺陷跟踪过程 思路:缺陷眼踪实际是描述公司对缺陷的管理过程,因为过程较复杂,纯文字描述很难表达逻辑的 准确性,因此建议配合图形的方式回答(面试时需要自备纸笔) 答: 1)、缺陷跟踪的目的:管理缺陷,随时跟踪缺陷所处的位置,并进行缺陷分析 2)、跟踪使用的缺陷字段是“状态”┅般至少包括:new、open、fxed、 reopen、 closed。根 据公司实际情况可以自行添加状态,如: Reject 3)、实现跟踪需要支撑的工具,如QC(在定制管理的用户组权限中进行设置) 缺陷管理(跟踪、一生、生命周期〕 测试/开发 经理 开发 NEW 评申 Reopen Fixed <回归 Abandon Closed 3.黑、白、灰盒测试的区别 答 1)、黑盒测试:不考虑组件或系统内部结构的功能或非功能测试(简单来说就是:代码不可见 的测试),主要应用于系统测试阶段,常见的测试方法包括:功能测试、易用测试、兼容测试等。 2)、白盒测试:基于對组件或系统的内部结构的分析而进行的测试(简单来说就是:代码可见 的测试),主要应用于单元测试阶段,常使用逻辑覆盖率(路经覆盖、分支覆盖等)进行测试设计 3)、灰盒沨试:介于黑盒和白盒之间的测试,一般理论上存在,实际招聘岗位的很少。主要应 用于集成测试阶段,常用于接口测試 4.静态、动态测试的区别 答 1)、这两种测试方法主要以代码是否被“执行”作为区分的标准。 2)、静态测试:代码没有被执行如:代码走读,Java编譯L具(代码写完要先编译,检査语 法是否有错误,属于静态+自动化测试,如果编译没有错误才可能被运行)。 3)、动态测试:代码被执行起来了如功能測试〔分别输入有效、无效值测试输入,程序必须 要先运行起来)。兼容测试(被测程序在不同的环境(Win7、Win8等)下运行是否正常) 5.验收测试和a测试、β测试的区别 思路:对这几个测试方法的分类,业界没有形成统一的标准,为了防止考官和你学习的标准不统一, 回答问题前最好加上些说明 答 1)、业內对以上方法的划分没有形成统一的标准,有人认为是并列关系,即验收测试针对的是 项日而言,α和β测试针对的是产品而言有人认为是从属關系,即α测试属于内部验收测试,是 可控的,β测试属于外部验收测试,一般难以控制。 2)、关于这三个测试的定义可以参考前面的“名词解释”蔀分 6.负载、压力、容量测试的区别 思路:一般这些测试均属」性能测试的范畴,业界的解释也是不统-的,类似的还包括“基准测试” 答 1)、以上词彙属于性能测试的常见术语 2)、定义见文档名词解释部分(压力测试、负载测试、容量测试)。 7.测试计划和策略都包括哪些内容 答 1)、测试计划:⊥要内容包括:测试的对象、工作任务安排(谁什么时间做什么事儿)、风险评 估、结束或成功的标准等 2)、测试策眳(设计):主要内容包括:依据《測试计划》进行用例的设计和分析、如何设计测 试数据、如何搭建沨试环境等 3)、定义见文档名词解释部分。 8.简述常见的测试方法和类型 思蕗:对于“测试方汯”、“测试类型”业界也没有统一的标准划分,因此答题的时候干脆把所有可 能的分类方法都说出来 答 1)、当前业界类似種类划分很多,没有形成统一的标准,我的理解是: 2)、测试方法分为:白盒、黑盒、静态、动态、人工、自动等。 3)、测试类型分为:(参考SO9126):功能、安全、兼容等27项 4)、用例设计方法:等价类、边界值、判定表、正交实验、流稈分析、状态迁移 9.单元测试和白盒测试的区别 答 1)、单元测试般指的是:測试的某个阶段 2)、白盒测试一般指的是:一种测试方法 3)、他们的关系:在单元测试阶段,使用白盒测试的方法 10.测试用例的组成字段 思路:每个公司鼡例的组成字段都不相同,因此回答分为两个部分,主要字段(所有公司都有的字 段,属于重要的内容)和其他字段(相对来说不是很重要,每个公司都鈈尽相同),这样防止考官总 说你回答的字段不全 答 1)、一般用例的主要字段包括:用例标题、步骤名称、步骤措述、预期结果、实际结果 2)、其咜辅助字段各个公司都不尽相同,如:用例编号、编写人、预貿条件、优先级、对应版 本、执行状态,覆盖需求等。 3)、额外补充:如QC工具可以将共性的用例步骤设计为模板,并进行参数化出来,以减少大量 重复用例写作,提高工作效率公司额外的宁段也可以在不同的项目中自行添加 4)、把鼡例的设计工作和编写工作最好分开,以便于评审和复用 5)、注意用例对需求的覆盖(跟踪)关系维护,以及确定执行的优先级和次序 11.缺陷报告的组荿字段 思路:同上 答 1)、主要字段:标题、描述、状态、严重程度、优先级 2)、其它字段:时间(提交、修改、回归、关闭)、版本(提父、修改、关闭)、囚(提交人、 分配人)、缺陷产生原因等。如果字段的数量多,也意味着缺陷分析的角度就多 3)、为了防止表达不清楚和义性,最好附加一些截图、操作视频、测试数据等附件 4)、额外补充:如αC类匚具,可以添加用户指定的宇段,并进行缺陷分析(柱形图、饼状图)。 12.如果出现需求变更怎么办 思路:需求是一个很大的范畴,统称需求工程,涵盖内容很多,主要从学习过的内容回答即可 答 1)、从so9000的定义中,需求包括:显示、隐式和规范性需求。除了客广提出的显示需求, 要尽量挖掘和发现隐式需求,同时要满足行业、国家等相关的规范 2)、需求要经过评审才能使用,保证需求的准确性和全面性。因为几乎所有的生命周期模型中 都以需求作为廾始的起点,因此如果需求出现问题,会导致缺陷的发散 3)、可以对需求进行“建模”,绘制“流稈图”或者“状态图”,用图形的方式保证需求尽量不 产生二义性(因为图形元素的定义是标准的),而且可以为后续的测试用例缤寫提供依据 4)、维护需求跟踪关系,如需求和用例的跟踪覆盖关系(αC中可以实现),一有需求发生变 更,可以确定需求变更对用例的影响范围。 5)、每佽需求变更并评审通过后,要进行基线化控制,保证相关人员使用的同一个版木的需求 13.开发不认可你的缺陷怎么办 思路:这道趣就没有标准答案∫,可以说是“人各有志”,不同的人有不同的方法,因此主要考察点 不是对测试知识和技能的掌握,而是你处理人际关系,团队关系,同事关系的能力。 1)、要尽可能避免这种情况发生,此类情况多发生在新员工身上,由于技术和业务掌握不是很 扎实,导致提交一些无效的缺陷,这时可以増加測试内部的评审的环芍来解决,即测试提交新缺陷 (NeW)后,由测试绎理或资深人员进行审核,硝认无误可以打开缺陷(opeη),提交给开发修改, 否则置为无效( Abandon),鈈提交给丌发进行修复参考《缺陷跟踪流程图》 2)、尽量沟通协调,听听对方的理由,如果开发理由充分,放弃此缺陷 3)、如果认为开发理由不充汾,确实需要修复,你要举出反例(参考其它同类软件凶功能)来 证明该缺陷是有道理的。 4)、咨询其他资深的测试同事,看是否有过类似问题,可以求敎一下 5)、实在无法协调的,可以直接提父缺陷报告,改或不改完全由开发决定,起码保证客户反馈 类似问题的时候,责任不在测试这里 6)、总之,凭借我的技术和沟通能力,相信一定能很完美的处理类似的问题 14.发现不可重现的缺陷怎么办 答 1)、检査是否严格按照用例去执行的,还是无意中发現的,尽量去重现或者找到规律 2)、检査测试环璄,包括操作系统、测试斆据等一切可能引起缺陷的原因。 3)、在缺陷报告中注明:不可重现或无法發现规律,最好缺陷报告中就设定类似宇段(QC中默 认有该字段,叫“是否可重现”) 4)、在提交缺陷报告的时候尽可能添加附件,如当时抛出的异常,日誌信息等,也诈开发能从 中发现一些蛛丝马迹,进而修复缺陷 15.验证和确认的区别 答 1)、确认:做没做。如软件的功能是否被开发实现了 2)、验证:莋的对不对。如丌发出来的功能需要验证(测试)是否正确 3)、这个词岀现的频率很高,如αMM(3级中有验证、确认两个过程域)、双Ⅴ模型。

我要回帖

更多关于 软件测试答题 的文章

 

随机推荐