先截图，然后给截图加水印～

太水了……

结尾说的挺好

http://docs.python-requests.org/en/master/user/quickstart/#post-a-multipart-encoded-file
这个？

只用一个域名
测试环境指定 host

发个源文件链接吧~即使是大图下载下来依然看不清啊

False

sys._getframe().f_code.co_name
或者 inspect 模块

allure 不只是 step ，还有 feature 、story

我没遇到过
不过这种问题，我建议你先换个手机试试。。。

号被盗了呗

另外，通过 WiFi 通信，与 USB 直接通讯的速度和质量是没法比的，尤其是规模越大越复杂

Chrome DevTools Protocol
这个也许可以。
所以你要这么做是什么原因呢？也许你折腾一圈发现，最后自己实现了一个 adb。。。

所以这类问题我的理解是可以修改，但是不建议修改（也就是有修改权限）。也许领导只是想改个错字而已……

推荐的流程是：leader 写备注并 @ 该用例所有人，提出修改意见 ——》用例所有人收到通知 —— 〉执行修改或驳回、忽略。

leader 的修改意见不一定正确，用例优化/修改也应该有评审——code review

一般来讲，我们是信任 HTTPS 的安全性的。
你抓包看到了，是因为你信任了自己的根证书。
如果是普通用户，一般是中了中间人攻击。

下一个页面不知道是什么样子的，但是你点击之前是可以获取当前页面布局的。点击之后，判断布局发生变化即可

#4 楼正解

换个角度，开发 leader 可以修改组员的代码吗？

adb connect HOST[:PORT]

TAPD 不服

看你们接口测试是什么情况了，如果是借口文档完备、有开发支持，那可以从接口测试入手；
如果不是，还是从 UI 自动化开始吧，接口测试要会的东西太多了，甚至很多时候比开发想的还要复杂

1. 区分公共参数和当前接口特有参数——抓包，多观察几个请求就能了解个大概
2. 公共参数统一配置，比如从配置文件读取，每个接口不必去单独测试这几个参数（或者也封装起来，在合适的方式用 python 的装饰器）
3. 对接口进行封装，比如我们这叫 action，这里只做请求
4. 用测试框架，如 pyunit，然后 case 这一层考虑各种可能的参数情况传入，和返回结果的断言
5. 如果每个参数都校验，那用例是非常多的，可以考虑正交法
6. 对于单个参数的可能情况，需要结合具体的业务场景。比如，一个字符串类型的参数，如果是用户输入的，那就要测试的非常详细，考虑比如中英日韩等各种语言、数字、字符、全角/半角、emoji 等等。但是如果不是用户输入来的，那就没必要测试这么细了（除非项目对安全要求比较高/时间非常充裕）

一点经验，供参考

核心功能自动化

命令行不会自动翻

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