#1 楼 @lihuazhang 。。。你应该关注妹子啊。。。

太简洁了。。。虽然大致知道你的意思，但是没看出它的具体做法和优势。而且如东哥所说，脱敏脱得太厉害了。。。要不你弄个 demo 来截图也好啊。。。

#15 楼 @jh901011 嗯，正常来说应该是能看到的。不过看你的截图还停在显示 template 阶段。

要不你拿另一个有 webview 的应用试试，看有没有问题？

#12 楼 @jennifer 你看下活动沙龙专区的帖子，上海和北京最多啊

#12 楼 @jh901011 android 版本是？
你的截图里不是有一个 webview 了吗？

忘了回答一下你的问题了。

测试的存在真的能提高产品的质量吗

我想先问清楚，你的测试时指测试人员还是测试活动？如果是人员，那只能说取决于他的能耐，如果大家都忽略他，那肯定对质量没多大贡献。如果是活动，我相信答案是肯定的。

你的疑惑我觉得应该是你提出的各种问题开发没有正视。例如你上面的例子，一个评论在网络良好的情况下超过 3s ，这在大部分情况下是不可接受的。但怎么说服开发，或者开发的老大去修复这个问题，这就需要一些技术之外的东西了。一般可以给出数据（平均评论时间多久，其中每一个环节的耗时是多久），说出和竞品或者大部分 app 的差距（一般差距超过 100% 就算比较严重了吧），如果能拿到源码，甚至可以自己去加一些 log ，加断点，了解到底是什么代码造成这么严重的耗时，给出可供参考的解决方案。

说白了就是报 bug 时不仅说出重现步骤、预期结果，还需要说明你认为它属于什么优先级（任何事情都有优先级）、给出合理的数据证明这点。

无论最后问题是否被采纳（我相信有这么齐全的数据如果还不采纳只能说情况特殊，例如这个 app 还存在很多比这个严重 n 倍的问题），你都学习到了不少东西。更重要的是你让开发同学看到你的能力，以后沟通起来会更顺畅。

看在你叫我大哥的份上，这次帮你调整了格式（仅此一次）。你自己使用编辑界面看下调整前后有什么区别。

写分享是好的，但如果格式让人没有读下去的欲望，效果会大打折扣。

#12 楼 @actionwind 额，不算纯白盒，不过确实是要拿到代码才能做。
不明白为啥不想研究？难懂的东西不是更有研究价值嘛。

#5 楼 @actionwind 文档不止一处：http://repo.xposed.info/module/de.robv.android.xposed.installer。多 google 一下，你的问题就解决了。

#24 楼 @gaopeng1106 不过我们这次评估得有点晚了，因为 topic review 比较迟才弄完。最后加上评估主要是避免之前预期落差大的问题。

赞！这几项都没接触过，学习了。

#9 楼 @jh901011 看看这里：
https://sites.google.com/a/chromium.org/chromedriver/getting-started/getting-started---android

留意这句：

ChromeDriver supports running tests on Chrome browser (version 30+) as well as WebView-based apps starting in Android 4.4 (KitKat) that have enabled web debugging and JavaScript.

#10 楼 @actionwind 我没试过，不敢下定论。你可以试试。
至于混合起来用，建议你两个都用一下，这样你就会找到答案。

款式三

#7 楼 @jh901011 你确定 webview 的 debug 开了？你确定 webview 是 android 4.4+ 系统的原生 webview ？没有这两个前提， webview 不会出现在 context 中。

#8 楼 @actionwind 额，这两者没什么关系。。。本来 uiautomator 在 google 的定位就只是用来做多应用之间的简单交互。单个应用用单测或者 Espresso 之类的覆盖。

话说 uiautomator 本来就不底层啊。

建议你看下自绘 view 的一些相关信息，你就知道为啥不支持了。

#4 楼 @actionwind 这是自绘 view ，没有实现 accessibility 方法，无解。

这个还真不知道。苹果的东西不开源，就算有个思路也只能说是猜。

你要不试试用 Debug View Hierarchy 看下控件结构，看是不是有什么控件覆盖了？

#18 楼 @turinblueice desired capability 是脚本里设置的，appium 图形化界面主要管 server 的参数。desired capability 属于会话参数。

#7 楼 @anikikun 今天终于用 mac 体验了下 stf ，确实不错。
之前用 docker 弄，花的时间太长了。。。用 mac 半个小时内就搞定了。

#53 楼 @coffeecatyao 其实有做过，把每个接口的常用操作封装起来，步骤一致的参数提取出来做 for 循环。但步骤一致的实在太少，而接口封装后其实重用性没有那么大，因为我会用到这个接口的用例数量不多。

#52 楼 @rambo 木有。求科普。

不错。以前用 LR 的时候前辈就教了最基础的两个点：think time 和 并发量的变化要以一定数量为步进逐步变。

话说表格的 markdown 是不是用错了？看起来有点像表格 markdown ，但实际又不是。

我的论坛用户名你输错了。。。不过刚好也看到这个贴了。

首先，inspector 的 visible 一直是 false 的问题是 inspector 本身的问题，话说我就没见过里面显示 visible 是 true 的元素。。。应该是它解析 xml 的时候那个属性有问题。所以我觉得你的问题和那位外国哥们不是同一个。

第二个，visible 确实如你所说，就是显示是否可见。你找的代码也对，appium 的 xml 中 visible 属性确实是这么来的。isVisible 是 UIAutomation 原生 API ，它用于指示当前元素是否用户可见，简单地说就是用户在界面上看不看得到。至于它返回值具体通过什么判定，准不准，这点我就没探究过了。不过从以前的使用经验上看，大部分情况下它是准的。

第三个，以前曾经遇到一个坑，不知道和你这个是不是同一个。我们以前的一个应用界面的 所有可见元素每隔一定时间会通过 remove-create 的方式重新生成（设计如此，开发的想法就是能简单实现实时更新，适应不同的界面配置）。重新生成后的界面元素连内存地址都不一样了，但当你继续使用之前的元素的方法时，并不会产生报错信息。例如访问元素的 isVisible 方法，它会一直告诉你是 false ，你完全看不出这个元素实际上已经不可用了。但有一个简单的方法可以分辨：获取元素名称。如果元素对象已经不可用，那么它会返回 null 。因为不知道你应用的具体情况，所以我也不好确定是不是同一个问题，只是给个思路你参考下吧。如果你想修复这个问题，可以参考我之前的 fix 代码：https://github.com/appium/appium-uiauto/compare/master...chenhengjie123:element-cache-fix

祝你成功~

#2 楼 @keen_lau :plus1: