測試員入門培訓唐滔2009.10.10《軟件工程》教學測試員入門培訓唐滔《軟件工程》教學1本文編寫目的這是為培訓專業(yè)測試人員參加測試工作，而編寫的包含測試基礎(chǔ)知識的入門培訓教材?！盾浖こ獭方虒W本文編寫目的《軟件工程》教學2讀者范圍將來參加測試工作的測試人員或者將來參加開發(fā)的程序員?！盾浖こ獭方虒W讀者范圍《軟件工程》教學3軟件缺陷軟件中含有符合下面5條規(guī)則之一的問題稱為軟件缺陷：軟件未達到產(chǎn)品說明書標明的功能。軟件出現(xiàn)產(chǎn)品說明書指明不會出現(xiàn)的錯誤。軟件功能超出產(chǎn)品說明書指明的范圍。軟件未達到產(chǎn)品說明書未指出但應(yīng)達到的目標。軟件測試人員或用戶認為軟件難以理解，不易使用，運行速度緩慢等問題。《軟件工程》教學軟件缺陷軟件中含有符合下面5條規(guī)則之一的問題稱為軟件缺陷4測試案例測試用例的別名?！盾浖こ獭方虒W測試案例《軟件工程》教學5黑盒測試指測試人員通過各種輸入和觀察軟件的各種輸出結(jié)果來發(fā)現(xiàn)軟件的缺陷，而不關(guān)心程序具體如何實現(xiàn)的一種測試方法?！盾浖こ獭方虒W黑盒測試《軟件工程》教學6靜態(tài)測試指測試不運行的部分，例如測試產(chǎn)品說明書，對此進行檢查和審閱。《軟件工程》教學靜態(tài)測試《軟件工程》教學7靜態(tài)白盒測試指在不執(zhí)行的條件下有條理地仔細審查軟件設(shè)計，體系結(jié)構(gòu)和代碼，從而找出軟件缺陷的過程。有時稱作結(jié)構(gòu)分析?！盾浖こ獭方虒W靜態(tài)白盒測試《軟件工程》教學8動態(tài)測試通過運行和使用軟件進行測試?！盾浖こ獭方虒W動態(tài)測試通過運行和使用軟件進行測試?！盾浖こ獭方虒W9探索測試通常用于沒有產(chǎn)品說明書的測試，這需要把軟件當作產(chǎn)品說明書來看待，分步驟逐項探索軟件特性，記錄軟件執(zhí)行情況，詳細描述功能，綜合利用靜態(tài)和動態(tài)技術(shù)來進行測試?！盾浖こ獭方虒W探索測試通常用于沒有產(chǎn)品說明書的測試，這需要把軟件當作產(chǎn)品說10等價區(qū)間指測試相同目標或者暴露相同軟件缺陷的一組測試用例。《軟件工程》教學等價區(qū)間指測試相同目標或者暴露相同軟件缺陷的一組測試用例。11測試設(shè)計提煉測試方法，明確指出設(shè)計包含的特性和相關(guān)測試。如果要求完成測試還明確指出測試案例和測試程序，指定特性通過/失敗的規(guī)則。《軟件工程》教學測試設(shè)計提煉測試方法，明確指出設(shè)計包含的特性和相關(guān)測試。如果12軟件QAQA=QualityAssessment質(zhì)量評價。防止軟件缺陷稱為軟件QA?！盾浖こ獭方虒W軟件QAQA=QualityAssessment質(zhì)量評13TQM或者TQC原理TQM(全面質(zhì)量管理)或者TQC(全面質(zhì)量控制)。其原理是，用集中的質(zhì)量評判團隊來負責質(zhì)量是不實際的，因為工作的人不負責質(zhì)量，所以他們不會設(shè)法實現(xiàn)質(zhì)量評判目的。要想制造高質(zhì)量產(chǎn)品，需要創(chuàng)立從管理開始自上而下的質(zhì)量意識，使全體成員共同承擔質(zhì)量責任?！盾浖こ獭方虒WTQM或者TQC原理TQM(全面質(zhì)量管理)或者TQC(全14SQC軟件質(zhì)量控制(SQC)是測試團隊很常用的名稱。該名稱來源于制造行業(yè)，其中QC檢驗員對生產(chǎn)線上的產(chǎn)品進行采樣、檢測，如果測試失敗，他有權(quán)停掉生產(chǎn)線或者整個工廠。測試團隊很少有這種授權(quán)。軟件QC團隊也是如此。《軟件工程》教學SQC軟件質(zhì)量控制(SQC)是測試團隊很常用的名稱。該名稱來15Murphy法則永遠不會有足夠的時間把事情做好，但是總有時間返工。軟件開發(fā)小組需要遵循一個過程，花費一些時間，變得有條理，一開始就設(shè)法作對?！盾浖こ獭方虒WMurphy法則永遠不會有足夠的時間把事情做好，但是總有時16測試人員的目標找出軟件缺陷，盡可能早一些，并保證其得到修復。《軟件工程》教學測試人員的目標找出軟件缺陷，盡可能早一些，并保證其得到修復。17測試工作過程要點利用組織良好的測試計劃、測試案例和測試報告正確交流和制定來完成的測試工作，是測試員達到目標的保障?！盾浖こ獭方虒W測試工作過程要點利用組織良好的測試計劃、測試案例和測試報告正18檢查代碼靜態(tài)白盒測試進行靜態(tài)白盒測試的首要原因是盡早發(fā)現(xiàn)軟件缺陷，以找出動態(tài)黑盒測試難以揭示或遇到的軟件缺陷。獨立審查代碼的人越多越好，特別是在開發(fā)過程初期從底層進行。另外可以為黑盒測試人員提供思路，他們不必了解代碼的細節(jié)，但是根據(jù)審查備注，可以確定似乎有問題或者存在軟件缺陷的特征范圍?！盾浖こ獭方虒W檢查代碼靜態(tài)白盒測試《軟件工程》教學19開發(fā)小組沒有專人負責白盒測試，一般由程序員組織和執(zhí)行審查人員，軟件測試人員被當作獨立的觀察者。也有測試人員是該任務(wù)執(zhí)行人，要求編寫代碼的程序員和其他同事幫助審查。靜態(tài)白盒測試常見問題是不能善始善終。很多小組認為費用太高，沒有產(chǎn)出。這是不正確的，很多公司已經(jīng)招聘和培訓程序員和測試員進行白盒測試了?！盾浖こ獭方虒W開發(fā)小組沒有專人負責白盒測試，一般由程序員組織和執(zhí)行審查人員20正式審查正式審查有四個要素：確定問題。審查的目標是找出軟件問題，包括出錯項目和遺漏項目。遵守規(guī)則。審查需要固定的規(guī)則，如審查代碼的行數(shù)，花的時間，那些內(nèi)容需要備注等。準備。每個合作者需要知道自己的職責，很多問題是在準備期間發(fā)現(xiàn)的。編寫報告。必須有書面報告，使報告便于開發(fā)小組使用?！盾浖こ獭方虒W正式審查正式審查有四個要素：《軟件工程》教學21同事審查這是一種最簡單的方法，一般由一兩個程序員和測試員一起進行，為了不至于成為閑聊，需要遵守正式審查的四個要素。這種聚集起來討論代碼也可以找出軟件缺陷?！盾浖こ獭方虒W同事審查這是一種最簡單的方法，一般由一兩個程序員和測試員一起22公開陳述編寫代碼的程序員向5人小組或者其他類似程序員和測試員正式表述。審查人員之中應(yīng)該有一名資深程序員是很重要的?！盾浖こ獭方虒W公開陳述編寫代碼的程序員向5人小組或者其他類似程序員和測23檢驗最正式的審查類型，參與者稱為檢驗員，職責從不同角度包括用戶，測試員和產(chǎn)品支持人員角度來審查產(chǎn)品。有些檢驗員被委任為會議主席和會議記錄，保證檢驗過程遵守規(guī)則及審查。會議后可能檢驗員要碰頭討論發(fā)現(xiàn)的不足，程序員進行修改。最后由主席檢驗修改結(jié)果。檢驗被證明為在設(shè)計文檔和代碼中發(fā)現(xiàn)軟件缺陷最有效的方法?！盾浖こ獭方虒W檢驗最正式的審查類型，參與者稱為檢驗員，職責從不同角度包括用24編碼規(guī)范和標準可以運行并且測試中也表現(xiàn)穩(wěn)定的代碼被稱為有問題，令人不易理解。一般有三個重要原因需要堅持標準和規(guī)范：可靠性。事實證明按照某種標準或者規(guī)范寫的代碼更加可靠?？勺x性/維護性。符合設(shè)備標準的規(guī)范代碼容易閱讀、理解和維護。移植性。如果代碼符合設(shè)備標準，移植將很輕松?！盾浖こ獭方虒W編碼規(guī)范和標準可以運行并且測試中也表現(xiàn)穩(wěn)定的代碼被稱為有問題25靜態(tài)白盒測試可能遇到的問題類型數(shù)據(jù)引用出錯數(shù)據(jù)聲明錯計算錯誤比較錯誤控制流程錯誤子程序參數(shù)錯誤輸入/數(shù)出錯誤其他《軟件工程》教學靜態(tài)白盒測試可能遇到的問題類型數(shù)據(jù)引用出錯《軟件26動態(tài)白盒測試基本測試內(nèi)容：1、直接測試底層功能、過程、子程序和庫。2、以完整程序方式從頂層測試軟件，然后根據(jù)軟件運行了解和調(diào)整測試案例。3、從軟件獲得讀取變量和狀態(tài)信息的訪問權(quán)，以便確定測試與預(yù)期結(jié)果是否相等。4、估算執(zhí)行測試時命中的代碼量和具體代碼，然后調(diào)整測試?！盾浖こ獭方虒W動態(tài)白盒測試基本測試內(nèi)容：《軟件工程》教學27動態(tài)白盒測試和調(diào)試兩者不能混為一談，雖然會有交叉，調(diào)試是程序員做的，目的是修復問題。測試是為了找到缺陷。測試員可能要使用代碼級調(diào)試器單步執(zhí)行，觀察變量，設(shè)置斷點等。對于要求合法性檢查的獨立代碼模塊，還要編寫測試程序進行測試?！盾浖こ獭方虒W動態(tài)白盒測試和調(diào)試兩者不能混為一談，雖然會有交叉，調(diào)試是程序28黑盒與白盒黑盒與白盒進行白盒測試之前，要根據(jù)說明書建立黑盒測試案例，這種方法可以真正理解測試用途。否則會偏向模塊的工作方式，程序員的說明也許包含錯誤，所以測試案例可能出現(xiàn)問題?！盾浖こ獭方虒W黑盒與白盒黑盒與白盒進行白盒測試之前，要根據(jù)說明書建立黑盒測29數(shù)據(jù)范圍白盒測試合理的方法是把軟件分成數(shù)據(jù)和狀態(tài)（或者程序流程）。同時可以把白盒信息映射到已經(jīng)寫完的黑盒案例中。首先考慮數(shù)據(jù)：包括所有變量、常量、數(shù)組、數(shù)據(jù)結(jié)構(gòu)、鍵盤鼠標輸入、文件、屏幕輸入輸出。以及調(diào)制解調(diào)器、網(wǎng)絡(luò)等其他設(shè)備的輸入/輸出。數(shù)據(jù)可以分成如下類型：數(shù)據(jù)流。觀察數(shù)據(jù)在各個模塊甚至整個程序中的各種狀態(tài)值。次邊界。尋找次邊界條件。比如2的乘方。公式和等式。比如被0除問題。錯誤強制。有的錯無條件不好模擬，需要制造錯誤。但是不要制造實際無法出現(xiàn)的錯誤。《軟件工程》教學數(shù)據(jù)范圍白盒測試合理的方法是把軟件分成數(shù)據(jù)和狀態(tài)（或者程序流30代碼覆蓋為了全面，必須測試程序的狀態(tài)及其中的程序流程，設(shè)法進入和退出每一個模塊，執(zhí)行每一行代碼，追蹤每一條邏輯和決策分支。最簡單的方法是利用編譯環(huán)境單步執(zhí)行。大多數(shù)程序要用專門的代碼范圍分析器。需要注意的是，全部語句都執(zhí)行一遍，不等于走遍了軟件的所有路徑。所以需要分支覆蓋。分支覆蓋也不完全，還要考慮條件范圍問題。如果測試了所有可能的條件，達到了分支覆蓋，順便達到了語句覆蓋。《軟件工程》教學代碼覆蓋為了全面，必須測試程序的狀態(tài)及其中的程序流程，設(shè)法進31配置測試因為無法保證用戶的設(shè)備都符合通用的標準，所以需要把軟件放在用戶使用比較廣泛的硬件上進行測試。測試要點：確定需要測試的硬件類型。明確硬件標準。確定可能的硬件屬性，模式和選項。分離配置缺陷。等價分配。只測試各種硬件不交叉的部分?！盾浖こ獭方虒W配置測試因為無法保證用戶的設(shè)備都符合通用的標準，所以需要把軟32文檔測試軟件測試員不僅要測試軟件同時需要測試文檔，因為他要負責整個軟件產(chǎn)品的各個部分的質(zhì)量?！盾浖こ獭方虒W文檔測試軟件測試員不僅要測試軟件同時需要測試文檔，因為他要負33文檔的類型包裝文字和圖形。市場宣傳資料、廣告和其他資料。授權(quán)/注冊登記表。EULA即最終用戶許可協(xié)議，一般要求用戶不經(jīng)同意不可以復制軟件，如果受到軟件缺陷的損害，不得向生產(chǎn)廠家起訴。標簽和不干膠。安裝和設(shè)置指導。用戶手冊。聯(lián)機幫助。指南，向?qū)Ш虲BT(計算機基礎(chǔ)訓練)。樣例、示例和模板。錯誤提示信息。《軟件工程》教學文檔的類型包裝文字和圖形。《軟件工程》教學34文檔測試的重要性如果安裝指導有問題，不正確的錯誤提示信息把用戶引入歧途，他們會認為這是軟件缺陷。文檔和代碼對于用戶來說是一樣的?！盾浖こ獭方虒W文檔測試的重要性如果安裝指導有問題，不正確的錯誤提示信息把用35文檔測試問題類型文檔面對的聽眾級別是否合適。術(shù)語是否適用于聽眾，是否用法一致，所有術(shù)語是否可以被正確索引。內(nèi)容和主題是否有遺漏或者多余。材料深度是否合適。所有信息是否準確。產(chǎn)品說明是否過時，技術(shù)支持網(wǎng)站鏈接和電話是否準確。逐步執(zhí)行。象用戶一樣來按步驟使用，看看是否遺漏某些說明。圖表和屏幕抓圖。來源和表現(xiàn)是否正確。樣例和示例。向客戶一樣使用樣例，如果是代碼就要執(zhí)行。樣例如果不能運行給客戶印象特別不好。拼寫和檢查?！盾浖こ獭方虒W文檔測試問題類型文檔面對的聽眾級別是否合適?！盾?6其他測試以下測試內(nèi)容被省略：兼容性測試本地化測試易用性測試網(wǎng)站測試自動測試及測試工具《軟件工程》教學其他測試以下測試內(nèi)容被省略：《軟件工程》教學37借助他人測試不同人的角度不同，可以有效打破殺蟲劑現(xiàn)象。請產(chǎn)品支持或者客戶服務(wù)幫助測試是很有效的一種方法?！盾浖こ獭方虒W借助他人測試不同人的角度不同，可以有效打破殺蟲劑現(xiàn)象。38測試共享如果幾個測試員來測試，常用方法是在一定時間內(nèi)簡單互換測試任務(wù)?！盾浖こ獭方虒W測試共享如果幾個測試員來測試，常用方法是在一定時間內(nèi)簡單互換39測試轟炸測試人員同時停下工作，選擇軟件的某一塊區(qū)域，集中進行測試。稱為測試轟炸?！盾浖こ獭方虒W測試轟炸測試人員同時停下工作，選擇軟件的某一塊區(qū)域，集中進行40Beta測試他是一種外部測試方法。該過程中，軟件分發(fā)給選定的潛在用戶，他們在實際環(huán)境中使用軟件。Beta測試需要考慮的幾個問題：1、誰是Beta測試者Beta測試有不同的目標，所以必須了解測試者的類型。比如測試人員想要找出測試中殘存的易用性錯誤，如果Beta測試者是技術(shù)人員的話，將更關(guān)心底層的技術(shù)，對于易用性不是很關(guān)心，這樣測試效果將不是很好?！盾浖こ獭方虒WBeta測試他是一種外部測試方法。該過程中，軟件分發(fā)給選定412、如何知道Beta測試者用過軟件1000個Beta測試者拿到Beta一個月后，沒有任何錯誤報告，是否可以認為沒有缺陷還是用戶沒有收到軟件，還是過些時間才開始測試。測試執(zhí)行者需要追問參加者，保證他們在使用軟件并符合計劃的目標?！盾浖こ獭方虒W2、如何知道Beta測試者用過軟件《軟件工程》教學423、Beta測試的優(yōu)缺點Beta測試可以成為尋找配置和兼容性軟件缺陷的好方法。Beta測試對易用性測試非常有好處。Beta測試對于尋找其他軟件缺陷方面出人意料的差?！盾浖こ獭方虒W3、Beta測試的優(yōu)缺點《軟件工程》教學43第三方測試提交給其他公司進行轉(zhuǎn)包測試，看上去比較麻煩，費用也高，但是如果做的好，可能成為共享測試的有效途徑?！盾浖こ獭方虒W第三方測試提交給其他公司進行轉(zhuǎn)包測試，看上去比較麻煩，費用也44計劃測試工作測試過程不可能在真空里工作，程序員編寫代碼，不說明它的功能，如何工作，何時完成，執(zhí)行測試任務(wù)就難了。測試員之間不交流測試的對象，需要什么資源，進度如何安排，項目很難成功。計劃測試工作主要目的是交流軟件測試小組的意圖、期望以及對將要執(zhí)行的任務(wù)的理解。而編制的測試計劃通常成為空架子，以后不會有人看。所以計劃工作的目標應(yīng)該從建立文檔轉(zhuǎn)移到計劃建立過程。《軟件工程》教學計劃測試工作測試過程不可能在真空里工作，程序員編寫代碼，不說451、測試計劃主題由于測試一般都有模板，所以很容易作出計劃文檔，然而如果只有文檔，當產(chǎn)品小組的人沒人知道測試員在做什么，或者為什么做的時候，測試的弊端就出來了?！盾浖こ獭方虒W1、測試計劃主題《軟件工程》教學461.1明確測試目標測試計劃過程和軟件測試計劃的目的是什么？程序員和技術(shù)作者及管理部門知道嗎？測試的產(chǎn)品是什么？是一個完全重寫一個產(chǎn)品還是僅僅維護和升級，是獨立程序還是很多小程序的組合？是自行開發(fā)的還是外包出去的，它的到底是什么東西？產(chǎn)品質(zhì)量和可靠性目標是什么？測試計劃過程的結(jié)果必須是產(chǎn)品質(zhì)量和可靠性目標的清晰、簡潔和一致通過的定義?！盾浖こ獭方虒W1.1明確測試目標《軟件工程》教學472.測試的組織工作測試計劃中應(yīng)該包括項目中所有主要人員的清單和聯(lián)系方式。同時，文檔存放的位置，測試工具從那里得到，使用什么硬件如果必要都需要指出。這些內(nèi)容最好類似于“測試新手問題指南”。通常是新手負責的絕好部分，找到所有問題答案，把發(fā)現(xiàn)記錄下來。《軟件工程》教學2.測試的組織工作《軟件工程》教學483.明確定義常用一些定義需要明確：版本生成：測試計劃應(yīng)該定義構(gòu)建版本的頻率（每天或每周等等）以及預(yù)定義的質(zhì)量等級。版本發(fā)布文檔：程序員提供的聲明新特性、不同特性、修復問題和準備測試的內(nèi)容。Alpha版：對少數(shù)主要客戶和市場進行數(shù)量有限的分發(fā)，用于演示的目的軟件版本。使用Alpha版的所有人應(yīng)該了解確切的內(nèi)容和質(zhì)量等級。Beta版：向潛在用戶廣泛分發(fā)的正式版本。說明書完成：說明書預(yù)計完成并且不再修改的計劃安排。實際工作中，這個期限是無法實現(xiàn)的，但是需要確定下來，以后只會進行小的改動。軟件缺陷會議：由測試人員、項目管理員、開發(fā)管理員和產(chǎn)品支持組成的團隊，審查缺陷，決定那些需要修改，那些不需要?！盾浖こ獭方虒W3.明確定義《軟件工程》教學494.需要和不需要測試的部分實際工作中有不需要測試部分存在的可能性。5.定義測試階段明確測試進入和退出的規(guī)則。計劃中應(yīng)該確定每個預(yù)定的階段。否則就會成為無頭緒的單個工作?！盾浖こ獭方虒W4.需要和不需要測試的部分《軟件工程》教學506.決定測試策略使用白盒還是黑盒，如果需要結(jié)合在一起，如何做。是否使用工具，是否需要提交給其他專業(yè)公司測試。這項工作需要資深測試員來做?！盾浖こ獭方虒W6.決定測試策略《軟件工程》教學517.資源要求人員設(shè)備辦公空間軟件是否或如何選擇測試公司其他供應(yīng)：軟盤，電話，參考書，培訓資料等。《軟件工程》教學7.資源要求《軟件工程》教學528.測試人員的任務(wù)分配9.測試進度如果一個特性雖然看起來很容易設(shè)計和完成，但是如果需要很多時間來測試，就要考慮是否要真正實現(xiàn)。另外測試工作量在軟家開發(fā)過程中是不平均分配的，比如從測試說明書和代碼審查開始，測試的任務(wù)，人員和工作量不斷增長，到產(chǎn)品發(fā)布之間會形成短暫的高峰。結(jié)果是不斷受到先前事件影響，如果前提條件拖延，那么應(yīng)該壓縮測試時間還是把項目推遲，這稱為進度危機。為了避免這種危機，建議使用進入退出標志，使用相對進度：例如測試計劃任務(wù)在說明書完成之后7天。期限4周。測試案例開始于測試計劃完成需要12周。第一階段測試開始于代碼完成可測試版本，期限6周。第二階段測試開始于Beta版完成，期限6周。第三階段測試開始于軟件發(fā)布版本完成，期限4周。《軟件工程》教學8.測試人員的任務(wù)分配《軟件工程》教學5310.測試案例計劃決定使用什么方法編寫測試案例，那里保存，如何使用和維護。11.缺陷報告決定如何記錄和跟蹤缺陷。采用什么工具來跟蹤缺陷。《軟件工程》教學10.測試案例《軟件工程》教學5412.頻度和統(tǒng)計測試計劃中應(yīng)該明確收集那些信息，做什么決定，誰來收集，例如：項目期間每天發(fā)現(xiàn)的軟件缺陷總數(shù)。仍然需要修復的軟件缺陷清單。根據(jù)嚴重程度對當前軟件缺陷評級。每個測試人員找出軟件缺陷的總數(shù)。從每個特性或者區(qū)域發(fā)現(xiàn)的軟件缺陷數(shù)目?！盾浖こ獭方虒W12.頻度和統(tǒng)計《軟件工程》教學5513.風險和問題明確指出項目的潛在問題或者風險區(qū)域，對測試工作的影響之處?！盾浖こ獭方虒W13.風險和問題《軟件工程》教學56測試案例的編寫和跟蹤測試案例計劃的目標測試員拿到測試計劃馬上坐下來想出測試案例并開始計算是不正確的，正如程序員馬上拿到產(chǎn)品說明書馬上編碼一樣。需要仔細計劃測試案例的原因：組織性：正確計劃案例，可以組織好測試案例并且使全部測試員和其他成員有效審查和使用。重復性：項目期間需要多次執(zhí)行同樣測試，需要有個計劃。跟蹤：可以回答計劃執(zhí)行多少個案例，最終版本需要多少案例，多少個通過，有被忽略等問題。測試證實：高風險行業(yè)，測試小組必須正式確實執(zhí)行了某些測試，發(fā)布忽略某些測試案例的軟件實際是危險和不合法的?！盾浖こ獭方虒W測試案例的編寫和跟蹤測試案例計劃的目標《軟件工程》教學572.測試案例的要點ANSI/IEEE829標準：標識符：測試設(shè)計過程和測試程序說明引用的唯一標識符。測試項：被測試的詳細特性、代碼模塊等。如“加法運算的上限溢出錯誤”。輸入說明：列舉送到軟件執(zhí)行測試案例的所有輸入內(nèi)容或者條件。輸出說明：描述進行測試案例的預(yù)期結(jié)果。環(huán)境要求：指執(zhí)行測試必須達到的軟、硬件、測試工具、實用工具、人員等要求。特殊要求：描述執(zhí)行測試必須做到的特殊要求。案例之間的依賴性：如果一個測試案例依賴于其他案例，應(yīng)該在此注明。實際上只能把上面的參考資料作為規(guī)范，而不是標準。大多時候使用簡便方法。需要發(fā)揮創(chuàng)造力，使用最有效的方法，使用簡單列表，大綱甚至狀態(tài)圖或者數(shù)據(jù)流程圖之類的圖表。設(shè)法與他人交流測試案例，并且使用最有效的方法，但不要偏離編寫測試案例的目的。《軟件工程》教學2.測試案例的要點《軟件工程》教學583.測試腳本說明該文檔定義了執(zhí)行測試案例的每一步步驟：標識符：把測試過程與相關(guān)測試案例和測試設(shè)計捆綁在一起的唯一表示符。目的：程序的目的及要執(zhí)行的測試案例的引用信息。特殊要求：執(zhí)行程序需要的其他程序、技術(shù)或者特殊設(shè)備。程序步驟：執(zhí)行測試的詳細步驟。日志：指出用什么方式、方法記錄結(jié)果和現(xiàn)象。設(shè)置：說明如何準備測試。啟動：說明啟動測試的步驟?！盾浖こ獭方虒W3.測試腳本說明《軟件工程》教學59程序：描述用于運行測試的步驟。衡量標準：描述如何判斷標準－例如用秒表或者憑眼睛判斷。關(guān)閉：說明由于意外原因推遲測試的步驟。中止：描述測試正常停止的步驟。重置：說明如何把環(huán)境恢復到測試前的狀態(tài)。偶然事件：說明如何處理計劃之外的情況。對于測試過程只說：“嘗試執(zhí)行所有測試案例并回報發(fā)現(xiàn)的問題等”是不夠的。應(yīng)該使用詳細的程序說明，要測試什么，如何測試都是一目了然的?！盾浖こ獭方虒W程序：描述用于運行測試的步驟?！盾浖こ獭方虒W604.細節(jié)和真實“適可而止”特別適用于測試案例計劃。通常不可能需要按照最細致的程度編寫測試案例。無比詳盡的測試案例說明減少了隨意性，使測試很好重復，使無經(jīng)驗的測試員按照預(yù)定想法執(zhí)行測試。缺點是，編寫如此細致的測試案例說明需要化費很多時間和精力，增加升級難度。由于細節(jié)繁多，阻礙了測試工作，造成執(zhí)行測試時間變長。開始編寫測試案例時，最好的機會是采用當前項目的標準。《軟件工程》教學4.細節(jié)和真實《軟件工程》教學615.測試案例的組織和跟蹤一般應(yīng)該考慮下面的問題：計劃執(zhí)行多少個測試案例？需要執(zhí)行多少時間？能否挑選出測試相關(guān)案例組測試某些特性或者軟件部分？執(zhí)行測試案例時，能否記錄那一個通過，那一個失敗。失敗的案例中，那些在上次執(zhí)行時也失敗了。上次執(zhí)行測試案例通過的百分比是多少?！盾浖こ獭方虒W5.測試案例的組織和跟蹤《軟件工程》教學626.跟蹤方式用腦子記是最不可取的。書面文檔。使用紙和筆填寫的含檢查清單的表格和框圖，提供了包含程序員簽字的書面檢查清單是法庭上證明測試執(zhí)行過程的極佳證據(jù)。使用電子表格是很流行的方法。自定義數(shù)據(jù)庫也是非常好的方法?！盾浖こ獭方虒W6.跟蹤方式《軟件工程》教學63評價成效利用從缺陷跟蹤工具庫得到的數(shù)據(jù)可以回答類似下面的問題：正在測試的軟件各個區(qū)域缺陷分布情況。某個測試員已經(jīng)關(guān)閉的缺陷數(shù)。某個時間段找出的缺陷數(shù)。所有優(yōu)先級為“嚴重級”的缺陷清單。軟件是否可以按正常發(fā)布期限發(fā)布?！盾浖こ獭方虒W評價成效利用從缺陷跟蹤工具庫得到的數(shù)據(jù)可以回答類似下面的問題64日常測試中使用的指數(shù)一般可以給出下面這些問題的答案：交給我來關(guān)閉的已解決軟件缺陷的ID是什么？該項目輸入了多少軟件缺陷？針對用戶界面輸入那些軟件缺陷以不修復形式解決？發(fā)現(xiàn)的軟件中有多少嚴重級為1或者嚴重性為2的？全部缺陷中修復了多少？推遲了多少？重復了多少。各種統(tǒng)計指數(shù)分析：測序員發(fā)現(xiàn)的缺陷的優(yōu)先級比重餅圖。測試員發(fā)現(xiàn)的缺陷如何處理的直方圖。（修復、未報告、重新提交、不是問題、推遲修復）?！盾浖こ獭方虒W日常測試中使用的指數(shù)《軟件工程》教學652.常用項目級指數(shù)顯示軟件每個主要功能區(qū)發(fā)現(xiàn)軟件缺陷數(shù)目的項目級餅圖。發(fā)現(xiàn)缺陷的時序圖（按每天發(fā)現(xiàn)缺陷情況）可以發(fā)現(xiàn)很多問題。上面的圖加上累加軟件缺陷趨勢圖。隨時間推遲的打開，解決和關(guān)閉的軟件缺陷圖。該圖表一般使用彩色表示：紅色代表打開的軟件缺陷，黃色代表解決的軟件缺陷，綠色代表關(guān)閉的軟件缺陷?！盾浖こ獭方虒W2.常用項目級指數(shù)《軟件工程》教學66軟件質(zhì)量評判制作高質(zhì)量產(chǎn)品的費用軟件缺陷發(fā)現(xiàn)的越晚，處理費用越高。2.軟件測試找出軟件缺陷，有效地描述他們，通知相應(yīng)的人，并跟蹤軟件缺陷直到解決?！盾浖こ獭方虒W軟件質(zhì)量評判制作高質(zhì)量產(chǎn)品的費用《軟件工程》教學673.質(zhì)量評判測試無法保證產(chǎn)品質(zhì)量。QA團隊是對項目進行近似完全地控制，建立標準和方法論，有條理地仔細監(jiān)視和評價軟件開發(fā)過程，對發(fā)現(xiàn)地軟件缺陷提出解決建議，執(zhí)行某些測試（或者忽略），擁有決定產(chǎn)品何時發(fā)布的權(quán)。讓一個管理員力爭實現(xiàn)“無缺陷”的目標，而不是使軟件如期發(fā)布或者低于預(yù)算。軟件QA的目標是防范軟件缺陷，在產(chǎn)品說明書、設(shè)計文檔和代碼上執(zhí)行靜態(tài)測試，就算一種軟件QA，因為這樣防止了軟件缺陷出現(xiàn)?！盾浖こ獭方虒W3.質(zhì)量評判《軟件工程》教學684.測試人員的其他任務(wù)軟件測試團隊進行配置管理或者構(gòu)造軟件等是不正常的。這樣作有兩個問題：占用了應(yīng)該用于測試產(chǎn)品的資源測試團隊的最終目的是破而不是立，承認軟件的構(gòu)造過程形成利益沖突。最好讓程序員或者獨立小組構(gòu)造軟件。測試應(yīng)該專注于尋找軟件缺陷?！盾浖こ獭方虒W4.測試人員的其他任務(wù)《軟件工程》教學695.測試管理與組織結(jié)構(gòu)要點小型開發(fā)小組（小于10人）常用組織結(jié)構(gòu)：測試團隊向管理員報告，他同時管理程序員的工作。這種組織形式的缺陷在于編寫代碼的人和尋找缺陷的人向同一個報告，可能引起利益沖突。開發(fā)管理員的目標是促使其小組開發(fā)軟件，測試員報告軟件缺陷只會妨礙這個過程。如果管理員為測試員提供很多資源和經(jīng)費，他們會找出更多缺陷，但他們找到的缺陷越多，就越妨礙管理員制作軟件的目標。但是如果開發(fā)管理員的經(jīng)驗很豐富，認識到其目標不僅是制作軟件，同時要制作高質(zhì)量軟件，這個結(jié)構(gòu)也可以運行的很好。管理員會一視同仁，有利于相互交流，管理層次也較少。《軟件工程》教學5.測試管理與組織結(jié)構(gòu)要點《軟件工程》教學70另一種組織結(jié)構(gòu)：測試團隊和開發(fā)團隊都向項目管理員報告。測試團隊一般有自己的負責人和管理員，其利益和注意力集中在測試小組及其工作上，這種獨立性在對軟件質(zhì)量做重大決定時極有好處。測試小組的意見與產(chǎn)品制作者的意見同等重要。然而，該組織結(jié)構(gòu)的缺點是項目管理員做最終決定。在高風險或者任務(wù)要求嚴格的系統(tǒng)開發(fā)中，由更高等級擁有質(zhì)量意見最終決定權(quán)是有益的?！盾浖こ獭方虒W另一種組織結(jié)構(gòu)：《軟件工程》教學71最后一種組織結(jié)構(gòu)：該組織中，負責軟件質(zhì)量的小組直接向高級管理員報告，相對獨立，擁有與各項目同等的項目等級。該團隊的獨立性允許他們建立標準和規(guī)范，評價結(jié)果，采取跨越多個項目的處理措施。關(guān)于質(zhì)量優(yōu)略的信息可以直達最高層。這種授權(quán)，并不意味著他們可以在軟件項目和用戶不要求的前提下，建立不合理和難以實現(xiàn)的質(zhì)量目標。這個獨立的質(zhì)量組織必須設(shè)法面對所有的項目，利用發(fā)布軟件的經(jīng)驗穩(wěn)定盲目追求質(zhì)量的熱情。同時必須保持程序員和其他小組成員的緊密合作關(guān)系。隨著交流路線的分散，這一點越來越難以控制?！盾浖こ獭方虒W最后一種組織結(jié)構(gòu)：《軟件工程》教學726.能力成熟度模型（CMM）美國國防部指導，由軟件開發(fā)委員會和軟件工程學會(SEI)和卡內(nèi)基梅?。–arnegieMello）大學共同開發(fā)。5級CMM成熟度：簡述和測試有關(guān)的方面。初步。測試與其他活動混在一起?？芍貜图墶；卷椖抗芾泶媪隧椖抠M用，進度等跟蹤，以前的項目經(jīng)驗可以被應(yīng)用。測試方面，使用了基本軟件測試行為，例如測試計劃和測試案例。明確。通用管理和工程活動被標準化和文檔化。測試開始之前，審查和證實測試文檔和計劃。測試與開發(fā)相互獨立。測試結(jié)果用于確定軟件發(fā)布時間?？煽亍＝M織過程處于統(tǒng)計控制之下。產(chǎn)品質(zhì)量事先由數(shù)量決定，軟件達到目標之前不可以發(fā)布。開發(fā)過程中收集開發(fā)和測試資料，不斷進行調(diào)整，使項目按計劃進行。不斷優(yōu)化。嘗試新的技術(shù)和處理過程，評價結(jié)果，不斷變革以期望達到質(zhì)量更高的等級。《軟件工程》教學6.能力成熟度模型（CMM）《軟件工程》教學737.ISO9000國際標準化組織（ISO）為所有制造業(yè)設(shè)立標準。他的目標在于開發(fā)過程，而不是產(chǎn)品。它關(guān)心的是進行工作的組織方式，而不是工作成果。質(zhì)量是相對的，主觀的。公司的目標應(yīng)該是達到滿足客戶要求的質(zhì)量等級。利用質(zhì)量開發(fā)過程可望實現(xiàn)該目標。ISO9000只決定過程的要求是什么，而不管如何達到。ISO9000針對軟件軟件的部分是ISO9001和ISO9000-3。9001負責處理設(shè)計、開發(fā)生產(chǎn)、安裝和服務(wù)產(chǎn)品。ISO9000-3負責處理開發(fā)、供應(yīng)安裝和維護計算機軟件。《軟件工程》教學7.ISO9000《軟件工程》教學74ISO9000-3的要求如下：開發(fā)詳細的質(zhì)量計劃和程序控制配置管理、產(chǎn)品驗證和合法性檢查（測試），不規(guī)范行為（軟件缺陷）和修正措施（修復）。準備和接受軟件開發(fā)證實，包括項目定義、產(chǎn)品目標清單、項目進度、產(chǎn)品說明書、如何組織項目的描述、風險和假設(shè)的討論，以及控制策略。使用客戶容易理解、測試時容易進行合法性檢查的用于來表述說明書。計劃、開發(fā)、編制和實施軟件設(shè)計審查程序。開發(fā)控制軟件設(shè)計隨著產(chǎn)品的生命周期中而變化的程序。開發(fā)和編制軟件測試計劃?！盾浖こ獭方虒WISO9000-3的要求如下：《軟件工程》教學75開發(fā)檢測軟件是否滿足客戶要求的方法。實施軟件合法性檢查和驗收測試。維護測試結(jié)果的記錄?？刂普{(diào)查研究和解決軟件缺陷的方式。證明產(chǎn)品在發(fā)布之前已經(jīng)就緒。開發(fā)控制產(chǎn)品發(fā)布過程的程序。明確指出和規(guī)定應(yīng)該收集何種質(zhì)量信息。使用統(tǒng)計技術(shù)分析軟件開發(fā)過程。使用統(tǒng)計技術(shù)評估產(chǎn)品質(zhì)量?！盾浖こ獭方虒W開發(fā)檢測軟件是否滿足客戶要求的方法。《軟件工程76Q&A《軟件工程》教學Q&A《軟件工程》教學77演講完畢，謝謝觀看！演講完畢，謝謝觀看！78測試員入門培訓唐滔2009.10.10《軟件工程》教學測試員入門培訓唐滔《軟件工程》教學79本文編寫目的這是為培訓專業(yè)測試人員參加測試工作，而編寫的包含測試基礎(chǔ)知識的入門培訓教材?！盾浖こ獭方虒W本文編寫目的《軟件工程》教學80讀者范圍將來參加測試工作的測試人員或者將來參加開發(fā)的程序員?！盾浖こ獭方虒W讀者范圍《軟件工程》教學81軟件缺陷軟件中含有符合下面5條規(guī)則之一的問題稱為軟件缺陷：軟件未達到產(chǎn)品說明書標明的功能。軟件出現(xiàn)產(chǎn)品說明書指明不會出現(xiàn)的錯誤。軟件功能超出產(chǎn)品說明書指明的范圍。軟件未達到產(chǎn)品說明書未指出但應(yīng)達到的目標。軟件測試人員或用戶認為軟件難以理解，不易使用，運行速度緩慢等問題?！盾浖こ獭方虒W軟件缺陷軟件中含有符合下面5條規(guī)則之一的問題稱為軟件缺陷82測試案例測試用例的別名?！盾浖こ獭方虒W測試案例《軟件工程》教學83黑盒測試指測試人員通過各種輸入和觀察軟件的各種輸出結(jié)果來發(fā)現(xiàn)軟件的缺陷，而不關(guān)心程序具體如何實現(xiàn)的一種測試方法?！盾浖こ獭方虒W黑盒測試《軟件工程》教學84靜態(tài)測試指測試不運行的部分，例如測試產(chǎn)品說明書，對此進行檢查和審閱?！盾浖こ獭方虒W靜態(tài)測試《軟件工程》教學85靜態(tài)白盒測試指在不執(zhí)行的條件下有條理地仔細審查軟件設(shè)計，體系結(jié)構(gòu)和代碼，從而找出軟件缺陷的過程。有時稱作結(jié)構(gòu)分析?！盾浖こ獭方虒W靜態(tài)白盒測試《軟件工程》教學86動態(tài)測試通過運行和使用軟件進行測試?！盾浖こ獭方虒W動態(tài)測試通過運行和使用軟件進行測試。《軟件工程》教學87探索測試通常用于沒有產(chǎn)品說明書的測試，這需要把軟件當作產(chǎn)品說明書來看待，分步驟逐項探索軟件特性，記錄軟件執(zhí)行情況，詳細描述功能，綜合利用靜態(tài)和動態(tài)技術(shù)來進行測試?！盾浖こ獭方虒W探索測試通常用于沒有產(chǎn)品說明書的測試，這需要把軟件當作產(chǎn)品說88等價區(qū)間指測試相同目標或者暴露相同軟件缺陷的一組測試用例?！盾浖こ獭方虒W等價區(qū)間指測試相同目標或者暴露相同軟件缺陷的一組測試用例。89測試設(shè)計提煉測試方法，明確指出設(shè)計包含的特性和相關(guān)測試。如果要求完成測試還明確指出測試案例和測試程序，指定特性通過/失敗的規(guī)則。《軟件工程》教學測試設(shè)計提煉測試方法，明確指出設(shè)計包含的特性和相關(guān)測試。如果90軟件QAQA=QualityAssessment質(zhì)量評價。防止軟件缺陷稱為軟件QA?！盾浖こ獭方虒W軟件QAQA=QualityAssessment質(zhì)量評91TQM或者TQC原理TQM(全面質(zhì)量管理)或者TQC(全面質(zhì)量控制)。其原理是，用集中的質(zhì)量評判團隊來負責質(zhì)量是不實際的，因為工作的人不負責質(zhì)量，所以他們不會設(shè)法實現(xiàn)質(zhì)量評判目的。要想制造高質(zhì)量產(chǎn)品，需要創(chuàng)立從管理開始自上而下的質(zhì)量意識，使全體成員共同承擔質(zhì)量責任?！盾浖こ獭方虒WTQM或者TQC原理TQM(全面質(zhì)量管理)或者TQC(全92SQC軟件質(zhì)量控制(SQC)是測試團隊很常用的名稱。該名稱來源于制造行業(yè)，其中QC檢驗員對生產(chǎn)線上的產(chǎn)品進行采樣、檢測，如果測試失敗，他有權(quán)停掉生產(chǎn)線或者整個工廠。測試團隊很少有這種授權(quán)。軟件QC團隊也是如此。《軟件工程》教學SQC軟件質(zhì)量控制(SQC)是測試團隊很常用的名稱。該名稱來93Murphy法則永遠不會有足夠的時間把事情做好，但是總有時間返工。軟件開發(fā)小組需要遵循一個過程，花費一些時間，變得有條理，一開始就設(shè)法作對?！盾浖こ獭方虒WMurphy法則永遠不會有足夠的時間把事情做好，但是總有時94測試人員的目標找出軟件缺陷，盡可能早一些，并保證其得到修復?！盾浖こ獭方虒W測試人員的目標找出軟件缺陷，盡可能早一些，并保證其得到修復。95測試工作過程要點利用組織良好的測試計劃、測試案例和測試報告正確交流和制定來完成的測試工作，是測試員達到目標的保障?！盾浖こ獭方虒W測試工作過程要點利用組織良好的測試計劃、測試案例和測試報告正96檢查代碼靜態(tài)白盒測試進行靜態(tài)白盒測試的首要原因是盡早發(fā)現(xiàn)軟件缺陷，以找出動態(tài)黑盒測試難以揭示或遇到的軟件缺陷。獨立審查代碼的人越多越好，特別是在開發(fā)過程初期從底層進行。另外可以為黑盒測試人員提供思路，他們不必了解代碼的細節(jié)，但是根據(jù)審查備注，可以確定似乎有問題或者存在軟件缺陷的特征范圍?！盾浖こ獭方虒W檢查代碼靜態(tài)白盒測試《軟件工程》教學97開發(fā)小組沒有專人負責白盒測試，一般由程序員組織和執(zhí)行審查人員，軟件測試人員被當作獨立的觀察者。也有測試人員是該任務(wù)執(zhí)行人，要求編寫代碼的程序員和其他同事幫助審查。靜態(tài)白盒測試常見問題是不能善始善終。很多小組認為費用太高，沒有產(chǎn)出。這是不正確的，很多公司已經(jīng)招聘和培訓程序員和測試員進行白盒測試了。《軟件工程》教學開發(fā)小組沒有專人負責白盒測試，一般由程序員組織和執(zhí)行審查人員98正式審查正式審查有四個要素：確定問題。審查的目標是找出軟件問題，包括出錯項目和遺漏項目。遵守規(guī)則。審查需要固定的規(guī)則，如審查代碼的行數(shù)，花的時間，那些內(nèi)容需要備注等。準備。每個合作者需要知道自己的職責，很多問題是在準備期間發(fā)現(xiàn)的。編寫報告。必須有書面報告，使報告便于開發(fā)小組使用?！盾浖こ獭方虒W正式審查正式審查有四個要素：《軟件工程》教學99同事審查這是一種最簡單的方法，一般由一兩個程序員和測試員一起進行，為了不至于成為閑聊，需要遵守正式審查的四個要素。這種聚集起來討論代碼也可以找出軟件缺陷?！盾浖こ獭方虒W同事審查這是一種最簡單的方法，一般由一兩個程序員和測試員一起100公開陳述編寫代碼的程序員向5人小組或者其他類似程序員和測試員正式表述。審查人員之中應(yīng)該有一名資深程序員是很重要的?！盾浖こ獭方虒W公開陳述編寫代碼的程序員向5人小組或者其他類似程序員和測101檢驗最正式的審查類型，參與者稱為檢驗員，職責從不同角度包括用戶，測試員和產(chǎn)品支持人員角度來審查產(chǎn)品。有些檢驗員被委任為會議主席和會議記錄，保證檢驗過程遵守規(guī)則及審查。會議后可能檢驗員要碰頭討論發(fā)現(xiàn)的不足，程序員進行修改。最后由主席檢驗修改結(jié)果。檢驗被證明為在設(shè)計文檔和代碼中發(fā)現(xiàn)軟件缺陷最有效的方法?！盾浖こ獭方虒W檢驗最正式的審查類型，參與者稱為檢驗員，職責從不同角度包括用102編碼規(guī)范和標準可以運行并且測試中也表現(xiàn)穩(wěn)定的代碼被稱為有問題，令人不易理解。一般有三個重要原因需要堅持標準和規(guī)范：可靠性。事實證明按照某種標準或者規(guī)范寫的代碼更加可靠?？勺x性/維護性。符合設(shè)備標準的規(guī)范代碼容易閱讀、理解和維護。移植性。如果代碼符合設(shè)備標準，移植將很輕松。《軟件工程》教學編碼規(guī)范和標準可以運行并且測試中也表現(xiàn)穩(wěn)定的代碼被稱為有問題103靜態(tài)白盒測試可能遇到的問題類型數(shù)據(jù)引用出錯數(shù)據(jù)聲明錯計算錯誤比較錯誤控制流程錯誤子程序參數(shù)錯誤輸入/數(shù)出錯誤其他《軟件工程》教學靜態(tài)白盒測試可能遇到的問題類型數(shù)據(jù)引用出錯《軟件104動態(tài)白盒測試基本測試內(nèi)容：1、直接測試底層功能、過程、子程序和庫。2、以完整程序方式從頂層測試軟件，然后根據(jù)軟件運行了解和調(diào)整測試案例。3、從軟件獲得讀取變量和狀態(tài)信息的訪問權(quán)，以便確定測試與預(yù)期結(jié)果是否相等。4、估算執(zhí)行測試時命中的代碼量和具體代碼，然后調(diào)整測試?！盾浖こ獭方虒W動態(tài)白盒測試基本測試內(nèi)容：《軟件工程》教學105動態(tài)白盒測試和調(diào)試兩者不能混為一談，雖然會有交叉，調(diào)試是程序員做的，目的是修復問題。測試是為了找到缺陷。測試員可能要使用代碼級調(diào)試器單步執(zhí)行，觀察變量，設(shè)置斷點等。對于要求合法性檢查的獨立代碼模塊，還要編寫測試程序進行測試。《軟件工程》教學動態(tài)白盒測試和調(diào)試兩者不能混為一談，雖然會有交叉，調(diào)試是程序106黑盒與白盒黑盒與白盒進行白盒測試之前，要根據(jù)說明書建立黑盒測試案例，這種方法可以真正理解測試用途。否則會偏向模塊的工作方式，程序員的說明也許包含錯誤，所以測試案例可能出現(xiàn)問題?！盾浖こ獭方虒W黑盒與白盒黑盒與白盒進行白盒測試之前，要根據(jù)說明書建立黑盒測107數(shù)據(jù)范圍白盒測試合理的方法是把軟件分成數(shù)據(jù)和狀態(tài)（或者程序流程）。同時可以把白盒信息映射到已經(jīng)寫完的黑盒案例中。首先考慮數(shù)據(jù)：包括所有變量、常量、數(shù)組、數(shù)據(jù)結(jié)構(gòu)、鍵盤鼠標輸入、文件、屏幕輸入輸出。以及調(diào)制解調(diào)器、網(wǎng)絡(luò)等其他設(shè)備的輸入/輸出。數(shù)據(jù)可以分成如下類型：數(shù)據(jù)流。觀察數(shù)據(jù)在各個模塊甚至整個程序中的各種狀態(tài)值。次邊界。尋找次邊界條件。比如2的乘方。公式和等式。比如被0除問題。錯誤強制。有的錯無條件不好模擬，需要制造錯誤。但是不要制造實際無法出現(xiàn)的錯誤?！盾浖こ獭方虒W數(shù)據(jù)范圍白盒測試合理的方法是把軟件分成數(shù)據(jù)和狀態(tài)（或者程序流108代碼覆蓋為了全面，必須測試程序的狀態(tài)及其中的程序流程，設(shè)法進入和退出每一個模塊，執(zhí)行每一行代碼，追蹤每一條邏輯和決策分支。最簡單的方法是利用編譯環(huán)境單步執(zhí)行。大多數(shù)程序要用專門的代碼范圍分析器。需要注意的是，全部語句都執(zhí)行一遍，不等于走遍了軟件的所有路徑。所以需要分支覆蓋。分支覆蓋也不完全，還要考慮條件范圍問題。如果測試了所有可能的條件，達到了分支覆蓋，順便達到了語句覆蓋。《軟件工程》教學代碼覆蓋為了全面，必須測試程序的狀態(tài)及其中的程序流程，設(shè)法進109配置測試因為無法保證用戶的設(shè)備都符合通用的標準，所以需要把軟件放在用戶使用比較廣泛的硬件上進行測試。測試要點：確定需要測試的硬件類型。明確硬件標準。確定可能的硬件屬性，模式和選項。分離配置缺陷。等價分配。只測試各種硬件不交叉的部分?！盾浖こ獭方虒W配置測試因為無法保證用戶的設(shè)備都符合通用的標準，所以需要把軟110文檔測試軟件測試員不僅要測試軟件同時需要測試文檔，因為他要負責整個軟件產(chǎn)品的各個部分的質(zhì)量?！盾浖こ獭方虒W文檔測試軟件測試員不僅要測試軟件同時需要測試文檔，因為他要負111文檔的類型包裝文字和圖形。市場宣傳資料、廣告和其他資料。授權(quán)/注冊登記表。EULA即最終用戶許可協(xié)議，一般要求用戶不經(jīng)同意不可以復制軟件，如果受到軟件缺陷的損害，不得向生產(chǎn)廠家起訴。標簽和不干膠。安裝和設(shè)置指導。用戶手冊。聯(lián)機幫助。指南，向?qū)Ш虲BT(計算機基礎(chǔ)訓練)。樣例、示例和模板。錯誤提示信息?！盾浖こ獭方虒W文檔的類型包裝文字和圖形?！盾浖こ獭方虒W112文檔測試的重要性如果安裝指導有問題，不正確的錯誤提示信息把用戶引入歧途，他們會認為這是軟件缺陷。文檔和代碼對于用戶來說是一樣的。《軟件工程》教學文檔測試的重要性如果安裝指導有問題，不正確的錯誤提示信息把用113文檔測試問題類型文檔面對的聽眾級別是否合適。術(shù)語是否適用于聽眾，是否用法一致，所有術(shù)語是否可以被正確索引。內(nèi)容和主題是否有遺漏或者多余。材料深度是否合適。所有信息是否準確。產(chǎn)品說明是否過時，技術(shù)支持網(wǎng)站鏈接和電話是否準確。逐步執(zhí)行。象用戶一樣來按步驟使用，看看是否遺漏某些說明。圖表和屏幕抓圖。來源和表現(xiàn)是否正確。樣例和示例。向客戶一樣使用樣例，如果是代碼就要執(zhí)行。樣例如果不能運行給客戶印象特別不好。拼寫和檢查?！盾浖こ獭方虒W文檔測試問題類型文檔面對的聽眾級別是否合適。《軟114其他測試以下測試內(nèi)容被省略：兼容性測試本地化測試易用性測試網(wǎng)站測試自動測試及測試工具《軟件工程》教學其他測試以下測試內(nèi)容被省略：《軟件工程》教學115借助他人測試不同人的角度不同，可以有效打破殺蟲劑現(xiàn)象。請產(chǎn)品支持或者客戶服務(wù)幫助測試是很有效的一種方法。《軟件工程》教學借助他人測試不同人的角度不同，可以有效打破殺蟲劑現(xiàn)象。116測試共享如果幾個測試員來測試，常用方法是在一定時間內(nèi)簡單互換測試任務(wù)?！盾浖こ獭方虒W測試共享如果幾個測試員來測試，常用方法是在一定時間內(nèi)簡單互換117測試轟炸測試人員同時停下工作，選擇軟件的某一塊區(qū)域，集中進行測試。稱為測試轟炸?！盾浖こ獭方虒W測試轟炸測試人員同時停下工作，選擇軟件的某一塊區(qū)域，集中進行118Beta測試他是一種外部測試方法。該過程中，軟件分發(fā)給選定的潛在用戶，他們在實際環(huán)境中使用軟件。Beta測試需要考慮的幾個問題：1、誰是Beta測試者Beta測試有不同的目標，所以必須了解測試者的類型。比如測試人員想要找出測試中殘存的易用性錯誤，如果Beta測試者是技術(shù)人員的話，將更關(guān)心底層的技術(shù)，對于易用性不是很關(guān)心，這樣測試效果將不是很好?！盾浖こ獭方虒WBeta測試他是一種外部測試方法。該過程中，軟件分發(fā)給選定1192、如何知道Beta測試者用過軟件1000個Beta測試者拿到Beta一個月后，沒有任何錯誤報告，是否可以認為沒有缺陷還是用戶沒有收到軟件，還是過些時間才開始測試。測試執(zhí)行者需要追問參加者，保證他們在使用軟件并符合計劃的目標?！盾浖こ獭方虒W2、如何知道Beta測試者用過軟件《軟件工程》教學1203、Beta測試的優(yōu)缺點Beta測試可以成為尋找配置和兼容性軟件缺陷的好方法。Beta測試對易用性測試非常有好處。Beta測試對于尋找其他軟件缺陷方面出人意料的差?！盾浖こ獭方虒W3、Beta測試的優(yōu)缺點《軟件工程》教學121第三方測試提交給其他公司進行轉(zhuǎn)包測試，看上去比較麻煩，費用也高，但是如果做的好，可能成為共享測試的有效途徑。《軟件工程》教學第三方測試提交給其他公司進行轉(zhuǎn)包測試，看上去比較麻煩，費用也122計劃測試工作測試過程不可能在真空里工作，程序員編寫代碼，不說明它的功能，如何工作，何時完成，執(zhí)行測試任務(wù)就難了。測試員之間不交流測試的對象，需要什么資源，進度如何安排，項目很難成功。計劃測試工作主要目的是交流軟件測試小組的意圖、期望以及對將要執(zhí)行的任務(wù)的理解。而編制的測試計劃通常成為空架子，以后不會有人看。所以計劃工作的目標應(yīng)該從建立文檔轉(zhuǎn)移到計劃建立過程?！盾浖こ獭方虒W計劃測試工作測試過程不可能在真空里工作，程序員編寫代碼，不說1231、測試計劃主題由于測試一般都有模板，所以很容易作出計劃文檔，然而如果只有文檔，當產(chǎn)品小組的人沒人知道測試員在做什么，或者為什么做的時候，測試的弊端就出來了?！盾浖こ獭方虒W1、測試計劃主題《軟件工程》教學1241.1明確測試目標測試計劃過程和軟件測試計劃的目的是什么？程序員和技術(shù)作者及管理部門知道嗎？測試的產(chǎn)品是什么？是一個完全重寫一個產(chǎn)品還是僅僅維護和升級，是獨立程序還是很多小程序的組合？是自行開發(fā)的還是外包出去的，它的到底是什么東西？產(chǎn)品質(zhì)量和可靠性目標是什么？測試計劃過程的結(jié)果必須是產(chǎn)品質(zhì)量和可靠性目標的清晰、簡潔和一致通過的定義?！盾浖こ獭方虒W1.1明確測試目標《軟件工程》教學1252.測試的組織工作測試計劃中應(yīng)該包括項目中所有主要人員的清單和聯(lián)系方式。同時，文檔存放的位置，測試工具從那里得到，使用什么硬件如果必要都需要指出。這些內(nèi)容最好類似于“測試新手問題指南”。通常是新手負責的絕好部分，找到所有問題答案，把發(fā)現(xiàn)記錄下來?！盾浖こ獭方虒W2.測試的組織工作《軟件工程》教學1263.明確定義常用一些定義需要明確：版本生成：測試計劃應(yīng)該定義構(gòu)建版本的頻率（每天或每周等等）以及預(yù)定義的質(zhì)量等級。版本發(fā)布文檔：程序員提供的聲明新特性、不同特性、修復問題和準備測試的內(nèi)容。Alpha版：對少數(shù)主要客戶和市場進行數(shù)量有限的分發(fā)，用于演示的目的軟件版本。使用Alpha版的所有人應(yīng)該了解確切的內(nèi)容和質(zhì)量等級。Beta版：向潛在用戶廣泛分發(fā)的正式版本。說明書完成：說明書預(yù)計完成并且不再修改的計劃安排。實際工作中，這個期限是無法實現(xiàn)的，但是需要確定下來，以后只會進行小的改動。軟件缺陷會議：由測試人員、項目管理員、開發(fā)管理員和產(chǎn)品支持組成的團隊，審查缺陷，決定那些需要修改，那些不需要?！盾浖こ獭方虒W3.明確定義《軟件工程》教學1274.需要和不需要測試的部分實際工作中有不需要測試部分存在的可能性。5.定義測試階段明確測試進入和退出的規(guī)則。計劃中應(yīng)該確定每個預(yù)定的階段。否則就會成為無頭緒的單個工作。《軟件工程》教學4.需要和不需要測試的部分《軟件工程》教學1286.決定測試策略使用白盒還是黑盒，如果需要結(jié)合在一起，如何做。是否使用工具，是否需要提交給其他專業(yè)公司測試。這項工作需要資深測試員來做?！盾浖こ獭方虒W6.決定測試策略《軟件工程》教學1297.資源要求人員設(shè)備辦公空間軟件是否或如何選擇測試公司其他供應(yīng)：軟盤，電話，參考書，培訓資料等?！盾浖こ獭方虒W7.資源要求《軟件工程》教學1308.測試人員的任務(wù)分配9.測試進度如果一個特性雖然看起來很容易設(shè)計和完成，但是如果需要很多時間來測試，就要考慮是否要真正實現(xiàn)。另外測試工作量在軟家開發(fā)過程中是不平均分配的，比如從測試說明書和代碼審查開始，測試的任務(wù)，人員和工作量不斷增長，到產(chǎn)品發(fā)布之間會形成短暫的高峰。結(jié)果是不斷受到先前事件影響，如果前提條件拖延，那么應(yīng)該壓縮測試時間還是把項目推遲，這稱為進度危機。為了避免這種危機，建議使用進入退出標志，使用相對進度：例如測試計劃任務(wù)在說明書完成之后7天。期限4周。測試案例開始于測試計劃完成需要12周。第一階段測試開始于代碼完成可測試版本，期限6周。第二階段測試開始于Beta版完成，期限6周。第三階段測試開始于軟件發(fā)布版本完成，期限4周?！盾浖こ獭方虒W8.測試人員的任務(wù)分配《軟件工程》教學13110.測試案例計劃決定使用什么方法編寫測試案例，那里保存，如何使用和維護。11.缺陷報告決定如何記錄和跟蹤缺陷。采用什么工具來跟蹤缺陷。《軟件工程》教學10.測試案例《軟件工程》教學13212.頻度和統(tǒng)計測試計劃中應(yīng)該明確收集那些信息，做什么決定，誰來收集，例如：項目期間每天發(fā)現(xiàn)的軟件缺陷總數(shù)。仍然需要修復的軟件缺陷清單。根據(jù)嚴重程度對當前軟件缺陷評級。每個測試人員找出軟件缺陷的總數(shù)。從每個特性或者區(qū)域發(fā)現(xiàn)的軟件缺陷數(shù)目?！盾浖こ獭方虒W12.頻度和統(tǒng)計《軟件工程》教學13313.風險和問題明確指出項目的潛在問題或者風險區(qū)域，對測試工作的影響之處?！盾浖こ獭方虒W13.風險和問題《軟件工程》教學134測試案例的編寫和跟蹤測試案例計劃的目標測試員拿到測試計劃馬上坐下來想出測試案例并開始計算是不正確的，正如程序員馬上拿到產(chǎn)品說明書馬上編碼一樣。需要仔細計劃測試案例的原因：組織性：正確計劃案例，可以組織好測試案例并且使全部測試員和其他成員有效審查和使用。重復性：項目期間需要多次執(zhí)行同樣測試，需要有個計劃。跟蹤：可以回答計劃執(zhí)行多少個案例，最終版本需要多少案例，多少個通過，有被忽略等問題。測試證實：高風險行業(yè)，測試小組必須正式確實執(zhí)行了某些測試，發(fā)布忽略某些測試案例的軟件實際是危險和不合法的?！盾浖こ獭方虒W測試案例的編寫和跟蹤測試案例計劃的目標《軟件工程》教學1352.測試案例的要點ANSI/IEEE829標準：標識符：測試設(shè)計過程和測試程序說明引用的唯一標識符。測試項：被測試的詳細特性、代碼模塊等。如“加法運算的上限溢出錯誤”。輸入說明：列舉送到軟件執(zhí)行測試案例的所有輸入內(nèi)容或者條件。輸出說明：描述進行測試案例的預(yù)期結(jié)果。環(huán)境要求：指執(zhí)行測試必須達到的軟、硬件、測試工具、實用工具、人員等要求。特殊要求：描述執(zhí)行測試必須做到的特殊要求。案例之間的依賴性：如果一個測試案例依賴于其他案例，應(yīng)該在此注明。實際上只能把上面的參考資料作為規(guī)范，而不是標準。大多時候使用簡便方法。需要發(fā)揮創(chuàng)造力，使用最有效的方法，使用簡單列表，大綱甚至狀態(tài)圖或者數(shù)據(jù)流程圖之類的圖表。設(shè)法與他人交流測試案例，并且使用最有效的方法，但不要偏離編寫測試案例的目的。《軟件工程》教學2.測試案例的要點《軟件工程》教學1363.測試腳本說明該文檔定義了執(zhí)行測試案例的每一步步驟：標識符：把測試過程與相關(guān)測試案例和測試設(shè)計捆綁在一起的唯一表示符。目的：程序的目的及要執(zhí)行的測試案例的引用信息。特殊要求：執(zhí)行程序需要的其他程序、技術(shù)或者特殊設(shè)備。程序步驟：執(zhí)行測試的詳細步驟。日志：指出用什么方式、方法記錄結(jié)果和現(xiàn)象。設(shè)置：說明如何準備測試。啟動：說明啟動測試的步驟?！盾浖こ獭方虒W3.測試腳本說明《軟件工程》教學137程序：描述用于運行測試的步驟。衡量標準：描述如何判斷標準－例如用秒表或者憑眼睛判斷。關(guān)閉：說明由于意外原因推遲測試的步驟。中止：描述測試正常停止的步驟。重置：說明如何把環(huán)境恢復到測試前的狀態(tài)。偶然事件：說明如何處理計劃之外的情況。對于測試過程只說：“嘗試執(zhí)行所有測試案例并回報發(fā)現(xiàn)的問題等”是不夠的。應(yīng)該使用詳細的程序說明，要測試什么，如何測試都是一目了然的?！盾浖こ獭方虒W程序：描述用于運行測試的步驟?！盾浖こ獭方虒W1384.細節(jié)和真實“適可而止”特別適用于測試案例計劃。通常不可能需要按照最細致的程度編寫測試案例。無比詳盡的測試案例說明減少了隨意性，使測試很好重復，使無經(jīng)驗的測試員按照預(yù)定想法執(zhí)行測試。缺點是，編寫如此細致的測試案例說明需要化費很多時間和精力，增加升級難度。由于細節(jié)繁多，阻礙了測試工作，造成執(zhí)行測試時間變長。開始編寫測試案例時，最好的機會是采用當前項目的標準?！盾浖こ獭方虒W4.細節(jié)和真實《軟件工程》教學1395.測試案例的組織和跟蹤一般應(yīng)該考慮下面的問題：計劃執(zhí)行多少個測試案例？需要執(zhí)行多少時間？能否挑選出測試相關(guān)案例組測試某些特性或者軟件部分？執(zhí)行測試案例時，能否記錄那一個通過，那一個失敗。失敗的案例中，那些在上次執(zhí)行時也失敗了。上次執(zhí)行測試案例通過的百分比是多少?！盾浖こ獭方虒W5.測試案例的組織和跟蹤《軟件工程》教學1406.跟蹤方式用腦子記是最不可取的。書面文檔。使用紙和筆填寫的含檢查清單的表格和框圖，提供了包含程序員簽字的書面檢查清單是法庭上證明測試執(zhí)行過程的極佳證據(jù)。使用電子表格是很流行的方法。自定義數(shù)據(jù)庫也是非常好的方法?！盾浖こ獭方虒W6.跟蹤方式《軟件工程》教學141評價成效利用從缺陷跟蹤工具庫得到的數(shù)據(jù)可以回答類似下面的問題：正在測試的軟件各個區(qū)域缺陷分布情況。某個測試員已經(jīng)關(guān)閉的缺陷數(shù)。某個時間段找出的缺陷數(shù)。所有優(yōu)先級為“嚴重級”的缺陷清單。軟件是否可以按正常發(fā)布期限發(fā)布?！盾浖こ獭方虒W評價成效利用從缺陷跟蹤工具庫得到的數(shù)據(jù)可以回答類似下面的問題142日常測試中使用的指數(shù)一般可以給出下面這些問題的答案：交給我來關(guān)閉的已解決軟件缺陷的ID是什么？該項目輸入了多少軟件缺陷？針對用戶界面輸入那些軟件缺陷以不修復形式解決？發(fā)現(xiàn)的軟件中有多少嚴重級為1或者嚴重性為2的？全部缺陷中修復了多少？推遲了多少？重復了多少。各種統(tǒng)計指數(shù)分析：測序員發(fā)現(xiàn)的缺陷的優(yōu)先級比重餅圖。測試員發(fā)現(xiàn)的缺陷如何處理的直方圖。（修復、未報告、重新提交、不是問題、推遲修復）?！盾浖こ獭方虒W日常測試中使用的指數(shù)《軟件工程》教學1432.常用項目級指數(shù)顯示軟件每個主要功能區(qū)發(fā)現(xiàn)軟件缺陷數(shù)目的項目級餅圖。發(fā)現(xiàn)缺陷的時序圖（按每天發(fā)現(xiàn)缺陷情況）可以發(fā)現(xiàn)很多問題。上面的圖加上累加軟件缺陷趨勢圖。隨時間推遲的打開，解決和關(guān)閉的軟件缺陷圖。該圖表一般使用彩色表示：紅色代表打開的軟件缺陷，黃色代表解決的軟件缺陷，綠色代表關(guān)閉的軟件缺陷?！盾浖こ獭方虒W2.常用項目級指數(shù)《軟件工程》教學144