第一篇：項目測試經(jīng)驗總結(jié)

項目測試經(jīng)驗總結(jié)

說明：以下項目測試經(jīng)驗是我在原來公司工作中的實際經(jīng)驗，拿出來和大家一起交流。我相信之前的項目測試工作中有不少可以改進的地方，還希望大家多多交流。

項目測試經(jīng)驗

——Judy Shen

本文是對我近幾年測試工作經(jīng)驗的總結(jié)，并以簡報的方式在研發(fā)中心內(nèi)進行分享及交流。測試團隊介紹

在介紹我們之前項目測試工作之前，需要首先介紹一下之前我所在團隊的組織架構(gòu)及測試人員在項目中的工作。

我們的測試團隊屬于質(zhì)量改進中心下的測試部，它和研發(fā)團隊屬于兩個不同的中心。測試團隊有6個人，從圖一可以看出來，一個人可以參與多個處于不同階段的項目測試工作。

圖一 測試團隊組織架構(gòu)

參與項目的測試人員以測試組的形式進入項目，測試組和需求組、開發(fā)組并列。每個測試組有一個測試組長負責項目測試工作。項目經(jīng)理不直接面對測試組成員，而是通過測試組長進行任務安排、協(xié)調(diào)、溝通。測試部經(jīng)理知情測試人員的項目測試工作，項目測試組的工作匯報均需要抄送給測試部經(jīng)理。如圖二所示：

圖二 項目組織架構(gòu)（舊）

上面說到的是舊的測試人員工作模式，在去年年底，為了有效利用公司測試人員資源，我們開始了測試外包的嘗試。這里的測試外包模式是指，測試組不進入項目，而是由項目組將測試工作以一個項目的方式分包給測試部，由測試部根據(jù)項目組提供的信息，進行計劃、執(zhí)行測試，并按照項目要求提交測試成果給項目組。

這個模式還在探索中，如圖三所示，測試部經(jīng)理直接負責項目的測試工作，測試組的工作情況抄送給項目經(jīng)理。這種模式需要進行獨立核算，包括成本估算、預算、結(jié)算等。但是這種模式的整體思路還不是很成熟，從這個組織架構(gòu)上大家也可以看出來，很多東西還沒有理順，所以一直都處于嘗試過程中。后面提到的內(nèi)容，如果沒有特殊說明，都是在舊的模式下進行的。

圖三 項目組織架構(gòu)（測試外包方式）

我想不可否認，大家都認為測試人員應該是測試技術(shù)上的專家，但是，測試人員是否需要熟悉并擅長一定的業(yè)務呢？不管答案是什么都沒有關(guān)系，但是我認為一個好的測試人員不僅是測試專家，他同時也是業(yè)務專家。有一些測試人員，因為系統(tǒng)的業(yè)務知識很復雜，就一頭扎進去，幾乎全力去學習業(yè)務知識，測試技術(shù)的學習和研究沒有跟上，結(jié)果不是設(shè)計出大量冗余的測試用例，就是很多方面沒考慮到，面對客戶的不當請求，也沒有底氣說測試應該怎么做，弄得做起項目來辛苦異常，個個苦不堪言！

有著樣的說法：“軟件測試人員要兩條腿走路，左腿是測試技術(shù)，右腿是業(yè)務知識。只有兩條腿的健壯差不多，走路才穩(wěn)當。”出于這種思想的考慮，在原來的測試團隊，我們每個人都有兩個學習、研究方向，一個是技術(shù)方向，一個是業(yè)務方向。例如：

? 技術(shù)方向：

? 功能自動化測試 ? 性能測試 ? 單元測試 ? 測試管理 ? 業(yè)務方向：

? 物流業(yè)務 ? 智能交通 ? 知識管理

但這種方式在工作開展上有些困難。如果公司認為測試人員應該絕大部分時間用在項目測試工作上，那么測試團隊既要研究測試技術(shù)，又要擠出時間學習業(yè)務知識，在操作上是比較困難的。在我們以前的測試團隊的工作中，有一部分工作時間是用來進行部門建設(shè)的，部門建設(shè)工作中包括前面說到的技術(shù)研究、業(yè)務學習，還有就是部門搭建所需要進行的一些工作（如部門制度建設(shè)）。當時公司允許我們團隊有30%的工作量投入部門建設(shè)上。將部門建設(shè)工作分開，主要是用于統(tǒng)計部門成本和測試成本用的。

前面說到了測試人員是以測試組身份進入項目開展測試工作的，但不是每個成員上去都從事同樣的工作。在進入項目組工作時，每個測試人員所充當?shù)慕巧遣煌模椖康臏y試角色劃分為以下四種，如表一所示。在實際工作中因為測試人員數(shù)量有限，所以經(jīng)常是一個人擔任多個角色。

角色 職責 測試管理員

負責測試項目的管理 測試過程問題的處理與反饋 系統(tǒng)/性能測試組織和計劃 測試過程狀態(tài)報告 測試設(shè)計員 測試需求的描述

系統(tǒng)/性能測試用例的設(shè)計 測試工具、方法的引入 測試執(zhí)行員

根據(jù)需要開發(fā)測試腳本

按照測試用例、測試腳本執(zhí)行測試 項目測試工作指導 測試監(jiān)督與度量員 測試度量

測試過程問題的匯總與反饋 開發(fā)產(chǎn)品的質(zhì)量抽檢與評定

表一 測試角色劃分

了解了原來測試團隊的分工之后，下面介紹一下測試團隊的工作內(nèi)容。原來的測試團隊承接的工作內(nèi)容包括：

? 承擔系統(tǒng)測試、用戶測試、性能測試；

? 進行測試技術(shù)研究及培訓

其中，測試技術(shù)研究，屬于提高團隊工作技能的工作，在整個部門范圍內(nèi)進行，這里屬于部門建設(shè)工作；對于項目中的測試人員有可能需要進行，如果項目采用新的測試技術(shù)或者測試工具，那么就需要項目測試組成員研究測試技術(shù)了，這部分屬于項目測試工作。

培訓，是指把內(nèi)部研究的成果在團隊內(nèi)使用，在適當?shù)臅r機在公司內(nèi)傳播。我們測試團隊在2004年開展了21次內(nèi)部培訓，7次公司級培訓。因為每個人各有研究重點，所以我們每個人都是團隊內(nèi)部培訓的講師。

說到測試工程師的工作內(nèi)容，那么就涉及到測試工程師該做的和不該做的。當然這和公司對測試人員定位有關(guān)，這里僅指以前的組織。要說該做的，那么我們需要先明確為什么我們要測試？這是因為存在“系統(tǒng)錯誤很多、系統(tǒng)不是客戶想要的東西、系統(tǒng)實現(xiàn)沒有遵照系統(tǒng)需求”等這樣的背景。在這樣的背景下，產(chǎn)生了測試，但是又因為開發(fā)人員自己測試自己的東西，難免測試不全面，所以產(chǎn)生了測試工程師這個角色。因此，測試人員他該做的，就是測試軟件產(chǎn)品和用戶需求不一致的地方，并盡可能多的發(fā)現(xiàn)缺陷，能夠向項目經(jīng)理匯報軟件質(zhì)量狀態(tài)。但是在實際工作中，測試人員經(jīng)常主動或被動的去做了一些不該做的事情。例如說，測試人員認為自己或者測試能夠保證軟件的質(zhì)量，以及有意識或無意識的接受了決定軟件是否發(fā)布的這個權(quán)利。

為什么測試無法保證軟件的質(zhì)量，是因為項目的質(zhì)量，需要項目組的所有成員共同努力，才能達到質(zhì)量保證的目的。單純靠測試工程師的力量，是無法實現(xiàn)軟件質(zhì)量保證的目的。

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

做了背景介紹后，下面我介紹之前項目如何開展測試工作的。

因為測試過程是整個測試工作的一個綱要，所以首先得從測試過程講起。

2.1 測試過程

測試過程，我們包括四個環(huán)節(jié)：測試計劃、測試設(shè)計、測試執(zhí)行、測試分析。

圖四 測試過程

2.1.1 測試計劃

測試計劃主要是進行描述測試需求、分析制定測試計劃工作。在制定測試計劃時，經(jīng)常有人認為測試計劃是在整個項目計劃制定之后才開始進行測試計劃的，事實上并不是這樣的。測試計劃和項目計劃是互相影響的。舉個例子。假設(shè)項目有進行性能測試的需求，但是測試工具又需要學習，那么我們在測試計劃中就需要預留這部分的時間，還有，測試用例的評審，也需要預留時間。或者，如果某部分比較復雜，可能測試需要的時間會較多，或者需要測試的次數(shù)會比較多，那么可能要求開發(fā)組先安排這個核心模塊的開發(fā)，這樣需要調(diào)整開發(fā)計劃的順序。所以，測試計劃和項目計劃是互相影響的。在測試計劃環(huán)節(jié)還包括測試需求的描述，主要是確認需求是可測試的，并將需求細化為具體的可測試點，保證測試設(shè)計時可以根據(jù)測試需求編寫測試用例，而避免遺漏測試點。我們的測試需求需要得到業(yè)務分析人員的評審，測試計劃要得到項目經(jīng)理的審批認可。對于測試計劃，還需要說明的是，在具體的每個測試階段工作計劃中，我們需要定義本階段測試需要進行的次數(shù)。每一輪測試是一個完整的測試周期，按照這里介紹的測試過程進行。通常我們是一天一輪測試，最多是兩天一輪測試。通過這種方式，減少了測試和開發(fā)之間的空擋時間，即測試等開發(fā)，開發(fā)等測試。例子如圖五所示：

圖五 測試迭代例子 肯定會有人疑問，如果一個系統(tǒng)很龐大的話，怎么能在一兩天內(nèi)完成測試呢？是的，如果系統(tǒng)比較大的話，確實沒法在一兩天內(nèi)完成所有測試點的全面測試，有可能需要一周或更長的時間，但是這樣的話，就出現(xiàn)了測試、開發(fā)互相等待的情況了。所以，在我們制定的測試階段計劃時，需要指明本次測試的測試重點，測試范圍。我可以這一輪測試進行A、B模塊基本功能測試，第二輪測試進行C、D模塊基本功能測試，第三輪測試，進行主要業(yè)務流程測試，第四輪測試，關(guān)注負面測試。在我之前的實踐中，發(fā)現(xiàn)這種方法還是比較有效的。可能大家也注意到了，這個例子是另一個項目的。沒錯，在今天提到的移動的這個項目中我們沒有按照這種策略進行測試，弄得當時我們測試小組工作很累，很被動，經(jīng)常是開發(fā)說測試我們就要馬上開始測試，而缺乏計劃。實施這種方法后，測試的計劃性就比較強，測試不用總是被打擾。

