软件测试面试题

一.软件测试理论部分

1.B/S架构和C/S架构区别

B/S 只需要有操作系统和浏览器就行，可以实现跨平台，客户端零维护，维护成本低，但是个性化能力低，响应速度较慢

C/S响应速度快，安全性强，一般应用于局域网中，因为要针对不同的操作系统,需要针对性的开发,并且维护成本高

2.HTTP协议

http协议又叫做超文本传输协议，在做网络请求的时候，我们基本上是使用http协议。
http协议包括请求和响应。
请求中包括:请求地址，请求方式，请求方式包括get请求和post请求，get和post的区别是get请求是在地址栏后边跟随请求参数，但是请求参数大小是有限制，不同浏览器是不同的。一般是4KB。post请求主要用于向服务器提交请求参数。post请求的参数是放到请求实体内容中的，相对get请求较为安全一些。另外，请求中会有各种请求头信息，比如支持的数据类型，请求的来源位置，以及Cookie头等相关头信息。

响应，主要包含响应的状态码，像200，304，307，404，500
还有各种响应头信息，比如设置缓存的响应头，Content-Type内容类型，设置cookie头信息。

200： (成功)服务器已成功处理了请求
304： (未修改)客户端发出了条件式请求，但服务器上的资源未曾发生改变，则通过响应此响应状态
307: (重定向)浏览器内部重定向
404： (未找到)服务器无法找到客户端请求的资源；Not Found
500： (服务器内部错误)无法完成请求；

3.POST与GET区别

1.Get请求一般是去取获取数据(其实也可以提交，但常见的是获取数据)；post请求一般是去提交数据。
2. Get是不安全的，因为在传输过程，数据被放在请求的URL中；Post的所有操作对用户来说都是不可见的，请求数据是放在body体中(最常用场景，用户登录密码提交，一定是使用post请求的)
3. Get传送的数据量较小，这主要是因为受url长度限制；Post传送的数据量较大，一般被默认为不受限制。
4. Get请求可以被缓存，Post请求不会被缓存

4.Cookie和Session的区别与联系

Cookie和Session都是会话技术，Cookie是运行在客户端，Session是运行在服务器端。
** Cookie有大小限制**以及浏览器在存cookie的个数也有限制，Session是没有大小限制和服务器的内存大小有关。Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击。Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。

5.测试的目的

简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正

6.软件测试分为哪几个阶段？【按开发阶段划分】

需求测试->概要设计测试->详细设计测试->单元测试->集成测试->系统测试->验收测试

单元测试

是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。

集成测试

也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。

系统测试

是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。

系统测试范围

功能测试、ui测试、性能测试、容错测试、可用性测试、异常问题测试、稳定性测试、系统稳定性测试、
兼容性测试、接口测试、安全性测试、登录权限测试

验收测试

是软件产品检验的最后一个环节。按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。

Alpha测试

是由用户在开发者的场所来进行的，在一个受控的环境中进行。并且在开发者对用户的指导下进行测试，开发者负责记录发现的错误和使用中遇到的问题
а测试 是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

Beta测试

由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场。由用户记录在测试中遇到的一系列问题，并定期报给开发者。
ß测试 是一种验收测试。beta测试是指在一个或多个用户的场所进行的测试。

其它得几个阶段划分

回归测试

是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例目的：
1.验证之前版本产生的所有缺陷已全部被修复；
2.确认修复这些缺陷没有引发新的缺陷

冒烟测试：

是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。也叫可测性测试。

7.分类

按代码运行划

静态测试：不实际运行被测对象，而是静态检查程序代码、界面或文档中可能存在错误的过程代码测试：主要测试代码是否符合相应的标准和规范界面测试：主要测试软件的实际界面与需求中的说明是否相符文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求动态测试： 实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以我们判断一个测试属于动态还是静态测试，唯一标准就是看是否运行程序

按软件特性

功能测试(黑盒测试)：黑盒测试一方面，检查实际软件功能是否符合用户需求性能测试：关注软件中某一功能在指定的时间、空间条件下，是否使用正常主要有时间性能和空间性能安全性测试：验证按在系统内的包含机制能否在实际应用中对系统进行保护使之不被非法入侵，不受各种因素干扰

8.白盒、黑盒、灰盒 【按测试技术划分】

白盒测试

也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试

黑盒测试

黑盒测试也称功能测试或数据驱动测试。不考虑程序内部结构和内部特性的情况下，对程序接口进行测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试

灰盒测试(接口测试)

关注输出对输入的正确性

特点：

黑盒测试方法：

等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法

等价类划分法

将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类

边界值分析法

是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试，因此该方法要和等价类划分法结合使用。

正交试验法

正交是从大量的试验点中挑选出适量的、有代表性的点

状态迁移法

是对一个状态在给定的条件内能够产生需要的状态变化，有没有出现不可达的状态和非法的状态

判定表分析法

判定表是分析和表达多种输入条件下系统执行不同动作的工具，

因果图法

因果图是用于描述系统输入输出之间的因果关系、约束关系。

白盒测试方法：

静态测试：不用运行程序的测试;动态测试：需要执行代码，通过运行程序找到问题;

区别：

黑盒和灰盒的区别：

