忘了回答一下你的问题了。
测试的存在真的能提高产品的质量吗
我想先问清楚,你的测试时指测试人员还是测试活动?如果是人员,那只能说取决于他的能耐,如果大家都忽略他,那肯定对质量没多大贡献。如果是活动,我相信答案是肯定的。
你的疑惑我觉得应该是你提出的各种问题开发没有正视。例如你上面的例子,一个评论在网络良好的情况下超过 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 我没试过,不敢下定论。你可以试试。
至于混合起来用,建议你两个都用一下,这样你就会找到答案。
款式三
#8 楼 @actionwind 额,这两者没什么关系。。。本来 uiautomator 在 google 的定位就只是用来做多应用之间的简单交互。单个应用用单测或者 Espresso 之类的覆盖。
话说 uiautomator 本来就不底层啊。
建议你看下自绘 view 的一些相关信息,你就知道为啥不支持了。
#4 楼 @actionwind 这是自绘 view ,没有实现 accessibility 方法,无解。
这个还真不知道。苹果的东西不开源,就算有个思路也只能说是猜。
你要不试试用 Debug View Hierarchy 看下控件结构,看是不是有什么控件覆盖了?
#18 楼 @turinblueice desired capability 是脚本里设置的,appium 图形化界面主要管 server 的参数。desired capability 属于会话参数。
#53 楼 @coffeecatyao 其实有做过,把每个接口的常用操作封装起来,步骤一致的参数提取出来做 for 循环。但步骤一致的实在太少,而接口封装后其实重用性没有那么大,因为我会用到这个接口的用例数量不多。
不错。以前用 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
祝你成功~
markdown 的 # 号和文字之间留一个空格。我们用的是严格的 markdown ,语法中的空格是不可忽略的。
没看懂你的代码。。。把 add ,update 方法的源码放上来才有意义啊。
按你的说法,add 写文件是没问题的,那就是 update 读文件有问题了。
加 accessibility id 。