軟件測試人員分工

最近看了點敏捷測試的東西，看得比較模糊。一方面是由於沒有見真實的環境與流程，也許它跟本就沒有固定的模式與流程，它就像告訴人們要「勇敢」「努力」。有的人在勇敢的面對生活，有些人在勇敢的挑戰自我，有些人在勇敢的面對失敗與挫折。好吧！他們都實現了「勇敢」，勇敢究竟是如何去作，也許說不清楚。或者說每一個人都有本身的實踐方式。可是他們卻一樣靠着「勇敢」攻克不本身所面臨的困難。固然了，敏捷並非簡單一個詞語，通過前人的不探索與總結，還積累與總結至關多的經驗可供咱們借鑑與參考。

 

 　　按照本文的主題仍是來談談軟件測試人員的分工吧！主要來談傳統軟件測試過程當中的測試分工，由於敏捷測試中的測試分工我還沒弄明白究竟是腫麼個狀況。

 

集體測試

 

　　也許專業測試裏講這種方式，極可能不叫「集體測試」。由於我根據的本身的理解起了大概符合意思的名詞叫集體測試「集體測試」。

    　　就是測試模式就是，公司裏全部的測試人員抱成一團兒，來一個項目，全部測試人員就集中測試一個項目。

 

先說這種分工方式的優勢：

　　一、由於測試團隊的中每一個成員有都有優缺，人員在工做之中相互取長補短。能夠很快的找出軟件中的缺陷。三個臭皮匠頂一個諸葛亮，一個經驗再豐富的測試不必定有三個水平通常的測從員發現的問題多。

　　二、人多的另外一個好處是測試項目能能夠在更快的時間內發現更多人缺陷。總結一下就是更短期內發現更多的問題。

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

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

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

　　三、工做重複，一樣一個缺陷，很能夠同時被全部測試員發現，或者叫重複率很高。

　　四、人員水平難以區分，在一個項目測試過程當中，有的測人員可能一個缺陷也沒找到，有的測試人員卻發現了幾乎全部的問題。也許這個項目一個缺陷也沒找到的測試員在下個項目中卻發現了不少缺陷。

　　五、了漏測現象是整個測試團隊的責任。（這也不是明確的缺點，要看團隊的氛圍是積極的仍是消極的。）

（也許，你說想照這麼個分析法是否是漏了太多東西，也許你有興趣繼續看下去話，我後面會講解。）

 

好吧！集體測試缺點太多，就像國家成立初期的「吃大鍋飯」，確定是阻礙發展的。那咱們來看看幾種分工方式。

 

 

按測試內容分工

　　

　　一個項目的測試包括文檔測試，易用性測試，邏輯功能測試，界面測試，配置和兼容等多個方面。咱們能夠根據人員的特色爲每一個人員分配不一樣的測試內容。

內容分工方式的優勢：

　　一、分工明確，每位人員都清楚本身的測試的內容重點。

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

 

 

 

按測試流程劃分

 

　　咱們的項目測試流程通常須要，制定測試計劃，編寫測試用例，執行測試用例，輸出測試報告等工做，咱們能夠根據流程中的各個階段來進行劃分。

不一樣的人員負責不一樣測試階段的工做。

優勢：

　　一、流程清晰，就像瀑布試項目開發流程，不一樣階段的工做由不一樣的人員擔任。

　　二、劃分流程的每一個階段難易程度和所須要的技能。

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

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

用例執行人員須要細心，使用缺陷系統，溝通，協助研發定位缺陷。

輸出測試報告人員須要對項目的測試過程，缺陷數量，類型，分佈。用例執行請況等進行統計。也能夠由測試執行人員擔任。

 

 

按項目模塊劃分

 

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

　　一、人員利用率高，爲何這麼說呢? 不一樣的人員負責的功能不同。工做就不會存在交叉與重複。

　　二、更容易挖掘深度缺陷，假如A人員今天測試這個功能，明天測試那個功能，他就不能夠對被測功能內部邏輯與業務有深刻有了解。找到的也只是很表面的缺陷。那麼若是一我的員長期負責一個模塊的功能，那麼就會更容易發現更有深度的缺陷。而每每深度的缺陷是致命的。

 

 

按照測試類型分工

 