2.1.2 測試設(shè)計

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

圖六 測試用例例子（項目內(nèi)用）

從圖中大家也可以感覺到項目組內(nèi)部使用的測試用例在維護上比較不方便。因為我們的需求并沒有做到很細，加上需求本身就是變化的，所以我們的測試需求經(jīng)常修改，一旦測試需求新增、修改、刪除時，測試用例要相應進行調(diào)整。這就造成了1)定位測試用例比較不方便，2)測試用例編號修改不方便，3)閱讀、執(zhí)行測試用例不方便。所以，我在2004年底開始準備在團隊內(nèi)自主開發(fā)一個測試用例管理系統(tǒng)。

2.1.3 測試執(zhí)行

在測試執(zhí)行階段，主要進行測試的執(zhí)行工作。如果項目有需要編寫或錄制測試腳本的話，那么也在這個階段進行。測試執(zhí)行結(jié)果是在原有測試用例的副本上編寫實際執(zhí)行結(jié)果而形成。在東南融通，它是把這個活動單獨為“測試實施”環(huán)節(jié)。

2.1.4 測試分析 在測試執(zhí)行結(jié)束后，我們開始對測試執(zhí)行結(jié)果進行測試分析并編寫測試報告。測試報告的編寫上，主要的內(nèi)容在于對投入的資源、測試結(jié)果、缺陷進行分析，并對整體測試情況進行總結(jié)分析。對于資源的分析，包括各個測試任務投入的人力情況、實際工作量與計劃工作量的對比，并進行分析。測試結(jié)果分析，可以通過對測試需求的覆蓋情況、測試用例的覆蓋情況及測試用例執(zhí)行結(jié)果情況進行統(tǒng)計，并進行分析。缺陷分析，可以通過對嚴重性、優(yōu)先級、模塊缺陷數(shù)、缺陷修復情況等方面進行統(tǒng)計，并分析。例如，對系統(tǒng)缺陷進行統(tǒng)計后，發(fā)現(xiàn)存在比較多的可用性問題，如修改操作員所屬的組后，無法登錄系統(tǒng)等。整體情況的總結(jié)可以從測試充分性、軟件質(zhì)量情況、測試活動情況、經(jīng)驗教訓等方面進行總結(jié)。

測試分析中有個很重要的活動是對測試活動和測試過程進行經(jīng)驗教訓的總結(jié)。因為測試經(jīng)驗教訓是很重要的，所以我們團隊有專人負責對每個項目測試報告中的經(jīng)驗教訓進行匯總，目的是讓后面項目測試工作可以吸取前面項目測試的經(jīng)驗，避免犯前面項目測試工作同樣的錯誤。注：本測試過程對于每個階段的測試活動、每一輪測試活動、測試團隊承接的各種測試類型均適用。

也就是說，每一輪測試之前，測試組組長都需要準備測試計劃，確定測試執(zhí)行重點、目標、測試內(nèi)容等，選取測試用例，并按照預先選取的測試用例執(zhí)行測試，測試執(zhí)行結(jié)束，需要進行測試匯報。

2.1.5 測試準則

在測試過程中有個很重要的內(nèi)容是：測試準則。

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

設(shè)置測試準時需要注重實用性。測試準則，通常包括測試進入、暫停、恢復、退出準則。這些測試準則的例子如表二所示：

進入準則 暫停準則 恢復準則 退出準則

含義

描述開始執(zhí)行測試的時機

描述系統(tǒng)在什么情況下暫停全部或部分測試工作。描述系統(tǒng)恢復測試的必要條件。

描述測試退出的條件，有正常退出，也有非正常或意外的退出。集成測試

測試環(huán)境已經(jīng)準備好； 已經(jīng)完成提交測試的模塊內(nèi)容； 主要功能無頁面點擊錯誤； 測試所需的文檔資料已經(jīng)完整。測試環(huán)境被破壞； 主要功能頁面點擊錯誤。測試環(huán)境重新搭建好；

主要功能不會出現(xiàn)頁面點擊錯誤的情況。完成已提交內(nèi)容所能完成的測試 系統(tǒng)測試

測試環(huán)境已經(jīng)準備好； 系統(tǒng)基本業(yè)務流程能走通 無任何功能的頁面點擊錯誤； 測試所需的文檔資料已經(jīng)完整。測試環(huán)境被破壞； 系統(tǒng)基本業(yè)務流程不通； 任何功能的頁面點擊錯誤。測試環(huán)境重新搭建好； 系統(tǒng)基本業(yè)務流程可以走通； 頁面點擊錯誤問題解決。測試內(nèi)容已經(jīng)完成；

阻塞測試的內(nèi)容（即測試暫停的產(chǎn)生原因）在短時間內(nèi)無法解決。內(nèi)部確認測試/UAT 測試環(huán)境已經(jīng)準備好； 系統(tǒng)正常功能已正確實現(xiàn)； 業(yè)務流程能走通。測試環(huán)境被破壞； 系統(tǒng)業(yè)務流程不通； 正常功能未正確實現(xiàn)；

用戶很容易重現(xiàn)的嚴重缺陷產(chǎn)生。測試環(huán)境重新搭建好； 系統(tǒng)業(yè)務流程能走通； 正常功能實現(xiàn)； 需要解決的缺陷解決。測試內(nèi)容已經(jīng)全部完成；

PM根據(jù)測試報告，認為系統(tǒng)可以滿足客戶的要求； PM要求修改的缺陷已經(jīng)全部修復； 到了時間，系統(tǒng)必須發(fā)布。驗收測試

測試環(huán)境已經(jīng)準備好； 客戶要求的功能都已經(jīng)完成。業(yè)務流程可以走通。測試環(huán)境被破壞； 發(fā)現(xiàn)需要修改的缺陷。測試環(huán)境重新搭建好； 修改完需要修改的缺陷。

所有要求的測試用例和測試程序都已經(jīng)執(zhí)行，并且沒有發(fā)現(xiàn)新的必須修改的缺陷 性能測試

測試環(huán)境已經(jīng)準備好； 系統(tǒng)的功能正常實現(xiàn)； 不存在影響系統(tǒng)流程的缺陷。測試環(huán)境被破壞； 系統(tǒng)流程存在缺陷； 被測試功能存在缺陷；

程序的版本更新，存在影響系統(tǒng)功能實現(xiàn)的缺陷。測試環(huán)境重新搭建好； 解決影響性能測試的缺陷。

所有要求的測試用例和測試腳本都已執(zhí)行； 完成性能分析工作。

表二 測試準則例子

恢復測試時，一般是需要把前面測試內(nèi)容重新進行測試，因為會花費較大的工作量，所以測試組長在決定暫停測試時需要很慎重。

在表二顯示的集成測試的退出準則中寫到“完成已提交測試內(nèi)容所能完成的測試”，這里的“所能完成的測試”是指，在當前版本所能進行的測試內(nèi)容，如在系統(tǒng)剛集成時，可進行界面測試，基本模塊的基本功能的測試。

上面的測試準則的例子，也不是很恰當及規(guī)范，至少缺少了數(shù)據(jù)度量部分，這里只是拿出來和大家一起交流。這部分內(nèi)容我一直認為是很重要的，如果做的不好，測試組的負擔會很重。

需要注意的一點是：測試準則，是在制定測試計劃時溝通確定的，它需要和相關(guān)人溝通，且得到項目經(jīng)理審批通過的。

測試準則是固定的，實際處理方式是靈活的。在實際測試過程中碰到同樣的問題，是否繼續(xù)測試，或者需要暫停測試，處理方式不是一成不變的，這是需要根據(jù)項目所處階段來具體情況具體分析的。

下面舉個例子，這個例子是經(jīng)常性的一種情況。假設(shè)在測試過程中，我們發(fā)現(xiàn)了一個阻塞性錯誤（流程無法繼續(xù)往下走等類似情況），是否繼續(xù)進行測試呢？

? 在項目初期，進行單個或多個模塊的測試時：因為可以執(zhí)行界面測試及熟悉系統(tǒng)，我們可以接受該版本，繼續(xù)進行測試。這就屬于已提交測試內(nèi)容所能完成的測試。在項目測試初期，要求不可過于嚴格。

? 系統(tǒng)測試：基本流程必須走通。如果基本業(yè)務流程（主干）不能走通，則需要根據(jù)實際情況來靈活處理。（是否暫停測試或繼續(xù)測試？）如果是整個流程的初始節(jié)點失效，沒有這個節(jié)點的數(shù)據(jù)，后面所有節(jié)點均無法進行，那么這種情況下就只能暫停測試。如果說是分支流程出現(xiàn)阻塞，那么可以考慮繼續(xù)測試，然后在測試報告中說明該分支未測試。此時不暫停測試，主要是考慮重新集成一個版本的性價比，也就是是否值得重新集成。

? 發(fā)布前的確認測試：一旦有阻塞性缺陷，馬上停止測試。

2.2 測試實施過程

上面說的是測試過程。下面簡單介紹一下我們實際的測試工作。

我們的測試組一般是在項目啟動時進入項目組的。在項目立項時，項目經(jīng)理會向測試部經(jīng)理申請測試資源。經(jīng)過評估衡量后，測試部經(jīng)理會安排一個測試人員作為項目測試組長。當項目啟動時，測試組長進入項目，開始了解項目用戶需求，起草項目測試計劃。在到了一定階段，例如測試設(shè)計階段，測試部經(jīng)理會根據(jù)項目規(guī)模，項目在公司的重要性以及團隊其他人員工作負荷情況，安排其他人進入項目組。一般來說，我們一個項目是2~3名測試人員。在項目進入維護階段時，則是一個測試人員跟進項目。

測試組長根據(jù)項目情況及項目階段計劃，定義項目本階段測試次數(shù)。項目經(jīng)理參考測試組長提供的測試次數(shù)建議，以及項目開發(fā)的情況，和項目組各個小組負責人溝通后，定義了系統(tǒng)本階段版本集成時間。在我們的項目里，有一個開發(fā)人員兼職做集成人員。在指定的版本集成時間之前的一段時間，各個開發(fā)人員將他們的程序提交配置庫，由集成人員進行集成（不同語言有不同的集成方式）。集成后，集成人員會進行簡單的自測，驗證是否集成成功。如果集成成功，就在服務器上給該版本程序打上標簽。如果集成不成功，那么返工給相應開發(fā)人員修改并重新集成，如此反復直至集成成功。集成成功后，集成人員會提交一份集成說明給測試組長。集成說明內(nèi)容包括：集成版本路徑、版本標簽、修改內(nèi)容、新增內(nèi)容等。測試組長則根據(jù)預先準備好的測試計劃開始測試。在開始測試時測試組長會通知項目組，告訴他們測試開始，請勿更新測試環(huán)境。測試結(jié)束后，也會通知項目組測試結(jié)束。

