1、成為測試主管第一步制定測試流程發布時間: 2011-5-06 10:51 作者: 陳衛俊 來源: 51testing軟件測試網采編剛接到這個題目的時候也有一些犯難：測試流程在不同的公司都會有微小的差異，而這些差異就有可能會決定測試流程是否是真正適用。在不同公司，不同的現狀情況引入適合的測試流程，就好像如同在尋秦記中提到的劍圣，他的三個徒弟劍法的風格類型完全不一樣同，這一點上，因材施教是非常重要的。其實在動筆撰寫本文的時候之前，我一直覺的感受到很大壓力很大，這其中最重要的原因莫過于怕誤人子弟了。測試流程的制定不是一門科學，而有時看起來，它更像一門藝術，一個好的測試管理者其實在面對不同的公司，不同

2、的研發階段，會采用不同的測試流程，或是而同樣的測試流程，為了真正達到執行的效果，執行的方法也可能不一樣。實施測試流程一般都是有兩個原因：一是軟件質量出現的了問題，雖然在某種程度上已經得到解決，但仍需要通過測試，把預防措施的方法找到并固化下來；還有另一個原因則種是軟件研發的規模壯大，要求做的在流程上更加清晰，可靠更好。我個人從我自己的角度出發最怕以下一某些情況是讓人非常頭疼的：一種情況是，是今天剛看了一本書，被告知說這樣做是規范應該這樣制定的，而明天就要引入進來，完全不考慮公司的實際情況；另一種情況是“蘇聯模式”，二是那種即某某大公司的測試流程如此制定是這樣做的，我們也要采用相同的方法這樣。其實

3、流程沒有最好的，只有適合自己的，規范的測試流程不一定會幫助研發成功，反而在某些情況下會弄不好羈絆到自己自己的工作。 現在大多數測試人會犯一個共同的錯誤，往往把流程設計的得很完美，但沒有可操作性很差，無法幫助對于軟件公司真正的目的研發，并沒有起到應有的作用成功，久而久之測試的重要性就無從談起，測試團隊也漸漸在公司變成次要部門，成為打雜的得不到應有的重視。 在流程的設計過程中，最重要的問題在于是目當前項目的特點是什么，產品經常出什么樣的哪些問題，需要做什么怎樣的調整，現有測試團隊能不能做這樣的能否做作出調整，研發團隊是不是會不會能接收接受？首先談談項目特點，按照項目特點，大致可以一般來說分成兩類：

4、 一種是長期進行的項目，這種項目有基本的框架，有核心的技術，應用比較穩定，這種項目要注重測試用例的積累與復用，同時也適合做單元測試，自動化測試的積累； 另一種是變更頻度更高，靈活，規模不大的項目，如果做自動化測試則會出現二次開發的時間大于手工測試的時間，而且項目結束后測試用例在長期中也沒有任何復用，在自動化測試人員普遍成本比較高的情況下，所以反而更適做功能測試。 雖然這兩者可能在長遠的目標上并不一致，但是引入測試管理平臺，從測試需求、測試設計、缺陷管理等方面入手則是測試團隊必備的技能。一個好的測試流程必需要有好的系統平臺的支撐，如果你把測試流程設計的得很完美，跟如同小學語文教科書一樣，但執行這

5、樣的流程在起來現有的資源的情況下是未免不現實，倒并非說詳細的流程是洪水猛獸，只是對于一家軟件公司來說，資源的限制仍然是瓶頸所在的，那流程也就沒有意義，一般來說一個執行的得好的測試流程必然會有好的平臺，就像我以前所在國內的幾家很有聲名的軟件公司，其測試平臺要不是么是采購的，就要么是自己開發的，但最主要是要適合自己一套適合自身特點的流程平臺起了非常積極的作用。在這里也給大家建議一些好的測試平臺，比如mercury interactive的test director，、ibm的testmanager，、silk的一些缺陷管理平臺，這些平臺大多都能充分滿足測試團隊的要求其實都能滿足大家的要求。，當然，

