1、項目測試經(jīng)驗總結(jié)說明：以下項目測試經(jīng)驗是我在原來公司工作中的實際經(jīng)驗，拿出來和大家一起交流。我相信之前的項目測 試工作中有不少可以改進的地方，還希望大家多多交流。項目測試經(jīng)驗JudyShen本文是對我近幾年測試工作經(jīng)驗的總結(jié)，并以簡報的方式在研發(fā)中心內(nèi)進行分享及交流。1測試團隊介紹在介紹我們之前項目測試工作之前，需要首先介紹一下之前我所在團隊的組織架構(gòu)及測試人員在項目中的工作。我們的測試團隊屬于質(zhì)量改進中心下的測試部，它和研發(fā)團隊屬于兩個不同的中心。測試團隊有6個人,從圖一可以看出來，一個人可以參與多個處于不同階段的項目測試工作。 圖一測試團隊組織架構(gòu)參與項目的測試人員以測試組的形式進入項目，

2、測試組和需求組、開發(fā)組并列。每個測試組有一個測試組 長負責(zé)項目測試工作。項目經(jīng)理不直接面對測試組成員，而是通過測試組長進行任務(wù)安排、協(xié)調(diào)、溝通。測 試部經(jīng)理知情測試人員的項目測試工作，項目測試組的工作匯報均需要抄送給測試部經(jīng)理。如圖二所示：圖二項目組織架構(gòu)（舊）上面說到的是舊的測試人員工作模式，在去年年底，為了有效利用公司測試人員資源，我們開始了測試外 包的嘗試。這里的測試外包模式是指，測試組不進入項目，而是由項目組將測試工作以一個項目的方式分包給測試部，由測試部根據(jù)項目組提供的信息，進行計劃、執(zhí)行測試，并按照項目要求提交測試成果給項目組。這個模式還在探索中，如圖三所示，測試部經(jīng)理直接負責(zé)項目

3、的測試工作，測試組的工作情況抄送給項目經(jīng)理。這種模式需要進行獨立核算，包括成本估算、預(yù)算、結(jié)算等。但是這種模式的整體思路還不是很成熟，從這個組織架構(gòu)上大家也可以看出來，很多東西還沒有理順， 所以一直都處于嘗試過程中。后面提到的內(nèi)容,如果沒有特殊說明，都是在舊的模式下進行的。圖三項目組織架構(gòu)（測試外包方式）我想不可否認，大家都認為測試人員應(yīng)該是測試技術(shù)上的專家，但是，測試人員是否需要熟悉并擅長一定 的業(yè)務(wù)呢？不管答案是什么都沒有關(guān)系，但是我認為一個好的測試人員不僅是測試專家，他同時也是業(yè)務(wù)專 家。有一些測試人員，因為系統(tǒng)的業(yè)務(wù)知識很復(fù)雜，就一頭扎進去，幾乎全力去學(xué)習(xí)業(yè)務(wù)知識，測試技術(shù)的 學(xué)習(xí)和研

4、究沒有跟上， 結(jié)果不是設(shè)計出大量冗余的測試用例，就是很多方面沒考慮到，面對客戶的不當(dāng)請求,也沒有底氣說測試應(yīng)該怎么做，弄得做起項目來辛苦異常，個個苦不堪言！有著樣的說法：“軟件測試人員要兩條腿走路，左腿是測試技術(shù)，右腿是業(yè)務(wù)知識。只有兩條腿的健壯差 不多，走路才穩(wěn)當(dāng)?！背鲇谶@種思想的考慮，在原來的測試團隊，我們每個人都有兩個學(xué)習(xí)、研究方向，一 個是技術(shù)方向，一個是業(yè)務(wù)方向。例如：技術(shù)方向：功能自動化測試性能測試單元測試測試管理業(yè)務(wù)方向：物流業(yè)務(wù)智能交通知識管理但這種方式在工作開展上有些困難。如果公司認為測試人員應(yīng)該絕大部分時間用在項目測試工作上，那么 測試團隊既要研究測試技術(shù)，又要擠出時間學(xué)習(xí)

