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

1、PAGE PAGE 38目 錄TOC o 1-3 h z HYPERLINK l _Toc96501905 第1章定義 PAGEREF _Toc96501905 h 2 HYPERLINK l _Toc96501906 1.1質(zhì)量的定義 PAGEREF _Toc96501906 h 2 HYPERLINK l _Toc96501907 1.2質(zhì)量控控制的定義 PAGEREF _Toc96501907 h 2 HYPERLINK l _Toc96501908 1.3測試的的定義 PAGEREF _Toc96501908 h 2 HYPERLINK l _Toc96501909 1.4什么才才是B

2、UG PAGEREF _Toc96501909 h 2 HYPERLINK l _Toc96501910 1.4.1功功能不正常 PAGEREF _Toc96501910 h 2 HYPERLINK l _Toc96501911 1.4.2難難以使用的軟軟件 PAGEREF _Toc96501911 h 2 HYPERLINK l _Toc96501912 1.4.3未未做良好規(guī)劃劃 PAGEREF _Toc96501912 h 2 HYPERLINK l _Toc96501913 1.4.4所所提供的功能能不足 PAGEREF _Toc96501913 h 3 HYPERLINK l _To

3、c96501914 1.4.5與與使用者的互互動 PAGEREF _Toc96501914 h 3 HYPERLINK l _Toc96501915 1.4.6使使用性能太差差 PAGEREF _Toc96501915 h 3 HYPERLINK l _Toc96501916 1.4.7未未做好錯誤處處理 PAGEREF _Toc96501916 h 4 HYPERLINK l _Toc96501917 1.4.8邊邊界錯誤 PAGEREF _Toc96501917 h 4 HYPERLINK l _Toc96501918 1.4.9計計算錯誤 PAGEREF _Toc96501918 h 4

4、 HYPERLINK l _Toc96501919 1.4.10使用一段時時間所產(chǎn)生的的錯誤 PAGEREF _Toc96501919 h 4 HYPERLINK l _Toc96501920 1.4.11控制流程的的錯誤 PAGEREF _Toc96501920 h 4 HYPERLINK l _Toc96501921 1.4.12在壓力之下下所產(chǎn)生的錯錯誤 PAGEREF _Toc96501921 h 5 HYPERLINK l _Toc96501922 1.4.13不同硬設(shè)備備所導(dǎo)致的錯錯誤 PAGEREF _Toc96501922 h 5 HYPERLINK l _Toc9650192

5、3 1.4.14版本控制不不良所產(chǎn)生的的錯誤 PAGEREF _Toc96501923 h 5 HYPERLINK l _Toc96501924 1.4.15文件錯誤 PAGEREF _Toc96501924 h 5 HYPERLINK l _Toc96501925 第2章質(zhì)量控控制部門的組組成 PAGEREF _Toc96501925 h 6 HYPERLINK l _Toc96501926 2.1部門的的定位 PAGEREF _Toc96501926 h 6 HYPERLINK l _Toc96501927 2.2部門成成員的角色及及職責(zé) PAGEREF _Toc96501927 h 6

6、HYPERLINK l _Toc96501928 2.2.1質(zhì)質(zhì)量控制經(jīng)理理 PAGEREF _Toc96501928 h 6 HYPERLINK l _Toc96501929 2.2.2質(zhì)質(zhì)量監(jiān)督員 PAGEREF _Toc96501929 h 6 HYPERLINK l _Toc96501930 2.2.3測測試協(xié)調(diào)員 PAGEREF _Toc96501930 h 6 HYPERLINK l _Toc96501931 2.2.4測測試執(zhí)行員 PAGEREF _Toc96501931 h 6 HYPERLINK l _Toc96501932 2.2.5用用戶培訓(xùn)員 PAGEREF _Toc9

7、6501932 h 6 HYPERLINK l _Toc96501933 2.2.6系系統(tǒng)實施員 PAGEREF _Toc96501933 h 7 HYPERLINK l _Toc96501934 2.2.7過過程研究員 PAGEREF _Toc96501934 h 7 HYPERLINK l _Toc96501935 2.3部門成成員的要求 PAGEREF _Toc96501935 h 7 HYPERLINK l _Toc96501936 2.3.1對對測試人員的的要求 PAGEREF _Toc96501936 h 7 HYPERLINK l _Toc96501937 第3章質(zhì)量控控制部門的

8、職職責(zé) PAGEREF _Toc96501937 h 9 HYPERLINK l _Toc96501938 3.1售前 PAGEREF _Toc96501938 h 9 HYPERLINK l _Toc96501939 3.1.1了了解需求 PAGEREF _Toc96501939 h 9 HYPERLINK l _Toc96501940 3.1.2熟熟悉功能和性性能 PAGEREF _Toc96501940 h 9 HYPERLINK l _Toc96501941 3.1.3確確認(rèn)工期 PAGEREF _Toc96501941 h 9 HYPERLINK l _Toc96501942 3.1

