软件测试面试题集锦

一、基础知识

1、什么是软件测试，软件测试的目的是啥？

软件测试是为了发现错误而执行程序的过程，为保证软件质量而采取的措施。 根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例（输入以及预期的输出结果），并利用这些测试用例去运行程序，以发现程序中的错误。目的以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷提高软件质量，回避因软件发布后由于潜在的缺陷和错误造成的隐患带来的商业风险。

二种思维：

正向：验证程序是否正常执行以及是否达到用户预期的需求。

反向：为发现错误或缺陷而进行的一系列活动。

2、什么是测试计划？都包括啥？什么是测试方案，什么是测试策略？测试方案包含哪些内容？测试用例设计方法有哪些？测试用例内容有哪些？

测试计划：是对工作内容的有效组织和规划，保证测试工作有效展开。包括测试目标，测试范围定义，测试方法选择，测试进度里程碑，测试资源管理和配置。测试目标最重要，因为他是软件测试的最终达到结果

测试方案：是指导我们怎么测的问题，里面的主要内容是测试点。测试策略是指导我们要测什么方面，比如要进行功能测试，性能测试，兼容性测试等等，并指出需要依赖于什么工具。

测试方案包含：业务功能的描述，对需求功能的理解，业务流程图，业务表，测试点等。

测试用例设计方法：等价类、边界值、错误推测法、场景法、因果图、判定表。

测试用例内容：ID 、标题、 优先级、 预置条件 、操作步骤 、预期结果、 实际结果、测试人、测试时间、备注。

3、测试用例为什么需要分级，如何分级别？测试用例需要哪些人来评审？评审的目的是什么？好的测试用例关键点是什么？不能发现BUG的测试用例不是好的测试用例吗？

用例分级之后，对于特定版本的冒烟测试、或者有大更改之后的遍历测试等等场景下，我们可以很方便快速地筛选出所需用例的最小子集，提高测试的效率。在不同阶段执行的用例数目是不同的，用例对应的功能的重要程度也是不同的，我们所约定的四个级别如下：

1. 非常重要：
   该用例执行失败，会导致很多重要功能无法运行；系统必须要使用的功能；这个级别的用例数量要控制。
2. 很重要：
   功能交互相关、个别使用频率较高的正常功能测试用例；这个级别的数量较多。
3. 一般：
   使用频率低于“很重要”级别；或使用频率与”很重要“差不多但功能很稳定；或即使发生错误，危害也很小。（举例：字段的输入范围）
4. 次要：
   功能稳定、发生错误的可能性很小；或即使发生错误，危害性也很小。

评审人员：客户、项目经理、开发人员。评审目的及时发现和客户理解不一致的地方，是否有改进的地方，希望把漏测的降到最低。毕竟测试是保证软件质量的最后一个环节，测试用例又是测试执行的依据，所以项目组非常重视测试用例的评审。

好的测试用例关键点：“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，能够完全覆盖测试需求。而跟能否发现缺陷无关。如白盒测试：较少的用例覆盖尽可能多的内部程序逻辑结果。黑盒测试：较少的用例覆盖模块输出和输入接口。用最少用例在合理时间内发现最多的问题。对可行和不可行的都要考虑：（1）输入 （2）详细操作步骤 （3）预期输出 （4）实际输出

我不这样认为，我觉得在执行之前，每个用例都可能发现缺陷，好的测试用例是一套完整的不遗漏的测试用例，是能够被其他的测试人员执行的测试用例。不能因为是否找到BUG来说明用例是否好。

4、测试分为哪几个阶段？

一般来说分为5个阶段：单元测试、集成测试、确认测试、系统测试、验收测试。

集成测试：确保最小单元被（部分）整合后能正常操作的测试执行阶段
系统测试：当应用作为整体运行时的测试执行阶段（测试最终的应用）
回归测试：修改了旧代码后，重新进行测试以确认修改操作没有引入新的错误或导致其他代码产生错误。
验收测试：以用户为主，由用户参加设计测试用例，对程序的功能、性能，以及可移植性、兼容性、可维护性、错误的恢复功能等进行确认。主要运用黑盒测试的方法，对系统主要流程、重要功能进行有效性测试，验证所测试的软件是否满足需求规格说明书列出的要求

需求分析，测试分析，测试设计，输出测试用例，测试策略，测试环境准备，测试执行，测试缺陷分析，测试报告

5、软件测试类型都有哪些？你进行过哪些测试，擅长什么?

测试类型包含：功能、性能、可靠性、安全性、负载测试，压力、安装/卸载、启动/停止、兼容、互联测试，文档、回归、可使用性、容量测试

常见：功能测试、性能测试、界面测试。
功能测试：占比最大，也叫黑盒测试（不看代码）。进行动态测试时，需要测试软件功能，不需要测试软件内部结构和处理过程。
技术方法有：等价类划分法、边界值分析、错误推测、因果图和综合策略。
性能测试：通过自动化测试工具模拟多种正常、异常、峰值条件，对系统各项性能指标测试。
负载测试、压力测试属于此。负载测试：确定各项工作负载下的系统性能，目标是负载主键增加时，系统各项性能指标变化；

压力测试：通过系统的瓶颈，获得系统能提供的最大服务级别。
界面测试：界面好坏决定用户对软件第一印象。合理的界面带来轻松愉悦感受，失败界面有挫败感，让强大的功能付诸东流。
区别：功能测试关注软件功能，每个功能可能存在的问题。性能测试软件多用户并发的稳定性和强壮性。界面测试关注用户体验和易用性。

兼容性测试：检查软件在不同软件、硬件平台是否可以正常运行。即软件的可移植性。主要查看在不同操作系统、浏览器、数据库、不同版本是否正常运行。数据格式是否兼容。

6、软件缺陷等级划分

软件缺陷的等级可以用严重性和优先级来描述：
严重性：衡量缺陷对客户满意度影响的满意程度，分为

1.致命错误，可能导致本模块以及其他相关的模块异常，死机等问题；

2.严重错误，问题局限在本模块，导致模块功能失常或异常退出；

3.一般错误，模块功能部分失效；

4.建议模块，有问题提出人对测试模块的改进建议；

优先级：缺陷被修复的紧急程度；

1.立即解决（P1级）：缺陷导致系统功能几乎不能使用或者测试不能继续，需立即修复；

2.高优先级（P2级）：缺陷严重，影响测试，需优先考虑；

3.正常排队（P3级）：缺陷需要正常排队等待修复；

4.低优先级（P4级）：缺陷可以在有时间的时候被纠正；

7、缺陷生命周期

新建bug–提交bug–确认bug–分配bug–修复bug–验证bug–关闭bug

8、测试生命周期

软件测试流程：熟悉产品/项目–需求评审–测试需求–测试计划–测试方案–测试用例–预测试，第一轮正式测试–第二轮回归测试–第三轮测试，测试报告–总结–测试指南

测试生命周期：需求测试计划制定和评审–测试用例编写–测试用例执行–bug管理–测试报告输出

（1）需求阶段测试：设计整个过程的进行、测试计划的安排、测试用例的设计以及软件的确认要达到那些要求等。
（2）设计阶段测试：包括概要设计和详细设计。在概要设计阶段，测试人员应阐述测试方法和测试评估准则，编写测试计划，组织成立独立的测试小组，安排具有里程碑的测试日程；在详细设计阶段，测试人员要开发或获取确认支持工具，生成功能测试数据和测试用例，以此来检查设计中遗漏的情况、错误的逻辑、模块接口的不匹配、数据结构不合理、错误的I/O假定、用户界面的补充分等。
（3）编码阶段测试：测试需要解决的首要问题是编码是否和设计的一致；其次是系统是否可维护，系统的规格说明是否正确地实现，编码是否按照既有的标准进行。是否有充分的测试计划评价程序，程序是否提供足够的文档资料，程序内部是否有足够的注释等。在测试完成后，要形成下列输出物：编码说明书、程序文档、计算机程序列表、可执行的程序、程序流程图、操作介绍和单元测试结果。
（4）测试阶段：要进行第三方的正确测试，检验所开发的系统是否能按照用户提出要求运行，在测试阶段要使的用户能成功地安装新的应用系统来进行测试。
（5）安装阶段测试：首先要根据系统安装手册制定好安装计划，确定安装流程图，准备好安装文件和程序清单，给出安装测试的预期结果，并对安装过程中的各项可能发生的结果进行说明准备，将程序运行的软硬件要求放入产品说明中。同时要检查时系统用户手册和操作手册，看是否可用。
（6）验收阶段测试 ：定义用户角色，定义验收标准，编制验收计划，执行验收计划和填写验收结论。

