測試管理方法與技巧.

1、測試管理方法與技巧.測試管理中的隱形指揮棒：測試組織模式的制定 很多公司都宣稱，員工是最重要的資產(chǎn)。在測試管理中，關于測試團隊的管理同樣是一件重要方面。人是萬物之靈，每個人都有自己獨特的一面，如何才干讓員工充份地發(fā)揮自己的潛能為公司服務，在個人的職業(yè)生涯發(fā)展道路上更順暢，同時也給公司帶來更多的效益，最終達到一個雙贏的目的，這是職場人士及公司經(jīng)營的共同目標。 測試團隊的管理是測試管理的基礎，不同的組織模式，決定著測試團隊在公司及在項目中的位置。測試的組織模式就像一根隱形的指揮棒，而指揮官則是公司的管理層。 1以開發(fā)為核心的基礎模式 以開發(fā)為核心，測試是開發(fā)隊伍中的一部分。測試負責人向開發(fā)經(jīng)理匯報

2、，多見于規(guī)模不大的一些小公司。在這種組織中，開發(fā)工程師除了負責制定的實現(xiàn)外，還必需參加編寫必需求，或者必需求直接由開發(fā)主管，甚至是開發(fā)經(jīng)理編寫，即某些開發(fā)人員承當著雙重或多重的角色。例如，開發(fā)經(jīng)理也是項目經(jīng)理，帶著大家一起做一個項目，在公司的發(fā)展初期常會有這種狀況。 2以開發(fā)為核心的擴大模式 隨著公司的發(fā)展壯大，項目的開發(fā)必需求增加，上面的模式已不夠以支持多項目并行開發(fā)的必需求，必需要把某些工作從某些身兼數(shù)職的人身上剝離出來，獨立成立某專業(yè)組，使分工變細，更明確，更清楚。即以開發(fā)為核心的組織擴大模式。在此模式中，成立了項目管理組，軟件必需求組，軟件必需求組向開發(fā)經(jīng)理匯報，項目管理組通常向更高一

3、級，如總監(jiān)級匯報。 測試計劃的風險和規(guī)避 測試計劃風險和規(guī)避 1、測試準備進度延誤 風險分析：如果計劃執(zhí)行過程中，測試準備階段的測試必需求分析到期未完成、測試必需求評審未通過、測試制定到期未完成以及測試制定評審未通過，那么就會造成計劃進度延誤，影響后續(xù)測試工作的展開。 規(guī)避方法：必需要測試人員在進行測試準備的時候，嚴格按照既定計劃執(zhí)行，如果出現(xiàn)上述狀況，則測試人員依據(jù)實際影響狀況，申請加班來確保進度。如果進度被延誤較多，則必需要通知所有項目參加人員和領導，并申請調(diào)整測試計劃。 2、BVT測試未通過 風險分析：如果開發(fā)提交的測試版本，執(zhí)行BVT測試未通過，則版本必需打回重新提交，這樣可能造成計劃

4、進度延誤，影響后續(xù)的測試工作安排。 規(guī)避方法：在提交測試版本前，開發(fā)應該抽出時間進行自測，如果沒有進行單元測試和集成測試，則必需要安排進行。如果到期提交的版本被測試打回，為了不影響整體計劃的進度，必需要開發(fā)人員適當安排增加人手或者加班。 3、開發(fā)進度延誤 風險分析：如果開發(fā)到版本公布時不能按時公布測試版本，則造成后續(xù)測試工作的安排順延，從而形成測試計劃執(zhí)行的風險。 規(guī)避方法：請開發(fā)組在項目進行過程中嚴格控制進度，如果有推遲的風險請馬上通知測試人員，協(xié)商解決。如果到期仍然不能按時公布，則測試人員必需要申請修改測試計劃，并通知所有相關人員。如果版本公布時間不能修改，則測試人員必需要申請加班，并通知

5、主管領導。 4、難以修復的缺陷造成測試用例阻礙 風險分析：如果測試執(zhí)行過程中，被測試版本發(fā)現(xiàn)難以修復的bug，造成被測試模塊的功能阻礙無法執(zhí)行測試，測試進度安排受到影響。 規(guī)避方法：出現(xiàn)這樣的問題，必需要開發(fā)人員全力配合測試，及時修改出現(xiàn)的問題。如果不能完全修復，也要給測試提供可以測試被阻礙模塊的接口。 5、未修改缺陷過多導致測試不能結束 風險分析：在測試將要結束的時候，如果當前版本的現(xiàn)存缺陷過多，被測試版本的各個指標無法達到測試停止標準，那么測試不能結束，將會影響后續(xù)版本上線的進度。 規(guī)避方法：測試在執(zhí)行過程中，必需要不斷的監(jiān)控被測試項目的現(xiàn)存缺陷狀況，如果發(fā)現(xiàn)缺陷數(shù)量堅持一定數(shù)量或者不斷上

