那就实现加密

可以自己写加解密的逻辑，或者集成开发的 SDK 都可以

加密因项目而异，你可以去问开发如何绕过加密，如在 header 里加上 ClientType=999，就能使接口通畅运行

你做接口测试的时候，遇到接口必填传参加密的时候，如何处理？？

看了各位的精彩回复，打开了我的思路，看来看是还是我学艺不精啊，继续学习

1. 可以把接口测试 理解成单元测试
2. APP 前端测试 理解成 集成测试或系统测试

这样你就明白了各自不同的意义了。

以下内容来自网络：

根据 V 模型，软件研发过程：需求分析->概要设计->详细设计->编码->单元测试->集成测试->系统测试
一、单元测试 ---- 白盒测试、自动化测试、静态测试
1、单元测试概念？
单元测试是完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。

2、单元测试的内容？
接口测试：保证进出单元模块的数据流是正确的
内部数据结构：保证临时存储的数据在算法执行过程中的完整性
全局数据结构：全局数据结构对单元模块的影响应当审查
边界：才用边界值分析技术，保证模块在边界条件和极限情况下正常执行
语句覆盖：保证每个语句执行一次
错误路径：对所有处理错误的路径进行测试

二、集成测试 ---- 白盒测试、黑盒测试、自动化测试、静态测试
1、集成测试概念？
通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。
自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。
自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。

2、集成测试的过程？
a.明确测试的目标和完成准则，并确定关键部分
b.确定阶段和进度安排
c.测试和修正协调的计划
d.清理系统结构
e.确定集成测试方法的组合策略
f.描述集成顺序
g.针对每次集成编制测试用例，从而形成测试方案
h.进行附加软件（测试桩）的开发
i.测试软件和测试准备准备
j.依据测试方案进行测试
k.根据测试结果提交测试报告
l.测试报告的分析
m.缺陷的管理
n.修正和测试工作
o.完成测试软件提交

三、系统测试 ---- 黑盒测试、自动化测试、手工测试
1、系统测试概念？
根据软件需求规范的要求进行系统测试，确认系统满足需求的要求，系统测试人员相当于用户代言人，在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作

2、系统测试主要内容？
a.所有功能需求得到满足
b.所有性能需求得到满足
c.其他需求（如安全性、容错性、兼容性等）得到满足

四、回归测试 ---- 黑盒测试、自动化测试、手工测试
1、回归测试概念？
当发现并修改缺陷后，或在软件中添加新的功能后，重新测试。用来检查被发现的缺陷是否被改正，并且所做的修改没有引发新的问题。回归测试可以通过人工重新执行测试用例，也可以使用自动化的工具来进行。

2、回归测试方式？
a.覆盖全部测试用例。选择基线测试用例库中的全部测试用例组成回归测试包，测试成本最高
b.基于风险选择测试。可以基于一定的风险标准来从基线测试用例库中选择回归测试包，首先运行最重要的、最关键的和最可疑的测试用例，测试从主要特征到次要特征
c.基于操作剖面选择测试。测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些最重要或最频繁使用的功能的测试用例
d.重新测试修改的部分。当测试者对修改的局部化有足够信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和他的接口上

五、用户验收测试 ---- 黑盒测试、自动化测试、手工测试
1、用户验收测试内容？
a.配置审查。确保已开发软件的所有文件资料均已编写齐全，并分类编目
b.Alpha 测试。是由用户在开发者的场所来进行的，在一个受控的环境中进行。
c.Beta 测试。由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件

说的好

前端的测试和后台的接口测试并不是为了解决同一件事情，不要单纯用发现 bug 的想法来看待接口测试活动，个人觉得接口测试的好处说明了其存在的价值：快速测试反馈、提高测试覆盖、质量风险把控，只做前端的测试是不可能覆盖这些面的。

楼上很多同学说的都有一定的道理，但是相信还是不能很好的解决楼主的疑惑 ---- 既然接口是我手工测试时必须要验证的一个环节，为什么我还要花额外的精力去接口测试。
我就自己的经验试着去回答这个问题。
举两个场景：
1.每个公司都有的上报功能。
这一块如果做了上报接口功能验证，在客户端测试时就只需要验证相应地方是否生效，上报次数是否符合等情况，而不需要每次都去验证接口的内容。而事实是很多公司都已经做了基于 UI 自动化的上报验证测试。
2.某信息流公司要验证 10000 条拉取中是否会包含相应的正确的广告数量。
这个场景是涉及数量上的，有时要验证的不仅 10000 条。因为广告投放的数量和具体投放哪个广告都是有要求的，每个频道每个时间点投什么，投多少都不确定，信息流公司更是要基于用户模型来判断广告的投放。如果都是手工验证，肯定是验证不过来的。