9、为什么要进行交叉测试？

因为自己执行自己设计的用例，会按照设计用例的思路来执行用例，可能会忽略一些偶然或异常的情况，交叉执行可能会发现新的BUG，当然如果用例已经写得很细，颗粒度很小吗，输入输出写得很全面交叉执行的结果都会差不多，无论谁来执行结果都是一样的。

10、α、β测试是什么，两者的区别是什么？

α测试是由一个用户在开发环境下进行的测试，可以是公司内部的用户在模拟实际操作环境下进行的受控测试，α测试不能由程序员和测试员完成。α测试发现的错误，可以在测试现场立即反馈给开发人员，由其分析和处理。目的是评价软件的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。可在编码结束/子模块测试完成之后开始。有关手册应该在测试前完成。

β测试是软件的多个用户在实际使用环境下进行的测试。开发者通常不在当前。不能由程序员和测试员来完成。因此是开发者无法控制的环境下进行的软件现场应用。同时，用户记录下所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者做修改，最终将软件产品交付给全体用户使用。Β测试更注重于产品的支持性，包括文档、客户培训和支持产品的生产能力。α测试ok后才开始β测试

区别：主要是测试场所不同，alpha是指把用户请到开发方的场所来测试，beta测试是指在一个或多个用户的场所进行测试；alpha测试的环境是受开发方控制的，用户的数量相对少，时间比较集中，beta测试环境不受开发方控制，用户数量相对多，时间不集中

11、什么是驱动模块、桩模块

驱动模块大多数称为是“主程序”，它接受测试数据并将数据传递到被测试模块，单元测试一个函数单元时，被测单元本身是不能独立运行的，需要为其传送数据，为此写驱动。
驱动模块主要完成以下内容：

１.接受测试输入

２.对输入进行判断

３.将输入传递给被测试单元，驱动被测单元执行

４.接受被测单元执行结果，并对结果进行判断

５.将判断结果作为用例执行结果输出测试报告

桩模块：用以模拟被测模块工作过程中所调用的下层模块，桩模块由被测模块调用，一般只有很少的数据处理，以便于检测被测试模块下级模块的接口，他俩可以隔离被测试单元，又能使测试继续下去。

比如对函数A做单元测试时，被测的函数单元下还包含函数B，为了更好的定位错误，就要为函数B写桩，来模拟函数B的功能，保证其正确。
总结：单元测试中，测试一个模块时，需要设计驱动模块和桩模块。

运行被测试单元时，为了隔离单元，根据被测试的接口，开发相应的驱动程序和桩程序。
驱动模块：为模拟被测试单元的上级模块，能调用被测试模块。

12、什么是白盒测试，有几种方法

又称为逻辑驱动测试，结构测试。知道产品内部的工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。
主要方法：逻辑驱动测试、基路测试

白盒测试分为静态和动态测试2类：

静态：不执行程序，静态结构分析法、代码检查法、静态质量度量法

动态：基本路径测试、逻辑覆盖（语句覆盖、判断覆盖、条件覆盖、判断-条件覆盖、条件组合覆盖、路径覆盖）、域测试、符号测试等

13、测试结束标准

单元测试退出标准

1. 单元测试用例设计已经通过评审

2. 核心代码100％ 经过Code Review

3. 单元测试功能覆盖率达到100％

4. 单元测试代码行覆盖率不低于80％

5. 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准

6. 不存在A、B类缺陷

7. C、D、E类缺陷允许存在

8. 按照单元测试用例完成了所有规定单元的测试

9. 软件单元功能与设计一致

集成测试退出标准

1. 集成测试用例设计已经通过评审

2. 所有源代码和可执行代码已经建立受控基线，纳入配置管理受控库，不经过审批不能随意更改

3. 按照集成构件计划及增量集成策略完成了整个系统的集成测试

4. 达到了测试计划中关于集成测试所规定的覆盖率的要求

5. 集成工作版本满足设计定义的各项功能、性能要求

6. 在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准

7. A、B类BUG不能存在

8. C、D类BUG允许存在,但不能超过单元测试总BUG的50％。

9. E类BUG允许存在

系统测试退出标准：

1. 系统测试用例设计已经通过评审

2. 按照系统测试计划完成了系统测试

3. 系统测试的功能覆盖率达100％

4. 系统的功能和性能满足产品需求规格说明书的要求

5. 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准

6. 系统测试后不存在A、B、C类缺陷

7. D类缺陷允许存在，不超过总缺陷的5％

8. E类缺陷允许存在，不超过总缺陷的10％

注：这只是一套比较理想化的退出标准，但在实际工作中不可能达到这种程度，尤其是测试覆盖率和缺陷解决率不可能是100%。现在的军方标准是达到99%。对于通用软件来说就要根据公司实际情况了。

14、测试报告包含哪些内容？

项目人员，测试时间，测试工具及环境，测试方法，测试范围，需求变更，bug情况（新增多少，回归验证多少，计各Bug的状态如无法复现、不予修改、延期解决等，严重程度如何），遗留问题，后期优化问题，测试风险，测试结论，附件：完整的测试用例及冒烟测试，如涉及性能测试，列出压测接口list

15、项目中的需求，测试可以和客户沟通吗？不确定的需求怎么解决？

A1：可以，最初与客户沟通需求时，测试人员直接参与，所以我们可以直接和客户方的代表开会进行沟通。

A2：不可以，一般情况下我们需要将问题整理到一起，由项目经理和测试经理作为接口人和客户进行沟通。

A3：不可以，我们的需求是产品线提的，产品线与客户直接沟通，所以关于需求问题我们直接找产品线。

一般情况下先由项目组内讨论解决，如果依旧得不到解决，则直接与需求方确认。

16、你认为测试人员需要具备哪些素质？开发犯低级错误怎么办？开发说不是bug怎么办？你为什么能够做测试这一行？你的职业规划？

做测试应该要有一定的协调能力，因为测试人员经常要与开发接触处理一些问题，如果处理不好的话会引起一些冲突，这样的话工作上就会不好做。还有测试人员要有一定的耐心，有的时候做测试很枯燥乏味。除了耐心，测试人员不能放过每一个可能的错误。开发犯低级错误时不要指责，耐心指出错误，并且让他们自己进行测试，反思找出错误。如果开发不认为时Bug，将自己的见解告诉开发，不行就把见解和bug提交项目经理决定。虽然我的测试技术还不是很成熟，但是我觉得我还是可以胜任软件测试这个工作的，因为做软件测试不仅是要求技术好，还有有一定的沟通能力，耐心、细心等外在因素。综合起来看我认为我是胜任这个工作的。巩固基础测试知识，提高理解需求能力。学习自动化测试，并且运用。技术到位后学习带领测试团队。最后争取达到测试经理水平。

17、如何测试纸杯

功能性：是否漏水；是否喝到水
安全性：有没有细菌可靠性：摔下来的损坏程度
可移植性：不同地方、温湿度使用
兼容性：容纳果汁、啤酒、汽水、汽油等
易用性：是否烫手、防滑、方便饮用水
用户文档：使用手册对用法、限制、使用条件描述
疲劳测试：分别装上水、汽油等24小时，泄露情况
压力测试：用物件不断加压，承受多大的压强

二、接口测试

1、什么是API？什么是API测试？

API是(Application Programming Interface)首字母缩略词，即应用程序编程接口。API是一组用于构建软件应用程序的规程，协议和工具。API充当软件应用程序之间的接口，并允许两个软件应用程序相互通信。API是一组软件功能，可以由其他软件执行。API测试是一种软件测试，涉及直接测试API，也是集成测试的一部分，用于检查API是否满足应用程序的功能，可靠性，性能和安全性方面的期望。在API测试中，我们主要关注软件架构的业务逻辑层。可以在包含多个API的任何软件系统上执行API测试。

2、常见的API测试点有哪些？API测试中使用的一些常用协议？用于API测试的工具？最常用的API文档模板？

