互联网产品为了快速了解，满足用户需求和完善用户体验，需要不断迭代更新版本，不断改进。版本迭代速度越快，再激烈的竞争中越具有优势。
快速迭代，效率很重要。那么我们该如何评估项目团队工作效率是好是坏，如何找出项目团队中效率的问题能？首先，团队主体构成由产品，开发，测试构成。每个环节在项目迭代过程中都占据重要地位，且相互影响，相互制约。虽然我们的角色是测试，但是只在测试的范畴内去讨论如何提高效率显然过于局限。因此，放眼整个项目评估各角色工作效率对项目整体效率提升意义更大。
那么该如何评估效率呢?
我们通过总结各角色经常发生的问题，并将问题转化成可量化的指标去度量，再分析评估指标的变化趋势来评估团队整体效率。
开发层面常见问题：
开发提测delay严重，Bug来回来去修改不对，测试要多次验证和回归。
开发提测质量不高，Bug特别多
开发间沟通不畅，经常出现信息不同步或信息有误导导致重构或返工情况
开发提交代码随意无约束经常计划外重构
改动比较大的模块提测晚，一轮后期发现大量Bug
建立指标：
千行bug率
用来评估开发代码质量，bug率越低越好
bug修改轮数及比例分布
开发修改bug轮数越多，说明开发修改代码质量不高或缺少自测
开发重构次数
一个版本内不应该有太多的代码重构，大的重构一般控制在一个左右，同一个版本重构过多无论是质量还是时间都无法保证。
产品层面常见问题：
需求前期考虑不充分，导致后面需变较多，重复开发测试工作量巨大
需求，交互不详细，测试过程中大量沟通确认，耗费时间
建立指标：
1.需变工作量占比
需求变更所带来的工作量越大，项目越不可能按照既定计划上线
2.需变时间轴
用来描述需求变更在整个项目周期内的分布情况，正常情况需变应该集中在项目前期，随着项目的进行，越往后需变应该越少，到最终回归阶段不应该再有需变。如果需变集中在中后期，往往上线时间会delay。
有人会说，身为测试这么关注开发产品的问题干啥，你也改变不了。我想说首先大家是一个项目团队，每个人都有义务指出配合团队的问题，其次，团队之间是相互影响的，只有上游团队变好了，某些测试工作才能变轻松。在指出对方问题时如果带着具体的实例，具体的数据，才能有说服力，对方才能够信服和接受。
测试层面常见：
用例设计花费时间多，或者评审返工多
用例设计遗漏，后期发现导致重复回归，延长上线时间
测试方法不足，部分Case执行耗时较多，例如场景构造，异常数据构造
工具应用比较少，手工测试比重大。测试时间变长
不可重现的Bug，导致花费大量时间重试或验证
二轮测试执行时间比较长
测试范围评估不准，临近上线回归发现bug，需要延长测试时间。
对需求理解有误，报了部分无效bug，对开发和测试时间造成浪
人员能力和经验不足，用例执行速度偏慢
建立指标：
每人用例设计时间及条数
用来评估测试人员用例设计方面的效率
用例设计评审及返工用时和占比
用例评审及返工时间越多，说明用例设计方法或对功能了解存在问题
测试各阶段时间占比
用例执行时间或回归执行时间的比例应该越少越好，比例越大说明在测试方法和 手段存在问题
不可重现Bug比例
不可重现的bug比例不应该太高，测试人员需要在如何重现问题及找到重现方面下功夫
Bug验证工时占比
bug验证时间多可能是bug过多或者验证手段不足，效率低下
发现晚的Bug占比
应该尽可能的降低这个比例，并逐个问题分析原因找到解决方案。
至此我们定义了各团队效率问题层面的指标，我们可以通过不同的迭代版本持续统计持续观察，相应的问题解决后通过指标的变化来验证效率是否提升。
(本文于2016-04-22首次发布)
