1.B/S架构和C/S架构区别
1、CS响应速度快，安全性强，用户体验好，一般应用于局域网中，但是开发维护成本高，；
2、BS可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢
2http和https
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
3.POST与GET区别
get:get方法通过url请求传递用户的数据、不安全、传递数据量小
post：post是可以传递大量的数据、安全
4.Cookie和Session的区别与联系
1、Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。
2、Cookie有大小限制以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关。
3、Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击。
4、Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。
5.测试的目的
1、测试是为了发现错误而执行程序的过程
2、测试是为了证明程序有错，而不是证明程序无错误
3、一个好的测试用例是在于它能发现至今未发现的错误
4、一个成功的测试是发现了至今未发现错误的测试
6.软件测试原则
1、尽早的和不断的进行软件测试
2、程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成
3、程序用例由输入和预期的输出结果组成
4、程序修改后要回归测试
5、穷尽测试是不可能的
7.软件测试分为哪几个阶段？
单元测试：按模块划分后的颗粒度进行分类测试（单个功能的测试 如：crud 分页 上传下载）
集成测试：功能模块的测试（将多个功能点进行总结在一起）
系统测试：多个模块合成测试(整体测试)
验收测试：客户以及产品经理进行(交付前的测试)
8.单元测试与集成测试的侧重点
单元测试：按模块划分后的颗粒度进行分类测试（单个功能的测试 如：crud 分页 上传下载）
集成测试：功能模块的测试（将多个功能点进行总结在一起）
9.系统测试范围
多个模块合成测试(整体测试)
10.a测试与ß测试的区别
A法：输入-输出法，效率=电机输出机械功率/电机输入电功率，直接做电机负载试验即可zhuan获取结果。
B法：损耗分析及输入-输出法间接测量杂散损耗，效率的计算需要用到30余个参数进行综合运算评估，需要做电机温升试验、电机负载试验和电机空载试验来获取运算所需的基本参数。
11.验收测试怎么做？
1、制定测试计划，测试项，测试策略及验收通过准则，并经过客户参与的计划评审。
2、建立测试环境，设计测试用例，并经过评审。
3、准备测试数据，执行测试用例，记录测试结果。
4、分析测试结果，根据验收通过准则分析测试结果，作出验收是否通过及测试评价。 测试项目通过； 测试项目没有通过，并且不存在变通方法，需要很大的修改； 测试项目没有通过，但存在变通方法，在维护后期或下一个版本改进； 测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说明清楚，应该修改测试计划。
5、提交测试报告。
12.白盒、黑盒和灰盒测试区别
黑：纯功能测试（点点点/手动测试）
功能测试：
安装/卸载测试
界面测试：
易用测试：
兼容性测试
性能测试：
稳定性测试： monkey命令
压力测试
负载测试
一般性能测试 系统资源使用率
白：使用编程脚本进行测试 实现自动化
灰：介于黑和白之间
13.冒烟测试的目的
对软件的主要功能进行测试
14.回归测试怎么做？
对软件的新版本进行测试时，重复执行上一个版本测试时的用例，比如在1.0版本中，有一个bug，到了2.0版本中,再重新测试1.0中这个bug
15.全部回归与部分回归的区别？
对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全部回归；
当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。
16.需求分析的目的
1、把用户需求转化为功能需求：1）对测试范围进度量 2）对处理分支进行度量 3）对需求业务的场景进行度量 4）明确其功能对应的输入、处理和输出 5）把隐式需求转变为明确。
2、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。
17.测试计划的目的
1、测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。
2、成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷
18. 什么时候开始写测试计划
在项目开始后，在前期你需要了解测试的背景，范围和工作量，以及人员的分工，所需的资源，工期等，在这些了解清楚后开始撰写测试计划
19. 由谁来编写测试计划
测试计划一般由资深的测试人员来做， 要对整zhi体的项目有非常好的掌控，有丰富的测试经验的人员来编写测试计划。
20. 测试计划的内容
1.简介
2.参考文档和提交文件
3.进度安排
4.测试资源
5.严重程度和优先级
6.风险分析
7.测试策略
21.结束条件(项目上线的条件)
结束条件：
1.测试用例执行比例，一般功能测试用例全部执行完毕，非功能测试用例执行达95%以上
2.测试缺陷修改数量，一般及以上的用例全部修复并验证通过，已修复缺陷占比95%以上
3.测试覆盖需求程度，测试覆盖全部的需求且达到上线的要求或标准
上线条件：
1.编写目的：明确软件测试工作的开始和结束标准。
2.软件测试合格标准：以上比例为错误占总测试模块的比例。
3.缺陷修复率标准
1) A、B、C级错误修复率应达到100%
2) D级错误修复率应达到96%以上
4.覆盖率标准
测试需求执行覆盖率应达到100%（业务测试用例均以执行）。
5.错误级别
A级：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。系统崩或挂起等导致系统不能继续运行。
B级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。
C级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新启动该软件不属于更正办法）。系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题
22. 常见的测试风险
使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题
23. 测试用例的要素
1、用例编号
由字符和数字组合成的字符串，测试用例编号应该具有唯一性、易识别。
如系统测试的用例编号格式为：产品编号-ST-系统测试项名-系统测试子项名-xxx。（备注：每个公司对于用例书写的规则不尽相同，具体细则还需要参考公司配置命名规范）
2、所属模块
当前测试用例所在的测试大类或被测试需求、被测的模块、被测单元等
3、用例标题
描述简洁清晰，无歧义，要用概括的语言描述出Case的关注点，且每个用例的标题不可重复。
4、重要级别，即用例优先级
一般分为高、中、低。特殊项目可以自定义优先级别，目的是用例执行人员可参照此来安排执行时间。
5、前置条件
执行当前测试用例时需要的前提条件，若不满足此前提条件，则无法执行后边的测试步骤。前置条件并不是每个用例都需要的，视情况而定。
6、输入数据
测试用例在执行过程中需要输入的外部数据。依据用例具体情况，通常包含有手工录入、文件、DB记录等。
7、操作步骤
执行当前测试用例需要的操作步骤，通常要明确的给出每个步骤的详细描述，用例执行人员需根据该步骤完成用例执行。
8、预期结果
当前用例的预期输出结果，包括返回值的内容，以及界面的响应结果，输出结果的规则符合度、数据库等存储表中的操作状态等。
24. 测试用例级别的划分
优先级一般都是和缺陷的严重程度对应的。
一般可以把优先级分为三种：
高：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。
中：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计
低：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别
25. 怎样保证覆盖用户需求？
覆盖用户的需求；
从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
用例各个要素要齐全，步骤应该足够详细，操作应该明确，容易被其它测试工程师读懂，并能顺利执行；
做好用例评审，及时更新测试用例。
测试完成应找业务人员进行验收，便于发现非测试角度的问题
26. 写好测试用例的关键 /写好用例要关注的维度
1.测试前：
1.对测试目的有一个清晰的认知、
2.熟悉产品的功能测试点、
3.熟悉模块原理，避免“互相影响”问题的产生、
4.关注用户场景问题和上网问题、
5.不可马虎的关键测试用例设计、
2.编写测试用例时：
1.构建测试用例框架、
2.测试步骤的设计（一是如果步骤过于粗糙很容易出现漏测问题；二是写的过于细致，可能耗时耗力，并且会限制执行人员的思维。）
3.测试用例设计方法及思考
4.切记产品测试的主要目标、2.注意用词精准问题
27.测试用例的状态
排队（In Queue）、进行中（IP）、阻塞（Block）、跳过（Skip）、通过（Pass）、失败（Fail）、警告（Warn）、关闭（Close）
28.常见的测试用例设计方法
等价类划分、边界值分析、错误推断法、判定法表、正交实验法
29.判定表用在哪些时候/哪些功能
判定表方法是bai黑盒du测试方法的一种，主要用zhi于输入dao和输出比较多，zhuan功能逻辑比较shu复杂的情况，通过画出判定表缕清需求中的功能逻辑，还能确保找到输入的所有组合情况获得更多关于测试的知识。
30.什么时候用到场景法
场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。
使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。
基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。
场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）。
Note：场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。
31.测试环境怎么搭建的？
搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。
32.偶然性问题的处理
1.一定要提交bug
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重现，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 记录bug要尽量描述清楚发生问题时的测试步骤、测试环境、测试数据。
2.尽量重现bug
33.当我们认为某个地方是bug，但开发认为不bug，怎么处理？
1.告知开发bug的判断依据，同时明确开发说不是bug的理由。
2.对开发的理由进行校验，校验依据1.参照需求文档，2.跟产品经理进行沟通确认。
3.校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量
34.产品在上线后用户发现bug，这时测试人员应做哪些工作？
1、测试人员复现问题后，提交问题单进行跟踪；
2、评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
3、问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
4、总结经验，分析问题发生的原因，避免下次出现同样问题。
35.二八定理
80%的缺陷里存在20%的BUG
38.缺陷的等级
轻微缺陷、一般缺陷、严重缺陷、致命缺陷
39.缺陷单应该包含这些要素
缺陷标题、缺陷类型、重现步骤、预期结果、实际结果、缺陷优先级、附件备注
40.测试报告的主要内容
测试报告包括哪些内容: 测试模块（每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少BUG、遗留多少BUG、解决多少BUG、追后对这个模块总结一下）。
BUG的统计，根据时间轴来统计BUG的数量，例如：XXXX年X月X日，发现BUG多少，关闭BUG多少，剩余BUG多少，高级的BUG有多少，中级的BUG有多少，低级和建议的BUG有多少，一直罗列到项目完结。
项目总结，汇报一下测试的大致结果。
遗留和风险，该软件还有什么遗留问题，还有什么风险，都要一一说明
最后评判该软件是否符合上线标准，日期，签字，加盖章等。
41.如何定位bug：
1、发现bug，首先要查看bug的详细信息，根据描述初步分析是哪个模块哪段代码的问题
2、检查引发bug的测试环境、测试代码段和测试数据，排除测试人员的误操作导致的程序异常
3、确认测试代码、测试环境和数据都正确后，再进一步分析bug根源。这里就需要看具体的测试业务了，可借助相关的工具进行分析，比如firebug插件等
4、如果产品或业务有相关的日志记录，可通过分析日志来确认bug
5、当测试人员经过一系列的分析，可以基本确认bug产生的原因后，就可以直接找开发提bug了（注意沟通技巧）
6、如果各方面都分析完还不能确认bug的原因，可以找开发一起定位（注意保留bug现场或者可以复现bug场景）
7、确认bug后，提单给开发进行bug跟踪。
问题单上要描述清楚以下信息：
具体的测试时间、测试环境、测试场景、测试的具体业务和功能、使用的测试代码和测试数据、测试执行步骤、测试结果、bug现象（最好截图）、日志记录、预期结果、bug确认相关人员等
8、跟踪bug，等开发人员修复bug后进行回归测试。（关注bug是否完全修复、有没有对其他功能造成影响、有没有引入新的问题）
42.开发没时间修复，如何推进bug的修复：
1、 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点
a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性
b) 可以和开发人员列举一个之前的类似问题，为开发提供参考
c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。
2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改
3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案
4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方的工作人员，反馈问题，尽量推动应用解决问题
小结
总之，bug修不修，测试应该有一个自己的原则，同时也要权衡利弊。不能因为推不动开发，就放弃，由着bug上线，也不能揪着一个小bug不放，影响上线时间。
43.软件测试流程
了解用户需求–》参考需求规格说明书–》测试计划（人力物力时间进度的安排）–》编写测试用例–》评审用例–》搭建环境–》测试包安排预测（冒烟测试）-正式测试-bug-测试结束出报告–》版本上线–》面向用户
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.一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
1. 影响用户体验
2. 如果不修改，在上线时可能会引起其他bug发生
3. 如果在版本迭代在修改，时间久了对bug的认知就没有现在清楚了
4. 拖得越久越难修复
5. 不符合需求产品需求
48.在需求文档不太详细的情况下，如何开展测试？
1、主动了解做这个功能的背景，意图，要去解决一个什么样的问题， 这个可以找产品或者开发要，或者谁要求做这个功能的人要，知道这些后，测试的时候才心中有数，知道功能实现对不对
2、尽量让熟悉这块的业务的人去测试，这样功能的一些业务问题就可以测试出来
3、 因为没有需求说明书，测试这边只有在功能做好了，转测试了，才知道功能是什么样子，所以这个时候写测试用例来不及，就采取这样思路操作 ，测试的时候边测试边记录测试的点，然后组内把这些测试点评审下，看看是否还有遗漏的地方
49.如何尽快找到软件中的bug?
优先解决可重现的bug、对于某些没有头绪的bug，可以找有经验的同事商讨、bug放大、二分定位法、模拟现场、等
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/内存的访问情况。
54.你们发现bug会怎么处理。
提交bug、指派bug、确认bug、解决bug、重测bug、关闭bug、bug存档