• 功能测试： 　接口的功能是否正确实现了 　　接口是否按照设计文档中来实现（比如username参数写为了user，那么这就不符合，因为接口文档在整个开发中都需要使用，所以接口实际的设计要与接口设计文档中保持一致）
• 兼容性测试： 比如说今天接口进行了调整，但是前端没有进行变更，这时候需要验证新的接口是否满足旧的调用方式
• 错误码测试： 通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的情况
• 返回值测试： 返回值除了内容需要是正确的，还需要类型也是正确的，保证调用方拿到这些参数能够正确的解析
• 参数边界值、等价类测试
• json格式测试： 通常我们的接口一般设计的都是传递json串，那么就需要去测试 如果传递非json的情况，这时候程序会不会正确的处理，返回相应的 error code
• 默认值测试： 很多情况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为返回查询的结果数量， 默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在这样的数据超过10条。
• 逻辑业务： 　是否有依赖业务，比如查看订单，是需要用户首先登录的，所以肯定要保证登录了或有相应的cookie
• 业务逻辑测试： 传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行 增删改的操作，也需要看数据库是否同步进行了这些操作
• 异常测试： 异常分为两类，参数异常和数据异常
• 参数异常： 关键字参数：将参数写为开发语言中的关键字 　　参数为空：比如去掉了username参数 　　多或少参数：多或者少参数的验证，现在还不确定如果一个接口多了参数如果没有报错是否是合理的，或者是否需要优化，因为就目前开发给予的答案是，一般不对接口多了参数的处理 　　错误参数：比如将username参数写为了user等看是否能返回相应的error?code
• 数据异常： 关键字数据：将参数的值填为开发语言中的关键字 　　数据为空：将参数的额值填为空 　　长度不一致：因为数据库中每个字段都设置有字段长度，填写不符合的长度进行验证 　　错误数据：就是将参数的值任意填写，或填写不存在的数值
• 异常类型测试： 比如count参数，这个参数的类型一定是可以转换为int类型的，这时候我们需要测试如果传的一些不可以 转换为int类型值来测试代码是否加入判断
• 性能测试： 　响应时间 　　吞吐量 　　并发用户数 　　占用内存，CPU等
• 安全性测试： 敏感信息是否加密 ；必要参数是否后端也进行校验（现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证） ；接口是否防恶意请求（SQL注入） ；cookie：就是将header中的cookie修改或删除后看是否能返回相应的error?code ；header：就是删除或修改header中部分参数的值，看是否能返回相应的error code ；唯一识别码：删除修改唯一识别码测试

常用协议：HTTP、REST、SOAP

常用工具：Requests: Postman、SoapUI、JMeter、自己写代码，用python是目前接口测试使用最广的语言，python测试框架及python 抓包工具(Hardware)

常用的API文档模板：Swagger、RestDoc、Web服务API规范。

接口规范文档具体内容包含：协议规范，域名规范，版本控制规范，API路径规范，API命名规范，请求参数规范，列表请求特殊规范，返回数据规范，接口文档规范，接口管理工具使用教程

3、API和Web服务之间的区别？

Web服务：所有Web服务都是API，所有Web服务都需要通过Web(HTTP)公开
Web服务只有三种使用方式：SOAP，REST和XML-RPC进行通信
API：API有很多并不基于HTTP，API使用多种方式进行通信，例如C / C ++中的DLL文件，java中的Jar文件/ RMI，Linux内核API中的中断等。

4、什么是Soap？什么是Rest API？SOAP和REST的区别？

SOAP代表简单对象访问协议(Simple Object Access Protocol)。它是一种基于XML的消息传递协议。虽说名字带了简单，但是协议比较罗嗦，已经远没有后来居上的JSON使用广泛。

REST即Representational State Transfer。它是一组帮助开发人员执行请求和接收响应的函数。通过REST API中的HTTP协议进行交互。

SOAP：通过共享XML文档进行通信，仅支持XML格式，不支持缓存，SOAP比REST慢，SOAP就像自定义桌面应用程序，紧密连接到服务器，SOAP基于HTTP进行封装

REST：基于网络的软件架构的服务架构和设计，支持不同的数据格式，支持缓存，比SOAP更快，REST客户端就像浏览器并使用应用程序必须适合的标准方法，REST使用HTTP标头来保存元信息

5、API常见测试有哪些？API测试有哪些优势？API测试中验证哪些内容？

API常见的测试有：验证不同输入条件的返回，验证不同数据结构，验证API是否触发其他事件或请求其他API，在没有返回值时验证API的行为

• 验证API所暴露的资源是否恰当的列出、创建、修改、和删除
• 验证API是否功能可用以及用户友好，是否便于与其他平台集成
• 安全测试，验证API是否包含了必要的认证以及敏感数据是否做了脱敏处理，是否支持加密或明码的http访问
• 自动化测试，将API高度业务场景化，实现自动化测试
• 文档，形成足够的文档，确保API质量的可维护行

API测试的优势：更快及更高的测试覆盖率：API测试有助于我们降低测试成本。通过API测试，我们可以在GUI测试之前找到小错误。在GUI测试期间，这些小错误将变得更大。因此，在API测试中发现这些错误将对公司具有成本效益；
API测试与语言无关：API测试在测试核心功能方面非常有用。我们可以在没有用户界面的情况下测试API。在GUI测试中，我们需要等到应用程序可用于测试核心功能；
API测试有助于我们降低风险。

API测试验证内容：数据准确性，HTTP或其他协议状态代码，响应时间，API返回任何错误时的错误代码，授权检查
，非功能测试，如性能测试，安全测试。

6、API测试、单元测试和UI测试之间的区别？

单元测试：多由开发团队进行
白盒测试：构建中的过程之前，涉及源代码，测试范围有限，只考虑基本功能
API测试：多由QA团队进行，多为黑盒测试，在构建部署后进行，大多不涉及源代码API测试、测试范围很广，支持两个不同软件系统之间的通信。它的主要重点是应用程序的业务层。

UI（用户界面）测试：测试应用程序的图形界面部分，重点是测试应用程序的外观和感觉。

7、API测试中可能会遇到哪些问题？

• 适当的参数及其组合
• 正确分类参数
• 顺序
• 验证输出
• 由于缺少GUI，提供输入值较困难

8、执行API测试时我们一般会发现哪些BUG类型呢？

• 无法正确处理错误的深入条件
• 缺少或重复功能
• 可靠性问题
• 压力、性能和安全问题
• 多线程问题
• 性能问题
• 响应数据结构不规范问题
• 有效参数值不能正确处理
• 不兼容的错误处理机制

9、接口测试用例的编写要点有哪些？

• 必填字段：请求参数必填项、可选项
• 合法性：输入输出合法、非法参数
• 边界：请求参数边界值等
• 容错能力：大容量数据、频繁请求、重复请求（如：订单）、异常网络等的处理
• 响应数据校验：断言、数据提取传递到下一级接口…
• 逻辑校验：如两个请求的接口有严格的先后顺序，需要测试调转顺序的情况
• 性能：对接口模拟并发测试，逐步加压，分析瓶颈点
• 安全性：构造恶意的字符请求，如：SQL注入、XSS、敏感信息、业务逻辑（如：跳过某些关键步骤；未经验证操纵敏感数据）
• 测试每个参数类型不合法的情况(类型不合法容易遗漏NULL型)
• 测试每个参数取值范围不合法的情况
• 测试参数为空的情况
• 测试参数前后台定义的一致性
• 测试每个参数的上下限(这里容易出致命的BUG，如果程序处理不当，可能导致崩溃)
• 如果两个请求有严格的先后顺序，需要测试调转顺序的情况

10、列举一些最常用的HTTP方法？常见的响应状态码及意义

GET：从服务器检索数据
POST：将数据添加到服务器中的现有文件或资源
PUT：它允许您替换服务器中的现有文件或资源
DELETE：它允许您从服务器中删除数据
PATCH：用于对资源进行部分修改，选项：用于描述目标资源的通信选项
HEAD：它要求响应与GET请求相同，但没有响应正文

常见状态代码、状态描述、说明：
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

11、可以使用GET请求而不是POST请求来创建资源吗？POST和GET有什么区别？

不能，GET请求仅允许只读权限。它使您可以从服务器检索数据，但不能创建资源。应使用PUT或POST方法来创建资源。

