1、B/S架构和C/S架构区别？
所谓的软件架构我们可以理解为是用来指导我们软件开发的一种思维，目前来说最常见的两种架构模式就是b/s c/s
b-browser浏览器
c-clent 客户端
s-server 服务端
两种架构的比较
1.标准:相对于 cs 架构来说bs架构的两端都是在使用现成的成熟产品，所以bs会显示的标准些。
2,效率:相对bs架构来说cs中的客户端可以分担一些数据的处理，因此执行效率会高一些
3,安全: bs架构当中得到数据传输都是以HTTP协议进行的输出，而HTTP协议又是明文输出。可以被抓包，所以相对于cs架构来说bs就显得不那么安全(相对的)
4,升级: bs架构只需要在服务器端将数据进地更新，前台只需要刷新页面就可以完成升级，而cs架构当中必须要将两端都进行更新
5,开发成本:相对于bs架构来说cs当中的客户端需要自己开发，所以相对于来说成本会高一些
2、HTTP协议
http协议又叫做超文本传输协议，在做网络请求的时候，我们基本上是使用http协议。
http协议包括请求和响应。
请求中包括:请求地址，请求方式，请求方式包括get请求和post请求，get和post的区别是get请求是在地址栏后边跟随请求参数，但是请求参数大小是有限制，不同浏览器是不同的。一般是4KB. post 请求主要用于向服务器提交请求参数。post请求的多数是液知清求实体内容中的，相对get请求较为安全些。
另外，请求中会有各种请求头信息，比如支持的数据类型，请求的来源位置。以及Cookie头等相关头信息。
响应，主要包含响应的状态码，像200（）、404（）、500（）、304（）、307（）
还有各种响应头信息，比如设置缓存的响应头，Content-Trpe 内容类型，设置Cookie头信息。
3、POST与GET区别
1.Get是不安全的，因为在传输过程，数据被放在请求的url中；POST的所有操作对用户来说都是不可见的。
2. Get传送的数据量较小，这主要是因为受URL长度限制；Post传送的数据量较大，一般被默认为不受限制。
3. Get限制Form表单的数据集的值必须为ASCII字符；而Post支持整个ISO10646字符集。
4. Get执行效率却比Post方法好。Get是form提交的默认方法。
4、Cookie和Session的区别与联系
Cookie是把数据保存在浏览器端的内存中
Session把数据保存在服务器端的内存中
cookie与session的联系：
1、Cookie仅由客户端生成、管理并使用，PHP只是发出指令要求客户端如何生成Cookie、何时过期等，但是客户端不一定会按照PHP的指令办事。
2、如果没有设置Cookie过期时间，Cookie会一直以文件或SQLit等DB形式存在客户端磁盘。
3、Session是用户进入某个网站到关闭浏览器这段时间的会话，默认以文件形式存在服务器磁盘，所以设置过多的Session会影响磁盘IO，也可以用Memory引擎存入MySQL，因为内存引擎读写速度快，现在也可以指定用Redis来处理Session，这样更快，效率更高。
4、Session的收回机制是被动的，shenzhen.offcn.com如果设置了生存周期，一般来说，一旦关闭浏览器Session也就被PHP自动回收了，但有时即使设置了过期时间并且关闭浏览器并不一定会删除Session，比如设置多目录多层级保存Session时，这时需要通过PHP脚本手动删除Session。
5、通常Cookie与Session是绑定的，即用户在没有禁用Cookie时，Cookie一般会保存sessionID及Session生存周期，如果用户删除Cookie一般会退出系统;如果没有禁用Cookie关闭浏览器Session也会立即失效，要重新登录系统。
6、Cookie与Session一般应于标识用户、权限认证、存储简单数据、还有就是利用P3P实现Cookie跨域单点登录(SSO：Single Sign On)。
5、测试的目的
1）软件测试是为了发现错误而执行程序的过程。
2）测试是为了证明程序有错，而不是证明程序无错。（发现错误不是唯一目的）
3）一个好的测试用例在于它发现至今未发现的错误。
4）一个成功的测试是发现了至今未发现的错误的测试。
6、软件测试原则
1、所有测试的bai标准都是建立在用户需求之上的，测试的目的在于发现系统是否满足规定的需求。
2、尽早的和不断的测试，越早进行测试，缺陷的修复成本就会越低。
3、程序员应避免检查自己的程序，由第三方进行测试更客观有效。
4、穷举测试是不可能的。
5、充分注意测试中的群集现象，一段程序中一发现的错误数越多，其中存在的错误概率越大，因此对发现错误较多的程序段，应进行更深入的测试。
6、设计测试用例时应包括合理输入和不合理输入，以及各种边界条件、特殊情况下要制造极端状态和意外状态。
7、注意回归测试的关联系，往往修改一个错误会引起更多错误。
8、测试应从“小规模”开始，逐步转向“大规模”。
9、测试用例式设计出来，不是写出来的，应根据测试的目的，采用相应的方法设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性。
10、重视并妥善保存一切测试过程文档（测试计划，测试用例，测试报告等）。
7、软件测试分为哪几个阶段？
软件测试可分为单元测试、集成测试，系统测试和验收测试。
单元测试：按模块划分后的颗粒度进行分类测试（单个功能的测试 如：crud 分页 上传下载）
集成测试：功能模块的测试（将多个功能点进行总结在一起）
系统测试：多个模块合成测试(整体测试)
验收测试：客户以及产品经理进行(交付前的测试)
8、单元测试与集成测试的侧重点
单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。
集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起shu也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。
9、系统测试范围
功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等
10、a测试与ß测试的区别
α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。
β测试是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。β测试主要衡量产品的FLURPS，着重于产品的支持性，包括文档，客户培训和支持产品生产能力。 只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。
11、验收测试怎么做？
在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。
验收测试的目的：确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试的参与者：用户，还可能有软测工程师等。
12、白盒、黑盒和灰盒测试区别
黑盒和灰盒的区别：
如果某软件包含多个模块，当使用黑盒测试时，你只要关心整个软件系统的边界，无需关心软件系统内部各个模块之间如何协作。而如果使用灰盒测试，则需要关心模块与模块之间的交互。
白盒和灰盒的区别：
在灰盒测试中，你无需关心模块内部的实现细节，对于软件系统的内部模块，灰盒测试依然把它当成一个黑盒来看待。而白盒测试还需要再深入地了解内部模块的实现细节和各个分支。
13、冒烟测试的目的
为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。
14、回归测试怎么做？
1）重点测试软件中被修改的部分；
（2）从原基线测试用例库中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库。
（3）依据一定的策略从测试用例库中选择测试用例测试被修改的软件。
（4）如果必要，生成新的测试用例集，用于测试无法充分测试到的软件部分。
（5）用新软件测试用例集执行修改后的软件。
15、全部回归与部分回归的区别？
全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。
16、需求分析的目的
产品需求也不等于是测试需求。没有测试需求分析，会导致我们的信息不完整、不准确，无法对所测产品有一个清晰全面的认识。所以，我们要先进行测试需求分析，在这个基础上，再进行后面的测试设计，测试计划等工作。
17、测试计划的目的
编写软件测试计划的目的是指导测试组成员进行工作和让测试组以外的项目成员了解测试工作的。
18、什么时候开始写测试计划
我这边的测试计划都是在需求形成文档时候开始的,也就是常说的软件需求分析阶段就开始,因为从这个时候就要进行需求测试了。
19、由谁来编写测试计划
需要编写测试计划的人员有：项目经理、测试经理、测试人员，他们将根据每个所处的位置编写相应的测试计划，下面我们看下每个人写的主要内容是哪些？
1.项目经理
项目经理当然是从整个项目角度出发，编写整体项目计划，那么其中就包括测试的计划了，他依赖于对应的开发计划，也就是首先要有开发计划、提测计划，再评估测试计划，最终得出上线时间
2.测试经理
测试经理主要是从测试组角度出发，编写项目的测试计划，重点就是项目的任务拆分、合理的安排人力资源、预估时间和风险等
3.测试人员
测试同学本人收到测试经理同步过来的具体分工后，也需要编写自己的测试计划，重点就是详细的说明自己的时间规划、每一个测试任务的前期准备以及开始和结束测试的时间等
20、测试计划的内容
1.简介
2.参考文档和提交文件
3.进度安排
4.测试资源
5.严重程度和优先级
6.风险分析
7.测试策略
21、结束条件(项目上线的条件)
1、软件经过充分的测试
开发人员测试---〉交叉测试---〉测试人员测试---〉用户的业务专家测试---〉一定数量的用户业务专家集中测试---〉上线前试运行----〉上线。
压力测试是必须的
2、用户培训
管理员，一定厂或地区必须有一个人经过了培训。
3、基础数据导入完成
用户、组织机构、业务数据等基础必须数据导入完成。
4、授权必须完成
5、新老系统的切换必须提前演练过，各种老数据的导入工作完成。
6、应急方案必须有。
22、常见的测试风险
需求风险
测试用例风险
缺陷风险
代码质量风险
测试环境风险
测试技术风险
回归测试风险
沟通协调风险
研发流程风险
其他不可预计风险
23、测试用例的要素
用例编号,所属模块,测试标题,重要级别,前置条件,测试输入,操作步骤,预期结果。以及编写测试用例时的注意事项。
24、测试用例级别的划分
概念：
有时候会听到0级别case的说法，其实这是对具有一定优先级的测试用例的说法。在实际测试实践中，测试用例根据重要性分成一定的等级。在不同的公司，可能测试用例的等级划分有所差异，但是基本大同小异。
又高至低依次为P0-P3
P0:核心功能测试用例（冒烟测试），确定此版本是否可测的测试用例，此部分测试用例如果fail会阻碍大部分其他测试用例的验证
P1:高优先级测试用例，最常执行以保证功能性是稳定的，基本功能测试和重要错误、便捷测试
P2:中优先级测试用例，更全面地验证功能的各个方面，异常测试，边界、中断、断网、容错、UI等测试用例
P3:低优先级测试用例，不常常被执行，性能、压力、兼容性、稳定性、安全、可用性等等
25、怎样保证覆盖用户需求？
1.确认需求、2.梳理需求，确认测试范围、3.制定测试计划、4.根据测试计划编写测试用例、5.执行测试步骤
26、写好测试用例的关键 /写好用例要关注的维度
1.测试前：
1.对测试目的有一个清晰的认知、2.熟悉产品的功能测试点、3.熟悉模块原理，避免“互相影响”问题的产生、4.关注用户场景问题和上网问题、
5.不可马虎的关键测试用例设计、
2.编写测试用例时：
1.构建测试用例框架、2.测试步骤的设计（一是如果步骤过于粗糙很容易出现漏测问题；二是写的过于细致，可能耗时耗力，并且会限制执行人员的思维。）
3.测试用例设计方法及思考
1.切记产品测试的主要目标、2.注意用词精准问题
27、测试用例的状态
排队（In Queue）：测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。
进行中（IP）：该测试正在进行，并且会持续一段时间。（如果一个测试所需要的时间少于一天，我就不会讲一个测试标为进行中，因为我每天会跟踪测试用例的状态）
阻塞（Block）：一些因素会导致测试不能进行到底，例如某个功能欠缺或者测试环境的某个部分欠缺。我通常会在测试用例总结工作表的意见栏记录下阻塞的状态。你可以把阻塞理解为：我希望运行测试，但是目前还不能运行测试。
跳过（Skip）：你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。（同样地，我会在测试用例总结工作表的意见栏记录下我跳过这个测试的原因。）你可以把跳过理解为：我现在可以运行这个测试，但是我不想运行它。
通过（Pass）：测试运行结束，测试人得到了预料中的测试结果状态和测试行为。
失败（Fail）：在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。
警告（Warn）：在很多情况下，测试人得到预料之外的测试结果，状态或行为，但是这些结果与测试目标差别不是很大（我通常会在测试包总结工作表的通过一栏记为警告，而不是另加一栏）。另一种想法是，警告意味着当前的错误是无关紧要的，或者对正在测试的特征是没有意义的。系统报出了更多的错。我处理这个问题的一个标准是只和延期的或不是一定要改的错误相关的测试可以标记为警告，而不是失败。
关闭（Close）：一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过，使得你可以跟踪测试在某一个测试发布中失败的实事（同标记为警告的测试一样，我在测试包总结工作表中将标记为关闭的测试也纳入成功的范畴）。
28、常见的测试用例设计方法
等价类划分法，边界值，场景法，因果图，正交表。
因用的场景：
等价类划分
多用输入框：注册？登入
边界值
多和等价类划分法结合使用，有便捷限制的:注册的密码长度
场景发
从基本流开始，再将基本流和备选流结合起来，可以确定用例场景
正交变
用于多个下拉框中间的组合，可以通过正交助手生成测试用例
错误推测
错误猜测发是测试经验丰富的人喜欢使用的一种测试用例设计方法
一般这种方法是基于经验和直觉推迟程序中可能发送的各种错误，有针对性地设计，
因果图
因果图法比较适合输条件比较多的情况，测试所以的输入条件的排列组合，所谓的原因就是输入，所谓的结果就是输出
29、判定表用在哪些时候/哪些功能
判定表方法是黑盒测试方法的一种，主要用于输入和输出比较多，功能逻辑比较复杂的情况，通过画出判定表缕清需求中的功能逻辑，还能确保找到输入的所有组合情况获得更多关于测试的知识，建议你去找视频学习一下，黑马程序员官网就有很多专业的视频，应该挺适合你的。
30、什么时候用到场景法
从基本流开始，再将基本流和备选流结合起来，可以确定用例场景
31、测试环境怎么搭建的？
搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。
32、偶然性问题的处理
一、一定要提交!!
1. 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2. 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3. 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4. 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5. 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。
二、程序不是测试人员写的，出问题也不是测试人员的原因。
至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。
测试人员的任务只是尽力重现问题，而不是必须重现!!
三、下次再遇到的时候，拉他们来看就可以了。
因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。
而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 : )
四、你可以告诉程序员，测试过程是没有错误的。
测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
需要让程序员理解，测试人员是帮助他们的，不是害他们的。
客户那里发现问题比测试员发现问题结果要严重的多。
五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。
在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。
问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。
实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现(比较严重的问题才如此处理，小问题经理之间商量商量可能就算了)。
至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现(仅仅出现一次)。
这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位(哼，程序有bug，是否可以说程序员工作不到位的呀)。
六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。
我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题。
其实只要自己尽到心就可以了，管别人怎么说呢。
七、我们使用的状态有：
程序员处理的状态(由测试员提交的Action)：等待处理的，再次出现的。
测试员处理的状态(由程序员提交的Action)：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。
经理处理的状态(由测试员提交Action)：管理员处理的。经理还可以删除记录。
按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。
最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”(由测试员或经理确认)和“暂不修改的”(比如下一个版本处理等)。
33、当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
1.找到需求文档或者是原型图进行匹对
2.尝试多种测试环境和多种测试方式来确认是否为bug
3.整理bug的复现的步骤和出现的频率
4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug
5.将客户经理 测试 测试经理和项目经理进行开确认会来判定是否为bug
6.测试人员需要将bug整理并写入测试总结中
34、产品在上线后用户发现bug，这时测试人员应做哪些工作？
首先要做的是重现这个问题并反馈给研发人员，尽快出patch或者解决方案。
当BUG解决且上线没有问题之后，我们再看后续的处理。
追查原因及处理方法：这个BUG出现的原因是什么。这有分为几种情况：
1）测试环境无法重现：可能是线上的环境造成的BUG或者是测试环境无法模拟的情况。
解决方法：尽量完善测试方法、尽量模拟测试环境、增加线上测试。
2）漏测：
a.测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例
解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。
b.测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏。
解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为偷懒漏测，还是因为负责模块过多漏测，还是有其他原因，对该名测试人员发出警告，对相关测试主管，项目经理，产品经理发出警告。
c.测试用例覆盖不全：由于用例评审的不严格造成的；中途需求变更造成的；由于某些其他因素造成的。
解决方法：找到原因，并进行记录，在以后的项目或者下一版本重点关注。
最最重要的：补测试用例！
35、二八定理
20%来源于代码，80%需求不明确产品需求经常变更
36、如何跟踪缺陷
新建，确认，解决，重新验证，关闭，重新打开
37、缺陷的状态
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”
38、缺陷的等级
系统崩溃，严重，一般，次要，建议
39、缺陷单应该包含这些要素
缺陷编号 缺陷标题 缺陷描述 重现步骤 严重程度 优先级 用例编号
40、测试报告的主要内容
测试报告包括哪些内容: 测试模块（每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少BUG、遗留多少BUG、解决多少BUG、追后对这个模块总结一下）
BUG的统计，根据时间轴来统计BUG的数量，例如：XXXX年X月X日，发现BUG多少，关闭BUG多少，剩余BUG多少，高级的BUG有多少，中级的BUG有多少，低级和建议的BUG有多少，一直罗列到项目完结
项目总结，汇报一下测试的大致结果。
遗留和风险，该软件还有什么遗留问题，还有什么风险，都要一一说明
最后评判该软件是否符合上线标准，日期，签字，加盖章等
41、如何定位bug：
①原始类(brute force)
②回溯类(backtracking)
③排除类(causeeliminations)
原始类定位方法是最常用也是最低效的方法，只有在万般无奈的情况下才使用它，主要思想是“通过计算机找错”。例如输出存储器、寄存器的内容，在程序安排若干输出语句等，凭借大量的现场信息，从中找到出错的线索，虽然最终也能成功，但难免要耗费大量的时间和精力。
回溯法能成功地用于程序的排错。方法是从出现bug征兆处开始，人工地沿控制流程往回追踪，直至发现出错的根源，不幸的是程序变大后，可能的回溯路线显著增加，以致人工进行完全回溯到望而不可及。
排除法基于归纳和演绎原理，采用“分治”的概念，首先确定所有与bug出现有关的所有数据，设想一个导致bug的原因，用这些数据证明或反驳它;或者一次列出所有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端，则立即精化数据，乘胜追击。
42、开发没时间修复，如何推进bug的修复
1、 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点
a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性
b) 可以和开发人员列举一个之前的类似问题，为开发提供参考
c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。
2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改
3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案
4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方的工作人员，反馈问题，尽量推动应用解决问题
小结
总之，bug修不修，测试应该有一个自己的原则，同时也要权衡利弊。不能因为推不动开发，就放弃，由着bug上线，也不能揪着一个小bug不放，影响上线时间。
43、软件测试流程
需求分析
制订测试计划
设计测试用例与编写
实施测试
提交缺陷报告
生成测试总结和报告
44、项目介绍
45、对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计
性能测试
能否正常书写是否有笔油泄露笔帽是否能正常按下弹起来
功能测试
一支笔可以用多少时间、写出的字是否褪色
易用性测试
笔的长短粗细是否顺手一根笔芯用尽是否方便更换
界面测试
外形是否美观时尚有趣
安全性测试
笔油是否含有有害物质笔尖是否容易伤到人笔油或者墨水保质期多长过期是否产生有害物质、
兼容性测试
在不同的温度、气压、和重力下能否正常使用在不同的纸质和力度下书写结果如何
三角形测试用例设计：
1、当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。
2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。
3、若是等边三角形，则打印：“等边三角形”。
4、画出程序流程图并设计一个测试用例。
因果图、等价类划分（推荐测试方法）
46、在项目中发现哪些经典bug？什么原因导致的？
编码的问题
接口限流防刷的时候，通过计数器限流，如果超过某个阈值，向前端返回一个codeMsg对象用于显示的时候，显示的是String是乱码的问题，之前由于一直返回都是json 格式，都是封装好在data里。
这次返回是直接通过输出流直接写到response直接返回字节数组的，而不是spring controller 返回数据（springboot 默认utf-8），出现乱码问题，用utf-8编码，解决。
比较难解决的bug无非就两种，一种就是程序的逻辑出现问题，导致得不到正确的结果，第二种就是一些中间件，开发环境的问题。
（1）如果是逻辑出现了问题，你项目比较大的话，那只能是通过单步调试，或者用System.out.println()打印出来想要得到的数据看看是哪步出了问题。
（2）如果是开发环境或者是中间件的问题，那只能是通过网上查阅资料来解决问题。如果你英语阅读能力还可以的话，我推荐使用Stack Overflow来查阅资料。
47、一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
48、在需求文档不太详细的情况下，如何开展测试？
出现以上的情况，如果仅仅想通过测试来提高软件质量，那几乎是不可能的，原因是没有足够的时间让你去测试，少而不规范的文档导致测试需求无法细化到足够且有针对行的测试。所以，作为公司质量保证的因该和项目经理确定符合项目本身是和的软件生命周期模型(比如RUP的建材，原型法)，明确项目的开发流程并督促项目组按照此流程开展工作，所有项目组成员（项目经理更加重要)都要制定出合理的工作计划，加强代码的单元测试，在客户既定的产品交付范围内，进行产品的持续集成等，如果时间允许可以再配合客户进行必要的系统功能测试。
49、如何尽快找到软件中的bug?
1.尽快熟悉软件的需求和业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷
2.把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗？
3.善于怀疑，不要开发人员的能力
4.不要让程序开发人员的观点：“用户不会进行这样的操作”而说服自己
5.使用完整的流程去测试软件系统，有些子流程在单独测试时没有问题，但按流程走的时候问题就可能出来了。
50、什么是bug？
bug是计算机领域专业术语，bug原意是“臭虫”，现在用来指代计算机上存在的漏洞，原因是系统安全策略上存在的缺陷，有攻击者能够在未授权的情况下访问的危害。
51、ATM机吞卡的吞卡现象是不是BUG?
不是，是特意设置的安全措施，防止有人马虎，操作后忘记取走银行卡而被人冒领卡中的钱款，所以特意设置了倒计时，限时内没有取走银行卡就会吞卡
52、如何减少非问题单的提交？
1、 缺陷的概要描述要清晰准确，要使相关开发负责人员能够一目了然问题是什么。
2、 一个完整的缺陷报告单，必须包含其必要的元素信息，例如：概要描述，缺陷发现人，测试环境，浏览器，缺陷重现步骤，严重等级，指派人，所属功能模块等等，必要元素信息必须描述全面清楚。
3、 缺陷的重现步奏必须描写清晰明了，使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷，使其定位缺陷的原因所在。
4、 指派给人一定要明确，如知道缺陷是所属具体的某一个开发人员时，应该直接指派给对应的负责人，这样就能减少中间分配环节的时间。
5、 测试数据，测试的数据作为重现缺陷的一个重要元素信息，一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。
6、 附件截图信息，附件或截图信息能让开发人员能够一目了然的清楚问题的所在，所以必要的时候提供附件或者截图信息也非常的重要。
7、描述缺陷内容的语气，在进行缺陷单书写时，尽量使用专业术语（体现测试的专业性），其次注意书写缺陷报告单时不要带有个人客观的语气内容，以免影响开发和测试人员之间的关系。
53、有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等
2、检查软件/硬件的配置是否符合软件的推荐标准
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况，
性能监视器打开方法：
一、【开始》运行】输入perfmon，回车
二、右键【计算机》管理】
54、你们发现bug会怎么处理。
一般测试员首先发现bug，然后提交bug，开发人员确认是否是bug，如果不是就拒绝修复，如果是就修复bug，测试员再对修复的bug进行验证，如果确实修复了就关闭bug，如果bug还存在就reopen。