9、.4確確定標(biāo)準(zhǔn) PAGEREF _Toc96501942 h 9 HYPERLINK l _Toc96501943 3.2售中 PAGEREF _Toc96501943 h 9 HYPERLINK l _Toc96501944 3.2.1制制定測試計劃劃 PAGEREF _Toc96501944 h 9 HYPERLINK l _Toc96501945 3.2.2產(chǎn)產(chǎn)品測試 PAGEREF _Toc96501945 h 9 HYPERLINK l _Toc96501946 3.2.3管管理BUG PAGEREF _Toc96501946 h 9 HYPERLINK l _Toc96501947

10、 3.2.4產(chǎn)產(chǎn)品質(zhì)量的評評審 PAGEREF _Toc96501947 h 9 HYPERLINK l _Toc96501948 3.2.5項項目文檔的評評審 PAGEREF _Toc96501948 h 9 HYPERLINK l _Toc96501949 3.2.6編編制用戶手手冊 PAGEREF _Toc96501949 h 9 HYPERLINK l _Toc96501950 3.2.7用用戶培訓(xùn) PAGEREF _Toc96501950 h 10 HYPERLINK l _Toc96501951 3.2.8系系統(tǒng)實施 PAGEREF _Toc96501951 h 10 HYPERL

11、INK l _Toc96501952 3.3售后 PAGEREF _Toc96501952 h 10 HYPERLINK l _Toc96501953 3.3.1測測試文檔提交交 PAGEREF _Toc96501953 h 10 HYPERLINK l _Toc96501954 3.3.2測測試總結(jié) PAGEREF _Toc96501954 h 10 HYPERLINK l _Toc96501955 3.3.3完完善測試標(biāo)準(zhǔn)準(zhǔn)、規(guī)范 PAGEREF _Toc96501955 h 10 HYPERLINK l _Toc96501956 3.4過程改改進(jìn) PAGEREF _Toc96501956

12、 h 10 HYPERLINK l _Toc96501957 3.4.1開開發(fā)過程的評評審 PAGEREF _Toc96501957 h 10 HYPERLINK l _Toc96501958 3.4.2對對開發(fā)過程的的各項標(biāo)準(zhǔn)的的定義 PAGEREF _Toc96501958 h 10 HYPERLINK l _Toc96501959 3.4.3開開發(fā)過程的持持續(xù)改進(jìn) PAGEREF _Toc96501959 h 10 HYPERLINK l _Toc96501960 第4章質(zhì)量控控制部門的工工作規(guī)范 PAGEREF _Toc96501960 h 11 HYPERLINK l _Toc965

13、01961 4.1共同分分擔(dān)責(zé)任 PAGEREF _Toc96501961 h 11 HYPERLINK l _Toc96501962 4.2良好的的工作心態(tài) PAGEREF _Toc96501962 h 11 HYPERLINK l _Toc96501963 4.3工作計計劃及進(jìn)度控控制 PAGEREF _Toc96501963 h 11 HYPERLINK l _Toc96501964 4.4積極參參與及有效溝溝通 PAGEREF _Toc96501964 h 11 HYPERLINK l _Toc96501965 4.5建設(shè)良良好的工作環(huán)環(huán)境 PAGEREF _Toc96501965 h

14、 11 HYPERLINK l _Toc96501966 4.6拋棄自自我 PAGEREF _Toc96501966 h 11 HYPERLINK l _Toc96501967 4.7不含敵敵意的沖突 PAGEREF _Toc96501967 h 11 HYPERLINK l _Toc96501968 4.8如何解解決問題 PAGEREF _Toc96501968 h 11 HYPERLINK l _Toc96501969 4.8.1各各項工作的規(guī)規(guī)范 PAGEREF _Toc96501969 h 11 HYPERLINK l _Toc96501970 第5章質(zhì)量控控制部門分級級測試方案 PA

15、GEREF _Toc96501970 h 12 HYPERLINK l _Toc96501971 5.1方案要要達(dá)到的目的的： PAGEREF _Toc96501971 h 12 HYPERLINK l _Toc96501972 5.2分級測測試方案 PAGEREF _Toc96501972 h 12 HYPERLINK l _Toc96501973 5.2.1一一級測試內(nèi)容容 PAGEREF _Toc96501973 h 12 HYPERLINK l _Toc96501974 5.2.2二二級測試內(nèi)容容 PAGEREF _Toc96501974 h 12 HYPERLINK l _Toc96

16、501975 5.2.3三三級測試內(nèi)容容 PAGEREF _Toc96501975 h 12 HYPERLINK l _Toc96501976 5.2.4四四級測試內(nèi)容容 PAGEREF _Toc96501976 h 12 HYPERLINK l _Toc96501977 5.3為什么么采用分級測測試方案 PAGEREF _Toc96501977 h 12 HYPERLINK l _Toc96501978 5.3.1問問題一：用戶戶演示時出現(xiàn)現(xiàn)錯誤頁面等等明顯BUGG PAGEREF _Toc96501978 h 12 HYPERLINK l _Toc96501979 5.3.2問問題二：BU

17、UG遺漏率太太大 PAGEREF _Toc96501979 h 12 HYPERLINK l _Toc96501980 5.4BUGG狀態(tài)說明 PAGEREF _Toc96501980 h 13 HYPERLINK l _Toc96501981 5.5分級測測試方案工作作流程 PAGEREF _Toc96501981 h 13 HYPERLINK l _Toc96501982 5.5.1一一級測試流程程 PAGEREF _Toc96501982 h 13 HYPERLINK l _Toc96501983 5.5.2二二級測試流程程 PAGEREF _Toc96501983 h 14 HYPER