6、還有一些免費的開源工具也是可用的。但從長遠的角度看，我還是更建議大家讀者使用那些不僅僅只是滿足缺陷管理的工具，而是要應該選擇能集成測試需求、測試設計、測試用例、缺陷管理的工具，最好也能滿足自動化的集成的，什么樣的產品能滿足就不多說了，免得有打廣告之嫌j，而商業軟件，如mi或ibm的產品在這些方面都有較好的表現。 項目特點決定流程的長期目標，但對于不同產品類型的公司，可能出現的問題往往會不一樣同。比如說在金蝶的eas-bossboss、或是在金山做的游戲軟件、亦或還是在阿里巴巴做電子商務，作為測試管理者，就要具體的問題都應該區別對待。對于eas-boss這樣大型的軟件產品，團隊的規模比較大，核心

7、技術比較穩定。但對于這樣的這樣的產品有以下一些特點： 由于產品比較大，手工測試時重復的工作量特別大； 引擎與產品框架比較穩定； 編譯與發布的流程比較固化； 由于團隊的規模比較大，接口特別多，集成測試風險特別高。這樣種產品的測試，主要是把大量的重復頻度比較高的功能測試轉化為自動化測試角本腳本，在開發過程中要注意，核心引擎與穩定的產品部分，盡可能使用測試框架形成單元測試集；同時由于編譯與發布固化，適合做每日編譯， ，自動化的執行單元測試集與自動化的測試角本。在做這種測試流程時，同時還要注意引入強大的分析統計工具，比如代碼覆蓋與評審工具，內存檢查與性能函數分析工具，出錯表統計模塊，達到發布、測試執行

8、與評估自動化、一體化。由于進行每日集成，接口的問題可以盡早的暴露出來，避免了后期集成的風險。 這一點每日集成對于大型項目非常重要。同時，由于測試的自動化，大部分的自動化測試角本在空閑的時間運行，測試組可以在進入手工測試時得到比較穩定的版本，及大極大的提升了團隊開發與測試的執行效率。但然而在這樣的情況下，缺陷點是整個團隊對研發、測試體系的技術要求特別高，其本上不亞于有時甚至難過做一個大型的項目。這樣的測試流程在，在中小團隊比較難以實現比較困難，而關鍵就在于無法降低的成本比較高。下圖就是一個穩定項目的測試流程圖。 游戲軟件產品的測試流程又有不同。當你去帶領這個測試團隊一個游戲團隊時，可能游戲核心引

9、擎應該是比較相對穩定的，而游戲內部的故事情節可能會不斷的變化。這時你可把一些更加穩定的程序做成比較穩定的自動化回歸測試，同時加強對不斷變化的游戲情節的功能測試，同時注意這些功能是不是否會影響到其它相關的模塊。同時在因此，游戲測試的過程中還有一些比較有其特殊性，主要表現以下幾點： 服務器的穩定性，網絡流量，與安全是游戲最至關重要的（往往有很多游戲不是不好玩，而是太不穩定）； 游戲由于有及時的即時更新，會經常在同時修改缺陷的時候，還在同一模塊下增加新功能； 好的網絡游戲開發，其的功能必然會是迎合玩家的需求（游戲性分析）。對于游戲軟件產品來說，這些需要特別注意重點控制的點關鍵，要求測試團隊必需要加強

10、以下幾個方面，性能測試，代碼的融合、相關性影響面的判斷、版本的變更與控制，還有游戲性的分析與測試。性能測試主要加強以下幾點，則需要注意在并發下服務器的穩定性監控、網絡流量與游戲客戶端在大場面下的表現；而版本控制在游戲軟件的過程中，其意義更多則會避免已經改了的問題重復出現，或是改了更新上去問題還是存在，如何高效的合并代碼、合成游戲資源、圖片與角本腳本還是一個比較難度很高的事情，尤其涉及到多個部門；而游戲性測試主要是避免那種些與游戲風格相背的情況，或是開發團隊累死累活拼命完成得功能性任務做出的功能沒有可延續性。 性能測試與版本控制，在大多數軟件的測試流程中都會涉及，但是在不同的軟件產品/項目中都有