如果某软件包含多个模块，当使用黑盒测试时，你只要关心整个软件系统的边界，无需关心软件系统内部各个模块之间如何协作。而如果使用灰盒测试，则需要关心模块与模块之间的交互。

白盒和灰盒的区别：

在灰盒测试中，你无需关心模块内部的实现细节，对于软件系统的内部模块，灰盒测试依然把它当成一个黑盒来看待。而白盒测试还需要再深入地了解内部模块的实现细节和各个分支。

9.验收测试怎么做？

1、界面测试；指软件产品所有的页面浏览时功能按钮或者界面是否能正常****显示。
2、功能测试；产品的功能是否都能正常实现。
3、性能测试；发现性能瓶颈的过程，包括对CPU、内存、网络环境、版本等多项测试内容。
4、安全测试；产品的信息保密，密码保护等功能的测试。

10.冒烟测试的目的

为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。

11.回归测试怎么做？

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

12.需求分析的目的

第一、把用户需求转化为功能需求：
1)对测试范围进度量
2)对处理分支进行度量
3)对需求业务的场景进行度量
4)明确其功能对应的输入、处理和输出
5)把隐式需求转变为明确。

第二、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。

13.测试计划的目的

1.尽早地明确测试工作内容(范围)、测试工作的方法以及测试工作所需要的各种资源。
2.所有涉及到测试工作的人员，尽快将下一步测试工作需要考虑的问题和准备的条件落实。
3.测试计划工作的重点在于：对当前工作任务的准备和规划以及信息的交流。

14.什么时候开始写测试计划

测试计划是在需求整理完成，和开发计划一起制定的一份计划书，它属于项目计划中其中的一个计划

15.由谁来编写测试计划

项目经理(从项目角度考虑)测试经理(从测试组角度考虑)测试人员(编写具体测试计划)

16.测试计划的内容

1、 测试目标：对测试目标进行简要的描述。
2、 测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。
3、 测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。
4、 重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。
5、 质量目标：制定测试软件的产品质量目标和软件测试目标。
6、 资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。
7、 人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。
8、 测试策略：制定测试整体策略、所使用的测试技术和方法。
9、 发布提交：在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。
10、 测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的Release不确定，可以给出测试的时间段.对于长期大型的测试计划，可以使用里程碑来表示进度的变化。
11、 测试开始/完成/延迟/继续的标准：制定测试开始和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。
12、 风险分析：需要考虑测试计划中可能的风险和解决方法。

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

1、软件经过充分的测试开发人员测试—〉交叉测试—〉测试人员测试—〉用户的业务专家测试—〉一定数量的用户业务专家集中测试—〉上线前试运行----〉上线。
2、用户培训
管理员，一定厂或地区必须有一个人经过了培训。
3、基础数据导入完成
用户、组织机构、业务数据等基础必须数据导入完成。
4、授权必须完成
5、新老系统的切换必须提前演练过，各种老数据的导入工作完成。
6、应急方案必须有。

18.常见的测试风险

1.需求风险、
2.测试用例风险、
3.缺陷风险、
4.代码质量风险、
5.测试环境风险、
6.测试技术风险、
7.回归测试风险、
8.沟通协调风险、
9.研发流程风险、
10.其他不可预计风险

19.测试用例的要素

1.用例编号、
2.测试模块、
3.用例的标题、
4.测试级别、
5.测试目的和条件、
6.测试输入、
7.操作步骤、
8.预期结果

20.测试用例级别的划分

测试用例优先级的目的

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

根据我们测试用例优先级目的

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

21.怎样保证覆盖用户需求？

1.确认需求、
2.梳理需求，确认测试范围、
3.制定测试计划、
4.根据测试计划编写测试用例、
5.执行测试步骤

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

测试前：

1.对测试目的有一个清晰的认知、
2.熟悉产品的功能测试点、
3.熟悉模块原理，避免“互相影响”问题的产生、
4.关注用户场景问题和上网问题、
5.不可马虎的关键测试用例设计、

编写测试用例时：

1.构建测试用例框架、
2.测试步骤的设计(一是如果步骤过于粗糙很容易出现漏测问题；二是写的过于细致，可能耗时耗力，并且会限制执行人员的思维。)

测试用例设计方法及思考

1.切记产品测试的主要目标、
2.注意用词精准问题

23.常见的测试用例设计方法

等价类划分、边界值分析、错误推断法、判定法表、正交实验法

24.什么时候用到场景法

场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。
使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。
基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。
场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试(等价类+边界值+判定表等)，而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试(先整体后细节)。
Note：场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。

25.偶然性问题的处理

1.一定要提交bug、
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重现，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 记录bug要尽量描述清楚发生问题时的测试步骤、测试环境、测试数据。
2.尽量重现bug、

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

1.告知开发bug的判断依据，同时明确开发说不是bug的理由。
2.对开发的理由进行校验，校验依据1.参照需求文档，2.跟产品经理进行沟通确认。
3.校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量

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

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

28.二八定理

缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在 20%的模块。

29.如何跟踪缺陷

当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。

30.缺陷的状态

1、 初始化：缺陷的初始状态；
2、 待分配：缺陷等待分配给相关开发人员处理；
3、 待修正：缺陷等待开发人员修正；
4、 待验证：开发人员已完成修正，等待测试人员验证；
5、 待评审：开发人员拒绝修改缺陷，需要评审委员会评审；
6、 关闭：缺陷已被处理完成。