5、業(yè)務(wù)知識，在操作上是比較困難的。在我們以前的測試團隊 的工作中，有一部分工作時間是用來進行部門建設(shè)的，部門建設(shè)工作中包括前面說到的技術(shù)研究、業(yè)務(wù)學(xué)習(xí),還有就是部門搭建所需要進行的一些工作（如部門制度建設(shè)）。當(dāng)時公司允許我們團隊有30%的工作量投入部門建設(shè)上。將部門建設(shè)工作分開，主要是用于統(tǒng)計部門成本和測試成本用的。前面說到了測試人員是以測試組身份進入項目開展測試工作的，但不是每個成員上去都從事同樣的工作。在進入項目組工作時， 每個測試人員所充當(dāng)?shù)慕巧遣煌?，項目的測試角色劃分為以下四種，如表一所示。在實際工作中因為測試人員數(shù)量有限，所以經(jīng)常是一個人擔(dān)任多個角色。角色職責(zé)測試管理員負責(zé)測試項目

6、的管理 測試過程問題的處理與反饋 系統(tǒng)/性能測試組織和計劃 測試過程狀態(tài)報告測試設(shè)計員測試需求的描述系統(tǒng)/性能測試用例的設(shè)計測試工具、方法的引入測試執(zhí)行員根據(jù)需要開發(fā)測試腳本按照測試用例、測試腳本執(zhí)行測試項目測試工作指導(dǎo)測試監(jiān)督與度量員測試度量測試過程問題的匯總與反饋 開發(fā)產(chǎn)品的質(zhì)量抽檢與評定表一測試角色劃分了解了原來測試團隊的分工之后，下面介紹一下測試團隊的工作內(nèi)容。原來的測試團隊承接的工作內(nèi)容包 括：承擔(dān)系統(tǒng)測試、用戶測試、性能測試；進行測試技術(shù)研究及培訓(xùn)其中，測試技術(shù)研究，屬于提高團隊工作技能的工作，在整個部門范圍內(nèi)進行，這里屬于部門建設(shè)工作； 對于項目中的測試人員有可能需要進行，如果項

7、目采用新的測試技術(shù)或者測試工具，那么就需要項目測試組 成員研究測試技術(shù)了，這部分屬于項目測試工作。培訓(xùn)，是指把內(nèi)部研究的成果在團隊內(nèi)使用，在適當(dāng)?shù)臅r機在公司內(nèi)傳播。我們測試團隊在 2004年開展了21次內(nèi)部培訓(xùn)，7次公司級培訓(xùn)。因為每個人各有研究重點，所以我們每個人都是團隊內(nèi)部培訓(xùn)的講師。說到測試工程師的工作內(nèi)容，那么就涉及到測試工程師該做的和不該做的。當(dāng)然這和公司對測試人員定位 有關(guān)，這里僅指以前的組織。要說該做的，那么我們需要先明確為什么我們要測試？這是因為存在“系統(tǒng)錯 誤很多、系統(tǒng)不是客戶想要的東西、系統(tǒng)實現(xiàn)沒有遵照系統(tǒng)需求”等這樣的背景。在這樣的背景下，產(chǎn)生了 測試，但是又因為開發(fā)人員

8、自己測試自己的東西，難免測試不全面， 所以產(chǎn)生了測試工程師這個角色。因此,測試人員他該做的，就是測試軟件產(chǎn)品和用戶需求不一致的地方，并盡可能多的發(fā)現(xiàn)缺陷，能夠向項目經(jīng)理 匯報軟件質(zhì)量狀態(tài)。但是在實際工作中，測試人員經(jīng)常主動或被動的去做了一些不該做的事情。例如說，測 試人員認為自己或者測試能夠保證軟件的質(zhì)量，以及有意識或無意識的接受了決定軟件是否發(fā)布的這個權(quán)利。為什么測試無法保證軟件的質(zhì)量，是因為項目的質(zhì)量，需要項目組的所有成員共同努力，才能達到質(zhì)量保 證的目的。單純靠測試工程師的力量，是無法實現(xiàn)軟件質(zhì)量保證的目的。為什么測試人員不適合承擔(dān)決定軟件是否發(fā)布的權(quán)利，是因為軟件的發(fā)布，是需要項目組各

