質(zhì)量控制部門職責(zé)及分工

1、目 錄第1章定義21.1質(zhì)量的定義21.2質(zhì)量控制的定義21.3測試的定義21.4什么才是BUG21.4.1功能不正常21.4.2難以使用的軟件21.4.3未做良好規(guī)劃21.4.4所提供的功能不足31.4.5與使用者的互動(dòng)31.4.6使用性能太差31.4.7未做好錯(cuò)誤處理41.4.8邊界錯(cuò)誤41.4.9計(jì)算錯(cuò)誤41.4.10使用一段時(shí)間所產(chǎn)生的錯(cuò)誤41.4.11控制流程的錯(cuò)誤41.4.12在壓力之下所產(chǎn)生的錯(cuò)誤51.4.13不同硬設(shè)備所導(dǎo)致的錯(cuò)誤51.4.14版本控制不良所產(chǎn)生的錯(cuò)誤51.4.15文件錯(cuò)誤5第2章質(zhì)量控制部門的組成62.1部門的定位62.2部門成員的角色及職責(zé)62.2.1質(zhì)量控

2、制經(jīng)理62.2.2質(zhì)量監(jiān)督員62.2.3測試協(xié)調(diào)員62.2.4測試執(zhí)行員62.2.5用戶培訓(xùn)員62.2.6系統(tǒng)實(shí)施員72.2.7過程研究員72.3部門成員的要求72.3.1對測試人員的要求7第3章質(zhì)量控制部門的職責(zé)93.1售前93.1.1了解需求93.1.2熟悉功能和性能93.1.3確認(rèn)工期93.1.4確定標(biāo)準(zhǔn)93.2售中93.2.1制定測試計(jì)劃93.2.2產(chǎn)品測試93.2.3管理BUG93.2.4產(chǎn)品質(zhì)量的評審93.2.5項(xiàng)目文檔的評審93.2.6編制用戶手冊93.2.7用戶培訓(xùn)103.2.8系統(tǒng)實(shí)施103.3售后103.3.1測試文檔提交103.3.2測試總結(jié)103.3.3完善測試標(biāo)準(zhǔn)、規(guī)

3、范103.4過程改進(jìn)103.4.1開發(fā)過程的評審103.4.2對開發(fā)過程的各項(xiàng)標(biāo)準(zhǔn)的定義103.4.3開發(fā)過程的持續(xù)改進(jìn)10第4章質(zhì)量控制部門的工作規(guī)范114.1共同分擔(dān)責(zé)任114.2良好的工作心態(tài)114.3工作計(jì)劃及進(jìn)度控制114.4積極參與及有效溝通114.5建設(shè)良好的工作環(huán)境114.6拋棄自我114.7不含敵意的沖突114.8如何解決問題114.8.1各項(xiàng)工作的規(guī)范11第5章質(zhì)量控制部門分級測試方案125.1方案要達(dá)到的目的：125.2分級測試方案125.2.1一級測試內(nèi)容125.2.2二級測試內(nèi)容125.2.3三級測試內(nèi)容125.2.4四級測試內(nèi)容125.3為什么采用分級測試方案125

4、.3.1問題一：用戶演示時(shí)出現(xiàn)錯(cuò)誤頁面等明顯BUG125.3.2問題二：BUG遺漏率太大125.4BUG狀態(tài)說明135.5分級測試方案工作流程135.5.1一級測試流程135.5.2二級測試流程145.5.3三級測試流程155.5.4四級測試流程16第6章部門人員工作考核方案176.1考核表176.1.1測試工作考核表176.1.2用戶培訓(xùn)考核表176.2考核說明18第1章 定義1.1 質(zhì)量的定義質(zhì)量的靜態(tài)定義：產(chǎn)品或服務(wù)能滿足規(guī)定或潛在需求的特性和特征的集合。質(zhì)量的動(dòng)態(tài)定義：是一個(gè)持續(xù)改進(jìn)的過程，在這個(gè)過程中取得的教訓(xùn)被用于提高未來產(chǎn)品和服務(wù)的質(zhì)量。1.2 質(zhì)量控制的定義質(zhì)量控制是關(guān)于活動(dòng)和

5、技術(shù)的集合性術(shù)語，在此過程中，活動(dòng)與技術(shù)旨在創(chuàng)造特定的質(zhì)量特征。這種活動(dòng)包括不斷監(jiān)控過程、識別和消除產(chǎn)生問題的原因、利用統(tǒng)計(jì)過程控制來減少可變性和增加這些過程的效率。質(zhì)量控制能保證組織的質(zhì)量以實(shí)現(xiàn)。1.3 測試的定義在G.J.Myers的經(jīng)典著作軟件測試技巧中，給出了測試的定義：“程序測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程”。1.4 什么才是BUG判定在測試中發(fā)現(xiàn)的問題是否屬于BUG，界定如下：功能不正常、難以使用、未做良好規(guī)劃、功能不足、與使用者互動(dòng)不良、性能太差、未做好錯(cuò)誤處理、邊界錯(cuò)誤、計(jì)算錯(cuò)誤、使用一段時(shí)間所產(chǎn)生的錯(cuò)誤，控制流程的錯(cuò)誤、在壓力之下所產(chǎn)生的錯(cuò)誤、不同硬設(shè)備所導(dǎo)致的錯(cuò)誤、版本控

