测试面试题 二代版本
1、B/S架构和C/S架构区别？
CS（Client/Server）响应速度快，安全性强，用户体验好，一般应用于局域网中，但是开发维护成本高，；BS（Browser/Server）可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢。所以有些单位日常办公应用BS，在实际生产中使用CS结构。
2、HTTP协议？
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
3、POST与GET区别？
1、GET使用URL或Cookie传参。而POST将数据放在BODY中。
2、GET的URL会有长度上的限制，2kb，则POST的数据则可以非常大。
3、POST比GET安全，因为数据在地址栏上不可见。
4、一般get请求用来获取数据，post请求用来发送数据。
4、Cookie和Session的区别与联系？
1、存储位置不同
Cookie 的数据信息存放在客户端浏览器上。
Session 的数据信息存放在服务器上。
2、存储容量不同
单个cookie 保存的数据<=4KB,一个站点最多保存20个cookie。
对于session来说并没有上限，但出于对服务器端的性能考虑，
Session 内不要存放过多的东西，并且设置session删除机制。
3、存储方式不同
Cookie中只能保管ASCII字符串，并需要通过编码方式存储为Unicode字符或者二进制数据。
Session中能够存储任何类型的数据，包括且不限于string,integer,list,map等。
4、隐私策略不同
Cookie对客户端是可见的，别有用心的人可以分析放在本地的
Cookie并进行cookie欺骗，所以它是不安全的。
session存储在服务器上，对客户端是不透明的，不存在敏感信息泄漏的风险。
5、跨域支持上不同
Cookie 支持跨域名访问。
Session不支持跨域名访问。
5、测试的目的？
软件测试的目的就是在已经规定好的条件下，对该软件进行测试，通过测试去发现软件中程序的错误或者是BUG，这样可以让程序员衡量软件的质量，然后对软件是否满足最初的要求或者初衷做出一个正确的判断。
6、软件测试原则？
一、测试显示软件存在缺陷
测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。
二、穷尽测试是不可能的
现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。
三、测试尽早介入
为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。
四、缺陷集群性（2/8原则）
缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中。
一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。
五、杀虫剂悖论
反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。
为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。
测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。
六、测试活动依赖于测试内容
根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。
七、没有错误是好是谬论
有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足用户的需求，即便找到和修复了缺陷也作用不大。
7、软件测试分为哪几个阶段？
软件测试分类
按照阶段
单元测试：是指对软件中的最小可测试单元进行检查和验证
集成测试：集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。
系统测试：指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
验收测试：以用户为主的测试，软件开发人员和质量保证人员参加
按照是否查看源代码划分
白盒测试:指的是把盒子盖打开，去研究里边源代码和程序结构(单元测试，ui/接口自动化测试)
黑盒测试:把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
功能测试：
逻辑功能测试:测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录,登录之后才能看我的购物车
界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容
易用测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适
安装测试:安装磁盘空间不足，安装中断(关闭程序，关机，，)下次安装时是否继续上次的安装等。。。
兼容测试:硬件兼容性测试和软件兼容性测试（硬件兼容性:比如一款软件在pc机，笔记本,主机上是否兼容，软件兼容性测试:比如一款软件在window8和window10上是否兼容）
性能测试：
时间性能测试： 一个事物的响应时间
空间性能测试： CPU内存
一般性能测试：软件正常运行，不向其施加任何压力的测试
稳定测试: 也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定程度
负载测试: 让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。（测试载重）
压力测试: 持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。（测试强度）
其他：
回归测试：回归测试是指修改了旧代码后，重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
冒烟测试：指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
随机测试：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误
8、单元测试与集成测试的侧重点？
单元测试：系统的模块，包括子程序的正确性验证等。
集成测试：模块间的衔接以及参数的传递等。
9、系统测试范围？
黑盒测试。不接触代码，只对整个系统做功能的测试和性能的测试。
10、a测试与ß测试的区别？
- α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。
- 经过α测试调整的软件产品称为β版本。β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见
11、验收测试怎么做？
验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，测试试图尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助，并保证系统或软件产品最终被用户接受。主要包括易用性测试、兼容性测试、安装测试、文档（如用户手册、操作手册等）测试等几个方面的内容。
验证软件的功能和性能符合用户期待。
12、白盒、黑盒和灰盒测试区别？
黑盒测试
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。
白盒测试
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。
灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
13、冒烟测试的目的？
冒烟测试就是在软件建立后，对系统的 基本功能进行简单的测试。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。SmokeTest优点是节省测试时间，防止软件失败。缺点是覆盖率还是比较低。
14、回归测试怎么做？
回归测试，即就是在软件生命周期中，只要软件发生了改变，就可能给该软件产产生问题;所以，每当软件发生变化时
1、在测试策略制定阶段，制定回归测试策略
2、确定需要回归测试的版本
3、回归测试版本发布,按照回归测试策略执行回归测试
4、回归测试通过，关闭缺陷跟踪单（问题单）
5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
15、全部回归与部分回归的区别？
全量回归：对软件新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了。
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响
16、需求分析的目的？
澄清需求，提取测试点
17测试计划的目的？
规划软件测试内容，方法和过程
18、什么时候开始写测试计划？
需求分析之后
19、由谁来编写测试计划?
测试经理或测试组长
20、测试计划的内容？
测试背景
测试目的
确定测试范围
制定测试策略（功能测试/业务测试..）
测试资源安排
测试时间安排
测试人员分配
风险评估
21、结束条件(项目上线的条件)？
需求的覆盖率、用例的执行率和缺陷的遗留率达到质量目标。
通常来说：需求覆盖率和用例执行率需要达到100%只是理论上来说
致命/严重的缺陷需要当天解决，轻微/一般遗留率不得超过30%
22、常见的测试风险？
需求风险
测试用例风险
缺陷风险
代码质量风险
测试环境风险
测试技术风险
回归测试风险
沟通协调风险
研发流程风险
其他不可预计风险
23、测试用例的要素？
用例编号，所属模块，用例描述，前置条件，优先级，输入数据，操作步骤，预期结果，实际结果，测试人员，测试时间
测试用例级别的划分？
高（Highs）：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。
中（Mediums）：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计
低（Lows）：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别。
24、怎样保证覆盖用户需求？
项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；用例编写完之后，再进行用例的评审，看看测试点有没有遗漏，对需求理解有没有错误，测试场景是否覆盖完全。
25写好测试用例的关键 /写好用例要关注的维度？
覆盖全面，工作量小，目的明确，易于维护，描述清晰
26、测试用例的状态？
No Test 未执行状态；Pass 通过状态；Fail 失败状态；Block 阻碍状态；Investigate 观察中状态
27、常见的测试用例设计方法？
等价类划分
多用于输入框：注册/登录
边界值（掌握上点和离点的取值）
多和等价类划分结合使用，有边界限制的:注册的密码长度，
场景法
从基本流开始，再将基本流和备选流结合起来，可以确定用例场景
正交表
用于多个下拉框之间的组合，可以通过正交助手生成测试用例
错误推测
错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。
一般这种方法是基于经验和直觉推测程序中可能发现的各种错误，有针对性地设计。只能作为一种补充
因果图
因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出
28、判定表用在哪些时候/哪些功能？
判定表方法是黑盒测试方法的一种，主要用于输入和输出比较多，功能逻辑比较复杂的情况，通过画出判定表缕清需求中的功能逻辑，还能确保找到输入的所有组合情况
29、什么时候用到场景法？
平常在冒烟测试中或者一些流程性比较强的软件/功能（比如安装，卸载等等）
30、测试环境怎么搭建的？
安装jdk,tomcat,jenkins(话术)
安装jdk，tomcat（配置环境）
1:从公司的工具库中拿到jdk.tar，tomcat.tar包
2：通过远程连接工具(ssh/xshell)连接Linux服务器，将jdk和tomcat上传到服务器上
3：首先解压jdk.tar包（tar -xvf）,将解压的之后的jdk路径填写在配置文件中
4：重启配置文件
5：通过Java -version 判断是否安装成功，安装成功则显示jdk的版本信息(1.8.0的版本)
6：jdk配置成功之后，接下来解压tomcat.tar包(tar -xvf )
7:开放8080端口
8：在tomcat中的bin目录在，启动(./startup.sh)，
9：在游览器中输入ip:8080,可以检验tomcat是否成功启动(如果tomcat没有启动，可以通过ps -ef | grep tomcat 查看tomcat进程是否开启，如果没有开启，，再次执行启动tomcat命令)
项目部署（web端项目）
1:将开发的压缩包(.tar),解压之后，放到tomcat中的webapps目录下，重启tomcat(./startup.sh)
2:在游览器中输入ip:8080/解压后名称，查看项目
安装MySQL
1:从公司的工具库中拿到mysql.tar包
2：通过远程连接工具(ssh/xshell)连接Linux服务器，将mysql压缩包上传到服务器上
3：解压mysql.tar包（tar -xvf ）
4:解压后的rpm文件,分别进行客户端和服务端的安装(rpm -ivh)
5：启动mysql（service mysql start）
6:将mysql加到系统服务中并设置开机启动
7:登录mysql(msyql –u root -p)
8:修改密码(set password = password('xxx');)
9:需要设置开启远程登录mysql的权限
10:开放Linux的对外访问的端口3306
11:通过连接MySQL工具（navicat）直接访问
31、偶然性问题的处理？
1. 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2. 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3. 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4. 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5. 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。
32、当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
1、需求不确定
可以找来产品经理进行确认需不需要改动，三方商量确定好后再看要不要改。
2、这种情况不可能发生，所以不需要修改
这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以把这个问题提出来，跟开发经理和测试经理进行确认，如果要修改就改，如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
33、产品在上线后用户发现bug，这时测试人员应做哪些工作？
追查原因及处理方法：这个BUG出现的原因是什么。
测试环境无法重现：可能是线上的环境造成的BUG或者是测试环境无法模拟的情况。
解决方法：尽量完善测试方法、尽量模拟测试环境、增加线上测试。
漏测：
a.测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例
解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。
b.测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏。
解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为偷懒漏测，还是因为负责模块过多漏测，还是有其他原因，对该名测试人员发出警告，对相关测试主管，项目经理，产品经理发出警告。
c.测试用例覆盖不全：由于用例评审的不严格造成的；中途需求变更造成的；由于某些其他因素造成的。
解决方法：找到原因，并进行记录，在以后的项目或者下一版本重点关注。
最最重要的：补测试用例！
34、二八定理？
80%的缺陷出现在20%的代码中；80%的BUG发现在20%的时间中；80%的花费在20%的错误代码上。
35、如何跟踪缺陷？
当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间（间隔一个小时，或两个小时都可以）其检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。
36、缺陷的状态？
激活状态(Active或Open)。
已修正状态(Fixed或Resolved)。
关闭或非激活状态(Close或Inactive)
37、缺陷的等级？
A类—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等
B类—严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件
C类—一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等
D类—较小错误的软件缺陷（Minor）:使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚
E类- 建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。
38、缺陷单应该包含这些要素？
1缺陷发现人 2缺陷发现时间 3缺陷状态 4缺陷的严重程度 5缺陷所属软件的版本 6缺陷修改时间
39、测试报告的主要内容？
测试项目背景介绍，测试计划，测试结果及发现，测试分析摘要
40、如何定位bug：？
首先是前台UI界面，我所提到的界面，包括界面的显示，兼容性，数据提交的判断以及页面的跳转等等，这些bug基本都是一眼可见的，不太需要定位。
当然也不排除一些异常情况，也就是原始数据本身在传导过来的时候就有问题，所以显示会出问题的情况，这个时候就需要直接责任到人。
后台程序的BUG，这个概念则包括前台调用的接口，中间层缓存和转发数据，定时任务脚本异步处理数据，程序之间的相互调用等等，而这些bug往往都是不可见的，有可能在功能上体现。
后台程序的BUG也有可能隐藏在不易发现的深处，这个时候就要通过一些辅助工具以及人工的判断去定位了。
41、开发没时间修复，如何推进bug的修复：？
a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性
b) 可以和开发人员列举一个之前的类似问题，为开发提供参考
c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。
2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改
3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案
4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题
42、软件测试流程？
立项(确定项目)--编写需求(需求人员)--需求评审(编写需求人员发起)----开发：编写概要和详细设计--- 编码并自测(开发环境) ---测试: 测试用例--测试用例评审(测试人员发起)------------部署环境(linux)---冒烟测试(通过)--提交bug---回归测试(测试报告)--验收测试--上线
43、项目介绍？
44、对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计？
功能，性能，安全，易用，界面
45、在项目中发现哪些经典bug？什么原因导致的？
页面刷新图片不显示，开发人员疏忽导致
46、一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由？
可以留下百分之多少不通过
47、在需求文档不太详细的情况下，如何开展测试？
查阅文档，可以参考一些行业知识的书籍，文档。这对理解系统也有很大的好处。
根据经验和常识猜测：既然没有需求，那可以推测
你还需要具备良好的软件知识
最后加上主观判断
48、如何尽快找到软件中的bug?
1尽快熟悉公司业务
2把自己当成用户
3善于怀疑
4在测试中要跟踪一条数据的完整流程
5软件的边界值
6非法容错性
7软件接口测试
8兼容性测试
9随机测试
10学习他人经验
49、什么是bug？
现在人们将在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题统称为bug（漏洞）
50、ATM机吞卡的吞卡现象是不是BUG?
不一定，看是什么情况下吞卡。如：输入三次密码错误吞卡是正常的，不属于Bug;若输入一次密码错误吞卡则是不正常的属于Bug.
51、如何减少非问题单的提交？
1熟悉项目需求，充分了解各个功能模块的功能，参数，约束条件，弄清存在数据交互的模块之间的数据来源，数据流向；
2跟产品确认该问题是否属于非问题单。
52、有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
将程序放在其他的windows上运行，如果运行的还是很慢则是程序的问题
53、你们发现bug会怎么处理？
查看日志，提交bug到管理工具中