• GET在浏览器回退时是无害的，而POST会再次提交请求。
• GET产生的URL地址可以被保存为书签，而POST不可以。
• GET请求会被浏览器主动cache，而POST不会，除非手动设置。
• GET请求只能进行url编码，而POST支持多种编码方式。
• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
• GET请求在URL中传送的参数是有长度限制的，而POST没有。
• GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
• GET参数通过URL传递，POST放在请求Body中。
• GET产生一个TCP数据包，POST产生两个TCP数据包。
• GET请求的参数只能是ASCII码，所以中文需要URL编码，而POST请求传参没有这个限制；

12、PUT和POST方法有什么区别？

POST用于在服务器上创建新对象，PUT请求用于在替换对象。当客户端将页面发送到服务器，然后服务器让客户端知道它放在何处时，应该使用POST。当客户端指定页面的位置时，应使用PUT。

13、接口产生的垃圾数据如何清理？测试的数据你放在哪？

测试用例前置操作，setUp做数据准备
后置操作，tearDown做数据清理

测试数据存放总结：

1.对于账号密码，这种管全局的参数，可以用命令行参数，单独抽出来，写的配置文件里（如ini）
2.对于一些一次性消耗的数据，比如注册，每次注册不一样的数，可以用随机函数生成
3.对于一个接口有多组测试的参数，可以参数化，数据放yaml,text,json,excel都可以
4.对于可以反复使用的数据，比如订单的各种状态需要造数据的情况，可以放到数据库，每次数据初始化，用完后再清理
5.对于邮箱配置的一些参数，可以用ini配置文件
6.对于全部是独立的接口项目，可以用数据驱动方式，用excel/csv管理测试的接口数据
7.对于少量的静态数据，比如一个接口的测试数据，也就2-3组，可以写到py脚本的开头，十年八年都不会变更的

总之不同的测试数据，可以用不同的文件管理

14、你们怎么做的参数化？

参数化和数据驱动的概念这个肯定要知道的，参数化的思想是代码用例写好了后，不需要改代码，只需维护测试数据就可以了，并且根据不同的测试数据生成多个用例

Jmeter中的CSVdata

15、接口测试的步骤有哪些？API测试设计的原理是？

步骤：

• 发送接口请求
• 测试接口获取返回值
• 断言：判断实际结果是否符合预期

原理：

• 安装：创建对象，启动服务，初始化数据等
• 执行：执行API或场景的步骤，也记录日志
• 验证：比较预期结果和实际结果
• 报告：查看执行情况，通过，失败或阻止
• 清理：回到最初的测试状态

16、异步接口怎么测试？

当业务处理比较耗时时, 接口一般会采用异步处理的方式, 这种异步处理的方式又叫Future模式。当你请求一个异步接口,接口会立刻返回你一个结果告诉你已经开始处理,结果中一般会包含一个任务id类似的东西用于追踪结果, 另外会提供一个查询结果的接口, 当结果未处理完查询接口会返回相应的"未完成"状态, 如果已经处理完,则会返回相应的数据。异步接口我们一般采取轮询的方法,每隔一定时间间隔取请求一下查询结果的接口,直到接口返回的状态是已完成/查询到指定数据或超时如果异步接口没有提供追踪id和查询接口,我们可以通过同样的方法轮询查取数据库数据或日志数据直到获取到指定结果或超时。

17、请详细阐述接口测试和UI测试在测试活动中是如何协同测试的？

18、怎么设计接口测试用例？

19、下个接口请求参数依赖上个接口的返回数据？依赖于登录的接口如何处理？依赖于第三方数据的接口如何进行测试？

不同的接口封装成不同的函数或方法，需要的数据return出来，用一个中间变量a去接受，后面的接口传a就可以了

登录接口依赖token的，可以先登录后，token存到一个yaml或者json，或者ini的配置文件里面，后面所有的请求去拿这个数据就可以全局使用了

可以利用一些MOCK工具（如：JSON Server、Easy Mock）来模拟第三方的数据返回，最大限度的降低对第三方数据接口的依赖

20、不可逆的操作，如何处理，比如删除一个订单这种接口如何测试

此题考的是造数据的能力，接口的请求数据，很多都是需要依赖前面一个状态的
比如工作流这种，流向不同的人状态不一样，操作权限不一样，测试的时候，每种状态都要测到,就需要自己会造数据了。
平常手工测试造数据，直接在数据库改字段状态。那么自动化也是一样，造数据可以用python连数据库了，做增删改查的操作
测试用例前置操作，setUp做数据准备
后置操作，tearDown做数据清理

21、json和字典dict的区别？

• json格式的数据，在python中以字符串形式呈现

• json中的空置为 null，字典中的空值为 None

• json中除数字外，所有的key和value都是字符串，而且一定要用双引号括起来，json中的key不论是数字还是字符串都要用双引号括起来（key可以重复）；python中的字典key为数字时用不用引号括起来都可以（key不能重复）

• json里面类似dict里面的键可以重复，转换成字典之后，后面的会将前面的覆盖，因为dict里面的键不能重复

• json= 会把 content-type 设成 application/json

三、性能测试

1、性能测试包含了哪些软件测试（至少举出3种）？

负载测试（Load Testing）：负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。

压力测试（Stress Testing）：强度测试也就是压力测试，压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。

容量测试（Volume Testing）：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。

或者在下面选择几项：

并发测试 - 测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题

基准测试 - 比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。

争用测试：- 核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受。

性能配置 - 核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的可接受性。

负载测试- 核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。

强度测试- 核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。

容量测试- 核实测试用户同时使用软件程序的最大数量

2、请问什么是性能测试、负载测试、压力测试？

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

负载测试、压力测试参考答案如上题。

3、在给定的测试环境下进行，考虑被测系统的业务压力量和典型场景？

负载测试

负载测试是用来测定系统饱和状态、确定阀值。其特点有：

1） 这种方法的目的是找到系统处理能力的极限；通过“检测、加压、阀值”手段找到如“响应时间不超过10秒”，“平均cpu利用率低于65%”等指标。

2） 这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景、另外HP Mercury LoadRuner在使用该方法进行“加压”的时候必须选择典型场景。

3） 这种性能测试方法一般用来了解系统的性能容量，或者是配合性能调优的时候来使用。特别是该的Weblogic 和库的性能调优。

4、什么时候可以开始执行性能测试？

在产品相对比较稳定，功能测试结束后。灵活性比较强。

5、简述性能测试的步骤。

熟悉应用

了解应用的架构、功能逻辑

测试需求

1、需要将开发给定的需求转为吞吐量和响应时间。

2、根据测试目的，细化需求

测试准备

测试准备包括测试客户端机器准备、测试数据准备、测试脚本准备。

测试执行

测试的执行中，需要监控测试客户端和服务器性能，监控服务器端应用情况：

客户端的系统资源（cpu、io、memory）情况

服务端的系统资源（cpu、io、memory）情况

服务器的jvm运行情况

服务端的应用情况，看是否有异常

响应时间、吞吐量等指标

系统资源监控，linux下可以采用的工具有：vmstat、top、meminfo等。

JVM的监控，可以用jprofiler工具，linux下面的jmap、jhat等。

响应时间、吞吐量等，由grinder提供。

上述这些信息，一般在测试结束后，均需要归档整理，已备后续详细分析

我们自己开发一套脚本，用于以固定的频率获取测试客户端和服务器的vmstat和top输出、grinder的log，并从中截取有用信息保存，用于事后分析。

每次测试运行完以后，肯定会增加很多数据，需要考虑本次执行对数据量的影响，如果数据量的变化对后续测试会有影响，则需要清理数据。

测试分析

6、你如何识别性能瓶颈？

RBI方法

重点测试“吞吐量”指标，因为RBI认定80%的系统性能瓶颈由吞吐量造成。RBI方法

按照网络、硬件、数据库、应用服务器、代码的顺序自上而下分析性能

工具：IBM、HP、OpenSource工具都支持。需使用分析模块、根据Weblogic、Oracle区别有专门的工具实现RBI。

7、性能测试时，是不是必须进行参数化？为什么要创建参数？LoadRunner中如何创建参数？

是。模拟用户真实的业务操作。

创建参数列表，用参数替换固定的文本。

8、你如何设计负载？标准是什么？

负载测试计划多少用户数量、使用什么类型的机器、以及在什么环境下进行。主要基于两个重要的文档，任务分布图和事务信息，任务分布图告诉我们在负载时间段内，某一个事务使用的用户数，高峰使用率及低峰使用率均来自该文档；事务信息告诉我们事务名及优先级，在设计场景时可以参考。