9、個小組負責(zé)人 等相關(guān)人一起對系統(tǒng)現(xiàn)在的缺陷、質(zhì)量狀況進行評估后，由項目經(jīng)理（或者與會者）做出是否發(fā)布的決定。 在這個過程中，測試工程師可以提供測試數(shù)據(jù)、系統(tǒng)當(dāng)前質(zhì)量狀態(tài)報告給與會者參考。當(dāng)然，我知道這兩點會有很多人不認同，但是沒有關(guān)系的。我接觸的同行中對兩點經(jīng)常有爭論。但是，有一些質(zhì)量大師等權(quán)威人士還是全部或部分贊同這兩個觀點的，如：菲利普.克勞士比曾在他的書中提到軟件質(zhì)量的保證需要全員努力，需要過程的控制的，而不是某個英雄可以保證軟件質(zhì)量的等。2項目測試工作做了背景介紹后，下面我介紹之前項目如何開展測試工作的。因為測試過程是整個測試工作的一個綱要，所以首先得從測試過程講起。測試過程測試過程，

10、我們包括四個環(huán)節(jié)：測試計劃、測試設(shè)計、測試執(zhí)行、測試分析。圖四測試過程測試計劃測試計劃主要是進行描述測試需求、分析制定測試計劃工作。在制定測試計劃時，經(jīng)常有人認為測試計劃 是在整個項目計劃制定之后才開始進行測試計劃的，事實上并不是這樣的。測試計劃和項目計劃是互相影響 的。舉個例子。假設(shè)項目有進行性能測試的需求，但是測試工具又需要學(xué)習(xí)，那么我們在測試計劃中就需要 預(yù)留這部分的時間，還有，測試用例的評審，也需要預(yù)留時間。或者，如果某部分比較復(fù)雜，可能測試需要 的時間會較多，或者需要測試的次數(shù)會比較多，那么可能要求開發(fā)組先安排這個核心模塊的開發(fā)，這樣需要 調(diào)整開發(fā)計劃的順序。所以，測試計劃和項目計劃

11、是互相影響的。在測試計劃環(huán)節(jié)還包括測試需求的描述， 主要是確認需求是可測試的，并將需求細化為具體的可測試點，保證測試設(shè)計時可以根據(jù)測試需求編寫測試 用例，而避免遺漏測試點。我們的測試需求需要得到業(yè)務(wù)分析人員的評審，測試計劃要得到項目經(jīng)理的審批 認可。對于測試計劃，還需要說明的是，在具體的每個測試階段工作計劃中，我們需要定義本階段測試需要進行的次數(shù)。每一輪測試是一個完整的測試周期，按照這里介紹的測試過程進行。通常我們是一天一輪測 試，最多是兩天一輪測試。通過這種方式，減少了測試和開發(fā)之間的空擋時間，即測試等開發(fā)，開發(fā)等測試。例子如圖五所示：圖五測試迭代例子肯定會有人疑問， 如果一個系統(tǒng)很龐大的話