6、升，則必需要馬上和項目開發(fā)組以及領導進行溝通，共同處理。如果將近測試版本公布日期仍然不能有所改善，則必需要申請版本延期公布。 6、其他緊急項目抽調(diào)人手 風險分析：如果在項目開發(fā)過程中或者測試執(zhí)行過程中，出現(xiàn)項目開發(fā)人員或者測試人員被緊急項目調(diào)用，無法按照計劃安排參加項目，那么會造成相應的計劃進度延誤。 規(guī)避方法：出現(xiàn)上述狀況，必需要通知所有項目參加人員，共同協(xié)商解決。如果沒有解決方案，則必需要馬上上報領導，申請加班或者申請進度延期。 測試工作的不利環(huán)境應對措施 1測試流程存在問題，沒有版本控制 沒有版本管理，導致工作混亂，測試人員的工作變成沒計劃，沒管理。比如新發(fā)現(xiàn)的BUG，無法去分析，是修改

7、帶來的，還是原來就有的，只是沒測試到；另外，測試、修改Bug、復測的時間混在一塊，分不清是誰的效率低；還有，會增加測試人員工作量。開發(fā)人員只要改代碼，就會提交到SVN中，頻繁的更改，測試輪次就會亂，且容易助長發(fā)人員，自己修改后不測試，就扔到測試人員手中。 建議：建立一個群。凡是開發(fā)有任何更新必需發(fā)群消息出來，測試員對更新狀況做出記錄。這樣在一定程度上做到了版本控制。 建議：這是配置管理員的專職工作，但當前公司沒配備，就必需要研發(fā)經(jīng)理控制一下，什么時候公布下一個版本到測試人員那，或是定在每周五多長時間，可以視狀況定公布一個新版本測試，這樣也促使開發(fā)人員盡量在下一版本前修改優(yōu)先級高的BUG。 2不

8、寫測試用例，想到哪測到哪，測試很難將功能點覆蓋全面。由于測試都是臨時通知，沒有時間寫測試用例。 建議：在沒必需求分析的狀況下，可以按功能菜單劃化測試必需求，理清功能點，有了測試必需求分解，可以邊測試邊寫測試用例。這么做的好處是，可以慢慢積存用例，如中間有測試人員離職，也還有用例在。 3關于bug是否必需要修改的問題 用極限值、在輸入數(shù)字的地方輸入字母出現(xiàn)的問題，開發(fā)人員很反感，他們不愿意修改這樣的問題，只想修改正常操作出現(xiàn)的問題，甚至他們的主管也是這樣認為，認為客戶不會那樣操作，讓我們測試人員很苦惱。 我們往往在這樣的bug上存在爭議：出現(xiàn)頻率很高，只要運行程序就出現(xiàn)。但不是致命的bug， 不

9、影響功能，修改起來也很比較容易。 例如打開一個頁面時，只是在左下角報腳本錯誤，功能照樣用。像這樣的Bug，開發(fā)人員心情好就改，心情不好就不改。我們測試人員關于這種bug是傾向于修改的 建議：把問題以郵件的形式反饋給開發(fā)并抄送一份給領導。同時把要不要修改的權力交給領導并暗示他，如果是誰說的不改以后出了問題誰來承當責任。 如何估算剩余bug的數(shù)量 魚塘法是用來估算魚塘中魚的數(shù)量的：從魚塘中撈上來比如100條魚，為每條魚都作上標記，說明這些魚是曾經(jīng)被捕捉過的，然后把這些魚放回魚塘中去，過一段時間后主要是想讓被捕到的魚盡量均勻的分布到魚塘中去，再補100條上來，檢查有多少條是標記的，比如是50條，那么

10、就可以估算出魚塘中的魚的總數(shù)為100*100/50=200條了。 這種思路也可以借鑒到bug的估算中來：讓兩個測試人員A和B同時獨立對同一被測對象進行測試，自己使用自己的思路和方法。測試結束后，A發(fā)現(xiàn)了m個bug，而B發(fā)現(xiàn)了n個bug，兩人相同的bug有k個，那么總的bug數(shù)就可以估算成m*n/k了。 當然這種思路有其前提條件： 1、采樣要足夠多，也就是說發(fā)現(xiàn)的bug數(shù)不能太少，要和總的bug數(shù)具有可比性，否則這種基于采樣的思路就行不通了； 2、測試人員的水平要比較接近，不能相差太大，不然很容易出現(xiàn)，一個人發(fā)現(xiàn)的bug是另一個人的子集，那就沒意思了； 3、針對的被測對象一定要完全相同，不能有b