這里要很注意一點的是，對于數(shù)據(jù)庫的更新也需要采用同樣的管理，即數(shù)據(jù)庫維護也是需要進行統(tǒng)一管理，避免出現(xiàn)客戶環(huán)境和測試環(huán)境不一致的情況。

在正常情況下，開發(fā)組是在預定的集成日期的當天晚上集成，測試組第二天上班后開始測試。如果遇到特殊情況需要當天集成當天測試的話，我們的開發(fā)人員會等到測試組發(fā)出測試結(jié)束的通知后，才離崗。

如果在完成計劃的測試次數(shù)后，系統(tǒng)質(zhì)量仍不穩(wěn)定或沒有達到預期目標的話，那么測試組長將和項目經(jīng)理溝通，相應增加測試次數(shù)。

關(guān)于測試用例的執(zhí)行，我不知道公司現(xiàn)在是采用怎樣的一種方式的。在我原來的團隊中，測試用例的主要作用是保證系統(tǒng)功能的測試覆蓋率，避免某些功能因為測試周期長而導致測試遺漏。但是我們也采用經(jīng)驗法、試探法、轉(zhuǎn)換思維的方式進行測試，所以，我們一般使用測試用例執(zhí)行3~4次測試。這可能和我們的測試用例設(shè)計能力有關(guān)。

在缺陷管理上，整體流程基本類似，但是在缺陷分配上，我們測試人員是直接分配給項目缺陷分配專員，缺陷分配專員一般是由業(yè)務分析員擔任。缺陷分配專員對缺陷進行分析后，再進行缺陷的再分配。對于缺陷分配專員處理為不修改的缺陷，測試人員需要進行確認。如果測試人員不認可缺陷分配專員的處理意見，可以同他進行溝通，或向相關(guān)人員（如項目經(jīng)理）提出自己的意見，最終以項目經(jīng)理的意見為準。在系統(tǒng)階段確認測試前的2~3天，測試組長會將系統(tǒng)未解決的缺陷清單給項目經(jīng)理確認，并要求項目經(jīng)理提供缺陷應對方案。缺陷應對方案在系統(tǒng)發(fā)布時，作為項目發(fā)布說明的附件。

我們是采用公司自主開發(fā)的缺陷管理系統(tǒng)進行缺陷管理的，使用excel、word進行其他測試工件的編寫的。

如何搭建一個高效的測試團隊

俗話說“工欲善其事，必先利其器”，要做好測試工作，首先需要建立并維護一個高效的測試團隊。然而，許多小型軟件企業(yè)卻將測試作為產(chǎn)品面臨發(fā)布時的一個小“插曲”，往往臨時抽調(diào)幾名程序員對產(chǎn)品的功能粗略測試一下即交付客戶（甚至在進度和成本不足時首先砍掉這一塊）。這種倉促完成的產(chǎn)品通常質(zhì)量問題很多，所以我們首先應拋棄小企業(yè)慣常的思維模式，不計較一時一地之利益，立足長遠，著手組建高效測試團隊。

第一步：招募測試人員

在國內(nèi)的軟件企業(yè)中有一種普遍做法，那就是把那些剛涉足軟件行業(yè)的技術(shù)新手或業(yè)績不突出的開發(fā)人員安排去做測試工作。筆者認為這絕對是一種欠妥當?shù)男袨椤Ｊ聦嵣希瑢σ粋€系統(tǒng)進行有效測試所需要的技能絕對不比進行軟件開發(fā)所需要的技能少，測試從業(yè)者甚至可能面對許多開發(fā)人員都不會遇到的技術(shù)難題。那么，測試團隊需要招募什么樣的成員呢？這里，筆者總結(jié)了以下兩點：

首先，測試人員要具備良好的溝通能力、自信心、外交能力、遷移能力以及懷疑精神。

其次，測試組成員應具備良好的專業(yè)技能或者技術(shù)學習能力。

當然，新招募的測試人員不可能像上面說的那么理想。關(guān)鍵是他們是否熱愛測試這項工作，對相關(guān)的工作內(nèi)容是否感興趣以及他們的學習能力如何。

第二步：測試團隊制度建設(shè)

良好的制度可以規(guī)范測試團隊的工作開展，同時也便于對團隊成員進行業(yè)績考評。相反,則很有可能導致人心渙散，滋長負面風氣。建設(shè)良好的測試團隊制度，可以考慮以下幾個方面：

? 匯報制度 團隊成員匯報本周工作情況及下周工作計劃、遇到的問題以及需要提供的幫助，培養(yǎng)團隊成員的匯報及計劃習慣。

? 工作總結(jié)制度 成員每個階段匯報上階段工作經(jīng)驗和教訓，并在部門例會上交流、分享經(jīng)驗及教訓，避免同樣的問題重復出現(xiàn)。

? 獎懲制度 對于貢獻突出的成員予以獎勵，對于業(yè)績差的提出批評，有效地保持測試團隊的工作熱情。

? 測試件審核制度 對測試件進行審核，去粗存精，鼓勵測試人員使用和提出改進，保證提交到測試團隊知識庫的測試件的質(zhì)量。

? 會議制度 定期召開部門例會，討論、解決工作中的問題，并提供部門內(nèi)的學習的平臺。

目前，已有不少軟件企業(yè)推行給測試人員區(qū)分級別的制度，獎優(yōu)罰劣。這無疑是一個好的做法，但成員業(yè)績的具體考評辦法，目前尚無可供參考的標準文件，所以筆者建議應盡量做到公正客觀，以免挫傷團隊成員的工作積極性。

第三步：測試團隊內(nèi)部的職責分工

明確測試團隊內(nèi)部各類測試人員的職責分工可以使測試團隊內(nèi)部各類測試人員能集中精力在較短的時間內(nèi)完成特定崗位必需的知識儲備和經(jīng)驗積累，同時也使得測試團隊的管理更科學，真正做到“用其所長，避其所短”。

第四步：測試流程建設(shè)

我們可以通過以下步驟來建立適合本單位的測試流程：

1.測試團隊負責人員根據(jù)對公司現(xiàn)有測試狀況的了解，及個人的測試經(jīng)驗，起草測試流程及相關(guān)的模板；

2.通過一到兩個項目的實踐，記錄測試流程草稿中的問題及不足之處； 3.根據(jù)實施經(jīng)驗，完善測試流程，得到測試流程初稿，并起草相關(guān)實施指南； 4.選擇一個到多個項目，實踐上述測試流程初稿及實施指南，記錄實踐過程中出現(xiàn)的問題；

5.根據(jù)上述實踐工作的反饋，組織修改測試流程初稿及實施指南，并把修改后的測試流程繼續(xù)應用到項目實踐中去，根據(jù)反饋進一步完善成熟；

6.測試流程及其相關(guān)文件基本趨于穩(wěn)定狀態(tài)時，可以考慮發(fā)布測試流程（含測試流程、模板、表格、指南），并在以后的實踐中不斷改進和完善。第五步：團隊成員能力的逐步提高

有了明確、合理的職責分工后，需要針對這些分工對團隊成員進行有意識的引導，穩(wěn)步提升團隊成員的技能。測試團隊負責人需要負起監(jiān)督和促進員工能力提升的任務。監(jiān)督和促進測試團隊成員能力提高，主要做好如下三個方面的工作:

一是，提倡資深測試人員在測試團隊內(nèi)部進行經(jīng)常性的培訓和測試經(jīng)驗交流，通過該渠道幫助資歷淺的測試人員大幅提升業(yè)務技能，做到新老員工之間的知識傳播和繼承。二是，測試團隊應充分利用好測試件知識庫，對于納入到測試團隊知識庫的測試件應充分消化和學習，在此基礎(chǔ)上進一步鼓勵測試團隊成員對這些測試件提出改進性意見。

三是，測試人員除了需要注重自身的測試技能提升，在條件許可的情況還應適度開發(fā)部門的基本知識，這樣能減少與開發(fā)團隊協(xié)同工作時的領(lǐng)域障礙。

第二篇：測試經(jīng)驗總結(jié)

1.測試人員和用戶的聯(lián)系與區(qū)別

黑盒測試人員和用戶，都是站在實際應用層進行操作，因此他們對應用層的可用性、實用性非常關(guān)注。用戶不懂的是軟件的使用，而相對用戶來說，測試人員對軟件比較了解，但不熟悉業(yè)務本身。

八個字歸納：用戶是用，測試是測。

用戶不懂使用就需要技術(shù)支持人員去培訓，而測試人員在測試初期經(jīng)過開發(fā)人員和項目負責人的簡單培訓后，就應該通過所學的理論知識和相關(guān)的業(yè)務知識獨立去了解、深入到軟件的功能點中。

應該做到：由測試人員培訓技術(shù)支持人員，由技術(shù)支持人員實施時給用戶培訓。

2.帶著問題去測試

阿豬工作守則第一條：帶著問題去測試

測試中會遇到很多問題，沒關(guān)系，沒有腦子里面的一個個問號，是不能很好的發(fā)現(xiàn)問題的。往往發(fā)現(xiàn)一些藏的很深的bug都是在測試人員一步步解決這些問號的過程中，切忌遇到問題就問，不僅因為增加不必要的與開發(fā)人員、負責人等的交流時間可能延誤項目進度，而且自己對問題的印象也不會很深刻，畢竟在相對較短的測試時間內(nèi)，聽不如記，記不如自己去發(fā)現(xiàn)規(guī)律。

3.測試期間提問題和交流的時機

什么時候應該提問題？

我們都知道，作為測試人員，并不是測試期間什么時候遇到問題就要馬上問，那什么時候是提問的時間？

培訓

培訓時，一般在講解內(nèi)容的間歇允許打斷，由培訓人員解答測試人員的疑惑。培訓的過程其實就是一個傳輸新知識并答疑的時間，這個期間的提問是歡迎的，也可以增加參與性和調(diào)動積極性。所以希望大部分的問題能在這個階段提出來。受時間、環(huán)境等條件制約，有時培訓的人講的也不一定細致和全面，這時就需要自己多想，想想這個功能是干什么的，為什么這么做，對應的業(yè)務是什么。

阿豬工作守則第二條：培訓時腦子靈活轉(zhuǎn)動，多想多問