12、，怎么能在一兩天內(nèi)完成測試呢？是的，如果系統(tǒng)比較大的話，確實沒法在一兩天內(nèi)完成所有測試點的全面測試，有可能需要一周或更長的時間，但是這樣的話，就出現(xiàn)了 測試、開發(fā)互相等待的情況了。所以，在我們制定的測試階段計劃時，需要指明本次測試的測試重點，測試 范圍。我可以這一輪測試進行A、B模塊基本功能測試，第二輪測試進行C、D模塊基本功能測試，第三輪測試，進行主要業(yè)務(wù)流程測試，第四輪測試，關(guān)注負面測試。在我之前的實踐中，發(fā)現(xiàn)這種方法還是比較有 效的?？赡艽蠹乙沧⒁獾搅耍@個例子是另一個項目的。沒錯，在今天提到的移動的這個項目中我們沒有按 照這種策略進行測試， 弄得當(dāng)時我們測試小組工作很累，很被動，經(jīng)常是

13、開發(fā)說測試我們就要馬上開始測試，而缺乏計劃。實施這種方法后，測試的計劃性就比較強，測試不用總是被打擾。測試設(shè)計測試設(shè)計，主要是根據(jù)需求、設(shè)計文檔進行的測試用例設(shè)計工作。如何從需求導(dǎo)出測試用例并設(shè)計測試用 例，是整個測試過程中很重要的一部分工作，關(guān)系到測試執(zhí)行效果。但是在剛開始時，系統(tǒng)沒有界面，所以 我們只能根據(jù)系統(tǒng)用例搭建測試用例的初步框架，能寫多少寫多少。隨著對系統(tǒng)的理解深入，加上后面也開 發(fā)了系統(tǒng)原型，我們就可以不斷完善測試用例。即使是在測試階段，我們?nèi)圆粩嘈薷臏y試用例。測試用例我 們分為兩種，一種是內(nèi)部測試用例，項目組內(nèi)部使用；一種是驗收測試用例，偏重于業(yè)務(wù)，供客戶使用。項 目組內(nèi)部用的

14、測試用例例子如圖六所示：圖六測試用例例子（項目內(nèi)用）從圖中大家也可以感覺到項目組內(nèi)部使用的測試用例在維護上比較不方便。因為我們的需求并沒有做到很 細，加上需求本身就是變化的，所以我們的測試需求經(jīng)常修改，一旦測試需求新增、修改、刪除時，測試用 例要相應(yīng)進行調(diào)整。這就造成了1）定位測試用例比較不方便，2）測試用例編號修改不方便，3）閱讀、執(zhí)行測試用例不方便。所以，我在 2004年底開始準(zhǔn)備在團隊內(nèi)自主開發(fā)一個測試用例管理系統(tǒng)。測試執(zhí)行在測試執(zhí)行階段，主要進行測試的執(zhí)行工作。如果項目有需要編寫或錄制測試腳本的話，那么也在這個階 段進行。測試執(zhí)行結(jié)果是在原有測試用例的副本上編寫實際執(zhí)行結(jié)果而形成。在東

15、南融通，它是把這個活動 單獨為“測試實施”環(huán)節(jié)。測試分析在測試執(zhí)行結(jié)束后，我們開始對測試執(zhí)行結(jié)果進行測試分析并編寫測試報告。測試報告的編寫上，主要的 內(nèi)容在于對投入的資源、測試結(jié)果、缺陷進行分析，并對整體測試情況進行總結(jié)分析。對于資源的分析，包 括各個測試任務(wù)投入的人力情況、實際工作量與計劃工作量的對比，并進行分析。測試結(jié)果分析，可以通過 對測試需求的覆蓋情況、測試用例的覆蓋情況及測試用例執(zhí)行結(jié)果情況進行統(tǒng)計，并進行分析。缺陷分析， 可以通過對嚴(yán)重性、優(yōu)先級、模塊缺陷數(shù)、缺陷修復(fù)情況等方面進行統(tǒng)計，并分析。例如，對系統(tǒng)缺陷進行 統(tǒng)計后，發(fā)現(xiàn)存在比較多的可用性問題，如修改操作員所屬的組后，無法登