18、LINK l _Toc96501984 5.5.3三三級測試流程程 PAGEREF _Toc96501984 h 15 HYPERLINK l _Toc96501985 5.5.4四四級測試流程程 PAGEREF _Toc96501985 h 16 HYPERLINK l _Toc96501986 第6章部門人人員工作考核核方案 PAGEREF _Toc96501986 h 17 HYPERLINK l _Toc96501987 6.1考核表表 PAGEREF _Toc96501987 h 17 HYPERLINK l _Toc96501988 6.1.1測測試工作考核核表 PAGEREF _

19、Toc96501988 h 17 HYPERLINK l _Toc96501989 6.1.2用用戶培訓(xùn)考核核表 PAGEREF _Toc96501989 h 17 HYPERLINK l _Toc96501990 6.2考核說說明 PAGEREF _Toc96501990 h 18定義質(zhì)量的定義質(zhì)量的靜態(tài)定義義：產(chǎn)品或服服務(wù)能滿足規(guī)規(guī)定或潛在需需求的特性和和特征的集合合。質(zhì)量的動態(tài)定義義：是一個持持續(xù)改進(jìn)的過過程，在這個個過程中取得得的教訓(xùn)被用用于提高未來來產(chǎn)品和服務(wù)務(wù)的質(zhì)量。質(zhì)量控制的定義義質(zhì)量控制是關(guān)于于活動和技術(shù)術(shù)的集合性術(shù)術(shù)語，在此過過程中，活動動與技術(shù)旨在在創(chuàng)造特定的的質(zhì)量特征。這

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

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

22、p的的方式開發(fā)的的。如果是以以Top-DDown結(jié)構(gòu)構(gòu)式方法所開開發(fā)的軟件，在在功能的規(guī)劃劃及組織上比比較完整，相相反的Botttom-UUp的組合式式開發(fā)所呈現(xiàn)現(xiàn)出來的軟件件功能較為分分散。舉例來說，假設(shè)設(shè)有一個軟件件提供了3個個掃描的功能能：實時掃描描、手動掃描描和全面掃描描。就功能而而言，這3種種功能應(yīng)該放放到同一個掃掃描選項內(nèi)，可可是因為實時時掃描是后來來增加的，而而且提供了立立即編輯的功功能，因此它它被獨立出來來成為另一個個單獨選項。所所造成的結(jié)果果是許多的使使用者誤以為為在實時掃描描所做的立即即編輯設(shè)置，應(yīng)應(yīng)該可以套用用在其他兩種種掃描功能上上。所提供的功能不不足這個問題與功能能不

23、正常是不不一樣的。這這里所指的是是軟件所提供供的功能在動動作上是正常常的，可是對對使用者而言言卻是不完整整的。即使軟軟件的功能運(yùn)運(yùn)作結(jié)果符合合設(shè)計規(guī)格的的要求，系統(tǒng)統(tǒng)測試人員在在測試結(jié)果的的判斷上，也也一定要從使使用者的角度度進(jìn)行思考。這這里舉一個例例子，假設(shè)所所測試的軟件件提供了數(shù)據(jù)據(jù)處理功能，但但是采用的是是封閉式的CCodeBaase數(shù)據(jù)庫庫。對開發(fā)人人員來說，采采用CodeeBase的的數(shù)據(jù)庫對程程序編寫來說說比較容易，經(jīng)經(jīng)過測試之后后也未發(fā)生其其他的問題?？煽墒窃诳蛻舻牡沫h(huán)境下進(jìn)行行Beta測測試之后才發(fā)發(fā)現(xiàn)，客戶要要求提供支持持SQL數(shù)據(jù)據(jù)庫的功能，因因為他們希望望能夠統(tǒng)一管管理所

24、有的資資料。在這種種情況下，系系統(tǒng)測試工程程師必須將這這個問題呈現(xiàn)現(xiàn)出來，雖然然現(xiàn)在要求增增加這個需求求已經(jīng)太晚了了，不過可以以建議提供另另一種解決方方法，例如提提供一個資料料轉(zhuǎn)換工具或或是提供資料料導(dǎo)出的功能能。測試人員要隨時時對進(jìn)行測試試的功能保持持一個存疑的的態(tài)度，因為為這樣的問題題如果出現(xiàn)在在開發(fā)的后期期，所能提供供的解決方式式很有限，所所以早一點發(fā)發(fā)現(xiàn)這樣的問問題對提高整整個開發(fā)質(zhì)量量的幫助很大大。通常這樣樣的問題大都都是由經(jīng)驗豐豐富的測試工工程師發(fā)現(xiàn)的的。與使用者的互動動一個好的軟件必必須與使用者者之間正?；セ?。在使用用者操作使用用軟件的過程程中，軟件必必須很好地響響應(yīng)使用者。這

