1、第 PAGE32 頁 共 NUMPAGES32 頁質量控制部門職責跟分工定義質量的定義質量的靜態定義：產品或效勞能滿足規定或潛在需求的特性和特征的集合。質量的動態定義：是一個持續改良的過程，在這個過程中獲得的教訓被用于進步將來產品和效勞的質量。質量控制的定義質量控制是關于活動和技術的集合性術語，在此過程中，活動與技術旨在創造特定的質量特征。這種活動包括不斷監控過程、識別和消除產生問題的原因、利用統計過程控制來減少可變性和增加這些過程的效率。質量控制能保證組織的質量以實現。測試的定義在G.J.Myers的經典著作軟件測試技巧中，給出了測試的定義：“程序測試是為了發現錯誤而執行程序的過程”。什么才

2、是BUG斷定在測試中發現的問題是否屬于BUG，界定如下：功能不正常、難以使用、未做良好規劃、功能缺乏、與使用者互動不良、性能太差、未做好錯誤處理、邊界錯誤、計算錯誤、使用一段時間所產生的錯誤，控制流程的錯誤、在壓力之下所產生的錯誤、不同硬設備所導致的錯誤、版本控制不良所產生的錯誤和文件錯誤。功能不正常簡單地說就是所應提供的功能，在使用上并不符合設計規格，或是根本無法使用。這個錯誤常常會發生在測試過程的初期和中期，有許多在設計規格內所應提供的功能無法運行，或是運行結果達不到預期設計。是明顯的例子就是在UI上所提供的選項及動作，使用者在操作后毫無反響。難以使用的軟件只要是不知如何使用或難以使用的軟

3、件，在設計上一定是出了問題。所謂好用的軟件就是使用上盡量方便，壓低使用者的學習曲線。未做良好規劃這里可以區分出所測試的軟件是以Top-Down的方式開發，還是以Bottom-Up的方式開發的。假如是以Top-Down構造式方法所開發的軟件，在功能的規劃及組織上比擬完好，相反的Bottom-Up的組合式開發所呈現出來的軟件功能較為分散。舉例來說，假設有一個軟件提供了3個掃描的功能：實時掃描、手動掃描和全面掃描。就功能而言，這3種功能應該放到同一個掃描選項內，可是因為實時掃描是后來增加的，而且提供了立即編輯的功能，因此它被獨立出來成為另一個單獨選項。所造成的結果是許多的使用者誤以為在實時掃描所做的

4、立即編輯設置，應該可以套用在其他兩種掃描功能上。所提供的功能缺乏這個問題與功能不正常是不一樣的。這里所指的是軟件所提供的功能在動作上是正常的，可是對使用者而言卻是不完好的。即使軟件的功能運作結果符合設計規格的要求，系統測試人員在測試結果的判斷上，也一定要從使用者的角度進展考慮。這里舉一個例子，假設所測試的軟件提供了數據處理功能，但是采用的是封閉式的CodeBase數據庫。對開發人員來說，采用CodeBase的數據庫對程序編寫來說比擬容易，經過測試之后也未發生其他的問題。可是在客戶的環境下進展Beta測試之后才發現，客戶要求提供支持SQL數據庫的功能，因為他們希望可以統一管理所有的資料。在這種情

5、況下，系統測試工程師必須將這個問題呈現出來，雖然如今要求增加這個需求已經太晚了，不過可以建議提供另一種解決方法，例如提供一個資料轉換工具或是提供資料導出的功能。測試人員要隨時對進展測試的功能保持一個存疑的態度，因為這樣的問題假如出如今開發的后期，所能提供的解決方式很有限，所以早一點發現這樣的問題對進步整個開發質量的幫助很大。通常這樣的問題大都是由經歷豐富的測試工程師發現的。與使用者的互動一個好的軟件必須與使用者之間正常互動。在使用者操作使用軟件的過程中，軟件必須很好地響應使用者。這個問題常常有網絡中閱讀網頁時出現。假設目前使用者正在某一個網頁填寫資料，但是所填寫的資料缺乏或是有誤。當使用者單擊

