软件测试经典面试题总结.docx
《软件测试经典面试题总结.docx》由会员分享，可在线阅读，更多相关《软件测试经典面试题总结.docx（27页珍藏版）》请在冰豆网上搜索。
软件测试经典面试题总结
1、什么是兼容性测试？
兼容性测试侧重哪些方面？
兼容测试：
主要是检查软件在不同的软\硬件平台上是否可以正常的运行，即软件可移植性。
兼容的类型：
细分为平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
兼容测试的重点：
对兼容环境的分析。
通常，是在运行软件的环境不是很确定的情况下，才需要做兼容测试。
兼容和配置测试的区别：
做配置测试通常不是CleanOS下做测试，而兼容测试多是在CleanOS的环境下做的。
2、我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
1、检查系统是否有中毒的特征；
2、检查软件/硬件的配置是否符合软件的推荐标准；
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。
3、测试的策略有哪些？
黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）
4、正交表测试用例设计方法的特点是什么？
1、用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
2、对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
3、具体的环境下，正交表一般都很难做的。
大多数，只在系统测试的时候使用此方法。
5、描述使用bugzilla缺陷管理工具对软件缺陷（BUG）跟踪的管理的流程？
标记
就是Bugzilla的状态转换图。
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的作用
⏹用Action可以对步骤集进行分组
⏹步骤重组，然后被整体调用
⏹拥有自己的sheet
⏹组合有相同需求的步骤，整体操作
⏹具有独立的对象仓库
Action的种类
⏹可复用Action
⏹不可复用Action
⏹外部Action
14、TestDirector有些什么功能，如何对软件测试过程进行管理？
标记
需求管理
⏹定义测试范围
⏹定义需求树
⏹描述需求树的功能点
测试计划
⏹定义测试目标和测试策略。
⏹分解应用程序，建立测试计划树。
⏹确定每个功能点的测试方法。
⏹将每个功能点连接到需求上，使测试计划覆盖全部的测试需求。
⏹描述手工测试的测试步骤
⏹指明需要进行自动测试的功能点
测试执行
⏹定义测试集合。
⏹为每个测试人员制定测试任务和测试日程安排。
⏹运行自动测试。
缺陷跟踪
⏹记录缺陷
⏹查看新增缺陷，并确定哪些是需要修正的
⏹相关技术人员修改缺陷
⏹回归测试
⏹分析缺陷统计图表，分析应用程序的开发质量。
15、你所熟悉的软件测试类型都有哪些？
请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）？
CompatibilityTesting（兼容性测试），测试软件是否和系统的其它与之交互的元素之间兼容，如：
浏览器、操作系统、硬件等。
验证测试对象在不同的软件和硬件配置中的运行情况。
Functionaltesting（功能测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。
Performancetesting（性能测试），评价一个产品或组件与性能需求是否符合的测试。
包括负载测试、强度测试、数据库容量测试、基准测试等类型。
16、软件缺陷（或者叫Bug）记录都包含了哪些内容？
如何提交高质量的软件缺陷（Bug）记录？
1，硬件平台和操作系统
2，版本
3，bug编号
4，bug报告优先级
5，bug状态
6，发现人
7，提交人
8，提交日期
9，指定处理人
10，概述
11，从属关系
12，详细描述
13，严重程度
14，所属模块
要提交高质量的软件缺陷记录要参考需求及前期详细设计等前期文档，设计高效测试用例，然后执行用例，对发现问题要充分肯定，然后对外发布。
17、Beta测试与Alpha测试有什么区别？
Betatesting（β测试）,测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。
开发者通常不在测试现场
Alphatesting（α测试）,是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试
18、软件的评审一般由哪些人参加？
其目的是什么？
标记
在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。
其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。
人员：
用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段
19、阶段评审与项目评审有什么区别？
标记
阶段评审对项目各阶段评审：
对阶段成果和工作
项目评审对项目总体评审：
对工作和产品
20、阐述工作版本的定义？
软件开发过程中，用于内部测试的功能和性能不完善的软件版本。
工作版本既可以是系统的可操作版本，也可以是要在发布产品中演示的部分功能模块。
21、什么是桩模块？
什么是驱动模块？
桩模块：
被测模块调用模块
驱动模块调用被测模块的模块
22、什么是扇入？
什么是扇出？
扇入：
被调次数，扇出：
调其它模块数目
23、你认为做好测试计划工作的关键是什么？
标记
软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；
做好测试计划工作的关键：
目的，管理，规范
1.明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。
因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2．坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。
利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4.分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。
测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
24、你认为做好测试用例工作的关键是什么？
需求和设计文档的理解程度，对系统的熟悉程度
25、简述一下缺陷的生命周期？
提交->确认->分配->修复->验证->关闭
26、软件的安全性应从哪几个方面去测试？
用户认证机制：
如数字证书、智能卡、双重认证、安全电子交易协议
加密机制
安全防护策略：
如安全日志、入侵检测、隔离防护、漏洞扫描
数据备份与恢复手段：
存储设备、存储优化、存储保护、存储管理
防病毒系统
27、软件配置管理工作开展的情况和认识？
标记
软件配置管理贯穿于软件开发、测试活动的始终，覆盖了开发、测试活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。
软件测试配置管理包括4个最基本的活动：
配置项标识
配置项控制
配置项状态报告
配置审计
软件配置管理通常借助工具来辅助，主要有MSSourceSafe、RationalClearCase等
28、你觉得软件测试通过的标准应该是什么样的？
缺陷密度值达到客户的要求
29、引入测试管理的含义？
标记
风险分析，进度控制、角色分配、质量控制
30、一套完整的测试应该由哪些阶段组成？
需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估
31、集成测试也叫组装测试或者联合测试，请简述集成测试的主要内容？
（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
（2）一个模块的功能是否会对另一个模块的功能产生不利的影响；
（3）各个子功能组合起来，能否达到预期要求的父功能；
（4）全局数据结构是否有问题；
（5）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
32、简述集成测试与系统测试关系？
（1）集成测试的主要依据概要设计说明书，系统测试的主要依据是需求设计说明书；
（2）集成测试是系统模块的测试，系统测试是对整个系统的测试，包括相关的软硬件平台、网络以及相关外设的测试。
33、软件测试的文档测试应当贯穿于软件生命周期的全过程，其中用户文档是文档测试的重点。
那么软件系统的用户文档包括哪些？
用户手册
安装和设置指导
联机帮助
指南、向导
样例、示例和模板
授权/注册登记表
最终用户许可协议
34、软件系统中除用户文档之外，文档测试还应该关注哪些文档？
开发文档
软件需求说明书
数据库设计说明书
概要设计说明书
详细设计说明书
可行性研究报告
管理文档
项目开发计划
测试计划
测试报告
开发进度月报
开发总结报告
35、简述软件系统中用户文档的测试要点？
（1）读者群。
文档面向的读者定位要明确。
对于初级用户、中级用户以及高级用户应该有不同的定位
（2）术语。
文档中用到的术语要适用与定位的读者群，用法一致，标准定义与业界规范相吻合。
（3）正确性。
测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。
检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
（4）完整性。
对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
（5）一致性。
按照文档描述的操作执行后，检查软件返回的结果是否与文档描述的相同。
（6）易用性。
对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。
需要注意的是文档要有助于用户排除错误。
不但描述正确操作，也要描述错误处理办法。
文档对于用户看到的错误信息应当有更详细的文档解释。
（7）图表与界面截图。
检查所有图表与界面截图是否与发行版本相同。
（8）样例与示例。
像用户一样载入和使用样例。
如果是一段程序，就输入数据并执行它。
以每一个模块制作文件，确认它们的正确性。
（9）语言。
不出现错别字，不要出现有二义性的说法。
特别要注意的是屏幕截图或绘制图形中的文字。
（10）印刷与包装。
检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等等。
文档测试主要包含什么内容？
文档的完整性：
主要是测试文档内容的全面性和完整性，从总体上把握文档的质量。
描述与软件实际情况的一致性：
主要测试软件文档和软件实施的一致性。
易理解性：
主要是检查文档对关键、重要的操作和有无图文字说明，文字、图表是否易于理解。
文档提供操作的实训：
这项检查内容主要针对用户手册。
主要功能和关键操作提供的应用实例是否丰富，提供的实训描述是否详细。
印刷和包装质量：
主要是检查软件稳定的商业化程序。
36、单元测试主要内容是什么？
1，模块接口测试。
单元测试的基础，只有在数据能正确流入，流出模块的前提下才有意义。
2，局部数据结构测试检查局部数据结构是为了保证临时存储在模块内的数据在程序执行中完整，正确。
重点是一些执行函数是否正确执行，内部是否运行正确。
局部数据结构往往是错误的根源，应仔细设计测试用例。
3，边界条件测试单元测试中最重要的一项任务。
因为软件经常在边界上失败，采用边界值分析，可能发现新的错误。
4，模块中所有独立路径的测试在模块中执行每一条独立执行路径进行测试，单元测试的基本任务保证模块中每条语句执行一次。
5，模块的各条错误处理通路测试：
程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件，并预设各种出错处理通路。
37、如何理解强度测试？
强度测试是为了确定系统在最差工作环境的工作能力,也可能是用于验证在标准工作压力下的各种资源的最下限指标。
它和压力测试的目标是不同的,压力测试是在标准工作环境下,不断增加系统负荷,最终测试出该系统能力达到的最大负荷（稳定和峰值）,而强度测试则是在非标准工作环境下,甚至不断人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源不足的情况下的工作状态,通过强度测试,可以确定本系统正常工作的最差环境.
强度测试和压力测试的测试指标相近,大多都是与时间相关的指标,如并发量（吞吐量）,延迟（最大\最小\平均）以及顺序指标等
强度测试需要对系统的结构熟悉,针对系统的特征设计强度测试的方法
38、如何理解压力、负载、性能测试测试？
性能测试是一个较大的范围，实际上性能测试本身包括了性能，强度，压力等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试。
主要任务是获取系统正确运行的极限，检查系统的瞬间峰值负荷下正确执行的能力。
增大访问系统的用户数量，或者几个用户进行大数据量操作都是压力测试，而负载测试是压力相对较大的测试，性能测试的重要部分。
100个用户对系统进行连续半小时的访问可以看做压力测试，连续访问8个小时就可以认为是负载测试。
实际上，做压力测试和负载测试没有明显的区别，测试人员应该站在关注整理性能的高度上来对系统进行测试。
39、什么是系统瓶颈？
主要指整个软件硬件构成的软件系统在某一个方面或者几个方面能力不能满足用户的特定业务要求。
“特定”是指瓶颈会在某些条件下出现。
严格的技术角度上讲，所有的系统都会有瓶颈，因为大多数系统的资源配置是不协调的，如cup使用率刚好到达100%时，内存正好耗尽的系统。
但是不多见。
所以我们要从应用角度讨论：
关键是看系统能否盲足用户需求。
在用户极限使用系统的情况下，系统的响应仍然正常，可以认为系统没有瓶颈或者瓶颈不影响用户工作。
测试系统瓶颈主要是实现下面两个目的：
--发现表面的瓶颈。
模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。
--发现潜在的瓶颈并解决，保证系统的长期稳定。
40、功能测试用例需要详细到什么程度才是合格的？
一，详细到每个步骤都写出来，目的是即使一个不了解的新手都可以按照测试用例来执行工作。
二，主张写的粗糙些，类似编写测试大纲。
因为软件开发需求管理不规范，频繁变动。
这样的测试用例容易维护。
然测试执行人员有更大的发挥空间。
实际上，软件测试用例的详细程度首先要以覆盖到测试点为基本要求。
41、配置和兼容性测试的区别是什么？
配置测试的目的是保证软件在其相关的硬件上能够正常运行，而兼容性测试主要是测试软件能否与不同的软件正确协作。
1，配置测试的目的是保证软件在其相关的硬件上能够正常运行的，而兼容测试主要是测试软件能否与不同的软件兼容。
2，配置测试的核心内容：
使用各种硬件来测试软件的运行情况，包括软件在不同的主机/主件上的运行情况，不同的外设，不同的接口，不同的可选项。
3，兼容测试的核心内容
1，测试软件在不同的操作系统或者同一系统的不同版本上兼容。
2，软件本身能否向前或者向后兼容。
3，测试软件能否与其它相关的软件兼容。
4，数据兼容测试，主要是指数据能否共享。
配置和兼容性测试通称对开发系统类软件比较重要，例如驱动程序、操作系统、数据库管理系统等。
具体进行时仍然按照测试用例来执行。
42、测试中的“杀虫剂怪事”是指什么？
“杀虫剂怪事”用于描述测试人员对同一测试对象进行的测试次数越多，发现的缺陷就会越来越少的现象。
就像老用一种农药，害虫就会有免疫力，农药发挥不了效力。
这种现象的根本原因就是测试人员对测试软件过于熟悉，形成思维定势。
为了克服这种现象，测试人员需要不断编写新的测试程序或者测试用例，对程序的不同部分进行测试，以发现更多的缺陷。
也可以引用新人来测试软件，刚刚进来的新手往往能发现一些意想不到的问题。
43、完全测试程序是可能的吗？
实际上完全测试是不可能的。
主要有以下一个原因：
-完全测试比较耗时，时间上不允许；
-完全测试通常意味着较多资源投入，这在现实中往往是行不通的；
-输入量太大，不能一一进行测试；
-输出结果太多，只能分类进行验证；
-软件实现途径太多；
-软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同；
因此测试的程度要根据实际情况确定。
44、软件测试人员就是QA吗？
软件测试人员的职责是尽可能的找出软件缺陷，确保缺陷能被修复。
QA（质量保证人员）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。
测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是保证人员的工作对象。
45、测试产品与测试项目的区别是什么？
习惯上吧开发完成进行商业化，几乎不进行代码修改就可以售给用户使用的软件称为软件产品。
把针对一个或几个特定的用户而开发的软件称为软件项目，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。
区别：
质量不同，产品的质量要求高一些，修复发布后产品的缺陷成本较高，甚至带来很多负面的影响。
而项目通常面向某一个用户，虽然质量越高越好，但是一般只要满足用户要求就可以。
测试资源投入多少不同。
软件产品通常是研发中心来开发，进度压力要小些，同时由于质量要求高，因此会投入较多的人力，物力资源。
46、和用户共同测试（UAT测试）的注意点有哪些？
标记
软件产品在投产前，通常都会进行用户验收测试。
如果用户验收测试没有通过，直接结果就是那不到“Money”，间接影响是损害了公司的形象，而后者的影响往往更严重。
根据作者的经验，用户验收测试一定要让用户满意。
实际上用户现场测试更趋于是一种演示。
在不欺骗用户的前提下，我们向用户展示我们软件的优点，最后让“上帝”满意并欣然掏出“银子”才是我们的目标。
因此用户测试要注意下面的事项：
（1）用户现场测试不可能测试全部功能，因此要测试核心功能。
这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。
测试核心模块的目的是建立用户对软件的信心。
当然如果这些模块如果问题较多，不应该进行演示。
（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。
争得时间后，及时修改缺陷来弥补。
（3）永远不能欺骗用户，蒙混过关。
道理很简单，因为软件是要给用户用的，问题早晚会暴露出来，除非你可以马上修改。
和用户进行测试还要注意各种交流技巧，争取不但短期利益得到了满足，还要为后面得合作打好基础。
47、如何编写提交给用户的测试报告？
标记
随着测试工作越来越受重视，开发团队向客户提供测试文档是不可避免的事情。
很多人会问：
“我们可以把工作中的测试报告提供给客户吗？
”答案是否定的。
因为提供内部测试报告，可能会让客户失去信心，甚至否定项目。
测试报告一般分为内部测试报告和外部测试报告。
内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况，这里不过多讨论，读者可以参考相关教材。
这里主要讨论一下外部测试报告的写法，一般外部测试报告要满足下面几个要求：
-根据内部测试报告进行编写，一般可以摘录；
-不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；
-报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；
-报告上面的内容尽量要真实可靠；
-整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。
总之，外部测试报告要小心谨慎的编写。
48、什么是软件测试，软件测试的目的？
使用人工或者自动手段来运行或测试某个系统的过程，目的在于检验它是否满足规定的需求或者弄清预期结果和实际结果之间的差别。
49、写出bug报告流转的步骤，每步的责任人及主要完成的工作。
标记
参考答案：
（要结合自己实际的工作经验进行回答，不同公司略有区别）
测试人员提交新的Bug入库，错误状态为New。
高级测试员/测试经理验证错误，如果确认是错误，分配给开发组。
设置状态为Open。
如果不是错误，则拒绝，设置为Declined状态。
开发经理分配bug至对应的模块开发人员。
开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。
不能解决的Bug，要留下文字说明及保持Bug为Open状态。
对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决，置Bu
升级会员 