25、這個問題常常常有網(wǎng)絡(luò)中瀏瀏覽網(wǎng)頁時出出現(xiàn)。假設(shè)目目前使用者正正在某一個網(wǎng)網(wǎng)頁填寫資料料，但是所填填寫的資料不不足或是有誤誤。當(dāng)使用者者單擊了“確定”按鈕之后，網(wǎng)網(wǎng)頁響應(yīng)使用用者所填寫的的資料有錯，可可是并未指明明錯誤在哪里里，使用者只只好回到上一一頁后重新填填寫一次，或或是直接放棄棄離開網(wǎng)站。這個問題就是軟軟件對使用互互動并I未做完整的的設(shè)計，對于于屬于窗口程程序類型的軟軟件，這一點點也常常被忽忽略，例如當(dāng)當(dāng)使用者做任任何更新或刪刪除動作的前前后，程序是是否提供相應(yīng)應(yīng)的信息給使使用者？或?qū)λ鶊?zhí)行的動動作做確認(rèn)？如提供確認(rèn)認(rèn)窗口。與使使用者的互動動原則就是所所有的動作必必須伴隨著適適當(dāng)?shù)捻憫?yīng)（

26、EEvery actioon comme witth a rreactiion）。使用性能太差所測試的軟件功功能正常但是是使用性能太太差了，這樣樣算不算問題題呢？這個問問題，也經(jīng)常常有測試人員員問。使用性性能不佳，當(dāng)當(dāng)然是一個問問題，而問題題通常是由于于開發(fā)人員采采用了錯誤的的解決方案，或或是運(yùn)用了不不適用的算法法所導(dǎo)致的。例例如有一個軟軟件屬于C/S的企業(yè)軟軟件，Serrver端會會將Clieent傳遞上上來的資料做做好分類處理理。由于資料料所包含的種種類相當(dāng)多，于于是開發(fā)人員員將它分別存存入不同的資資料文件內(nèi)，例例如Clieent A送送給Servver的資料料種類有A11-A10，而而S

27、erveer就分別將將資料存到110個不同的的資料文件內(nèi)內(nèi)。這樣做的的結(jié)果是造成成使用者在做做資料查詢時時速度出奇地地慢，因為SServerr會逐一搜尋尋10個不同同的資料文件件內(nèi)容來做對對比。類似的例子相當(dāng)當(dāng)多，尋根究究底是因為未未做好基礎(chǔ)審審核（Arcchiteccture Revieew）及設(shè)計計審核（Deesign Revieew），可是是卻大都是在在進(jìn)行系統(tǒng)測測試或性能測測試時才顯示示出問題的嚴(yán)嚴(yán)重性。當(dāng)然然，在有些情情況下，項目目經(jīng)理或開發(fā)發(fā)人員會反駁駁說如此的使使用性能是在在合理的范圍圍內(nèi)。建議測測試人員將競競爭對手或同同類型的軟件件拿來做一個個性能測試，這這個測試的結(jié)結(jié)果最好以

28、數(shù)數(shù)字或百分比比的形式返回回給產(chǎn)品及開開發(fā)人員。這這樣的方式所所達(dá)到的效果果遠(yuǎn)比互相爭爭吵來得有效效得多。未做好錯誤處理理軟件除了避免出出錯之外，還還要做好錯誤誤處理。許多多軟件之所以以會產(chǎn)生錯誤誤，是因為程程序本身不知知道如何處理理所遇到的錯錯誤。譬如說說，所測試的的程序可以讀讀取外部的資資料文件并且且做一些分類類整理，可是是剛好所讀取取的外部資料料文件的內(nèi)容容是被損毀的的。當(dāng)程序讀讀取這個損毀毀的資料文件件時，程序就就發(fā)生問題，這這時候操作系系統(tǒng)不知如何何處理這個狀狀況，為了保保護(hù)自己只好好中斷程序。由由此可見這個個程序并未做做好錯誤處理理。除了做好好錯誤處理之之外，同時也也要設(shè)立防止止錯

