模板
教程
環境
性能
功能
管理
軟件測試管理知識大匯總
1、 測試團隊結構是怎樣的?
大多數測試團隊，或者說傳統測試團隊，一般按照測試類型構建團隊體系，如圖所示：
優點：職能劃分明確。
缺點：技能發展單一，協調成本較高。
有部分團隊按照測試粒度構建體系，如圖所示：
優點：測試提前。
缺點：測試成本偏高。
還有的按照測試階段或者說測試能力構建體系，也就是通常說的流水線，如圖所示：
優點：測試速度快。
缺點：測試職業發展容易形成瓶頸。
有極少數團隊按照測試專業程度構建體系，這也是目前甚囂塵上大肆鼓吹的結構，如圖所示：
優點：測試成本低。
缺點：容易脫離實際業務。
上面幾種結構本身并無高下之分，可結合團隊實際情況進行選擇。筆者所處團隊的結構目前是第一種、第三種和第四種的混合體，如圖所示：
優點：資源利用率最大化。
缺點：并行工作較多。
2、 開發需要什么樣的測試?
測試時間短
測試質量高
善于交流
專業
深入了解產品
……
隨隨便便可以列一堆要求，但其實核心就一條，能做開發做不了的事。聞道有先后術業有專攻，測試自有其專業領域，測試人員的核心價值應該體現在哪?開發與測試的關系既涇渭分明又水乳交融，身為團隊主導者應能準確辨別在當前整個研發體系中測試團隊處在什么位置應起到何種作用。由此制定團隊目標確定團隊發展方向，而不是拍腦袋亂想，或者把測試團隊孤立出來單獨訂目標。技術儲備很重要，但技術儲備的方向要靠主導者來確定，比開發更懂測試比測試更懂開發，這句玩笑話說出來真的很心酸，因為四不像。
一般測試團隊會經歷這么個過程：
草創，先不管別的能把基本的測試需求滿足就好。
上升，普通的功能測試趨于成熟，開始引入性能、自動化測試等等，多采用第三方測試工具。
突破，有相當的測試積累，有較為豐富的測試資源，開始建立獨有的測試體系，包括各種方法論與測試產品。
平穩，該做的好像都做的差不多了，也想不出什么革命性的創意，保持現狀吧，開始著書立傳。
下滑，人浮于事，毫無激情。
筆者見過的測試團隊大多處在“突破”階段，在此階段要注意技術研究與實用性的關系。
說了半天，其實這個問題應該變成，企業需要什么樣的測試團隊。
3、 老板需要什么樣的測試?
和上面問題有什么區別?有，上面是群體對測試的要求，這里是個體對測試的要求。
首先，這里的老板指的是整個研發體系的負責人，什么產品、開發、測試都在他那。
其次，有一說一，大多數老板對測試領域并沒有太多深入的了解，對測試的認知更多來自其它團隊的反饋及產品的最終質量。所以老板最關注的測試問題是什么呢?
測試成本：測試到底能為我帶來多大的收益?這是每個老板都會問的問題。ROI是每個人心里的一本賬。筆者一直闡述資源利用率最大化、能量守恒的原因，就是建議用最少的資源辦最多的事，要一個人承擔多個任務而不是多個人做一件事。講到這很多人會說你當我們不知道啊問題是怎么做到。如何降低測試比例下文會談到，但筆者在這首先想問，作為主管的你真的想縮小團隊規模嗎?是否因為其它因素反而想擴大規模?
技術含量：一家企業到底是以商業為主還是技術為主，這點不用費腦子多想，至少我們都是做技術的。測試技術到底包含哪些內容?上文提到過這里不重復。如果仍不清楚可以查閱筆者一系列文章。在這就說一點，很老套也很樸實，能發現更多更深入的別人發現不了的缺陷，就有技術含量，不管你在過程中使用了何種技術何種方法。你說你用了多少高精尖的技術結果愣是一個缺陷沒找到，有用嗎?
產品質量：這條不用多說，缺陷預防才是王道啊。
團隊協作：如果你認為開發、測試是兩個團隊，那么就一定是兩個。職能劃分明確沒問題，但自掃門前雪就很有問題。這故障是開發弄的與測試無關，一旦有這種想法何談協作?
無可否認，在整個研發體系中，測試不是核心，至少在當今各種各樣的研發流程里它都不是。明確這一點，也就能明確老板到底需要什么樣的測試團隊了。
4、 如何提升測試開發比?
測試開發比應該是1：3?1：4?1：10?甚至干脆就沒有測試。這是個哲學問題，爭論無止境。不過筆者還是要說，單純的談論測試開發比是毫無意義的，它涉及的因素太多太多，絕對不是越高越好。
列幾個提升比例的切實有效的思路：
能量守恒：測試工作量不會消失而只會轉移，轉移給機器，轉移給非測試人員。目前大多數團隊的作法是轉移給機器，這就是自動化測試長盛不衰的原因。題外話，雖然筆者并不認為自動化測試是銀彈，但承認它至少是顆子彈。然后有少部分團隊的作法是轉移給人，即把測試工作發散出去，發散給非專業測試人員。說白了就是很容易開展測試活動，是個人就能來進行測試。想達到這點必須滿足一個前提條件，待測產品具有極高的可測性。這也是筆者一直鼓吹的全民測試，測試工廠化、傻瓜化等等等等。具體如何提升產品可測性，請參看筆者另一篇文章《測試手段多樣化》。