6、制不良所產(chǎn)生的錯(cuò)誤和文件錯(cuò)誤。1.4.1 功能不正常 簡單地說就是所應(yīng)提供的功能，在使用上并不符合設(shè)計(jì)規(guī)格，或是根本無法使用。這個(gè)錯(cuò)誤常常會發(fā)生在測試過程的初期和中期，有許多在設(shè)計(jì)規(guī)格內(nèi)所應(yīng)提供的功能無法運(yùn)行，或是運(yùn)行結(jié)果達(dá)不到預(yù)期設(shè)計(jì)。是明顯的例子就是在UI上所提供的選項(xiàng)及動(dòng)作，使用者在操作后毫無反應(yīng)。1.4.2 難以使用的軟件只要是不知如何使用或難以使用的軟件，在設(shè)計(jì)上一定是出了問題。所謂好用的軟件就是使用上盡量方便，壓低使用者的學(xué)習(xí)曲線。1.4.3 未做良好規(guī)劃這里可以區(qū)分出所測試的軟件是以Top-Down的方式開發(fā)，還是以Bottom-Up的方式開發(fā)的。如果是以Top-Down結(jié)構(gòu)式方

7、法所開發(fā)的軟件，在功能的規(guī)劃及組織上比較完整，相反的Bottom-Up的組合式開發(fā)所呈現(xiàn)出來的軟件功能較為分散。舉例來說，假設(shè)有一個(gè)軟件提供了3個(gè)掃描的功能：實(shí)時(shí)掃描、手動(dòng)掃描和全面掃描。就功能而言，這3種功能應(yīng)該放到同一個(gè)掃描選項(xiàng)內(nèi)，可是因?yàn)閷?shí)時(shí)掃描是后來增加的，而且提供了立即編輯的功能，因此它被獨(dú)立出來成為另一個(gè)單獨(dú)選項(xiàng)。所造成的結(jié)果是許多的使用者誤以為在實(shí)時(shí)掃描所做的立即編輯設(shè)置，應(yīng)該可以套用在其他兩種掃描功能上。1.4.4 所提供的功能不足這個(gè)問題與功能不正常是不一樣的。這里所指的是軟件所提供的功能在動(dòng)作上是正常的，可是對使用者而言卻是不完整的。即使軟件的功能運(yùn)作結(jié)果符合設(shè)計(jì)規(guī)格的要求

8、，系統(tǒng)測試人員在測試結(jié)果的判斷上，也一定要從使用者的角度進(jìn)行思考。這里舉一個(gè)例子，假設(shè)所測試的軟件提供了數(shù)據(jù)處理功能，但是采用的是封閉式的CodeBase數(shù)據(jù)庫。對開發(fā)人員來說，采用CodeBase的數(shù)據(jù)庫對程序編寫來說比較容易，經(jīng)過測試之后也未發(fā)生其他的問題?？墒窃诳蛻舻沫h(huán)境下進(jìn)行Beta測試之后才發(fā)現(xiàn)，客戶要求提供支持SQL數(shù)據(jù)庫的功能，因?yàn)樗麄兿Ｍ軌蚪y(tǒng)一管理所有的資料。在這種情況下，系統(tǒng)測試工程師必須將這個(gè)問題呈現(xiàn)出來，雖然現(xiàn)在要求增加這個(gè)需求已經(jīng)太晚了，不過可以建議提供另一種解決方法，例如提供一個(gè)資料轉(zhuǎn)換工具或是提供資料導(dǎo)出的功能。測試人員要隨時(shí)對進(jìn)行測試的功能保持一個(gè)存疑的態(tài)度，因

9、為這樣的問題如果出現(xiàn)在開發(fā)的后期，所能提供的解決方式很有限，所以早一點(diǎn)發(fā)現(xiàn)這樣的問題對提高整個(gè)開發(fā)質(zhì)量的幫助很大。通常這樣的問題大都是由經(jīng)驗(yàn)豐富的測試工程師發(fā)現(xiàn)的。1.4.5 與使用者的互動(dòng)一個(gè)好的軟件必須與使用者之間正?；?dòng)。在使用者操作使用軟件的過程中，軟件必須很好地響應(yīng)使用者。這個(gè)問題常常有網(wǎng)絡(luò)中瀏覽網(wǎng)頁時(shí)出現(xiàn)。假設(shè)目前使用者正在某一個(gè)網(wǎng)頁填寫資料，但是所填寫的資料不足或是有誤。當(dāng)使用者單擊了“確定”按鈕之后，網(wǎng)頁響應(yīng)使用者所填寫的資料有錯(cuò)，可是并未指明錯(cuò)誤在哪里，使用者只好回到上一頁后重新填寫一次，或是直接放棄離開網(wǎng)站。這個(gè)問題就是軟件對使用互動(dòng)并I未做完整的設(shè)計(jì)，對于屬于窗口程序類型

