成為測試主管第一步--制作測試流程

　　剛接到這個題目的時候也有一些犯難，：測試流程在不同的公司都會有微小的差異，而這些差異就有可能會決定測試流程是否是真正適用。在不同公司，不同的現狀情況引入適合的測試流程，就好像如同在《尋秦記》中提到的劍圣，他的三個徒弟劍法的風格類型完全不一樣同，這一點上，因材施教是非常重要的。其實在動筆撰寫本文的時候之前，我一直覺的感受到很大壓力很大，這其中最重要的原因莫過于怕誤人子弟了，。測試流程的制定不是一門科學，而有時看起來，它更像一門藝術，一個好的測試管理者其實在面對不同的公司，不同的研發階段，會采用不同的測試流程, ?；蚴嵌瑯拥臏y試流程，為了真正達到執行的效果，執行的方法也可能不一樣。

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

　　現在大多數測試人會犯一個共同的錯誤，往往——把流程設計的得很完美，但沒有可操作性很差，無法幫助對于軟件公司真正的目的——研發，并沒有起到應有的作用成功，久而久之測試的重要性就無從談起，測試團隊也漸漸在公司變成次要部門，成為打雜的得不到應有的重視。

　　在流程的設計過程中，最重要的問題在于是目當前項目的特點是什么，產品經常出什么樣的哪些問題，需要做什么怎樣的調整，現有測試團隊能不能做這樣的能否做作出調整，研發團隊是不是會不會能接收接受?

　　首先談談項目特點，按照項目特點，大致可以一般來說分成兩類，：

　　一種是長期進行的項目，這種項目有基本的框架，有核心的技術，應用比較穩定，這種項目要注重測試用例的積累與復用，同時也適合做單元測試，自動化測試的積累;

　　另一種是變更頻度更高，靈活，規模不大的項目，如果做自動化測試則會出現二次開發的時間大于手工測試的時間，而且項目結束后測試用例在長期中也沒有任何復用，在自動化測試人員普遍成本比較高的情況下，所以反而更適做功能測試。

　　雖然這兩者可能在長遠的目標上并不一致，但是引入測試管理平臺，從測試需求，、測試設計，、缺陷管理等方面入手則是測試團隊必備的技能。一個好的測試流程必需要有好的系統平臺的支撐，如果你把測試流程設計的得很完美，跟如同小學語文教科書一樣，但執行這樣的流程在起來現有的資源的情況下是未免不現實，倒并非說詳細的流程是洪水猛獸，只是對于一家軟件公司來說，資源的限制仍然是瓶頸所在的。，那流程也就沒有意義，一般來說一個執行的得好的測試流程必然會有好的平臺，就像我以前所在國內的幾家很有聲名的軟件公司，其測試平臺要不是么是采購的，就要么是自己開發的，但最主要是要適合自己一套適合自身特點的流程平臺起了非常積極的作用。在這里也給大家建議一些好的測試平臺，比如Mercury Interactive的Test Director，、IBM的TestManager,、Silk的一些缺陷管理平臺，這些平臺大多都能充分滿足測試團隊的要求其實都能滿足大家的要求。，當然，還有一些免費的開源工具也是可用的。但從長遠的角度看，我還是更建議大家讀者使用那些不僅僅只是滿足缺陷管理的工具，而是要應該選擇能集成測試需求，、測試設計，、測試用例，、缺陷管理的工具，最好也能滿足自動化的集成的，什么樣的產品能滿足就不多說了，免得有打廣告之嫌J，而商業軟件，如MI或IBM的產品在這些方面都有較好的表現。

　　項目特點決定流程的長期目標，但對于不同產品類型的公司，可能出現的問題往往會不一樣同。，比如說在金蝶的EAS-BossBOSS，、或是在金山做的游戲軟件，、亦或還是在阿里巴巴做電子商務，作為測試管理者，就要具體的問題都應該區別對待。

　　對于EAS-Boss這樣大型的軟件產品，團隊的規模比較大，核心技術比較穩定。但對于這樣的這樣的產品有以下一些特點：

　　由于產品比較大，手工測試時重復的工作量特別大;

　　引擎與產品框架比較穩定;

　　編譯與發布的流程比較固化;

　　由于團隊的規模比較大，接口特別多，集成測試風險特別高;。

　　這樣種產品的測試，主要是把大量的重復頻度比較高的功能測試轉化為自動化測試角本腳本，在開發過程中要注意，核心引擎與穩定的產品部分，盡可能使用測試框架形成單元測試集，;同時由于編譯與發布固化，適合做每日編譯, ，自動化的執行單元測試集與自動化的測試角本。在做這種測試流程時，同時還要注意引入強大的分析統計工具，比如代碼覆蓋與評審工具，內存檢查與性能函數分析工具，出錯表統計模塊，達到發布，、測試執行與評估自動化、一體化。由于進行每日集成，接口的問題可以盡早的暴露出來，避免了后期集成的風險，。

　　這一點每日集成對于大型項目非常重要。同時，由于測試的自動化，大部分的自動化測試角本在空閑的時間運行，測試組可以在進入手工測試時得到比較穩定的版本，及大極大的提升了團隊開發與測試的執行效率，。但然而在這樣的情況下，缺陷點是整個團隊對研發，、測試體系的技術要求特別高，其本上不亞于有時甚至難過做一個大型的項目。這樣的測試流程在，在中小團隊比較難以實現比較困難，而關鍵就在于無法降低的成本比較高。下圖就是一個穩定項目的測試流程圖。

　　游戲軟件產品的測試流程又有不同。當你去帶領這個測試團隊一個游戲團隊時，可能游戲核心引擎應該是比較相對穩定的，而游戲內部的故事情節可能會不斷的變化，。這時你可把一些更加穩定的程序做成比較穩定的自動化回歸測試，同時加強對不斷變化的游戲情節的功能測試，同時注意這些功能是不是否會影響到其它相關的模塊。同時在因此，游戲測試的過程中還有一些比較有其特殊性，主要表現以下幾點：

原文轉自：http://www.kjueaiud.com