9、解释5个常用的性能指标的名称与具体含义。

响应时间、并发用户数，吞吐量，性能计数器，TPS，HPS

响应时间：指的是“系统响应时间”定义为应用系统从发出请求开始到客户端接收到响应所消耗的时间。把它作为用户视角的软件性能的主要体现。

最大并发用户数：有两种理解方式，一种是从业务的角度来模拟真实的用户访问，体现的是业务并发用户数，指在同一时间段内访问系统的用户数量。另一种是从服务器端承受的压力来考虑，这里的“并发用户数”指的是同时向服务器端发出请求的客户数，该概念一般结合并发测试（Concurrency Testing）使用，体现的是服务端承受的最大并发访问数。

吞吐量是指“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力。

性能计数器（Counter）是描述服务器或操作系统性能的一些数据指标。例如，对Windows 系统来说，使用内存数（Memory In Usage），进程时间（Total Process Time）等都是常见的计数器。

思考时间（Think Time），也被称为“休眠时间”，从业务的角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。从自动化测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个操作之间等待一段时间，体现在脚本中，具体而言，就是在操作之间放置一个Think 的函数，使得脚本在执行两个操作之间等待一段时间。

TPS:Transaction per second，每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能力的重要指标。

点击率：HPS，每秒钟用户向WEB服务器提交的HTTP请求数。

10、描述不同的角色（用户、产品开发人员、系统管理员）各自关注的软件性能要点。

用户：重点关注打开速度及响应时间

开发：重点关注响应时间和数据库交互

管理员：重点关注用户感受到的软件性能；如何利用管理功能进行性能调优；如何利用其他软硬件手段进行性能调优

11、请分别针对性能测试、负载测试和压力测试试举一个简单的例子？

性能测试例子：公司开发了一个小型项目管理系统，上线前需要做负载、压力、大数据量、强度测试等。

负载测试：逐步加压，从而得到“响应时间不超过10秒”，“服务器平均CPU利用率低于85%”等指标阀值。

压力测试：逐步加压，从而使“响应时间超过10秒”，“服务器平均CPU利用率高于90%”等指标来确定系统能承受的最大负载量。

12、请问您是如何得到性能测试需求？怎样针对需求设计、分析是否达到需求？

在查看需求文档，从中提取性能测试需求，与用户交流，了解实际使用情况。

结合业务信息设计操作场景总结出需测试的性能关键指标。

执行用例后根据提取关键性能指标来分析是否满足性能需求。

13、描述你的性能测试流程

• 做性能需求分析，挑选用户使用最频繁的功能来做测试，比如：登陆，搜索，提交订单
• 确定性能指标，比如：事务通过率为100%；90%的事务响应时间不超过5秒；并发用户为1000人时CPU和内存的使用率在70%以下
• 性能测试计划，明确测试时间(通常在功能稳定后，如第一轮测试后进行)和测试环境和测试工具的选择
• 搭建性能测试环境
• 通过性能测试用例，编写性能测试脚本，准备性能测试数据
• 性能测试脚本进行调优，设置检查点、参数化、关联、集合点、事务，调整思考时间
• 设计性能测试场景，监控服务器，运行测试场景
• 分析性能测试结果，判断性能瓶颈，反馈结果信息
• 回归性能测试
• 编写性能测试报告

四、安全测试

1、HTTP接口测试和Web Service接口测试区别是什么？

由于要进行xml解析，webservice接口测试速度会比http接口测试有所降低请。webservice求是HTTP的一个专用版本，遵循一种特殊的xml消息格式Content-type设置为： text/xml任何数据都可以xml化。

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络传输协议，所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。

webservice接口测试流程：

• 开发人员要到接口的wsdl地址和接口设计说明书。
• 在soapui中新建工程，导入wsdl地址。
• 选择自己要测试的接口的方法，选择request。
• 根据接口设计说明书选择要测试方法的xml请求，并粘贴到soapui的请求栏，然后用自己的测试数据替换原有的xml请求中的参数。
• 点击运行，查看返回的xml响应，并参照接口设计说明书及自己的输入参数，确定接口返回的xml响应是否是预期结果，以判断接口是否是通的 。

2、HTTPS的优点和缺点？HTTPS的工作原理？HTTPS和HTTP的区别？什么是http代理服务器，有什么用？HTTPS在哪一层, 会话层在第几层？

尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

• 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
• HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
• HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
• 谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

• HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
• HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
• SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
• SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
• HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

我们都知道HTTPS能够加密信息，以免敏感信息被第三方获取，所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。

客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图所示。

• 客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。
• Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
• 客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。
• 客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
• Web服务器利用自己的私钥解密出会话密钥。
• Web服务器利用会话密钥加密与客户端之间的通信。

HTTPS和HTTP的区别主要如下：

• https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
• http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
• http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
• http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

3、简述TCP/IP的三次握手和四次挥手，为什么TCP建立连接协议是三次握手，而关闭连接却是四次握手呢？为什么不能用两次握手进行连接？

三次握手

起初，服务器和客户端都为 CLOSED 状态。

在通信开始前，双方都得创建各自的传输控制块（TCB）。

服务器创建完 TCB 后遍进入 LISTEN 状态，此时准备接收客户端发来的连接请求。

第一次握手

客户端向服务端发送连接请求报文段。该报文段的头部中SYN=1，ACK=0，seq=x。请求发送后，客户端便进入SYN-SENT状态。

• • PS1：SYN=1，ACK=0表示该报文段为连接请求报文。
  • PS2：x为本次TCP通信的字节流的初始序号。
  • TCP规定：SYN=1的报文段不能有数据部分，但要消耗掉一个序号。

第二次握手 服务端收到连接请求报文段后，如果同意连接，则会发送一个应答：SYN=1，ACK=1，seq=y，ack=x+1。该应答发送完成后便进入SYN-RCVD状态。

• • PS1：SYN=1，ACK=1表示该报文段为连接同意的应答报文。
  • PS2：seq=y表示服务端作为发送者时，发送字节流的初始序号。
  • PS3：ack=x+1表示服务端希望下一个数据报发送序号从x+1开始的字节。

第三次握手

当客户端收到连接同意的应答后，还要向服务端发送一个确认报文段，表示：服务端发来的连接同意应答已经成功收到。该报文段的头部为：ACK=1，seq=x+1，ack=y+1。

客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接的建立完成！

四次挥手

TCP连接的释放一共需要四步，因此称为『四次挥手』。

我们知道，TCP连接是双向的，因此在四次挥手中，前两次挥手用于断开一个方向的连接，后两次挥手用于断开另一方向的连接。

第一次挥手

若A认为数据发送完成，则它需要向B发送连接释放请求。该请求只有报文头，头中携带的主要参数为： FIN=1，seq=u。此时，A将进入 FIN-WAIT-1 状态。

• • PS1：FIN=1表示该报文段是一个连接释放请求。
  • PS2：seq=u，u-1是A向B发送的最后一个字节的序号。

第二次挥手

B收到连接释放请求后，会通知相应的应用程序，告诉它A向B这个方向的连接已经释放。此时B进入CLOSE-WAIT状态，并向A发送连接释放的应答，其报文头包含： ACK=1，seq=v，ack=u+1。

• • PS1：ACK=1：除TCP连接请求报文段以外，TCP通信过程中所有数据报的ACK都为1，表示应答。
  • PS2：seq=v，v-1是B向A发送的最后一个字节的序号。
  • PS3：ack=u+1表示希望收到从第u+1个字节开始的报文段，并且已经成功接收了前u个字节。

A收到该应答，进入FIN-WAIT-2状态，等待B发送连接释放请求。

第二次挥手完成后，A到B方向的连接已经释放，B不会再接收数据，A也不会再发送数据。但B到A方向的连接仍然存在，B可以继续向A发送数据。

第三次挥手

当B向A发完所有数据后，向A发送连接释放请求，请求头：FIN=1，ACK=1，seq=w，ack=u+1。B便进入LAST-ACK状态。

第四次挥手

A收到释放请求后，向B发送确认应答，此时A进入TIME-WAIT状态。

该状态会持续2MSL时间，若该时间段内没有B的重发请求的话，就进入 CLOSED 状态，撤销TCB。

当B收到确认应答后，也便进入 CLOSED 状态，撤销 TCB。