10、的軟件，這一點(diǎn)也常常被忽略，例如當(dāng)使用者做任何更新或刪除動(dòng)作的前后，程序是否提供相應(yīng)的信息給使用者？或?qū)λ鶊?zhí)行的動(dòng)作做確認(rèn)？如提供確認(rèn)窗口。與使用者的互動(dòng)原則就是所有的動(dòng)作必須伴隨著適當(dāng)?shù)捻憫?yīng)（Every action come with a reaction）。1.4.6 使用性能太差所測試的軟件功能正常但是使用性能太差了，這樣算不算問題呢？這個(gè)問題，也經(jīng)常有測試人員問。使用性能不佳，當(dāng)然是一個(gè)問題，而問題通常是由于開發(fā)人員采用了錯(cuò)誤的解決方案，或是運(yùn)用了不適用的算法所導(dǎo)致的。例如有一個(gè)軟件屬于C/S的企業(yè)軟件，Server端會將Client傳遞上來的資料做好分類處理。由于資料所包含的種類相

11、當(dāng)多，于是開發(fā)人員將它分別存入不同的資料文件內(nèi)，例如Client A送給Server的資料種類有A1-A10，而Server就分別將資料存到10個(gè)不同的資料文件內(nèi)。這樣做的結(jié)果是造成使用者在做資料查詢時(shí)速度出奇地慢，因?yàn)镾erver會逐一搜尋10個(gè)不同的資料文件內(nèi)容來做對比。類似的例子相當(dāng)多，尋根究底是因?yàn)槲醋龊没A(chǔ)審核（Architecture Review）及設(shè)計(jì)審核（Design Review），可是卻大都是在進(jìn)行系統(tǒng)測試或性能測試時(shí)才顯示出問題的嚴(yán)重性。當(dāng)然，在有些情況下，項(xiàng)目經(jīng)理或開發(fā)人員會反駁說如此的使用性能是在合理的范圍內(nèi)。建議測試人員將競爭對手或同類型的軟件拿來做一個(gè)性能測試，

12、這個(gè)測試的結(jié)果最好以數(shù)字或百分比的形式返回給產(chǎn)品及開發(fā)人員。這樣的方式所達(dá)到的效果遠(yuǎn)比互相爭吵來得有效得多。1.4.7 未做好錯(cuò)誤處理軟件除了避免出錯(cuò)之外，還要做好錯(cuò)誤處理。許多軟件之所以會產(chǎn)生錯(cuò)誤，是因?yàn)槌绦虮旧聿恢廊绾翁幚硭龅降腻e(cuò)誤。譬如說，所測試的程序可以讀取外部的資料文件并且做一些分類整理，可是剛好所讀取的外部資料文件的內(nèi)容是被損毀的。當(dāng)程序讀取這個(gè)損毀的資料文件時(shí)，程序就發(fā)生問題，這時(shí)候操作系統(tǒng)不知如何處理這個(gè)狀況，為了保護(hù)自己只好中斷程序。由此可見這個(gè)程序并未做好錯(cuò)誤處理。除了做好錯(cuò)誤處理之外，同時(shí)也要設(shè)立防止錯(cuò)誤發(fā)生的機(jī)制。如上述所說的，程序在讀取外部資料文件之前，應(yīng)該先檢查