31.缺陷的等级

轻微缺陷、一般缺陷、严重缺陷、致命缺陷

32.缺陷单应该包含这些要素

缺陷标题、缺陷类型、重现步骤、预期结果、实际结果、缺陷优先级、附件备注

33.测试报告的主要内容

测试报告包括哪些内容: 测试模块(每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少BUG、遗留多少BUG、解决多少BUG、追后对这个模块总结一下)BUG的统计，根据时间轴来统计BUG的数量，例如：XXXX年X月X日，发现BUG多少，关闭BUG多少，剩余BUG多少，高级的BUG有多少，中级的BUG有多少，低级和建议的BUG有多少，一直罗列到项目完结项目总结，汇报一下测试的大致结果。遗留和风险，该软件还有什么遗留问题，还有什么风险，都要一一说明
最后评判该软件是否符合上线标准，日期，签字，加盖章等

34.如何定位bug：

1、发现bug，首先要查看bug的详细信息，根据描述初步分析是哪个模块哪段代码的问题
2、检查引发bug的测试环境、测试代码段和测试数据，排除测试人员的误操作导致的程序异常
3、确认测试代码、测试环境和数据都正确后，再进一步分析bug根源。这里就需要看具体的测试业务了，可借助相关的工具进行分析
4、如果产品或业务有相关的日志记录，可通过分析日志来确认bug
5、当测试人员经过一系列的分析，可以基本确认bug产生的原因后，就可以直接找开发提bug了(注意沟通技巧)
6、如果各方面都分析完还不能确认bug的原因，可以找开发一起定位(注意保留bug现场或者可以复现bug场景)
7、确认bug后，提单给开发进行bug跟踪。
　　问题单上要描述清楚以下信息：
　　具体的测试时间、测试环境、测试场景、测试的具体业务和功能、使用的测试代码和测试数据、测试执行步骤、测试结果、bug现象(最好截图)、日志记录、预期结果、bug确认相关人员等
8、跟踪bug，等开发人员修复bug后进行回归测试。(关注bug是否完全修复、有没有对其他功能造成影响、有没有引入新的问题)

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

1、 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点：

a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性
b) 可以和开发人员列举一个之前的类似问题，为开发提供参考
c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。

2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改
3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案
4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方的工作人员，反馈问题，尽量推动应用解决问题
小结总之，bug修不修，测试应该有一个自己的原则，同时也要权衡利弊。不能因为推不动开发，就放弃，由着bug上线，也不能揪着一个小bug不放，影响上线时间。

36.软件测试流程

了解用户需求–》
参考需求规格说明书–》
测试计划(人力物力时间进度的安排)–》
编写测试用例–》
评审用例–》
搭建环境–》
测试包安排预测(冒烟测试)-正式测试-bug-测试结束出报告–》
版本上线–》
面向用户

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

性能测试
能否正常书写 是否有笔油泄露 笔帽是否能正常按下弹起来
功能测试
一支笔可以用多长时间、写出的字是否褪色
易用性测试
笔的长短粗细是否顺手 一根笔芯用尽是否方便更换
界面测试
外形是否美观 时尚有趣
安全性测试
笔油是否含有有害物质 笔尖是否容易伤到人 笔油或者墨水保质期多长 过期是否产生有害物质、
兼容性测试
在不同的温度、气压、和重力下能否正常使用 在不同的纸质和力度下书写结果如何

三角形测试用例设计：

1、当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。
2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。
3、若是等边三角形，则打印：“等边三角形”。
4、画出程序流程图并设计一个测试用例。
因果图、等价类划分(推荐测试方法)

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

编码的问题接口限流防刷的时候，通过计数器限流，如果超过某个阈值，向前端返回一个codeMsg对象用于显示的时候，显示的是String是乱码的问题，之前由于一直返回都是json 格式，都是封装好在data里。
这次返回是直接通过输出流直接写到response直接返回字节数组的，而不是spring controller 返回数据(springboot 默认utf-8)，出现乱码问题，用utf-8编码，解决。
比较难解决的bug无非就两种，一种就是程序的逻辑出现问题，导致得不到正确的结果，第二种就是一些中间件，开发环境的问题。
(1)如果是逻辑出现了问题，你项目比较大的话，那只能是通过单步调试，或者用System.out.println()打印出来想要得到的数据看看是哪步出了问题。
(2)如果是开发环境或者是中间件的问题，那只能是通过网上查阅资料来解决问题。如果你英语阅读能力还可以的话，我推荐使用Stack Overflow来查阅资料。

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

1、主动了解做这个功能的背景，意图，要去解决一个什么样的问题， 这个可以找产品或者开发要，或者谁要求做这个功能的人要，知道这些后，测试的时候才心中有数，知道功能实现对不对
2、尽量让熟悉这块的业务的人去测试，这样功能的一些业务问题就可以测试出来
3、 因为没有需求说明书，测试这边只有在功能做好了，转测试了，才知道功能是什么样子，所以这个时候写测试用例来不及，就采取这样思路操作 ，测试的时候边测试边记录测试的点，然后组内把这些测试点评审下，看看是否还有遗漏的地方，

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

优先解决可重现的bug、对于某些没有头绪的bug，可以找有经验的同事商讨、bug放大、二分定位法、模拟现场、等

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

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

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