29、誤發(fā)生的的機(jī)制。如上上述所說的，程程序在讀取外外部資料文件件之前，應(yīng)該該先檢查外部部資料文件是是否毀損，這這樣的方法才才比較保險。當(dāng)然，除了做好好錯誤處理之之外，產(chǎn)品是是否提供適當(dāng)當(dāng)?shù)恼{(diào)試機(jī)制制，也是測試試人員應(yīng)該注注意的。復(fù)雜雜的軟件如果果未提供調(diào)試試文檔或調(diào)試試方法，在以以后的維護(hù)過過程中將會吃吃盡苦頭。建建議在進(jìn)行軟軟件設(shè)計規(guī)格格階段時，最最好將調(diào)試機(jī)機(jī)制包含在內(nèi)內(nèi)，這對以后后的開發(fā)過程程與維護(hù)過程程絕對有很大大的幫助。邊界錯誤緩沖區(qū)溢出的問問題（Bufffer OOverfllows），這這幾年來成為為相當(dāng)熱門的的網(wǎng)絡(luò)攻擊方方式，而這個個錯誤就屬于于邊界錯誤的的一種。簡單單地說，程序序

30、本身無法處處理超過邊界界資料所導(dǎo)致致的錯誤。這這個問題有許許多情形是開開發(fā)人員在聲聲明變量或是是使用資料的的長度時不小小心引起的。計算錯誤只要是軟件程序序就免不了包包括數(shù)學(xué)計算算。軟件之所所以會出現(xiàn)計計算錯誤，大大部分出錯的的原因在于采采用了錯誤的的數(shù)學(xué)運(yùn)算或或未將計數(shù)器器歸0。使用一段時間所所產(chǎn)生的錯誤誤這個問題就是程程序剛開始運(yùn)運(yùn)行時很正常常，但在運(yùn)行行了一段時間間后卻出現(xiàn)問問題。最典型型的例子就是是數(shù)據(jù)庫的搜搜尋功能。有有一些軟件在在剛開始使用用時，所提供供的資料搜尋尋功能運(yùn)作良良好，可是在在使用了一段段時間后卻發(fā)發(fā)現(xiàn)，進(jìn)行資資料搜尋所需需的時間卻越越來越長了。結(jié)結(jié)果發(fā)現(xiàn)，所所采用的資料

31、料搜尋方式是是從第一筆搜搜查到最后一一筆的方法。類類似這樣的問問題可以解決決和避免。例子：有一個軟軟件提供組件件更新的功能能，程序會通通過因特網(wǎng)對對比下載最新新的組件，之之后程序會以以新的組件取取代舊的組件件。這個更新新程序做第一一次更新動作作的時候是正正確運(yùn)作，可可是如果再做做第二次更新新動作就毫無無作用了，其其原因很簡單單，開發(fā)人員員忘了將狀態(tài)態(tài)標(biāo)志恢復(fù)到到原來的狀態(tài)態(tài)，所以程序序無法再進(jìn)行行第二次的更更新動作?？刂屏鞒痰腻e誤誤控制流程的好與與壞，考驗著著開發(fā)人員對對軟件開發(fā)的的態(tài)度及設(shè)計計的程序是否否嚴(yán)謹(jǐn)。軟件件在狀態(tài)間的的轉(zhuǎn)變是否合合理，要依據(jù)據(jù)流程進(jìn)行控控制。相信許許多測試人員員在使

32、用軟件件時，有時候候會有這種感感覺為什么會跳跳到這一步？或是好像少少了一個步驟驟等類似的問問題，這就是是所謂的控制制流程錯誤。用軟件安裝程序序解釋這樣的的問題是最容容易的。譬如如使用者在進(jìn)進(jìn)行軟件安裝裝時，在輸入入用戶名及一一些其他資料料后，軟件就就直接進(jìn)行安安裝了，問題題就出在安裝裝程序并未為為使用者提供供可以選擇安安裝目的地的的狀態(tài)。這就就是軟件控制制流程不完整整的錯誤問題題。在壓力之下所產(chǎn)產(chǎn)生的錯誤程序在處于壓力力狀態(tài)下如果果運(yùn)作不正常常的話，就是是屬于這種軟軟件的錯誤。壓壓力測試對于于Serveer級的軟件件是必須要進(jìn)進(jìn)行的一項測測試，因為SServerr級的軟件對對穩(wěn)定度的要要求遠(yuǎn)比

33、其他他的軟件高。通通常一連串的的壓力測試是是必須配合著著測試軟件來來實施的，例例如讓程序處處理超過100萬筆的資料料，然后再來來觀察程序運(yùn)運(yùn)行的結(jié)果。要要準(zhǔn)備10萬萬筆的資料就就必須借助于于測試軟件。不同硬設(shè)備所導(dǎo)導(dǎo)致的錯誤顧名思義就是問問題的產(chǎn)生與與硬件設(shè)備不不同有關(guān)。如如果所開發(fā)的的軟件與硬件件設(shè)備有直接接的關(guān)系，這這樣的問題就就會相當(dāng)多，例例如光盤刻錄錄機(jī)的軟件就就存在不少這這樣的問題。例如：所開發(fā)的的軟件在特殊殊品牌的服務(wù)務(wù)器上運(yùn)行約約七八分鐘就就會停擺。版本控制不良所所產(chǎn)生的錯誤誤 出現(xiàn)這這樣的問題屬屬于項目管理理的疏忽，當(dāng)當(dāng)然測試人員員未善盡職守守也是原因之之一。在最近近的例子中有

34、有一個錯得很很冤，情形是是這家公司一一年前所出版版的一個軟件件被反應(yīng)有安安全上的漏洞洞，后來這家家公司也很快快將這個問題題的修正版提提供給客戶下下載。理論上上這個事件就就應(yīng)該平息了了，但是在一一年后他們在在推出新版本本時，卻忘記記將這個已解解決掉的問題題加入新版本本內(nèi)。所以對對舊客戶來說說，原本的問問題已經(jīng)解決決了，可是想想不到將版本本升級后，舊舊問題又出現(xiàn)現(xiàn)了。文件錯誤最后這個錯誤是是文件錯誤。這這里所提及的的錯誤除了軟軟件所附帶的的使用手冊、說說明文檔、FFAQ，以及及其他相關(guān)的的文件內(nèi)容除除了降低質(zhì)量量之外，最主主要的問題是是會誤導(dǎo)作用用者。很多客客戶投訴，不不滿使用手冊冊所提供的資資料

35、與實際不不符合。質(zhì)量控制部門的的組成部門的定位質(zhì)量控制部門不不僅僅是一個個測試部門，與與單純的測試試部門有著重重要的區(qū)別：測試針對一一個項目，包包含詳細(xì)的技技術(shù)工作，它它是項目組的的一個核心角角色。質(zhì)量控控制是公司的的一個職能部部門，它在一一個負(fù)責(zé)企業(yè)業(yè)質(zhì)量和標(biāo)準(zhǔn)準(zhǔn)實施和監(jiān)督督的人領(lǐng)導(dǎo)下下工作。質(zhì)量量控制也負(fù)責(zé)在在不同的項目目組之間共享享最好的實踐踐經(jīng)驗。部門成員的角色色及職責(zé)質(zhì)量控制部門的的角色分為七七種：質(zhì)量控控制經(jīng)理、質(zhì)質(zhì)量監(jiān)督員、測測試協(xié)調(diào)員、測測試執(zhí)行員、用用戶培訓(xùn)員、系系統(tǒng)實施員、過過程研究員。質(zhì)量控制經(jīng)理質(zhì)量控制經(jīng)理的的職責(zé)是：協(xié)調(diào)部門各角色色的工作，并并對最終發(fā)布布的產(chǎn)品、產(chǎn)產(chǎn)

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

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

38、程改進(jìn)方方案。部門成員的要求求產(chǎn)品質(zhì)量關(guān)系到到企業(yè)的生命命和前途，質(zhì)質(zhì)量控制部門門應(yīng)全程跟蹤蹤產(chǎn)品的開發(fā)發(fā)過程，是產(chǎn)產(chǎn)品質(zhì)量的最最后一道防線線，對最終發(fā)發(fā)布的產(chǎn)品的的質(zhì)量負(fù)有直直接的責(zé)任，所所以對部門成成員的要求是是：有高度的的責(zé)任心、對對工作的認(rèn)真真態(tài)度、具有有嚴(yán)謹(jǐn)和細(xì)致致的思維習(xí)慣慣。對測試人員的要要求 測試人人員包括：測測試協(xié)調(diào)員、測測試執(zhí)行員人是測試工作中中最有價值也也是最重要的的資源，沒有有一個合格的的、積極的測測試小組，測測試就不可能能實現(xiàn)。為高高質(zhì)高效地完完成測試任務(wù)務(wù)，好的測試試工程師應(yīng)具具有如下能力力：溝通能力一名理想的測試試者必須能夠夠同測試涉及及到的所有人人進(jìn)行溝通，具具

39、有與技術(shù)（開開發(fā)者）和非非技術(shù)人員（客客戶，管理人人員）的交流流能力。既要要可以和用戶戶談得來，又又能同開發(fā)人人員說得上話話，不幸的是是這兩類人沒沒有共同語言言。和用戶談?wù)勗挼闹攸c必必須放在系統(tǒng)統(tǒng)可以正確地地處理什么和和不可以處理理什么上。而而和開發(fā)者談?wù)勏嗤男畔⑾r，就必須須將這些活重重新組織以另另一種方式表表達(dá)出來，測測試小組的成成員必須能夠夠同等地同用用戶和開發(fā)者者溝通。技術(shù)能力就總體言，開發(fā)發(fā)人員對那些些不懂技術(shù)的的人持一種輕輕視的態(tài)度。一一旦測試小組組的某個成員員作出了一個個錯誤的斷定定，那么他們們的可信度就就會立刻被傳傳揚(yáng)了出去。一一個測試者必必須既明白被被測軟件系統(tǒng)統(tǒng)的概念又要