13、外部資料文件是否毀損，這樣的方法才比較保險(xiǎn)。當(dāng)然，除了做好錯(cuò)誤處理之外，產(chǎn)品是否提供適當(dāng)?shù)恼{(diào)試機(jī)制，也是測試人員應(yīng)該注意的。復(fù)雜的軟件如果未提供調(diào)試文檔或調(diào)試方法，在以后的維護(hù)過程中將會吃盡苦頭。建議在進(jìn)行軟件設(shè)計(jì)規(guī)格階段時(shí)，最好將調(diào)試機(jī)制包含在內(nèi)，這對以后的開發(fā)過程與維護(hù)過程絕對有很大的幫助。1.4.8 邊界錯(cuò)誤緩沖區(qū)溢出的問題（Buffer Overflows），這幾年來成為相當(dāng)熱門的網(wǎng)絡(luò)攻擊方式，而這個(gè)錯(cuò)誤就屬于邊界錯(cuò)誤的一種。簡單地說，程序本身無法處理超過邊界資料所導(dǎo)致的錯(cuò)誤。這個(gè)問題有許多情形是開發(fā)人員在聲明變量或是使用資料的長度時(shí)不小心引起的。1.4.9 計(jì)算錯(cuò)誤只要是軟件程序就免

14、不了包括數(shù)學(xué)計(jì)算。軟件之所以會出現(xiàn)計(jì)算錯(cuò)誤，大部分出錯(cuò)的原因在于采用了錯(cuò)誤的數(shù)學(xué)運(yùn)算或未將計(jì)數(shù)器歸0。1.4.10 使用一段時(shí)間所產(chǎn)生的錯(cuò)誤這個(gè)問題就是程序剛開始運(yùn)行時(shí)很正常，但在運(yùn)行了一段時(shí)間后卻出現(xiàn)問題。最典型的例子就是數(shù)據(jù)庫的搜尋功能。有一些軟件在剛開始使用時(shí)，所提供的資料搜尋功能運(yùn)作良好，可是在使用了一段時(shí)間后卻發(fā)現(xiàn)，進(jìn)行資料搜尋所需的時(shí)間卻越來越長了。結(jié)果發(fā)現(xiàn)，所采用的資料搜尋方式是從第一筆搜查到最后一筆的方法。類似這樣的問題可以解決和避免。例子：有一個(gè)軟件提供組件更新的功能，程序會通過因特網(wǎng)對比下載最新的組件，之后程序會以新的組件取代舊的組件。這個(gè)更新程序做第一次更新動(dòng)作的時(shí)候是正

15、確運(yùn)作，可是如果再做第二次更新動(dòng)作就毫無作用了，其原因很簡單，開發(fā)人員忘了將狀態(tài)標(biāo)志恢復(fù)到原來的狀態(tài)，所以程序無法再進(jìn)行第二次的更新動(dòng)作。1.4.11 控制流程的錯(cuò)誤控制流程的好與壞，考驗(yàn)著開發(fā)人員對軟件開發(fā)的態(tài)度及設(shè)計(jì)的程序是否嚴(yán)謹(jǐn)。軟件在狀態(tài)間的轉(zhuǎn)變是否合理，要依據(jù)流程進(jìn)行控制。相信許多測試人員在使用軟件時(shí)，有時(shí)候會有這種感覺為什么會跳到這一步？或是好像少了一個(gè)步驟等類似的問題，這就是所謂的控制流程錯(cuò)誤。用軟件安裝程序解釋這樣的問題是最容易的。譬如使用者在進(jìn)行軟件安裝時(shí)，在輸入用戶名及一些其他資料后，軟件就直接進(jìn)行安裝了，問題就出在安裝程序并未為使用者提供可以選擇安裝目的地的狀態(tài)。這就是軟

16、件控制流程不完整的錯(cuò)誤問題。1.4.12 在壓力之下所產(chǎn)生的錯(cuò)誤程序在處于壓力狀態(tài)下如果運(yùn)作不正常的話，就是屬于這種軟件的錯(cuò)誤。壓力測試對于Server級的軟件是必須要進(jìn)行的一項(xiàng)測試，因?yàn)镾erver級的軟件對穩(wěn)定度的要求遠(yuǎn)比其他的軟件高。通常一連串的壓力測試是必須配合著測試軟件來實(shí)施的，例如讓程序處理超過10萬筆的資料，然后再來觀察程序運(yùn)行的結(jié)果。要準(zhǔn)備10萬筆的資料就必須借助于測試軟件。1.4.13 不同硬設(shè)備所導(dǎo)致的錯(cuò)誤顧名思義就是問題的產(chǎn)生與硬件設(shè)備不同有關(guān)。如果所開發(fā)的軟件與硬件設(shè)備有直接的關(guān)系，這樣的問題就會相當(dāng)多，例如光盤刻錄機(jī)的軟件就存在不少這樣的問題。例如：所開發(fā)的軟件在特殊

17、品牌的服務(wù)器上運(yùn)行約七八分鐘就會停擺。1.4.14 版本控制不良所產(chǎn)生的錯(cuò)誤 出現(xiàn)這樣的問題屬于項(xiàng)目管理的疏忽，當(dāng)然測試人員未善盡職守也是原因之一。在最近的例子中有一個(gè)錯(cuò)得很冤，情形是這家公司一年前所出版的一個(gè)軟件被反應(yīng)有安全上的漏洞，后來這家公司也很快將這個(gè)問題的修正版提供給客戶下載。理論上這個(gè)事件就應(yīng)該平息了，但是在一年后他們在推出新版本時(shí)，卻忘記將這個(gè)已解決掉的問題加入新版本內(nèi)。所以對舊客戶來說，原本的問題已經(jīng)解決了，可是想不到將版本升級后，舊問題又出現(xiàn)了。1.4.15 文件錯(cuò)誤最后這個(gè)錯(cuò)誤是文件錯(cuò)誤。這里所提及的錯(cuò)誤除了軟件所附帶的使用手冊、說明文檔、FAQ，以及其他相關(guān)的文件內(nèi)容除了

18、降低質(zhì)量之外，最主要的問題是會誤導(dǎo)作用者。很多客戶投訴，不滿使用手冊所提供的資料與實(shí)際不符合。第2章 質(zhì)量控制部門的組成2.1 部門的定位質(zhì)量控制部門不僅僅是一個(gè)測試部門，與單純的測試部門有著重要的區(qū)別：測試針對一個(gè)項(xiàng)目，包含詳細(xì)的技術(shù)工作，它是項(xiàng)目組的一個(gè)核心角色。質(zhì)量控制是公司的一個(gè)職能部門，它在一個(gè)負(fù)責(zé)企業(yè)質(zhì)量和標(biāo)準(zhǔn)實(shí)施和監(jiān)督的人領(lǐng)導(dǎo)下工作。質(zhì)量控制也負(fù)責(zé)在不同的項(xiàng)目組之間共享最好的實(shí)踐經(jīng)驗(yàn)。2.2 部門成員的角色及職責(zé)質(zhì)量控制部門的角色分為七種：質(zhì)量控制經(jīng)理、質(zhì)量監(jiān)督員、測試協(xié)調(diào)員、測試執(zhí)行員、用戶培訓(xùn)員、系統(tǒng)實(shí)施員、過程研究員。2.2.1 質(zhì)量控制經(jīng)理質(zhì)量控制經(jīng)理的職責(zé)是：協(xié)調(diào)部門各