6、了“確定”按鈕之后，網頁響應使用者所填寫的資料有錯，可是并未指明錯誤在哪里，使用者只好回到上一頁后重新填寫一次，或是直接放棄分開網站。這個問題就是軟件對使用互動并I未做完好的設計，對于屬于窗口程序類型的軟件，這一點也常常被忽略，例如當使用者做任何更新或刪除動作的前后，程序是否提供相應的信息給使用者？或對所執行的動作做確認？如提供確認窗口。與使用者的互動原那么就是所有的動作必須伴隨著適當的響應Every action e with a reaction。使用性能太差所測試的軟件功能正常但是使用性能太差了，這樣算不算問題呢？這個問題，也經常有測試人員問。使用性能不佳，當然是一個問題，而問題通常是由

7、于開發人員采用了錯誤的解決方案，或是運用了不適用的算法所導致的。例如有一個軟件屬于C/S的企業軟件，Server端會將Client傳遞上來的資料做好分類處理。由于資料所包含的種類相當多，于是開發人員將它分別存入不同的資料文件內，例如Client A送給Server的資料種類有A1-A10，而Server就分別將資料存到10個不同的資料文件內。這樣做的結果是造成使用者在做資料查詢時速度出奇地慢，因為Server會逐一搜尋10個不同的資料文件內容來做比照。類似的例子相當多，尋根究底是因為未做好根底審核Architecture Review及設計審核Design Review，可是卻大都是在進展系統

8、測試或性能測試時才顯示出問題的嚴重性。當然，在有些情況下，工程經理或開發人員會反駁說如此的使用性能是在合理的范圍內。建議測試人員將競爭對手或同類型的軟件拿來做一個性能測試，這個測試的結果最好以數字或百分比的形式返回給產品及開發人員。這樣的方式所到達的效果遠比互相爭吵來得有效得多。未做好錯誤處理軟件除了防止出錯之外，還要做好錯誤處理。許多軟件之所以會產生錯誤，是因為程序本身不知道如何處理所遇到的錯誤。譬如說，所測試的程序可以讀取外部的資料文件并且做一些分類整理，可是剛好所讀取的外部資料文件的內容是被損毀的。當程序讀取這個損毀的資料文件時，程序就發生問題，這時候操作系統不知如何處理這個狀況，為了保

9、護自己只好中斷程序。由此可見這個程序并未做好錯誤處理。除了做好錯誤處理之外，同時也要設立防止錯誤發生的機制。如上述所說的，程序在讀取外部資料文件之前，應該先檢查外部資料文件是否毀損，這樣的方法才比擬保險。當然，除了做好錯誤處理之外，產品是否提供適當的調試機制，也是測試人員應該注意的。復雜的軟件假如未提供調試文檔或調試方法，在以后的維護過程中將會吃盡苦頭。建議在進展軟件設計規格階段時，最好將調試機制包含在內，這對以后的開發過程與維護過程絕對有很大的幫助。邊界錯誤緩沖區溢出的問題Buffer Overflows，這幾年來成為相當熱門的網絡攻擊方式，而這個錯誤就屬于邊界錯誤的一種。簡單地說，程序本身

10、無法處理超過邊界資料所導致的錯誤。這個問題有許多情形是開發人員在聲明變量或是使用資料的長度時不小心引起的。計算錯誤只要是軟件程序就免不了包括數學計算。軟件之所以會出現計算錯誤，大局部出錯的原因在于采用了錯誤的數學運算或未將計數器歸0。使用一段時間所產生的錯誤這個問題就是程序剛開場運行時很正常，但在運行了一段時間后卻出現問題。最典型的例子就是數據庫的搜尋功能。有一些軟件在剛開場使用時，所提供的資料搜尋功能運作良好，可是在使用了一段時間后卻發現，進展資料搜尋所需的時間卻越來越長了。結果發現，所采用的資料搜尋方式是從第一筆搜尋到最后一筆的方法。類似這樣的問題可以解決和防止。例子：有一個軟件提供組件更

