这里我们明确一个概念，就是项目（Project），在新twork中，项目的概念变大了，购物车、收藏夹这些都是项目，而购物车2.0、收藏夹3.0这些是演进的一些版本。因此，PTM（Project Test Manager）有了新的含义，其实就是之前所说的“子产品的owner”，但是这样叫太拗口，干脆以后统一叫PTM。注意，P4工程师的责任范围内，是没有PTM的责任的。
好，下面我们继续讲不同层级的分工。上面从工作内容上进行了分类，下面我们从他们所提交的bug，来进行一下分类，请看表格：
|
测试工程师层级 |
发现的bug |
|
开发工程师 |
80％初级bug |
|
P4 |
20％初级bug |
|
P5＝PTM |
20％中级bug |
|
P6 |
你们自己看着办 |
|
P7 |
你们自己看着办 |
从提交的bug质量上，很容易看出一位工程师的技术和能力，如果P6发现的bug，跟P4差不多，那怎么好意思继续混下去。下面我们再从另一个维度来比较，那就是：是否专注在一个project里面，请看表格：
|
测试工程师层级 |
对Project专注程度 |
|
P4 |
可以在几个Project中轮回 |
|
P5＝PTM |
必须坚守自己的Project |
|
P6 |
可以选择坚守一个Project，也可以不限定Project |
|
P7 |
完全不限定Project |
讲到这里第二点“测试工程师的分工”就讲完了。P4工程师的考评最简单最好量化，他只要按照文档，完成一定功能点分数的测试，就可以了。在执行过程中，P4也不需要大伤脑筋，如果有压力也是工作量的压力。假如P4工程师感到执行测试很困难，举步为艰，那说明PTM的设计和准备，没有做到位。而P5P6工程师，虽然摆脱了大量机械的工作，感到无比畅快，但是很快就会感到一丝不安，因为他们有了更多的资源，因此会受到了更大的压力，这种压力主要是思想上的压力，不过这些都是正常的，也是合理的。
我想一定会有很多人会对这种分工方式产生疑问，那么这里我先预测一些问题，跟大家解释一下。
Q：如果一个project的用例都由PTM写，ta能忙得过来么？
A：这就要看用例的规模了，如果按照现在我们的写法，估计够呛，用例写成“说明书”，PTM肯定累半死。用例应该是一个结构化的文档，与知识沉淀珠联璧合，总之这就要看PTM的能力了，怎么设计才能既简洁，又可读。另外如果项目太大（不禁想起WCS），那估计要多位PTM合作。
