最近看了點敏捷測試的東西，看得比較模糊。一方面是因為沒有見真實的環(huán)境與流程，也許它跟本就沒有固定的模式與流程，它就像告訴人們要“勇敢”“努力”。有的人在勇敢的面對生活，有些人在勇敢的挑戰(zhàn)自我，有些人在勇敢的面對失敗與挫折。好吧！他們都實現(xiàn)了“勇敢”，勇敢到底是如何去做，也許說不清楚?；蛘哒f每個人都有自己的實踐方式。但是他們卻同樣靠著“勇敢”攻克不自己所面臨的困難。當然了，敏捷并不是簡單一個詞語，經過前人的不探索與總結，還積累與總結相當多的經驗可供我們借鑒與參考。

?　　按照本文的主題還是來談談軟件測試人員的分工吧！主要來談傳統(tǒng)軟件測試過程中的測試分工，因為敏捷測試中的測試分工我還沒弄明白到底是腫么個情況。

集體測試

　　也許專業(yè)測試里講這種方式，很可能不叫“集體測試”。因為我根據(jù)的自己的理解起了大概符合意思的名詞叫集體測試“集體測試”。

????　　就是測試模式就是，公司里所有的測試人員抱成一團兒，來一個項目，所有測試人員就集中測試一個項目。

?

先說這種分工方式的優(yōu)點：

　　1、因為測試團隊的中每個成員有都有優(yōu)缺，人員在工作之中相互取長補短。可以很快的找出軟件中的缺陷。三個臭皮匠頂一個諸葛亮，一個經驗再豐富的測試不一定有三個水平一般的測從員發(fā)現(xiàn)的問題多。

　　2、人多的另一個好處是測試項目能可以在更快的時間內發(fā)現(xiàn)更多人缺陷?？偨Y一下就是更短時間內發(fā)現(xiàn)更多的問題。

再來說說這種方式的缺點：

　　1、一個人員一張嘴，人力成本很長（人員工資，人員平均時間投入，測試機等硬件資源投入）。

　　2、當同時需要測試多個項目中時，不要意思，按順序來，請在后面排好隊。

　　3、工作重復，同樣一個缺陷，很可以同時被所有測試員發(fā)現(xiàn)，或者叫重復率很高。

　　4、人員水平難以區(qū)分，在一個項目測試過程中，有的測人員可能一個缺陷也沒找到，有的測試人員卻發(fā)現(xiàn)了幾乎所有的問題。也許這個項目一個缺陷也沒找到的測試員在下個項目中卻發(fā)現(xiàn)了很多缺陷。

　　5、了漏測現(xiàn)象是整個測試團隊的責任。（這也不是明確的缺點，要看團隊的氛圍是積極的還是消極的。）

（也許，你說想照這么個分析法是不是漏了太多東西，也許你有興趣繼續(xù)看下去話，我后面會講解。）

好吧！集體測試缺點太多，就像國家成立初期的“吃大鍋飯”，肯定是阻礙發(fā)展的。那我們來看看幾種分工方式。

按測試內容分工

　　一個項目的測試包括文檔測試，易用性測試，邏輯功能測試，界面測試，配置和兼容等多個方面。我們可以根據(jù)人員的特點為每個人員分配不同的測試內容。

內容分工方式的優(yōu)點：

　　1、分工明確，每位人員都清楚自己的測試的內容重點。

　　2、責任到位，通過漏測的缺陷就可明確是誰的責任。

按測試流程劃分

　　我們的項目測試流程一般需要，制定測試計劃，編寫測試用例，執(zhí)行測試用例，輸出測試報告等工作，我們可以根據(jù)流程中的各個階段來進行劃分。

不同的人員負責不同測試階段的工作。

優(yōu)點：

　　1、流程清晰，就像瀑布試項目開發(fā)流程，不同階段的工作由不同的人員擔任。

　　2、劃分流程的每個階段難易程度和所需要的技能。

編寫測試計劃人員需要對整個項目的工作時間、資源分配，測試內容，實施過程有整體的把控能力。

用例辨析人員，需要對項目需求，測試方法，測試點有深入的了解。

用例執(zhí)行人員需要細心，使用缺陷系統(tǒng)，溝通，協(xié)助研發(fā)定位缺陷。

輸出測試報告人員需要對項目的測試過程，缺陷數(shù)量，類型，分布。用例執(zhí)行請況等進行統(tǒng)計。也可以由測試執(zhí)行人員擔任。

按項目模塊劃分

　　對中大型的項目，這種劃分就非常必要了，項目的模塊非常多，功能也非常多。不同的測試人員負責不同模塊的功能，這樣會使用測試工作變得更加清晰。

　　1、人員利用率高，為什么這么說呢??不同的人員負責的功能不一樣。工作就不會存在交叉與重復。

　　2、更容易挖掘深度缺陷，假如A人員今天測試這個功能，明天測試那個功能，他就不可以對被測功能內部邏輯與業(yè)務有深入有了解。找到的也只是很表面的缺陷。那么如果一個人員長期負責一個模塊的功能，那么就會更容易發(fā)現(xiàn)更有深度的缺陷。而往往深度的缺陷是致命的。

按照測試類型分工

