软件测试经典面试题.docx
《软件测试经典面试题.docx》由会员分享，可在线阅读，更多相关《软件测试经典面试题.docx（72页珍藏版）》请在冰豆网上搜索。
软件测试经典面试题
软件测试面试题汇总
测试技术面试题
1、什么是兼容性测试，兼容性测试侧重哪些方面？
参照答案：
兼容测试重要是检查软件在不同硬件平台、软件平台上与否可以正常运营，即是普通说软件可移植性。
兼容类型，如果细分话，有平台兼容，网络兼容，数据库兼容，以及数据格式兼容。
兼容测试重点是，对兼容环境分析。
普通，是在运营软件环境不是很拟定状况下，才需要做兼容。
依照软件运营需要，或者依照需求文档，普通都可以得出顾客会在什么环境下使用该软件，把这些环境整顿成表单，就得出做兼容测试兼容环境了。
兼容和配备测试区别在于，做配备测试普通不是CleanOS下做测试，而兼容测试多是在CleanOS环境下做。
2、我当前有个程序，发当前Windows上运营得很慢，怎么鉴别是程序存在问题还是软硬件系统存在问题？
参照答案：
1、检查系统与否有中毒特性；
2、检查软件/硬件配备与否符合软件推荐原则；
3、确认当前系统与否是独立，即没有对外提供什么消耗CPU资源服务；
4、如果是C/S或者B/S构造软件，需要检查是不是由于与服务器连接有问题，或者访问有问题导致；
5、在系统没有任何负载状况下，查看性能监视器，确认应用程序对CPU/内存访问状况。
3、测试方略有哪些？
参照答案：
黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试方略）
4、正交表测试用例设计办法特点是什么？
参照答案：
用至少实验覆盖最多操作，测试用例设计很少，效率高，但是很复杂；
对于基本验证功能，以及二次集成引起缺陷，普通都能找出来；但是更深缺陷，更复杂缺陷，还是无能为力；
详细环境下，正交表普通都很难做。
大多数，只在系统测试时候使用此办法。
5、描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪管理流程？
参照答案：
1、当你发现问题时候，可以新建一种BUG，将bug信息填写完整;
2、当bug被改好后来可将状态改为已修改或是标记或不拟定状态;
3、当bug再次浮现时候可以将状态改为再次打开;
4、拟定更改后关闭bug.
6、你觉得bugzilla在使用过程中，有什么问题？
参照答案：
界面不稳定；
依照需要配备它不同某些，过程很啰嗦。
流程控制上，安全性不好界定，很容易对她人Bug进行误操作；
没有综合评分指标，不好确认修复优先级别。
7、描述测试用例设计完整过程？
参照答案：
需求分析+需求变更维护工作；
依照需求得出测试需求；
设计测试方案，评审测试方案；
方案评审通过后，设计测试用例，再对测试用例进行评审；
8、单元测试方略有哪些？
参照答案：
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
9、LoadRunner分哪三某些？
参照答案：
顾客动作设计；
场景设计；
测试数据分析；
10、LoadRunner进行测试流程?
参照答案：
1、测试分析
2、创立虚拟顾客脚本
3、创立运营场景
4、运营测试脚本
5、监视场景
6、分析测试成果
以上，最佳是结合一种案例，依照以上流程来简介。
11、什么是并发？
在lordrunner中，如何进行并发测试？
集合点失败了会怎么样？
参照答案：
在同一时间点，支持各种不同操作。
LoadRunner中提供IP伪装，集合点，配合虚拟顾客设计，以及在多台电脑上设立，可以比较好模仿真实并发。
集合点，即是各种顾客在某个时刻，某个特定环境下同步进行虚拟顾客操作。
集合点失败，则集合点才操作就会取消，测试就不能进行。
12、使用QTP做功能测试，录制脚本时候，要验证各种顾客登录状况/查询状况，如何操作？
参照答案：
分析顾客登录基本状况，得出一组数据，通过性测试/失败性测试均有（依照TC来设计这些数据），然后录制登录脚本，将核心数据参数化，修改脚本，对代码进行加强，调试脚本。
13、QTP中Action有什么作用？
有几种？
参照答案：
Action作用：
1）用Action可以对环节集进行分组
2）环节重组，然后被整体调用
3）拥有自己sheet
4）组合有相似需求环节，整体操作
5）具备独立对象仓库
Action种类
1）可复用Action
2）不可复用Action
3）外部Action
14、TestDirector有些什么功能，如何对软件测试过程进行管理？
参照答案：
需求管理
⏹定义测试范畴
⏹定义需求树
⏹描述需求树功能点
测试筹划
⏹定义测试目的和测试方略。
⏹分解应用程序，建立测试筹划树。
⏹拟定每个功能点测试办法。
⏹将每个功能点连接到需求上，使测试筹划覆盖所有测试需求。
⏹描述手工测试测试环节
⏹指明需要进行自动测试功能点
测试执行
⏹定义测试集合。
⏹为每个测试人员制定测试任务和测试日程安排。
⏹运营自动测试。
缺陷跟踪
⏹记录缺陷
⏹查看新增缺陷，并拟定哪些是需要修正
⏹有关技术人员修改缺陷
⏹回归测试
⏹分析缺陷记录图表，分析应用程序开发质量。
15、你所熟悉软件测试类型均有哪些？
请试着分别比较这些不同测试类型区别与联系（如功能测试、性能测试……）？
参照答案：
CompatibilityTesting（兼容性测试），也称“Configurationtesting（配备测试）”，测试软件与否和系统其他与之交互元素之间兼容，如：
浏览器、操作系统、硬件等。
验证测试对象在不同软件和硬件配备中运营状况。
Functionaltesting（功能测试），也称为behavioraltesting（行为测试），依照产品特性、操作描述和顾客方案，测试一种产品特性和可操作行为以拟定它们满足设计需求。
本地化软件功能测试，用于验证应用程序或网站对目的顾客能对的工作。
使用恰当平台、浏览器和测试脚本，以保证目的顾客体验将足够好，就像应用程序是专门为该市场开发同样。
Performancetesting（性能测试），评价一种产品或组件与性能需求与否符合测试。
涉及负载测试、强度测试、数据库容量测试、基准测试等类型。
16、软件缺陷（或者叫Bug）记录都包括了哪些内容？
如何提交高质量软件缺陷（Bug）记录？
参照答案：
一条Bug记录最基本应包括：
编号、Bug所属模块、Bug描述、Bug级别、发现日期、发现人、修改日期、修改人、修改办法、回归成果等等；要有效发现Bug需参照需求以及详细设计等前期文档设计出高效测试用例，然后严格执行测试用例，对发现问题要充分确认必定，然后再向外发布如此才干提高提交Bug质量。
17、Beta测试与Alpha测试有什么区别？
参照答案：
Betatesting（β测试）,测试是软件各种顾客在一种或各种顾客实际使用环境下进行测试。
开发者普通不在测试现场
Alphatesting（α测试）,是由一种顾客在开发环境下进行测试，也可以是公司内部顾客在模仿实际操作环境下进行受控测试
18、软件评审普通由哪些人参加？
其目是什么？
参照答案：
在正式会议上将软件项目成果（涉及各阶段文档、产生代码等）提交给顾客、客户或关于部门人员对软件产品进行评审和批准。
其目是找出也许影响软件产品质量、开发过程、维护工作合用性和环境方面设计缺陷，并采用补救办法，以及找出在性能、安全性和经济方面也许改进。
人员：
顾客、客户或关于部门开发人员，测试人员，需求分析师都可以，就看处在评审那个阶段
19、测试活动中，如果发现需求文档不完善或者不精确，怎么解决？
参照答案：
测试需求分析发现需求文档不完善或者不精确，应当及时和有关人员进行协调交流。
20、阶段评审与项目评审有什么区别？
参照答案：
阶段评审对项目各阶段评审：
对阶段成果和工作
项目评审对项目总体评审：
对工作和产品
21、阐述工作版本定义？
参照答案：
产品到达测试环节了，需要一种版本号，例如当前是V1.0，进行一轮功能测试后，会发现许多问题，开发人员修复后，会再发出一种修复后版本，例如V1.1，工作版本用于区别和之前版本不同之处，以便控制软件开发流程。
22、什么是桩模块？
什么是驱动模块？
参照答案：
桩模块：
被测模块调用模块
驱动模块调用被测模块
23、什么是扇入？
什么是扇出？
参照答案：
扇入：
被调次数，扇出：
调其他模块数目
24、你以为做好测试筹划工作核心是什么？
参照答案：
软件测试筹划就是在软件测试工作正式实行之前明确测试对象，并且通过对资源、时间、风险、测试范畴和预算等方面综合分析和规划，保证有效实行软件测试；
做好测试筹划工作核心：
目，管理，规范
1.明确测试目的，增强测试筹划实用性
编写软件测试筹划得重要目就是使测试过程可以发现更多软件缺陷，因而软件测试筹划价值取决于它对协助管理测试项目，并且找出软件潜在缺陷。
因而，软件测试筹划中测试范畴必要高度覆盖功能需求，测试办法必要切实可行，测试工具并且具备较高实用性，便于使用，生成测试成果直观、精确
2．坚持“5W”规则，明确内容与过程
“5W”规则指是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。
运用“5W”规则创立软件测试筹划，可以协助测试团队理解测试目（Why），明确测试范畴和内容（What），拟定测试开始和结束日期（When），指出测试办法和工具（How），给出测试文档和软件存储位置（Where）。
3．采用评审和更新机制，保证测试筹划满足实际需求
测试筹划写作完毕后，如果没有通过评审，直接发送给测试团队，测试筹划内容也许不精确或漏掉测试内容，或者软件需求变更引起测试范畴增减，而测试筹划内容没有及时更新，误导测试执行人员。
4.分别创立测试筹划与测试详细规格、测试用例
应把详细测试技术指标包括到独立创立测试详细规格文档，把用于指引测试小组执行测试过程测试用例放到独立创立测试用例文档或测试用例管理数据库中。
测试筹划和测试详细规格、测试用例之间是战略和战术关系，测试筹划重要从宏观上规划测试活动范畴、办法和资源配备，而测试详细规格、测试用例是完毕测试任务详细战术。
25、你以为做好测试用例工作核心是什么？
参照答案：
需求和设计文档理解限度，对系统熟悉限度
26、简述一下缺陷生命周期？
参照答案：
提交->确认->分派->修复->验证->关闭
27、软件安全性应从哪几种方面去测试？
参照答案：
（1）顾客认证机制：
如数据证书、智能卡、双重认证、安全电子交易合同
（2）加密机制
（3）安全防护方略：
如安全日记、入侵检测、隔离防护、漏洞扫描
（4）数据备份与恢复手段：
存储设备、存储优化、存储保护、存储管理
（5）防病毒系统
28、软件配备管理工作开展状况和结识？
参照答案：
软件配备管理贯穿于软件开发、测试活动始终，覆盖了开发、测试活动各个环节，它重要作用之一就是要全面管理保存各个配备项，监控各配备项状态，并向项目经理及有关人员报告，从而实现对软件过程控制。
软件测试配备管理涉及4个最基本活动：
配备项标记
配备项控制
配备项状态报告
配备审计
软件配备管理普通借助工具来辅助，重要有MSSourceSafe、RationalClearCase等
29、你觉得软件测试通过原则应当是什么样？
参照答案：
缺陷密度值达到客户规定
30、引入测试管理含义？
参照答案：
风险分析，进度控制、角色分派、质量控制
31、一套完整测试应当由哪些阶段构成？
参照答案：
测试筹划、测试设计与开发、测试实行、测试评审与测试结论
32、单元测试重要内容？
参照答案：
模块接口测试、局部数据构造测试、途径测试、错误解决测试、边界测试
33、集成测试也叫组装测试或者联合测试，请简述集成测试重要内容？
参照答案：
（1）在把各个模块连接起来时候，穿越模块接口数据与否会丢失；
（2）一种模块功能与否会对另一种模块功能产生不利影响；
（3）各个子功能组合起来，能否达到预期规定父功能；
（4）全局数据构造与否有问题；
（5）单个模块误差累积起来，与否会放大，从而达到不能接受限度。
34、简述集成测试与系统测试关系？
参照答案：
（1）集成测试重要根据概要设计阐明书，系统测试重要根据是需求设计阐明书；
（2）集成测试是系统模块测试，系统测试是对整个系统测试，涉及有关软硬件平台、网络以及有关外设测试。
35、软件测试文档测试应当贯穿于软件生命周期全过程，其中顾客文档是文档测试重点。
那么软件系统顾客文档涉及哪些？
参照答案：
顾客手册
安装和设立指引
联机协助
指南、向导
样例、示例和模板
授权/注册登记表
最后顾客允许合同
36、软件系统中除顾客文档之外，文档测试还应当关注哪些文档？
参照答案：
开发文档
软件需求阐明书
数据库设计阐明书
概要设计阐明书
详细设计阐明书
可行性研究报告
管理文档
项目开发筹划
测试筹划
测试报告
开发进度月报
开发总结报告
37、简述软件系统中顾客文档测试要点？
参照答案：
（1）读者群。
文档面向读者定位要明确。
对于初级顾客、中级顾客以及高档顾客应当有不同定位
（2）术语。
文档中用到术语要合用与定位读者群，用法一致，原则定义与业界规范相吻合。
（3）对的性。
测试中需检查所有信息与否真实对的，查找由于过期产品阐明书和销售人员夸大事实而导致错误。
检查所有目录、索引和章节引用与否已更新，尝试链接与否精确，产品支持电话、地址和邮政编码与否对的。
（4）完整性。
对照软件界面检查与否有重要分支没有描述到，甚至与否有整个大模块没有描述到。
（5）一致性。
按照文档描述操作执行后，检查软件返回成果与否与文档描述相似。
（6）易用性。
对核心环节以粗体或背景色给顾客以提示，合理页面布局、适量图表都可以给顾客更高易用性。
需要注意是文档要有助于顾客排除错误。
不但描述对的操作，也要描述错误解决办法。
文档对于顾客看到错误信息应当有更详细文档解释。
（7）图表与界面截图。
检查所有图表与界面截图与否与发行版本相似。
（8）样例与示例。
像顾客同样载入和使用样例。
如果是一段程序，就输入数据并执行它。
以每一种模块制作文献，确认它们对的性。
（9）语言。
不浮现错别字，不要出既有二义性说法。
特别要注意是屏幕截图或绘制图形中文字。
（10）印刷与包装。
检查印刷质量；手册厚度与开本与否适当；包装盒大小与否适当；有无零散易丢失小部件等等。
38、单元测试重要内容是什么？
参照答案：
单元测试大多数由开发人员来完毕，测试人员技术背景较好或者开发系统软件时也许会安排测试人员进行单元测试，大多数进行单元测试都是开发人员调试程序或者开发组系统联合调试过程。
讨论这个问题重要是扩充一下读者视野。
单元测试普通涉及五个方面测试：
（1）模块接口测试：
模块接口测试是单元测试基本。
只有在数据能对的流入、流出模块前提下，其她测试才故意义。
模块接口测试也是集成测试重点，这里进行测试重要是为背面打好基本。
测试接口对的与否应当考虑下列因素：
-输入实际参数与形式参数个数与否相似；
-输入实际参数与形式参数属性与否匹配；
-输入实际参数与形式参数量纲与否一致；
-调用其她模块时所给实际参数个数与否与被调模块形参个数相似；
-调用其她模块时所给实际参数属性与否与被调模块形参属性匹配；
-调用其她模块时所给实际参数量纲与否与被调模块形参量纲一致；
-调用预定义函数时所用参数个数、属性和顺序与否对的；
-与否存在与当前入口点无关参数引用；
-与否修改了只读型参数；
-对全程变量定义各模块与否一致；
-与否把某些约束作为参数传递。
如果模块功能涉及外部输入输出，还应当考虑下列因素：
-文献属性与否对的；
-OPEN/CLOSE语句与否对的；
-格式阐明与输入输出语句与否匹配；
-缓冲区大小与记录长度与否匹配；
-文献使用前与否已经打开；
-与否解决了文献尾；
-与否解决了输入/输出错误；
-输出信息中与否有文字性错误。
-局部数据构造测试；
-边界条件测试；
-模块中所有独立执行通路测试；
（2）局部数据构造测试：
检查局部数据构造是为了保证暂时存储在模块内数据在程序执行过程中完整、对的，局部功能是整个功能运营基本。
重点是某些函数与否对的执行，内部与否运营对的。
局部数据构造往往是错误根源，应仔细设计测试用例，力求发现下面几类错误：
-不适当或不相容类型阐明；
-变量无初值；
-变量初始化或省缺值有错；
-不对的变量名（拼错或不对的地截断）；
-浮现上溢、下溢和地址异常。
（3）边界条件测试：
边界条件测试是单元测试中最重要一项任务。
众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有也许发现新错误。
边界条件测试是一项基本测试，也是背面系统测试中功能测试重点，边界测试执行较好，可以大大提高程序健壮性。
（4）模块中所有独立途径测试：
在模块中应对每一条独立执行途径进行测试，单元测试基本任务是保证模块中每条语句至少执行一次。
测试目重要是为了发现因错误计算、不对的比较和不恰当控制流导致错误。
详细做法就是程序员逐条调试语句。
常用错误涉及：
-误解或用错了算符优先级；
-混合类型运算；
-变量初值错；
-精度不够；
-表达式符号错。
比较判断与控制流经常紧密有关，测试时注意下列错误：
-不同数据类型对象之间进行比较；
-错误地使用逻辑运算符或优先级；
-因计算机表达局限性，盼望理论上相等而事实上不相等两个量相等；
-比较运算或变量出错；
-循环终结条件或不也许浮现；
-迭代发散时不能退出；
-错误地修改了循环变量。
模块各条错误解决通路测试：
程序在遇到异常状况时不应当退出，好程序应能预见各种出错条件，并预设各种出错解决通路。
如果顾客不按照正常操作，程序就退出或者停止工作，事实上也是一种缺陷，因而单元测试要测试各种错误解决途径。
普通这种测试着重检查下列问题：
-输出出错信息难以理解；
-记录错误与实际遇到错误不相符；
-在程序自定义出错解决段运营之前，系统已介入；
-异常解决不当；
-错误陈述中未能提供足够定位出错信息。
39、如何理解强度测试？
参照答案：
强度测试是为了拟定系统在最差工作环境工作能力,也也许是用于验证在原则工作压力下各种资源最下限指标。
它和压力测试目的是不同,压力测试是在原则工作环境下,不断增长系统负荷,最后测试出该系统能力达到最大负荷（稳定和峰值）,而强度测试则是在非原则工作环境下,甚至不断人为减少系统工作环境所需要资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源局限性状况下工作状态,通过强度测试,可以拟定本系统正常工作最差环境.
强度测试和压力测试测试指标相近,大多都是与时间有关指标,如并发量（吞吐量）,延迟（最大\最小\平均）以及顺序指标等
强度测试需要对系统构造熟悉,针对系统特性设计强度测试办法
40、如何理解压力、负载、性能测试测试？
参照答案：
性能测试是一种较大范畴，事实上性能测试自身包括了性能、强度、压力、负载等多方面测试内容。
压力测试是对服务器稳定性以及负载能力等方面测试，是一种很寻常测试。
增大访问系统顾客数量、或者几种顾客进行大数据量操作都是压力测试。
而负载测试是压力相对较大测试，重要是测试系统在一种或者集中极限条件下相应能力，是性能测试重要某些。
100个顾客对系统进行持续半个小时访问可以看作压力测试，那么持续访问8个小时就可以以为负载测试，1000个顾客持续访问系统1个小时也可以看作是负载测试。
事实上压力测试和负载测试没有明显区别。
测试人员应当站在关注整体性能高度上来对系统进行测试。
41、什么是系统瓶颈？
参照答案：
瓶颈重要是指整个软硬件构成软件系统某一方面或者几种方面能力不能满足顾客特定业务规定，“特定”是指瓶颈会在某些条件下会浮现，由于毕竟大多数系统在投入前。
严格从技术角度讲，所有系统都会有瓶颈，由于大多数系统资源配备不是协调，例如CPU使用率刚好达到100％时，内存也正好耗尽系统不是诸多见。
因而咱们讨论系统瓶颈要从应用角度讨论：
核心是看系统能否满足顾客需求。
在顾客极限使用系统状况下，系统响应依然正常，咱们可以以为改系统没有瓶颈或者瓶颈不会影响顾客工作。
因而咱们测试系统瓶颈重要是实现下面两个目：
-发现“表面”瓶颈。
重要是模仿顾客操作，找出顾客极限使用系统时瓶颈，然后解决瓶颈，这是性能测试基本目的。
-发现潜在瓶颈并解决，保证系统长期稳定性。
重要是考虑顾客在将来扩展系统或者业务发生变化时，系统可以适应变化。
满足顾客当前需求系统不是最佳，咱们设计系统目的是在保证系统整个软件生命周期可以不断适应顾客变化，或者通过简朴扩展系统就可以适应新变化。
42、文档测试重要包括什么内容？
参照答案：
在国内软件开发管理中，文档管理几乎是最弱一项，因而在测试工作中特别容易忽视文档测试也就局限性为奇了。
要想给顾客提供完整产品，文档测试是必不可少。
文档测试普通注重下面几种方面：
文档完整性：
重要是测试文档内容全面性与完整性，从总体上把握文档质量。
例如顾客手册应当涉及软件所有功能模块。
描述与软件实际状况一致性：
重要测试软件文档与软件实际一致限度。
例如顾客手册基本完整后，咱们还要注意顾客手册与实际功能描述与否一致。
由于文档往往跟不上软件版本更新速度。
易理解性：
重要是检查文档对核心、重要操作有无图文阐明，文字、图表与否易于理解。
对于核心、重要操作仅仅只有文字阐明必定是不够，应当附有图表使阐明更为直观和明了。
文档中提供操作实例：
这项检查内容重要针对顾客手册。
对重要功能和核心操作提供应用实例与否丰富，提供实例描述与否详细。
只有简朴图文阐明，而无实例顾客手册看起来就像是软件界面简朴拷贝，对于顾客来说，事实上没有什么协助。
印刷与包装质量：
重要是检查软件文档商品化限度。
有些顾客手册是简朴打印、装订而成，过于粗糙，不易于顾客保存。
先进文档例如顾客手册和技术白皮书，应提供商品化包装，并且印刷精美。
43、功能测试用例需要详细到什么限度才是合格？
参照答案：
这个问题也是测试工程师经常问问题。
有人主张测试用例详细到每个环节执行什么都要写出来，目是虽然一种不理解系统新手都可以按照测试用例来执行工作。
主张此类写法人还可以举出例子：
欧美、日本等软件外包文档都是这样做。
此外一种观点就是主张写粗些，类似于编写测试大纲。
主张这种观点人是由于软件开发需求管理不规范，变动十分频繁，因而不能按照欧美高原则来编写测试用例。
这样测试用例容易维护，可以让测试执行人员有更大发挥空间。
事实上，软件测试用例详细限度一方面要以覆盖到测试点为基本规定。
举个例子：
“顾客登陆系统”测试用例可以不写出详细执行数据，但是至少要写出五种以上状况（），如果只用一句话覆盖了这个功能是不合格测试用例。
覆盖功能点不是指列出功能点，而是要写出功能点各个方面（如果组合状况较多时可以采用等价划分）。
另一种影响测试用例就是组织开发能力和测试对象特点。
如果开发力量比较落后，编写较详细测试用例是不现实，由于主线没有那么大资源投入，固然这种状况很随着团队发展而逐渐有所改进。
测试对象特点重点是指测试对象在进度、成本等方面规定，如果进度较紧张状况下，是主线没有时间写出高质量测试用例，甚至有些时候测试工作只是一种辅助工作，因而不编写测试用例。
因而，测试用例编写要依照测试对象特点、团队执行能力等各个方面综合起来决定编写方略。
最后要注意是测试人员一定不能抱怨，力求在不断提高测试用例编写水平同步
升级会员 