1.接口测试策略：
接口有多种类型，针对不同类型的接口的测试策略是有差别的
接口类型：
按业务类型分：客户端接口、服务端接口
按形式分：HTTP接口、RPC接口、Web Service接口（SOAP协议）
按访问形式分：使用用户令牌，通过web api接口进行数据访问；使用安全签名进行数据提交；提供公开的接口调用，不需要传入数据令牌或对参数进行加密签名
2.接口功能测试：
功能测试：对产品的各个功能进行验证，根据功能测试用例，逐项测试，检查产品是否到达用户需求的功能
接口测试：是指针对模块或系统间接口进行的测试，测试的重点是检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系
3.常用工具：
postman、jmeter
4.用例设计
接口测试用例设计的重点，在于功能性的业务逻辑检查和参数检查
接口测试的用例设计，主要从输入和接口处理两方面考虑：
(1)针对输入，可参考参数类型进行设计
(2)针对接口处理，可按照逻辑进行用例设计
(3)针对输出，可根据结果进行分析设计
主要采用等价类划分、边界值分析法
接口功能测试：
1.业务测试
2.边界分析测试：覆盖所有必选参数、组合可选参数、参数有无或为null、参数的顺序个数类型、参数类型数值大小、输入的数值范围、参数值长短,null,max,max+1、参数包含特殊字符
3.参数组合测试
接口异常测试：
接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不 一定是输入的数据造成的，而有可能是逻辑造成的，程序需要对任何异常都进行处理。
比如：某个接口需要先登录获取session,如果直接调用该接口应该给出响应提示
异常情况测试：
1.幂等测试
2.并发测试
3.事务测试
4.分布式测试
5.环境异常测试
6.大数据量时测试
兼容性测试：
兼容性测试简称：CTS,指对所设计程序与硬件、软件之间的兼容性的测试。分为浏览器兼容性测试和分辨率兼容测试两类
接口兼容性测试：简单来说就是参数组合测试
在边界分析的基础上，考虑输入条件的各种组合、输入条件之间的相互制约关系。也需要考虑依赖数据库字段的兼容性组合测试
组要使用因果图法进行用例设计
接口文档测试：
接口文档测试换种说法是接口文档规范
通过文档获取接口的说明、请求参数、响应参数以及一些依赖关系
一般包括接口名、接口描述、接口地址、请求方式、请求参数和格式、应参数和格式等。
接口安全测试：
“开源Web应用安全项目”（OWASP）在2019年发布了API十大安全风险《OWASP API 安全 Top10》：失效的对象级别授权、失效的用户身份验证、过度的数据暴露、资源缺乏和速率限制、失效的功能级授权、批量分配、安全配置错误、注 入、资产管理不当、日志和 监视不足位列其中。我们以此为依据对API十大安全风险进行介绍
失效的对象级别授权：
失效的对象级别授权是指：用户与服务器使用API进行通信时，服务器端未进行对象级别的权限控制或限制不严格。攻击者可以通过修改请求数据中的对象ID等信息，实现未授权获取或修改敏感信息
案例：在使用某个功能时通过用户提交的对象ID(如订单号、记录号)来访问或操作对应的数据，且未进行严格的权限限制
失效的用户身份验证：
失效的用户身份验证是指：API在访问时未对请求方进行身份验证或身份验证存在问题导致易被破解，那么攻击者可以实现未授权对API进行操作
案例：
1.未校验令牌的有效性
2.更新密码接口未限制请求频率，旧密码参数可暴力破解
3.短信验证吗或者邮箱验证码有效期超出10分钟或者长度小于6位
过度的数据暴露：
发生过度数据暴露的主要原因之一是，开发人员和编码人员对他们的应用程序将使用的数据种类没有足够的洞察力。正因为如此，开发人员倾向于利用通用流程，在这种流程中，所有的对象属性都暴露给最终用户
利用过度暴露的数据十分容易，通常通过嗅探流量分析API的响应获取不应该返回给用户的多余敏感信息
防御：
1.不要依赖客户端来过滤敏感数据：
2.检查API的响应，确认其中仅包含合法数据
3.停止用通过API向用户发送一切的过程也很重要。例如，必须避免将所有信息直接执行to_json()和to_string(),然后发送给客户端。应该专门挑选需要返回给授权用户的属性，并专门发送这些信息
4.对于敏感数据应使用加密技术进行保护。这样，即使该数据的位置作为过度数据暴露漏洞的一部分被泄露出去，也有一个良好的第二道防线，即使数据落入恶意用户或威胁行为者手中，也能保护数据
接口性能测试：
a.用户视角的性能：网站响应速度快与慢
b.开发人员视角的性能：包括系统吞吐量，并发处理能力，系统稳定性，响应延迟。如果发现不满足要求的地方，需要定位出问题所在，并给出解决方案
c.运维：主要关注基础设施性能和资源利用率，如网络运营商带宽能力，服务器应急配置，数据中心网络架构，服务器和网络带宽的资源利用率等
为什么要做接口压力测试：
1.清楚自己所提供的接口性能是多少
2.判断出系统可能存在的问题（代码，DB, cache,系统配置，容量等）提前解决
3.为设置接口的限制、熔断做参考
接口压力测试的局限性
1.接口压力测试只注重单业务的接口性能，进行压测的时候，只关注个别接口的性能
2.接口大部分时间是在线下进行，可能线上线下机器配置不一样，而且线上同时在进行着各种不同的业务
3.因此在线下进行接口压力测试的结果，只能作为线上配置的一个参考值
谁来做接口压力测试：
对接口比较熟悉的开发人员来做，这样有以下爱好出：
1.对接口实现比较了解，对接口中潜在的问题有一定的预判
2.比较容易对接口进行优化（业务逻辑层面和技术层面）
如何做接口压力测试：
Jmeter、loadRunner、Metersphere等进行压力测试
如何设计接口压力测试：
1.如何确定并发数：可以通过尝试的方式。第一次压测的时候，可以设置自己预期接口需要达到的并发数，进行压力测试。然后通过二分法进行调整
举例：如果期望的并发数是100，第一次压测并发数设置为100，如果系统没有压力，第二次并发就尝试设置为200.如果系统有压力测试，下次就设置为150.通过逐渐尝试的方式，找出当前接口的并发阈值
2.如何确定总请求数：有时候单纯的通过并发数并不能完全发现系统的压力状况，因为并发数只能测出系统的处理能力。但是有时随着长时间的调用，系统可能会出现其他问题。比如：随着数据量的增多，存储磁盘满了、内存缓存用光，缓存服务使用磁盘缓存 而拖慢系统等情况为了避免这种情况，可以尝试用现有的线上业务每天产生的数量乘以一定的天数（天数的大小视业务的具体情况而定，推荐180天以上），作为接口压力测试的总请求次数
3.接口压力测试数据的选取
通常随机选取数据，但是要注意重复进行压力测试对性能的影响
比如：第一次压测的Id是从2500W到2600W之间选择的，下次用同样的Id范围做压测的时候，如果接口实现中有缓存，则会很大程度影响压力测试的结果，对压力测试的解读时候，要考虑到这个因素
另外，使用不存在的ID去进行压测，结果并没有太大意义
压力测试报告应该包含哪些结果：
1.接口压力测试结果
并发数、总请求数、响应时间（平均）、等
2.服务器压力
每次接口压力测试时，接口所在服务的服务器cpu/jvm使用率历史记录，jvm堆大小，响应时长图（借助pinpoint查看），cpu load值（top命令），gc信息等
如何解读压力测试结果
1.对于接口压力测试的结果：
关注响应的时间是否符合要求，响应时间（前99%）是不是在可允许的范围内，最大值是多少，是否可以容忍。通常来说，错误百分比应该是0
2.对于服务器压力：看cpu使用率是否在可接受范围内，jvm堆大小是否变化频繁，是否有fullGC. Young GC耗时， CPUload值是否在可接受范围内，响应时长图是否平滑（如果有毛刺现象，需要找出原因）
如何根据测试结果定位性能问题：
1.响应时间不符合要求：通过pinpoint观察调用链，找出耗时比较长的步骤，进行优化
2.并发数达不到要求，可以从以下几个方面进行考虑：
a、是否发生系统依赖资源争用（比如：数据库连接，业务处理线程数等）
b、业务流程/代码性能是否可以优化
c、在运行的过程中是否频繁GC
3.CPU使用率过高：
a 在运行的过程中是否频繁GC
b 是否发生过多的线程切换
c 程序中是否有比较耗cpu的代码
修复性能问题：
除了只可能在极端压力测试情况下会发生的性能问题，并且修复代价过大的问题可以不进行修复（但是在压力测试报告中体现出来此问题，以及解决发难）其他问题都必须修复
其他：
如果没有专门的接口压力测试环境，记得做完接口压力测试之后，将测试数据清除（缓存，数据库，消息中间件中未消费完毕的信息等）
前端交互测试：前端页面与后端代码之间的交互测试，可以理解为接口功能测试的一个子集
测试准备：在进行交互测试前，首先要对前端功能有个明确的认知，能够明确区分：
什么功能属于前端页面逻辑功能
什么功能又属于前端与后端交互功能
前端功能与后端是通过什么接口方式进行交互
前、后端，双方有什么约束
准备事宜：
1.前端功能：前端页面逻辑、前端交互逻辑
2.接口方式
3.约束：前端、后端
在这里提到了约束这个概念，在实际项目研发过程中，功能测试阶段所产生的bug，有很大一方面是由于前后端沟通不彻底，需求确认模糊导致，如果在进入研发前，双方将各自需求、约束确认清楚，那么能够极大的减少后续由于bug导致的返工工作量
测试方法：