19、角色的工作，并對最終發(fā)布的產(chǎn)品、產(chǎn)品的文檔及整個(gè)開發(fā)過程進(jìn)行評審。2.2.2 質(zhì)量監(jiān)督員質(zhì)量監(jiān)督員的職責(zé)是：參與項(xiàng)目組，具有使項(xiàng)目組成員充分了解各項(xiàng)標(biāo)準(zhǔn)和規(guī)范的責(zé)任；協(xié)助并監(jiān)督項(xiàng)目組在開發(fā)過程中執(zhí)行相關(guān)標(biāo)準(zhǔn)和規(guī)范；協(xié)助質(zhì)量控制經(jīng)理對開發(fā)過程進(jìn)行評審；可根據(jù)執(zhí)行情況對各項(xiàng)標(biāo)準(zhǔn)和規(guī)范提出改善建議。2.2.3 測試協(xié)調(diào)員測試協(xié)調(diào)員的職責(zé)是：針對某個(gè)產(chǎn)品或某個(gè)項(xiàng)目制定測試計(jì)劃和測試方法，確定測試工期；根據(jù)各測試執(zhí)行員提交的測試結(jié)果，完成項(xiàng)目或產(chǎn)品的測試總結(jié)報(bào)告。一個(gè)測試協(xié)調(diào)員的角色可由多個(gè)人員擔(dān)任，一個(gè)人員也可擔(dān)任多個(gè)測試協(xié)調(diào)員的角色。2.2.4 測試執(zhí)行員測試執(zhí)行員的職責(zé)是：根據(jù)測試協(xié)調(diào)員制定的測試

20、計(jì)劃和測試方法編寫測試說明包括測試用例的設(shè)計(jì)和說明；對產(chǎn)品進(jìn)行測試，并記錄測試結(jié)果；對BUG進(jìn)行管理，保證它們在產(chǎn)品提交以前被解決；參與產(chǎn)品的質(zhì)量評審。2.2.5 用戶培訓(xùn)員用戶培訓(xùn)員的職責(zé)是：參與系統(tǒng)測試，并在系統(tǒng)測試的同時(shí)獲取系統(tǒng)界面、了解系統(tǒng)的操作，完成用戶手冊和培訓(xùn)教材；通過方案演示和系統(tǒng)培訓(xùn)，最大可能性地使系統(tǒng)的使用者得到相關(guān)產(chǎn)品和服務(wù)的價(jià)值。2.2.6 過程研究員過程研究員的職責(zé)是： 參與項(xiàng)目或產(chǎn)品開發(fā)過程評審，參與產(chǎn)品質(zhì)量評審，并根據(jù)評審結(jié)果對開發(fā)過程進(jìn)行分析，找出影響產(chǎn)品質(zhì)量的主要因素，并針對主要因素提出相應(yīng)的過程改進(jìn)方案。2.3 部門成員的要求產(chǎn)品質(zhì)量關(guān)系到企業(yè)的生命和前途，

21、質(zhì)量控制部門應(yīng)全程跟蹤產(chǎn)品的開發(fā)過程，是產(chǎn)品質(zhì)量的最后一道防線，對最終發(fā)布的產(chǎn)品的質(zhì)量負(fù)有直接的責(zé)任，所以對部門成員的要求是：有高度的責(zé)任心、對工作的認(rèn)真態(tài)度、具有嚴(yán)謹(jǐn)和細(xì)致的思維習(xí)慣。2.3.1 對測試人員的要求 測試人員包括：測試協(xié)調(diào)員、測試執(zhí)行員人是測試工作中最有價(jià)值也是最重要的資源，沒有一個(gè)合格的、積極的測試小組，測試就不可能實(shí)現(xiàn)。為高質(zhì)高效地完成測試任務(wù)，好的測試工程師應(yīng)具有如下能力：2.3.1.1 溝通能力一名理想的測試者必須能夠同測試涉及到的所有人進(jìn)行溝通，具有與技術(shù)（開發(fā)者）和非技術(shù)人員（客戶，管理人員）的交流能力。既要可以和用戶談得來，又能同開發(fā)人員說得上話，不幸的是這兩類人

22、沒有共同語言。和用戶談話的重點(diǎn)必須放在系統(tǒng)可以正確地處理什么和不可以處理什么上。而和開發(fā)者談相同的信息時(shí)，就必須將這些活重新組織以另一種方式表達(dá)出來，測試小組的成員必須能夠同等地同用戶和開發(fā)者溝通。2.3.1.2 技術(shù)能力就總體言，開發(fā)人員對那些不懂技術(shù)的人持一種輕視的態(tài)度。一旦測試小組的某個(gè)成員作出了一個(gè)錯(cuò)誤的斷定，那么他們的可信度就會立刻被傳揚(yáng)了出去。一個(gè)測試者必須既明白被測軟件系統(tǒng)的概念又要會使用工程中的那些工具。要做到這一點(diǎn)需要有一定的編程經(jīng)驗(yàn)，前期的開發(fā)經(jīng)驗(yàn)可以幫助對軟件開發(fā)過程有較深入的理解，從開發(fā)人員的角度正確的評價(jià)測試者，簡化自動(dòng)測試工具編程的學(xué)習(xí)曲線。2.3.1.3 自信心開