当然，实际过程中肯定有更多场景必须用到接口测试，也有很多公司的 APP，web 等产品并不适合上述情况，说这么多只是想说接口测试的适用空间还是非常多的。

首先我觉得是接口测试是有意义的，可以覆盖 App 前端可能不能覆盖的内容，几点理由：

1. 有代码的地方就有可能出错，APP 前端验证之后，接口部分的代码实际上可能并没有全部验证到， 原因为，App 前端的代码已经对接口的请求参数做了一部分验证，所以有些接口的用例可能没有办法覆盖 如果从覆盖率的角度看，就是纯粹通过 App 前端，有些代码永远的走不到 (不是只是异常处理的逻辑)
2. 接口并不只有 App 端访问，直接调用，或者其他客户端调用都有可能，甚至说可能被拦截后 直接修改参数再访问也有可能，从这点来说接口测试需要更加严格的校验，所以测试用例需要更多， 或者说需要去仿造通过 App 端无法测试的情况。 举个例子来说，如果用于用户名必须要要少于 5 个字符，这个限制只有在 App 端做了，没有在接口层做， 那么 App 端测试时候超过 5 个字符的用户名是不能注册，但是如果通过接口注册了超过 5 个字符的用户， 这个时候我想 App 端登录超过 5 个字符的用户名说不定永远不能成功了，这个其实就是接口测试的一些意义

确实 App 的前端校验和接口测试从业务的角度，用例确实有部分重合，不过从测试的意义来说，App 端的测试
有一部分的意义实际上验证和后端的交互是不是符合产品定义，这部分代码不是接口，
而是如何前端校验，如何交互，如何转换数据；举个极端点例子来说，如果登录的时候，App 同时发了两个请求，一个给了登录接口，
一个给了开发小哥自己的网站 (纯粹举例子)，从功能的角度看，整个登录流程是没有问题的，但是它是一个 bug，
而且很严重，而这些是接口测试无法覆盖的；

楼主其实问的是个好问题，其中确实有重复的部分，而且很多团队确实就是用 App 测试代替了接口测试，
在人员短缺，这个也是一个办法，合起来一起测试也不是一个完全没有道理，质疑重复测试也有道理，
把两者合起来看，看两者的差异点，相同的是什么，不同的是什么，可能就会更高效率了.

我有点啰嗦 .......

接口测试也可以用来快速定位。
如果接口测试没有错误的话，那就可以把问题定位到前段。
当然如果直接接口报错了，那就可以把问题定位到提供接口的后台。
免的前后台相互踢皮球，当然也可以通过抓包查看数据。
接口测试也可以提前发现一些接口提供数据错误的问题，免的前后台联调的时候再发现，延误测试进度。

因为这原因出过 1 次生产问题过...，接口自动化跑完是通过的，但是前端被改的影响到了看起来八竿子打不着的一个功能。快速迭代的版本里又不可能做全量的回归测试，影响范围分析又怎么能做得更好呢。

大致能理解楼主的困惑，接口测试通过，客户端测试不通过，那么我直接做客户端测试好了，干嘛还需要额外做一次接口测试？

但可以换个角度想下：

1. 时间方面，一般客户端都是最后才联调好的，这个时间咱们就干等着？
2. 覆盖度方面，客户端一般已经做了过滤，无法覆盖更完整的接口参数场景，而接口测试可以。基本上接口测试通过，服务端不会有大问题。
3. 自动化成本方面，接口测试无论是维护成本还是执行效率，都比客户端自动化好不少，很适合投入自动化，也可以做得比较全面。开发自测或冒烟测试的时候会用得很爽。

不过有一个点，接口测试建议还是用自动化的方式进行，这样成本才低。用 postman ，每次执行都要手动改参数，确实成本比较高。

我用接口测试后的感受如下：
1，可以提前介入测试，不用等开发完，只要调完一个接口就可以先测试一个接口；比前端自动化有时间优势，在追求敏捷项目的今天，测试时间周期……是吧？
2，相比前端自动化，我觉得接口的用例维护起来要简洁省力的多；当然你要保证你的用例数据是分离出来的。可以参考下社区里开源的 HttpRunner。用例与项目分离，测试数据与用例分离！
3，项目回归测试，包括老版本的兼容及新版本测试后期的快速回归（这里就不得不说了，前端自动化新项目回归测试指望不上……我就回归一下老版本）
4，你给的例子是一条容错的用例吧，只要是根据预定的输入得出预定的输出，就算是正确的。至于前台加载错了提示语！你可以去对着开发呵呵

前端是可以被跳过的

后台开发一个接口，可以给 WEB、Android、iOS 等等各种平台使用。
接口测试不仅仅是逻辑，还有安全。