#1 楼 @lihuazhang 。。。你应该关注妹子啊。。。
太简洁了。。。虽然大致知道你的意思,但是没看出它的具体做法和优势。而且如东哥所说,脱敏脱得太厉害了。。。要不你弄个 demo 来截图也好啊。。。
忘了回答一下你的问题了。
测试的存在真的能提高产品的质量吗
我想先问清楚,你的测试时指测试人员还是测试活动?如果是人员,那只能说取决于他的能耐,如果大家都忽略他,那肯定对质量没多大贡献。如果是活动,我相信答案是肯定的。
你的疑惑我觉得应该是你提出的各种问题开发没有正视。例如你上面的例子,一个评论在网络良好的情况下超过 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 ,但实际又不是。