16、錄系統(tǒng)等。整體情況的總結(jié)可以 從測試充分性、軟件質(zhì)量情況、測試活動情況、經(jīng)驗教訓(xùn)等方面進行總結(jié)。測試分析中有個很重要的活動是對測試活動和測試過程進行經(jīng)驗教訓(xùn)的總結(jié)。因為測試經(jīng)驗教訓(xùn)是很重要 的，所以我們團隊有專人負責(zé)對每個項目測試報告中的經(jīng)驗教訓(xùn)進行匯總，目的是讓后面項目測試工作可以 吸取前面項目測試的經(jīng)驗，避免犯前面項目測試工作同樣的錯誤。注：本測試過程對于每個階段的測試活動、每一輪測試活動、測試團隊承接的各種測試類型均適用。也就是說，每一輪測試之前，測試組組長都需要準(zhǔn)備測試計劃，確定測試執(zhí)行重點、目標(biāo)、測試內(nèi)容等， 選取測試用例，并按照預(yù)先選取的測試用例執(zhí)行測試，測試執(zhí)行結(jié)束，需要進行測試

17、匯報。測試準(zhǔn)則在測試過程中有個很重要的內(nèi)容是：測試準(zhǔn)則。在實際執(zhí)行中，我們不難碰到以下類似情況：提交測試的系統(tǒng)經(jīng)常在測試執(zhí)行初期，就出現(xiàn)頁面訪問失敗 或者正常功能失效的情況；測試人員不知道提交測試的版本改了什么內(nèi)容或者新增了什么功能，改了哪些缺陷，導(dǎo)致經(jīng)常碰到開發(fā)人員說測試人員提交的某些缺陷所對應(yīng)的功能不屬于本版本集成內(nèi)容等等。存在這些 情況的很大一部分的原因是因為在項目策劃階段時，測試組未就測試準(zhǔn)則和項目組達成一致意見，或者已經(jīng) 達成一致，但是并沒有嚴(yán)格執(zhí)行。我們今天要講的測試準(zhǔn)則，主要是針對前者，后者屬于管理層面問題，不 在我們的考慮范圍內(nèi)。設(shè)置測試準(zhǔn)時需要注重實用性。測試準(zhǔn)則，通常包括測

18、試進入、暫停、恢復(fù)、退出準(zhǔn)則。這些測試準(zhǔn)則的 例子如表二所示：進入準(zhǔn)則暫停準(zhǔn)則恢復(fù)準(zhǔn)則退出準(zhǔn)則含義描述開始執(zhí)行測試的時 機描述系統(tǒng)在什么情況下 暫停全部或部分測試工 作。描述系統(tǒng)恢復(fù)測試的必 要條件。描述測試退出的條件， 有正常退出，也有非正 ?；蛳⑼獾耐顺?。集成測試測試環(huán)境已經(jīng)準(zhǔn)備好； 已經(jīng)完成提交測試的模 塊內(nèi)容；主要功能無頁面點擊錯 誤；測試所需的文檔資料已 經(jīng)完整。測試環(huán)境被破壞；主要功能頁面點擊錯 誤。測試環(huán)境重新搭建好； 主要功能不會出現(xiàn)頁面 點擊錯誤的情況。完成已提交內(nèi)容所能完 成的測試系統(tǒng)測試測試環(huán)境已經(jīng)準(zhǔn)備好；系統(tǒng)基本業(yè)務(wù)流程能走 通無任何功能的貝卸點擊 錯誤；測試所需的文檔

