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

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

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

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

　　在流程的設計過(guò)程中，最重要的問(wèn)題在于是目當前項目的特點(diǎn)是什么，產(chǎn)品經(jīng)常出什么樣的哪些問(wèn)題，需要做什么怎樣的調整，現有測試團隊能不能做這樣的能否做作出調整，研發(fā)團隊是不是會(huì )不會(huì )能接收接受?

　　首先談?wù)勴椖刻攸c(diǎn)，按照項目特點(diǎn)，大致可以一般來(lái)說(shuō)分成兩類(lèi)，：

　　一種是長(cháng)期進(jìn)行的項目，這種項目有基本的框架，有核心的技術(shù)，應用比較穩定，這種項目要注重測試用例的積累與復用，同時(shí)也適合做單元測試，自動(dòng)化測試的積累;

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

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

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

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

　　由于產(chǎn)品比較大，手工測試時(shí)重復的工作量特別大;

　　引擎與產(chǎn)品框架比較穩定;

　　編譯與發(fā)布的流程比較固化;

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

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

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

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

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