11、新的功能，程序會通過因特網比照下載最新的組件，之后程序會以新的組件取代舊的組件。這個更新程序做第一次更新動作的時候是正確運作，可是假如再做第二次更新動作就毫無作用了，其原因很簡單，開發人員忘了將狀態標志恢復到原來的狀態，所以程序無法再進展第二次的更新動作。控制流程的錯誤控制流程的好與壞，考驗著開發人員對軟件開發的態度及設計的程序是否嚴謹。軟件在狀態間的轉變是否合理，要根據流程進展控制。相信許多測試人員在使用軟件時，有時候會有這種感覺為什么會跳到這一步？或是好似少了一個步驟等類似的問題，這就是所謂的控制流程錯誤。用軟件安裝程序解釋這樣的問題是最容易的。譬如使用者在進展軟件安裝時，在輸入用戶名及一

12、些其他資料后，軟件就直接進展安裝了，問題就出在安裝程序并未為使用者提供可以選擇安裝目的地的狀態。這就是軟件控制流程不完好的錯誤問題。在壓力之下所產生的錯誤程序在處于壓力狀態下假如運作不正常的話，就是屬于這種軟件的錯誤。壓力測試對于Server級的軟件是必需要進展的一項測試，因為Server級的軟件對穩定度的要求遠比其他的軟件高。通常一連串的壓力測試是必須配合著測試軟件來施行的，例如讓程序處理超過10萬筆的資料，然后再來觀察程序運行的結果。要準備10萬筆的資料就必須借助于測試軟件。不同硬設備所導致的錯誤顧名思義就是問題的產生與硬件設備不同有關。假如所開發的軟件與硬件設備有直接的關系，這樣的問題就

13、會相當多，例如光盤刻錄機的軟件就存在不少這樣的問題。例如：所開發的軟件在特殊品牌的效勞器上運行約七八分鐘就會停擺。版本控制不良所產生的錯誤出現這樣的問題屬于工程管理的忽略，當然測試人員未善盡職守也是原因之一。在最近的例子中有一個錯得很冤，情形是這家公司一年前所出版的一個軟件被反響有平安上的破綻，后來這家公司也很快將這個問題的修正版提供應客戶下載。理論上這個事件就應該平息了，但是在一年后他們在推出新版本時，卻忘記將這個已解決掉的問題參加新版本內。所以對舊客戶來說，本來的問題已經解決了，可是想不到將版本晉級后，舊問題又出現了。文件錯誤最后這個錯誤是文件錯誤。這里所提及的錯誤除了軟件所附帶的使用手冊

14、、說明文檔、FAQ，以及其他相關的文件內容除了降低質量之外，最主要的問題是會誤導作用者。很多客戶投訴，不滿使用手冊所提供的資料與實際不符合。質量控制部門的組成部門的定位質量控制部門不僅僅是一個測試部門，與單純的測試部門有著重要的區別：測試針對一個工程，包含詳細的技術工作，它是工程組的一個核心角色。質量控制是公司的一個職能部門，它在一個負責企業質量和標準施行和監視的人領導下工作。質量控制也負責在不同的工程組之間共享最好的理論經歷。部門成員的角色及職責質量控制部門的角色分為七種：質量控制經理、質量監視員、測試協調員、測試執行員、用戶培訓員、系統施行員、過程研究員。質量控制經理質量控制經理的職責是：

15、協調部門各角色的工作，并對最終發布的產品、產品的文檔及整個開發過程進展評審。質量監視員質量監視員的職責是：參與工程組，具有使工程組成員充分理解各項標準和標準的責任；協助并監視工程組在開發過程中執行相關標準和標準；協助質量控制經理對開發過程進展評審；可根據執行情況對各項標準和標準提出改善建議。測試協調員測試協調員的職責是：針對某個產品或某個工程制定測試方案和測試方法，確定測試工期；根據各測試執行員提交的測試結果，完成工程或產品的測試總結報告。一個測試協調員的角色可由多個人員擔任，一個人員也可擔任多個測試協調員的角色。測試執行員測試執行員的職責是：根據測試協調員制定的測試方案和測試方法編寫測試說明

