#92 楼 @lihuazhang 游戏这块很多公司都执行了这个，我觉得有些敏捷测试就是套皮的，有些方法不对，有些是有方法，但没人去强调贯彻。。。敏捷贯彻的 1 个要点还是人的自我驱动。

测试的确是定位成服务部门，不过做为交付下游，这个也是没错的。
至于所说的意义类的，岗位权责技能和开发重合也是必然存在的，绝非对立（不可能没有重合）。只是方向不一样，开发是基于实现，测试是推动和降低风险，开发和测试 V 也好，W 也好，螺旋也好，都是基于尽可能更早的测试，发现的问题来制定 1 个 debug 周期和如何收敛问题（这条原则一直未变，尽早提出问题）
测试和开发都是在做一件事，服务于需求，开发是实现和生产，测试在按开发实现的顺序和生产的顺序枚举，科学的方式和规范，和测试数据分析的策略就是在寻找枚举最优路径。（怀疑开发意思是指不要信任每次更新内容是绝对安全的，而不是对立，测试是产品交付的下游）
我想说测试不仅仅是和开发打交道。
还有关键看你认为的测试岗位权责是什么。

做的很牛，覆盖点炒鸡多，不过内存抖动和 so 文件保护等问题 提出，程序也不会修的，但重绘等是会修改的。

#28 楼 @chaos1001 一些是根据业务生成的 SLA 标准，需要基本功和理论知识，不过这里的一些我觉得也不是很认同。

#1 楼 @monkey 啊。我是夜猫子，O(∩_∩) O 哈！

棒棒的~~

为啥没人选运维。。

没看到 welcome-skip 下面有挂脚本。。

#1 楼 @seveniruby 好的

= =老罗的那个工匠精神是营销。

#4 楼 @seveniruby 是要先做 1 个打赏码嘛

= =我的工资居然和你这个岗位上限 25k 还有差距，真是伤感。

ui 自动化 也是有些必要性，咳咳看什么业务，某些消息是需要打开某个 ui 才可以下发（保存，读取，变更），直接接口测试当然也行，测试模拟真实操作。《---自动化考虑拆分业务吧
一些 ui 伸缩性测试，有必要性。
单纯读取元素就意义不大，不过还是需要的。
补充：如果按多少行用例产出 bug 数量，级别和 bug 类型重复来看，ui 产能就真不怎么样。

支付宝关于通讯大头如何定义的，购买通讯设备吗= =好奇

#4 楼 @actionwind 最早都是用 word 写计划的，然后计划里标注什么阶段，需要用到的文档名称和文件位置。。

#4 楼 @monkey 第二章发了

#4 楼 @monkey 看完了。是可以的，脚本语言层面支持动态更新，游戏也是这样的，底层或者 sdk 壳里的，就不能了。

#1 楼 @lihuazhang 对的。chunk 现改现看效果，不用重编译包。
#2 楼 @monkey 大众点评的 a/b 测试，= =什么语言写的？

文章不长，但内容还是很充实的，个人觉得这个对于有一定工作经验或者从事过相关工作的人 看更好点，如果可以的话，建议可以写点原理，让新手性能也可以一样效果。

写的不错

#1 楼 @lihuazhang 的确问问题，描述清楚，对问和回答的人都好= = 这个好像是某个版本新加的 API

#3 楼 @monkey 是董杰

梁羽生大大的书 买了 1 套 看完了
买了十几本 青春文学 看完了，看完一段觉得自己萌萌的。
旅行了不少地方，还都住了
充了九阴真经 ol = =剁手
其他吃喝，团建，上缴家里，谈恋爱一起吃喝，主动给红包和被要走红包等

自动化和手工比例 3:7 左右，以整个测试是 1 来算，比例是按投入人头来算，基本上自动化、修改代码的测试不会超过 40%，其次是看项目的 target，满足需求第一，然后才能走 PDCA