试过重启大法不？

1. 麻烦进行一下排版。现在都挤在一起了。
2. 说明一下上下文，补充你的环境信息等和这个问题相关的信息。如果还是不理解，建议看下 https://testerhome.com/topics/587 。

#7 楼 @lose 不是很明白你的意思。你说的网页浏览器具体是指什么？

#3 楼 @seveniruby appium 控制 webview 走的是 chromedriver ，这个时候 appium 只是个中继转发。

微信兼容了 inspector ，但有没有兼容 chromedriver 还是个未知数。

其实你的路线还是很不错的呀。像老徐说的，只要能解决问题，自动化就是成功的。

你提到的点确实都是优化点，但其实也是要看具体的项目情况决定的。一般前期需要先出效果，这些点都不一定会顾上，然后后期逐步优化，这些点再一点一点补充上去。等到后续有足够经验和代码沉淀后，前期就可以在开发效率能满足需要的前提下加上这些点。

有些时候也不要顾虑太多。太想面面俱到会导致过度设计，在合适的时候做合适的事情就好。

#1 楼 @Lihuazhang 官方有两种方式，一种是 weinre，iOS 和 Android 通用，但要授权。另一种就是文中的，只能用于 Android，应该是 x5 内核兼容了 chrome inspector。

#2 楼 @anonymous 等到我写年终总结的时候再一起说吧。我现在其实也是在做新的探索，还没探索出个所以然。

#5 楼 @branty 不客气。另外，我不是大神。。。

用 which appium 确认下你命令行用的 appium 是不是 dmg 里面的？

写得不错，但有几个点遗漏了：

get 的：

1. 没有对保留字做 url 转码，例如当参数的 key 或者 value 中含有 & 或者 = 符号，拼出来的 url 会出问题。
2. 不大清楚 HttpGet 会不会自动做 url 编码（例如中文或者其它字符进行 url 转码），如果不会，应该在组合 url 的时候做好转码。

post 的：

1. post 参数类型固定是 json 有点不对吧，遇到非 json 的就不行了。建议方法名说明下只能用于 json ，例如 HttpClientPostMethodWithJson。
2. 当服务端返回的状态不是 200 时，方法返回了 null 且没有任何相关日志，定位问题会比较麻烦。

最后，强烈建议使用类似 okhttpclient 之类的更高层次的封装框架代替直接用 httpclient ，省很多代码，可读性也会强不少。

最终不是成功启动了吗？那是个 warning 吧？

写得挺多，尤其是测试后的反思，可能也是不少人会遗漏的。

不过，文中有些观点不大认同：

如果只是对于只上线一次的项目，或是上线后项目基本不会改动，又或时间不允许的情况下，个人觉得就没必要写用例了。

个人不是很赞同。测试用例是审视自己测试活动的一个很重要的依据，对于避免遗漏作用很大。如果时间有限可以简化，但不写有点说不过去。

PS：这种贴没太大必要匿名吧。。。

.app 是个文件夹来的。你用 shell 的 file 命令检查下就知道了。
Finder 遇到这种文件夹默认会显示为文件，右键－显示包内容就能看到里面的文件了

#2 楼 @seveniruby 要定一个标准，到底咱们的 md 跟着哪个规范走。。。

gitlab 也是回车不等价于 md 的换行的。

#72 楼 @jira 没，我们的应用接入了 crash 收集平台，直接看设备的 crash 日志也可以满足需要。

#11 楼 @kelequy 我们之前强推过一次，用于做无界面的服务端接口测试。feature 由业务测试写，代码由测试开发写。当时遇到的几个主要问题是 story 的风格不统一（不同人写的风格不一样，会增大后续测试开发编写代码的沟通成本和维护成本）、粘合代码编写成本较高（如果不用确保和 feature 对应，写起来能更快更爽）、维护比较麻烦（一旦有更改，feature 和代码都要调整，偶尔也会出现 feature 不用改，但代码要调整的情况）。

总的来说，当时活文档这个特性的带来的好处没太大感觉（测试报告中更直观地看出具体是哪个步骤出错？），但由于这个特性带来的编写速度慢、维护困难的问题倒是深有体会。

#69 楼 @jira 嗯，应该是这个。

#17 楼 @lihaiye 你找下获取当前 context 的函数。。。这个顺序是固定 NATIVE_APP 排在第一位的，和你当前在什么 context 没啥关系。

#66 楼 @jira 它源码是 ruby 写得，不过那句命令是外部调用的，有开发经验应该能很快找到。命令名称我之前发过给你了。

#14 楼 @lihaiye
你要确认下你执行 swipe 前处于什么 context 。chromium 是浏览器，走的也是 selenium。swipe 这些只有处于 native app 这个 context 才能用

#64 楼 @jira 你查下 crashmonkey4ios 源码？就是一个命令，具体是啥命令我也忘了

建议先去看下 appium 官方 sample 里面切换 context 相关的代码。你现在的用法是 selenium 的用法，和 appium 的有一些出入。

#11 楼 @lihaiye 你代码里哪里切换了 native context ？我只看到你获取了 contextNames ，但没做切换啊。

#6 楼 @junewang 目前能想到的你这边基本都汇总了。iOS 的 stf 现在也搞出了个类似 minicap 的工具，你可以了解下：

https://testerhome.com/topics/6470

另外，既然是比较汇总，能否做一下各个方式的性能评测，比较各种方式的截图速度、兼容性？这样能更方便以后大家根据需要选择更合适的方案。

方法不错，增强了 feature 文件的描述性。

但加了图片感觉维护工作量更大了，而且也还是没办法很好地说清楚大部分需求（例如针对 UI 的，点击 xx 按钮后不同状态应该有怎样不同的界面效果）。感觉目前 bdd 比较适合描述逻辑类的需求，这类需求比较适合通过纯文字描述。

目前接触的产品都比较喜欢用原型工具展示需求，界面与逻辑结合，表达的内容也是大家都相对能看得懂。BDD 的描述能力相比之下局限性还是比较大。

你们现在有在落地 BDD 吗？效果如何？