1、 缺陷的概要描述要清晰准确，要使相关开发负责人员能够一目了然问题是什么。
　　2、 一个完整的缺陷报告单，必须包含其必要的元素信息，例如：概要描述，缺陷发现人，测试环境，浏览器，缺陷重现步骤，严重等级，指派人，所属功能模块等等，必要元素信息必须描述全面清楚。
　　3、 缺陷的重现步奏必须描写清晰明了，使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷，使其定位缺陷的原因所在。
　　4、 指派给人一定要明确，如知道缺陷是所属具体的某一个开发人员时，应该直接指派给对应的负责人，这样就能减少中间分配环节的时间。
　　5、 测试数据，测试的数据作为重现缺陷的一个重要元素信息，一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。
　　6、 附件截图信息，附件或截图信息能让开发人员能够一目了然的清楚问题的所在，所以必要的时候提供附件或者截图信息也非常的重要。
　　7、描述缺陷内容的语气，在进行缺陷单书写时，尽量使用专业术语(体现测试的专业性)，其次注意书写缺陷报告单时不要带有个人客观的语气内容，以免影响开发和测试人员之间的关系。

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

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

44.搜索功能怎么测试

功能方面的测试：

搜索单个字，词语，句子，检索到的内容是否准确，链接是否准确
长度：例如输入框支持100字符， 那需要测试100字符、101字符，最大长度的显示是否正常；
哪些是支持的字符类型：数字、字母、汉字、字符！@！#、特殊字符；(需求而定)
字符串前后中带空格，前后的空格是否过滤， 中间的空格是否保留；(需求而定)
全角半角的字母、数字(需求而定)

性能方面的测试

点击搜索按钮后，搜索结果多长时间能够显示
进入搜索页面需要多久

安全性方面的测试

能否防止SQL注入攻击,否防止XSS攻击

用户体验测试：

页面布局是否合理，输入框和按钮是否对齐
输入框的大小和按钮的长度，高度是否合理
快捷键：能不能全选，部分选择，复制剪切粘贴是否可用，粘贴超过最大长度的字符串怎么显示

兼容性测试

BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等

45.登录功能怎么测试

功能方面的测试：

输入正确的用户名和密码，点击提交按钮，登录成功，跳转到正确的页面
输入正确的的用户名, 错误的密码，登录失败，并且提示相应的错误信息
输入错误的用户名，正确的密码, 登录失败，并且提示相应的错误信息
用户名为空, 验证登录失败，并且提示相应的错误信息
密码为空, 验证登录失败，并且提示相应的错误信息
用户名和密码都为空，点击登陆
用户名和密码前后有空格，，中间空格是否处理(需求而定)

性能方面的测试

打开登录页面，需要多长时间
输入正确的用户名和密码后，登录成功跳转到新页面，需要多长时间

安全性方面的测试

密码是否在前端加密，在网络传输的过程中是否加密
用户名和密码的输入框，能否防止SQL注入攻击
用户名和密码的输入框，能否防止XSS攻击
错误登陆的次数限制(防止暴力破解)
是否支持多用户在同一机器上登录
一个用户在不同终端上登陆
用户异地登陆

用户体验测试：

页面布局是否合理，输入框和按钮是否对齐
输入框的大小和按钮的长度，高度是否合理
是否可以全用键盘操作，是否有快捷键
输入用户名，密码后按回车，是否可以登陆
牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色(色盲使用者)，刷新或换一个按钮是否好用

兼容性测试

BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
APP：在主流的不同机型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo、苹果等

46.如果需要你来测试淘宝的购物车，你会如何设计测试用例，需要从哪些方面来考虑。

1.打开淘宝页面后，页面的布局是否是完整的
2.页面的功能按钮是否可以正常显示
3.在商品页面是否会显示加入购物车
4.选中的商品是否能加入购物车
5.加入购物车后是否可以显示商品的所有信息
6.添加到购物车的商品是否可以进行删除
7.如果在网络不佳或无网络时是否可以成功的加入购物车
8.添加购物车后，点击加号的时候数量是否会增长
9.添加购物车后，点击减号的时候数量是否会减少
10.如果点击减号减到一定程度时，是否会提示不能再减少了
11.如果淘宝用户未登录时，如果添加到购物车时是否会提示请先登录
12.如果没有选择任何商品，点击结算，是否会提示用户“请添加要结算的商品”
13.勾选商品后已选商品的总价是否会显示
14.勾选商品显示总价后，总价计算是否正确
15.勾选商品，点击结算按钮后，是否会进入确认订单信息的页面
16.进入确认订单信息页面的总价是否正确
17.总价是否会出现精度不准的情况，比如：正确总价是18.99，结果显示的确实18.999999999999
18.是否有回到顶部功能
19.是否可以编辑商品属性
20.能否移入到收藏中
21.店铺名称是否显示
22.能否选择全部商品
23.能否取消选择全部商品
24.是否可以在购物车中修改商品的规格
25.添加购物的数量超过库存数量是否进行限制
26.是否可以进行清空购物车
27.结算金额是否会随着商品数量的增加减少进行变化
28.如果刷新的次数过多，是否会出现闪退的现象
29.当手机来电话时淘宝页面是会还会运行
30.当手机内存不够时，淘宝运行起来是否会出现卡顿的现象

