地铁 40 分钟 + 走路 15 分钟

你现在的问题是 adb devices 可以显示设备，但 Provider 无法使用设备。

adb devices 可以显示设备说明你的机器和设备之间的连接是没问题的，provider 无法使用，意味着 provider 无法和手机上的 stf service 连接，所以无法使用（这个 service 用于传图像信息等）。

当 provider 开着的时候，连接手机会自动安装 stf service 这个 android 应用，你可以往这个方向检查下这个应用是不是没有被成功安装。

建议你另外开贴来问吧。把你的完整脚本、执行命令、错误信息、环境信息等都发出来。

现在是没看懂你的报错是什么。。。另外，你的代码里有个很低级的错误，就是 try 和 except 里面都有个 return 。你一 return 不就退出这个函数了么，后面的 click 还怎么执行。。。

可以看下 http://www.techrepublic.com/article/keyboard-shortcuts-in-bash-and-zsh/

试了下，在 mac 命令行 (zsh 或 bash) 下，alt + 方向左键 可以做到按空格来跳光标，即每次都是跳到一个空格符的后一个字符，ssh 连接了远程机器后这种方法也是生效的。

不过不确定 windows 下是否也同样适用。

从日志里只能看出 Coverage.info 这个文件有问题，没有有效的记录。因为不知道这个文件是怎么来的，内容是啥，也无法追查下去。

建议把你详细的部署步骤、操作步骤（包括你觉得和报错有关的所有细节）和出错日志都发出来？

不需要什么额外配置，和你做普通真机调试差不多。

检查下安装 stf service 这个 apk 的时候是不是没有允许安装？

今天看到个 BackstopJS ，css 样式回归工具，不知道能不能满足楼主需要

你牵的驴子，它跟军队打了 10 年了。666 呀~

代码块是支持 C# 的，只是下拉列表里没加上。可以这么用：

```C#
你的代码...

赞，这些基础知识的坑确实需要有深入的了解。

从你的环境配置来看，有可能是真机 iOS 版本太低。Xcode 8 系列主要对应的是 iOS 10 系列，可能对 iOS 9 支持度一般。

可以拿台 iOS 10 试试。

1. 检查你的 jenkins 机器上 git 是否正确安装
2. 试下把 workspace 移动到不带有空格的路径。"Program Files" 这个文件夹带有空格，不排除会产生一些其妙的问题。

还是没 xcode 版本。。。

那还是先解决 npm 重装 appium 的问题吧。

建议找下 android 官方的文档吧，或者 adb --help 查下。我相信这个机制不会消失的，有可能只是命令改了而已。

这个确实不好覆盖。不过如果这个 sql 不大复杂，确认有覆盖到这个 sql 对应的写入函数应该可以接受。如果 sql 很复杂，那得考虑用另外的方式去覆盖这块功能，例如单元测试。

不过我觉得没太大必要追求百分百的覆盖率，有个基础要求就好。对于手工测试这种场景，覆盖率数据的价值是根据未覆盖内容结合对代码的解析，得出未覆盖的功能或流程，然后由团队根据实际需要补充相关的测试用例，避免遗漏。

最近终于有空自己跑了一遍，有报告生成了。

报告放在了网盘：https://pan.baidu.com/s/1bOakvO

解压后打开 ExtentReports.html 即可。

@mamian @wangpengfei100 我自己尝试了一下，踩到的坑及解决方案已补充到正文中，两位可以参考下。

补充一下公众号收到的一个如何获取 ID 的方法：

APP ID 可以到 APP 文件夹看（命令进入），也可以用 powershell 命令查，也可以直接看程序属性（程序要先调出 explorer.exe 文件夹）

目前没在 sdk 实践过，以下仅为参考 android app 收集覆盖率得到的想法：

jacoco 原理上应该支持任何 java 程序的覆盖率收集和报告生成。可以考虑在 sdk 里面嵌入一个 receiver 执行覆盖率 ec 文件生成并存储的操作，然后另外做个 apk 来发送这个广播和把生成的文件上传到覆盖率后台服务进行报告生成。

好问题，从技术角度，这两者的覆盖率从收集到生成报告都是两套不同的机制的。如何结合起来一起看，这是个难题。目前还没到这一步，不好回答，不过从我的角度，最终覆盖率的服务形式不是单纯让测试人员看覆盖率报告，而是从覆盖率报告得到测试的推荐建议，例如 xx 模块未覆盖，涉及 xx 流程，优先级 px ，建议通过 xx 用例覆盖。

手动测试的覆盖率是下一步目标，目前计划是用 istanbul-middleware 来做。具体可行性后续继续研究。

或者你把报错信息发上来一下，说不定有其它小伙伴遇到过并且解决了？

增加的话我能想到的是：

• 功能方面：各个接口是否确实都转为了 https ，有没有遗漏。
• 安全方面：如果使用了自定义的 ssl 证书（如 fildder 抓包时配置的证书），是否应用会检测到并认为此证书不可信，即不会信任系统信任的证书，只信任自己公司使用的证书。证书校验我觉得应该 hard code 在应用包中。
• 代码方面：了解具体代码改动范围，是否只涉及接口的公共库层，会不会连带改了别的东西。
• 调试方面：调试包是否带有证书信任开关，正式包是否会自动把开关设为关（不信任系统信任的证书）。毕竟能抓包看数据内容这个功能，在测试阶段还是非常重要的，调试包应该设置为可以抓包。

当然，这些是建立在原来使用 http 的时候接口的数据处理已经经过充分测试的前提，针对 http 转 https 想出来的测试点。

后面抽空写下，最近比较忙