前言：本站為你精心整理了軟件工程測試范文，希望能為你的創(chuàng)作提供參考價值，我們的客服老師可以幫助你提供個性化的參考范文，歡迎咨詢。

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

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

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

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

首先談?wù)勴椖刻攸c，按照項目特點，大致可以一般來說分成兩類，：

一種是長期進行的項目，這種項目有基本的框架，有核心的技術(shù)，應(yīng)用比較穩(wěn)定，這種項目要注重測試用例的積累與復(fù)用，同時也適合做單元測試，自動化測試的積累；

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

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

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

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

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

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

編譯與的流程比較固化；

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

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

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

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

服務(wù)器的穩(wěn)定性，網(wǎng)絡(luò)流量，與安全是游戲最至關(guān)重要的，（往往有很多游戲不是不好玩，而是太不穩(wěn)定）；

游戲由于有及時的即時更新，會經(jīng)常在同時修改缺陷的時候，還在同一模塊下增加新功能；

好的網(wǎng)絡(luò)游戲開發(fā)，其的功能必然會是迎合玩家的需求(游戲性分析)。；

對于游戲軟件產(chǎn)品來說，這些需要特別注意重點控制的點關(guān)鍵，要求測試團隊必需要加強以下幾個方面，性能測試，代碼的融合、相關(guān)性影響面的判斷、版本的變更與控制，還有游戲性的分析與測試。性能測試主要加強以下幾點，則需要注意在并發(fā)下服務(wù)器的穩(wěn)定性監(jiān)控，、網(wǎng)絡(luò)流量與游戲客戶端在大場面下的表現(xiàn)。；而版本控制在游戲軟件的過程中，其意義更多——則會避免已經(jīng)改了的問題重復(fù)出現(xiàn)，或是改了更新上去問題還是存在，如何高效的合并代碼，、合成游戲資源、圖片與角本腳本還是一個比較難度很高的事情，尤其涉及到多個部門。；而游戲性測試主要是避免那種些與游戲風(fēng)格相背的情況，或是開發(fā)團隊累死累活拼命完成得功能性任務(wù)做出的功能沒有可延續(xù)性。

性能測試與版本控制，在大多數(shù)軟件的測試流程中都會涉及，但是在不同的軟件產(chǎn)品/項目中都有其特點。一般屬于通用軟件測試流程的部分，但而游戲性測試則需要對游戲感覺很好有比較深刻的了解，并由真正懂懂得的玩家的人來擔(dān)任，。某些時候，他甚至可以不是一個很好的軟件測試人員，但他一定是一個真正懂游戲的人，這里有一些扯遠，但這里，本文稍后一節(jié)，將我會在后面會強調(diào)人的因素也決定了流程的實施。

下圖是游戲迭代開發(fā)模型圖

如果你去做電子商務(wù)，或是做門戶，這些項目的適時性，高性能，復(fù)雜的功能會給你更高的技術(shù)要求，更高強的時間性效率挑戰(zhàn)，對測試的設(shè)計，、執(zhí)行，、與性能測試提出更高的要求。其實在大多數(shù)互聯(lián)網(wǎng)公司經(jīng)常會出現(xiàn)這樣的情況：剛出去的功能又撤下來修改，或是性能達不到要求仍需要又要調(diào)優(yōu)。許多一些人都會犯這樣一個錯，認為測試的時間不夠，就只要測試執(zhí)行，而忽略了其他幾個環(huán)節(jié)就可以了，不做細致的分析與設(shè)計，為后續(xù)工作帶來很大壓力。其實，一個充分測試過的有質(zhì)量保證的產(chǎn)品，可以減輕客服，、市場，、等各方面很多的壓力。產(chǎn)品在用戶和研發(fā)之間，反復(fù)，幾次不如晚一些上提供給用戶。從另外一方面看，這還需要測試主管能頂住某些壓力。時間緊迫當然這不是理由，如何在流程上保證測試的需求分析，、用例的設(shè)計與研發(fā)在開發(fā)時同步進行是最重要的，這時你要加強早期的測試介入，明確卡住需求確認這一部分，。這樣，在研發(fā)進入開發(fā)階段時，測試團隊也能進入測試設(shè)計，。當研發(fā)開發(fā)完成時，你測試團隊事實上已經(jīng)其本基本上完成了大部分的測試設(shè)計，并準備進入測試執(zhí)行，。不要在開發(fā)提交后再去想如何測測試，抱怨之聲也就不絕于耳了。這樣才可能測試好一個時間比較緊的項目不管在用于測試的時間上，還是測試的質(zhì)量上都無法滿足要求。

，同時測試設(shè)計的很好，不僅可以節(jié)約測試執(zhí)行的時間，也可以在反復(fù)提交的過程中，由于用例執(zhí)行的一致性，保證了測試在多次的執(zhí)行中的質(zhì)量，；。同時也有的標準，一是缺陷的情況，二是用例的執(zhí)行與覆蓋。同時由于研發(fā)給的測試時間比較緊，所以有兩件事情就必需作做好，：一是明確產(chǎn)品提交測試時間，并在研發(fā)延遲時給自己爭取時間；二是在質(zhì)量達不到要求的情況下，時間及時的做出反應(yīng)，不要到最后在研發(fā)不了解項目質(zhì)量的情況下建議研發(fā)延遲項目。為了達到上面的要求你必需要一個很好的測試平臺，把設(shè)計，測試用例管理，執(zhí)行與用例的聯(lián)動，缺陷管理與報表統(tǒng)計打通，盡可能的利用平臺解決事務(wù)性工作，降低流程執(zhí)行的成本，。也就是說，既讓測試人員可以集中精力去測試，同時又能夠讓研發(fā)管理人員隨時獲取正在進行測試的進度與質(zhì)量，。當這些工作做到透明化時以后，就算讓研發(fā)延遲，研發(fā)部門也會接收接受，。下圖是這一階段的大致流程

在這里可以跟大家說一下，我就曾經(jīng)在產(chǎn)品權(quán)限不在測試這里部門的情況下，成功的讓研發(fā)決定推遲了大約一半以上的項目,。大多數(shù)的測試部門主管，很難頂住來自項目/技術(shù)經(jīng)理的壓力是有理由的，因為他們根本不了解你做了哪些工作。有時候一些情況下，看似不可能的事情任務(wù)要想做成完成，關(guān)鍵要看在于事情的技巧，。流程表示了只是一個大方向的東西，而且，你永遠也無法將責(zé)任推卸給流程也許是對的，更多情況下，作為測試主管，需要但將做事的方法與風(fēng)格可以影響到推廣到測試流程的推廣中。

在測試互聯(lián)網(wǎng)項目時，還有一個更重要的就是如何保證性能，。

也許大家會說不就是性能測試并不是單獨存在的。其實不是完全正確，如果有充足的優(yōu)秀高手人力資源做性能測試當然很好，但性能測試也不能完全保證所有的項目完全沒有性能問題都完美無缺，因此，項目投入期間，同時性能測試是一個這個費時費力的工作，所以往往都是一般在資源不足的情況下開展的。