47.app测试性能指标

内存
cpu
流量
启动速度

48.web测试和app测试不同点

系统架构方面：

web项目，一般都是b/s架构，基于浏览器的app项目，则是c/s的，必须要有客户端，用户需要安装客户端。web测试只要更新了服务器端，客户端就会同步会更新。App项目 则需要客户端和服务器都更新。

性能方面:

web页面主要会关注响应时间
而app则还需要关心流量、电量、CPU、GPU、Memory等。

兼容方面：

web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统方面的兼容app测试则要看分辨率，屏幕尺寸，操作系统、网络。web测试是基于浏览器的所以不必考虑安装卸载。
而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景:包括安装时的中断、弱网、安装后删除安装文件 。

二.软件开发模型

软件生命周期： 从软件最初构思到最终消亡(退役)的过程。

1. 软件生命周期

立项 —需求分析 —设计、编码、测试 —发布 —运行维护 —淘汰
软件立项===》可行性研究 ===》需求分析 ===》概要设计 ===》详细设计 ===》编码实现 ===》单元测试 ===》集成测试 ===》系统测试 ===》验收测试 ==》运行维护

2. 瀑布模型

缺点：
1. 各阶段划分完全固定，阶段之间产生大量文档，极大增加工作量
2. 由于开发模型是线性的，用户只有等到整个过程的末期才能看到开发结果，增加开发风险
3. 不适应用户需求变化

3 . 快速原型模型(现在特别流行模式) Axure 软件

原理：迅速搭建一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最后在确定需求基础上开发客户满意的软件产品
特点：适合预先不能确切定义需求的软件系统的开发
优点： 克服瀑布模型缺点，减少由于软件需求不明确带来的开发风险

4. 增量模型(最常用开发模型之一)

分批次地分析、设计、编码和测试这些增量组件。

5. 迭代模型 开发进度快

原理

强调开发的深入 —优化过程
开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程

优点

降低在一个增量上的开支风险
降低产品无法按照既定进度进入市场的风险
加快开发工作进度
适应需求变化快的场景

6. 螺旋模型

1. 原理：
   兼顾了快速模型的迭代的特征以及瀑布模型的系统化与严格监控
2. 优点
   最大特点：引入其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减少损失
   适合大型昂贵的系统级的软件应用

三. 软件测试模型

1. v模型

1. 原理：揭示开发过程和测试过程中各阶段的对应关系
2. 缺点与不足：
   仅把测试过程作为需求分析、系统设计及编码之后的一个阶段，忽略了测试对需求分析、系统设计的验证
   需求的满足情况一直到后期验收测试才被验证
   没有体现出“尽早和不断地进行软件测试原则

2. w模型

1. 由两个 v 字模型组成，分别代表测试与开发过程，明确表示了测试与开发并行关系
2. 优点：
   测试活动与软件开发同步进行
   测试对象不仅是程序，包括需求与设计尽早发现软件缺陷可降低软件开发成本
3. 局限性：无法支持迭代开发模型(没有循环过程)

3. h模型

1. 将测试活动完全独立出来，形成一个完全独立的流程
2. 只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了
3. 软件测试要尽早准备，尽早执行，不同测试活动可按某个次序先后进行，也可反复进行(迭代)

4. x模型

1. 针对单独的程序片段进行相互分离的编码和测试；
2. 定位了探索性测试，这是不进行事先计划的特殊类型的测试；

5. 软件测试生命周期

获取测试需求
编写测试计划
制定测试方案
开发与设计测试用例
执行测试
提交缺陷报告
测试分析与评审
提交测试总结
准备下一版本测试

6. 简述缺陷的生命周期？ 面试重点

软件测试人员提交缺陷报告；
测试负责人审核后将缺陷分配给相关开发人员修复
缺陷被修改后有测试人员根据缺陷报告中修改记录进行返测
返测通过的缺陷由负责人关闭；
返测未通过的缺陷直接返回给开发人员重新修改，然后再由测试人员返测，直到测试和开发达成一致处理意见。

四. shell编程和命令部分

1. 怎么用shell命令查看行号

获取文本对应文本的行号,可以用grep，也可以用sed
grep -n “xxx” a.txt | cut -d “:” -f 1
sed -n -e ‘/xxx/=’ a.txt

2. 怎么查进程id

shell获取进程ID的方法有三种：
1、ps -A |grep “cmdname”| awk ‘{print $1}’
2、pidof “cmdname”
3、pgrep “cmdname”

3. 网络相关常用命令

ifconnfig：查看网卡配置信息
route显示路由表
netstat:查看本地计算机所使用的网络服务状况
ping:测试本地计算机与目标主机是否连接 如ping 127.0.0.1

4. linux查看进程

ps a 显示现行终端机下的所有程序，包括其他用户的程序。
ps u 以用户为主的格式来显示程序状况。
ps x 显示所有程序，不以终端机来区分。
最常用的方法是ps -aux

5. top

用于实时显示 process 的动态。
语法：top [-] [d delay] [q] [c] [S] [s] [i] [n] [b]

6. 查看磁盘

df命令参数功能：检查文件系统的磁盘空间占用情况
du：检查磁盘空间使用量
fdisk：用于磁盘分区