19、資料已 經(jīng)完整。測試環(huán)境被破壞； 系統(tǒng)基本業(yè)務(wù)流程不 通；任何功能的貝卸點擊錯 誤。測試環(huán)境重新搭建好； 系統(tǒng)基本業(yè)務(wù)流程可以 走通；頁面點擊錯誤問題解 決。測試內(nèi)容已經(jīng)完成； 阻塞測試的內(nèi)容（即測 試暫停的產(chǎn)生原因）在 短時間內(nèi)無法解決。內(nèi)部確認測 tit/UAT測試環(huán)境已經(jīng)準(zhǔn)備好；系統(tǒng)正常功能已正確實現(xiàn)；業(yè)務(wù)流程能走通。測試環(huán)境被破壞； 系統(tǒng)業(yè)務(wù)流程不通； 正常功能未正確實現(xiàn)； 用戶很容易重現(xiàn)的嚴(yán)重 缺陷產(chǎn)生。測試環(huán)境重新搭建好； 系統(tǒng)業(yè)務(wù)流程能走通； 正常功能實現(xiàn)；需要解決的缺陷解決。測試內(nèi)容已經(jīng)全部完 成；PM根據(jù)測試報告，認為 系統(tǒng)可以滿足客戶的要 求；PM要求修改的缺陷已 經(jīng)全部修

20、復(fù)； 到了時間，系統(tǒng)必須發(fā) 布。驗收測試測試環(huán)境已經(jīng)準(zhǔn)備好； 客戶要求的功能都已經(jīng) 完成。業(yè)務(wù)流程可以走通。測試環(huán)境被破壞；發(fā)現(xiàn)需要修改的缺陷。測試環(huán)境重新搭建好； 修改完需要修改的缺 陷。所有要求的測試用例和 測試程序都已經(jīng)執(zhí)行， 并且沒有發(fā)現(xiàn)新的必須 修改的缺陷性能測試測試環(huán)境已經(jīng)準(zhǔn)備好； 系統(tǒng)的功能正常實現(xiàn)； 不存在影響系統(tǒng)流程的 缺陷。測試環(huán)境被破壞； 系統(tǒng)流程存在缺陷； 被測試功能存在缺陷； 程序的版本更新，存在 影響系統(tǒng)功能實現(xiàn)的缺 陷。測試環(huán)境重新搭建好； 解決影響性能測試的缺 陷。所有要求的測試用例和 測試腳本都已執(zhí)行； 完成性能分析工作。表二測試準(zhǔn)則例子恢復(fù)測試時，一般是需要

21、把前面測試內(nèi)容重新進行測試，因為會花費較大的工作量，所以測試組長在決定 暫停測試時需要很慎重。在表二顯示的集成測試的退出準(zhǔn)則中寫到“完成已提交測試內(nèi)容所能完成的測試”，這里的“所能完成的 測試”是指，在當(dāng)前版本所能進行的測試內(nèi)容，如在系統(tǒng)剛集成時，可進行界面測試，基本模塊的基本功能 的測試。上面的測試準(zhǔn)則的例子，也不是很恰當(dāng)及規(guī)范，至少缺少了數(shù)據(jù)度量部分，這里只是拿出來和大家一起交 流。這部分內(nèi)容我一直認為是很重要的，如果做的不好，測試組的負擔(dān)會很重。需要注意的一點是：測試準(zhǔn)則，是在制定測試計劃時溝通確定的，它需要和相關(guān)人溝通，且得到項目經(jīng)理 審批通過的。測試準(zhǔn)則是固定的，實際處理方式是靈活的

22、。在實際測試過程中碰到同樣的問題，是否繼續(xù)測試，或者需 要暫停測試，處理方式不是一成不變的，這是需要根據(jù)項目所處階段來具體情況具體分析的。下面舉個例子，這個例子是經(jīng)常性的一種情況。假設(shè)在測試過程中，我們發(fā)現(xiàn)了一個阻塞性錯誤（流程無 法繼續(xù)往下走等類似情況），是否繼續(xù)進行測試呢？在項目初期，進行單個或多個模塊的測試時：因為可以執(zhí)行界面測試及熟悉系統(tǒng)，我們可以接受該版本，繼續(xù)進行測試。這就屬于已提交測試內(nèi)容所能完成的測試。在項目測試初期，要求不可過 于嚴(yán)格。系統(tǒng)測試：基本流程必須走通。如果基本業(yè)務(wù)流程（主干）不能走通，則需要根據(jù)實際情況來靈活 處理。（是否暫停測試或繼續(xù)測試？）如果是整個流程的初始