为什么A要先进入TIME-WAIT状态，等待2MSL时间后才进入 CLOSED 状态？为了保证B能收到A的确认应答。若A发完确认应答后直接进入 CLOSED 状态，那么如果该应答丢失，B等待超时后就会重新发送连接释放请求，但此时A已经关闭了，不会作出任何响应，因此B永远无法正常关闭。

4、TCP和UDP有什么区别？

• TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
• TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
• TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
• 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
• TCP首部开销20字节;UDP的首部开销小，只有8个字节
• TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

5、什么是TCP/IP？什么是OSI协议？TCP/IP协议以及每层对应的协议？为什么说TCP/IP协议是不可靠的？OSI有哪七层模型？TCP/IP是哪四层模型？

TCP/IP，也就是互联网协议套件（英语：Internet Protocol Suite，缩写IPS）是一个网络通信模型，以及一整个网络传输协议家族，为网际网络的基础通信架构。

因为该协议家族的两个核心协议：TCP（传输控制协议）和IP（网际协议）为该家族中最早通过的标准，所以它常被通称为TCP/IP协议族，简称TCP/IP。

由于在网络通讯协议普遍采用分层的结构，当多个层次的协议共同工作时，类似计算机科学中的堆栈，因此又被称为TCP/IP协议栈。

TCP/IP提供点对点的链接机制，将数据应该如何封装、定址、传输、路由以及在目的地如何接收，都加以标准化。

它将软件通信过程抽象化为四个抽象层，采取协议堆栈的方式，分别实现出不同通信协议。

协议族下的各种协议，依其功能不同，被分别归属到这四个层次结构之中，常被视为是简化的七层OSI模型。

TCP/IP四层模型：

• 应用层：应用程序之间相互沟通的层
• 传输层：提供了数据传输，应用程序之间的通信服务
• 网络互联层：负责提供基本的数据封包传送功能，让每一块数据包都能够到达目的主机
• 网络接口层：接收数据，并进行传输

6、TCP长连接和短连接的区别？

当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次挥手，所以说每个连接的建立都是需要资源消耗和时间消耗的

长连接：

所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持（不发生RST包和四次挥手）。

连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接（一个TCP连接通道多个读写通信）；

这就要求长连接在没有数据通信时，定时发送数据包(心跳)，以维持连接状态；

TCP保活功能，保活功能主要为服务器应用提供，服务器应用希望知道客户主机是否崩溃，从而可以代表客户使用资源。如果客户已经消失，使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，则服务器将应远等待客户端的数据，保活功能就是试图在服务器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何的动作，则服务器就向客户发一个探测报文段，客户主机必须处于以下4个状态之一：

1. 1. 客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两小时后将保活定时器复位。
   2. 客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务端将不能收到对探测的响应，并在75秒后超时。服务器总共发送10个这样的探测 ，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
   3. 客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
   4. 客户机正常运行，但是服务器不可达，这种情况与2类似，TCP能发现的就是没有收到探查的响应。

短连接：

短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接（管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段）；

连接→数据传输→关闭连接；

应用场景：

长连接多用于操作频繁（读写），点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

而像WEB网站的http服务一般都用短链接（http1.0只支持短连接，1.1keep alive 带时间，操作次数限制的长连接），因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好；

在长连接中一般是没有条件能够判断读写什么时候结束，所以必须要加长度报文头。读函数先是读取报文头的长度，再根据这个长度去读相应长度的报文。

7、为什么要有cookie，它的作用是什么？测试点有哪些？缺点是什么？cookie与session的区别？

cookie可以解决http的无状态的问题，与服务器进行交互，作为http规范存在。它具有极高的简便性、可扩展性和可用性，也可以通过加密和SSL技术来提高其安全性。因此推荐使用cookie作为标识而不是身份验证的工具。

其中cookie的作用就是为了解决HTTP协议无状态的缺陷所作出的努力

• 禁止使用Cookie：设置浏览器禁止使用Cookie，访问网页后，检查存放Cookie文件中未生成相关文件；
• Cookie存储路径：按照操作系统和浏览器对Cookie存放路径的设置，检查存放路径是否与设置一致；
• Cookie过期检查：按照Cookie过期时间，检查存放文件该Cookie是否被自动删除；
• 检查浏览器中Cookie选项：通过不同浏览器，设置是否接受Cookie文件，如同意接受Cookie，检查存放路径中是否存在Cookie文件；
• 浏览器删除Cookie：通过浏览器的设置，删除Cookie文件；
• Cookie加密：提交敏感信息时，数据应加密；
• Cookie保存信息：验证Cookie能正常工作；
• 篡改Cookie：修改Cookie内容，查看系统功能是否出现异常，或数据错乱；
• Cookie的兼容性：使用不同类型，或同一类型不同版本的浏览器，检查cookie文件的兼容性；
• 刷新操作对cookie的影响：进行刷新操作后，是否重新生成cookie文件或是对cookie文件进行修改；
• 检查cookie内容存储是否完整正确：若cookie进行了加密，先对cookie文件内容进行解密，然后检查是否按照设计要求存储了相关所有的cookie记录信息；
• 对应硬盘存储空间没有空闲时，是否能进行cookie内容的有效存储；
• 多次做相同的操作或设置，检查是否更新或添加了新的cookie文件，按照设计要求进行判断；
• 如果使用cookie来统计次数，则要检测是否统计正确；

缺点：

• 大小和数目受限制。浏览器对一个域cookie的条目数有上限要求，且每个cookie的大小不得超过4kb。
• 存在安全性问题，易被人拦截。
• 需要指定域，不可以跨域
• 浪费带宽，因为我每次请求一个新的页面，cookie都会被自动发送过去。
• 有的移动端浏览器不支持cookie或浏览器禁用cookie
• 有些状态不可能保存在客户端。例如，为了防止重复提交表单，我们需要在服务器端保存一个计数器。如果我们把这个计数器保存在客户端，那么它起不到任何作用。

cookie与session的区别：

• 保存位置。SESSION 数据保存在服务器端**，Cookie 数据保存在**客户端浏览器
• 保存方式。SESSION 默认被存在在服务器的一个文件里，可以手动设置放在文件、数据库、或内存中；Cookie 默认保存在客户端内存中，如果设置了过期时间就保存在硬盘中。
• 依赖关系。SESSION 依赖 Cookie 来识别 session_id，如果浏览器禁用了 Cookie，SESSION 也会失效，此时可以通过 url 传递 session_id。
• 安全性。因为 SESSION 数据保存在服务端，所以 SESSION安全性比Cookie 高。
• 尺寸大小。SESSION 基本上没有大小限制，COOKIE 保存的内容比较小，具体由浏览器决定。
• 服务器性能。SESSION 对服务器的压力会更大一些，而 Cookie 放在客户端，所以对服务器基本没影响
• 所以建议：将登陆信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中

8、什么是安全测试（Security Testing）？

在所有类型的软件测试中，安全测试可以被认为是最重要的。其主要目的是在任何软件（Web或基于网络）的应用程序中找到漏洞，并保护其数据免受可能的攻击或入侵者。由于许多应用程序包含机密数据，需要被保护泄漏。软件测试需要定期在这样的应用程序上进行，以识别威胁并立即采取行动。

9、什么是漏洞（Vulnerability）？

漏洞可以被定义为任何系统的弱点（Vulnerability），入侵者或bug可以通过该系统进行攻击。如果系统没有严格执行安全性测试，那么漏洞的机会就会增加。有时补丁或修复程序需要防止系统出现漏洞。

10、什么是入侵检测（Intrusion Detection）？

入侵检测（Intrusion Detection）是帮助确定和处理可能的攻击的系统。入侵检测包括从多个系统和源收集信息，分析信息，找出可能的攻击方式。

入侵检测检查如下：

• 可能的攻击
• 任何异常活动
• 审核系统数据
• 不同采集数据的分析等。

11、什么是SQL注入（SQL injection）？

SQL注入是黑客获取关键数据的常用攻击技术之一。

黑客检查系统中的任何循环漏洞，通过这些漏洞，他们可以通过SQL查询传递安全检查并返回关键数据。这就是所谓的SQL注入。它可以允许黑客窃取关键数据，甚至使系统崩溃。

SQL注入非常关键，需要避免。定期的安全测试可以防止此类攻击。SQL数据库安全性需要正确定义，输入框和特殊字符应该正确处理。