16、包括測試用例的設計和說明；對產品進展測試，并記錄測試結果；對BUG進展管理，保證它們在產品提交以前被解決；參與產品的質量評審。用戶培訓員用戶培訓員的職責是：參與系統測試，并在系統測試的同時獲取系統界面、理解系統的操作，完成用戶手冊和培訓教材；通過方案演示和系統培訓，最大可能性地使系統的使用者得到相關產品和效勞的價值。過程研究員過程研究員的職責是：參與工程或產品開發過程評審，參與產品質量評審，并根據評審結果對開發過程進展分析p ，找出影響產品質量的主要因素，并針對主要因素提出相應的過程改良方案。部門成員的要求產品質量關系到企業的生命和前途，質量控制部門應全程跟蹤產品的開發過程，是產品質量的最后一

17、道防線，對最終發布的產品的質量負有直接的責任，所以對部門成員的要求是：有高度的責任心、對工作的認真態度、具有嚴謹和細致的思維習慣。對測試人員的要求測試人員包括：測試協調員、測試執行員人是測試工作中最有價值也是最重要的資，沒有一個合格的、積極的測試小組，測試就不可能實現。為高質高效地完成測試任務，好的測試工程師應具有如下才能：溝通才能一名理想的測試者必須可以同測試涉及到的所有人進展溝通，具有與技術開發者和非技術人員客戶，管理人員的交流才能。既要可以和用戶談得來，又能同開發人員說得上話，不幸的是這兩類人沒有共同語言。和用戶談話的重點必須放在系統可以正確地處理什么和不可以處理什么上。而和開發者談一樣

18、的信息時，就必須將這些活重新組織以另一種方式表達出來，測試小組的成員必須可以同等地同用戶和開發者溝通。技術才能就總體言，開發人員對那些不懂技術的人持一種輕視的態度。一旦測試小組的某個成員作出了一個錯誤的斷定，那么他們的可信度就會立即被傳揚了出去。一個測試者必須既明白被測軟件系統的概念又要會使用工程中的那些工具。要做到這一點需要有一定的編程經歷，前期的開發經歷可以幫助對軟件開發過程有較深化的理解，從開發人員的角度正確的評價測試者，簡化自動測試工具編程的學習曲線。自信心開發者指責測試者出了錯是常有的事，測試者必須對自己的觀點有足夠的自信心。假如容許別人對自己指東指西，就不能完成什么更多的事情了。外

19、交才能當你告訴某人他出了錯時，就必須使用一些外交方法。機智老練和外交手法有助于維護與開發人員的協作關系，測試者在告訴開發者他的軟件有錯誤時，也同樣需要一定的外交手腕。假如采取的方法過于強硬，對測試者來說，在以后和開發部門的合作方面就相當于“贏了戰爭卻輸了戰役”。幽默感在遇到狡辯的情況下，一個幽默的批評將是很有幫助的。疑心精神可以意料，開發者會盡他們最大的努力將所有的錯誤解釋過去。測式者必須聽每個人的說明，但他必須保持疑心直到他自己看過以后。自我催促干測試工作很容易使你變得懶散。只有那些具有自我催促才能的人才可以使自己每天正常地工作。洞察力一個好的測試工程師具有“測試是為了破壞”的觀點，捕獲用戶

20、觀點的才能，強烈的質量追求，對細節的關注才能。應用的高風險區的判斷才能以便將有限的測試針對重點環節。質量控制部門的職責售前理解需求理解客戶需求、對測試的詳細或特殊要求。熟悉功能和性能結合工程方案、需求分析p ，熟悉和分析p 系統功能、性能指標。確認工期確認測試所需的工作量，提供應工程負責人以確認工程工期。確定標準與開發組確定開發標準和測試標準。售中制定測試方案根據用戶需求和需求分析p 、設計方案，制定工程測試方案。產品測試測試的任務是保證產品或效勞交付之前，可以發現所有存在的問題。測試要準備測試方案、測試規定和測試的用例，這些文檔用于拓寬測試范圍和進展足夠的可使用性測試。在軟件開發的工程中，測