23、節(jié)點失效，沒有這個節(jié)點的數(shù)據(jù)，后 面所有節(jié)點均無法進行，那么這種情況下就只能暫停測試。如果說是分支流程出現(xiàn)阻塞，那么可以考慮繼續(xù)測試， 然后在測試報告中說明該分支未測試。此時不暫停測試， 主要是考慮重新集成一個版本的性價比，也就是是否值得重新集成。發(fā)布前的確認測試：一旦有阻塞性缺陷，馬上停止測試。測試實施過程上面說的是測試過程。下面簡單介紹一下我們實際的測試工作。我們的測試組一般是在項目啟動時進入項目組的。在項目立項時，項目經(jīng)理會向測試部經(jīng)理申請測試資源。經(jīng)過評估衡量后，測試部經(jīng)理會安排一個測試人員作為項目測試組長。當(dāng)項目啟動時，測試組長進入項目， 開始了解項目用戶需求，起草項目測試計劃。在到

24、了一定階段，例如測試設(shè)計階段，測試部經(jīng)理會根據(jù)項目 規(guī)模，項目在公司的重要性以及團隊其他人員工作負荷情況，安排其他人進入項目組。一般來說，我們一個 項目是23名測試人員。在項目進入維護階段時，則是一個測試人員跟進項目。測試組長根據(jù)項目情況及項目階段計劃，定義項目本階段測試次數(shù)。項目經(jīng)理參考測試組長提供的測試次 數(shù)建議，以及項目開發(fā)的情況，和項目組各個小組負責(zé)人溝通后，定義了系統(tǒng)本階段版本集成時間。在我們 的項目里，有一個開發(fā)人員兼職做集成人員。在指定的版本集成時間之前的一段時間，各個開發(fā)人員將他們 的程序提交配置庫，由集成人員進行集成（不同語言有不同的集成方式）。集成后，集成人員會進行簡單的

25、自測，驗證是否集成成功。如果集成成功，就在服務(wù)器上給該版本程序打上標(biāo)簽。如果集成不成功，那么返 工給相應(yīng)開發(fā)人員修改并重新集成，如此反復(fù)直至集成成功。集成成功后，集成人員會提交一份集成說明給 測試組長。集成說明內(nèi)容包括：集成版本路徑、版本標(biāo)簽、修改內(nèi)容、新增內(nèi)容等。測試組長則根據(jù)預(yù)先準(zhǔn) 備好的測試計劃開始測試。在開始測試時測試組長會通知項目組，告訴他們測試開始，請勿更新測試環(huán)境。 測試結(jié)束后，也會通知項目組測試結(jié)束。這里要很注意一點的是， 對于數(shù)據(jù)庫的更新也需要采用同樣的管理，即數(shù)據(jù)庫維護也是需要進行統(tǒng)一管理，避免出現(xiàn)客戶環(huán)境和測試環(huán)境不一致的情況。在正常情況下，開發(fā)組是在預(yù)定的集成日期的當(dāng)天

26、晚上集成，測試組第二天上班后開始測試。如果遇到特殊 情況需要當(dāng)天集成當(dāng)天測試的話，我們的開發(fā)人員會等到測試組發(fā)出測試結(jié)束的通知后，才離崗。如果在完成計劃的測試次數(shù)后，系統(tǒng)質(zhì)量仍不穩(wěn)定或沒有達到預(yù)期目標(biāo)的話，那么測試組長將和項目經(jīng)理 溝通，相應(yīng)增加測試次數(shù)。關(guān)于測試用例的執(zhí)行，我不知道公司現(xiàn)在是采用怎樣的一種方式的。在我原來的團隊中，測試用例的主要作用是保證系統(tǒng)功能的測試覆蓋率， 避免某些功能因為測試周期長而導(dǎo)致測試遺漏。但是我們也采用經(jīng)驗法、試探法、轉(zhuǎn)換思維的方式進行測試，所以，我們一般使用測試用例執(zhí)行34次測試。這可能和我們的測試用例設(shè)計能力有關(guān)。在缺陷管理上，整體流程基本類似，但是在缺陷分

