测试面试题

测试的目的

软件测试的目的是为了保证软件产品的最终质量，在软件开发的过程中，对软件产品进行质量控制。一般来说软件测试应由独立的产品评测中心负责，严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，对测试记录进行分析，并根据回归测试情况撰写测试报告。测试是为了证明程序有错，而不能保证程序没有错误

软件测试原则

1、所有测试的标准都是建立在用户需求之bai上的，测试的目的在于发现系统是否满足规定的需求。
2、尽早的和不断的测试，越早进行测试，缺陷的修复成本就会越低。
3、程序员应避免检查自己的程序，由第三方进行测试更客观有效。
4、穷举测试是不可能的。
5、充分注意测试中的群集现象，一段程序中一发现的错误数越多，其中存在的错误概率越大，因此对发现错误较多的程序段，应进行更深入的测试。
6、设计测试用例时应包括合理输入和不合理输入，以及各种边界条件、特殊情况下要制造极端状态和意外状态。
7、注意回归测试的关联系，往往修改一个错误会引起更多错误。
8、测试应从“小规模”开始，逐步转向“大规模”。
9、测试用例式设计出来，不是写出来的，应根据测试的目的，采用相应的方法设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性。
10、重视并妥善保存一切测试过程文档（测试计划，测试用例，测试报告等）

软件测试分为哪几个阶段？

单元测试：单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。
集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。
系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。
验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。

单元测试与集成测试的侧重点

单元测试的重点是系统的模块，包括子程序的正确性验证等。
集成测试的重点是模块间的衔接以及参数的传递等。

系统测试范围

分为：单元测试，集成测试和系统测试。
单元测试：纯代码的测试（白盒测试）。主要测试代码语句的正确性，如所有的代码是否都可以跑到，是否有冗余的代码等等。
集成测试：接口测试（灰盒测试，结合白盒和黑盒测试）。主要测试代码块之间的接口。看看数据的传输是否有问题。
系统测试：黑盒测试。不接触代码，只对整个系统做功能的测试和性能的测试。
以上的三中测试是在项目组中测试的。
确认测试：是客户做的测试。也可以叫做验收测试。客户对他提出的需求，对应要交付的软件看看是否达到其要求。
回归测试只是说，你第一次测试出的问题，开发修改好后，你再去测试他们是否改好了。这个就叫做回归测试。

a测试与ß测试的区别

它们都是验收测试！
α测试是指把用户请到开发方的场所来测试
β测试是指在一个或多个用户的场所进行的测试。
α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。
β测试的环境是不受开发方控制的, 用户数量相对比较多,时间不集中。

验收测试怎么做？

制定测试计划，测试项，测试策略及验收通过准则，并经过客户参与的计划评审。
建立测试环境，设计测试用例，并经过评审。
准备测试数据，执行测试用例，记录测试结果。
分析测试结果，根据验收通过准则分析测试结果，作出验收是否通过及测试评价。 测试项目通过； 测试项目没有通过，并且不存在变通方法，需要很大的修改； 测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进； 测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说明清楚，应该修改测试计划。
提交测试报告。

白盒、黑盒和灰盒测试区别

白箱测试或白盒测试(White-box testing 或glass-box testing)是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。
　　黑箱测试或黑盒测试(Black-box testing)是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。通常测试人员在进行测试时不仅使用肯定出正确结果的输入数据，而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据。
　　灰箱测试或灰盒测试(Gray-box testing):灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能。

冒烟测试的目的

针对每个版本或每次需求变更后，在正式测试前，对产品或系统的一次简单的验证性测试。
为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。
最好的方法，设计出自动化测试脚本，每一次版本更新后都可以去执行脚本验证一下

回归测试怎么做？

1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷跟踪单（问题单）
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

全部回归与部分回归的区别？

对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全部回归；
当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。

需求分析的目的

第一、把用户需求转化为功能需求：
1）对测试范围进度量
2）对处理分支进行度量
3）对需求业务的场景进行度量
4）明确其功能对应的输入、处理和输出
5）把隐式需求转变为明确。
第二、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解

测试计划的目的

