互联网测试的生生死死

互联网的测试发展方向有些步入了奇怪的道路。

时效性决定了测试的两难：和许多传统测试行业不同，互联网更讲究时效，也就是大家都在比速度，在确保不是太差的用户体验上。大多网络产品都是以完成满足用户需求的功能为首要目的。在确保时间点的问题下，部分问题可以容忍。时间一久甚至被遗忘，又或者还未等待解决，这个功能都有可能已经结束了它的生命周期。偶有产品经理处于考虑用户体验，对一些实际影响不大的问题非常纠结。抱着一定要解决并且要准时上。而不能是不解决就不上的这种态度。解决问题，测试问题，变得紧迫而急切。上线后自然不一定能拿到好的效果（会有一定的几率又引入了其他问题）。

测试人员的技术在向开发看齐：测试和开发人员的技术大多都被要求的有点类似：“全栈性”工程师，或者说是“测试开发”。大家基本上已经忘记了这个人必须是个测试，是有专属的质量保障工作要求的。更多的是要求这个人必须能够从头吃到尾。考量的依据也不再是执行了多少测试用例，测试了多少功能，对需求本身是否吃透了。而是有没有测试框架的创新，测试新方法的研究。测试的技术能力因此得到了质疑。往往把只会做好黑盒测试的同学打上没有测试技术的标签，测试的工作在晋升、绩效时也不一定被认可。

测试需要拥抱变化：但是这样的测试是否还是原本大家期望的样子呢？测试的理论，测试用例的设计方法，测试方案的制定是否还是测试人员的必须技能以及提高点呢？但是标准又有谁来关注，谁来制定呢？

研发决定手动测试应该无法避免：互联网快，研发框架也没有考虑太多的可测性易测性，因为快。新项目初期不适合自动化，代码化，或者说你自动化的时间还不及手动效率更高。但是一旦对你的要求是你既要做手动还要写代码做自动的时候，工作量就大的惊人。但是当绩效又有点向代码技能偏向的时候，这就是质量风险点出现隐患的地方。

技能高低在于你写了多少行代码：互联网行业评价体系，大多是评价你有多少创新。开发往往多在实现功能，这造就了开发天生具备更多的创新机会，也一定层度上巩固了开发实现创新的基础。而测试，因为必须要确保质量，必然创新的机会就少之又少。如果是类似的评价标准，自然而然测试就不占优势。支付宝，测试P9据说只有1个人，而其他大多都是开发人员。“我们对开发人员的要求也是要创新，而不是只是写业务代码”。但是不要忘记了，任何实现新东西，往往都是要靠代码解决的，而这块技能上，开发本身就占有优势，除非哪一天，写代码可以代替所有测试工作。当然测试也能创新，本人作为一个测试写过好几篇专利，都是和业务相关，但是和测试无关的。我其实也很希望在用测试就可以实现创新，但是发现却很困难。

华为的一个问题解决了3个月：在华为，很多产品版本迭代周期非常长，这是华为无法融入互联网的一个原因所在，但是迭代周期长也体现了华为对质量的重视层度。这也决定了不同产品质量是不同的。

361制度下开除了一个只会做功能测试但是责任心很强业务也很精通的测试人员：我觉得这是测试人员的悲哀，也应该会是一个公司的悲哀。

测试与开发地位应该相同：在互联网，测试的地位和开发并不一致。大多数的技术大牛基本上开始就不会选择测试，导致站在巅峰的裁判满大多也来自于研发而非测试。而非测试去评价测试这本身也不太公正。久而久之的恶心循环后，测试的位置也变得比较微妙。此外，由于互联网的业务还是比较简单。并不需要太复杂的组网就可以完成测试。因此，测试的工作展开很“容易”。我也经常见有人叫嚣道：你们不就是这样点点么，我也可以。这个声音来自各方各面。但是却最终导致了测试话仅仅容易变成建议，风险预判容易变成友情提示。但是故障背后，血与泪的教训背后却是这无法改变的恶心循环。

生生死死之路：感慨互联网测试的生死，其实还是要求大家去拥抱一些变化，在回归初心（质量为先）的基础上，我们更需要体现出大家的专业性。基本的代码功底，更高的push能力。然后期待，期待业界有新的不一样的认识在变化，而这一切的风向标也许是某一家bat企业。