質量控制部門職責與分工

53/54目錄TOC\o"1-3"\h\z第1章 定義 21.1 質量的定義 21.2 質量操縱的定義 21.3 測試的定義 21.4 什么才是BUG 21.4.1 功能不正常 21.4.2 難以使用的軟件 21.4.3 未做良好規(guī)劃 21.4.4 所提供的功能不足 31.4.5 與使用者的互動 31.4.6 使用性能太差 31.4.7 未做好錯誤處理 41.4.8 邊界錯誤 41.4.9 計算錯誤 41.4.10 使用一段時刻所產生的錯誤 41.4.11 操縱流程的錯誤 41.4.12 在壓力之下所產生的錯誤 51.4.13 不同硬設備所導致的錯誤 51.4.14 版本操縱不良所產生的錯誤 51.4.15 文件錯誤 5第2章 質量操縱部門的組成 62.1 部門的定位 62.2 部門成員的角色及職責 62.2.1 質量操縱經理 62.2.2 質量監(jiān)督員 62.2.3 測試協調員 62.2.4 測試執(zhí)行員 62.2.5 用戶培訓員 62.2.6 系統(tǒng)實施員 72.2.7 過程研究員 72.3 部門成員的要求 72.3.1 對測試人員的要求 7第3章 質量操縱部門的職責 93.1 售前 93.1.1 了解需求 93.1.2 熟悉功能和性能 93.1.3 確認工期 93.1.4 確定標準 93.2 售中 93.2.1 制定測試打算 93.2.2 產品測試 93.2.3 治理BUG 93.2.4 產品質量的評審 93.2.5 項目文檔的評審 93.2.6 編制《用戶手冊》 93.2.7 用戶培訓 103.2.8 系統(tǒng)實施 103.3 售后 103.3.1 測試文檔提交 103.3.2 測試總結 103.3.3 完善測試標準、規(guī)范 103.4 過程改進 103.4.1 開發(fā)過程的評審 103.4.2 對開發(fā)過程的各項標準的定義 103.4.3 開發(fā)過程的持續(xù)改進 10第4章 質量操縱部門的工作規(guī)范 114.1 共同分擔責任 114.2 良好的工作心態(tài) 114.3 工作打算及進度操縱 114.4 積極參與及有效溝通 114.5 建設良好的工作環(huán)境 114.6 拋棄自我 114.7 不含敵意的沖突 114.8 如何解決問題 114.8.1 各項工作的規(guī)范 11第5章 質量操縱部門分級測試方案 125.1 方案要達到的目的： 125.2 分級測試方案 125.2.1 一級測試內容 125.2.2 二級測試內容 125.2.3 三級測試內容 125.2.4 四級測試內容 125.3 什么緣故采納分級測試方案 125.3.1 問題一：用戶演示時出現錯誤頁面等明顯BUG 125.3.2 問題二：BUG遺漏率太大 125.4 BUG狀態(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 用戶培訓考核表 176.2 考核講明 18定義質量的定義質量的靜態(tài)定義：產品或服務能滿足規(guī)定或潛在需求的特性和特征的集合。質量的動態(tài)定義：是一個持續(xù)改進的過程，在那個過程中取得的教訓被用于提高以后產品和服務的質量。質量操縱的定義質量操縱是關于活動和技術的集合性術語，在此過程中，活動與技術旨在制造特定的質量特征。這種活動包括不斷監(jiān)控過程、識不和消除產生問題的緣故、利用統(tǒng)計過程操縱來減少可變性和增加這些過程的效率。質量操縱能保證組織的質量以實現。測試的定義在G.J.Myers的經典著作《軟件測試技巧》中，給出了測試的定義：“程序測試是為了發(fā)覺錯誤而執(zhí)行程序的過程”。什么才是BUG判定在測試中發(fā)覺的問題是否屬于BUG，界定如下：功能不正常、難以使用、未做良好規(guī)劃、功能不足、與使用者互動不良、性能太差、未做好錯誤處理、邊界錯誤、計算錯誤、使用一段時刻所產生的錯誤，操縱流程的錯誤、在壓力之下所產生的錯誤、不同硬設備所導致的錯誤、版本操縱不良所產生的錯誤和文件錯誤。功能不正常簡單地講確實是所應提供的功能，在使用上并不符合設計規(guī)格，或是全然無法使用。那個錯誤常常會發(fā)生在測試過程的初期和中期，有許多在設計規(guī)格內所應提供的功能無法運行，或是運行結果達不到預期設計。是明顯的例子確實是在UI上所提供的選項及動作，使用者在操作后毫無反應。難以使用的軟件只要是不知如何使用或難以使用的軟件，在設計上一定是出了問題。所謂好用的軟件確實是使用上盡量方便，壓低使用者的學習曲線。未做良好規(guī)劃那個地點能夠區(qū)分出所測試的軟件是以Top-Down的方式開發(fā)，依舊以Bottom-Up的方式開發(fā)的。假如是以Top-Down結構式方法所開發(fā)的軟件，在功能的規(guī)劃及組織上比較完整，相反的Bottom-Up的組合式開發(fā)所呈現出來的軟件功能較為分散。舉例來講，假設有一個軟件提供了3個掃描的功能：實時掃描、手動掃描和全面掃描。就功能而言，這3種功能應該放到同一個掃描選項內，但是因為實時掃描是后來增加的，而且提供了立即編輯的功能，因此它被獨立出來成為另一個單獨選項。所造成的結果是許多的使用者誤以為在實時掃描所做的立即編輯設置，應該能夠套用在其他兩種掃描功能上。所提供的功能不足那個問題與功能不正常是不一樣的。那個地點所指的是軟件所提供的功能在動作上是正常的，但是對使用者而言卻是不完整的。即使軟件的功能運作結果符合設計規(guī)格的要求，系統(tǒng)測試人員在測試結果的推斷上，也一定要從使用者的角度進行考慮。那個地點舉一個例子，假設所測試的軟件提供了數據處理功能，然而采納的是封閉式的CodeBase數據庫。對開發(fā)人員來講，采納CodeBase的數據庫對程序編寫來講比較容易，通過測試之后也未發(fā)生其他的問題。但是在客戶的環(huán)境下進行Beta測試之后才發(fā)覺，客戶要求提供支持SQL數據庫的功能，因為他們希望能夠統(tǒng)一治理所有的資料。在這種情況下，系統(tǒng)測試工程師必須將那個問題呈現出來，盡管現在要求增加那個需求差不多太晚了，只是能夠建議提供另一種解決方法，例如提供一個資料轉換工具或是提供資料導出的功能。測試人員要隨時對進行測試的功能保持一個存疑的態(tài)度，因為如此的問題假如出現在開發(fā)的后期，所能提供的解決方式專門有限，因此早一點發(fā)覺如此的問題對提高整個開發(fā)質量的關心專門大。通常如此的問題大差不多上由經驗豐富的測試工程師發(fā)覺的。與使用者的互動一個好的軟件必須與使用者之間正?；印Ｔ谑褂谜卟僮魇褂密浖倪^程中，軟件必須專門好地響應使用者。那個問題常常有網絡中掃瞄網頁時出現。假設目前使用者正在某一個網頁填寫資料，然而所填寫的資料不足或是有誤。當使用者單擊了“確定”按鈕之后，網頁響應使用者所填寫的資料有錯，但是并未指明錯誤在哪里，使用者只好回到上一頁后重新填寫一次，或是直接放棄離開網站。那個問題確實是軟件對使用互動并I未做完整的設計，關于屬于窗口程序類型的軟件，這一點也常常被忽略，例如當使用者做任何更新或刪除動作的前后，程序是否提供相應的信息給使用者？或對所執(zhí)行的動作做確認？如提供確認窗口。與使用者的互動原則確實是所有的動作必須伴隨著適當的響應（Everyactioncomewithareaction）。使用性能太差所測試的軟件功能正常然而使用性能太差了，如此算不算問題呢？那個問題，也經常有測試人員問。使用性能不佳，因此是一個問題，而問題通常是由于開發(fā)人員采納了錯誤的解決方案，或是運用了不適用的算法所導致的。例如有一個軟件屬于C/S的企業(yè)軟件，Server端會將Client傳遞上來的資料做好分類處理。由于資料所包含的種類相當多，因此開發(fā)人員將它分不存入不同的資料文件內，例如ClientA送給Server的資料種類有A1-A10，而Server就分不將資料存到10個不同的資料文件內。如此做的結果是造成使用者在做資料查詢時速度出奇地慢，因為Server會逐一搜尋10個不同的資料文件內容來做對比。類似的例子相當多，尋根究底是因為未做好基礎審核（ArchitectureReview）及設計審核（DesignReview），但是卻大差不多上在進行系統(tǒng)測試或性能測試時才顯示出問題的嚴峻性。因此，在有些情況下，項目經理或開發(fā)人員會反駁講如此的使用性能是在合理的范圍內。建議測試人員將競爭對手或同類型的軟件拿來做一個性能測試，那個測試的結果最好以數字或百分比的形式返回給產品及開發(fā)人員。如此的方式所達到的效果遠比互相爭吵來得有效得多。未做好錯誤處理軟件除了幸免出錯之外，還要做好錯誤處理。許多軟件之因此會產生錯誤，是因為程序本身不明白如何處理所遇到的錯誤。譬如講，所測試的程序能夠讀取外部的資料文件同時做一些分類整理，但是剛好所讀取的外部資料文件的內容是被損毀的。當程序讀取那個損毀的資料文件時，程序就發(fā)生問題，這時候操作系統(tǒng)不知如何處理那個狀況，為了愛護自己只好中斷程序。由此可見那個程序并未做好錯誤處理。除了做好錯誤處理之外，同時也要設立防止錯誤發(fā)生的機制。如上述所講的，程序在讀取外部資料文件之前，應該先檢查外部資料文件是否毀損，如此的方法才比較保險。因此，除了做好錯誤處理之外，產品是否提供適當的調試機制，也是測試人員應該注意的。復雜的軟件假如未提供調試文檔或調試方法，在以后的維護過程中將會吃盡苦頭。建議在進行軟件設計規(guī)格時期時，最好將調試機制包含在內，這對以后的開發(fā)過程與維護過程絕對有專門大的關心。邊界錯誤緩沖區(qū)溢出的問題（BufferOverflows），這幾年來成為相當熱門的網絡攻擊方式，而那個錯誤就屬于邊界錯誤的一種。簡單地講，程序本身無法處理超過邊界資料所導致的錯誤。那個問題有許多情形是開發(fā)人員在聲明變量或是使用資料的長度時不小心引起的。計算錯誤只要是軟件程序就免不了包括數學計算。軟件之因此會出現計算錯誤，大部分出錯的緣故在于采納了錯誤的數學運算或未將計數器歸0。使用一段時刻所產生的錯誤那個問題確實是程序剛開始運行時專門正常，但在運行了一段時刻后卻出現問題。最典型的例子確實是數據庫的搜尋功能。有一些軟件在剛開始使用時，所提供的資料搜尋功能運作良好，但是在使用了一段時刻后卻發(fā)覺，進行資料搜尋所需的時刻卻越來越長了。結果發(fā)覺，所采納的資料搜尋方式是從第一筆搜查到最后一筆的方法。類似如此的問題能夠解決和幸免。例子：有一個軟件提供組件更新的功能，程序會通過因特網對比下載最新的組件，之后程序會以新的組件取代舊的組件。那個更新程序做第一次更新動作的時候是正確運作，但是假如再做第二次更新動作就毫無作用了，其緣故專門簡單，開發(fā)人員忘了將狀態(tài)標志恢復到原來的狀態(tài)，因此程序無法再進行第二次的更新動作。操縱流程的錯誤操縱流程的好與壞，考驗著開發(fā)人員對軟件開發(fā)的態(tài)度及設計的程序是否嚴謹。軟件在狀態(tài)間的轉變是否合理，要依據流程進行操縱。相信許多測試人員在使用軟件時，有時候會有這種感受—什么緣故會跳到這一步？或是看起來少了一個步驟等類似的問題，這確實是所謂的操縱流程錯誤。用軟件安裝程序解釋如此的問題是最容易的。譬如使用者在進行軟件安裝時，在輸入用戶名及一些其他資料后，軟件就直接進行安裝了，問題就出在安裝程序并未為使用者提供能夠選擇安裝目的地的狀態(tài)。這確實是軟件操縱流程不完整的錯誤問題。在壓力之下所產生的錯誤程序在處于壓力狀態(tài)下假如運作不正常的話，確實是屬于這種軟件的錯誤。壓力測試關于Server級的軟件是必須要進行的一項測試，因為Server級的軟件對穩(wěn)定度的要求遠比其他的軟件高。通常一連串的壓力測試是必須配合著測試軟件來實施的，例如讓程序處理超過10萬筆的資料，然后再來觀看程序運行的結果。要預備10萬筆的資料就必須借助于測試軟件。不同硬設備所導致的錯誤顧名思義確實是問題的產生與硬件設備不同有關。假如所開發(fā)的軟件與硬件設備有直接的關系，如此的問題就會相當多，例如光盤刻錄機的軟件就存在許多如此的問題。例如：所開發(fā)的軟件在專門品牌的服務器上運行約七八分鐘就會停擺。版本操縱不良所產生的錯誤出現如此的問題屬于項目治理的疏忽，因此測試人員未善盡職守也是緣故之一。在最近的例子中有一個錯得專門冤，情形是這家公司一年前所出版的一個軟件被反應有安全上的漏洞，后來這家公司也專門快將那個問題的修正版提供給客戶下載。理論上那個事件就應該平息了，然而在一年后他們在推出新版本時，卻不記得將那個已解決掉的問題加入新版本內。因此對舊客戶來講，原本的問題差不多解決了，但是想不到將版本升級后，舊問題又出現了。文件錯誤最后那個錯誤是文件錯誤。那個地點所提及的錯誤除了軟件所附帶的使用手冊、講明文檔、FAQ，以及其他相關的文件內容除了降低質量之外，最要緊的問題是會誤導作用者。專門多客戶投訴，不滿使用手冊所提供的資料與實際不符合。質量操縱部門的組成部門的定位質量操縱部門不僅僅是一個測試部門，與單純的測試部門有著重要的區(qū)不：測試針對一個項目，包含詳細的技術工作，它是項目組的一個核心角色。質量操縱是公司的一個職能部門，它在一個負責企業(yè)質量和標準實施和監(jiān)督的人領導下工作。質量操縱也負責在不同的項目組之間共享最好的實踐經驗。部門成員的角色及職責質量操縱部門的角色分為七種：質量操縱經理、質量監(jiān)督員、測試協調員、測試執(zhí)行員、用戶培訓員、系統(tǒng)實施員、過程研究員。質量操縱經理質量操縱經理的職責是：協調部門各角色的工作，并對最終公布的產品、產品的文檔及整個開發(fā)過程進行評審。質量監(jiān)督員質量監(jiān)督員的職責是：參與項目組，具有使項目組成員充分了解各項標準和規(guī)范的責任；協助并監(jiān)督項目組在開發(fā)過程中執(zhí)行相關標準和規(guī)范；協助質量操縱經理對開發(fā)過程進行評審；可依照執(zhí)行情況對各項標準和規(guī)范提出改善建議。測試協調員測試協調員的職責是：針對某個產品或某個項目制定測試打算和測試方法，確定測試工期；依照各測試執(zhí)行員提交的測試結果，完成項目或產品的測試總結報告。一個測試協調員的角色可由多個人員擔任，一個人員也可擔任多個測試協調員的角色。測試執(zhí)行員測試執(zhí)行員的職責是：依照測試協調員制定的測試打算和測試方法編寫測試講明包括測試用例的設計和講明；對產品進行測試，并記錄測試結果；對BUG進行治理，保證它們在產品提交往常被解決；參與產品的質量評審。用戶培訓員用戶培訓員的職責是：參與系統(tǒng)測試，并在系統(tǒng)測試的同時獵取系統(tǒng)界面、了解系統(tǒng)的操作，完成《用戶手冊》和培訓教材；通過方案演示和系統(tǒng)培訓，最大可能性地使系統(tǒng)的使用者得到相關產品和服務的價值。過程研究員過程研究員的職責是：參與項目或產品開發(fā)過程評審，參與產品質量評審，并依照評審結果對開發(fā)過程進行分析，找出阻礙產品質量的要緊因素，并針對要緊因素提出相應的過程改進方案。部門成員的要求產品質量關系到企業(yè)的生命和前途，質量操縱部門應全程跟蹤產品的開發(fā)過程，是產品質量的最后一道防線，對最終公布的產品的質量負有直接的責任，因此對部門成員的要求是：有高度的責任心、對工作的認真態(tài)度、具有嚴謹和細致的思維適應。對測試人員的要求測試人員包括：測試協調員、測試執(zhí)行員人是測試工作中最有價值也是最重要的資源，沒有一個合格的、積極的測試小組，測試就不可能實現。為高質高效地完成測試任務，好的測試工程師應具有如下能力：溝通能力一名理想的測試者必須能夠同測試涉及到的所有人進行溝通，具有與技術（開發(fā)者）和非技術人員（客戶，治理人員）的交流能力。既要能夠和用戶談得來，又能同開發(fā)人員講得上話，不幸的是這兩類人沒有共同語言。和用戶談話的重點必須放在系統(tǒng)能夠正確地處理什么和不能夠處理什么上。而和開發(fā)者談相同的信息時，就必須將這些活重新組織以另一種方式表達出來，測試小組的成員必須能夠同等地同用戶和開發(fā)者溝通。技術能力就總體言，開發(fā)人員對那些不明白技術的人持一種輕視的態(tài)度。一旦測試小組的某個成員作出了一個錯誤的斷定，那么他們的可信度就會趕忙被傳揚了出去。一個測試者必須既明白被測軟件系統(tǒng)的概念又要會使用工程中的那些工具。要做到這一點需要有一定的編程經驗，前期的開發(fā)經驗能夠關心對軟件開發(fā)過程有較深入的理解，從開發(fā)人員的角度正確的評價測試者，簡化自動測試工具編程的學習曲線。自信心開發(fā)者指責測試者出了錯是常有的事，測試者必須對自己的觀點有足夠的自信心。假如容許不人對自己指東指西，就不能完成什么更多的情況了。外交能力當你告訴某人他出了錯時，就必須使用一些外交方法。機智老練和外交手法有助于維護與開發(fā)人員的協作關系，測試者在告訴開發(fā)者他的軟件有錯誤時，也同樣需要一定的外交手腕。假如采取的方法過于強硬，對測試者來講，在以后和開發(fā)部門的合作方面就相當于“贏了戰(zhàn)爭卻輸了戰(zhàn)役”。幽默感在遇到狡辯的情況下，一個幽默的批判將是專門有關心的。懷疑精神能夠預料，開發(fā)者會盡他們最大的努力將所有的錯誤解釋過去。測式者必須聽每個人的講明，但他必須保持懷疑直到他自己看過以后。自我督促干測試工作專門容易使你變得懶散。只有那些具有自我督促能力的人才能夠使自己每天正常地工作。洞察力一個好的測試工程師具有“測試是為了破壞”的觀點，捕獲用戶觀點的能力，強烈的質量追求，對細節(jié)的關注能力。應用的高風險區(qū)的推斷能力以便將有限的測試針對重點環(huán)節(jié)。質量操縱部門的職責售前了解需求了解客戶需求、對測試的具體或專門要求。熟悉功能和性能結合項目方案、需求分析，熟悉和分析系統(tǒng)功能、性能指標。確認工期確認測試所需的工作量，提供給項目負責人以確認項目工期。確定標準與開發(fā)組確定開發(fā)標準和測試標準。售中制定測試打算依照用戶需求和需求分析、設計方案，制定《項目測試打算》。產品測試測試的任務是保證產品或服務交付之前，能夠發(fā)覺所有存在的問題。測試要預備測試打算、測試規(guī)定和測試的用例，這些文檔用于拓寬測試范圍和進行足夠的可使用性測試。在軟件開發(fā)的項目中，測試必須針對所有的接口，包括API的每個方面。將新軟件集成到現行系統(tǒng)時也必須進行測試。系統(tǒng)測試工作全部完成后要預備測試總結報告。測試的內容包括：代碼測試、單元測試、集成測試、系統(tǒng)測試、性能測試、系統(tǒng)實施測試、應用程序接口測試。注：測試這種角色必須獨立于開發(fā)才是真正有效的。治理BUG測試要治理BUG跟蹤數據庫，并對BUG報告的質量負責。BUG數據庫關于產生針對進度跟蹤項目狀態(tài)的統(tǒng)計報告來講，是一種重要資源。BUG報告也用于確定項目進度中的、關鍵部分的風險。產品質量的評審依照產品測試報告的對產品的質量進行評審，確定產品是否能夠公布。項目文檔的評審依照項目治理規(guī)范，按時檢查各時期需提交的開發(fā)文檔，檢查開發(fā)文檔的規(guī)范性和正確性，對文檔進行評審。編制《用戶手冊》在進行測試的過程中，獵取系統(tǒng)界面，并對各項功能和操作進行講明，最后形成《用戶手冊》。用戶培訓用戶培訓的任務是通過方案演示和系統(tǒng)培訓，最大可能性地使系統(tǒng)的使用者得到相關產品和服務的價值。用戶培訓的第二個任務是通過使產品更容易理解和使用，降低系統(tǒng)技術支持的費用。系統(tǒng)實施系統(tǒng)實施的任務是確保產品平穩(wěn)地過渡、安裝和移交到產品操作和技術支持組手中。售后測試文檔提交將《項目測試打算》、《項目測試總結報告》以及開發(fā)文檔交項目治理部相關負責人。測試總結總結測試中遇到的問題、經驗、測試方法。完善測試標準、規(guī)范依照總結的結論，對不適合的測試標準、規(guī)范進行修訂，使之更加完善。過程改進開發(fā)過程的評審依照項目開發(fā)過程中各標準的執(zhí)行情況對開發(fā)過程進行評審。對開發(fā)過程的各項標準的定義定義開發(fā)過程中所需要遵循的各項標準，制定標準有兩條原則：一是標準應有利于穩(wěn)定質量或在不損害質量的基礎上降低開發(fā)成本；二是具有可執(zhí)行性。開發(fā)過程的持續(xù)改進依照開發(fā)過程的評審結果及產品質量的結果，找出阻礙產品質量的因素，并改進開發(fā)過程的標準或方法，保持產品質量的穩(wěn)定和持續(xù)上升。各項目組在開發(fā)過程中積存的好的經驗也可作為持續(xù)改進開發(fā)過程的一個重要參考。質量操縱部門的工作規(guī)范共同分擔責任質量操縱經理是部門的負責人，但部門的每位成員都有必要分擔那個責任。良好的工作心態(tài)部門每一位成員都應始終保持如下的工作心態(tài)以保證產品的成功及個人成長：高度責任感、認真工作、思想開放，有著進一步自我進展的愿望。工作打算及進度操縱充分了解客觀情況，制訂切實可行的工作打算，充分利用時刻，對情況的進展主動加以操縱，以做好為目的，對不可操盡情況及時預警，幸免返工或重做。充分相信其他成員能夠按時優(yōu)質完成各自的任務而不阻礙其他成員的工作。積極參與及有效溝通在任何需要的時候都要積極參與，充分表達你的見解，而不是坐等被人問起。主動與其他小組成員進行明確與及時的溝通，提倡建設性的反饋，幸免任何指責性的言語和行為。每一位成員既是問題的發(fā)覺者，又是問題的解決者。既便是面對超出職責范圍的問題，也不能以此作為推諉的理由。建設良好的工作環(huán)境共同制造積極而又有建設性的工作環(huán)境：尊重部門的所有成員，也尊重其他人的觀點。認識到個人之間的差不，不以自己的意志及好惡強求不人。摒棄驕傲、自滿或固執(zhí)的情緒，因為那會阻礙到部門成員的合作與互助。拋棄自我拋棄自我的概念：團隊的成功高于一切，個人的獵取是次要的。在團隊中沒有自我的概念，從而也就沒有個人的勝敗。假如團隊成功了，每個人差不多上贏家。不含敵意的沖突不含敵意的沖突是好的，它能激起討論，以澄清認識并促成尋求新的方法。每個人都必須以積極的態(tài)度對待沖突，并情愿就面臨的沖突廣泛交換意見，盡力得到最好、最全面的解決方案，不同意有任何情緒化的言論和行為。反對無原則的附和。在附和意見之前先問自己：出了門是不是還會支持決議？為其辯護？如何解決問題解決問題的9個步驟：講明問題；發(fā)覺問題的可能緣故；收集資料并明確最可能緣故；明確可能方案；評估可行方案；決定最佳方案；修訂質量打算；實施方案；推斷問題是否得以解決。各項工作的規(guī)范在部門的各項工作的應遵循的標準和規(guī)范詳見《測試規(guī)范》、《過程改進規(guī)范》、《產品和過程度量標準》、《項目文檔規(guī)范》等。質量操縱部門分級測試方案方案要達到的目的：1、幸免再出現給用戶演示時出現較明顯的BUG。2、降低BUG的遺漏率。分級測試方案測試工作分為四級：一級測試內容1、正常操作，能否執(zhí)行通過。2、需求描述的功能是否實現（只檢查功能實現，不考慮合理性）。二級測試內容1、業(yè)務邏輯是否合理。2、用戶能否容易上手。三級測試內容1、非正常操作（包括邊界值、非法值、空值輸入等）看是否有合適的異常處理（錯誤提示是否準確易明白）。2、頁面布局及顯示信息（如：tital顯示等）。四級測試內容破壞性操作，如：多個用戶對同一條信息進行刪除等。性能測試。壓力測試。什么緣故采納分級測試方案在測試工作中遇到一些難以解決的問題，為了解決這些問題，制定了分級測試方案。問題一：用戶演示時出現錯誤頁面等明顯BUG緣故分析：測試人員在測試中，要檢查系統(tǒng)所有方面的問題，涉及面廣，造成工作量龐大，不能及時對系統(tǒng)進行全面檢查。解決方法：采納測試分級方案，在給用戶演示前，應提早通知質量保證部，對系統(tǒng)進行一級測試，測試通過才能進行演示，以保證演示順利通過。問題二：BUG遺漏率太大假如測試人員的BUG遺漏太多，就失去測試的意義了。緣故分析：測試人員要對以上四個級不的內容都進行測試，就要考慮專門多方面的問題，這需要具有較強的思維嚴密性，不容易做到。解決方法：采納測試分級方案，系統(tǒng)提交給測試人員后，先進行一級測試，測試人員只考慮一級測試的內容，完成后提交BUG給開發(fā)人員。按照一級測試流程進行（見一級測試流程圖）。一級測試通過后，再進行二級測試，如此逐級上升，每個測試級不只考慮比較單純的問題，能夠減輕測試人員的壓力，如此就對思維嚴密性的要求降低專門多，又能降低BUG遺漏率。BUG處理BUG狀態(tài)講明狀態(tài)講明標注狀態(tài)的角色1Open差不多發(fā)覺的BUG測試人員2Updated已被修正的BUG開發(fā)人員3