40、要會使用工程程中的那些工工具。要做到到這一點需要要有一定的編程經(jīng)經(jīng)驗，前期的的開發(fā)經(jīng)驗可可以幫助對軟軟件開發(fā)過程程有較深入的的理解，從開開發(fā)人員的角角度正確的評評價測試者，簡簡化自動測試試工具編程的的學(xué)習(xí)曲線。自信心開發(fā)者指責(zé)測試試者出了錯是是常有的事，測測試者必須對對自己的觀點點有足夠的自自信心。如果果容許別人對對自己指東指指西，就不能能完成什么更更多的事情了了。外交能力當(dāng)你告訴某人他他出了錯時，就就必須使用一一些外交方法法。機(jī)智老練練和外交手法法有助于維護(hù)護(hù)與開發(fā)人員員的協(xié)作關(guān)系系，測試者在在告訴開發(fā)者者他的軟件有有錯誤時，也也同樣需要一一定的外交手手腕。如果采采取的方法過過于強(qiáng)硬，對對測

41、試者來說說，在以后和和開發(fā)部門的的合作方面就就相當(dāng)于“贏了戰(zhàn)爭卻卻輸了戰(zhàn)役”。幽默感在遇到狡辯的情情況下，一個個幽默的批評評將是很有幫幫助的。懷疑精神可以預(yù)料，開發(fā)發(fā)者會盡他們們最大的努力力將所有的錯錯誤解釋過去去。測式者必必須聽每個人人的說明，但但他必須保持持懷疑直到他他自己看過以以后。自我督促干測試工作很容容易使你變得得懶散。只有有那些具有自自我督促能力力的人才能夠夠使自己每天天正常地工作作。洞察力一個好的測試工工程師具有“測試是為了了破壞”的觀點，捕捕獲用戶觀點點的能力，強(qiáng)強(qiáng)烈的質(zhì)量追追求，對細(xì)節(jié)節(jié)的關(guān)注能力力。應(yīng)用的高高風(fēng)險區(qū)的判判斷能力以便便將有限的測測試針對重點點環(huán)節(jié)。質(zhì)量控制部門