7. 查看端口号、进程的指令是？动态查看日志的指令？怎么判断一个端口存不存在，磁盘满了怎么处理，删除一个目录下的txt文件，你还熟悉其他什么linux指令？

查看端口号命令：
    netstat –tunlp|grep 端口号
    lsof -i:端口号

查看进程指令
ps -ef |grep 进程
-e 　显示所有程序。
-f 　 显示UID,PPIP,C与STIME栏位。
动态查看日志
1、先切换到：cd usr/local/tomcat5/logs
2、tail -f catalina.out

8 linux三剑客：grep、sed、awk 、[find]

grep：指定文件中搜索特定的内容，并将含有这些内容的行标准输出
格式：grep [options] 文件名
[options]主要参数：
    －c：只输出匹配行的计数
    －i：不区分大小写(只适用于单字符)
    －h：查询多文件时不显示文件名
    －l：查询多文件时只输出包含匹配字符的文件名
    －n：显示匹配行及行号
    －s：不显示不存在或无匹配文本的错误信息
    －v：显示不包含匹配文本的所有行
    -e：使用正则匹配
    -E：使用扩展正则
    --color=auto：将

sed 流文本编辑器
awk 文本和数据处理，
find作用是在目录中搜索文件，它的使用权限是所有用户。

格式：find [path][options][expression]
    path指定目录路径。它是一个路径列表，相互用空格分离，如果不写path，那么默认为当前目录。

五. 数据库部分

概念

1. 主键： 主关键字primary key

针对一个表来说的，主键修饰的列：唯一，不能重复，不能为空；一个表中只能只有一个主键

2. 外键：

针对两个表来说，加强表与表之间联系

3. 关系模型的规范化： 关系模式要满足的条件称为规范化形式，范式(NF)

目的：消除储存异常，减少数据冗余，保证数据完整性和存储效率
如果关系 R 的所有属性均为简单属性，每个属性是不可再分的(无重复的列)，则 R 满足第一范式
第二范式(2NF)：关系 R 满足第一范式，每一个非主键关键字段完全依赖于主键，则称 R 满足第二范式
第三范式(3NF):关系 R 满足第二范式，且非关键字段之间不存在依赖关系，则称满足第三范式。(从表只能引用主表中一个列)
总结：一个基本的关系型数据库，需要满足第一范式；一个完整的关系型数据库要满足第三范式

4. 唯一约束

特征：
不允许出现重复的值，但是可以为多个 null
同一个表中可以有多个唯一约束
如果不给唯一约束名称，就默认和列名相同

5. 非空约束

格式： 列名 数据类型 not null
一个表里面也可以有多个非空约束

6. 默认约束

default 一个表中可以有多个默认约束

7. 外键约束

表的外键值必须在主表中能找到
当主表记录被从表参照时，主表的记录将不允许删除
如果要删除数据，需要先删除表中依赖该记录的数据(删从表记录)
主表：被引用的表(被参照的表) zhu
从表：应用的表 外键约束建立在表里面 cong
被引用的列，要么主键约束，要么唯一约束
注意：在引用过程中，主表和从表的来个两个列的数据必须保持一致。(内容也要保持一致)

8. 检查约束

描述：限制某个列的取值范围 年龄 18-25 性别：要么男或女

9. 主键、外键作用，索引的优点与不足

主键

表中的唯一标示键
作用：保证实体的完整性，加快数据库的操作速度。
外键：主键的从属，表示两个表之间的联系
作用：作用外键可以建立数据之间的关联，避免冗余

索引：

优点

通过创建唯一性的索引，保证表中数据唯一性
       加速数据的检索速度
       加快表与表之间的连接
       使用优化隐藏器，提供系统性能

缺点：

创建索引需要时间，
       索引需要占用物理空间
      当对表中数据进行修改时，索引也要动态维护，减低数据的维护速度

表结构操作

1. 表的创建语法

create table 表名(
属性名1 数据类型 [约束条件],
属性名2 数据类型 [约束条件],
属性名3 数据类型 [约束条件]
);

2. 删除表

drop table 表名;

3. 删除多个表

drop table 表名 1,表名 2 …

4.修改表结构

1. 添加列(属性)

alter table 表名 add 属性名 数据类型;

2. 删除表(属性)

alter table 表名 drop 属性名;

3. 修改属性：数据类型

alter table 表名 modify 属性名 数据类型;

4. 修改字段名

alter table 表名 change 旧字段名 新字段名 数据类型;

5.数据库增删改查

create alter drop desc主要针对表结构来说的
insert delete update select 主要针对表中的数据来进行操作的

1 DML-INSERT

insert 插入 值和列一一对应关系

格式 1：
insert into 表名(列名 1,列名 2 ...) values(值 1,值 2 ...);
格式 2：
insert into 表名 values(值 1,值 2 ...);
格式 3：
insert into 表名 values(值 1,值 2,值 3 ...),(值 1,值 2,值 3 ...);

2. 删除 delete

格式 1：代表清空表内的数据
delete from 表名;
格式 2：
有条件的进行删除：delete from 表名 where 条件;

3 DML–UPDATE 更新

格式 1
update table_name set 字段=值;
格式 2
update table_name set 字段=值,字段=值;
格式 3
update table_name set 字段=值,字段=值 where 条件;