测试计划描述所要完成的测试，包括测试背景、测试目的、风险分析、所需资源、任务安排和进度等：
（1）将需求和总体设计分解成可测试，应该测试，推迟测试和无法测试的范围
（2）对每个范围制订测试的策略和方法
（3）制订release和停止测试的标准
（4）准备测试所需要的环境
（5）确定测试风险
（6）确定软件测试目标
（7）确定测试所需要的资源其其他相关信息
（8）制订测试进度和任务安排

什么时候开始写测试计划

测试计划都是在需求形成文档时候开始的,也就是常说的软件需求分析阶段就开始,因为从这个时候就要进行需求测试了。

由谁来编写测试计划

1.项目经理
项目经理当然是从整个项目角度出发，编写整体项目计划，那么其中就包括测试的计划了，他依赖于对应的开发计划，也就是首先要有开发计划、提测计划，再评估测试计划，最终得出上线时间
2.测试经理
测试经理主要是从测试组角度出发，编写项目的测试计划，重点就是项目的任务拆分、合理的安排人力资源、预估时间和风险等
3.测试人员
测试同学本人收到测试经理同步过来的具体分工后，也需要编写自己的测试计划，重点就是详细的说明自己的时间规划、每一个测试任务的前期准备以及开始和结束测试的时间等

测试计划的内容

1.简介
2.参考文档和提交文件
3.进度安排
4.测试资源
5.严重程度和优先级
6.风险分析
7.测试策略

结束条件(项目上线的条件)

1) 软件系统在进行系统测试过程中，发现一、二级缺陷数目达到项目质量管理目标要求，测试暂停返回开发；
2) 软件项目在其开发生命周期内出现重大估算和进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据；
3) 如有新的需求变更过大，测试活动应暂停，待原测试计划和测试用例修改后，再重新执行测试；
4) 若开发暂停，则相应测试也应暂停，并备份暂停点数据；
5) 所有功能和性能测试用例100％执行完成； 此外，测试是有成本的，当你2周发现2个bug有类似此种情况时，在产品质量要求不是十分严格的情况下，即可以停止测试了。

常见的测试风险

需求风险
测试用例风险
缺陷风险
代码质量风险
测试环境风险
测试技术风险
回归测试风险
沟通协调风险
研发流程风险
其他不可预计风险

测试用例的要素

1、用例编号
2、测试项目
3、测试标题
4、重要级别
5、预置条件
6、测试输入
7、操作步骤
8、预期结果

测试用例级别的划分

测试用例的重要级别如何划分， 那些用例是高等级， 中等级，低等级

测试用例优先级的目的：测试用例优先级可以用来方便地基于测试策略来筛选用例。
比如某块功能改动小，就只用测高或中高优先级的用例。
比如冒烟测试的时候我们只需要筛选优先级最高的用例执行即可。

根据我们测试用例优先级目的：那么优先级越高的测试用例覆盖的测试点应该是用户最关心的，  
比如一个注册功能， 能够注册成功这个用例的优先级就是最高的（但是不是所有的注册成功的case都是优先级最高，只需要挑选一个即可），
 其他各种异常校验都是次要优先级的，  还有一些场景覆盖的测试点很难出现，或者叫就算有问题影响也不大， 可以放到低优先级

怎样保证覆盖用户需求？

写好测试用例的关键 /写好用例要关注的维度

测试用例的状态

排队（In Queue）
进行中（IP）
阻塞（Block）
跳过（Skip）
通过（Pass）
失败（Fail）
警告（Warn）
关闭（Close）

常见的测试用例设计方法

等价类划分，边界值，错误推测，因果图，场景法，正交表

应用的场景
等价类划分
多用于输入框：注册/登录
边界值（掌握上点和离点的取值）
多和等价类划分结合使用，有边界限制的:注册的密码长度，，
场景法
从基本流开始，再将基本流和备选流结合起来，可以确定用例场景
正交表
用于多个下拉框之间的组合，可以通过正交助手生成测试用例
错误推测
错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。
一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充
因果图
因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出

判定表用在哪些时候/哪些功能

什么时候用到场景法

流程图：矩形（表示步骤，操作，结果）
菱形（判断-是，否）
注意：场景法的重点是测试流程，因此每个流程一个用例验证即可，流程测试没有问题并不能说明系统功能么有问题，还需要针对单步的功能进行测试
只有单个功能和测试流程，才算充分的测试