42、的的職責(zé)售前了解需求了解客戶需求、對對測試的具體體或特殊要求求。熟悉功能和性能能結(jié)合項目方案、需需求分析，熟熟悉和分析系系統(tǒng)功能、性性能指標(biāo)。確認(rèn)工期確認(rèn)測試所需的的工作量，提提供給項目負(fù)負(fù)責(zé)人以確認(rèn)認(rèn)項目工期。確定標(biāo)準(zhǔn)與開發(fā)組確定開開發(fā)標(biāo)準(zhǔn)和測測試標(biāo)準(zhǔn)。售中制定測試計劃根據(jù)用戶需求和和需求分析、設(shè)設(shè)計方案，制制定項目測測試計劃。產(chǎn)品測試測試的任務(wù)是保保證產(chǎn)品或服服務(wù)交付之前前，能夠發(fā)現(xiàn)現(xiàn)所有存在的的問題。測試試要準(zhǔn)備測試試計劃、測試試規(guī)定和測試試的用例，這些文文檔用于拓寬寬測試范圍和和進(jìn)行足夠的的可使用性測測試。在軟件件開發(fā)的項目目中，測試必必須針對所有有的接口，包包括API的的每個方面。將

43、將新軟件集成成到現(xiàn)行系統(tǒng)統(tǒng)時也必須進(jìn)進(jìn)行測試。系系統(tǒng)測試工作作全部完成后后要準(zhǔn)備測試試總結(jié)報告。測試的內(nèi)容包括括：代碼測試試、單元測試試、集成測試試、系統(tǒng)測試試、性能測試試、系統(tǒng)實施施測試、應(yīng)用用程序接口測測試。注：測試這種角角色必須獨立立于開發(fā)才是是真正有效的的。管理BUG測試要管理BUUG跟蹤數(shù)據(jù)據(jù)庫，并對BBUG報告的的質(zhì)量負(fù)責(zé)。BUG數(shù)據(jù)庫對于產(chǎn)生針對進(jìn)度跟蹤項目狀態(tài)的統(tǒng)計報告來說，是一種重要資源。BUG報告也用于確定項目進(jìn)度中的、關(guān)鍵部分的風(fēng)險。產(chǎn)品質(zhì)量的評審審 根據(jù)產(chǎn)產(chǎn)品測試報告告的對產(chǎn)品的的質(zhì)量進(jìn)行評評審，確定產(chǎn)產(chǎn)品是否可以以發(fā)布。項目文檔的評審審 根據(jù)項項目管理規(guī)范范，按時檢查

44、查各階段需提提交的開發(fā)文文檔，檢查開開發(fā)文檔的規(guī)規(guī)范性和正確確性，對文檔檔進(jìn)行評審。編制用戶手冊冊 在進(jìn)行行測試的過程程中，獲取系系統(tǒng)界面，并并對各項功能能和操作進(jìn)行行說明，最后后形成用戶戶手冊。用戶培訓(xùn)用戶培訓(xùn)的任務(wù)務(wù)是通過方案案演示和系統(tǒng)統(tǒng)培訓(xùn)，最大大可能性地使使系統(tǒng)的使用用者得到相關(guān)關(guān)產(chǎn)品和服務(wù)務(wù)的價值。用用戶培訓(xùn)的第二個個任務(wù)是通過過使產(chǎn)品更容容易理解和使使用，降低系系統(tǒng)技術(shù)支持持的費用。系統(tǒng)實施系統(tǒng)實施的任務(wù)務(wù)是確保產(chǎn)品品平穩(wěn)地過渡渡、安裝和移移交到產(chǎn)品操操作和技術(shù)支支持組手中。售后測試文檔提交將項目測試計計劃、項項目測試總結(jié)結(jié)報告以及及開發(fā)文檔交交項目管理部部相關(guān)負(fù)責(zé)人人。測試總結(jié)

45、總結(jié)測試中遇到到的問題、經(jīng)經(jīng)驗、測試方方法。完善測試標(biāo)準(zhǔn)、規(guī)規(guī)范 根據(jù)總總結(jié)的結(jié)論，對對不適合的測測試標(biāo)準(zhǔn)、規(guī)規(guī)范進(jìn)行修訂訂，使之更加加完善。過程改進(jìn)開發(fā)過程的評審審 根據(jù)項項目開發(fā)過程程中各標(biāo)準(zhǔn)的的執(zhí)行情況對對開發(fā)過程進(jìn)進(jìn)行評審。對開發(fā)過程的各各項標(biāo)準(zhǔn)的定定義 定義開開發(fā)過程中所所需要遵循的的各項標(biāo)準(zhǔn)，制制定標(biāo)準(zhǔn)有兩兩條原則：一一是標(biāo)準(zhǔn)應(yīng)有有利于穩(wěn)定質(zhì)質(zhì)量或在不損損害質(zhì)量的基基礎(chǔ)上降低開開發(fā)成本；二二是具有可執(zhí)執(zhí)行性。開發(fā)過程的持續(xù)續(xù)改進(jìn)根據(jù)開發(fā)過程的的評審結(jié)果及及產(chǎn)品質(zhì)量的的結(jié)果，找出出影響產(chǎn)品質(zhì)質(zhì)量的因素，并并改進(jìn)開發(fā)過過程的標(biāo)準(zhǔn)或或方法，保持持產(chǎn)品質(zhì)量的的穩(wěn)定和持續(xù)續(xù)上升。各項目組在開