21、試必須針對所有的接口，包括API的每個方面。將新軟件集成到現行系統時也必須進展測試。系統測試工作全部完成后要準備測試總結報告。測試的內容包括：代碼測試、單元測試、集成測試、系統測試、性能測試、系統施行測試、應用程序接口測試。注：測試這種角色必須獨立于開發才是真正有效的。管理BUG測試要管理BUG跟蹤數據庫，并對BUG報告的質量負責。BUG數據庫對于產生針對進度跟蹤工程狀態的統計報告來說，是一種重要資。BUG報告也用于確定工程進度中的、關鍵局部的風險。產品質量的評審根據產品測試報告的對產品的質量進展評審，確定產品是否可以發布。工程文檔的評審根據工程管理標準，按時檢查各階段需提交的開發文檔，檢查開

22、發文檔的標準性和正確性，對文檔進展評審。編制用戶手冊在進展測試的過程中，獲取系統界面，并對各項功能和操作進展說明，最后形成用戶手冊。用戶培訓用戶培訓的任務是通過方案演示和系統培訓，最大可能性地使系統的使用者得到相關產品和效勞的價值。用戶培訓的第二個任務是通過使產品更容易理解和使用，降低系統技術支持的費用。系統施行系統施行的任務是確保產品平穩地過渡、安裝和移交到產品操作和技術支持組手中。售后測試文檔提交將工程測試方案、工程測試總結報告以及開發文檔交工程管理部相關負責人。測試總結總結測試中遇到的問題、經歷、測試方法。完善測試標準、標準根據總結的結論，對不合適的測試標準、標準進展修訂，使之更加完善。

23、過程改良開發過程的評審根據工程開發過程中各標準的執行情況對開發過程進展評審。對開發過程的各項標準的定義定義開發過程中所需要遵循的各項標準，制定標準有兩條原那么：一是標準應有利于穩定質量或在不損害質量的根底上降低開發本錢；二是具有可執行性。開發過程的持續改良根據開發過程的評審結果及產品質量的結果，找出影響產品質量的因素，并改良開發過程的標準或方法，保持產品質量的穩定和持續上升。各工程組在開發過程中積累的好的經歷也可作為持續改良開發過程的一個重要參考。質量控制部門的工作標準共同分擔責任質量控制經理是部門的負責人，但部門的每位成員都有必要分擔這個責任。良好的工作心態部門每一位成員都應始終保持如下的工

24、作心態以保證產品的成功及個人成長：高度責任感、認真工作、思想開放，有著進一步自我開展的愿望。工作方案及進度控制充分理解客觀情況，制訂實在可行的工作方案，充分利用時間，對事情的開展主動加以控制，以做好為目的，對不可控制事情及時預警，防止返工或重做。充分相信其他成員可以按時優質完成各自的任務而不影響其他成員的工作。積極參與及有效溝通在任何需要的時候都要積極參與，充分表達你的見解，而不是坐等被人問起。主動與其他小組成員進展明確與及時的溝通，提倡建立性的反響，防止任何指責性的言語和行為。每一位成員既是問題的發現者，又是問題的解決者。既便是面對超出職責范圍的問題，也不能以此作為推諉的理由。建立良好的工作

25、環境共同創造積極而又有建立性的工作環境：尊重部門的所有成員，也尊重其別人的觀點。認識到個人之間的差異，不以自己的意志及好惡強求別人。摒棄驕傲、自滿或固執的情緒，因為那會影響到部門成員的合作與互助。拋棄自我拋棄自我的概念：團隊的成功高于一切，個人的獲取是次要的。在團隊中沒有自我的概念，從而也就沒有個人的勝敗。假如團隊成功了，每個人都是贏家。不含敵意的沖突不含敵意的沖突是好的，它能激起討論，以澄清認識并促成尋求新的方法。每個人都必須以積極的態度對待沖突，并愿意就面臨的沖突廣泛交換意見，盡力得到最好、解決方案，不允許有任何情緒化的言論和行為。反對無原那么的附和。在附和意見之前先問自己：出了門是不是還