11、其特點。一般屬于通用軟件測試流程的部分，但而游戲性測試則需要對游戲感覺很好有比較深刻的了解，并由真正懂懂得的玩家的人來擔任。某些時候，他甚至可以不是一個很好的軟件測試人員，但他一定是一個真正懂游戲的人，這里有一些扯遠，但這里，本文稍后一節，將我會在后面會強調人的因素也決定了流程的實施。 下圖是游戲迭代開發模型圖如果你去做電子商務，或是做門戶，這些項目的適時性，高性能，復雜的功能會給你更高的技術要求，更高強的時間性效率挑戰，對測試的設計、執行、與性能測試提出更高的要求。其實在大多數互聯網公司經常會出現這樣的情況：剛出去的功能又撤下來修改，或是性能達不到要求仍需要又要調優。許多一些人都會犯這樣一個

12、錯，認為測試的時間不夠，就只要測試執行，而忽略了其他幾個環節就可以了，不做細致的分析與設計，為后續工作帶來很大壓力。其實，一個充分測試過的有質量保證的產品，可以減輕客服、市場、等各方面很多的壓力。產品在用戶和研發之間，反復，幾次不如晚一些上提供給用戶。從另外一方面看，這還需要測試主管能頂住某些壓力。時間緊迫當然這不是理由，如何在流程上保證測試的需求分析、用例的設計與研發在開發時同步進行是最重要的，這時你要加強早期的測試介入，明確卡住需求確認這一部分。這樣，在研發進入開發階段時，測試團隊也能進入測試設計。當研發開發完成時，你測試團隊事實上已經其本基本上完成了大部分的測試設計，并準備進入測試執行。

13、不要在開發提交后再去想如何測測試，抱怨之聲也就不絕于耳了。這樣才可能測試好一個時間比較緊的項目不管在用于測試的時間上，還是測試的質量上都無法滿足要求。，同時測試設計的很好，不僅可以節約測試執行的時間，也可以在反復提交的過程中，由于用例執行的一致性，保證了測試在多次的執行中的質量。同時也有發布的標準，一是缺陷的情況，二是用例的執行與覆蓋。同時由于研發給的測試時間比較緊，所以有兩件事情就必需作做好：一是明確產品提交測試時間，并在研發延遲時給自己爭取時間；二是在質量達不到要求的情況下，時間及時的做出反應，不要到最后在研發不了解項目質量的情況下建議研發延遲項目。為了達到上面的要求你必需要一個很好的測試

14、平臺，把設計，測試用例管理，執行與用例的聯動，缺陷管理與報表統計打通，盡可能的利用平臺解決事務性工作，降低流程執行的成本。也就是說，既讓測試人員可以集中精力去測試，同時又能夠讓研發管理人員隨時獲取正在進行測試的進度與質量。當這些工作做到透明化時以后，就算讓研發延遲發布，研發部門也會接收接受。下圖是這一階段的大致流程 在這里可以跟大家說一下，我就曾經在產品發布權限不在測試這里部門的情況下，成功的讓研發決定推遲發布了大約一半以上的項目。大多數的測試部門主管，很難頂住來自項目/技術經理的壓力是有理由的，因為他們根本不了解你做了哪些工作。有時候一些情況下，看似不可能的事情任務要想做成完成，關鍵要看在于

15、事情的技巧。流程表示了只是一個大方向的東西，而且，你永遠也無法將責任推卸給流程也許是對的，更多情況下，作為測試主管，需要但將做事的方法與風格可以影響到推廣到測試流程的推廣中。 在測試互聯網項目時，還有一個更重要的就是如何保證性能。 也許大家會說不就是性能測試并不是單獨存在的。其實不是完全正確，如果有充足的優秀高手人力資源做性能測試當然很好，但性能測試也不能完全保證所有的項目完全沒有性能問題都完美無缺，因此，項目投入期間，同時性能測試是一個這個費時費力的工作，所以往往都是一般在資源不足的情況下開展的。作為測試主管，更應該，要學會判斷那些相對更加重要的問題項目影響面會更廣，需要集中做性能測試。這時

