一、接口测试 1、接口测试用例的编写要点有哪些？（问法二：接口测试用例设计需要考虑哪些方面？问法三：接口测试中有哪些要注意的测试点？） 1） 考虑输入参数和输出参数的合法性，参数必填，默认值，参数长度和格式校验，边界等，图片长传考 虑图片大小和格式。查询考虑数据排序，分页考虑分页显示等。 2） 业务逻辑和功能实现 3） 数据库校验 4） 性能测试（接口tps、响应时间等） 5） 兼容性，新老版本数据的兼容 6） 安全性，敏感信息加密，恶意攻击的防范，权限控制等 7） 幂等性（接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为 多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但 是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果 成功，用户查询余额返发现多扣钱了，流水记录也变成了两条，这就没有保证接口的幂等性） 2、你是怎么测试接口的？（问法二：说一下你们接口测试流程？） 1、获取接口文档，熟悉单接口以及链路接口业务，包括接口地址，请求方式，鉴权方式，入参，出 参，错误码等。 2、编写接口测试用例并评审。 接口功能用例设计： 1） 正例：单接口返回成功场景！链路接口（业务流接口）逻辑实现！ 2） 反例： 鉴权反例：鉴权码为空，错误的鉴权码，鉴权码已过期...... 参数反例：参数为空，参数类型异常，参数长度异常， 错误码反例：(根据业务而定) 其他反例场景： 如接口黑名单，接口调用次数限制等，分页场景：（0，第一页1，中间页5，最后一页10，100，其他 业务异常） 3） 兼容性用例：比如一个接口需要兼容多个版本的前端调用。 3、使用接口测试工具Postman/Jmeter执行接口测试 通常执行过程中需要考虑以下几个方面： 1） 是否满足前提条件：有些接口需要满足前提，才可成功获取数据。常见的，需要登录Token 2） 参数之间是否存在关联：有些参数彼此之间存在相互制约的关系 3） 参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到 你的请求，就能获取到你的信息 了，加密规则是否容易破解。 4） 参数是否是动态参数。 5） 接口是否需要签名验证等。 4、实现持续集成并输出接口测试报告发送电子邮件，企微（钉钉群）等，有bug报bug。 5、每天晚上12点都会运行一次，从而监控是否有因开发代码变更或者新功能添加而导致的遗漏接口 bug。 3、get和post的区别 区别在于： 1） GET一般用于查询数据；而POST一般用于添加、删除或修改数据。 2） 传参方式不同：get通过地址栏传输，post通过表单报文传输，所以post请求比get请求的安全性相对 较好。get请求可以直接通过浏览器访问，支持刷新和后退。post请求不能直接使用浏览器访问，刷新后 数据要重新发送。 3） 传参长度不同：get参数有长度限制（受限于url长度），而post无限制 4） GET产生一个TCP数据包（对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200返回数据），POST产生两个TCP数据包（对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok返回数据）、 4、http和https的区别 1） http是超文本传输协议，信息是明文传输，Https协议是由HTTP协议+SSL协议构建的加密传输协 议，比http协议安全； 2） http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443； 3） HTTP 无需证书，而 HTTPS 需要认证证书 5、cookie，session，token有什么相同点和不同点。 相同点：三者都是用于鉴权并且都是由服务器产生的。不同点：
cookie保存在客户端的浏览器上，cookie不安全，其他人可以通过分析存放在本地的cookie并进行cookie欺骗。
session比cookie安全，它会在一定时间内保存在服务器的内存，但当访问增多时，比较占用服务器的 性能。单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，而session则存储与服务端，浏览器对其没有限制。
token就是令牌，是一个字符串，主要是用于做客户端身份认证，通常登录成功后，服务端会返回token，客户端需要把token值保存下来，后续请求其他接口时，需要在请求中携带这个token值，只有 服务端对token校验通过后，才允许访问。 6、你平常做接口测试的过程中发现过哪些bug?多吗？（问法二：接口测试有没有测试出什么问题？） 接口测试中发现的bug，大多都是接口没按约定返回结果，参数为空，参数长度或类型校验、参数边界 值、代码逻辑、数据错误、或没有返回合理的错误提示等方面的问题。 (1) 一般在前后端联调阶段执行接口测试发现的 bug 会很多（之前开发写代码的时候，所有的ajax 数据都不是后端返回的真实数据，而是我们自己通过接口mock模拟的假数据，当前端的代码编写完毕， 后端的接口也已经写好之后，我们就需要把mock数据去掉，尝试使用后端提供的数据，进行前后端联 调，这个过程我们就把它称之为前后端的接口联调。） 前后端联调接口Bug案例： 比如1：查询列表页接口，前端想分页，Mock就写了三条测试数据，调用后端接口时分页有问题？ 比如2：前端访问的mock数据时没有考虑鉴权。访问真实的后端接口时没有权限。 (2) 然后在接口冒烟测试、回归测试阶段执行接口测试的时候，bug就不多。 常规接口Bug案例： 比如1：新增促销活动接口，满减金额为空也能保存成功，原因是后端代码没有对满减金额参数做空值判 断。 比如2：活动列表接口，查询出来的活动数据少了第一条，原因是SQL中limit条件传入起始序号是1而不 是0 比如3：更新活动接口，接口提示更新成功，但是数据库中的update_time字段没有更新成最新时间，原 因是开发忘记更新这个字段 比如4：比如说下订单接口，商品的价格参数是300元，那我在提交订单时候，我把这个商品的价格改成 3元，后端并没有做验证，更狠点，我把钱改成-3，我的余额还增加了？ 接口鉴权Bug案例： 比如1：比如说修改商品信息接口，只有卖家权限才能修改，我传一个普通用户也可以修改成功，我传一 个其他卖家用户也能修改成功。 比如2：之前有个退保接口，下游系统加了身份证证件有效期校验，导致被测系统接口调用跑不通，通过 自动化发现的问题，并及时去评估到对被测系统的影响。 7、你在接口测试中是怎么校验接口返回结果是否正确？ 1） 验证接口响应状态码是否是200。 2） 当接口响应正文比较短，比较固定时验证响应的完整内容是否等于预期。 3） 当响应内容较长较多时，验证响应报文是否包含关键信息。 4） 当响应正文为XML格式或JSON格式时，可以通过XPATH或JSONPATH，正则表达式，获取其中的某个节点，验证响应报文关键字段是否存在。 5） 查询数据库或调用其余接口查询。当要验证的信息在当前测试接口的响应内容中不存在时，可以调用 其他接口来验证。例如，一个增加用户信息的接口，要验证信息确实增加成功了，可以再调用查询用户 信息接口来确认用户信息添加成功。当然，在获取数据库查询权限的情况下，也可以直接查询数据库来 验证。 8、为什么要做接口测试 A、 在目前前后端分离开发的模式下，项目在开发过程中，客户端和服务端开发的进度不一致，比如服务端先开发完了，这个时候可以先对服务端进行接口测试，确保服务端逻辑和返回数据是正确的，然后 再测试客户端。 B、在测试某些业务时，不能仅仅通过前端来测试，比如用户注册，前端限制了用户名不能为空，但是 可以通过工具绕过前端直接调用服务端接口，如果服务端没有做相关的逻辑判断，就会造成数据错误。 包括接口数据传输过程中是否对关键信息加密等。所以必须针对服务端接口做测试。 C、接口测试属于集成测试、测试介入越早、就越能在项目早期发现问题，其修复问题的 成本越低，在开发提测后，可以先通过工具把服务端的接口测试跑一遍，确保接口测试用例都是通过 的，快速判断服务端接口是否符合预期。然后再通过UI界面进行测试。否则接口有bug，前端页面必定 有bug。并且接口测试非常快速、接口测试用例执行的时间是毫秒级的。 9、说一下你知道的HTTP状态码，以及它们代表什么意思 1xx 信息提示（表示临时的响应） 200 正常（表明服务器成功地接受了客户端请求） 307 重定向（服务器要求客户端重新请求一个新的URL） 401 未授权，需要身份认证 403 服务端禁止访问 404 请求的资源未找到（比如url写错了，页面被删除等） 405 请求方法不允许（比如服务端的POST类型，客户端使用GET方式请求） 5xx 服务端内部错误（服务器由于遇到错误而不能完成该请求）
10、一个接口请求不通该如何排查？ 可能的原因是：
检查请求四要素：请求方式，请求路径，请求头，请求参数是否写错。
客户端和服务端网络不通
服务端项目没有部署起来，接口无法访问。
请求被服务器的拦截了
服务端程序内部发生了错误
没有访问权限（比如缺乏token、cookie之类）
客户端设置了网络代理（比如打开了Fiddler/Charles等抓包工具） 8.如果是浏览器访问，是不是绑定了错误的hosts 11、接口测试中的加密或签名的接口如何处理？ 加密接口： 1） 首先要先了解接口使用的加密方式（如：base64、md5、sha系列加密、rsa加密等） 2） 检查接口测试工具是否支持这种加密方式，如果支持的话，直接使用对应功能就行了（比如Jmeter 支持md5）；如果加密方式是公司内部特有的算法，可以在接口测试工具中调用公司的加密算法代码 （如jar包）来实现加密。 签名接口： 了解签名规则之后，在接口请求之前先对参数按照签名规则加密之后再发送请求。签名sign一般通过请 求头传值。 12、你们项目中有哪些接口，举几个例子 结合项目去说：一般不低于3-5个接口案例（不能包括登录和注册接口），记住一条原则就是：凡是有数 据交互的地方就一定有接口。比如：增，删，改，查的功能接口。码尚教育官方技术*********** 13、没有接口文档，如果做接口测试？ 方式一：可以使用Fiddler、Charles等抓包工具抓取接口数据之后整理成接口文档，接口中不清楚的字 段，找时间集中找开发解答。然后再进行接口测试； 方式二：可以通过Jmeter的代理录制功能，先把接口请求录制下来，然后再逐一进行接口测试。 14、依赖于第三方数据的接口如何进行测试？ 可以通过Postman搭建mock服务，但是Postman的mock服务有访问次数限制，每天只能访问1000 次，也可以通过Flask，Servlet等技术搭建接口Mock服务器。 15、依赖于登录状态的接口如何测试？ 答：依赖登录状态的接口的本质上是在每次发送请求时需要带上session或者cookie才能发送成功， postman会自动关联cookie，jmeter通过添加http cookie管理器来处理cookie关联。 16、常见的请求头以及它们的作用是什么？ Accept: （客户端可以接收的数据格式） X-Requested-With:（ajax请求，异步请求） User-Agent: （客户端的用户） Content-Type: application/x-www-form-urlencoded; charset=UTF-8（内容的格式） Cookie: csrf_token=2c76c391ab3922fe; （cookie信息） 17、工作中常用的jmeter自带函数有哪些 1） random()：随机数函数 2） randomString()：随机字符串函数3） time()：获取当前时间戳函数 4） md5()：加密函数 5） setpropty()：跨线程组设置属性值函数 18、使用jmeter如何做接口之间的数据关联 接口数据关联指的是上一个接口的某个返回值，作为下一个接口的请求参数。 如果上一个接口返回的是json格式的，可以用json提取器把数据保存到一个变量里，如果是其他格式 的，可以使用正则提取器保存数据。 那么在下一个接口中，直接使用${变量名}就能使用这个数据。 19、Jmeter中常用的断言方式 1、Json断言，可以通过Json路径表达式判断接口返回的Json字符串中某些字段是否符合预期 2、响应断言，可以判断响应头/响应体中是否包含预期的字符串。区别在于：Json断言只能判断Json格式；响应断言只要是文本格式都可以判断，应用范围更广 3、beanshell断言，可以判断当一个接口经过CSV数据驱动之后，对返回的正常结果和异常结果同时进 行判断。 20、postman 你在工作中使用流程是什么样的？ 1） 获取接口文档，熟悉单接口以及链路接口业务，包括接口地址，请求方式，鉴权方式，入参，出 参，错误码等。 2） 编写好用例 3） 在 postman 先建好 url 环境变量 4） 根据接口用例所属的模块新建集合管理 5） 在集合中不同模块下录入测试用例 6） 录入测试用例的时候根据预期结果在 tests 页签中增加断言 7） 导出通过 Newman+Jenkins 去运行 21、Postman中常见的POST提交数据方式有哪些？ 主要有以下四种方式： application/x-www-form-urlencoded表单方式提交数据。multipart/form-data 报文包含有文件上传application/json（text/plain，text/xml） 报文类型为json字符串类型。binary 报文类型为二进制文件上传。 22、接口测试中关联是什么含义？如何用 postman 设置关联？ 关联就是把上一个接口返回值的部分截取出来，作为下一个接口的参数，能让接口串联运行在 postman 中设置关联的步骤如下： 1） 先通过正则表达式提取的方式或 json 取值的方式把下一个接口需要的信息从上一个接 口截取出来 2） 使用设置全局变量的代码把取出来的值保存到全局变量 3） 在下一个接口中，使用{{全局变量}}代替要替换的静态值 23、工作中用fiddler抓包工具来做什么 1）当测试出bug时，可以通过fiddler抓包，分析bug是客户端还是服务端的问题2）当做接口测试时，通过抓包获取接口的入参和返回值，包括接口之间的数据关联 3） 当对客户端做弱网测试，可以修改fiddler的网络模拟参数，模拟出不同的网络速度 4） 当需要对客户端测试一下特殊场景（线上调试），可以使用fiddler设置响应断点，修改服务端响应的 数据，测试客户端对应的逻辑处理。码尚教育官方技术*************
24、如何分析一个bug是前端还是后端的？ 平常提bug的时候，当不清楚是前端开发还是后端开发的bug时。我们可以通过抓包分析。 抓包之后，先分析请求报文是否有问题。参考物可以是前端页面元素也可以是接口文档，如果有问题就 是前端开发的数据不对。 如果请求报文没有问题，那么重点分析返回的报文，如果返回的报文数据以及报文的条数不符合预期的 话，那么可以确定是后端开发问题，如果返回的报文和条数没有问题，然后查看返回的报文和前端显示 的内容是否一致。如果不一致则是前端开发的问题。
二、web自动化测试 1、你们WEB自动化测试框架是如何搭建的？ 我们web自动化测试使用的技术栈是： Python+Selenium+Pytest+Parametrices+Excel+Allure+Jenkins 框架使用的是基于Excel的关键字驱动，将维护框架和使用框架分离开来 进行自动化测试时，将元素定位表达式及要执行在操作写入excel即可，显著降低了自动化测试的落地难 度 主要功能：
内置常用关键字，实现关键字驱动测试，有升级为BDD潜力
自动的判断浏览器类型版本，并自动下载、启动合适的浏览器驱动
内置自动等待，避免正常情况下UI测试的出错情况
通过执行js的方式，实现特殊场景交互，如强制点击、强制输入、拖拽上传等
以字符串为核心断言策略，支持等于、包含、正则匹配、内容组合等多种断言方式
自动生成allure的测试报告，报告内置与excel内容一一对于匹配
支持并行测试和分布式测试 文件架构： conf # 项目配置 data # 数据驱动测试文件 action.py # 关键字驱动封装case.py # 用例管理和封装data.py # 数据驱动封装pages # PO 封装 report # allure测试报告 tests # 存放 excel文件作为测试用例 框架用法： 1）创建execl文件，每个sheet页看作一个TestSuite 2）在sheet页中申明测试用例，填写测试用例的名称 3）在单元格中填写步骤名、关键字、关键字参数，完成测试步骤 2、你觉得WEB自动化测试的价值在哪里？你们公司为什么要做WEB自动化测试？ Web自动化测试就是模拟手工测试人员来做功能测试。用机器的自动执行代替人的操作。主要用于产品 的核心功能冒烟测试、回归测试。从系统最核心的功能开始做，再根据情况慢慢展开。 引用自动化测试之后，能代替大量繁琐的回归测试工作，把业务测试人员解放出来，既而让业务测试人 员把精力集中在复杂的业务功能模块上，自动化测试一般是对稳定下来的功能进行自动化，保证不会因 为产品的更新导致之前稳定下来的功能出现BUG。 3、公司如何把WEB自动化测试在项目中开展起来？ 1） 项目组做自动化的可行性分析，包括自动化率能够实施到什么程度？主要考虑：
项目时间是否比较长，一般需要一年以上的项目或者长期的产品
需求会不会频繁变更
自动化脚本是否能够持续反复的使用。 2） 项目组调研自动化工具的选择和demo演示，主要演示selenium和robotframework两种。如果有以往成熟的框架演示更好。 3） 逐渐在项目中实施自动化，发现问题并改善。主要包括：
编写自动化测试计划
提取或编写自动化测试用例
由leader编写自动化测试框架脚本
编写，调试并维护自动化测试脚本（代码规范以及根据分工编写响应的自动化测试脚本，自测没有 问题之后提交到Git服务器）
Jenkins持续集成无人值守测试
后期维护脚本（主要是因为版本更新添加用例） 4） 把自动化流程化，规范化，文档化，自动化框架出使用文档以及规范文档。 5） 生成定制的报告。继续完善框架。并推广到其他的项目 4、web自动化有多少case？覆盖率是多少？全部执行完需要多久？ 1） WEB自动化用例个数根据功能测试用例数而定。自动化用例覆盖率一般为功能测试用例的30%左右 2） 所有WEB自动化用例执行完成大概30-60分钟左右。 5、web自动化测试用例如何设计？ WEB自动化测试用例是从手工测试用例中提取出来的，主要是冒烟用例和回归测试的用例。自动化测试 用例的选取更加需要注重用例的严谨性，选择用例的时候遵循以下原则：
优先选取覆盖产品核心业务流程的用例；
选取的用例是需要重复执行或繁琐的验证功能，比如字段验证、提示信息验证；
优先选择正向的测试用例，反向用例一般情况复杂、数量多；
不要选择流程太复杂的用例（主流程除外）； 6、如何保证(提升)自动化测试的稳定性？ 自动化测试稳定性主要表现在两个方面：一个是元素定位的稳定性，另一个是用例之间依赖稳定性： 元素定位稳定性问题： (1) 尽量用相对路径的xpath表达式； (2) 定位元素使用智能等待+显示等待的方式避免元素未加载完成问题； (3) 脚本执行失败后加入重试机制，提升用例的稳定性； (4) 用例执行结束后对测试场景进行还原，避免影响其他用例的执行； (5) 尽量保证单独的测试环境，避免其他的测试同步进行； 用例之间依赖稳定性问题： (1) 用例与用例之间尽量避免依赖，用例尽量可以独立执行；让每条用例都从一个共同的页面开始执行，比如首页，这就需要在测试框架中采用后置处理的方式使每条用例执行完成后都回到首页。 7、自动化测试发现BUG多吗？ 不多，因为WEB自动化的用例就是之前项目组已经测试过的基本功能，然后再进行自动化脚本的编写和 执行，它主要是保证已经测试通过的功能在新版本更新后不会因为新增的功能而导致原来的基本功能产 生错误。 8、什么是PO模式？为什么要使用它？ PO模式，全称为Page Object Model ，简称PO，是页面对象模式。意思是把一个页面当做一个对象， 页面的元素就是对象的属性，页面的操作就是对象的行为（方法），PO模式一般使用三层架构，分别 为：基础封装层BasePage，PO页面对象层，TestCase测试用例层。 使用PO模式可以使我们的测试用例更简单，更清晰，很多时候我们可以在页面对象中封装很多业务操作 方法，测试脚本只需要调用相关方法就可以。 另一个就是如果有页面元素发生改变，我们只需要去修改这个页面对象的元素定位和相关方法就可以 了，不需要修改其它脚本。增加代码的可维护性。 9、说说你对数据驱动和关键字驱动的理解？ 数据驱动是从某个数据文件(例如Excel文件、Csv文件、YAML文件等)中读取输入、输出的测试数据，然后通过数据驱动方法（ddt，parameterize等）传入自动化测试脚本中。在整个过程中，自动化测试脚 本实现数据的读取、测试状态的改变、结果的判断等，从而实现数据和代码分离，这种方式叫数据驱 动。 关键字驱动是从面向对象的思路出发，同样的业务逻辑会编写成一个函数作为关键字来被不同的测试脚 本所调用。当所有的业务逻辑测试都可以被写好的函数所组合完成时，就是关键字驱动框架。这个时候 测试用例的开发就变成了测试数据和关键字的组合，并把这种组合工作简化为所有人都很熟悉的表格填 写任务，从而最终达到一个由数据和关键字驱动整个测试的效果。 10、举例说明一下你在自动化测试过程中主要用到了哪些Python 库？碰到过哪些异常？ web自动化测试： webdriver，WebDriverWait，By，os,xlrd，xlwt，unittest/pytest，time，logging， HTMLTestRunner等 接口自动化测试： requests，time，logging，json，csv，jsonpath，pyyaml，re，unittest/pytest，allure 常见的异常有以下： NoSuchElementException： 没有如此元素异常NoSuchAttributeException ： 没有如此属性异常NoSuchFrameException ： 没有如此frame异常ElementNotSelectableException ：元素不能选择异常ElementNotVisibleException ：元素不可见异常Element not visible at this point ：在当前点元素不可见TimeoutException ： 超时异常、
参考资料：
接口测试+自动化测试