23、發(fā)者指責(zé)測試者出了錯(cuò)是常有的事，測試者必須對自己的觀點(diǎn)有足夠的自信心。如果容許別人對自己指東指西，就不能完成什么更多的事情了。2.3.1.4 外交能力當(dāng)你告訴某人他出了錯(cuò)時(shí)，就必須使用一些外交方法。機(jī)智老練和外交手法有助于維護(hù)與開發(fā)人員的協(xié)作關(guān)系，測試者在告訴開發(fā)者他的軟件有錯(cuò)誤時(shí)，也同樣需要一定的外交手腕。如果采取的方法過于強(qiáng)硬，對測試者來說，在以后和開發(fā)部門的合作方面就相當(dāng)于“贏了戰(zhàn)爭卻輸了戰(zhàn)役”。2.3.1.5 幽默感在遇到狡辯的情況下，一個(gè)幽默的批評將是很有幫助的。2.3.1.6 懷疑精神可以預(yù)料，開發(fā)者會盡他們最大的努力將所有的錯(cuò)誤解釋過去。測式者必須聽每個(gè)人的說明，但他必須保持懷疑

24、直到他自己看過以后。2.3.1.7 自我督促干測試工作很容易使你變得懶散。只有那些具有自我督促能力的人才能夠使自己每天正常地工作。2.3.1.8 洞察力一個(gè)好的測試工程師具有“測試是為了破壞”的觀點(diǎn)，捕獲用戶觀點(diǎn)的能力，強(qiáng)烈的質(zhì)量追求，對細(xì)節(jié)的關(guān)注能力。應(yīng)用的高風(fēng)險(xiǎn)區(qū)的判斷能力以便將有限的測試針對重點(diǎn)環(huán)節(jié)。第3章 質(zhì)量控制部門的職責(zé)3.1 售前3.1.1 了解需求了解客戶需求、對測試的具體或特殊要求。3.1.2 熟悉功能和性能結(jié)合項(xiàng)目方案、需求分析，熟悉和分析系統(tǒng)功能、性能指標(biāo)。3.1.3 確認(rèn)工期確認(rèn)測試所需的工作量，提供給項(xiàng)目負(fù)責(zé)人以確認(rèn)項(xiàng)目工期。3.1.4 確定標(biāo)準(zhǔn)與開發(fā)組確定開發(fā)標(biāo)準(zhǔn)和

25、測試標(biāo)準(zhǔn)。3.2 售中3.2.1 制定測試計(jì)劃根據(jù)用戶需求和需求分析、設(shè)計(jì)方案，制定項(xiàng)目測試計(jì)劃。3.2.2 產(chǎn)品測試測試的任務(wù)是保證產(chǎn)品或服務(wù)交付之前，能夠發(fā)現(xiàn)所有存在的問題。測試要準(zhǔn)備測試計(jì)劃、測試規(guī)定和測試的用例，這些文檔用于拓寬測試范圍和進(jìn)行足夠的可使用性測試。在軟件開發(fā)的項(xiàng)目中，測試必須針對所有的接口，包括API的每個(gè)方面。將新軟件集成到現(xiàn)行系統(tǒng)時(shí)也必須進(jìn)行測試。系統(tǒng)測試工作全部完成后要準(zhǔn)備測試總結(jié)報(bào)告。測試的內(nèi)容包括：代碼測試、單元測試、集成測試、系統(tǒng)測試、性能測試、系統(tǒng)實(shí)施測試、應(yīng)用程序接口測試。注：測試這種角色必須獨(dú)立于開發(fā)才是真正有效的。3.2.3 管理BUG測試要管理BUG

26、跟蹤數(shù)據(jù)庫，并對BUG報(bào)告的質(zhì)量負(fù)責(zé)。BUG數(shù)據(jù)庫對于產(chǎn)生針對進(jìn)度跟蹤項(xiàng)目狀態(tài)的統(tǒng)計(jì)報(bào)告來說，是一種重要資源。BUG報(bào)告也用于確定項(xiàng)目進(jìn)度中的、關(guān)鍵部分的風(fēng)險(xiǎn)。3.2.4 產(chǎn)品質(zhì)量的評審 根據(jù)產(chǎn)品測試報(bào)告的對產(chǎn)品的質(zhì)量進(jìn)行評審，確定產(chǎn)品是否可以發(fā)布。3.2.5 項(xiàng)目文檔的評審 根據(jù)項(xiàng)目管理規(guī)范，按時(shí)檢查各階段需提交的開發(fā)文檔，檢查開發(fā)文檔的規(guī)范性和正確性，對文檔進(jìn)行評審。3.2.6 編制用戶手冊 在進(jìn)行測試的過程中，獲取系統(tǒng)界面，并對各項(xiàng)功能和操作進(jìn)行說明，最后形成用戶手冊。3.2.7 用戶培訓(xùn)用戶培訓(xùn)的任務(wù)是通過方案演示和系統(tǒng)培訓(xùn)，最大可能性地使系統(tǒng)的使用者得到相關(guān)產(chǎn)品和服務(wù)的價(jià)值。用戶培訓(xùn)