6. select 查询

基本格式:

select 列名 from 表名;
select 列名 1,列名 2,列名 3 ... form 表名;

1. 使用关键字 distinct 查询

在查询返回结果中删除重复行
语法：select distinct 列名称 from 表名称;
只针对一个列去重

2. 使用别名查询

根据需要对数据显示的标题进行修改
格式：select 列名1 '别名',列名2 '别名',... from 表名;
AS 关键字连接列表达式和指定的别名
select 列名 as '别名' from 表名;

3. 条件查询

格式：select 列名 from 表名 where 条件;
如果在查询过程中，有多个条件，可以使用 and 或 or 进行连接
and 连接 —》同时满足； or 连接 ------只满足其一

4. 范围搜索范围

在范围之内
select 列名 from where 列名 between 开始值 and 结束值
不在范围之内
select 列名 from 表名 where 列名 not between 开始值 and 结束值;

5. 列表搜索条件

in: 只要匹配到括号里任意一个值就会有查询结果；
    格式：select 列名 from 表名 where 列名 in (值 1,值 2,值 3 ...)
not in：
    格式： select 列名 from 表名 where 列名 not in(值 1,值 2,值 3);

7.数据库表连接查询：子查询、内连接、外连接

1. 多表查询

去重
    显式

    	 select [distinct] A.列名,B.列名,C.列名,... from C 
    	 join A on A.key=C.FKeyA 
    	 join B on B.key=C.FKeyA and B.key=A.key
    	 [GROUP BY 字段名]

    隐式

    	select [distinct] A.列名,B.列名,C.列名,... from 表A,
    	表B,
    	表C
    	 where 表A.字段1 = 表B.字段1 and
    	 表B.字段2 = 表C.字段2 and ....
    	 [GROUP BY 表名.字段名]


排序

select  A.列名,B.列名,C.列名,... from C 
 join A on A.key=C.FKeyA 
 join B on B.key=C.FKeyA and B.key=A.key
[ORDER BY 表名.字段名]

2. 子查询

子查询只返回一个值
子查询首选使用in做匹配
子查询在其他查询结果的基础上提供了一种有效的方式来表示where字句的条件 。
子查询的selec查询总是使用圆括号括起来。
对于子查询来说，外查询条件要什么，子查询就查什么。 一一对应的关系。
子查询结果分类：
    标量子查询(子查询结果为单个值)：
        子查询返回的结果是单个值〔数字、字符串、日期等)
        常用操作符：= <> > >= <= <
    列子查询(子查询结果为一列)：子查询返回的结果是一列
        常用操作符：in、not in、any、some、all

    	select 列表名 from 表名 where 字段名 > all (子查询语句);
    	select 列表名 from 表名 where 字段名 > any (子查询语句);

    在这里插入图片描述
    行子查询(子查询结果为一行)：
        常用操作符：=、<>、 in、not in
        select 字段名,... from 表名A where (字段名1,字段名2,...) = (select 字段名1值，字段名2值,... from 表名B where 条件)
    表子查询(子查询结果为多行多列)：in
        select 字段名,... from 表名A where (字段名1,字段名2,...) in (select 字段名1值，字段名2值,... from 表名B where 条件)

3. 内连接：只有匹配到的情况下才会返回结果值

格式一(隐式)：

from 表名1.列名1,表名1.列名2,表名2.列名1,表名2.列名2... 
form 表名1,表名2
where 表名1.列=表名2.列; //列为相同的列


格式二(显式):
select 表名1.列名1,表名1.列名2,表名2.列名1,表名2.列名2... 
from 表名1 inner join 表名2
on 表名1.列=表名2.列

4. 外连接

外部连接会返回from字句中提到的至少一个表或视图中的所有行
左连接：显示左边所有行。如果左表的某行在右表中没有找到匹配的行，则结果集中的右表相对应位置为null。

select 表名1.列名1,表名1.列名2,表名2.列名1,表名2.列名2
from 表名1 left outer join 表名2
on 表名1.列=表名2.列; //列为大家共有的列
右连接：显示右边所有行

right outer join
select 表名1.列名1,表名1.列名2,表名2.列名1,表名2.列名2
from 表名1 right outer join 表名2
on 表名1.列=表名2.列; 


区分是左连接还是右连接：左连接以坐标为参考，左表没有则返回null，右连接以右表为参考，右表没有则返回null

5.联合查询

把多次查询的结果合并起来，形成一个新的查询结果集
对于联合查询的多张表的列数必须保持一致，字段类型也需要保持一致。
union all会将全部的数据直接合并在一起，union 会对合并之后的数据去重。

select 字段名 from 表A ....
UNION [ALL]
select 字段名 from 表B ...;

六.计算机网络部分

1. 三次握手，四次挥手过程

三次握手：

第一次握手：客户端发送syn包(syn=1，seq=x)到服务器，并进入SYN_SENT状态，等待服务器确认；
    第二次握手：服务器收到syn包，必须确认客户的SYN(ack=x+1)，同时自己也发送一个SYN包(syn=y)，即SYN+ACK包，此时服务器进入SYN_RECV状态；
    第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
    握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

四次挥手:

断开一个TCP连接则需要“四次挥手”。
    第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。
    第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1(与SYN相同，一个FIN占用一个序号)。
    - 第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
    第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

