模板
教程
环境
性能
功能
管理
软件测试管理知识大汇总
1、 测试团队结构是怎样的?
大多数测试团队，或者说传统测试团队，一般按照测试类型构建团队体系，如图所示：
优点：职能划分明确。
缺点：技能发展单一，协调成本较高。
有部分团队按照测试粒度构建体系，如图所示：
优点：测试提前。
缺点：测试成本偏高。
还有的按照测试阶段或者说测试能力构建体系，也就是通常说的流水线，如图所示：
优点：测试速度快。
缺点：测试职业发展容易形成瓶颈。
有极少数团队按照测试专业程度构建体系，这也是目前甚嚣尘上大肆鼓吹的结构，如图所示：
优点：测试成本低。
缺点：容易脱离实际业务。
上面几种结构本身并无高下之分，可结合团队实际情况进行选择。笔者所处团队的结构目前是第一种、第三种和第四种的混合体，如图所示：
优点：资源利用率最大化。
缺点：并行工作较多。
2、 开发需要什么样的测试?
测试时间短
测试质量高
善于交流
专业
深入了解产品
……
随随便便可以列一堆要求，但其实核心就一条，能做开发做不了的事。闻道有先后术业有专攻，测试自有其专业领域，测试人员的核心价值应该体现在哪?开发与测试的关系既泾渭分明又水乳交融，身为团队主导者应能准确辨别在当前整个研发体系中测试团队处在什么位置应起到何种作用。由此制定团队目标确定团队发展方向，而不是拍脑袋乱想，或者把测试团队孤立出来单独订目标。技术储备很重要，但技术储备的方向要靠主导者来确定，比开发更懂测试比测试更懂开发，这句玩笑话说出来真的很心酸，因为四不像。
一般测试团队会经历这么个过程：
草创，先不管别的能把基本的测试需求满足就好。
上升，普通的功能测试趋于成熟，开始引入性能、自动化测试等等，多采用第三方测试工具。
突破，有相当的测试积累，有较为丰富的测试资源，开始建立独有的测试体系，包括各种方法论与测试产品。
平稳，该做的好像都做的差不多了，也想不出什么革命性的创意，保持现状吧，开始著书立传。
下滑，人浮于事，毫无激情。
笔者见过的测试团队大多处在“突破”阶段，在此阶段要注意技术研究与实用性的关系。
说了半天，其实这个问题应该变成，企业需要什么样的测试团队。
3、 老板需要什么样的测试?
和上面问题有什么区别?有，上面是群体对测试的要求，这里是个体对测试的要求。
首先，这里的老板指的是整个研发体系的负责人，什么产品、开发、测试都在他那。
其次，有一说一，大多数老板对测试领域并没有太多深入的了解，对测试的认知更多来自其它团队的反馈及产品的最终质量。所以老板最关注的测试问题是什么呢?
测试成本：测试到底能为我带来多大的收益?这是每个老板都会问的问题。ROI是每个人心里的一本账。笔者一直阐述资源利用率最大化、能量守恒的原因，就是建议用最少的资源办最多的事，要一个人承担多个任务而不是多个人做一件事。讲到这很多人会说你当我们不知道啊问题是怎么做到。如何降低测试比例下文会谈到，但笔者在这首先想问，作为主管的你真的想缩小团队规模吗?是否因为其它因素反而想扩大规模?
技术含量：一家企业到底是以商业为主还是技术为主，这点不用费脑子多想，至少我们都是做技术的。测试技术到底包含哪些内容?上文提到过这里不重复。如果仍不清楚可以查阅笔者一系列文章。在这就说一点，很老套也很朴实，能发现更多更深入的别人发现不了的缺陷，就有技术含量，不管你在过程中使用了何种技术何种方法。你说你用了多少高精尖的技术结果愣是一个缺陷没找到，有用吗?
产品质量：这条不用多说，缺陷预防才是王道啊。
团队协作：如果你认为开发、测试是两个团队，那么就一定是两个。职能划分明确没问题，但自扫门前雪就很有问题。这故障是开发弄的与测试无关，一旦有这种想法何谈协作?
无可否认，在整个研发体系中，测试不是核心，至少在当今各种各样的研发流程里它都不是。明确这一点，也就能明确老板到底需要什么样的测试团队了。
4、 如何提升测试开发比?
测试开发比应该是1：3?1：4?1：10?甚至干脆就没有测试。这是个哲学问题，争论无止境。不过笔者还是要说，单纯的谈论测试开发比是毫无意义的，它涉及的因素太多太多，绝对不是越高越好。
列几个提升比例的切实有效的思路：
能量守恒：测试工作量不会消失而只会转移，转移给机器，转移给非测试人员。目前大多数团队的作法是转移给机器，这就是自动化测试长盛不衰的原因。题外话，虽然笔者并不认为自动化测试是银弹，但承认它至少是颗子弹。然后有少部分团队的作法是转移给人，即把测试工作发散出去，发散给非专业测试人员。说白了就是很容易开展测试活动，是个人就能来进行测试。想达到这点必须满足一个前提条件，待测产品具有极高的可测性。这也是笔者一直鼓吹的全民测试，测试工厂化、傻瓜化等等等等。具体如何提升产品可测性，请参看笔者另一篇文章《测试手段多样化》。