46、發(fā)發(fā)過程中積累累的好的經(jīng)驗驗也可作為持持續(xù)改進(jìn)開發(fā)發(fā)過程的一個個重要參考。質(zhì)量控制部門的的工作規(guī)范共同分擔(dān)責(zé)任質(zhì)量控制經(jīng)理是是部門的負(fù)責(zé)責(zé)人，但部門門的每位成員員都有必要分分擔(dān)這個責(zé)任任。良好的工作心態(tài)態(tài)部門每一位成員員都應(yīng)始終保保持如下的工工作心態(tài)以保保證產(chǎn)品的成成功及個人成成長：高度責(zé)責(zé)任感、認(rèn)真真工作、思想想開放，有著著進(jìn)一步自我我發(fā)展的愿望望。工作計劃及進(jìn)度度控制充分了解客觀情情況，制訂切切實可行的工工作計劃，充充分利用時間間，對事情的的發(fā)展主動加加以控制，以以做好為目的的，對不可控控制事情及時時預(yù)警，避免免返工或重做做。充分相信信其他成員能能夠按時優(yōu)質(zhì)質(zhì)完成各自的的任務(wù)而不影影響其他

47、成員員的工作。積極參與及有效效溝通在任何需要的時時候都要積極極參與，充分分表達(dá)你的見見解，而不是是坐等被人問問起。主動與與其他小組成成員進(jìn)行明確確與及時的溝溝通，提倡建建設(shè)性的反饋饋，避免任何何指責(zé)性的言言語和行為。每每一位成員既既是問題的發(fā)發(fā)現(xiàn)者，又是是問題的解決決者。既便是是面對超出職職責(zé)范圍的問問題，也不能能以此作為推推諉的理由。建設(shè)良好的工作作環(huán)境共同創(chuàng)造積極而而又有建設(shè)性性的工作環(huán)境境：尊重部門門的所有成員員，也尊重其其他人的觀點點。認(rèn)識到個個人之間的差差別，不以自自己的意志及及好惡強(qiáng)求別別人。摒棄驕驕傲、自滿或或固執(zhí)的情緒緒，因為那會會影響到部門門成員的合作作與互助。拋棄自我拋棄自

48、我的概念念：團(tuán)隊的成成功高于一切切，個人的獲獲取是次要的的。在團(tuán)隊中中沒有自我的的概念，從而而也就沒有個個人的勝敗。如如果團(tuán)隊成功功了，每個人人都是贏家。不含敵意的沖突突不含敵意的沖突突是好的，它它能激起討論論，以澄清認(rèn)認(rèn)識并促成尋尋求新的方法法。每個人都都必須以積極極的態(tài)度對待待沖突，并愿愿意就面臨的的沖突廣泛交交換意見，盡盡力得到最好好、最全面的的解決方案，不不允許有任何何情緒化的言言論和行為。反反對無原則的的附和。在附附和意見之前前先問自己：出了門是不不是還會支持持決議？為其其辯護(hù)？如何解決問題解決問題的9個個步驟：說明明問題；發(fā)現(xiàn)現(xiàn)問題的可能能原因；收集集資料并明確確最可能原因因；明確

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

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

51、系統(tǒng)進(jìn)行一一級測試，測測試通過才能能進(jìn)行演示，以以保證演示順順利通過。問題二：BUGG遺漏率太大大如果測試人員的的BUG遺漏漏太多，就失失去測試的意意義了。原因分析：測試試人員要對以以上四個級別別的內(nèi)容都進(jìn)進(jìn)行測試，就就要考慮很多多方面的問題題，這需要具具有較強(qiáng)的思思維嚴(yán)密性，不不容易做到。解決方法：采用用測試分級方方案，系統(tǒng)提提交給測試人人員后，先進(jìn)進(jìn)行一級測試試，測試人員員只考慮一級級測試的內(nèi)容容，完成后提提交BUG給給開發(fā)人員。按按照一級測試試流程進(jìn)行（見見一級測試流流程圖）。一一級測試通過過后，再進(jìn)行行二級測試，這這樣逐級上升升，每個測試試級別只考慮慮比較單純的的問題，可以以減輕測試人人員的壓力，這這樣就對思維維嚴(yán)密性的要要求降低很多多，又能降低低BUG遺漏漏率。BUG處理BUG狀態(tài)說明明狀態(tài)說明標(biāo)注狀態(tài)的角色色1Open已經(jīng)發(fā)現(xiàn)的BUUG測試人員2Updatedd已被修正的BUUG開發(fā)人員3Disputeed有爭議的BUGG開發(fā)人員4False假BUG測試人員5Close測試證實已經(jīng)修修正的BUGG測試人員6Reopen.被修正的BUGG再次出現(xiàn)，NNO