測試員入門培訓

測試員入門培訓唐滔?軟件工程?教學本文編寫目的這是為培訓專業(yè)測試人員參加測試工作，而編寫的包含測試根底知識的入門培訓教材。?軟件工程?教學讀者范圍將來參加測試工作的測試人員或者將來參加開發(fā)的程序員。?軟件工程?教學軟件缺陷軟件中含有符合下面5條規(guī)那么之一的問題稱為軟件缺陷：軟件未到達產(chǎn)品說明書標明的功能。軟件出現(xiàn)產(chǎn)品說明書指明不會出現(xiàn)的錯誤。軟件功能超出產(chǎn)品說明書指明的范圍。軟件未到達產(chǎn)品說明書未指出但應(yīng)到達的目標。軟件測試人員或用戶認為軟件難以理解，不易使用，運行速度緩慢等問題。?軟件工程?教學測試案例測試用例的別名。?軟件工程?教學黑盒測試指測試人員通過各種輸入和觀察軟件的各種輸出結(jié)果來發(fā)現(xiàn)軟件的缺陷，而不關(guān)心程序具體如何實現(xiàn)的一種測試方法。?軟件工程?教學靜態(tài)測試指測試不運行的局部，例如測試產(chǎn)品說明書，對此進展檢查和審閱。?軟件工程?教學靜態(tài)白盒測試指在不執(zhí)行的條件下有條理地仔細審查軟件設(shè)計，體系構(gòu)造和代碼，從而找出軟件缺陷的過程。有時稱作構(gòu)造分析。?軟件工程?教學動態(tài)測試通過運行和使用軟件進展測試。?軟件工程?教學探索測試通常用于沒有產(chǎn)品說明書的測試，這需要把軟件當作產(chǎn)品說明書來對待，分步驟逐項探索軟件特性，記錄軟件執(zhí)行情況，詳細描述功能，綜合利用靜態(tài)和動態(tài)技術(shù)來進展測試。?軟件工程?教學等價區(qū)間指測試一樣目標或者暴露一樣軟件缺陷的一組測試用例。?軟件工程?教學測試設(shè)計提煉測試方法，明確指出設(shè)計包含的特性和相關(guān)測試。如果要求完成測試還明確指出測試案例和測試程序，指定特性通過/失敗的規(guī)那么。?軟件工程?教學軟件QAQA=QualityAssessment質(zhì)量評價。防止軟件缺陷稱為軟件QA。?軟件工程?教學TQM或者TQC原理TQM(全面質(zhì)量管理)或者TQC(全面質(zhì)量控制)。其原理是，用集中的質(zhì)量評判團隊來負責質(zhì)量是不實際的，因為工作的人不負責質(zhì)量，所以他們不會設(shè)法實現(xiàn)質(zhì)量評判目的。要想制造高質(zhì)量產(chǎn)品，需要創(chuàng)立從管理開場自上而下的質(zhì)量意識，使全體成員共同承擔質(zhì)量責任。?軟件工程?教學SQC軟件質(zhì)量控制(SQC)是測試團隊很常用的名稱。該名稱來源于制造行業(yè)，其中QC檢驗員對生產(chǎn)線上的產(chǎn)品進展采樣、檢測，如果測試失敗，他有權(quán)停掉生產(chǎn)線或者整個工廠。測試團隊很少有這種授權(quán)。軟件QC團隊也是如此。?軟件工程?教學Murphy法那么永遠不會有足夠的時間把事情做好，但是總有時間返工。軟件開發(fā)小組需要遵循一個過程，花費一些時間，變得有條理，一開場就設(shè)法作對。?軟件工程?教學測試人員的目標找出軟件缺陷，盡可能早一些，并保證其得到修復。?軟件工程?教學測試工作過程要點利用組織良好的測試方案、測試案例和測試報告正確交流和制定來完成的測試工作，是測試員到達目標的保障。?軟件工程?教學檢查代碼靜態(tài)白盒測試進展靜態(tài)白盒測試的首要原因是盡早發(fā)現(xiàn)軟件缺陷，以找出動態(tài)黑盒測試難以提醒或遇到的軟件缺陷。獨立審查代碼的人越多越好，特別是在開發(fā)過程初期從底層進展。另外可以為黑盒測試人員提供思路，他們不必了解代碼的細節(jié)，但是根據(jù)審查備注，可以確定似乎有問題或者存在軟件缺陷的特征范圍。?軟件工程?教學開發(fā)小組沒有專人負責白盒測試，一般由程序員組織和執(zhí)行審查人員，軟件測試人員被當作獨立的觀察者。也有測試人員是該任務(wù)執(zhí)行人，要求編寫代碼的程序員和其他同事幫助審查。靜態(tài)白盒測試常見問題是不能善始善終。很多小組認為費用太高，沒有產(chǎn)出。這是不正確的，很多公司已經(jīng)招聘和培訓程序員和測試員進展白盒測試了。?軟件工程?教學正式審查正式審查有四個要素：確定問題。審查的目標是找出軟件問題，包括出錯工程和遺漏工程。遵守規(guī)那么。審查需要固定的規(guī)那么，如審查代碼的行數(shù)，花的時間，那些內(nèi)容需要備注等。準備。每個合作者需要知道自己的職責，很多問題是在準備期間發(fā)現(xiàn)的。編寫報告。必須有書面報告，使報告便于開發(fā)小組使用。?軟件工程?教學同事審查這是一種最簡單的方法，一般由一兩個程序員和測試員一起進展，為了不至于成為閑聊，需要遵守正式審查的四個要素。這種聚集起來討論代碼也可以找出軟件缺陷。?軟件工程?教學公開陳述編寫代碼的程序員向5人小組或者其他類似程序員和測試員正式表述。審查人員之中應(yīng)該有一名資深程序員是很重要的。?軟件工程?教學檢驗最正式的審查類型，參與者稱為檢驗員，職責從不同角度包括用戶，測試員和產(chǎn)品支持人員角度來審查產(chǎn)品。有些檢驗員被委任為會議主席和會議記錄，保證檢驗過程遵守規(guī)那么及審查。會議后可能檢驗員要碰頭討論發(fā)現(xiàn)的缺乏，程序員進展修改。最后由主席檢驗修改結(jié)果。檢驗被證明為在設(shè)計文檔和代碼中發(fā)現(xiàn)軟件缺陷最有效的方法。?軟件工程?教學編碼標準和標準可以運行并且測試中也表現(xiàn)穩(wěn)定的代碼被稱為有問題，令人不易理解。一般有三個重要原因需要堅持標準和標準：可靠性。事實證明按照某種標準或者規(guī)范寫的代碼更加可靠?？勺x性/維護性。符合設(shè)備標準的標準代碼容易閱讀、理解和維護。移植性。如果代碼符合設(shè)備標準，移植將很輕松。?軟件工程?教學靜態(tài)白盒測試可能遇到的問題類型數(shù)據(jù)引用出錯數(shù)據(jù)聲明錯計算錯誤比較錯誤控制流程錯誤子程序參數(shù)錯誤輸入/數(shù)出錯誤其他?軟件工程?教學動態(tài)白盒測試根本測試內(nèi)容：1、直接測試底層功能、過程、子程序和庫。2、以完整程序方式從頂層測試軟件，然后根據(jù)軟件運行了解和調(diào)整測試案例。3、從軟件獲得讀取變量和狀態(tài)信息的訪問權(quán)，以便確定測試與預期結(jié)果是否相等。4、估算執(zhí)行測試時命中的代碼量和具體代碼，然后調(diào)整測試。?軟件工程?教學動態(tài)白盒測試和調(diào)試兩者不能混為一談，雖然會有穿插，調(diào)試是程序員做的，目的是修復問題。測試是為了找到缺陷。測試員可能要使用代碼級調(diào)試器單步執(zhí)行，觀察變量，設(shè)置斷點等。對于要求合法性檢查的獨立代碼模塊，還要編寫測試程序進展測試。?軟件工程?教學黑盒與白盒黑盒與白盒進展白盒測試之前，要根據(jù)說明書建立黑盒測試案例，這種方法可以真正理解測試用途。否那么會偏向模塊的工作方式，程序員的說明也許包含錯誤，所以測試案例可能出現(xiàn)問題。?軟件工程?教學數(shù)據(jù)范圍白盒測試合理的方法是把軟件分成數(shù)據(jù)和狀態(tài)〔或者程序流程〕。同時可以把白盒信息映射到已經(jīng)寫完的黑盒案例中。首先考慮數(shù)據(jù)：包括所有變量、常量、數(shù)組、數(shù)據(jù)構(gòu)造、鍵盤鼠標輸入、文件、屏幕輸入輸出。以及調(diào)制解調(diào)器、網(wǎng)絡(luò)等其他設(shè)備的輸入/輸出。數(shù)據(jù)可以分成如下類型：數(shù)據(jù)流。觀察數(shù)據(jù)在各個模塊甚至整個程序中的各種狀態(tài)值。次邊界。尋找次邊界條件。比方2的乘方。公式和等式。比方被0除問題。錯誤強制。有的錯無條件不好模擬，需要制造錯誤。但是不要制造實際無法出現(xiàn)的錯誤。?軟件工程?教學代碼覆蓋為了全面，必須測試程序的狀態(tài)及其中的程序流程，設(shè)法進入和退出每一個模塊，執(zhí)行每一行代碼，追蹤每一條邏輯和決策分支。最簡單的方法是利用編譯環(huán)境單步執(zhí)行。大多數(shù)程序要用專門的代碼范圍分析器。需要注意的是，全部語句都執(zhí)行一遍，不等于走遍了軟件的所有路徑。所以需要分支覆蓋。分支覆蓋也不完全，還要考慮條件范圍問題。如果測試了所有可能的條件，到達了分支覆蓋，順便到達了語句覆蓋。?軟件工程?教學配置測試因為無法保證用戶的設(shè)備都符合通用的標準，所以需要把軟件放在用戶使用比較廣泛的硬件上進展測試。測試要點：確定需要測試的硬件類型。明確硬件標準。確定可能的硬件屬性，模式和選項。別離配置缺陷。等價分配。只測試各種硬件不穿插的局部。?軟件工程?教學文檔測試軟件測試員不僅要測試軟件同時需要測試文檔，因為他要負責整個軟件產(chǎn)品的各個局部的質(zhì)量。?軟件工程?教學文檔的類型包裝文字和圖形。市場宣傳資料、廣告和其他資料。授權(quán)/注冊登記表。EULA即最終用戶許可協(xié)議，一般要求用戶不經(jīng)同意不可以復制軟件，如果受到軟件缺陷的損害，不得向生產(chǎn)廠家起訴。標簽和不干膠。安裝和設(shè)置指導。用戶手冊。聯(lián)機幫助。指南，向?qū)Ш虲BT(計算機根底訓練)。樣例、例如和模板。錯誤提示信息。?軟件工程?教學文檔測試的重要性如果安裝指導有問題，不正確的錯誤提示信息把用戶引入歧途，他們會認為這是軟件缺陷。文檔和代碼對于用戶來說是一樣的。?軟件工程?教學文檔測試問題類型文檔面對的聽眾級別是否適宜。術(shù)語是否適用于聽眾，是否用法一致，所有術(shù)語是否可以被正確索引。內(nèi)容和主題是否有遺漏或者多余。材料深度是否適宜。所有信息是否準確。產(chǎn)品說明是否過時，技術(shù)支持網(wǎng)站鏈接和是否準確。逐步執(zhí)行。象用戶一樣來按步驟使用，看看是否遺漏某些說明。圖表和屏幕抓圖。來源和表現(xiàn)是否正確。樣例和例如。向客戶一樣使用樣例，如果是代碼就要執(zhí)行。樣例如果不能運行給客戶印象特別不好。拼寫和檢查。?軟件工程?教學其他測試以下測試內(nèi)容被省略：兼容性測試本地化測試易用性測試網(wǎng)站測試自動測試及測試工具?軟件工程?教學借助他人測試不同人的角度不同，可以有效打破殺蟲劑現(xiàn)象。請產(chǎn)品支持或者客戶效勞幫助測試是很有效的一種方法。?軟件工程?教學測試共享如果幾個測試員來測試，常用方法是在一定時間內(nèi)簡單互換測試任務(wù)。?軟件工程?教學測試轟炸測試人員同時停下工作，選擇軟件的某一塊區(qū)域，集中進展測試。稱為測試轟炸。?軟件工程?教學Beta測試他是一種外部測試方法。該過程中，軟件分發(fā)給選定的潛在用戶，他們在實際環(huán)境中使用軟件。Beta測試需要考慮的幾個問題：1、誰是Beta測試者Beta測試有不同的目標，所以必須了解測試者的類型。比方測試人員想要找出測試中殘存的易用性錯誤，如果Beta測試者是技術(shù)人員的話，將更關(guān)心底層的技術(shù)，對于易用性不是很關(guān)心，這樣測試效果將不是很好。?軟件工程?教學2、如何知道Beta測試者用過軟件1000個Beta測試者拿到Beta一個月后，沒有任何錯誤報告，是否可以認為沒有缺陷還是用戶沒有收到軟件，還是過些時間才開場測試。測試執(zhí)行者需要追問參加者，保證他們在使用軟件并符合方案的目標。?軟件工程?教學3、Beta測試的優(yōu)缺點Beta測試可以成為尋找配置和兼容性軟件缺陷的好方法。Beta測試對易用性測試非常有好處。Beta測試對于尋找其他軟件缺陷方面出人意料的差。?軟件工程?教學第三方測試提交給其他公司進展轉(zhuǎn)包測試，看上去比較麻煩，費用也高，但是如果做的好，可能成為共享測試的有效途徑。?軟件工程?教學方案測試工作測試過程不可能在真空里工作，程序員編寫代碼，不說明它的功能，如何工作，何時完成，執(zhí)行測試任務(wù)就難了。測試員之間不交流測試的對象，需要什么資源，進度如何安排，工程很難成功。方案測試工作主要目的是交流軟件測試小組的意圖、期望以及對將要執(zhí)行的任務(wù)的理解。而編制的測試方案通常成為空架子，以后不會有人看。所以方案工作的目標應(yīng)該從建立文檔轉(zhuǎn)移到方案建立過程。?軟件工程?教學1、測試方案主題由于測試一般都有模板，所以很容易作出方案文檔，然而如果只有文檔，當產(chǎn)品小組的人沒人知道測試員在做什么，或者為什么做的時候，測試的弊端就出來了。?軟件工程?教學1.1明確測試目標測試方案過程和軟件測試方案的目的是什么？程序員和技術(shù)作者及管理部門知道嗎？測試的產(chǎn)品是什么？是一個完全重寫一個產(chǎn)品還是僅僅維護和升級，是獨立程序還是很多小程序的組合？是自行開發(fā)的還是外包出去的，它的到底是什么東西？產(chǎn)品質(zhì)量和可靠性目標是什么？測試方案過程的結(jié)果必須是產(chǎn)品質(zhì)量和可靠性目標的清晰、簡潔和一致通過的定義。?軟件工程?教學2.測試的組織工作測試方案中應(yīng)該包括工程中所有主要人員的清單和聯(lián)系方式。同時，文檔存放的位置，測試工具從那里得到，使用什么硬件如果必要都需要指出。這些內(nèi)容最好類似于“測試新手問題指南〞。通常是新手負責的絕好局部，找到所有問題答案，把發(fā)現(xiàn)記錄下來。?軟件工程?教學3.明確定義常用一些定義需要明確：版本生成：測試方案應(yīng)該定義構(gòu)建版本的頻率〔每天或每周等等〕以及預定義的質(zhì)量等級。版本發(fā)布文檔：程序員提供的聲明新特性、不同特性、修復問題和準備測試的內(nèi)容。Alpha版：對少數(shù)主要客戶和市場進展數(shù)量有限的分發(fā)，用于演示的目的軟件版本。使用Alpha版的所有人應(yīng)該了解確切的內(nèi)容和質(zhì)量等級。Beta版：向潛在用戶廣泛分發(fā)的正式版本。說明書完成：說明書預計完成并且不再修改的方案安排。實際工作中，這個期限是無法實現(xiàn)的，但是需要確定下來，以后只會進展小的改動。軟件缺陷會議：由測試人員、工程管理員、開發(fā)管理員和產(chǎn)品支持組成的團隊，審查缺陷，決定那些需要修改，那些不需要。?軟件工程?教學4.需要和不需要測試的局部實際工作中有不需要測試局部存在的可能性。5.定義測試階段明確測試進入和退出的規(guī)那么。方案中應(yīng)該確定每個預定的階段。否那么就會成為無頭緒的單個工作。?軟件工程?教學6.決定測試策略使用白盒還是黑盒，如果需要結(jié)合在一起，如何做。是否使用工具，是否需要提交給其他專業(yè)公司測試。這項工作需要資深測試員來做。?軟件工程?教學7.資源要求人員設(shè)備辦公空間軟件是否或如何選擇測試公司其他供給：軟盤，，參考書，培訓資料等。?軟件工程?教學8.測試人員的任務(wù)分配9.測試進度如果一個特性雖然看起來很容易設(shè)計和完成，但是如果需要很多時間來測試，就要考慮是否要真正實現(xiàn)。另外測試工作量在軟家開發(fā)過程中是不平均分配的，比方從測試說明書和代碼審查開場，測試的任務(wù)，人員和工作量不斷增長，到產(chǎn)品發(fā)布之間會形成短暫的頂峰。結(jié)果是不斷受到先前事件影響，如果前提條件拖延，那么應(yīng)該壓縮測試時間還是把工程推遲，這稱為進度危機。為了防止這種危機，建議使用進入退出標志，使用相對進度：例如測試方案任務(wù)在說明書完成之后7天。期限4周。測試案例開場于測試方案完成需要12周。第一階段測試開場于代碼完成可測試版本，期限6周。第二階段測試開場于Beta版完成，期限6周。第三階段測試開場于軟件發(fā)布版本完成，期限4周。?軟件工程?教學10.測試案例方案決定使用什么方法編寫測試案例，那里保存，如何使用和維護。11.缺陷報告決定如何記錄和跟蹤缺陷。采用什么工具來跟蹤缺陷。?軟件工程?教學12.頻度和統(tǒng)計測試方案中應(yīng)該明確收集那些信息，做什么決定，誰來收集，例如：工程期間每天發(fā)現(xiàn)的軟件缺陷總數(shù)。仍然需要修復的軟件缺陷清單。根據(jù)嚴重程度對當前軟件缺陷評級。每個測試人員找出軟件缺陷的總數(shù)。從每個特性或者區(qū)域發(fā)現(xiàn)的軟件缺陷數(shù)目。?軟件工程?教學13.風險和問題明確指出工程的潛在問題或者風險區(qū)域，對測試工作的影響之處。?軟件工程?教學測試案例的編寫和跟蹤測試案例方案的目標測試員拿到測試方案馬上坐下來想出測試案例并開場計算是不正確的，正如程序員馬上拿到產(chǎn)品說明書馬上編碼一樣。需要仔細方案測試案例的原因：組織性：正確方案案例，可以組織好測試案例并且使全部測試員和其他成員有效審查和使用。重復性：工程期間需要屢次執(zhí)行同樣測試，需要有個方案。跟蹤：可以答復方案執(zhí)行多少個案例，最終版本需要多少案例，多少個通過，有被忽略等問題。測試證實：高風險行業(yè)，測試小組必須正式確實執(zhí)行了某些測試，發(fā)布忽略某些測試案例的軟件實際是危險和不合法的。?軟件工程?教學2.測試案例的要點ANSI/IEEE829標準：標識符：測試設(shè)計過程和測試程序說明引用的唯一標識符。測試項：被測試的詳細特性、代碼模塊等。如“加法運算的上限溢出錯誤〞。輸入說明：列舉送到軟件執(zhí)行測試案例的所有輸入內(nèi)容或者條件。輸出說明：描述進展測試案例的預期結(jié)果。環(huán)境要求：指執(zhí)行測試必須到達的軟、硬件、測試工具、實用工具、人員等要求。特殊要求：描述執(zhí)行測試必須做到的特殊要求。案例之間的依賴性：如果一個測試案例依賴于其他案例，應(yīng)該在此注明。實際上只能把上面的參考資料作為標準，而不是標準。大多時候使用簡便方法。需要發(fā)揮創(chuàng)造力，使用最有效的方法，使用簡單列表，大綱甚至狀態(tài)圖或者數(shù)據(jù)流程圖之類的圖表。設(shè)法與他人交流測試案例，并且使用最有效的方法，但不要偏離編寫測試案例的目的。?軟件工程?教學3.測試腳本說明該文檔定義了執(zhí)行測試案例的每一步步驟：標識符：把測試過程與相關(guān)測試案例和測試設(shè)計捆綁在一起的唯一表示符。目的：程序的目的及要執(zhí)行的測試案例的引用信息。特殊要求：執(zhí)行程序需要的其他程序、技術(shù)或者特殊設(shè)備。程序步驟：執(zhí)行測試的詳細步驟。日志：指出用什么方式、方法記錄結(jié)果和現(xiàn)象。設(shè)置：說明如何準備測試。啟動：說明啟動測試的步驟。?軟件工程?教學程序：描述用于運行測試的步驟。衡量標準：描述如何判斷標準－例如用秒表或者憑眼睛判斷。關(guān)閉：說明由于意外原因推遲測試的步驟。中止：描述測試正常停頓的步驟。重置：說明如何把環(huán)境恢復到測試前的狀態(tài)。偶然事件：說明如何處理方案之外的情況。對于測試過程只說：“嘗試執(zhí)行所有測試案例并回報發(fā)現(xiàn)的問題等〞是不夠的。應(yīng)該使用詳細的程序說明，要測試什么，如何測試都是一目了然的。?軟件工程?教學4.細節(jié)和真實“適可而止〞特別適用于測試案例方案。通常不可能需要按照最細致的程度編寫測試案例。無比詳盡的測試案例說明減少了隨意性，使測試很好重復，使無經(jīng)歷的測試員按照預定想法執(zhí)行測試。缺點是，編寫如此細致的測試案例說明需要化費很多時間和精力，增加升級難度。由于細節(jié)繁多，阻礙了測試工作，造成執(zhí)行測試時間變長。開場編寫測試案例時，最好的時機是采用當前工程的標準。?軟件工程?教學5.測試案例的組織和跟蹤一般應(yīng)該考慮下面的問題：方案執(zhí)行多少個測試案例？需要執(zhí)行多少時間？能否挑選出測試相關(guān)案例組測試某些特性或者軟件局部？執(zhí)行測試案例時，能否記錄那一個通過，那一個失敗。失敗的案例中，那些在上次執(zhí)行時也失敗了。上次執(zhí)行測試案例通過的百分比是多少。?軟件工程?教學6.跟蹤方式用腦子記是最不可取的。書面文檔。使用紙和筆填寫的含檢查清單的表格和框圖，提供了包含程序員簽字的書面檢查清單是法庭上證明測試執(zhí)行過程的極佳證據(jù)。使用電子表格是很流行的方法。自定義數(shù)據(jù)庫也是非常好的方法。?軟件工程?教學評價成效利用從缺陷跟蹤工具庫得到的數(shù)據(jù)可以答復類似下面的問題：正在測試的軟件各個區(qū)域缺陷分布情況。某個測試員已經(jīng)關(guān)閉的缺陷數(shù)。某個時間段找出的缺陷數(shù)。所有優(yōu)先級為“嚴重級〞的缺陷清單。軟件是否可以按正常發(fā)布期限發(fā)布。?軟件工程?教學日常測試中使用的指數(shù)一般可以給出下面這些問題的答案：交給我來關(guān)閉的已解決軟件缺陷的ID是什么？該工程輸入了多少軟件缺陷？針對用戶界面輸入那些軟件缺陷以不修復形式解決？發(fā)現(xiàn)的軟件中有多少嚴重級為1或者嚴重性為2的？全部缺陷中修復了多少？推遲了多少？重復了多少。各種統(tǒng)計指數(shù)分析：測序員發(fā)現(xiàn)的缺陷的優(yōu)先級比重餅圖。測試員發(fā)現(xiàn)的缺陷如何處理的直方圖?！残迯汀⑽磮蟾妗⒅匦绿峤?、不是問題、推遲修復〕。?軟件工程?教學2.常用工程級指數(shù)顯示軟件每個主要功能區(qū)發(fā)現(xiàn)軟件缺陷數(shù)目的工程級餅圖。發(fā)現(xiàn)缺陷的時序圖〔按每天發(fā)現(xiàn)缺陷情況〕可以發(fā)現(xiàn)很多問題。上面的圖加上累加軟件缺陷趨勢圖。隨時間推遲的翻開，解決和關(guān)閉的軟件缺陷圖。該圖表一般使用彩色表示：紅色代表翻開的軟件缺陷，黃色代表解決的軟件缺陷，綠色代表關(guān)閉的軟件缺陷。?軟件工程?教學軟件質(zhì)量評判制作高質(zhì)量產(chǎn)品的費用軟件缺陷發(fā)現(xiàn)的越晚，處理費用越高。2.軟件測試找出軟件缺陷，有效地描述他們，通知相應(yīng)的人，并跟蹤軟件缺陷直到解決。?軟件工程?教學3.質(zhì)量評判測試無法保證產(chǎn)品質(zhì)量。QA團隊是對工程進展近似完全地控制，建立標準和方法論，有條理地仔細監(jiān)視和評價軟件開發(fā)過程，對發(fā)現(xiàn)地軟件缺陷提出解決建議，執(zhí)行某些測試〔或者忽略〕，擁有決定產(chǎn)品何時發(fā)布的權(quán)。讓一個管理員力爭實現(xiàn)“無缺陷〞的目標，而不是使軟件如期發(fā)布或者低于預算。軟件QA的目標是防范軟件缺陷，在產(chǎn)品說明書、設(shè)計文檔和代碼上執(zhí)行靜態(tài)測試，就算一種軟件QA，因為這樣防止了軟件缺陷出現(xiàn)。?軟件工程?教學4.測試人員的其他任務(wù)軟件測試團隊進展配置管理或者構(gòu)造軟件等是不正常的。這樣作有兩個問題：占用了應(yīng)該用于測試產(chǎn)品的資源測試團隊的最終目的是破而不是立，成認軟件的構(gòu)造過程形成利益沖突。最好讓程序員或者獨立小組構(gòu)造軟件。測試應(yīng)該專注于尋找軟件缺陷。?軟件工程?教學5.測試管理與組織構(gòu)造要點小型開發(fā)小組〔小于10人〕常用組織構(gòu)造：測試團隊向管理員報告，他同時管理程序員的工作。這種組織形式的缺陷在于編寫代碼的人和尋找缺陷的人向同一個報告，可能引起利益沖突。開發(fā)管理員的目標是促使其小組開發(fā)軟件，測試員報告軟件缺陷只會阻礙這個過程。如果管理員為測試員提供很多資源和經(jīng)費，他們會找出更多缺陷，但他們找到的缺陷越多，就越阻礙管理員制作軟件的目標。但是如果開發(fā)管理員的經(jīng)歷很豐富，認識到其目標不僅是制作軟件，同時要制作高質(zhì)量軟件，這個構(gòu)造也可以運行的很好。管理員會一視同仁，有利于相互交流，管理層次也較少。?軟件工程?教學另一種組織構(gòu)造：測試團隊和開發(fā)團隊都向工程管理員報告。測試團隊一般有自己的負責人和管理員，其利益和注意力集中在測試小組及其工作上，這種獨立性在對軟件質(zhì)量做重大決定時極有好處。測試小組的意見與產(chǎn)品制作者的意見同等重要。然而，該組織構(gòu)造的缺點是工程管理員做最終決定。在高風險或者任務(wù)要求嚴格的系統(tǒng)開發(fā)中，由更高等級擁有質(zhì)量意見最終決定權(quán)是有益的。?軟件工程?教學最后一種組織構(gòu)造：該組織中，負責軟件質(zhì)量的小組直接向高級管理員報告，相對獨立，擁有與各工程同等的工程等級。該團隊的獨立性允許他們建立標準和標準，評價結(jié)果，采取跨越多個工程的處理措施。關(guān)于質(zhì)量優(yōu)略的信息可以直達最高層。這種授權(quán)，并不意味著他們可以在軟件工程和用戶不要求的前提下，建立不合理和難以實現(xiàn)的質(zhì)量目標。這個獨立的質(zhì)量組織必須設(shè)法面對所有的工程，利用發(fā)布軟件的經(jīng)歷穩(wěn)定盲目追求質(zhì)量的熱情。同時必須保持程序員和其他小組成員的嚴密合作關(guān)系。隨著交流路線的分散，這一點越來越難以控制。?軟件工程?教學6.能力成熟度模型〔