2. OSI，TCP/IP，五层协议的体系结构，以及各层协议

OSI分层 (7层)：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
TCP/IP分层(4层)：网络接口层、 网际层、运输层、 应用层。
五层协议 (5层)：物理层、数据链路层、网络层、运输层、 应用层。
每层作用
    物理层：传输二进制比特流
    数据链路层：负责将上层数据封装成帧
    网络层：负责路由寻址和广播 ；广播：发送消息和接收消息
    *传输层：负责建立一个可靠的端到端的连接；端到端：发送到接收 ；过程：建立、维护、撤销(拆除)
    会话层：负责建立维护拆除会话，为端应用之间提供控制功能(可靠性)
    表示层：完成对传输数据格式转换：格式化；发：加密；接：解密；发：压缩，接：解压缩
    应用层：对应用软件提供网络支持

3. cookie、session、token

cookie:在客户端存储在客户端用于存储会话信息的
session：在服务器端，记录用户的请求状态，一般默认时间30min
    session_id会存在cookie中，每次请求cookie中所有信息都会传递给服务器，服务器通过session_id来识别是否是同一个用户请求，不是同一个用户的话，就会要求重新登录
token：访问权限，保存在客户端本地
    鉴权：访问的接口是否正常，是否非法访问绕过前端。 防止跳过页面直接访问接口**token**
    授权：是否具有访问接口的权限。 唯一全局动态的 。

4. 常用状态码

100系列：请求已收到继续处理；

200系列:表示成功
    200：正常，服务器正确响应了请求

300系列：资源重定向；
    301:永久重定向；请求的网页已永久移动到新位置
    302：2临时重定向；被请求文档已经临时移至别处，此文档新的url在location响应头中给出
    303：浏览器对于POST的响应进行重定向至新的url
    307：浏览器对于GET的响应重定向至新的url

400系列：客户端错误：
    400：错误请求；服务器不理解请求的语法。
    401：未授权；如请求参数、方法、格式等
    403：拒绝访问；服务器理解客户的请求，但拒绝处理它(没有权限)
    404：请求资源不存在

500系列：服务器端出错
    500：服务器内部错误
    501：尚未实施；服务器不具备完成请求的功能
    502:服务器网关错误
    503：服务器由于维护或者负载过重未能应答
    504请求超时

5. http请求头和响应头

**http请求及其结构：
请求信息包含：请求行(request) 请求头部header 、空行和请求数据组成
响应及其结构
响应组成：状态行、响应头报文、空行和响应正文**

6. IP地址的分类

A类地址：以0开头， 第一个字节范围：1~126(1.0.0.0 - 126.255.255.255)；

B类地址：以10开头， 第一个字节范围：128~191(128.0.0.0 - 191.255.255.255)；

C类地址：以110开头， 第一个字节范围：192~223(192.0.0.0 - 223.255.255.255)；

D类地址：以1110开头，第一个字节范围：224~239(224.0.0.0 - 239.255.255.255)；(作为多播使用)

E类地址：保留

以下是留用的内部私有地址：
    A类 10.0.0.0–10.255.255.255

    B类 172.16.0.0–172.31.255.255

    C类 192.168.0.0–192.168.255.255

7. 常见一些词汇

ARP:地址解析协议(Address Resolution Protocol)
RARP:反地址解析协议(Reverse Address Resolution Protocol)将ip地址转换为物理地址
FTP:文件传输协议(File Transfer Protocol)
HTTP：超文本传输协议(Hyper Text Transfer Protocol)
TCP:传输控制协议(Transmission Control Protocol)
UDP:用户数据报协议(User Datagram Protocol)

8. TCP的三次握手过程？为什么会采用三次握手，若采用二次握手可以吗？

建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。
(1)TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
(2)采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
(3)采用两次握手不行，原因就是上面说的失效的连接请求的特殊情况。

9. 常用四种请求方法

get：
post
put
delete

. get和post区别

GET - 从指定的资源请求数据。请求的数据会附加在URL之后，以?分割URL和传输数据，多个参数用&连接
POST - 向指定的资源提交要被处理的数据。POST请求会把请求的数据放置在HTTP请求包的包体中

10. http和https区别

HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTPS和HTTP的区别主要如下：
    https需要到cat申请证书，需要交费
    http是超文本传输协议，信息明文传输，https具有安全性的ssl加密传输协议
    http和https使用完全不同的连接方式和端口号，前者80，后者443
    http连接简单、无状态；https可进行加密传输、身份验证网络协议

11. 请你说一下分布式和集群的概念。

分布式：是指将不同的业务分布在不同的地方，
集群：是指将几台服务器集中在一起，实现同一业务。

分布式中的每一个节点，都可以做集群，而集群并不一定就是分布式的。集群有组织性，一台服务器垮了，其它的服务器可以顶上来，而分布式的每一个节点，都完成不同的业务，一个节点垮了，哪这个业务就不可访问了。

12. 路由寻址(路由)：

在路由器中，从一个接口接收到数据包，根据数据包所携带的目的地址进行定向转发到另一个接口的过程。

13. HTTP协议工作原理

浏览器作为HTTP客户端通过URL向http服务端即web服务器发送所有请求
web服务器根据接收到的请求后，向客户端发送响应信息