　　咱們知道軟件除了功能須要測試之外，軟件在編碼階段須要單元測試，接口測試等，在系統測試階段，爲提升功能測試的效率，可能對某些模塊進行功能自動化，咱們還要考慮軟件的性能、安全性等問題。這些類型也是我項目中最多見的分類。咱們能夠根據這些類型爲測試人員分配測試工做。固然，其專業性對測試人員的要求也比較高。

這種分工方式的特色。

　　一、專業技能要求較高，在這些分類中除了手工測試要求較低外（表面看是這樣的），其它分類都須要較高的專業技能。例如，安全性測試須要掌握網絡協議，編程技術，腳本***，SQL注入，漏洞分析等方面的技能。

　　二、不一樣分類之間交互性低，正國爲不一樣分類須要的技能不一樣，雖然同爲「測試」工做，但一個作單元測試的人就沒法讓其去作性能測試。

 

 

上面分類方式的疑問

 

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

　　拿筆者目前所在的公司，是一個長期的互聯網產品，產品功能比較多，每位測試人員負責不一樣的功能模塊，測試員人員從測試計劃到測試報告都基本由一我的來完成。固然對於比較大和緊急的版本迭代，也會多人協做對版本進行測試（協做的方式通常更將版本功能再次細分到每一個人員身上）。安全測試由專業的安全人員指導功能測試人員對本身負責的功能進行安全掃描與分析。有獨立的性能測試小組，對須要進行性能的產品版本進行性能測試。在獨立的功能自動化人員，對於適合自動化的功能進行自動化工做。

　　筆者公司的分工做方式幾乎包括了上面全部的分工方式。那麼，我爲何要進行上面那麼單一的分工方式劃分呢？這樣有助於咱們理清對測試工做的各類分工方式。在實際的工做中，有大型項目，有小型項目，有客戶端軟件，也有互聯網產品，有短到幾天的項目，也有「永久」性的項目。有一次開發完成交付的，也有不段迭代更新的。根據項目的狀況，咱們能夠能夠選擇合適的分工方式來應用於項目中。

 

 

---

 

投入人員與發現缺陷的關係

 

　　在人員分工時，這也是一個必須也要考慮問題，對一個項目，投入的人員數量，投入的時間，與發現缺陷的數量有密切的關係。

 

投入時間與發現缺陷的關係：

　　在人員必定的狀況下，投入的時間越多，發現的缺陷越多。但有一個規律，越到後期發現的新缺陷越少。假設軟件總缺陷爲100個，第一週發現50個問題，第二新發現20個，第二週可能只發現10個新缺陷。並且一個必然的結果是，測試不可能發現全部的缺陷。

 

投入人員數量與缺陷的關係：

　　在時間必定有的狀況下，投入的人員越多，發現的問題越多，從圖中能夠看出，投入的人員越多，人員發現缺陷的重疊度越高。固然，你能夠說，把每一個人員要測試的內容劃分清晰就不會重疊了。作爲一個系統的各個功能模塊，他們之間確定存在必然的聯繫。有可能A人員在測試時會涉及到B人員測試的功能，而且發現了問題，不論是告訴B缺陷仍是A人員直接提交缺陷（固然，你也能夠裝做沒看到，等着B去發現），這都算不可避免的重疊。

 

　　固然了，劃分更清晰的任務有效的下降重疊度。同步也下降了發現缺陷的數量，提升項目風險。除非投入更多的時間測試。這之間的關係，須要測試管理者認真去權衡。

　　在項目不緊急測試時間充分的狀況下，能夠投入更少的人員，延長測試時間發現更多的缺陷。 在項目緊急的狀況下，須要投入更多的人員測試，以便儘快的發現更多的缺陷。在項目質量要求很高的狀況下須要投入更多的人員與時間進行測試。在測試時間少，項目質量要求不高的狀況下，能夠投入較少的人員與時間進行測試。

 

-------------------------------------------------------------------------------------- 

 

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

一、A人員發現了b功能模塊的缺陷（b模塊由B人員負責測試）應該如何處理？ 本身提缺陷單 ，告訴B人員，讓B人員提單。直接忽視，等着B測試人員去發現。

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

三、測試人員的發展職業發展，這與測試人員的分工有着密切的聯繫。