12、列举安全测试的关注点？

1. Authentication
2. Authorization
3. Confidentiality
4. Availability
5. Integrity
6. Non-repudiation
7. Resilience

13、什么是XSS？

XSS或跨站点脚本是黑客用来攻击web应用程序的漏洞类型。

它允许黑客将HTML或JAVASCRIPT代码注入网页，网页可以从cookie中窃取机密信息并返回给黑客。这是最关键和最常见的技术之一，需要加以预防。

14、什么是SSL连接和SSL Session？

SSL或安全套接字层连接是瞬态对等通信链路，其中每个连接与一个SSL会话（SSL Session）相关联。

SSL会话可以定义为通常由握手协议列出的客户端和服务器之间的关联。定义了一组参数，并且可以由多个SSL连接共享。

15、什么是渗透测试（Penetration Testing）？

渗透测试（Penetration Testing）是关于安全测试的，它有助于识别系统中的漏洞。渗透测试是试图通过手动或自动技术来评估系统的安全性，以及如果发现任何漏洞测试人员使用该漏洞来更深入地访问系统并发现更多漏洞。此测试的主要目的是防止系统受到任何可能的攻击。

渗透测试可以通过两种方式进行——白盒测试和黑盒测试。

在白盒测试中，测试人员可以使用所有信息，而在黑盒测试中，测试人员没有任何信息，他们在真实场景中测试系统以找出漏洞。

16、为什么渗透测试（Penetration Testing）非常重要？

渗透测试很重要，因为：

• 由于攻击的威胁总是可能的，黑客可以窃取重要数据，甚至使系统崩溃，因此系统中的安全漏洞和环路漏洞可能非常昂贵。
• 不可能一直保护所有的信息。黑客总是会带来新的技术来窃取重要数据，以及测试人员需要定期执行测试以检测可能的攻击。
• 渗透测试通过上述攻击来识别和保护系统，并帮助组织保持其数据安全。

17、 请说出用于保护密码文件的两种常见技术？

保护密码文件的两种常见技术是散列密码和salt值或密码文件访问控制。

18、什么是ISO/IEC 17799？

ISO/IEC 17799最初在英国出版，定义了信息安全管理的最佳实践。它针对所有小型或大型信息安全组织都有指导方针。

19、列举一些可能导致软件系统存在漏洞的因素？

造成漏洞的因素有：

• 设计缺陷——如果系统中存在允许黑客轻易攻击系统的环路漏洞。
• 密码——如果黑客知道密码，他们可以很容易地获得信息。应严格遵守密码政策，以尽量减少密码被盗的风险。
• 复杂性——复杂软件可以打开漏洞的大门。
• 人为错误——人为错误是安全漏洞的重要来源。
• 管理——数据的管理不当会导致系统中的漏洞。

20、列举进行安全测试的方法论？

安全测试的方法论有：

White Box- All the information are provided to the testers.
Black Box- No information is provided to the testers and they can test the system in real world scenario.
Grey Box- Partial information is with the testers and rest they have to rest on their own.

21、列举开源安全测试方法手册列出7种主要类型的安全测试？

根据开源安全测试方法手册，7种主要的安全测试类型是：

• 漏洞扫描：自动软件针对已知的漏洞扫描系统。
• 安全扫描:手动或自动识别网络和系统弱点的技术。
• 渗透测试：渗透测试是关于安全测试的，它有助于识别系统中的漏洞。
• 风险评估：包括对系统中可能的风险进行分析。风险分为低、中、高三种。
• 安全审计：完成对系统和应用程序的检查，以检测漏洞。
• 道德黑客:为检测系统中的缺陷而非个人利益而对系统进行的黑客攻击。
• 态势评估：将安全扫描、道德黑客和风险评估结合起来，以显示组织的总体安全态势。

22、什么是SOAP and WSDL？

SOAP或简单对象访问协议是基于XML的协议，应用程序通过该协议通过HTTP交换信息。XML请求由SOAP格式的Web服务发送，然后SOAP客户端向服务器发送SOAP消息。服务器再次用SOAP消息和请求的服务进行响应。

Web服务描述语言（WSDL）：是UDDI使用的XML格式语言。“Web服务描述语言描述Web服务以及如何访问它们”。

23、请列举SSL session connection中定义的参数？

The parameters that define an SSL session connection are:

Server and client random
Server write MACsecret
Client write MACsecret
Server write key
Client write key
Initialization vectors
Sequence numbers

24、什么是 file enumeration？

这种攻击使用强制浏览和URL操作攻击。黑客可以操纵url字符串中的参数，获得通常不向公众开放的关键数据，如已实现的数据、旧版本或正在开发的数据。

25、入侵检测系统（ intrusion detection system）有什么优点？

入侵检测系统有三个优点。

• NIDS或网络入侵检测
• NNIDS或网络节点入侵检测系统
• HIDS或主机入侵检测系统

26、什么是HIDS？

HIDS或主机入侵检测系统是一种对现有系统进行快照，并与以前的快照进行比较的系统。它检查是否修改或删除了关键文件，然后生成警报并发送给管理员。

27、解释一下什么是URL操纵（URL manipulation）?

URL操纵是黑客操纵网站URL获取关键信息的一种攻击。该信息在查询字符串中的参数中通过HTTP GET方法在客户机和服务器之间传递。黑客可以更改这些参数之间的信息，并在服务器上获得身份验证并窃取关键数据。

为了避免这种攻击，需要进行URL操作的安全性测试。测试人员本身可以尝试操作URL并检查可能的攻击，如果发现它们可以防止此类攻击。

28、常见的三类入侵者（intruders）都是什么？

• Masquerader：它可以被定义为在计算机上未被授权但攻击系统的访问控制并获得经过身份验证的用户帐户的访问的个人。
• Misfeasor：在这种情况下，用户被认证为使用系统资源，但是他未能使用对系统的访问。
• Clandestine user：可以定义为攻击系统的控制系统并绕过系统安全系统的个人。

29、请列举SSL中常常使用到的组件有哪些？

安全套接字层协议或SSL用于在客户端和计算机之间建立安全连接。以下是在SSL中使用的组件：

• SSL记录协议
• 握手协议
• 更改密码规范
• 加密算法

30、什么是端口扫描（port scanning）？

端口是信息进出任何系统的点。扫描端口以发现系统中的任何环形孔称为端口扫描。系统中可能存在黑客攻击和获取关键信息的弱点。这些点应该被识别并防止任何滥用。

常见的Port Scanning类型：

Strobe: Scanning of known services.
UDP: Scanning of open UDP ports
Vanilla: In this scanning the scanner attempts to connect to all 65,535 ports.
Sweep: The scanner connects to the same port on more than one machine.
Fragmented packets: The scanner sends packet fragments that get through simple packet filters in a firewall
Stealth scan: The scanner blocks the scanned computer from recording the port scan activities.
FTP bounce: The scanner goes through an FTP server in order to disguise the source of the scan.

31、什么是honeypot？

Honeypot是一种伪计算机系统，它表现得像一个真实的系统，并吸引黑客对其进行攻击。Honeypot用于发现系统中的环路漏洞，并为此类攻击提供解决方案。

32、请列举用于描述 SSL Session state定义的参数？

Session identifier
Peer certificate
Compression method
Cipher spec
Master secret
Is resumable

33、请简单描述一下 Network Intrusion Detection system？

Network Intrusion Detection System（NIDS）它用于分析整个子网上的传递流量，并与已知的攻击进行匹配。如果识别出任何循环漏洞，则管理员将收到警报。

六、团队管理

1、测试团队的工作也依赖于业务和开发，如何有效提高与业务团队和开发团队的合作默契？

解答1：

测试团队与开发团队和业务团队的沟通，都是难点。这个难点，一方面是沟通机制的问题。但是更为重要的是各自的知识积累，比如测试人员的业务知识积累，以及对软件系统的全面了解。

因此，对于复杂的产品，比如业务性很强的软件，比如复杂通讯系统，复杂的金融系统，测试工程师的测试效果，可能三分靠测试技术，七分要靠对测试金融、通讯具体业务的了解和掌握程度。测试人员的职业寿命比较长，与这一点也是密切相关。对于复杂的业务来说，培养一个测试专家不难，难的是培养一个对业务全面了解的业务专家是很难的。这也是测试工程师职业竞争力的一个积累点所在。

