看来是乐视的小兄弟啊, 写的不错, 总结的也很认真.赞一个.

#14 楼 @rdtriny 分享沙龙来吧. 下期给你一个 topic, 听你们分享下干货

#14 楼 @kasi 我们这一代人只能想到 0527

#7 楼 @doctorq 你应该再加个 11, 变成 101111. 这样就成了 233...

#15 楼 @lihuazhang 到月底吧. 发票我还没凑上. 他们得要发票.

支持 appium 框架的. 不过执行方式是把自己的脚本上传上去. 可以参考下 testdroid 的做法.

#2 楼 @doctorq 我也在采坑, 用法偏学术, 高能的技术不太好掌握, 国内的文档也很少. 建议你慎入

#1 楼 @newbee scala 并不火. 最后还会是小众的命. 没有 ruby 更适合测试领域. 但是贴近国内庞大的 jvm 生态. 方便和研发协作.

听说 rubychina 也打算正式发布官方的客户端了.

#1 楼 @newbee 恩. 我们也正在应用 twitter 的 diffy. 晓光是我领导.

好玩, 感觉更像是故意设计的.

#1 楼 @lihuazhang
#2 楼 @lucasluo
#3 楼 @chenhengjie123

这应该是反调试的技术. 不让在模拟器上调试

#1 楼 @lihuazhang 恩 那看起来是好事, 说明大家都已经不差钱了. 分发的方式可以再想想. 改成微信红包试试?

有意思. 估计是代码上没判断返回的结果. 返回 null 之后 后续进行了各种调用

如此研究深度, 国内少见啊. 恒捷进步好快.

这个不好修了. 他们估计也只能在代码中加点警告了.

先明确原因. 如果是环境的差异, 就逼研发提供一个隔离环境满足测试, 否则就说服他们担责.
在很多公司里面, 出了问题首先是研发的责任, 这样是逼他们提升自己的产品质量. 质量是开发出来的, 测试偏防御.

梳理你们出的所有问题, 然后提出改进建议, 理清需要支持的资源, 然后再明确是谁担责, 在公司树立一个有问题研发先担责的氛围, 这样你们压力就会小些. 也符合利益. 我想 cto 和 ceo 会同意的

#7 楼 @shixue33 是的, 最后两行代码目的估计是运行保持线程数. 实际上主流程的代码执行完毕, 充数是没意义的. 因为实际上它是没用的. 也达不到类似 loadrunner 那样的聚合点. 如果想模拟并发, 你应该设置一个聚合点, 让 50 个线程先启动, 然后再 hold, 等待一个全局的条件满足后再执行. 在启动 50 个线程后再设置某个条件. 这样所有线程才会真的并发执行, 并发度才较为理想.

#7 楼 @mohu nice

了解你团队的目标, 你团队的 KPI 要和更高的领导确定. 确认方向.
然后是把 KPI 化解到每个人. 不用太确定细节的数字. 不然就会陷入官僚式的数字魔窟. 覆盖率在 69% 和 70% 并没有差别. 不必纠结.

KPI 要从结果和过程中分别体现出来.
结果就是产品的质量数据. bug 率. 线上故障, 用户投诉, 迭代或者发布次数.
过程就是测试的效率, 人力成本, 需求满足度, 测试覆盖度, 技术应用度, 然后再细化具体的数据就行了
比如测试多少轮, 测试发现多少 bug. 测试时间缩短多少, 技术的价值体现, 测试体系的完备和流程规范. 人员的成长等

#5 楼 @infy001 适合新人. 并不是每个公司都要招高手的. 或许人家已经有了

被评论给带偏了, 作者都没提开源. 我觉得能够开放这个思路就很好了. 大家别奢求太多, 关键的还要靠自己去做

那估计是搜狗的 bug 了