测试环境怎么搭建的？

偶然性问题的处理

当我们认为某个地方是bug，但开发认为不是bug，怎么处理？

1.首先我会从自身去经过多次的测试发现BUG出现的次数和频率 记录复现BUG的方式 然后发送给开发人员
2.再根据需求文档来确认是否为BUG
3.如果开发不认为是BUG的 将复现BUG的记录和需求文档找产品经理和项目经理来确定是否BUG
4.如果项目经理和产品经理都不认为是BUG 我会将BUG记录在测试文档中 方便在下次评审会上将问题再次抛出

产品在上线后用户发现bug，这时测试人员应做哪些工作？

1.测试人员复现问题后，提交问题单进行跟踪；
2.评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
3.问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
4.总结经验，分析问题发生的原因，避免下次出现同样问题。

二八定理

如何跟踪缺陷

在执行用例的过程中发现了跟预期实际不符的情况，就提交缺陷,跟踪缺陷修改，跟踪缺陷流程主要有四个(一个正常的修改结束的流程，三个特殊处理流程)
新建 – 开启 – 修改 – 关闭 提交缺陷后开发人员确认修改后回归通过；
新建 – 拒绝 开发人员未确认缺陷拒绝修改，这个时候需要在确认需求理解正确(跟产品确认)和复现步骤(多次复现)的基础上, 跟开发人员沟通是否需要修改；
新建 – 开启 – 修改 – 重开 修改后提交的版本回归不通过，这是需要重新打开缺陷,为了加快缺陷正确修改，可以跟开发人员沟通，协助开发人员定位缺陷；
新建 – 开启 – 延期 部分开启的缺陷，由于无法复现, 难以修改，进度压力等原因,可能需要延期修改，这个时候，是否延期，是需要多方确认的(测试、产品、开发、领导)。

缺陷的状态

New（新的）：bug提交到缺陷库中会自动的被设置成New状态
Assigned（已指派）：当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”
Open（已打开）：开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug”
Fixed（已修复）：当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组
Rejected(被拒绝)：测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”
Postponed（延期）：有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”
Closed（已关闭）：测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed”
Reopen（再次打开）：如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”

缺陷的等级

bug缺陷等级一般划分为四个等级，致命、严重、一般、提示
致命（一级bug） 通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。
比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。
严重（二级bug） 通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
比如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误。
一般（三级bug）通常表现为：界面、性能缺陷。
比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。
提示（四级bug） 通常表现为：易用性及建议性问题
比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范

缺陷单应该包含这些要素

缺陷标题，缺陷描述，重现步骤，预期结果，实际结果，缺陷优先级，缺陷严重程度，附件

测试报告的主要内容

概述、测试过程、功能实现清单、测试统计、测试总结及测试风险
概述：一般会在概述中添加项目背景、需求描述等信息。
测试过程主要包含评审记录、测试范围、测试用例
罗列出是否已按本次测试计划实现功能
包括资源统计、执行情况、问题统计、问题列表、遗留问题
主要总结本次测试测了哪些内容、用例覆盖程度、bug解决程度等，以及最终是否决定通过本次测试。
测试风险没有放在测试总结里，而是单独划分为一个模块，可见其重要性。

如何定位bug：

开发没时间修复，如何推进bug的修复：

软件测试流程

项目介绍

对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计

在项目中发现哪些经典bug？什么原因导致的？

一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

在需求文档不太详细的情况下，如何开展测试？

如何尽快找到软件中的bug?

开发基本不自测，甚至没有自测的环境，特别是涉及多个系统的对接。
提测后很多基本的功能都不能正常使用。
项目管理比较混乱，但是最终的发布日期又被项目经理定死，所以测试时间常常被压缩。
没有对于开发人员的质量方面的考核

什么是bug？

BUG是指，系统发生错误或者有缺陷漏洞。

ATM机吞卡的吞卡现象是不是BUG?

不是
是特意设置的安全措施
防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱款
所以特意设置了倒计时，限时内没有取走银行卡就会吞卡

如何减少非问题单的提交？

有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？

1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等
2、检查软件/硬件的配置是否符合软件的推荐标准
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况

你们发现bug会怎么处理。