先收了，以后研究

最主要的原因是有了家庭，多了一些重点。

#14 楼 @mingway_hu 共勉！

#3 楼 @oscar 谢谢！有同感就好！

#7 楼 @se7en 误解，不理解，在生活中也常见，关键是坚持对的事情。

#6 楼 @qddegtya 这就是我上次赞你在做有意义的事情的原因

#4 楼 @lihuazhang 不好意思，其实也不清楚，上次在支付宝开的沙龙，monkey 的主管好像说了达到了 1:1，可能是我听错了

#1 楼 @monkey bingo

#5 楼 @lihuazhang 前期开发还没有完成，发现的 BUG 可能在进测之后已经修复，当然记录是有必要的，BDD 和 code review 对于大部分测试人员来说难度大了，而且国内开发素质参差不齐，BDD 估计都很少人会了解，叫你 review code 可能不会。

第四个问题，用心，用心去看书，积累，才能积累到东西，想这里兼顾，那里兼顾，肯定会得不偿失。
综上所述，仅是给一个参考，其实我觉得根本原因还是自己不清楚自己的工作，没有给自己一个清晰的定位和规划。

第三个问题，项目一开始 PM 就会给出一个项目进度的时间表，什么时候需求评审，什么时候测试评审，都会有一个明确的时间点，那在需求评审还没有开始之前，你可能认为是一个 QA 的工作真空期，但是你确认自己在即将到来的测试工作需要的技能掌握好了吗？这个阶段可以作为你积累的阶段，至于你这个阶段提 BUG，还没进测，BUG 是不可能提的，清楚自己的工作，你提了开发也不会鸟你，可以以各种理由 reject。

第二个问题，首先清楚，QA 的工作是怎么量化的？BUG 数量是其中之一，那为什么不录入 BUG 系统？BUG 系统不止有 BUG 跟踪管理的功能，还是很多对项目开发有帮助的功能，而且 BUG 管理系统是可以作为以后跟开发有分歧的依据，各个 team 的老大都可以看得到，有记录可循，BUG 系统作用是很大的，不要简单理解。

第一个问题：需求不明或者需求不合理在很多公司，不同团队都有，需求不明，首先需要跟产品沟通下，确认需求，我们确认需求是在确认预期结果，所以只能产品给预期。需求不合理，首先清楚每个岗位的职责，QA 是对保证产品质量，也就是说最基本产品功能逻辑需要 OK，那这些都是根据 PRD 来进行测试的，所以当 QA（还是开发）对需求有疑问，或者不赞同的时候，通过沟通跟产品和业务，给出我们自己的建议，让他们接受你的建议，假如你的建议是合理的，而且是对产品的质量是有很大的改进的，假如产品跟业务不接受你的建议，你还是对自己的看法建议坚持，你可以找 QA manager，他会产品主管或者跟开发经理谈，通过上级去沟通。

#14 楼 @seveniruby traceview？有没有元素定位工具的 jar 包，traceview 是个带 UI 的工具，我需要拿到控件名和位置。

辛苦了！

android 有自带的元素定位工具吗？

写的非常不错！

#1 楼 @qddegtya 说的很有道理

#34 楼 @seveniruby 哦哦，加油！！！我准备扫描二维码，O(∩_∩) O

技术项目搞的咋样了？有多少个志愿者？

#9 楼 @lihuazhang robot fw 他自己本身也有移动平台的 lib，只是用的是 calabash，是不是可以自己写一个基于 appium 的 robot lib？这不就把 2 者结合起来了吗？