在一些軟件大會上，人們常常會問這樣一個問題：測試人員與開發人員的比例究竟多少是合理的？而這樣的問題，很難直接給出一個答案。為什么會有這樣的問題，可能來自于兩方面的壓力：

　　 許多公司領導總是希望得到一個合理的比例，然后按這個比例分配招聘的名額，或者設法縮小測試隊伍，減少開發成本。

　　多數情況下，測試人員工作量大，比開發人員忙，所以想尋求一個數據，來說服其公司，多招些測試人員。

　　有些專家說，根據調查結果發現通常的比例是1個測試人員對3個開發人員。實際上，這樣的比例毫無意義。測試人員與開發人員的比例會受到很多因素的影響，因不同的業務、文化和產品而不同。如果不管公司的文化、產品的類型和責任定義等，一定要按照某個比例來分配測試人員與開發人員，這是武斷的做法，缺乏科學性。有兩個典型的例子能說明這個問題：

　　微軟公司的測試人員與開發人員比例一般為1:1，甚至在Windows 2000開發團隊中，有1800個測試人員，900個開發人員，測試人員與開發人員比例為2:1。

　　在Google (谷歌)公司，則測試人員與開發人員比例則很低，據谷歌公司的測試經理介紹，為1:10.

　　那為什么呢？這里主要是測試人員與開發人員工作范圍的定義，在這兩家公司差別挺大，在微軟，單元測試由測試人員（SoftwareDevelopment Engineer in Test, SDET）做,相當于SDET再寫一套代碼來測試開發人員寫的產品代碼，其工作量不比開發人員低，另外，微軟開發的產品都是比較復雜的操作系統、服務器軟件等，自然就需要很多的測試人員。而Google的單元測試和功能測試一般都是由開發人員自己來完成，測試人員主要提供自動化測試工具的支持。軟件開發人員進行了足夠的單元測試，單元測試的覆蓋度高達85％以上，軟件在交給測試人員時，在功能上基本沒有缺陷，這樣測試人員主要集中精力進行性能測試、負載測試、安全性測試等，而這些都是自動化工具來完成的，自然需要較少的測試人員。

　　另外，測試人員與開發人員還受所開發的產品類型、企業文化、項目環境、質量要求水平、開發人員或測試人員的自身素質等影響。例如：

 　　所開發的產品是操作系統、基礎平臺，和一般的客戶端軟件、簡單的Web應用系統，其測試需求、范圍和工作量都是不同的。如Windows操作系統要支持第3方各種應用程序、支持大量的API和各種硬件驅動程序等，還有兼容DOS、32位/64位等應用程序，系統非常復雜、用戶操作也非常靈活，所以測試的工作量也大得多，需要大量測試人員的付出。

　　軟件設計、代碼的質量，也就是企業文化、開發人員的素質和能力等直接影響了軟件的階段性成果的質量，如果軟件構造質量很高，其回歸測試范圍有限、重復測試的次數只有1～2次，而不是4～5次，結果，測試的工作量大大降低，測試人員數量隨之降低。

　　例如，許多免費的網絡應用產品總是將自己定位在Beta版，那么，會降低質量水平，讓用戶試用，并幫助發現一些缺陷（因為免費，用戶也不能抱怨什么），這樣的話，公司內部測試的努力會少多了。

　　測試人員素質高，精兵強將，那么人數就會少些；如果測試人員定位低、待遇低，就可能靠人海戰術，那么人數就會多。

　　在敏捷方法中，開發人員的主導作用比較明顯，測試人員對開發人員的比例會低些。如果采用測試驅動開發，測試人員對開發人員的比例會更低。這時，測試人員和開發人員的界限也變得模糊些。

　　當然，針對一個具體公司，流程、產品和文化等都定型了，可以根據自己的經驗、歷史數據等，定出一個合適的比例，如1:2、1:3等，都是可以的。如果一個軟件公司，硬要參考微軟、谷歌或其它某個公司的做法，也許就不合理。一定要找相似的公司，那家公司又做得很成功，那就可以直接參考。

　　也許將來某一天，測試人員和開發人員會合二為一，并沒有明顯的區分，只是每個人的任務會有所不同，大家都能勝任、完成某個任務中的測試和開發的工作。所以，作為測試人員，掌握良好的技術也是必要的，包括編程能力。

　　Google 測試工程師職責:

    * Developing test strategies.
    * Automating tests using test frameworks.
    * Write moderately complex code/scripts to test systems.
   * Take responsibility for monitoring product development and usage atall levels with an eye toward improving product quality.
    * May create test harnesses and infrastructure.

　　微軟SDET的責任：

　　*Hire developers to write code to test code. Our goal is to haveengineers writing robust, reliable and repeatable tests that findissues early and cover the surface area of the component under testthoroughly.
　　*SDETs are in the source code for the product as muchas they are working with test source and our SDETs build the frameworkused for testing.
　　*Build programmatic tests that areself-verifying, that are easily extensible and that are not simplycomparing “data in” to “expected out”.
　　*A successful SDET derivespleasure from building lasting designs, implementing robustmaintainable code, and being a partner in the design of the componentswhile advancing the technologies and approaches for testing softwar

it知識庫：測試人員與開發人員的比例究竟多少是合理的？，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。