27、的第二個(gè)任務(wù)是通過使產(chǎn)品更容易理解和使用，降低系統(tǒng)技術(shù)支持的費(fèi)用。3.2.8 系統(tǒng)實(shí)施系統(tǒng)實(shí)施的任務(wù)是確保產(chǎn)品平穩(wěn)地過渡、安裝和移交到產(chǎn)品操作和技術(shù)支持組手中。3.3 售后3.3.1 測試文檔提交將項(xiàng)目測試計(jì)劃、項(xiàng)目測試總結(jié)報(bào)告以及開發(fā)文檔交項(xiàng)目管理部相關(guān)負(fù)責(zé)人。3.3.2 測試總結(jié)總結(jié)測試中遇到的問題、經(jīng)驗(yàn)、測試方法。3.3.3 完善測試標(biāo)準(zhǔn)、規(guī)范 根據(jù)總結(jié)的結(jié)論，對不適合的測試標(biāo)準(zhǔn)、規(guī)范進(jìn)行修訂，使之更加完善。3.4 過程改進(jìn)3.4.1 開發(fā)過程的評審 根據(jù)項(xiàng)目開發(fā)過程中各標(biāo)準(zhǔn)的執(zhí)行情況對開發(fā)過程進(jìn)行評審。3.4.2 對開發(fā)過程的各項(xiàng)標(biāo)準(zhǔn)的定義 定義開發(fā)過程中所需要遵循的各項(xiàng)標(biāo)準(zhǔn)，制定標(biāo)準(zhǔn)

28、有兩條原則：一是標(biāo)準(zhǔn)應(yīng)有利于穩(wěn)定質(zhì)量或在不損害質(zhì)量的基礎(chǔ)上降低開發(fā)成本；二是具有可執(zhí)行性。3.4.3 開發(fā)過程的持續(xù)改進(jìn)根據(jù)開發(fā)過程的評審結(jié)果及產(chǎn)品質(zhì)量的結(jié)果，找出影響產(chǎn)品質(zhì)量的因素，并改進(jìn)開發(fā)過程的標(biāo)準(zhǔn)或方法，保持產(chǎn)品質(zhì)量的穩(wěn)定和持續(xù)上升。各項(xiàng)目組在開發(fā)過程中積累的好的經(jīng)驗(yàn)也可作為持續(xù)改進(jìn)開發(fā)過程的一個(gè)重要參考。第4章 質(zhì)量控制部門的工作規(guī)范4.1 共同分擔(dān)責(zé)任質(zhì)量控制經(jīng)理是部門的負(fù)責(zé)人，但部門的每位成員都有必要分擔(dān)這個(gè)責(zé)任。4.2 良好的工作心態(tài)部門每一位成員都應(yīng)始終保持如下的工作心態(tài)以保證產(chǎn)品的成功及個(gè)人成長：高度責(zé)任感、認(rèn)真工作、思想開放，有著進(jìn)一步自我發(fā)展的愿望。4.3 工作計(jì)劃及進(jìn)

29、度控制充分了解客觀情況，制訂切實(shí)可行的工作計(jì)劃，充分利用時(shí)間，對事情的發(fā)展主動(dòng)加以控制，以做好為目的，對不可控制事情及時(shí)預(yù)警，避免返工或重做。充分相信其他成員能夠按時(shí)優(yōu)質(zhì)完成各自的任務(wù)而不影響其他成員的工作。4.4 積極參與及有效溝通在任何需要的時(shí)候都要積極參與，充分表達(dá)你的見解，而不是坐等被人問起。主動(dòng)與其他小組成員進(jìn)行明確與及時(shí)的溝通，提倡建設(shè)性的反饋，避免任何指責(zé)性的言語和行為。每一位成員既是問題的發(fā)現(xiàn)者，又是問題的解決者。既便是面對超出職責(zé)范圍的問題，也不能以此作為推諉的理由。4.5 建設(shè)良好的工作環(huán)境共同創(chuàng)造積極而又有建設(shè)性的工作環(huán)境：尊重部門的所有成員，也尊重其他人的觀點(diǎn)。認(rèn)識到個(gè)

30、人之間的差別，不以自己的意志及好惡強(qiáng)求別人。摒棄驕傲、自滿或固執(zhí)的情緒，因?yàn)槟菚绊懙讲块T成員的合作與互助。4.6 拋棄自我拋棄自我的概念：團(tuán)隊(duì)的成功高于一切，個(gè)人的獲取是次要的。在團(tuán)隊(duì)中沒有自我的概念，從而也就沒有個(gè)人的勝敗。如果團(tuán)隊(duì)成功了，每個(gè)人都是贏家。4.7 不含敵意的沖突不含敵意的沖突是好的，它能激起討論，以澄清認(rèn)識并促成尋求新的方法。每個(gè)人都必須以積極的態(tài)度對待沖突，并愿意就面臨的沖突廣泛交換意見，盡力得到最好、最全面的解決方案，不允許有任何情緒化的言論和行為。反對無原則的附和。在附和意見之前先問自己：出了門是不是還會支持決議？為其辯護(hù)？4.8 如何解決問題解決問題的9個(gè)步驟：說明