26、會支持決議？為其辯護？如何解決問題解決問題的9個步驟：說明問題；發現問題的可能原因；搜集資料并明確最可能原因；明確可能方案；評估可行方案；決定最正確方案；修訂質量方案；施行方案；判斷問題是否得以解決。各項工作的標準在部門的各項工作的應遵循的標準和標準詳見測試標準、過程改良標準、產品和過程度量標準、工程文檔標準等。質量控制部門分級測試方案方案要到達的目的：1、防止再出現給用戶演示時出現較明顯的BUG。2、降低BUG的遺漏率。分級測試方案測試工作分為四級：一級測試內容1、正常操作，能否執行通過。2、需求描繪的功能是否實現只檢查功能實現，不考慮合理性。二級測試內容1、業務邏輯是否合理。2、用戶能否容

27、易上手。三級測試內容1、非正常操作包括邊界值、非法值、空值輸入等看是否有適宜的異常處理錯誤提示是否準確易懂。2、頁面布局及顯示信息如：tital顯示等。四級測試內容破壞性操作，如：多個用戶對同一條信息進展刪除等。性能測試。壓力測試。為什么采用分級測試方案在測試工作中遇到一些難以解決的問題，為理解決這些問題，制定了分級測試方案。問題一：用戶演示時出現錯誤頁面等明顯BUG原因分析p ：測試人員在測試中，要檢查系統所有方面的問題，涉及面廣，造成工作量龐大，不能及時對系統進展全面檢查。解決方法：采用測試分級方案，在給用戶演示前，應提早通知質量保證部，對系統進展一級測試，測試通過才能進展演示，以保證演示

28、順利通過。問題二：BUG遺漏率太大假如測試人員的BUG遺漏太多，就失去測試的意義了。原因分析p ：測試人員要對以上四個級別的內容都進展測試，就要考慮很多方面的問題，這需要具有較強的思維嚴密性，不容易做到。解決方法：采用測試分級方案，系統提交給測試人員后，先進展一級測試，測試人員只考慮一級測試的內容，完成后提交BUG給開發人員。按照一級測試流程進展見一級測試流程圖。一級測試通過后，再進展二級測試，這樣逐級上升，每個測試級別只考慮比擬單純的問題，可以減輕測試人員的壓力，這樣就對思維嚴密性的要求降低很多，又能降低BUG遺漏率。BUG處理BUG狀態說明狀態說明標注狀態的角色1Open已經發現的BUG測

29、試人員2Updated已被修正的BUG開發人員3Disputed有爭議的BUG開發人員4False假BUG測試人員5Close測試證實已經修正的BUG測試人員6測試人員BUG處理流程分級測試方案工作流程一級測試流程二級測試流程三級測試流程四級測試流程部門人員工作考核方案考核表測試工作考核表考核項權重%評分描繪測試溝通：與相關人員溝通，充分理解需求2025細致：沒有BUG遺漏35速度：可以在指定時間內完成20質量：無返工現象，符合要求25BUG記錄分級：對BUG分級的判斷準確1530BUG描繪：描繪準確，容易理解20修改意見：可以提出準確的修改意見25創新：能提出較好的解決方案15質量：無返工現象，符合要求25BUG追蹤主動追蹤BUG的修改情況4025溝通：開發人員對BUG的斷定有疑問時，能有效地與開發人員溝通，解決爭議60職業素質工作態度：工作熱情、不發牢騷2020服從性：可以按要求完成任務20克制困難：遇到困難能想方法并努力解決15責任心：對工作負責，不推卸責任20協作：能與其他員工有效配合進展工作15親和力：與所有人相處友善、和諧10測試工作考核分：等級：考核項權重%評分描繪理解需求溝通：與相關人員溝通，理解需求2025細致：沒有遺漏需求，理解充分35速度：可以在指定時間內完成20細化需求分析p ：對需求進展分析p 1530更改建議：對需