以前大家可能有過參加辯論會的經(jīng)歷，就算沒有其實和人聊天也是一個交互的過程。參加辯論會要求快速思考，然后放慢語速說出自己的觀點，因為不能說錯。我們在參加培訓時前者相同，后者相反。腦子嘴巴都要快，說錯了也沒有關(guān)系，自己的想法被糾正的過程中也是加深印象和理解的過程。

計劃評審

提出對于軟件不理解、安排的任務不明白的地方。

測試期間

這個時期最主要的問題應該集中在影響測試流程和進度的問題，而不是說明書或其它文檔上已有的內(nèi)容，或者與自己負責模塊無關(guān)的內(nèi)容。開發(fā)人員和其他測試人員都有自己的進度安排，因此，影響測試流程和進度的問題,馬上問！

不影響流程的問題，記下來統(tǒng)一問！

不必要的問題（說明書或其它文檔上已有的內(nèi)容、講過三遍以上的問題、今晚去哪里吃飯的問題），不問！

好處：避免不必要的時間支出，不打亂自己的測試思路，一氣呵成，并且使項目成本得到控制

壞處（？）：腦子里、筆記本上留下一堆待解決的問號吧，浪費腦細胞和公司的筆和紙

張等資源

阿豬工作守則第三條：先做事，后學習

在有限的時間內(nèi)先完成該做的事，有空閑的時間再去補充自己的知識。

要很好的把握上述內(nèi)容，也要求提高培訓期間培訓人員培訓內(nèi)容的完善性，要求前期培訓人員強調(diào)出軟件的重點、難點和注意事項。這個期間適合于上面提到的“帶著問題去測試”的方法。

但有一點需要注意：不要為了一個地方的卡殼在那耗上一天半天的，這就不值得了。測試中期評審測試問題

答疑解惑的時間。

測試報告評審

對一些結(jié)論有疑惑和不解的地方，提！

4.記筆記

一個老生常談的話題。

阿豬工作守則第四條：好記性不如爛筆頭

測試培訓的時候?qū)τ谝恍┲攸c應該記下來，即使當時聽懂了；沒聽明白的更應該記下來，到測試軟件的時候去驗證自己的疑問。如果培訓時特別強調(diào)的地方，測試時再去問，這就不好了。

養(yǎng)成一個良好的習慣，會使以后的工作更加順利。

5.在公司和學校的學習的區(qū)別

學校是專門學習的地方，公司就是工作的地方，因此，它們的性質(zhì)決定了其學習內(nèi)容和方法的不同。

學校 公司 備注

內(nèi)容上 主要是系統(tǒng)的理論知識 主要是和項目相關(guān)的業(yè)務知識 如果在測試中感到自己部分理論知識欠缺時，就應該回家多補充了

時間上 大塊時間的連續(xù)學習相對鄰散 在公司一般不會拿出大塊時間來學習和講解 形式上 老師授課＋自學 培訓＋交流＋測試過程中自學

個人覺得，一個高效的測試流程應該如下：

a.花幾個小時至多半天時間快速閱讀瀏覽軟件說明書、設(shè)計文檔；

這個階段要讓腦子里面形成對軟件的整體印象感，能夠讓自己把握全局，因此，測試負責人安排時間看文檔時，決不能忽視它的重要性，否則就會出現(xiàn)后續(xù)階段磕磕碰碰的情況。注重速讀，把握軟件說明，忽略具體的數(shù)據(jù)庫設(shè)計、功能點設(shè)計、計算、規(guī)則和輔助工具（相關(guān)軟件）說明文檔，囫圇吞棗的方法在這里就顯得很有效。

如果項目時間緊或沒有文檔，這個步驟所做的事可以在下面完成。

b.利用培訓時間消化吸收的知識

c.軟件上手

幾個小時至多半天時間，熟悉軟件框架和基本功能，不要求所有功能都會操作，自己負責的模塊可以多側(cè)重一些。

d.細測

主要癥對計劃中安排給自己做的模塊，這時就要相對放慢節(jié)奏，每一步操作、每個對話框（操作界面）都要深究，別放過任何情況。這時會遇到一些錯誤或不理解的地方，明顯的如報錯就提到開發(fā)過程論壇，不明顯的就先記下來，等這個功能點測完再回頭去看，你會發(fā)現(xiàn)：

50％的問題可以自己分析出來和解決，有的問題不是問題，只是開始還沒有完全理解。阿豬工作守則第五條：軟件不是一次能測透的Rome is not built in one day.工期、人力、環(huán)境資料等，都制約著測試的深度和廣度，因為不要期望一次能完全把握某個軟件。

綜合測試的優(yōu)勢在于，我們負責公司產(chǎn)品的把關(guān)，而項目由產(chǎn)品延伸而來；測試產(chǎn)品會不斷出新的版本，一次沒有理解，可以在下一次中彌補，溫故而知新。

一口吃不成一個胖子，看我這么瘦又這么能吃就知道了^^

要結(jié)合自己的實際情況決定本次測試的深度，不要看著別人進度快了就打亂自己的節(jié)奏，只要安排合理，應該按照計劃來。特別忌諱認為自己這塊沒問題了就馬上去看看別人負責的功能，期望全能。這樣一般來說除了ljl這種全能性人物外都會造成最后自己的問題留了一堆，別人的也沒搞懂。

新人特別注意，踏踏實實的搞懂每個自己負責的模塊，打陣地站，這種方法很有效。評價自己是否可以轉(zhuǎn)入下個模塊的幾個因素：自我提問與別人提問、測試進度

如果大多數(shù)相關(guān)人員（主要是測試負責人、其他部分相關(guān)測試人員特別是開發(fā)組集成測試人員和技術(shù)支持人員）對于自己負責模塊的問題都能解答，搞定！NEXT-->轉(zhuǎn)入下個模塊。

否則，還是再回頭想想思路和遺漏的地方。當然，要綜合考慮測試進度。請組長對自己提幾個軟件的問題，他會很樂意的。

e.小結(jié)

一個階段就進行一次小結(jié)，這個小結(jié)可以是書面的，比如測試問題記錄、測試用例補充、測試模塊設(shè)計等，但大多是自己分析，為了方便接下來模塊的測試.f.性能測試

性能測試不僅是測試性能，同時也加深自己對軟件應用的理解，因為性能測試往往和實際應用或用戶需求結(jié)合的很緊密，避免造成軟件功能都會用，但不知用來干麻的尷尬情況。g.安裝盤測試

安裝盤程序測試，簡單過一下軟件功能有無錯誤。

安裝盤程序文件、庫文件、組件等的完整性、正確性，這個非常重要，要不返工就浪費時間了。這個階段要積極與開發(fā)負責人和GJ溝通，確保最后的勝利。

h.測試總結(jié)

測試接近尾聲，總結(jié)自己對軟件的掌握情況，得出測試結(jié)論、歸納測試方法、提出修改建議，為軟件以后版本的修改提供依據(jù)，也為以后再測類似軟件提供捷徑。

5.小結(jié)

? 用戶用軟件，測試測軟件

培訓時多想多問?

好記性不如爛筆頭?

帶著問題去測試，在測試中解決問題?

? 先做事，后學習，爭取雙贏

軟件不是一次能測透的?

第三篇：測試經(jīng)驗總結(jié)

6年測試工作的思考

前言

在公司已經(jīng)干了6年的測試了，干測試經(jīng)理也5年了。正好趁此機會把自己6年來一直想寫但沒寫的東西寫出來。這篇文件純粹是對自己工作的回顧。由于時間倉促基本上是想到什么些什么，有點兒亂，也請大家多多擔待了。只要還有些人能從中找到些兒同感，或從中得到一些幫助，一些經(jīng)驗，我就知足了。

1.什么是測試

首先我要談談什么是測試。相信好多測試人員跟我一樣，來公司之前也沒有從事過任何測試工作。對于測試都是從零開始的。也有好多人跟我一樣，從各種書上或是培訓中得到過有關(guān)測試的各種定義。但不知道大家有沒有凈下心思考一下。什么是測試。在公司公司測試工作的定義是什么，測試的工作范圍是什么。

測試的定義根據(jù)測試技術(shù)的發(fā)展，歷經(jīng)了3個主要的階段。第一個階段，認為測試就是找產(chǎn)品中的bug。第二個階段，除了找bug以外，又增加測試是對軟件質(zhì)量的度量這一概念。第三個階段，明確了測試是指為了度量和提高被測試軟件的質(zhì)量，對測試件進行工程設(shè)計，使用和維護的并發(fā)生命周期。注意其中提高的測試件，其主要是與軟件這個詞進行對應。明確測試也是一種開發(fā)過程。他的工作成果就是測試件，好像平時我們所謂的測試案例、測試腳本等等都可以稱為測試件。然后使用測試件去度量和提高被測試軟件的質(zhì)量。

目前，在中國大部分軟件企業(yè)，尤其是中小型的軟件企業(yè)還停留在第一階段。我個人覺得公司稍微好一點兒，處于一、二階段之間。因為我們平時做的最多的一件事，還是找bug。至于測試案例和測試腳本等等，只占用工作量的很小一部分。而且我看不到大家在平時的測試工作中是完全依據(jù)測試案例進行測試的。目前測試案例等工作更多的成為了一種形式上的產(chǎn)物。從有些部分所有產(chǎn)品的測試案例在一個下午就能評審完就能看得出來。

說到這里順便在談一句測試計劃。目前的測試計劃是作為產(chǎn)品計劃的一部分。先明確大概發(fā)版時間，然后是各個階段的里程碑，其中提交集成的里程碑是死的。開發(fā)需要的時間就是那么多，剩下倒推的時間就是測試的時間。這樣定出的計劃是否能夠起到計劃的作用就不好說了。現(xiàn)在的計劃更多的是羅列聯(lián)調(diào)測試的各種內(nèi)容，至于時間，不說也罷。所以從中也可以開出公司的測試也就停留在一、二階段之間。

明確了公司測試的定義（個人理解），也就不難理解公司給測試人員的定位了。在測試人員中經(jīng)常流傳的一種說法就是國外測試人員的地位多么多么的高，開發(fā)就是coding。咱們公司開發(fā)比測試多拿多少多少，測試人員地位是開發(fā)序列中最低的。大家也要看看人家公司測試人員的素質(zhì)，測試在開發(fā)過程中的重要性。再看看自己所從事的工作，就是找軟件的bug。當然我也個人認為有經(jīng)驗極其豐富的測試人員對產(chǎn)品的貢獻比開發(fā)和需求大。明確了這些，心里也就能少點兒不平衡感。

2.測試方法的思考

說完個人對測試含義的理解，再說說個人對測試方案的一些思考。

