@wowpanda 不能说是暗淡，自动化测试的价值依然很高，只是这个岗位的需求随着企业信息化项目的订单减少，逐渐缩减需求而已。只能说单纯靠写自动化软件脚本去完成自动化测试的需求变小了。对自动化测试的能力要求也提高了，比如随着移动互联网的兴起，移动端上面的自动化测试要求难度更大了，在没有一统天下的移动应用测试框架出来之前，只能调用系统接口去模拟操作，这种自动化测试脚本开发难度已经和移动应用的开发难度相当了。
此外就是互联网公司的轻快步伐快速发布的试错模式，提高了对测试的要求，传统的测试方法论无法跟进这种迭代开发的模式，小公司干脆把测试的锅甩给开发，真有测试需求的公司，往往还来不及写完自动化测试和性能测试的脚本产品就要上线了。那些真正有能力的公司测试脚本往往是交给开发能力更强的开发人员。普通写写脚本跟不上这种公司的步伐。
与之类似的就是运维岗位，传统形式的运维岗位通常都被淘汰了，只有那些能跟上虚拟化步伐有开发能力的可以留下来做价值更高的活，薪酬当然也更高。

人海战术依然有效，很多大型软件和应用的开发还是需要庞大的测试团队去保证产品的质量，只是测试人员要加快自己的技能升级速度了。

解 bug 大家可能听不懂，其实就是写手工测试的步骤，这个阶段一般是做过手工测试，了解一定的测试方法论了，开始根据测试点的需求，写各种测试步骤，比如某个功能的边界测试，就把-1 ， 0 ， 1 ， 9999999 这类的步骤一步一步写好。
通常这种要整理很多报告，写完了步骤，还要汇总各个测试点的执行反馈。作报告之类的。
如果同岗位想往上走，那就多学点 excel ，把测试报告的汇总做成自动化处理各种水晶报表都用 vbs 写好。这样有机会上去做测试需求分析，会更好一些。

如果想转测试，就不要回头做手工测试了，学学 QTP 或者 python 之类的，去做自动化测试。这也是一般测试干三年的正常进阶路线，了解测试方法论的情况下，看看视频应该就可以迈过门槛了。

工作内容上面测试需求分析对基础要求要略高一些，要懂一点开发的只是，测试规划的样例才能抽象好。
如果是自动化测试，那就是纯代码了，对测试理论要求不会太高，主要还是拿需求写好回归测试之类的脚本。比开发轻松，但也没离开开发写代码这个范畴。

压力上面，自动化测试的压力小一些，毕竟底下干活，埋头写好脚本就可以了，不需要费心做规划报告，有事上面老大扛。

行业情况就不太乐观了，最近外企不景气的原因就是好多传统企业的 IT 实施都基本完成，有进一步优化需求的都想着自己组 IT 团队来做，所以单子少了很多，测试又是很看重项目规模的岗位，项目规模小了还用不起测试。所以自己考虑吧。

资金入股和技术入股以及工资都要分开算。
谈股权的时候，技术和时间要计算一个资金估值，如果月薪两万做一年，那至少也得算是 24w 的资金估值了。

至于工资，多领的就少拿股份，少领的股份或者期权贴上去。

这些统统写合同上面开工之前就定下来，没有的话后期做成或者不成都是一笔烂帐。

成本非常高，尤其在国内这种网络带宽比较贵，人力资源比较低，管理方式比较落后的企业中实施。基本属于大炮打蚊子的应用场景。

优点其实还蛮多的，资源动态划分，容灾处理方案完善减少故障带来的损失，统一管理系统镜像和备份方案节省运维人力成本，节省 IT 设备管理成本。

前景来说，是企业市场的杀手锏，基本上大企业要做自有机房建设，功能终端管理，都会考虑使用这些企业虚拟化的解决方案。

应用案例上面，自有机房建设都少不了这套虚拟化的东西，涉及服务器高可用方案上面，多花两倍的成本和运维费用钱把故障率降低对没有太多 IT 运维人员的公司来说是挺划算的。
此外就是需要使用大量终端的企业，比如银行、移动运营商的营业厅终端，医院各个门诊医生所使用的医疗管理系统终端，工厂车间管理系统所使用的各种管理系统终端。都可以使用基于虚拟化的虚拟桌面系统减少终端设备的成本，终端就一台低性能的瘦客户机，所有操作和数据都放在服务器上面运算，管理终端的系统更新，权限变更等等操作都在服务器完成，现场的瘦客户机成本低坏了也不用担心，直接搬台新的过去登录帐号。

使用域是因为微软的操作系统在企业化实施上面通过域去管理帐号和权限的解决方案比较完善，所以虚拟机都集成这套域管理机制，方便批量管理虚拟机的系统设置。