11、ug修復的過程，否則兩個人所針對的樣本空間就不一樣了，那樣這種思路也就失效了。 項目經(jīng)理問：為什么總是只有我在加班掛包袱現(xiàn)象最近和一位項目經(jīng)理聊天。這位PM之前是個技術大牛，沒什么搞不定的東西，而且做事也認真，也賣命。領導沒理由不提拔這種牛人。所以，這個項目讓這哥們當PM。 聊著聊著，這位牛人發(fā)出一聲感慨，現(xiàn)在的員工不好帶啊，天天到了晚上7點，就只剩我和另一個小組長了。項目組10多個人，都跑的精光。 我樂了。其實這種狀況，我也是碰到過的，在我?guī)У牡谝粋€項目，也是類似的狀況。我不敢武斷的下決定，就跟他多聊了幾句。 問：那你大概幾點下班的？ 答：天天都11點之后。 問：任務很重嗎？ 答：其實也不重

12、。 問：那些走了的人，你沒有安排任務給他們嗎？ 答：安排不了。 問：為什么不能給他們安排任務呢？ 答：他們搞不定。 問：為什么搞不定?。?答：我也不知道。我嘗試給他們分配了任務，但是到頭來，那些問題又到我和XXX另一個小組長手上了。 后面我也不必需要多問了，大概就是我估計的狀況。 我把這種狀況，稱之為：掛包袱現(xiàn)象。 分析 為什么叫包袱現(xiàn)象呢？我們可以這么來描述。 每個項目，其實是一個大包袱。一個公司有大大小小的許多包袱，每個包袱合理完整的解開了，里面就有利潤。但是如果包袱解開不正確，就會減少利潤，甚至破壞利潤。 那么每個包袱，都交給一個項目經(jīng)理來解。項目經(jīng)理帶領一幫兄弟，負責把這個包袱合理的解

13、開。而包袱是可分解的，也就是說，包袱可以分成大大小小的子包袱，如何解開子包袱，也是每個項目組成員的工作。 關于一個項目經(jīng)理來說，最重要的工作，是如何把大包袱，合理的分解成小包袱，然后合理的分配給項目組成員來解，并且必需要隨時監(jiān)控小包袱的解開狀況，一旦發(fā)現(xiàn)有小包袱解開的步驟不合理，馬上予以干預；如果發(fā)現(xiàn)有大包袱分解方式不合理，也必需及早的改正。 項目經(jīng)理最重要的工作是不是，自己親自擼袖子去解包袱呢？ 答案很容易說，當然不是。但是，一般初次做PM的人，就容易走進這個圈套。 例子 我們來說一個例子吧。 項目經(jīng)理甲，在項目一開始分配任務的時候，這么安排的： A同學，你做#1模塊；B同學，你做#2模塊；

14、C同學，你做#3模塊。剩下最難的#4模塊和framework我來做。要求5天完成。 OK，貌似挺合理的，ABC三位工程師就去干活了。 A同學比較聰慧，第一天就完成了50%，下班就走了。第二天就做完了，下班也走了，然后就優(yōu)哉游哉的玩了三天，等著最后的時候昂首挺胸的匯報佳績。 B同學很賣力，但是偏偏#2模塊比較麻煩。B同學第一天完成了50%，加班到8點下班了。第二天碰到一個難題，搞不定了。于是向甲求助。甲無奈去幫B同學分析了一下午，終于把這個問題解決了。這時甲延遲半天。第三天，B同學又碰到一個難題，再次請教甲，甲分析了一上午，搞不定了，于是扔下一句話：這個等我有空來看吧。于是，B同學第三天努力的分析問題，加班到10點。第四天，B同學想著反正甲答應解決的，于是在下班后就回家了，也沒有加班。 C同學是個新人，關于環(huán)境也不熟悉。第一天熟悉了一天開發(fā)環(huán)境。第二天毛毛糙糙的做了一點東西，感覺還不錯。于是，第三天第四天，不用加班就把東西做出來了。第五天，C同學很開心的匯報說，工作做完了。 第五天下班的時候，甲自己已經(jīng)延遲了2天的進度，其中