31、問題；發(fā)現(xiàn)問題的可能原因；收集資料并明確最可能原因；明確可能方案；評估可行方案；決定最佳方案；修訂質(zhì)量計(jì)劃；實(shí)施方案；判斷問題是否得以解決。4.8.1 各項(xiàng)工作的規(guī)范在部門的各項(xiàng)工作的應(yīng)遵循的標(biāo)準(zhǔn)和規(guī)范詳見測試規(guī)范、過程改進(jìn)規(guī)范、產(chǎn)品和過程度量標(biāo)準(zhǔn)、項(xiàng)目文檔規(guī)范等。第5章 質(zhì)量控制部門分級測試方案5.1 方案要達(dá)到的目的：1、避免再出現(xiàn)給用戶演示時(shí)出現(xiàn)較明顯的BUG。2、降低BUG的遺漏率。5.2 分級測試方案測試工作分為四級：5.2.1 一級測試內(nèi)容1、正常操作，能否執(zhí)行通過。2、需求描述的功能是否實(shí)現(xiàn)（只檢查功能實(shí)現(xiàn)，不考慮合理性）。5.2.2 二級測試內(nèi)容1、業(yè)務(wù)邏輯是否合理。2、用戶能

32、否容易上手。5.2.3 三級測試內(nèi)容1、非正常操作（包括邊界值、非法值、空值輸入等）看是否有合適的異常處理（錯(cuò)誤提示是否準(zhǔn)確易懂）。2、頁面布局及顯示信息（如：tital顯示等）。5.2.4 四級測試內(nèi)容1、 破壞性操作，如：多個(gè)用戶對同一條信息進(jìn)行刪除等。2、 性能測試。3、 壓力測試。5.3 為什么采用分級測試方案在測試工作中遇到一些難以解決的問題，為了解決這些問題，制定了分級測試方案。5.3.1 問題一：用戶演示時(shí)出現(xiàn)錯(cuò)誤頁面等明顯BUG原因分析：測試人員在測試中，要檢查系統(tǒng)所有方面的問題，涉及面廣，造成工作量龐大，不能及時(shí)對系統(tǒng)進(jìn)行全面檢查。解決方法：采用測試分級方案，在給用戶演示前，

33、應(yīng)提前通知質(zhì)量保證部，對系統(tǒng)進(jìn)行一級測試，測試通過才能進(jìn)行演示，以保證演示順利通過。5.3.2 問題二：BUG遺漏率太大如果測試人員的BUG遺漏太多，就失去測試的意義了。原因分析：測試人員要對以上四個(gè)級別的內(nèi)容都進(jìn)行測試，就要考慮很多方面的問題，這需要具有較強(qiáng)的思維嚴(yán)密性，不容易做到。解決方法：采用測試分級方案，系統(tǒng)提交給測試人員后，先進(jìn)行一級測試，測試人員只考慮一級測試的內(nèi)容，完成后提交BUG給開發(fā)人員。按照一級測試流程進(jìn)行（見一級測試流程圖）。一級測試通過后，再進(jìn)行二級測試，這樣逐級上升，每個(gè)測試級別只考慮比較單純的問題，可以減輕測試人員的壓力，這樣就對思維嚴(yán)密性的要求降低很多，又能降低B

34、UG遺漏率。5.4 BUG處理5.4.1 BUG狀態(tài)說明狀態(tài)說明標(biāo)注狀態(tài)的角色1Open已經(jīng)發(fā)現(xiàn)的BUG測試人員2Updated已被修正的BUG開發(fā)人員3Disputed有爭議的BUG開發(fā)人員4False假BUG測試人員5Close測試證實(shí)已經(jīng)修正的BUG測試人員6Reopen.被修正的BUG再次出現(xiàn)，NO.為出現(xiàn)次數(shù)測試人員5.4.2 BUG處理流程5.5 分級測試方案工作流程5.5.1 一級測試流程5.5.2 二級測試流程5.5.3 三級測試流程5.5.4 四級測試流程第6章 部門人員工作考核方案6.1 考核表6.1.1 測試工作考核表考核項(xiàng)權(quán)重%評分描述測試溝通：與相關(guān)人員溝通，充分了解需求2025細(xì)致：沒有BUG遺漏35速度：能夠在指定時(shí)間內(nèi)完成20質(zhì)量：無返工現(xiàn)象，符合要求25BUG記錄分級：對BUG分級的判斷準(zhǔn)確1530BUG描述：描述準(zhǔn)確，容易理解20修改意見：能夠提出準(zhǔn)確的修改意見25創(chuàng)新：能提出較好的解決方案15質(zhì)量：無返工現(xiàn)象，符合要求25BUG追蹤主動(dòng)追蹤BUG的修改情況4025溝通：開發(fā)人員對BUG的判定有疑問時(shí)，能有效地與開發(fā)人員溝通，解決爭議60職業(yè)素質(zhì)工作態(tài)度：工作熱情、不發(fā)牢騷2020服從性：能夠按要求完成任務(wù)20克服困難：遇到困難能想辦法并努力解決15責(zé)任心：對工作負(fù)責(zé)，不推卸責(zé)任20協(xié)作：能