個人認為在公司6年，測試方法沒有什么提高。主要還是以黑盒測試為主。中間也曾經(jīng)引入過各種各種工具，但測試人員真正用起來的也就是robot。而且robot主要是進行回歸測試，再加上一些人并沒有真正認識到其價值，應用范圍也極其有限。對整體測試效率的提升影響不大。所以目前的測試方案還主要是以需求為依據(jù)的黑盒測試。至于什么極限值了，成對測試法等等，都是建立在黑盒測試的基礎(chǔ)上，而且從我一來公司就有相應的測試項目，只不過沒有明確概念而已。

另一個說個人覺得6年來公司測試方法沒有什么提高的原因是，6年前測試是以人為主，靠得是測試人員的經(jīng)驗，對產(chǎn)品的熟悉程度，對業(yè)務的理解程度。6年后測試還是以人為主，人就是測試的主體，產(chǎn)品質(zhì)量的保證。還沒有過渡到測試案例就是測試的主體，測試案例的完整性是產(chǎn)品質(zhì)量的保證。只要測試還是以人為本，我覺得測試的效率就不會有太大提高，產(chǎn)品質(zhì)量的信心來源也是對相關(guān)測試人員的信任。我個人覺得以黑盒測試為主要的測試方法沒錯，而且也比較符合目前公司的測試現(xiàn)狀。但一定要注意各種經(jīng)驗的總結(jié)、積累，更重要的是共享。雖然目前測試案例在測試工作過程中的地位不重要，但其畢竟是編寫者的經(jīng)驗積累。匯總起來也是一筆可觀的財富。可現(xiàn)在如果有人問我850的測試方案在那里，其中還有多大比例能夠用在現(xiàn)在的產(chǎn)品中，在現(xiàn)在的測試工作中有多少以前的案例能夠復用。其他產(chǎn)品中的測試案例中有多少是關(guān)于接口功能，有多少我可以借鑒。我不知道，這也是自己工作不到位的地方。所以我要說的作為黑盒測試為主要的測試方法，一定要注意測試經(jīng)驗的總結(jié)和共享。

而且我認為一個人如果黑盒測試能做到位，做到最后培養(yǎng)的是一種測試的感覺。測到最后，產(chǎn)品你一看就能知道那里可能有問題，那里應該沒什么問題。這樣有重點地投入測試力量可以收到事半功倍的效果。可這是需要大量測試經(jīng)驗的積累的，不是我告訴你，你就知道的能力。在此前提上加強測試人員之間的橫向溝通，形成經(jīng)驗貢獻。可以較快的培養(yǎng)測試人員的測試感覺。

最為測試經(jīng)驗積累的另一個重要方法就是加強對測試案例的要求和管理。每版測試案例不僅要包括新增功能，還需要包括上一版本中繼承的案例，修改或刪除上版案例中變更的內(nèi)容。從而形成一份完整的關(guān)于產(chǎn)品所有功能點、接口、升級、年結(jié)等等各方面的測試案例。真正做到測試案例是測試的主體，從而提高測試效率，提高產(chǎn)品質(zhì)量。

3.測試工具的概念和作用

測試工具，什么叫測試工具。我認為任何能提高你測試效率的工具都可以稱之為測試工具。不僅僅指robot或是loadrunner這類專門的測試工具，也不僅僅指使用各種編程工具編寫的測試工具。像總賬工具、eai等，即使只是幫我們導入一些常用檔案，也可以節(jié)約我們的測試時間也可以稱之為測試工具。

我個人現(xiàn)在公司測試在測試工具開發(fā)上還很不足。在公司里一提起測試工具，大家第一個想到的可能就是robot。即使是robot應用的也不夠深入。大家經(jīng)常認為robot主要錄制gui的腳本，跟產(chǎn)品界面聯(lián)系緊密。每次回放成功率不高，各個版本間腳本復用率也較低。而且每次總是以各種理由將腳本錄制放到最后，經(jīng)常就不了了之了。最后階段的測試任務實在太緊。我想說的是robot的應用雖然有各種各樣的局限性，但其畢竟提高了測試效率。比如說安裝盤驗證，使用robot驗證，每天都可以節(jié)約一半以上的驗證時間，這就是效率。認識了它的好處，才能想盡辦法解決或避免在robot使用中的各種問題。以前同事有一套robot腳本規(guī)范就很好，使用后不僅提高了回放成功率，而且回放中斷后，繼續(xù)回放也變得很容易。所以說使用robot后，想100%回放成功不可能，想不再進行腳本的調(diào)試也不可能。認識這兩個問題后，就需要加強robot使用經(jīng)驗的總結(jié)和共享，有針對性地加強robot使用問題的研究，每版測試開始時針對上版robot腳本的復用問題進行研究。這樣才能用好它，真得使之成為一個工具，而不是一項任務。

一種工具也不是萬能，有許多針對產(chǎn)品特性的測試工具。只能自己開發(fā)，大家應該積極提需求。凡是認為有可能提高測試效率的工具需求都可以提。能從網(wǎng)上找到現(xiàn)成的工具解決需求更好。不能，如果是普遍性的需求，可以專門進行開發(fā)。因為咱們產(chǎn)品的特性，每版間測試工具的復用度很大。從長遠看就是節(jié)約開發(fā)成本，縮短開發(fā)周期。

在現(xiàn)階段加大測試工具的適用范圍和力度，用好各種測試工具，可能是提高整體測試效率最快最好的方法。但一定要加大推廣的力度。否則有了好的工具，沒人用或用不起來也是沒用。

4.如何看待各種規(guī)則和執(zhí)行

可能大家覺得平時開發(fā)過程中有好多規(guī)則、制度。這些除了一些自己公司內(nèi)根據(jù)各種情況制定的外，大部分都是跟cmm體系相關(guān)的一些規(guī)則。可以說是已經(jīng)被許多軟件公司驗證過，可以提高開發(fā)和測試效率的規(guī)則。但好多人覺得起沒有什么用，就是在浪費時間。總是以一種完成任務或是應付差事的心情去做。我覺得大家之所以覺得其沒用，恰恰就是由于你去做這件事的動機不對。總以應付差事的心情去做，你就不可能真正理解這么做的目的，這樣做能給你帶來什么好處，你從中會得到什么收益。所以我個人認為，既然有規(guī)則，不管是公司自創(chuàng)的或是借鑒其他標準，都是為了解決開發(fā)過程中的問題，為了提高開發(fā)的效率，保證產(chǎn)品質(zhì)量。也許這些規(guī)則中有這樣那樣的不合理，但只有你認真地去做了，才能發(fā)現(xiàn)其中的不妥之處，才能改進，才能更有助于你的工作。

執(zhí)行也是我覺得在工作中需要進一步加強的環(huán)節(jié)。許多規(guī)則就是因為執(zhí)行力度不足，才容易讓一些人找到空子，應付了事。但怎樣加強執(zhí)行力度，還是一個需要大家一起進行探討的問題。

5.作為一名測試人員應該具有的素質(zhì)

測試人員應該具有什么樣的素質(zhì)，相信好多人都有自己的理解，不同書上的觀點也不盡相同。我就說說我在公司工作了六年，覺得一個合格的測試人員應該具有什么樣的素質(zhì)。業(yè)務和測試方面的能力就不說了。

測試人員應該具有的素質(zhì)包括： 1.踏實細心和積極主動

我覺得作為一名測試人員首先要踏實細心。測試人員每天都要面對著枯燥的程序，從事著大量的重復工作，還要盡量發(fā)現(xiàn)產(chǎn)品中的bug。如果不踏實，你就坐不住，總想干別的，就無法凈下心來想用戶有可能怎么用，需求對產(chǎn)品是怎么要求的，現(xiàn)在產(chǎn)品中是怎么做的，哪里可能存在問題。不細心，就特別容易一些產(chǎn)品中微笑的錯誤，而恰恰就是這些錯誤是最影響產(chǎn)品形象的問題。

至于積極主動就不多說了。這是每個人都應該具有的素質(zhì)。2.懷疑一切

不抱著懷疑一切的態(tài)度就不是一名合格的測試人員。經(jīng)過你手測試的產(chǎn)品面對的是直接用戶。你不認真負責，不抱著懷疑一切的態(tài)度。總想著這個功能本版沒動應該沒什么問題，這個功能沒什么用戶用不用認真測了。這樣發(fā)出的產(chǎn)品，我是不敢讓用戶用。因為用戶用起產(chǎn)品來是千奇百怪，有些用戶的水平和對產(chǎn)品的理解比咱們還要深。所以一定要抱著懷疑一切的態(tài)度，認為產(chǎn)品每個功能都可能有問題，認真地測試產(chǎn)品的每一個測試點。

3.協(xié)作和團隊感

協(xié)作和團隊感也是十分重要的。要意識到測試、開發(fā)、需求是一個團隊，一個整體。離了誰，產(chǎn)品的質(zhì)量都無法保證。誠然有個別開發(fā)人員責任心不強，經(jīng)常將未經(jīng)任何驗證的代碼編譯后發(fā)給測試進行驗證。耽誤了測試人員不少的時間。但越這樣，測試人員越應該負責，否則產(chǎn)品發(fā)出去影響的是公司的形象。

還有個別開發(fā)人員開不起測試。此時就需要你通過各種方法去證明你自己的能力。比如測試出他根本就沒考慮過的問題等等。以實際行動證明你離不開我，咱們是一個水平的。只有這樣加強協(xié)作和團隊建設(shè)，加強整個團隊的質(zhì)量意識，才能提高開發(fā)效率，保證產(chǎn)品質(zhì)量。

4.自我提高和總結(jié)的能力

測試人員經(jīng)常很迷茫，不知道自己的發(fā)展方向在哪里。測試技術(shù)還是專業(yè)知識。領(lǐng)導們所謂的個人發(fā)展方向考慮也經(jīng)常是畫一個餅在那里。這時就只能靠我們自己了。看你想今后從事哪方面的工作。一般情況下，如果升不到管理層就只有兩條路可選了。一是業(yè)務精通，將來可以向需求或是售前、實施方向發(fā)展。一是技術(shù)精通，多掌握幾種測試工具，又能力可以學習一些編程方面的知識。將來還繼續(xù)從事測試方面的工作。隨著中國軟件開發(fā)的規(guī)范化，這條路也是很有發(fā)展的。

另外，我覺得作為一名合格的測試人員，一定要注意進行總結(jié)。通過總結(jié)可以對自己的工作進行一個回顧分析，看看那些做得不錯，下次還繼續(xù)這么做。那些工作還有改進的余地。對自己能力的提高是一個很好的幫助。

6.作為一名測試經(jīng)理應該具有的能力

作為一名測試經(jīng)理，我覺得除了具備一個測試人員應該具備的素質(zhì)外，還應具備以下能力。

