不要做伸手党。。。
我记下了 issue 了:
https://github.com/testerhome/A-Native-TesterHome/issues/7
从 log 来看和之前另一个 issue 比较类似,都是 onResponse 出问题,后续等客户端的同学有空再一并解决吧。
印象中 711 大会时 mujun 有提到过原生 adb 稳定性有问题。不过是否和频繁打开关闭 app 有关就不清楚了。
ATT 是什么缩写?
#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 我没试过,不敢下定论。你可以试试。
至于混合起来用,建议你两个都用一下,这样你就会找到答案。
款式三