加油加油加油，现在的互联网学习资源非常多，去看书，去自学。社区前段时间还有几个“我是做 xxx 的，我想转行做 IT ”。才三十职业生涯才开始几年而已，转行也好，继续在本行深入也好，都有二三十年的时间继续学习。不要放弃自己梦想的职业方向持续去学习！

新手不要用跨平台方案，欲速则不达，跨平台方案是给那些已经了解各个平台 SDK 差异的人用的。在没有了解细节的情况下使用跨平台方案，只有一个结果，被各个平台之间细微的实现差异绕晕，同时要学习多个平台的设计思路，光是定位问题就足够耗尽你的精力。接着就是各个平台 API 升级变迁带来的坑在跨平台方案的累积，跨平台方案要支持不同平台的接口是要付出开发时间的，某个平台开放新版本之后跨平台方案都要去跟进接口的升级变迁，可能几个月也可能不开发支持接口。

要么就用 Web ，要么就原生。不要偷懒。

赶紧截图，证明这网站是你从百度搜索并且显示推广标识，网站的页面和汇款人的交易证明发到各个社交媒体把事情搞大，然后报警拿立案书去找百度，这锅就是百度来背的。

业务有问题哦，既然运营有删除用户信息的操作，就应该把功能做到管理系统里面让运营自己去操作，而且这种一般都是伪删除，打个删除的标志位就好了。

直接去数据库跑 sql 太危险了。每日备份也不够，至少再开个 binlog ，同时把备份和 binlog 同步到其它服务器做为简单的容灾。这样操作都有记录。

绑定手机找回可以作为密保的可选项之一，而不应该是现在这种形式的唯一选择，不选择就完全不能用，这样等于别的密保方式都是无效的。

@TimePPT 按照你说的逻辑，更不应该把资料提供给腾讯才对，至于绑定手机方便找回这个我承认很方便也比邮箱找回安全，但是我依然认为密保问题是最安全的找回方式，我完全可以通过设置答非所问的密保问题避免被人社工密保问题。这点是别的手段无法替代的。

@skylancer 这点就要佩服腾讯啦，社会工程学相当不错。在进行申诉的资料提交里面，我还看到了好友辅助的功能也增加了手机号码提交哦！并且是必填项，你说填个 QQ 好友号码，企鹅大人你还要人的手机号码干嘛？这是隐私好么。

要比初级程序员高一些，毕竟有后端开发经验，在 http 协议这块，总比新手要懂得多，在调试网络请求的时候优势就出来了。
做三年了，架构上面的经验也多多少少有积累，就独立完成产品的能力来说，要比初级程序员高。
转过去，我觉得如果自己单抄完一个产品，怎么也可以算 1.5 年 ios 开发经验了。

毕竟业务处理逻辑、调试能力、架构经验这些和语言关系不大是可以迁移的。

@MSDOS 其实国家要求的是身份证信息绑定，手机是各个公司为了自己的业务强制要求的。
@laydown 主要是手机找回这个操作权限实在太高，丢手机这个不可控因素无法完全避免。

@raycloud 看来为了绑定手机这个 kpi ，很多功能都被强制加上手机短信操作了。

@laydown 我觉得所有业务都绑定了手机的时候，手机丢了更绝望。很多产品都提供了手机验证码找回功能，一条短信就可以重置很多信息。

@lycosme 你这个嘈点满满啊！ 密保业务升级，把老用户找回密码的路全断掉了。

@lausius 如果还记得密码，准备好常用登陆地区和曾经使用过的密码，走申诉渠道应该可以重置。
如果忘记密码这种十几年的号，正常申诉应该无解了吧。除了曾经使用过的密码，感觉什么有信服力的资料都没有了。

@cxe2v 没有开通过手机 qq 这个业务很特别？
我不担心泄漏 qq 号， qq 好友， qq 群这一类的数据，这些都是腾讯的数据，我也拦不住。
我担心的只是涉及我个人隐私的资料被腾讯泄露。例如身份证，银行卡，手机号，个人姓名这一类的。所以涉及填写这些信息的产品，我都尽可能不使用。
互联网好玩的一点不就是匿名性么，个人资料都提交上去了，回头别人一社工，什么都暴露了。

我还记得当年天涯明文密码被爆出来之后，早年天涯关于贵族生活一战成名的周公子邮箱泄露，直接被人肉出真实身份非帖子所说那种家世显赫的贵族。

所以资料是我的，我愿意提供就提供，不愿意提供就不能使用某些功能这个业务逻辑也没有错。只是吐槽一下腾讯这种，不提供直接完全不能用的业务逻辑。

@lycosme 这点确实是腾讯逼迫用户使用新业务，无解。申诉我感觉只要老老实实交上个人资料，应该就会给过。

@cxe2v 很抱歉，这些我都没有开通， qq 至于我而言，就是一个聊天工具，我不希望把个人资料提交给它，因为必须提交个人身份证和手机资料才能正常使用的产品，通常我都放弃使用了。比如支付宝，比如微信支付。