1.出色的溝通和協(xié)調(diào)能力

由于測試人員和開發(fā)人員的工作性質(zhì)，必然導致測試人員和開發(fā)人員在工作中會產(chǎn)生沖突，對同一問題會產(chǎn)生不同的看法。這時，你怎么去協(xié)調(diào)，去溝通，解決這種矛盾，讓自己所在的開發(fā)團隊中極少的受此影響，就是考驗你能力的時候。

2.條理性和計劃性

作為測試經(jīng)理，要負責帶領(lǐng)團隊內(nèi)的其他測試人員全面的測試產(chǎn)品。由于測試項目很多，不僅包括產(chǎn)品功能，還要包括效率，性能，壓力，并發(fā)互斥，環(huán)境等等方方面面。此時你如何去安排這些測試項目，哪些可以先做，哪些可以并行。與開發(fā)人員在一些項目的測試中如何協(xié)調(diào)就是考驗你做事的條理性和計劃性。

3.從全局考慮產(chǎn)品測試的能力

每一個測試人員在產(chǎn)品測試中，重點肯定是自己負責產(chǎn)品的功能，此時就容易遺漏其他的一些測試項目。有可能是接口的部分功能，又可能是升級或年結(jié)的部分功能。此時，你如何提請他們還有漏測的功能點。在有限時間內(nèi)，能找出他產(chǎn)品測試上的薄弱點，就是考驗你通盤考慮產(chǎn)品測試的能力。

后記

上面就是我對6年測試工作的一個回顧。這些都是我個人的一些觀點，很不全面，也有不正確和遺漏的地方。大家看后，能從中得到一些自己需要的東西，我就知足了。

再次感謝在這6年中給了我許多幫助和支持的各位兄弟姐妹們。

附錄A、QA工作心得

看過許多同行兄弟姐妹的工作感受，反映了一些從事QA工作過程中的困惑，心里也很有同感。之前做過幾年的測試工作，到了新的公司開始做QA工作，雖說測試工作也是屬于質(zhì)量工作范疇，但是真正干起來才發(fā)現(xiàn)，還是有很大的不同的，尤其是思想方法和工作方法上。所以也是邊學邊干，這邊和大家分享一點心得。

1、調(diào)整好自己的心態(tài)。

尊重開發(fā)人員、產(chǎn)品經(jīng)理、項目經(jīng)理等項目組內(nèi)同事，不要把自己定位為監(jiān)工，要把自己定位為服務員。如果你真的是從心里想幫助大家把事情做好，而不是教訓別人，大家會感受到的。很多時候，調(diào)整好自己的心態(tài)才是難點。

2、有的放矢 不要盲目的發(fā)表意見，要做到有理有據(jù)，這也是避免項目組內(nèi)成員產(chǎn)生爭執(zhí)和不理解的前提。在提出意見和建議前，最好做一下調(diào)查，收集一些資料和數(shù)據(jù)，或者和大家深入的聊一聊，開一些交流會，座談會，收集到一線開發(fā)人員的真實感受，不要自己一覺得有問題就沖出來，這樣肯定會被別人反感，也會降低大家對QA的認同和信任感。

3、數(shù)據(jù)說話

質(zhì)量工作相對務虛不假，之前做測試好歹還有很多的bug擺在那里，剛開始做QA工作確實覺得虛了很多。自己的產(chǎn)出在哪里？后來發(fā)現(xiàn)，其實還是可以有很多的，呵呵。你可以給相關(guān)人員進行培訓（質(zhì)量知識、軟件工程知識、產(chǎn)品開發(fā)知識、質(zhì)量制度和規(guī)范等等），會議記錄和培訓資料算是你的產(chǎn)出的一部分。另外，對于項目過程中產(chǎn)生的問題，變更等，要有記錄，一定周期內(nèi)作出分析和報告，比如，變更發(fā)生率，項目延期的原因分布，與計劃的不符合程度等等。進一步提出改進建議，有了這些數(shù)據(jù)支持，你提出建議也就更有說服力。

4、溝通再溝通

其實很多問題都是發(fā)生在溝通上，我覺得溝通好了，起碼可以解決70%的問題。多為大家提供交流和溝通的機會，比如，發(fā)起一個交流會，讓組內(nèi)同事互相培訓，形成一個良好的內(nèi)部學習交流氣氛。另外，什么也比不過面對面的溝通，拋棄聊天工具和email吧，走過去，和你的同事一起好好聊聊，吃飯的時候，坐車的時候，你會發(fā)現(xiàn)很多深入的問題的，呵呵。

5、循序漸進

規(guī)范制定好了，不要一下子就想完全推行到底。畢竟要改變別人已有的習慣，是會讓別人不舒服的，呵呵。所以要循序漸進，分期分批，一點點來，習慣慢慢的就被改變了，這樣大家就不會太抵觸。而且，在分期分批推行規(guī)范的過程中，別忘了不斷收集反饋意見，不斷改進和修正規(guī)范，規(guī)范可不是qa說是什么就是什么的，一定要收集大家的意見，達成共識，這樣才有被大家執(zhí)行的基礎(chǔ)。

6、展示自己

QA工作務虛，但是可以落到實處，是有很多實際工作要做的，比如文檔編寫，規(guī)范起草。培訓、評審、跟進問題。這些工作的成果如何體現(xiàn)，效果如何，可以通過一些問卷調(diào)查，來收集大家的反饋，舉個例子，如果推行產(chǎn)品開發(fā)流程規(guī)范前大家對流程的滿意度是50%，推行規(guī)范兩個月以后，滿意度成了90%，你說這是誰的功勞呢？呵呵，這也是數(shù)據(jù)說話的一個方面，也是QA工作成績的展現(xiàn)。說了這么多，其實我做QA工作也只有3個月，還有很多的不足，希望能和大家多多的交流，如果自己的一點心得，能夠給大家一些幫助或啟發(fā)，就深感欣慰了，呵呵。歡迎拍磚！

附錄B、SQA之Q&A 軟件質(zhì)量保證，即 SQA，全稱是 Software Quality Assurance。

問： SQA 目的是什么？

答： 對于任何的行業(yè)，講到質(zhì)量控制，歸根結(jié)底都是為客戶提供更高品質(zhì)的產(chǎn)品，更好地滿足客戶的需求。質(zhì)量有問題的話就不能滿足客戶的需求。在 CMMI 里邊就有 “ 集成流程產(chǎn)品開發(fā) IPPD(Integrated Product & Process Development)”，為什么要集成呢？就是說產(chǎn)品的研發(fā)不僅僅是開發(fā)團隊的工作，還要把市場團隊、銷售團隊、整個的流程、包括客戶的反饋都要考慮進來、集成進來。目的是為了什么？其實就是為了更好地滿足客戶的需求。六西格瑪里面說 DPMO(Defect Per Million Opportunities)，百萬產(chǎn)品里有缺陷的產(chǎn)品只有三個。這是為什么？就是為了減少差錯，從而讓客戶享受非常高質(zhì)量的服務。

問： SQA 等于測試？

答： 測試其實只是 SQA 的一個環(huán)節(jié)，SQA 的全稱是軟件質(zhì)量保證。在國外很多的大型的企業(yè)，比如說摩托羅拉、愛立信，他們的研發(fā)團隊里面都專門有一個 QA 部門，其實他們并不是做測試工作的。QA 部門其實是管理開發(fā)流程的執(zhí)行，并專門負責制定產(chǎn)品開發(fā)流程。比如說 RUP 里面有一個角色，叫 Process Engineer，過程工程師，他就屬于 QA 部門，他的工作就是負責制定整個軟件開發(fā)的流程。因為如果說要保證質(zhì)量的話，不能只靠測試來保證。而必須在整個開發(fā)流程的各個環(huán)節(jié)都要做得很好，才能夠真正地提升軟件的質(zhì)量。而測試只是整個開發(fā)流程最后的一個階段。所以說一個好的流程就決定了一個軟件的開發(fā)能不能按時交貨，能否保證軟件質(zhì)量。這個流程就是由 QA 部門來制定的。QA 部門還有另外一個職責，就是保證整個研發(fā)團隊能夠嚴格按照這個流程來運作。在項目到達每一個里程碑的時候，QA 部門的 QA 經(jīng)理就會介入，對項目做一個審核，檢查前一階段的工作是否按照公司制定的流程來運作。看看該有的工件是不是都有了，該有的步驟是不是都有了。開發(fā)團隊要證明給 QA 人員看。只有過了這一關(guān)，QA 部門才會同意說開發(fā)團隊可以往下走，進行下一步的工作。所以嚴格來講，眾廣義上理解，SQA 是針對整個軟件開發(fā)流程的，它關(guān)心的是怎樣在軟件開發(fā)生命周期中來保證好軟件的質(zhì)量。這是一個非常大的概念。

問： SQA 在 RUP 中是如何體現(xiàn)的？

答： 其實 RUP 整個流程都在講 SQA。業(yè)界常見的模型，譬如 CMM/CMMI，六西格瑪，ISO9000，RUP，它們做的基本上是同一件事情--都是在做流程改進，都在做質(zhì)量控制，但是各自的側(cè)重點不一樣。像 RUP 和 SDP 專門側(cè)重于從軟件開發(fā)的整個生命周期來保證軟件質(zhì)量，所以對軟件開發(fā)商特別適合。而其它的模型，側(cè)重點則在其它的環(huán)節(jié)，比如說 ISO9000，用在制造業(yè)比較多一些； CMM，原來是應用在軟件這個行業(yè)的，后來擴展到 CMMI，就擴展到其它行業(yè)它也適用。但適用面越廣，它拉的層次就越高，可實際操作的東西就越少。RUP 是專門側(cè)重于軟件項目開發(fā)的。怎樣來保證做好 QA 呢？ RUP 里定義了一個軟件生命周期模型，分成四個階段--初始階段、細化階段、構(gòu)造階段、交付階段，每個階段有不同的側(cè)重點，通過多次的迭代，每次迭代里面都要做質(zhì)量控制。

質(zhì)量控制從需求開始，有很多需求分析和需求管理方面的技巧和技術(shù)方法，它們從需求方面來保證軟件的質(zhì)量；到了設(shè)計，就有很多成熟的設(shè)計方法，例如可視化建模，基于構(gòu)件的架構(gòu)設(shè)計和現(xiàn)在提出的模型驅(qū)動開發(fā)方法；再到實現(xiàn)，到測試等方面，都有很多的方法和技巧來提高軟件的質(zhì)量。這里面每一個環(huán)節(jié)的目的都是為了提高整個軟件開發(fā)的質(zhì)量。

