我们在这几个月里将测试人员下放到了项目组，由项目经理统一管理，项目经理具有一定的考核建议权。

实行一段时间之后我们发现在某些项目中，有些测试人员一直处于工作量不是很饱和的状态。由于人员的工作是由项目经理安排，而大部分项目经理是不太关注测试活动的，所以安排的工作难免流于形式，没办法充分调动起测试人员的工作积极性。这样就造成了在一些项目里，测试同学经常会某段时间没啥事情做，而版本快上线的时候又忙的焦头烂额，那时候项目经理又会找测试管理部门协调资源，希望能加大投入，准时交付。

尽管我们发现了这个问题，也跟项目经理提议能不能把暂时闲置的测试人员调出来，学习其他项目的业务逻辑或者是支援别的项目，但这时候项目经理总会说，这个人很忙，不能兼顾其他的工作。

下面问题就来了，怎么样度量一个测试人员忙碌与否？通过什么指标可以粗略的估算出测试人员的工作产出呢？如果测试人员的产出一直不高，要么就证明工作量不饱和，要么就是能力有问题，需要做技能提升或者是其他优化。

哪些指标可以衡量测试人员的产出呢？

编写的用例数量

测试人员的日常工作基本上就是分析需求，编写用例，执行用例，追踪缺陷。

编写测试用例的过程实际上加深了对需求的理解，整理了测试思路，找出需求中没有涉及到的地方，然后通过各种方式确定这些模糊的点。

开发用代码去实现需求，测试同学则使用测试用例去分解需求，还原测试场景，了解需求的真实目的。

我们是不是可以通过统计每个测试人员在单位时间内编写的用例数量来粗略估计测试的产出呢？应该是大致可以，不过有些需求描述的比较清晰，而有些需求就只有一句话，太多的内容需要去脑补，所以只看用例输出的效率未免不太客观，容易被挑战。

另外用例编写规范的不一致也可能导致用例输入的效率有较大的差异。有些测试同学的用例基本上是测试点，没有断言信息，这样的用例写起来就比较快；有些人的用例则比较详尽，有测试数据，测试步骤及断言，这样的用例写起来就比较花时间。

另外一些同学用excel来管理用例，各种拖拽加复制粘贴之后就能批量形成大量的用例，这些用例看起来都差不多，执行的时候能有多大的作用，实在是不好判断。

如果只看测试用例的数量来判断工作量的话，那么也可能产生一些消极用例的情况。所谓消极的用例指的是测试同学编写很多无效的用例，这些用例看起来内容详尽，步骤及预期都显得挺有章法，但本质上是复制粘贴，只是为了增加用例数量，对具体的测试工作其实并没什么太大帮助。

因此如何来保证用例的质量呢？如何尽可能多的去设计和输入有效用例，避免消极用例？评审是一个方法，用合适的方式去展示用例，让用例更容易看出端倪也是一个办法。

执行的用例数量

很多时候我们都是不看测试用例去执行的，所以执行了多少用例精确统计起来也很困难。很多情况下大家都是按照经验去估计，测的多一点就多估计一点，少一点执行的用例就少写几个，所以执行的用例量可以大致的看出工作量，当然也不排除有人虚报情况。

会议情况

开会也是工作量。很多测试同学都会参与需求评审会，项目计划会，测试用例评审会等。如果一个测试同学不是在开会就是在去开会的路上，那么他在其他方面的产出自然会变少，这时候就需要想办法降低沟通成本了。

完成生命周期的bug数量

这些bug应该是有效的bug，也就是说跟开发达成一致的bug。由于bug是有生命周期的，所以只提bug而不去跟踪bug是不行的，因为bug的处理流程并没走完，相应的工作并没有结束。

完成生命周期的bug数越多，大概可以认为工作量相对越大，但是也不排除有些项目质量其实不错，测不出来多少有效的bug的情况。

从上面的分析可以看出来，这些指标都有一定的片面性，都只能反映出正常情况下的一些产出情况，仔细分析我们会发现，这些指标其实都不算特别合理。这些指标都有一些偏过程导向，如果从结果导向去分析测试同学的工作效果的话，交付后的遗留问题数或者线上bug数也是一些可以参考的指标。从结果导向上看，不管你测试同学做了些什么，投入了什么，只要项目质量没问题，那么大家做的都是对的，是合理的；否则做的越多，错的越多。

考核测试同学的指标究竟应该是过程导向还是结果导向，其实有些微妙。可以用结果导向为主导，在结果相似的情况下看过程，这也许是一种比较中庸的做法吧。