　　我們知道軟件除了功能需要測試以外，軟件在編碼階段需要單元測試，接口測試等，在系統(tǒng)測試階段，為提高功能測試的效率，可能對某些模塊進行功能自動化，我們還要考慮軟件的性能、安全性等問題。這些類型也是我項目中最常見的分類。我們可以根據(jù)這些類型為測試人員分配測試工作。當然，其專業(yè)性對測試人員的要求也比較高。

這種分工方式的特點。

　　1、專業(yè)技能要求較高，在這些分類中除了手工測試要求較低外（表面看是這樣的），其它分類都需要較高的專業(yè)技能。例如，安全性測試需要掌握網(wǎng)絡協(xié)議，編程技術，腳本攻擊，SQL注入，漏洞分析等方面的技能。

　　2、不同分類之間交互性低，正國為不同分類需要的技能不同，雖然同為“測試”工作，但一個做單元測試的人就無法讓其去做性能測試。

上面分類方式的疑問

　　看了上面的幾種分工方式，你是不是每一種測試人員分工方式都似曾相識，但又沒有哪個公司是單一的按照上述某種分工作方式工作。

　　拿筆者目前所在的公司，是一個長期的互聯(lián)網(wǎng)產品，產品功能比較多，每位測試人員負責不同的功能模塊，測試員人員從測試計劃到測試報告都基本由一個人來完成。當然對于比較大和緊急的版本迭代，也會多人協(xié)作對版本進行測試（協(xié)作的方式一般更將版本功能再次細分到每個人員身上）。安全測試由專業(yè)的安全人員指導功能測試人員對自己負責的功能進行安全掃描與分析。有獨立的性能測試小組，對需要進行性能的產品版本進行性能測試。在獨立的功能自動化人員，對于適合自動化的功能進行自動化工作。

　　筆者公司的分工作方式幾乎包括了上面所有的分工方式。那么，我為什么要進行上面那么單一的分工方式劃分呢？這樣有助于我們理清對測試工作的各種分工方式。在實際的工作中，有大型項目，有小型項目，有客戶端軟件，也有互聯(lián)網(wǎng)產品，有短到幾天的項目，也有“永久”性的項目。有一次開發(fā)完成交付的，也有不段迭代更新的。根據(jù)項目的情況，我們可以可以選擇合適的分工方式來應用于項目中。

投入人員與發(fā)現(xiàn)缺陷的關系

　　在人員分工時，這也是一個必須也要考慮問題，對一個項目，投入的人員數(shù)量，投入的時間，與發(fā)現(xiàn)缺陷的數(shù)量有密切的關系。

投入時間與發(fā)現(xiàn)缺陷的關系：

　　在人員一定的情況下，投入的時間越多，發(fā)現(xiàn)的缺陷越多。但有一個規(guī)律，越到后期發(fā)現(xiàn)的新缺陷越少。假設軟件總缺陷為100個，第一周發(fā)現(xiàn)50個問題，第二新發(fā)現(xiàn)20個，第二周可能只發(fā)現(xiàn)10個新缺陷。而且一個必然的結果是，測試不可能發(fā)現(xiàn)所有的缺陷。

投入人員數(shù)量與缺陷的關系：

　　在時間一定有的情況下，投入的人員越多，發(fā)現(xiàn)的問題越多，從圖中可以看出，投入的人員越多，人員發(fā)現(xiàn)缺陷的重疊度越高。當然，你可以說，把每個人員要測試的內容劃分清晰就不會重疊了。做為一個系統(tǒng)的各個功能模塊，他們之間肯定存在必然的聯(lián)系。有可能A人員在測試時會涉及到B人員測試的功能，并且發(fā)現(xiàn)了問題，不管是告訴B缺陷還是A人員直接提交缺陷（當然，你也可以裝作沒看到，等著B去發(fā)現(xiàn)），這都算不可避免的重疊。

　　當然了，劃分更清晰的任務有效的降低重疊度。同步也降低了發(fā)現(xiàn)缺陷的數(shù)量，提高項目風險。除非投入更多的時間測試。這之間的關系，需要測試管理者認真去權衡。

　　在項目不緊急測試時間充分的情況下，可以投入更少的人員，延長測試時間發(fā)現(xiàn)更多的缺陷。?在項目緊急的情況下，需要投入更多的人員測試，以便盡快的發(fā)現(xiàn)更多的缺陷。在項目質量要求很高的情況下需要投入更多的人員與時間進行測試。在測試時間少，項目質量要求不高的情況下，可以投入較少的人員與時間進行測試。

--------------------------------------------------------------------------------------?

本文結束，但還有許多問題我沒有講清楚（或者，我目前還說不清楚）。

1、A人員發(fā)現(xiàn)了b功能模塊的缺陷（b模塊由B人員負責測試）應該如何處理？?自己提缺陷單?，告訴B人員，讓B人員提單。直接忽視，等著B測試人員去發(fā)現(xiàn)。

2、項目緊急情況，人員投入，時間投入，某些情況下，考慮某些模塊不進行測試。

3、測試人員的發(fā)展職業(yè)發(fā)展，這與測試人員的分工有著密切的聯(lián)系。

到了這里，關于軟件測試具體人員分工的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！