27、配上，我們測試人員是直接分配給項目缺陷分配專員， 缺陷分配專員一般是由業(yè)務(wù)分析員擔(dān)任。缺陷分配專員對缺陷進行分析后，再進行缺陷的再分配。對于缺陷 分配專員處理為不修改的缺陷，測試人員需要進行確認。如果測試人員不認可缺陷分配專員的處理意見，可 以同他進行溝通，或向相關(guān)人員（如項目經(jīng)理）提出自己的意見，最終以項目經(jīng)理的意見為準(zhǔn)。在系統(tǒng)階段 確認測試前的23天，測試組長會將系統(tǒng)未解決的缺陷清單給項目經(jīng)理確認，并要求項目經(jīng)理提供缺陷應(yīng)對方案。缺陷應(yīng)對方案在系統(tǒng)發(fā)布時，作為項目發(fā)布說明的附件。我們是采用公司自主開發(fā)的缺陷管理系統(tǒng)進行缺陷管理的，使用excel、word進行其他測試工件的編寫的。3 如何搭

28、建一個高效的測試團隊俗話說“工欲善其事，必先利其器”，要做好測試工作，首先需要建立并維護一個高效的測試團隊。然而， 許多小型軟件企業(yè)卻將測試作為產(chǎn)品面臨發(fā)布時的一個小“插曲”，往往臨時抽調(diào)幾名程序員對產(chǎn)品的功能 粗略測試一下即交付客戶（甚至在進度和成本不足時首先砍掉這一塊）。這種倉促完成的產(chǎn)品通常質(zhì)量問題 很多，所以我們首先應(yīng)拋棄小企業(yè)慣常的思維模式，不計較一時一地之利益，立足長遠，著手組建高效測試 團隊。第一步：招募測試人員在國內(nèi)的軟件企業(yè)中有一種普遍做法，那就是把那些剛涉足軟件行業(yè)的技術(shù)新手或業(yè)績不突出的開發(fā)人員安排去做測試工作。筆者認為這絕對是一種欠妥當(dāng)?shù)男袨?。事實上，對一個系統(tǒng)進行有效

29、測試所需要的 技能絕對不比進行軟件開發(fā)所需要的技能少，測試從業(yè)者甚至可能面對許多開發(fā)人員都不會遇到的技術(shù)難 題。那么，測試團隊需要招募什么樣的成員呢？這里，筆者總結(jié)了以下兩點：首先，測試人員要具備良好的溝通能力、自信心、外交能力、遷移能力以及懷疑精神。其次，測試組成員應(yīng)具備良好的專業(yè)技能或者技術(shù)學(xué)習(xí)能力。當(dāng)然，新招募的測試人員不可能像上面說的那么理想。關(guān)鍵是他們是否熱愛測試這項工作，對相關(guān)的 工作內(nèi)容是否感興趣以及他們的學(xué)習(xí)能力如何。第二步：測試團隊制度建設(shè)良好的制度可以規(guī)范測試團隊的工作開展，同時也便于對團隊成員進行業(yè)績考評。相反，則很有可能導(dǎo)致人心渙散，滋長負面風(fēng)氣。建設(shè)良好的測試團隊制度，可以考慮以下幾個方面：匯報制度團隊成員匯報本周工作情況及下周工作計劃、遇到的問題以及需要提供的幫助，培養(yǎng)團 隊成員的匯報及計劃習(xí)慣。工作總結(jié)制度成員每個階段匯報上階段工作經(jīng)驗和教訓(xùn)，并在部門例會上交流、分享經(jīng)驗及教訓(xùn)， 避免同樣的問題重復(fù)出現(xiàn)。獎懲制度對于貢獻突出的成員予以獎勵，對于業(yè)績差的