開發(fā)過程中，什么樣的問題會造成質(zhì)量問題呢？其實最主要的就是溝通方面的問題，以及對系統(tǒng)復雜度把握程度的問題。我們逐漸發(fā)展了一些技術(shù)來幫助我們解決這些方面的問題，例如用 UML 這種標準化的語言來增強團隊的溝通，用面向?qū)ο蟮募夹g(shù)來幫助加強對復雜度的控制能力。

原來這個系統(tǒng)很復雜，使用面向?qū)ο蟮姆椒ǎ旧砭褪菫榱撕喕到y(tǒng)構(gòu)建的復雜度。改變你看問題的角度，你對問題的把握程度就會不一樣。譬如人看一個二維迷宮很容易就能找到出路，但螞蟻在里面就走不出來，因為看問題的角度不一樣。面向?qū)ο蠓椒ê涂梢暬＜夹g(shù)可以讓開發(fā)人員可以更好地去把握系統(tǒng)，增強對系統(tǒng)的可控制能力，從而從這些維度上來提高和保證軟件的質(zhì)量。

現(xiàn)在有很多自動化的工具，如 IBM Rational RAD(Rational Application Developer)/ RSA(Rational Software Architect)，都是支持 MDA 的開發(fā)方法，在模型這一級進行開發(fā)，從模型直接生成代碼。在開發(fā)方面我們有很多輔助工具，幫助開發(fā)人員盡量將人工做的工作、復雜的重復性的工作、不具有創(chuàng)造性的工作讓工具來做。讓人去關(guān)注他應該關(guān)注的方面，比如開發(fā)人員應該關(guān)注業(yè)務邏輯的處理，但是軟件的構(gòu)建方面我們是盡量讓工具來降低構(gòu)建細節(jié)上的難度。這樣也是有助于提高質(zhì)量的。

然后產(chǎn)品出來了，需要進行測試，有測試流程、測試規(guī)范來幫助保證質(zhì)量，這是最直接的。然后還有很多的環(huán)節(jié)還會發(fā)生錯誤，比如配置管理、版本的管理，也需要相關(guān)的支持來保證軟件的質(zhì)量。所以說軟件質(zhì)量保證不應該只是在一個環(huán)節(jié)上，比如測試環(huán)節(jié)來保證，而應該是整個的流程，我們應該全面地去改進流程來保證質(zhì)量。

問： 做 SQA 這方面的人員，在溝通方面需要的什么樣技巧和能力？

答： 首先從大的方面說，整個團隊的溝通，首先是大家要講同樣的語言。UML 只是這種語言的一部分，我們不要狹義地理解這種溝通語言就是 UML。它還包括采用一個什么樣的流程方法，整個團隊都要理解。譬如你說項目正處于 “ 精化(Elaboration)” 階段，這個團隊都要能理解這個術(shù)語。

還有就是整個組織機構(gòu)內(nèi)部大家采用的流程都是要一樣的。舉個例子來說，Rational 有很多產(chǎn)品，其中很多都是收購來的。不同的產(chǎn)品團隊采用的開發(fā)方法、開發(fā)工具都是不一樣的，他們到了 Rational 之后做的第一件事就是整合。這個整合一方面是說產(chǎn)品要整合起來（我們有 Suite 產(chǎn)品）；同時也是針對開發(fā)團隊開發(fā)方法的整合，例如 Rational 花了一兩年的時間把所有產(chǎn)品團隊統(tǒng)一到 RUP 和 ClearCase/ClearQuest平臺之上，這是我們的首選。實際上到了 IBM 之后也是一樣，IBM 現(xiàn)在正在做的計劃就是讓所有的實驗室、研發(fā)團隊都要使用 IBM Rational 自己的開發(fā)工具，他們都在使用 IBM 自己的開發(fā)方法、開發(fā)平臺。這就是讓大家的溝通基于一個統(tǒng)一的基礎(chǔ)架構(gòu) ―― 統(tǒng)一的軟件開發(fā)平臺，這也是增強溝通的一種方式。另外，講到 SQA 的人員，在 RUP 里對應的就應該是 Process Engineer。他的主要的職能就是定義流程，保證流程的執(zhí)行，并且不斷地改進流程。對他的要求就是要對流程要比較了解，有實際項目的開發(fā)經(jīng)驗，不然沒有辦法理解流程，這是技能方面；另外就是與人的溝通能力要強，跟一般的開發(fā)人員和項目經(jīng)理是有區(qū)別的，溝通的能力一定要強，他要負責說服項目團隊來遵循標準。

問： QA 人員與目經(jīng)理和開發(fā)人員之間的關(guān)系是怎樣的？

答： 首先彼此之間是一個合作的關(guān)系。如果片面理解 QA 人員只是 “ 過程警察 ” 的話，就可能把他和其他的角色對立起來了。實際上在一個團隊內(nèi)部要避免這種認識。因為大家都是在一個組織架構(gòu)內(nèi)部的，大家的目標是一致的，就是要把公司的業(yè)務做好。所以 QA 人員的職責和任務就是幫助這個項目團隊更好地進行軟件的開發(fā)。既然已經(jīng)定義的流程是比較適合企業(yè)的，項目就應該遵守這個流程來進行開發(fā)。如果有時候項目因為趕工，或是其它的原因違背一些流程上的規(guī)定的話，就會對軟件的質(zhì)量會造成一定影響，他就有責任來幫助開發(fā)團隊來糾正這方面的一些錯誤。還有就是進度方面的問題。如果不按照流程來走的話，短期內(nèi)看起來進度是快了一點，但從整個項目的周期來看，有可能是給以后的工作帶來隱患，客觀上肯定是延長整個開發(fā)的進度的。所以對于一些流程管理得比較好的企業(yè)，你會發(fā)現(xiàn)他們的 QA 部門和開發(fā)團隊是相處得比較融洽的，配合是比較緊密的。在我們的客戶里就看到過他們的開發(fā)團隊非常感謝自己的質(zhì)量控制人員，覺得他們對自己是給了很大的幫助。

QA 人員跟每一個角色的關(guān)系，如果你對應到 RUP 的話，RUP 里就定義好每一個角色是做什么工作的。RUP 里分了 9 個規(guī)程(discipline)，流程工程師是在環(huán)境規(guī)程里邊，項目經(jīng)理是在項目管理規(guī)程里邊。每一個規(guī)程其實就是一類開發(fā)活動，其中的角色和他們所產(chǎn)生的工件集合，是一個分類。可以把項目經(jīng)理相關(guān)的工作，他所涉及到的工件，比如說軟件開發(fā)計劃、風險管理計劃、質(zhì)量保證計劃都放在一起，放在這個規(guī)程里面。所以 QA 人員跟項目經(jīng)理的關(guān)系就是去檢查項目經(jīng)理在這個崗位上所做的職責是否到位，是不是跟流程相符合。其他的角色也是一樣的，譬如一個測試人員，就要看你有沒有根據(jù)規(guī)定把缺陷按正確的測試流程匯報，發(fā)現(xiàn)缺陷之后是否能夠得到改正，并作一個復審，還有回歸測試的時候有沒有考慮測試的完備性等問題，就是看測試人員有沒有做好具體的工作。QA 人員和整個項目團隊在工作中的關(guān)系就是看每一個角色是不是很好地完成了自身角色所應該完成的開發(fā)任務。標準是什么？就是這個組織的流程，流程是保證質(zhì)量很重要的一個依據(jù)。

問： QA 人員如何判斷其工作效果和質(zhì)量？

答： 最直接就是 RUP 里的工件。可以去檢查這些工件，可以根據(jù)檢查的結(jié)果來判斷角色是否達到了要求。既然是檢查這個結(jié)果的話，就有必要涉及到統(tǒng)一流程和工具的問題。就是說開發(fā)團隊有必要采用統(tǒng)一的開發(fā)方法和流程。不然的話每一個開發(fā)團隊各自采用不同的開發(fā)流程，流程工程師就很難去評價，沒有一個可對照的標準，沒有可比性。另外，和采用的工具也有關(guān)系，就是說團隊要盡量采用統(tǒng)一的開發(fā)平臺。采用統(tǒng)一的開發(fā)平臺，工具會幫助自動收集很多的信息。比如說我們的 Project Console 可以幫助收集很多量化的指標；現(xiàn)在有 Portfolio Manager，項目組合管理平臺，可以幫助了解項目進度還有項目進行過程中產(chǎn)生的各種結(jié)果；還有包括測試的報告等等，這些都最好有一個統(tǒng)一的標準。打個比方來說，現(xiàn)在的航空公司都會選擇相同飛機制造廠商的機型，就是要降低維護的成本。因為機型比較統(tǒng)一的話，就比較好進行管理。在一個軟件企業(yè)的話，在內(nèi)部采用統(tǒng)一的軟件開發(fā)平臺也能有助于企業(yè)判斷項目的情況，判斷的方法也會相對比較簡單，工作量會降低。

這是從 QA 的角度來看，其次從整個團隊的角度來說，今天是做這個項目，明天做另外一個項目，作為企業(yè)的管理人員肯定不希望員工今天做這個項目用一個工具，明天做另外一個項目用另外的工具，這樣學習成本就太高了。

第四篇：稿件管理系統(tǒng)測試項目經(jīng)驗總結(jié)

稿件管理發(fā)布系統(tǒng)測試項目經(jīng)驗總結(jié)

經(jīng)過近兩周時間，稿件管理發(fā)布系統(tǒng)測試工作基本完成了，收獲很多，但還有很多不足，希望在之后的學習中以此為借鑒，完善測試過程。收獲：

（一）了解了做一個項目的大概步驟；要想做一個好的項目，測試要貫穿整個開發(fā)過程，在做項目之前要做好充分的準備，如環(huán)境配置、文檔準備、資料收集等。在一個項目中至少要有以下幾個文檔：需求分析報告、測試設(shè)計報告、測試用例設(shè)計報告、bug報告及測試報告。對一個測試人員來說，測試設(shè)計報告是一個前提，首先要保證測試設(shè)計合理，并且內(nèi)容齊全。這樣才能更直接、準確地進入下一項目步驟。測試用例是整個項目的重點，在一個項目中測試用例必須經(jīng)過三方面的評審，評審通過才能執(zhí)行。一是自我檢查，二是測試人員互相評審，三是項目經(jīng)理評審。一個好的測試用例要覆蓋全測試需求，測試用例的設(shè)計要合理、正規(guī)。測試用例不在于多，要在于覆蓋全，測試用例的多少在一定程度上并不代表質(zhì)量的高低，所以說，測試人員對于測試用例的設(shè)計一定要細心且全面。接下來是bug記錄，在bug記錄中一定要詳細給出測試的重現(xiàn)步驟。一個bug報告中所包含的標題有：缺陷ID、缺陷標題、缺陷描述、缺陷的重現(xiàn)步驟、缺陷的嚴重級或者優(yōu)先級、測試模塊、缺陷提交人、缺陷的版本及證明是缺陷的視頻或者截圖等。最后是測試報告，在測試報告中最突出的問題就是測試缺陷的分析，測試用例中缺陷有多少，通過率是多少，有哪些建設(shè)性的意見，及最終得測試結(jié)果，是通過還是沒通過。