解答2：

测试团队和开发团队的关系是上下游关系，测试的进程依赖于开发的进度，测试的结果需要开发承认。需要注意的是双方的关系要融洽。开发和测试容易形成敌对关系，这需要开发和测试的主管要具备协调对立关系的能力和缓解对立情绪办法。

2、团队如何考虑平衡质量和速度的测试策略？

解答1：

测试本身就是在成本和质量之间找的平衡点，如果投入的财力和工作量是有限的。那么必须对被测试对象的功能点划分优先级，优先级高的优先测试。

另外，一个要考虑产品遗留bug会产生后果的严重程度。如果是公司内部IT系统，功能对业务影响不大，又着急上线，那么跑完正常功能和正常流程，以及少量异常流程，基本就可以上西线了。如果，是银行、电信这类系统，没有办法避免投入。目前，中国的银行在IT方面的投入，可能是世界之最，超级的投入，产生超级的应用和质量。大家可以对比国外的金融IT，基本上都不是中国的对手。如果是产品，或者系统不断迭代升级的软件系统，那么就需要考虑自动化了。一般来说，同一产品，五轮以上的手工测试，就可以考虑自动化了。这是提升效率的好办法。

不同的项目，对软件的质量要求是不一样的，公司的领导层必须对产品质量的要求要有理性客观的定位，否则，会出现测试资源投入不足，造成既要马儿跑，又不让马儿吃草的局面。所以说，测试工作的定调，首先是研发的老大要做好的。如果一旦做不好，可能工作开展就比较麻烦。我对这个问题，就阐述到此。

解答2：

移动app举例解答下这个问题，app要求全质量（功能、性能、易用性、安全和兼容性，一样不少），考虑到发布要求尽量做到分层测试。

第一种分层考虑是先考虑接口功能、UI功能和性能测试，再考虑兼容性和安全测试。第二种分层考虑研发阶段、系统测试阶段和上线回归三个阶段任务分层。研发相当于功能集成测试，尽量做到接口功能自动化测试，用例和自动化保持在基本覆盖用例集，内部测试团队独立承担；在系统测试和上线验收阶段，可考虑众测、灰度发布用户中组织并承担测试。

系统测试和验收测试阶段，倘若用例质量高，建立众测能力也是不错的选择，用例覆盖有保障，执行层面参与的人多了，手工比自动化测试效率更高。

3、敏捷模式下，如何平衡快速发布和客户对质量的期望？

**解答：**敏捷指的是内部迭代的敏捷，不是鲁莽的把一个没经过充分测试的产品直接推给客户。客户对质量的期望需要在销售阶段就做好引导，测试人员在后期面对客户去平衡客户的期望就太晚了。

4、团队的人测不出问题 ，上线后问题又很多，主管只能抽测一些重点的 ，这种情况怎么解决？

解答1：

团队的人员测试不出来问题，这是很严重的。那么，首先要找到原因所在。既然主管，做了一些重新测试，如果主管发现了问题，针对这些问题，要与测试工程师一起分析为什么测试工程师没有发现问题。也就是做缺陷分析，缺陷分析是提升测试人员测试效果很好的手段。

解答2：

如果系统的使用环境很复杂的话，这种情况就不是自己能避免的了。某公司，他们内部测试团队能力已经比较强了，但是系统部署到客户那里依然会出现各种问题，归根到底是因为客户是多样的，而自己的测试环境变化是有限的。解决方案只能是自家的测试队伍努力提高测试用例的完备性，利用其它力量在不同的环境下做充分验证。

解答3：

我觉得测试测不出问题，工作量评估、工作环境评估不准也是原因。

应需充分调研客户的具体需求，实际运作环境，然后做测试工作量的准确评估，提出合理的人力、测试时长诉求。如果人力、时间给足了，Case也覆盖到了，还有遗漏，就是严重的工作态度问题，属于测试遗漏。我们的做法是所有跟用例无关的缺陷，后续都必须维护回测试用例里，不求用例百分百覆盖，但应尽可能趋近于百分百。

七、非技术相关问题，软实力

1、自我介绍

套路
1）很高兴获得面试机会……想证明我是合适的人选……想获得您的认可……
2）反问面试官：您看我继续介绍项目还是您提问关心的问题？

从业时间，教育背景，工作经验，擅长技能，你的性格。
实例：你好，我叫xxx，19年从xxxx大学毕业，18年六月至今在xxx有限公司从事软件测试工作。
主要负责过两个项目：

1、xxxapp 通过人工智能发现每个人自己喜欢的视频，并可以帮助视频创作人轻松地向全世界分享自己的视频作品。
2、xxx 利用现有流量，广告资源，精准投放给贷款用户，并推荐贷款超市中的产品

在项目中我负责包括测试用例设计，接口测试，功能测试等；可以使用Python 编写基本的自动化脚本。
（我是一个自律，热爱学习人，有信心做好测试工作）

2、项目和测试流程

——你是如何进行测试的？

——项目做了多久？ 上家公司多少测试人员？多少开发？公司规模多大？

——具体分工？针对测试组成员

——项目业务？ 敏捷开发模式？

迭代版本？ 每次迭代时间？ 项目周期中你扮演的角色？你角色的重要性？

先整体再局部介绍，项目五大维度：
规模（代码规模、需求规模、用例规模、工作量、进度、质量、成本），测试流程，角色与职责，项目中自己角色，自己的特色（做得好的、遇到的困难、做得差的），最后是心得体会。

3、公司测试工作怎么进行？

根据产品经理编写的需求文档做需求分析（小组讨论，不懂问经理），测试经理制定测试计划 ，各成员分别写用例，小组内审核，会议讨论整个项目组的用例评审，开发研发完毕后，测试组接入测试，根据测试用例和功能分工任务来测试， 浏览器的兼容性，执行过程返现缺陷，提交bug到缺陷管理平台，对bug进行追踪，直到满足客户需求，测试完成。

对测试结果进行分析，写好测试报告，提交测试报告并通过运维发布后，上线后，关注web是否正常运行

问题：

——bug生命周期

——bug记录里面包含哪些内容：

——提交bug开发不认，测试该怎么办？

——对于复现率不高的bug，

——前后端bug 定位问题

——影响深刻的bug

——计划？报告？ 搞清楚内容！ 关键/重点是什么

4、Hr心理

Hr 到底在考察什么？

求职者的动机与工作期望：双向选择：体现对职位兴趣很高

求职者的仪表、性格、知识、能力、经验等特征

考核笔试中难以获得的信息：水分不真实区分真伪？软能力？

1、自我介绍（说出和别人不一样的）三个关键词

2、举例说明你的影响力

3、管理班级中遇到的问题，怎么解决的

4、如何学习

5、为什么做测试开发？以后是怎么规划的

5、面试原则

**原则：**真诚、不卑不亢、正能量、专业

离职原因：

社会责任感

职业规划

向自动化测试方面

向管理方面

谈缺点：

真实的，无伤大雅的，一经发现，针对改正方案

粗心：备忘录，好记性不如烂笔头，自律

要求对方发问：

对公司，项目，职位，技术充满兴趣的问题

公司这边是否有老人可以带新人

挑战式的问题：

你不会的该怎么办

陷阱式的问题：

领导的犯错

不熟悉的领域

发散性的问题：

解决问题的经历

测试最重要的是什么

测试环境搭建

6、你还有什么想要问的吗？

满意情况：先表示感谢，问如果有下一轮面试，什么时候，做什么准备；
一般般情况：感谢，对自己表现不太满意，能否给我一些建议；
很糟糕：感谢，认识到不足，希望给建议

5、测试工具相关

三大类：

第一类是测试管理类工具（基本：权限管理系统，svn），功能测试，接口测试，性能测试工具，自动化测试工具。

最起码的要求是熟悉工具的使用、原理？Jmeter和lunderunner区别？
举例：

——你们的测试用例怎么进行管理的？（svn）

——你们公司用的什么缺陷管理工具？（禅道？）
关于自动化测试工具，性能测试工具，接口测试工具……

——你会编写脚本吗？

——性能测试工作的流程？

——关联有哪些方式？有什么区别？

——对于要获取的验证码是随机的，性能测试脚本怎么处理？

——你测试过程中又碰到什么性能问题吗？ 怎么解决？

——你接口测试是怎么做的？