谢谢，已更正，写完了自己也觉得怪怪的，好像短了点

天行者？阿纳肯？

要不要测试拿一个 8 拍对面的人，然后通过 8 的 AR 来解锁 X？

• 覆盖率本身不重要，100% 的覆盖率也不意味着没问题，环境、配置集成的问题占比不在少数
• 非要看覆盖率，变更覆盖率才稍显更有价值一点，扫变更集，svn、git 都支持拉变更文件清单
• 覆盖率只要环境能允许，java 的用 sonarqube 或者 jacoco（推荐），手动自动都可以看

顶高 P 光哥，找工作关键是跟对人，跟着光哥混，前途钱途都有~

如果数据量不大，可以用 System.setProperty，报告里面取就好了
或者维护一个 hashmap 之类的在内村里，声称报告的时候取

谢谢恒温邀请，问题太抽象，我不善于导人从 0 向 1 的发展，倒是比较擅长在现有的能力中找闪光点以谋发展
我还是用一张 PPT 来说吧：

• 能力和价值对等逐层上升。
• 学一些经典理论，温习和梳理你在学校里学习的那些基础课，对你的工作有非常大的意义，至少不会让你的工作流于做苦力，能让你自己知道自己做的事情有什么意义和价值，背后是什么方法论在支撑，你应该怎样丰富这些方法论的实际应用。
• 我的理解里没有把自动化和性能测试作为发展的必由之路，当然你要做，还是要多看看文章、帖子，你该明白，自动化也好，性能也好，都只是质量的一个方面，我看到的为此而随大流的现象，大多是为了迎合一些懵懂的老板的某些无知趣味而已，看清背后的东西更重要。
• 落地非常重要，空想没有用，文章只看不实践也没有用，好的 team 有天然的，也有你自己打造的，如果你能通过自己的努力将这些事情做好，比你进一个天然好的 team 的履历要有价值的多，等待领导首肯或者授意，这跟我等着被 boss 升为 CIO 来实施自己的抱负一样……这特么的是一句废话鸡汤 仅作用于暂时没有条件进入一个好的 team 的时候，我自己也宁愿进一个好 team
• 心急、浮躁是大忌，比薪水神马的 LOW 爆了，我面试遇到要求专职做自动化或者性能的人，我一般直接 PASS 掉，一方面我们没有这样不需要关注业务的岗位，一方面我会觉得这样的人视野太有限、看问题太片面，以至于以后发展的路太窄，我也不希望我带出来这样的人，呵呵。

只有 2 年经验还能达到要求的人，够可以的了，25K*13 能招到估计比较难

感觉待遇是德国总部的 1/5 还不到？

完全同意你的看法

第一段快的唯一原因是……编译器编译不通过，不用执行了

不客气，出去面试的确是个好办法，不过需要运气，比如我：
我去支付宝面试过 2 次，前后相隔 6 年：

• 第一次我跟人家说分析测试需求……人家抓狂了，问测试需求是什么鬼，然后没有然后了
• 第二次，人家因为我做了两三年的团队管理，断定我不适合一线工作

两次都没有机会到第二轮，是不是很惨~
此外，还可以多参加社区的交流活动，这个很有用，没有了，祝你好运

补充一点，在平时的工作里，要时刻问自己，你是想做下面哪一种？
有些人就是忘记了这点，让自己能得变成了 rambo，然后呢，you are fighting alone，要刻意改变这种趋势
这是个一个培训 ppt 的结尾

• 不要跳槽，如果能力够了，想走管理路线，时间到了自然会有机会，分这么两种情况：

• 你的领导、你领导的领导在想办法帮你谋位子，扩张或者拆分团队，为了你这样有能力但是发展遇到瓶颈的人；
• 你的领导感受到威胁，不安，或暗示你或针对你，或因自己能力已经逊于你而有让位之心，如果不能妥善解决这时候你再离职，这时候你自己必须已经具备 “离开这个平台依旧这么牛逼” 的能力，否则你就被动了，别看现在是否是什么核心员工；

• 看你自己的描述，你还没有具备能够将学到的东西运用到工作中、在工作中寻找各种改进点的能力——因为这需要足够的积累和底蕴，这需要你在日常工作中有足够的思考和沉淀

• 隔三差五的跳槽也可以发展，但是大公司不是很喜欢你的履历，除非你是个奇才（其实没什么大公司喜欢奇才的），持续在一个稳定的环境里也可以发展，这需要你主动把手伸向别人的领域，比如研发、运维、基础架构、DBA、PC 桌面服务、网络架设，等等，这两种模式的差异在于：

• 持续跳槽获得的晋升，最多做到经理、总监，撑死 CTO
• 在一个稳定的大环境里历练再做几次跳槽，上限可以做到 CIO、CEO

deflate2 压缩，压缩比比较好，服务端给一个接口用来收数据，http 请求附带上压缩的 json 文件，到服务端解压重新拿数据请求原始 url

严格来说你这已经不叫框架了，有点向平台靠拢了

找网络组同事给你开墙，然后让 SMTP 服务器的管理员给你授权

不用 jenkins 的邮件服务更简单，自己用 java 或者 python 写个调邮件服务的小程序，在 JMeter 的断言里调用

bat：java -jar……http://www.cnblogs.com/weidiao/p/6082011.html
至于如何导出 jar 包……
Jenkins：add build step——>execute batch command

知道你团队的研发流程、你的同事需要你提供什么东西来帮助他们并且实现他，这就是核心价值

是这样有魄力的领导 你去了一个人也未必玩得转啊
当时一个测试组就四五十号人，有 buffer 可以撸，而且开发不跟测试抢人力资源
这个前提建立在开发多年对测试的信任上，不然也不好说，好多代熬出来的

冒烟测试，就不要想着 e2e 全部测完了，挑重点独立测，测接口验后端等，配置没那么突出的重要吧

关键是，你觉得在开发环境冒烟有什么不可以的呢？除了死规范？

所以我还是比较乐意带那种我给出论断，他自己就能猜出 8、9 分背后的论据的 DDMM，省得我磨磨唧唧招人烦，做测试虽然没啥技术含量，但是难度还是很高的，基础要好，理解能力要好，敏而善思

靠什么测有什么关系？
你没懂我啥意思吧，我的意思是做业务测试的自己来做自动化才行，相对专门的自动化测试来说更加事半功倍
你想想：

• 第一，测试数据发生冲突，对测试环境造成伤害，一旦环境分离，那场景有效性就不好说了
• 第二，写完自动化测试，以后谁来维护？谁对测试的有效性做评估？
• 第三，你愿意你的团队两拨人地位不等同，考核标准不一样，不好管理
• 第四，不排除业务测试的人会迷信自己不会自动化没前途……可能造成流失的可能性？
• 第五，

if  (自动化测试的精通业务细节、测试设计) {
    自动化测试的人力和工作压力非常大 || 配比可能跟业务测试达到1：1，这样可算是浪费？
} else if(场景设计由业务测试的人分析清楚交给他们){
  if  (传递过程中就会有信息损失){
      测试实现效果差
  } else if  (即便不损失) {
      if (这样做完自动化，自动化测试的人会理解所有做过的业务){
        这跟做业务的人自己去做有啥区别呢？
      } else {
        你愿意相信做完自动化还未能理解业务场景的自动化工程师？
      }
  }
}