16、你也許會問，那么會有人問其它相對不太重要的項目與問題怎么辦，？其實做過性能調優的人都知道，大部分的性能問題都是由于一兩個弱智的sql語句導致的，所以可以從流程上加強對sql查詢語句在i/o問題的跟蹤與評審，從而避免大部分性能問題。 上面分析了不同公司根據上文的分析，不同類型的產品在測試流程上的是有很大差異的。這時，也許大家你也許可以把握測試流程大的方向了，但真正是否適合現有的測試團隊與研發團隊，則仍需要精心的調整。當我遇到問題的時候，第一時間往往有時候不是去尋找流程不對的問題，而是通過現有資源與執行的方法可能需要著手來微調一下你的測試流程，直到發現問題的所在，并紀錄下來，最后整合到原來設定的流

17、程中。 這樣的情況大概常常發生：比如說在需求上的處理，可能會有很多的測試人員會經常指責需求人員撰寫的文檔非常粗糙不詳細，無法進行測試。好像在我的記憶中，需求人員常常就是被罵的得灰頭土臉，但是經過這些年在測試崗位上的工作，我才漸漸發現，其實有時候需求人員更需要鼓勵鼓勵是比職責更加有效的工作方式。這可能是一個放之四海皆準的工作態度，指責只能加深對立。其實在驗收需求時，由于當時大家也只是知道一個大概我們的需求人員也只能從大致上把握核了解，可能大多數情況下是：原則上沒有問題就通過了。但然而，這種不負責任的態度卻是給我們在做的測試工作帶來相當多的麻煩。也只有在這樣的時候，這些問題才能真正暴露出來，從而使

18、測試設計時就會發現很多問題并沒有寫清楚。一般情況下，很多測試人員這時就多半會放棄手邊的工作，并消極地認為認為無法做工作無法繼續下去。，等東西出來，并將問題最終歸結到是需求給的不詳細，而大加指責。 從我對測試主管工作的記事以來，就在印象中保留了這樣的一幕。記的剛進一家公司時，我團隊中的人員就開始經常會有下屬跟我說抱怨，公司的需求工程師讓我們太失望了。需求如何如何不好，然而，多少有些經驗的我，當時我是把幾家國內我服務過的頂尖公司情況作了一個簡單的對比，的需求跟公司的需求人員的需求做了比較這時才發現，發現，原來我們公司的需求人員還是做的得不錯的。讓測試人員把心態調整過來是測試主管的另外一件事。試問，

19、如果是你做需求作為需求工程師，是否會比他們做的好嗎得更好？有了這樣的基調，就可以讓然后建議測試人員去總結不清楚的地方，給需求人員一個相對比較具體和明確的意見，這樣順利的了解了需求。 其實有時候不是流程不對流程在這其中并沒有太多值得指責的地方，而是相互的理解與支持，換位思考而對流程的執行態度，卻是更加關鍵的。我們不得不學會如何換位思考，并更多地從他人的角度來看待這些問題。 同樣的問題還出現在還有需求變更上，很多測試人過不了這一關。總是他們指責研發人員，讓研發那些本來就已經惱火的軟件工程師更加火冒三丈。換位思考一番，其實不難了解，其實需求變更對研發工程師來說是更大的麻煩。他們需要修改設計、代碼，相

20、較而測試只要需改測試用例，他們的工作確實更加麻煩。簡單來說，就ok了，其實大家要分析什么樣的需求變更最可怕，而不是眉毛胡子一把抓，其實測試對需求變更并不可怕，怕的是只有在提交時才發現，導致測試時間不夠，才會真正讓測試人員心慌。這時需要從研發流程上保證變更及時的通知到測試就可以了行。也許有人會說你也需要說，說的倒很容易，如果研發不按照你的要求做怎么辦！其實這里你只要用我所采用的方法是用數據說話，在項目進行時統計發生過多少次這樣的事情，讓研發管理層知道，讓項目組之間有一個比較。一方面，如果是一家公司重視質量的公司，必然會引起重視；另一方面，從質量管理部門角度本身出發，也應該推動公司重視質量，隨著時間的增加，需求變更給測試人員的反饋一定會有下降的趨勢。關鍵是測試不能抓住雞毛就一直揪著不放寬容一些來看待身邊的同事，要允許別人他們犯錯，對于解決問題本身