#15 楼 @anikikun
#16 楼 @lylyliuyu 我只是小兵，最认真的还是 @huanzhijin ，他做的事情最多。

整体看了一遍，写的不错，有些坑有写出来了，不过有一小部分的翻译有问题。

1. is_displayed Whether the element is visible to a user. 该元素是否是可见的用户 翻译错了，应该是此元素用户是否可见。简单地说就是隐藏元素和被控件挡住无法操作的元素（仅限 Selenium，appium 是否实现了类似功能不是太确定）这一项都会返回 False

70.execute_script

Synchronously Executes JavaScript in the current window/frame.
  同步执行的JavaScript在当前窗口/框架

这个正确翻译应该是：在当前窗口/框架（特指 Html 的 iframe ）同步执行 javascript 代码。你可以理解为如果这段代码是睡眠 5 秒，这五秒内主线程的 javascript 不会执行。

71.execute_async_script
execute_async_script(self, script, *args):

Asynchronously Executes JavaScript in the current window/frame.
异步执行JavaScript在当前窗口/框架。

和上一个类似，也是插入 javascript 代码，只是这个是异步的，也就是如果你的代码是睡眠 5 秒，那么你只是自己在睡，页面的其他 javascript 代码还是照常执行。

#10 楼 @lylyliuyu get attribute 这个可以参考我以前的一个帖子：https://testerhome.com/topics/2606，不过有点超出 API 文档的范畴了。

#29 楼 @4amla 首先澄清一点，我这个不是科普贴，是个人感悟贴。不敢说我的观点一定正确，只能说是我个人的个人感悟。

那我表达一下对你这几个问题的观点吧：

如果只验证返回值，是否代表着这个接口的功能完全 OK，或者接口测试不去管这个接口的具体功能实现？

首先，我这里关于接口测试的观点都基于一个前提：你有比较完备的功能测试。而且我是因为条件所限按照一个用例一个接口的规则只能检查到返回值，如果你有条件应该还要同时检查数据库内容，这样完整性好一些。

那，如果不管这个功能是否 OK（这个返回值研发也可以直接 return 一个正确值即可），那么这个功能就要在其他阶段再进行详细的测试？

我的其中一个用例就发现了这样的一个问题，A 用户无权删除 B 用户的帖子，但接口却返回操作成功（当然实际上还是没有成功删除的）。对于这样的情况，如果可以获取到数据库那就可以调用单个接口完成，因为数据是否成功修改可以直接通过数据库知道。如果不能，而是需要调用其他 API 才能知道，那更建议把这个部分放到功能测试里做，毕竟功能测试里这个基本是必测的。当然你也可以根据功能的优先级考虑专门为这个功能做个接口层面的校验，但这个更多的是补充，而非接口测试本身的目的。

如果这些便于测试的接口，由研发人员提供，我们是否需要检查接口的具体实现（貌似也要消耗一点时间），还是说就直接拿过来用就行了？

肯定不是直接拿来用。。。而且检查接口的具体实现也不现实，如果某一次研发错改了这个接口呢？我觉得有两种方式吧，一种是为这个接口也做一个用例，用于保证这个接口的返回值正确，另一种是直接通过数据库来计算得出这个数据。我这里说的艰难特指模拟用户操作来逐个翻页，导致翻页次数不确定，因此应该有更合适的办法保证一次性能翻到最后一页。

很开心我的分享能帮助到你，也欢迎你以后在接触接口测试，或者其他新的事物的时候把感悟分享出来。如果只是单纯感悟我发到自己博客给自己以后看就好，产生思维碰撞才是我把这个帖子发在 Testerhome 的目的。因为我有感觉，我目前的观点仍然不完全正确。

#4 楼 @huanzhijin 右下角铅笔图标。

angular 现在这么强大了！？

#2 楼 @huanzhijin 64. location_once_scrolled_into_view 这里 markdown 有问题

#25 楼 @blink 我说下我的理解吧。