（二）了解了如何寫測試計劃、測試用例、bug報告、測試報告等；

1、測試計劃的內(nèi)容包括引言、測試背景、測試組織結(jié)構(gòu)、測試策略、測試計劃、測試環(huán)境及測試總結(jié)。在整個測試計劃中最重要是測試的詳細計劃，當然在測試之前，要評估好測試的工作量分配及進度安排，人員規(guī)劃等，測試計劃的書寫要有一定得邏輯，要能夠真實反應測試項目。測試進度的安排要合理。

2、測試用例報告是一個項目中的重點，描寫一個測試用例包括測試需求ID、測試需求標題、用例ID、用例步驟、期望結(jié)果、測試結(jié)果、測試人員、所屬模塊、嚴重級、備注等。在測試用例報告中重點在于測試步驟

要盡可能地詳細，測試需求、標題等要描述清楚。

3、Bug報告也是測試項目中的重點，也是最讓人有成就感的報告，bug報告中缺陷要描述清楚、正確評估缺陷的嚴重級別。

4、測試報告是一個項目的總結(jié)性報告，測試報告主要包括引言、測試設(shè)計簡介、測試結(jié)果分析、測試結(jié)論及建議。

（三）了解了如何有條理地書寫測試用例；首先測試用例要覆蓋需求，根據(jù)項目的需求分析或者軟件，設(shè)計測試用例。其次，寫復雜的測試用例要掌握一些方法。例如決策表法，要先把影響因素和測試用例的個數(shù)做成表格形式，以便于詳細分析設(shè)置用例的多少。在設(shè)計測試用例的過程中最常用的是等價類劃分法，基本上每個測試用例的設(shè)計都要考慮正反兩個方面。在這劃分過程中遵守著盡量覆蓋尚未覆蓋的有效等價類，僅覆蓋一個尚未覆蓋的無效等價類原則。

不足：

1)需求分解不徹底；在本次項目執(zhí)行過程中，我們發(fā)現(xiàn)在需求手冊中很多地方描述很模糊或者很簡單，不能很好地向設(shè)計者呈現(xiàn)要設(shè)計軟件的細節(jié)操作步驟，從而，對于軟件測試人員來說就很難辨別測試結(jié)果是否符合要求，換句話來說，如果一個測試人員想把需求描寫的很模糊的地方測試清楚就必須和客戶不停的交流、溝通，在一定程度上影響項目的進度。以上是從客戶需求角度來說的。對于客戶只提供軟件而沒有需求的情況下，項目組人員就要人怎分析測試需求，詳細分解。

2)測試用例覆蓋不了測試需求；一開始感覺設(shè)計的測試用例可以覆蓋需求了，但是執(zhí)行后才發(fā)現(xiàn)很多細節(jié)部分沒有寫全，例如稿件管理發(fā)布系統(tǒng)用谷歌瀏覽器打開就會出現(xiàn)很多錯誤，稿件管理系統(tǒng)在瀏覽器的應用上存在一定得兼容性問題，等等。針對這種情況，我們需要在執(zhí)行之前，詳細地了解用戶需求及真實軟件的運用效果。兩者相結(jié)合，設(shè)計更全面的用例。

3)對bug的辨識度還有待提高；在測試用例執(zhí)行時，會發(fā)現(xiàn)很多細節(jié)性的問題，不容易判斷它是不是一個bug。例如稿件管理發(fā)布系統(tǒng)中高級查詢里的版本查詢，雖然說它支持的是模糊查詢，但是輸入很多“.”時查詢的結(jié)果仍然是正確的，如果把它歸類為非法版本號，非法版本號輸入后查詢結(jié)果應該是查不到，而不是查詢到正確的結(jié)果。在一開始我將其定義為bug，但是和其他人討論之后，覺得可以不是bug，第二天又去考慮覺得還是bug。雖然說各人的判斷標準不同，但是總該有一個統(tǒng)一的標準。想這類問題還要在以后的項目實行過程中不斷總結(jié)經(jīng)驗。

4)測試執(zhí)行方法及步驟還存在很大的改善空間；在測試用例設(shè)計中不只

是功能測試，它還包括性能測試、界面測試、安全測試等，對于這些測試，測試用例設(shè)計時步驟不是很詳細，操作時就存在一定得困難。例如：性能測試中系統(tǒng)支持20人并發(fā)訪問系統(tǒng)，這就要求我們要盡量組織20人去集體測試，怎么去組織，要做哪些事情，諸如此類準備工作一定要詳細準備。

5)很多業(yè)務知識還不了解；這個問題在本次項目中體現(xiàn)不明顯。這是做

軟件測試學長給的意見。要做好一個項目，必須地相應項目的業(yè)務流程有一定的了解。

6)項目中組員間的交流不夠；雖然很多時候大家都提出互相檢查用例及

bug記錄等，但在實際過程中并沒有切實實行。交流是測試人員必備的溝通技巧，在項目進行過程中遇到問題要互相溝通，以便更好地解決問題。

7)對部分基礎(chǔ)知識的理解不夠透徹；在寫測試用例時，我們采取的步驟

是先把可能考慮到得測試寫全，但在寫測試用例時，就發(fā)現(xiàn)對一些測試的概念記得不清楚甚至混淆。這就說明我們對基礎(chǔ)問題的認識還不夠深。因此，在之后的學習過程中我們要不端去記憶一些概念，或者在做項目過程中不斷地發(fā)現(xiàn)相應的問題然后去解決。反復記憶，出現(xiàn)問題才能銘記于心。

8)報告書寫技能有待提高；測試人員做項目時，很多問題的結(jié)果都是以

報告形式，我們要不斷練習自己的公文寫作能力，熟悉應用office辦公軟件。

9)數(shù)據(jù)庫、服務器等其他知識了解太少；在測試執(zhí)行中，遇到一些bug，不清楚其出現(xiàn)的原因，知識面太狹隘。在之后的過程中要多了解與測試相關(guān)的知識。

總之，這兩個星期來，收獲頗多，問題多多，革命尚未成功，同志仍需努力！我們要通過各種渠道主動去獲取知識，多交流，多溝通，共同收獲！

第五篇：測試工作經(jīng)驗總結(jié)

測試工作經(jīng)驗總結(jié)

功能測試最重要的是理解業(yè)務和需求。知道系統(tǒng)要實現(xiàn)什么功能，業(yè)務流程是怎樣的，然后就可以根據(jù)需求編寫測試計劃和測試用例了。測試書籍上介紹常用的編寫測試用例的方法有：等價類、邊界值、因果圖、判定表等，在實際工作中，我使用較多的有等價類、邊界值、場景法和錯誤猜測法。在這里需要提一點，將測試用例按測試目的進行分類，比如用戶界面、功能點、業(yè)務場景等，會讓測試用例的結(jié)構(gòu)看起來更清晰，執(zhí)行測試用例的效率也更高。

要做好功能測試，還需要對整個系統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)比較清楚，每個功能點涉及哪些數(shù)據(jù)表，對數(shù)據(jù)的操作方式是怎樣的。這樣就不單從前臺頁面來進行測試，通過對數(shù)據(jù)庫中數(shù)據(jù)的驗證，可以發(fā)現(xiàn)隱藏的一些bug。比如庫表沒有進行關(guān)聯(lián)刪除，從前臺頁面是看不出來的，但實際可能導致程序出現(xiàn)問題。對一些比較復雜的組合查詢或數(shù)據(jù)排序，也可以自己編寫sql語句對結(jié)果進行驗證。

了解程序的框架結(jié)構(gòu)和一些開發(fā)知識也有助于更好地測試程序和定位錯誤。

測試用例的編寫經(jīng)驗步驟和數(shù)據(jù)的分離

將輸入的各種數(shù)據(jù)已參數(shù)的形式表達在操作步驟中，而不需要為每一種輸入數(shù)據(jù)創(chuàng)建一個測試用例。

例如：atm存款

好的測試用例，在執(zhí)行的步驟(Step)的表達上應該是盡可能和數(shù)據(jù)相分離。舉例來講，有一個ATM機取款的功能，可能有以下幾個場景：

1.密碼正確的登錄

2.密碼錯誤的登錄

3.密碼輸入三次錯誤，卡被鎖定

4.取少于余額的款項

5.嘗試取大于余額的款項

6.嘗試取等于余額的款項(考慮手續(xù)費)

6.取款額度大于當次的限制

7.取款額度大于當天的限制

7.取款次數(shù)大于限制次數(shù)

等等

不管你用什么用例設(shè)計的方法論來做指導，作為這個簡單的例子，有經(jīng)驗的人都應該能看出，此處的很多步驟是可以重用的，總結(jié)下來如下(此處只列出了操作的步驟，略去了系統(tǒng)的交互中的反饋結(jié)果)：

1.插入卡->A:輸入密碼->B:按“確定”鍵->重復A-B

2.A:選擇取款功能->B:填寫取款金額->C:點擊“確定取款”的按鈕->D:取現(xiàn)金->重復A-D

因此，我們只需要寫出兩套比較完整的步驟，將密碼和取款金額多數(shù)字用參數(shù)來表達即可。這樣是不是簡單了很多呢?單獨的測試基礎(chǔ)數(shù)據(jù)準備工作

將測試基礎(chǔ)數(shù)據(jù)提前準備好，寫到你單獨的測試數(shù)據(jù)準備文檔中，而不是分散到 所有使用到它的case中才去描述。測試用例的前后置條件

除了第二點中談到的數(shù)據(jù)需要準備外，在測試用例這個Level，必須有一些條件滿足，您才能開始執(zhí)行它。集中的把這些步驟整理成一個相對獨立的操作單元，具體用例中只要引用就可以了，這樣會便于對用例的理解和在多處復用。

順便說一下，對于一些類似軟件運行環(huán)境的條件，比如安裝和配置測試中，需要3種操作系統(tǒng)和3種瀏覽器的組合等，我們可以把他放在Test Set這個Level上來，不用寫多個用例，只是在測試計劃和執(zhí)行的管理系統(tǒng)中作為測試集的一個環(huán)境參數(shù)，恰當?shù)乇磉_出來就可以。