3、如何考核测试人员？
这问题有太多人探讨，网上随便一搜一大把。大致汇总有以下几点：
● 按业绩：又可分为按结果和按过程。按结果就是待测产品最终质量如何，上线有多少故障；按过程就是针对测试过程中的各项产出进行评判，什么有多少测试用例多少缺陷多少脚本用了多少资源多长时间等等等等。
● 按能力：会不会编码写脚本会不会开发测试工具会不会各种类型的测试会不会写文章会不会演讲反正上天入地电光霹雳有你不会的没。
简单粗暴点的按结果居多，管你三七二十一线上有多少故障，超出预订目标就砍你。复杂点的把各种指标放一起加减乘除还要加上各种权重。
无论哪种都有个核心问题，如何收集数据？特别是准确的收集？所以想要公平客观的考核测试人员首先必须拿到准确的评估数据，这也是为什么我一直强调测试数据报表重要性的原因。当然，测试报表的作用远远不止用于考核，更多是为制定未来测试发展方向所用，最近我一直在整理我们需要哪些报表怎样的算法才更精准，本文不做深入探讨，有兴趣的单独找我。
有些数据可以收集但有些数据需要主观判断，尤其是综合素质方面，难以量化。所以我认为考核的思路应该是一个中心两个基本点，以产品建设的最终结果为中心，坚持高效的研发过程，坚持小规模作战的思想。
产品发布后是否达到预订目标甚至超过预期，这是我们最关注的，你测试做的再好任你说的天花乱坠，最终产品目标没达成那就是扯淡。所以我反复强调不要仅站在测试的角度看问题，要不得。
互联网产品出故障不可怕，可怕的是故障迟迟得不到修复。出个P1故障我一秒甚至是一毫秒就修复了，影响能有多大？此观点很多人论述过了在这我不重复。所以在产品建设的过程中，我们第一考虑的是高效，如何才能高效，凡是阻挡高效的一律扫除。天下武功无坚不摧唯快不破，测试工作如何能更快的进行完，这是我们优先考虑的。
不要把团队无限制的扩大，更不要认为人多就好办事。咱们国家为啥要搞计划生育？用最少的人办更多的事，这才是王道。当然，出于某些个人利益考虑而做出的选择请无视我说的。
综上所述，考核测试人员就三条：产品建设最终结果如何，测试过程有没有更快，测试资源有没有更少。
4、测试人员如何才能晋升？
这问题太敏感，不适合公开讲，我做过几次试验，还算有点心得，改天单独写个攻略，私下传阅。不过有一点是可以说的，想想你所在的企业，所在的团队，你的老板，过去现在将来需要什么样的测试人员，你可以列个表格一一对比，如果看不清未来那就不必费力了，模仿别人的道路往前走吧。
5、垂直团队与传统团队有何区别？
垂直化的测试团队与传统结构的测试团队有何区别？看完这么多FAQ你还不清楚那我也没办法了，传统结构的测试团队基本不会这么做。
垂直化测试团队有个瓶颈，资源较少，测试人员的发展空间容易受限，特别是往管理方向发展的测试人员。所以不管是纵向还是横向发展，最好是走技术与业务相结合这条路，这也是我们一直说的，跳出测试的条条框框，站在垂直的层面看问题。
至于是垂直结构好，还是传统结构好，仁者见仁智者见智吧。
相关链接：