1. 很多时候服务端压根就没人做测试（我们这服务端的东西一个人搞定，因为不需要做界面，纯做接口就好，单测这些在开发的时间都不够的情况下谁去）
2. 实际流程不会像你所说那样分三步走，而是同步走。服务端会先给个 Mock 服务器让 app 可以调节，接口测试会跟着服务器开发进度走，app 则是一直跟着 mock 的结果和设计的逻辑走，直到服务端说接口搞定了再开始联调。

这个过程中为什么要有接口测试呢？主要是为了保证开发过程中能比较高频率得跑测试，最好做到服务端一提交代码接口测试就自动跑。同时接口测试也能在后续每次服务端更新代码的时候跑一遍，保证没有出什么重大问题。自动化本身的优势之一不就是能大幅度提高测试效率嘛。

至于你说业务稳定为啥要测接口，这个我的观点和 monkey 一样，为了回归。而且接口有个好处，定位问题简单，一出问题基本都是服务端的问题，而且肯定是和这个接口相关的代码，不用花时间再去抓包->分析（->撕逼）

https 的话建议你了解下 https 和 http 区别是什么吧，相信你了解后也就知道答案了。

#2 楼 @lihuazhang 这不是 iOS ？

没搞懂你的问题。
appium 的缓存只会缓存你 find 过的对象，只要重新 find 一次就不会用缓存啊。

#22 楼 @taurus 这个不错，赞一个。不过感觉遇到有业务关联的接口时不大好做。
testly 那个和这个比较类似，不过他有一些针对数据传递的特殊处理。

#17 楼 @face_south 这个应该找开发取文档。正常来说前后端协作的时候应该有个接口文档，如果没有再去抓包。抓包有个不好的地方是有些不常用的参数可能不会出现。

#14 楼 @rocker 建议把这个做成自动化的吧。接口的东西做成自动化比 UI 方便很多。

#13 楼 @face_south 你有把用例做成自动化的吗？返回码都走一遍这个从我的角度看来还是需要的，不过也要看你具体情况。有些业务上基本不会出现的也许可以跳过。

有 Release Note 什么的吗？

#11 楼 @284772894 这个不错，谢谢分享。把它的文档过了一遍，主要是把 http 操作简化到了可以直接用 annotation ，优势应该是快速构建不同的 http 操作，但对于参数组合和后续的断言还需要再封装，这个工作量还是不少的。

#7 楼 @75281920 谢谢～看来分析回帖内容自动点赞的功能要加入 手动点赞 这个文字了，哈哈

#3 楼 @xushizhao 谢谢～你提到的内容我已更新到帖子里面了，你看下有没有不对的地方？
#5 楼 @nickli 谢谢～

你是不是 xpath 用得比较多？

我之前和一个人交流过，最终结论是：脚本什么的花再大精力去优化，还不如直接把测试机换成 6s 效果好。

#8 楼 @simonpatrick 我现在遇到最常用的场景其实就是一些 id 的传递。create 接口执行成功时会返回 id ，然后其他接口要把 id 作为参数去获取相关的信息。

Jmeter 的实现是有一个 post processor 专门做这个事情（类似于你的 Resolver ，专门处理返回值），把返回值放到一些全局变量里，然后下一个接口再去调用这个变量。因为使用的是变量，所以字段名是否相同没有太大关系。

#6 楼 @simonpatrick 这块我也在想，但还没找到能兼顾灵活度和易用度的方案。
@seveniruby 思寒这块是怎么做的？

为了做出解释，暂时先移到违规处理区。

请学会如何提问，阅读：https://testerhome.com/topics/587

#3 楼 @simonpatrick 有个问题想问下，你一开始有提到进行上下文数据的传递，但你文中没有提到具体的实现方式。想问下你这一块的实现是放在了 Java 里面还是在 excel 中？

#4 楼 @jiguanghover 麻烦更新一下标题，在上面加上【已解决】方便后面的人参考吧。

#8 楼 @lihuazhang 我错了。。。是 app 。。。最近都在做 android ，有点错乱了。。。