Ch軟件測試基礎知識課件

1、10月-221軟件測試基礎知識內容概要：序言軟件測試定義軟件測試目的對軟件測試的認識軟件測試理論軟件測試原則軟件測試的分類軟件測試的術語和定義其它10月-221軟件測試基礎知識內容概要：10月-2223.1序言困惑： 軟件測試可以說是一個非常令人捉摸不定的領域?！皯撛鯓訉ξ覀兊漠a(chǎn)品進行測試？”和“怎樣才算對產(chǎn)品進行了足夠的測試？”等問題，對于不同企業(yè)的不同類產(chǎn)品、同一企業(yè)的不同類產(chǎn)品、或不同企業(yè)的同一類產(chǎn)品, 實際操作上都會有很大的不同。10月-2223.1序言困惑：10月-223軟件過程現(xiàn)狀實際項目中，看不到完全符合客戶需求的產(chǎn)品需求規(guī)格說明書。客戶需求不斷變化。代碼頻繁更改。資源有限，進

2、度逼人理想的軟件過程只是追求的目標。測試人員應該面對現(xiàn)實。10月-223軟件過程現(xiàn)狀實際項目中，看不到完全符合客戶需求10月-224軟件測試現(xiàn)狀軟件測試的技術和方法多年以來并沒有取得令人振奮的進展。軟件測試的效果主要還是依賴于測試人員的經(jīng)驗。10月-224軟件測試現(xiàn)狀軟件測試的技術和方法多年以來并沒10月-225對軟件測試的認識的發(fā)展測試=調試測試是證明軟件正確測試是發(fā)現(xiàn)軟件中的錯誤測試是減小軟件不工作的風險測試是一種認識上的訓練10月-225對軟件測試的認識的發(fā)展測試=調試10月-226關于軟件測試的討論這個軟件已經(jīng)經(jīng)過了測試。這個軟件已經(jīng)經(jīng)過了嚴格的測試。這個軟件通過了測試。STE概述10

3、月-226關于軟件測試的討論這個軟件已經(jīng)經(jīng)過了測試。ST10月-227軟件測試的發(fā)展二十世紀70年代以前 Ad-hoc testing，指的是測試者想到哪測到哪，沒有周密的測試計劃和過程，沒有測試文檔，測試不能復用，與調試沒有區(qū)分。70年代末80年代中期 測試基礎理論和實用技術形成，測試作為軟件質量保證（SQA）的主要職能。10月-227軟件測試的發(fā)展二十世紀70年代以前10月-228軟件測試的發(fā)展80年代末90年代中期 測試工具在質量和數(shù)量上不斷增長，測試與SQA分離，SQA注重于過程和質量監(jiān)督，專職測試崗位產(chǎn)生。并且注重工具對測試效率的影響，測試自動化開始廣泛應用。90年代后期 關注有效的

4、過程管理對于軟件測試的重要性，形成各種測試模型、測試能力成熟度模型。10月-228軟件測試的發(fā)展80年代末90年代中期10月-229軟件測試的發(fā)展二十一世紀初 軟件測試的重要性越來越被人們接受，甚至出現(xiàn)了軟件開發(fā)活動應以測試為主導的思潮，如XP方法。而且，隨著軟件測試分工的細化和成熟，軟件企業(yè)注重于自身核心競爭力的提升，促使大量的獨立軟件測試服務機構涌現(xiàn)出來。這些測試服務機構運作機制日趨成熟，從單一的第三方認證評測，逐步轉向參與整個軟件開發(fā)過程的測試服務，并按照軟件領域形成市場細分，已經(jīng)形成一個成熟和廣闊的市場區(qū)間。10月-229軟件測試的發(fā)展二十一世紀初10月-2210軟件測試的發(fā)展官方軟件

5、評測機構軟件工程師資格認證專業(yè)軟件測試企業(yè)專門的軟件測試課程專門的軟件測試學位（不遠的將來）10月-2210軟件測試的發(fā)展10月-22114.2軟件測試定義曾有的定義：軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。軟件測試是根據(jù)軟件開發(fā)階段的規(guī)格說明和程序的內部結構而精心設計的一批測試用例（即輸入數(shù)據(jù)及預期的輸出結果），并利用這些測試用例去運行程序，以發(fā)現(xiàn)錯誤的過程。10月-22114.2軟件測試定義曾有的定義：10月-2212軟件測試的定義（推薦）【國家標準GBT 114571995 】 由人工或自動方法來執(zhí)行或評價系統(tǒng)或系統(tǒng)部件的過程，以驗證它是否滿足規(guī)定的需求；或識別出期望的結果和實際結果之間

6、的差別。【ISO/IEC2號導則】 測試是指由給定產(chǎn)品、過程或按照規(guī)定的規(guī)程服務的一個或多個特性的測定組成的技術操作。10月-2212軟件測試的定義（推薦）【國家標準GBT 110月-2213軟件測試定義（推薦）【 IEEE/ANSI, std829-1983 】 對軟件進行分析，找出其現(xiàn)有狀況與要求狀況之間的差異?；A概念 10月-2213軟件測試定義（推薦）【 IEEE/ANSI,10月-2214關于軟件測試的著名論點關于軟件測試的著名論點Grenford J. Myers：測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程一個好的測試是指很可能找到尚未發(fā)現(xiàn)的錯誤的測試一個成功的測試是指發(fā)現(xiàn)了至今未發(fā)現(xiàn)的

7、錯誤的測試Hetzel：軟件測試是對軟件建立信心的過程測試是評估軟件或系統(tǒng)的品質或能力的一種積極的行為測試是對軟件質量的度量10月-2214關于軟件測試的著名論點關于軟件測試的著名論點10月-22154.3軟件測試目的Grenford J. Myers關于軟件測試的著名論點:測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤；一個好的測試用例在于能夠發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。10月-22154.3軟件測試目的Grenford J. M10月-2216軟件測試目的個人認為這是一種比較狹窄的觀點。10月-2216軟件測試目的個人認為這是一種比較狹窄的觀點。10月-22

8、17軟件測試目的一個被人忽略的軟件測試目的是：測試可以幫助發(fā)現(xiàn)當前開發(fā)工作所采用的軟件過程的缺陷，以便進行改進。 測試并不僅僅是為了要找出錯誤。10月-2217軟件測試目的一個被人忽略的軟件測試目的是：測10月-2218軟件測試目的通過分析錯誤產(chǎn)生的原因, 分析錯誤產(chǎn)生于哪一個開發(fā)階段、而又在哪一個階段被發(fā)現(xiàn)，我們可以判斷從錯誤的產(chǎn)生到錯誤的發(fā)現(xiàn)，跨越了多少個開發(fā)階段。一個錯誤能夠超越本開發(fā)階段而不被發(fā)現(xiàn)，就指明了該開發(fā)階段的檢測手段有缺陷，從而有針對性地制定出加強的措施與辦法。這也就是軟件過程改進的一項重要內容。10月-2218軟件測試目的通過分析錯誤產(chǎn)生的原因, 分析錯10月-2219對軟

9、件測試目的理解以最少時間和最小代價，發(fā)現(xiàn)最多數(shù)量的錯誤。 測試具有發(fā)現(xiàn)錯誤的能力，但不能說明軟件中不存在錯誤，恰恰相反，測試只能證明軟件中存在錯誤。 測試可以減少軟件中的錯誤。測試過程中的數(shù)據(jù)和測試結果，可以為軟件質量的評價提供依據(jù)，可以得到軟件性能指標。 對測試而言，困難和挑戰(zhàn)在于無法預知軟件中潛在的錯誤總 量。但完整的測試是評定軟件質量的一種方法。 沒有發(fā)現(xiàn)錯誤的測試也是有價值的。10月-2219對軟件測試目的理解以最少時間和最小代價，發(fā)現(xiàn)10月-22204.4對軟件測試的認識 軟件測試能做什么?發(fā)現(xiàn)軟件中殘存的錯誤為軟件質量的評價提供支持為軟件開發(fā)過程的改進提供幫助一種有效的軟件工程驗證

10、與確認方法10月-22204.4對軟件測試的認識 軟件測試能做什么?10月-2221測試設計 測試是需要設計的。一個好的測試計劃和測試用例往往能達到事半功倍的效果。測試是一項具有很大創(chuàng)造性的工作，其工作量一點也不比軟件設計小。軟件測試的創(chuàng)造性主要表現(xiàn)在測試方案選擇、測試計劃制定、測試用例設計、測試結果的分析以及測試過程的管理等方面10月-2221測試設計 測試是需要設計的。10月-2222測試目標測試目標我們的目標是設計一個能夠系統(tǒng)地發(fā)現(xiàn)不同階段的錯誤的測試，且消耗最短的時間和最小的工作量。測試的附帶收獲示證了軟件的功能依據(jù)其需求說明而工作表明軟件滿足其性能需求測試中收集的數(shù)據(jù)提供了軟件可靠性

11、和軟件質量的部分信息10月-2222測試目標測試目標10月-2223對軟件測試的理解基于上述定義，測試并不僅僅意味著運行程序的動態(tài)測試，也包括對需求定義和設計等進行分析的靜態(tài)測試。測試是攻擊和破壞軟件的方法和過程，以達到提高軟件質量的目的。測試是努力發(fā)現(xiàn)上述三類軟件錯誤的活動，即：努力發(fā)現(xiàn)偏離錯誤努力發(fā)現(xiàn)語言使用錯誤努力發(fā)現(xiàn)功能缺陷基礎概念 10月-2223對軟件測試的理解基于上述定義，測試并不僅僅意10月-2224對軟件測試的理解從軟件過程的角度來看測試： 測試是指軟件產(chǎn)品生命周期內所有的檢查、評審和確認活動。如：設計評審、代碼走查、系統(tǒng)測試等。測試的最終目的是確保交給用戶的產(chǎn)品符合用戶的需

12、求。10月-2224對軟件測試的理解從軟件過程的角度來看測試： 10月-2225對軟件測試的理解軟件測試要解決的問題是：軟件的行為是否符合“規(guī)定的”要求。 它有兩個方面的含義：第一，軟件測試要解決的問題是，是否做了規(guī)定要做的事；第二，軟件是否做了沒有規(guī)定要做的事？10月-2225對軟件測試的理解軟件測試要解決的問題是：軟件10月-2226軟件測試的局限性無法實現(xiàn)徹底的測試被測系統(tǒng)存在故障敏感性和巧合正確性不能直接驗證需求獲得預期結果困難，甚至不可能測試本身也可能存在錯誤10月-2226軟件測試的局限性無法實現(xiàn)徹底的測試10月-2227軟件測試的致命缺陷測試的不完全、不徹底性。由于任何軟件只能進

13、行有限的測試，發(fā)現(xiàn)了錯誤說明軟件有問題；未發(fā)現(xiàn)錯誤不能說明軟件沒有問題。10月-2227軟件測試的致命缺陷測試的不完全、不徹底性。10月-2228對測試的正確認識軟件測試不是解決軟件質量問題的唯一方法；軟件測試不能取代其他的質量保證手段；軟件測試不能保證發(fā)現(xiàn)軟件中的所有錯誤，完全的測試是不現(xiàn)實的；軟件測試是巨大的效益和艱苦的工作并存，測試的組織和管理就是在其中取得平衡。10月-2228對測試的正確認識軟件測試不是解決軟件質量問題10月-2229軟件測試的重要性項目持續(xù)時間 延遲上市測試人員測試人員100%50%0%完成比率代碼實現(xiàn)消除缺陷質量問題維護的費用1x 10 x 100 x 問題發(fā)現(xiàn)得

14、越早，解決的代價就越小10月-2229軟件測試的重要性項目持續(xù)時間 延遲上市測試人10月-2230項目持續(xù)時間 100%50%0%完成比率消除缺陷消除缺陷保證軟件質量縮短上市時間Close the Quality Gap軟件測試重要性Close the Quality Gap So We Can Release Working Software on time10月-2230項目持續(xù)時間 100%50%0%完成比率消除10月-2231系統(tǒng)性能應用性能功能可靠性100%軟件測試重要性10月-2231系統(tǒng)性能應用性能功能可靠性100%軟件測試重10月-2232風險代碼完成可靠性功能應用性能系統(tǒng)性能

15、風險越早測試越好自動的測試測試每一個版本 傳統(tǒng)的測試是在代碼實現(xiàn)之后進行 軟件測試重要性10月-2232風險代碼完成可靠性功能應用性能系統(tǒng)性能風險越10月-2233一個好的軟件工程的守則軟件開發(fā)全過程檢測，力爭本階段修正錯誤。單元測試是在軟件開發(fā)的“實現(xiàn)階段”才開始的，在此之前的“可行性研究與計劃階段”，“需求分析階段”，“概要設計階段”，和“詳細設計階段”，都必須有切實的手段與措施對開發(fā)結果進行檢驗，以保證階段的正確完成10月-2233一個好的軟件工程的守則軟件開發(fā)全過程檢測，力10月-2234測試的重要性測試是軟件生存周期中一個獨立的、關鍵的階段，是保證軟件質量的重要手段，也是軟件質量保證

16、的最后一個環(huán)節(jié)。測試活動貫穿于軟件活動中的所有階段。 從需求階段高層設計低層設計編碼階段單元測試集成測試系統(tǒng)測試驗收測試測試越早開始，故障越早被發(fā)現(xiàn)，消除故障的成本越少。10月-2234測試的重要性測試是軟件生存周期中一個獨立的、10月-2235內容概要：序言軟件測試定義軟件測試目的對軟件測試的認識軟件測試理論軟件測試原則軟件測試的分類軟件測試的術語和定義其它10月-2235內容概要：序言10月-22363.5軟件測試理論 后面總結了9條軟件測試的基本原理，是軟件測試和軟件開發(fā)的“交通規(guī)則”、“生活法則”。理解它們有助于透徹了解軟件過程。10月-22363.5軟件測試理論 后面總結了9條軟件測

17、試的10月-2237 Parito法則 一般情況下，在分析、設計、實現(xiàn)階段的復審和測試工作只能夠發(fā)現(xiàn)和避免80%的Bug，而系統(tǒng)測試也只能找出其余Bug中的80%，最后剩余的Bug只有在用戶的大范圍、長時間使用后才有可能會曝露出來。因為測試只能夠保證盡可能多地發(fā)現(xiàn)錯誤，無法保證能夠發(fā)現(xiàn)所有的錯誤。 也稱80-20理論。10月-2237 Parito法則 一般情況下，在分析、設10月-2238木桶理論在軟件產(chǎn)品生產(chǎn)方面就是全面質量管理(TQM)的概念。產(chǎn)品質量的關鍵因素是分析、設計和實現(xiàn)，測試應該是融于其中的補充檢查手段，其他管理、支持、甚至文化因素也會影響最終產(chǎn)品的質量。應該說，測試是提高產(chǎn)品

18、質量的必要條件，也是提高產(chǎn)品質量最直接、最快捷的手段，但決不是一種根本手段。反過來說，如果將提高產(chǎn)品量的砝碼全部押在測試上，那將是一個恐怖而漫長的災難。木桶理論就是要強調改進我們木板最短的那一塊.只有短木板變?yōu)殚L木板,桶裝水才會更多。10月-2238木桶理論在軟件產(chǎn)品生產(chǎn)方面就是全面質量管理10月-2239測試不能證明軟件無錯 軟件測試的不完全、不徹底性。測試無法顯示潛伏的軟件缺陷。 由于任何程序只能進行有限的測試，在發(fā)現(xiàn)錯誤時能說明程序有問題；但在測試未發(fā)現(xiàn)錯誤時，不能說明程序中沒有錯誤。10月-2239測試不能證明軟件無錯 軟件測試的不完全、不10月-2240完全測試軟件是不可能的主要原因

19、：輸入量太大輸出結果太多軟件實現(xiàn)的途徑太多軟件需求規(guī)格說明書沒有客觀標準。“太多”的可能性加在一起，致使測試條件難以確定。10月-2240完全測試軟件是不可能的主要原因：10月-2241完全測試軟件是不可能的例如：WinX操作系統(tǒng)帶的計算器程序。單個數(shù)據(jù)、多個數(shù)據(jù)的組合；+,-,*./各種算法組合；正常、異常情況組合輸入組合無窮多，無法完全測試。注：如果覺得某些測試條件是重復的或者無必要的而將其剔除，那么就不能稱作完全測試。10月-2241完全測試軟件是不可能的例如：WinX操作系統(tǒng)10月-2242軟件測試是有風險的行為 如果決定不去測試所有的情況，那就是選擇了風險。（泄漏故障的可能性）（碰巧

20、在某個特定的輸入組合下軟件留有缺陷）如何把無邊無際的輸入可能減少到可以控制的范圍？去粗存精，減小風險。10月-2242軟件測試是有風險的行為 如果決定不去測試所10月-2243測試量和發(fā)現(xiàn)的軟件缺陷數(shù)量之間的關系10月-2243測試量和發(fā)現(xiàn)的軟件缺陷數(shù)量之間的關系10月-2244軟件測試是有風險的行為 由上圖，隨著測試工作量的增加，費用增加，遺漏軟件缺陷數(shù)目減少。最佳平衡點在哪？找到了它，就找到了最合適的測試工作量。10月-2244軟件測試是有風險的行為 由上圖，隨著測試工作10月-2245測試無法顯示潛伏的軟件缺陷 軟件測試工作可以報告已發(fā)現(xiàn)的軟件缺陷；卻不能保證軟件缺陷全部找到；也不知道還

21、有多少潛伏的軟件缺陷。繼續(xù)測試，可能還會找到一些。10月-2245測試無法顯示潛伏的軟件缺陷 軟件測試工作可10月-2246程序中存在錯誤的概率與該程序中已發(fā)現(xiàn)的錯誤數(shù)成比例。 軟件缺陷的“群集”現(xiàn)象， 80%的錯誤存在于20%的代碼中。原因：程序員疲倦。一個軟件缺陷很可能是附近有更多的軟件缺陷的征兆。程序員易犯同樣的錯誤。個人偏好。多個軟件缺陷相互關聯(lián)，甚至是由同一個原因造成的。缺陷的“傳遞”和“放大”。10月-2246程序中存在錯誤的概率與該程序中已發(fā)現(xiàn)的錯誤10月-2247程序中存在錯誤的概率與該程序中已發(fā)現(xiàn)的錯誤數(shù)成比例。 找到軟件缺陷越多的模塊，遺留的軟件缺陷越多。如果某軟件無論如何

22、也找不出軟件缺陷，也可能是軟件經(jīng)過精心編制，確實存在極少的軟件缺陷。10月-2247程序中存在錯誤的概率與該程序中已發(fā)現(xiàn)的錯誤數(shù)10月-2248軟件缺陷的免疫力 軟件會對相同類型的測試會產(chǎn)生“免疫力”。(開發(fā)小組VS.測試小組)。經(jīng)過幾輪的測試，該發(fā)現(xiàn)的錯誤都被發(fā)現(xiàn)了，再測試下去也不會有新的發(fā)現(xiàn)了。農(nóng)藥殺蟲劑怪事。解決：不斷編寫新的測試用例，采用新的測試程序，對程序的不同部分進行測試，以找出更多的軟件缺陷。10月-2248軟件缺陷的免疫力 軟件會對相同類型的測試會10月-2249并非所有軟件缺陷都能修復 項目組需要對每一個軟件缺陷進行評估和取舍，根據(jù)風險和成本決定哪些必須修復，哪些不用修復，哪

23、些可以延期修復。通常有CCB會議決定。CCB由軟件項目各方代表組成。10月-2249并非所有軟件缺陷都能修復 項目組需要對每一10月-2250并非所有軟件缺陷都能修復 不需要修復的軟件缺陷的原因：沒有足夠的時間。不算是真正的軟件缺陷。小功能，小改進。修復的風險太大。技術難度，引入新的缺陷，不值得修復。商業(yè)風險（intel奔騰浮點數(shù)運算缺陷）10月-2250并非所有軟件缺陷都能修復 不需要修復的軟件缺10月-2251相互關系不可能進行完全的測試。由于1，測試是有風險的，即測試會遺漏軟件缺陷。由于2，測試不能證明程序無措，而僅能證明程序有錯。由于1，2，3，測試發(fā)現(xiàn)的錯誤越多，則說明軟件的錯誤越多

24、。錯誤密度大，遺漏的也多?；A概念 10月-2251相互關系不可能進行完全的測試?；A概念 10月-2252內容概要：序言軟件測試定義軟件測試目的對軟件測試的認識軟件測試理論軟件測試原則軟件測試的分類軟件測試的術語和定義其它10月-2252內容概要：序言10月-22533.6軟件測試的基本原則 基于上述的測試理論，下面列舉一些測試原則，它們是軟件測試工作中常用的策略。它們建立在實踐的基礎上。10月-22533.6軟件測試的基本原則 基于上述的測試理論10月-2254測試的基本原則(一)所有的測試都應追溯到用戶需求 產(chǎn)品最終是為了給用戶使用，對用戶來說，最嚴重的錯誤是那些導致程序不能夠滿足他們的

25、需求的錯誤，所以測試應該從用戶的角度來測試產(chǎn)品。 事實上，需求是驅動整個研發(fā)過程的源頭，不僅僅設計、開發(fā)要需求 驅動，測試更是要需求驅動。 實際的做法：測試設計依據(jù)需求設計，并建立需求追蹤矩陣，測試活動按照測試設計進行。測試人員把握用戶真實的需求，不僅僅做驗證工作，也要做確認工作。10月-2254測試的基本原則(一)所有的測試都應追溯到用戶10月-2255測試的基本原則(二)所有測試活動都應該是有計劃的，并且計劃能夠得到保障。 嚴格執(zhí)行測試計劃,排除測試的隨意性。要堅決反對無計劃、無明確目的、隨意的測試活動；反對過程不可重復的即興測試。 測試計劃應在需求一確定或需求模型一完成就開始，總之要在代

26、碼產(chǎn)生之前就開始。測試計劃包括日程計劃、資源計劃、方案設計、測試用例設計等。 現(xiàn)實工作中，常見的問題就是測試無計劃或計劃性不強、隨意更改測試計劃、迫于市場壓力壓縮測試計劃等。10月-2255測試的基本原則(二)所有測試活動都應該是有計10月-2256測試的基本原則(三) Good-enough原則 測試要權衡投入產(chǎn)出比，即要充分也不要過分。不充分的測試是不負責任的；過分的測試是一種資源的浪費，同樣也是一種不負責任的表現(xiàn)。 過分測試指無意義的重復測試和需要消耗過大投入的非關鍵性測試。 困難在于：如何界定什么樣的測試是不充分的，什么樣的測試是過分的。10月-2256測試的基本原則(三) Good-

27、enough10月-2257測試的基本原則(三續(xù)) 答案： 制定最低測試通過標準和測試內容，然后具體問題具體分析。 持續(xù)地對測試過程進行度量，對測試和測試結果評價，在保證充分性的前提下去除冗余測試，確保測試過程的有效性。 然而，實際測試工作中，我們很少去關注這方面的數(shù)據(jù)。 對于相對復雜的產(chǎn)品或系統(tǒng)來說，zero-bug是一種理想，good-enough是我們的原則。 尋求合適的測試策略，在質量和成本之間尋求合適的平衡點。10月-2257測試的基本原則(三續(xù)) 答案：10月-2258測試的基本原則(四)軟件測試應遵循Parito法則（二八法則）。 二八法則最初來源于社會經(jīng)濟現(xiàn)象研究結果，也同樣適

28、用于軟件測試領域。 80的故障存在于20的代碼中； 80的故障歸因于20的故障原因； 關注測試中的群集現(xiàn)象；關注發(fā)現(xiàn)缺陷較多的代碼。 掌握這一法則有助于我們在測試過程中抓住重點，有針對性，做到事半功倍。10月-2258測試的基本原則(四)軟件測試應遵循Parit10月-2259測試的基本原則(五)盡早地和不斷地進行軟件測試在軟件生命周期中，越早發(fā)現(xiàn)軟件故障，修復它所花費的費用越少，造成的損失越小。軟件開發(fā)全過程進行測試，力爭在本階段發(fā)現(xiàn)和修正錯誤。10月-2259測試的基本原則(五)盡早地和不斷地進行軟件測10月-2260測試的基本原則(六)測試應由小到大，從小規(guī)模到大規(guī)模。 測試的粒度和范圍

29、應該由小到大，最初的測試應該把焦點放在單個程序模塊上，也就是單元測試，然后是多個模塊的集成（集成測試），最后是全系統(tǒng)測試（系統(tǒng)測試）。 現(xiàn)狀是缺乏小粒度的測試，所以即使系統(tǒng)測試投入足夠的資源和時間也難以將產(chǎn)品質量提高到一個新的層次。 10月-2260測試的基本原則(六)測試應由小到大，從小規(guī)模10月-2261測試的基本原則(七)窮舉測試是不可能的，充分覆蓋程序邏輯是有可能的。 真實運行情況下，產(chǎn)品將運行于不同的環(huán)境和條件下。特別是對于復雜軟件，做到窮舉測試是不可能的。 但是我們應該提高測試的覆蓋率，保證程序的每一個邏輯判斷分支可以測試到。 正是因為不能窮舉測試，所以軟件總會遺留（潛在的）缺陷，

30、所以測試覆蓋率提高是測試永恒的追究目標。 因窮舉測試是不可行的。為了節(jié)省時間和資源，就必須從數(shù)量極大的可用測試案例中精心地挑選出少量的具有代表性測試案例（采用這些測試案例是最佳平衡點）；并在測試執(zhí)行過程中嚴格按測試計劃執(zhí)行，才能達到最佳的測試效果。10月-2261測試的基本原則(七)窮舉測試是不可能的，充分Ch軟件測試基礎知識課件Ch軟件測試基礎知識課件10月-2264程序員避免測試自己的程序 原因2：思路受局限難以發(fā)現(xiàn)功能理解錯誤。 程序中可能包含由于程序員對問題的敘述或說明的誤解而產(chǎn)生的錯誤。如果是這種情況，當程序員測試自己的程序時，往往還會帶著同樣的誤解致使問題難以發(fā)現(xiàn)。10月-2264

31、程序員避免測試自己的程序 原因2：思路受局限Ch軟件測試基礎知識課件10月-2266測試的基本原則(九)為了達到最佳效果，應由獨立于開發(fā)的專門測試人員來構造測試。 全面的獨立第三方測試對測試的效果有保障（后面詳細介紹），但需要在測試的人力和設備上有較大投入。如微軟的測試，在開發(fā)Exchange 2000時測試人員和開發(fā)人員的比例是2.5:1,在開發(fā)Win2000時，測試人員和開發(fā)人員的比例是1.9:1。 我們的實際情況目前難以做到這樣的投入。10月-2266測試的基本原則(九)為了達到最佳效果，應由獨10月-2267軟件測試的其它原則 分派有經(jīng)驗、富有創(chuàng)造性的人員承擔測試。 不能為了便于測試擅

32、自修改程序。既測試軟件應該做的也檢查軟件不該做的。既測試有效的和期望的輸入也測試無效的和不期望的輸入。10月-2267軟件測試的其它原則 分派有經(jīng)驗、富有創(chuàng)造性的10月-2268“好的”測試的基本特征具有高的發(fā)現(xiàn)錯誤的概率沒有冗余測試測試是“最佳類別”既不太簡單也不太復雜10月-2268“好的”測試的基本特征具有高的發(fā)現(xiàn)錯誤的概率10月-2269誰來完成測試1、開發(fā)者測試2、對等測試3、獨立測試小組4、獨立測試機構10月-2269誰來完成測試1、開發(fā)者測試10月-2270獨立測試的好處獨立測試是指軟件測試工作由在經(jīng)濟上和管理上獨立于開發(fā)機構的組織進行。軟件測試由獨立測試機構承擔有許多好處。獨立

33、測試可以避免軟件開發(fā)者測試自己開發(fā)的軟件。由于心理學上的問題，軟件開發(fā)者難以客觀、有效地測試自己的軟件，而找出那些因為對問題的誤解而產(chǎn)生的錯誤就更加困難。 10月-2270獨立測試的好處獨立測試是指軟件測試工作由在經(jīng)10月-2271獨立測試的好處獨立測試還可以避免軟件開發(fā)機構測試自己的軟件。軟件產(chǎn)品的開發(fā)過程受到時間、成本和質量三者的制約，時間和成本指標便于衡量，而質量卻很難度量，因此在軟件開發(fā)過程中，當時間、成本和質量三者發(fā)生矛盾時，質量最容易被忽視。如果測試組織與開發(fā)組織來自相同的機構，測試過程就會面臨來自與開發(fā)組織同一來源的管理方面的壓力，使測試過程受到干擾。 10月-2271獨立測試的

34、好處獨立測試還可以避免軟件開發(fā)機構Ch軟件測試基礎知識課件Ch軟件測試基礎知識課件Ch軟件測試基礎知識課件Ch軟件測試基礎知識課件10月-2276典型項目的軟件測試投入(IBM)一般項目：項目總投入的30%40%高可靠性和高安全性項目：項目其它投入的35倍10月-2276典型項目的軟件測試投入(IBM)一般項目：項10月-2277典型項目的人工統(tǒng)計(HP)10月-2277典型項目的人工統(tǒng)計(HP)10月-2278內容概要：序言軟件測試定義軟件測試目的對軟件測試的認識軟件測試理論軟件測試原則軟件測試的分類軟件測試的術語和定義其它10月-2278內容概要：序言10月-22793.7軟件測試分類不同

35、的分類方法，得出不同的分類。10月-22793.7軟件測試分類不同的分類方法，得出不同的10月-2280軟件測試的分類(一)按測試對象分文檔測試 包括用戶需求文檔、軟件需求文檔、系統(tǒng)設計文檔、用戶手冊等。代碼測試版本測試 對代碼集成、編譯后的軟件運行版本的測試。10月-2280軟件測試的分類(一)按測試對象分10月-2281軟件測試的分類(二)按測試對象的粒度分單元測試集成測試系統(tǒng)測試確認測試 如驗收測試就是典型的確認測試。10月-2281軟件測試的分類(二)按測試對象的粒度分10月-2282軟件測試的分類(三)按測試方法分白盒測試 白盒測試又叫結構測試。已知軟件的內部工作過程，通過測試證明每

36、種內部操作是否符合設計規(guī)格要求，所有內部成分是否已經(jīng)通過檢查。黑盒測試 黑盒又叫做功能測試。已知軟件的功能設計規(guī)格，進行測試證明每個實現(xiàn)了的功能是否符合要求，它不僅用于開發(fā)階段的測試，更重要的是用于產(chǎn)品的測試階段及維護階段?；液袦y試 白盒測試和黑盒測試方法的結合運用。目前最常用的測試方法。10月-2282軟件測試的分類(三)按測試方法分10月-2283軟件測試的分類(四)按測試執(zhí)行方法分人工測試自動測試 由工具實現(xiàn)自動的測試運行、記錄測試值并和設定的期望值進行比較，自動輸出測試結果和測試報告。半自動測試 借助一定的工具輔助手工測試，或者對自動測試進行人工干預。 10月-2283軟件測試的分類(

37、四)按測試執(zhí)行方法分10月-2284軟件測試的分類(五)按運行狀態(tài)分動態(tài)測試 動態(tài)測試就是通過選擇適當?shù)臏y試用例，實際運行測試程序，比較運行結果，動態(tài)測試能使所測程序有控制地運行，自動地監(jiān)視、記錄、統(tǒng)計程序的運行情況。 動態(tài)測試更具真實性，但是動態(tài)測試必須生成測試數(shù)據(jù)來運行程序，開展測試工作費時費力，動態(tài)測試中涉及多方面工作，要求有完善的管理和工作流程。靜態(tài)測試 靜態(tài)測試是指靜態(tài)分析程序。靜態(tài)測試不需要執(zhí)行所測試的程序，它掃描所測試程序的正文，對程序的數(shù)據(jù)流和控制流進行分析，然后提出測試報告。 代碼走查可以看作是一種靜態(tài)測試。靜態(tài)測試可以使用一些輔助工具如：PCLint、Logiscope 、

38、CodeWizard10月-2284軟件測試的分類(五)按運行狀態(tài)分10月-2285軟件測試的分類(六) 按測試執(zhí)行者分開發(fā)人員自測測試人員測試第三方測試機構測試驗收測試用戶測試 10月-2285軟件測試的分類(六) 按測試執(zhí)行者分10月-2286軟件測試的分類(七)按被測對象技術領域分系統(tǒng)平臺類軟件測試數(shù)據(jù)庫軟件測試工具軟件測試應用軟件測試不同領域的軟件對測試的要求也不一樣，如系統(tǒng)平臺類軟件關注系統(tǒng)的穩(wěn)定性和健壯性，數(shù)據(jù)庫軟件關注數(shù)據(jù)處理的性能和流量，工具類軟件關注易用性等。10月-2286軟件測試的分類(七)按被測對象技術領域分10月-2287軟件測試的分類(八)按測試內容分功能測試性能測

39、試 性能測試用來衡量系統(tǒng)的響應時間、事務處理速度和其它時間敏感的需求。并能測出與性能相關的工作負載和硬件配置條件等。界面測試壓力測試 可找出由于資源不足或資源競爭引起的錯誤，在較少的內存和磁盤空間狀態(tài)下可能會暴露常態(tài)下不易發(fā)現(xiàn)的問題。安全性測試10月-2287軟件測試的分類(八)按測試內容分10月-2288軟件測試的分類(八)（續(xù)）安裝測試 確保軟件在各種條件下能正確安裝，包括初次安裝、升級、完全安裝和客戶定制安裝。以及檢查軟件安裝之后操作的正確性。配置測試 檢查測試應用在不同的軟硬件配置狀態(tài)下的操作。大多數(shù)情況下，不同的客戶工作站、網(wǎng)絡、數(shù)據(jù)庫服務器配置具備不同的性能，甚至系統(tǒng)性能隨軟件配置

40、的變化而不同。恢復性測試（容錯測試）兼容性測試等等10月-2288軟件測試的分類(八)（續(xù)）10月-2289軟件測試的分類(九)按測試范圍分驗證測試 僅僅驗證變更的修改是否達到了預期目的。通常會對修改做變更波及分析，但不會重新執(zhí)行所有的測試用例。完整測試：執(zhí)行所有的測試用例?；貧w測試 測試范圍介于前兩者之間。其測試范圍通常是：前一次執(zhí)行未通過的測試用例；變更波及分析后預計受影響的測試用例；因變更修改而新增的測試用例；部分前一次執(zhí)行通過的測試用例；部分很長一段時間沒有執(zhí)行過的測試用例。10月-2289軟件測試的分類(九)按測試范圍分10月-2290軟件測試的分類(九)還有：冒煙測試 進行檢驗系統(tǒng)

41、是否能夠正常上電運行，是否提供最基本的業(yè)務功能。BVT（Basic Verify Test）測試 BVT測試是測試的最基本要求，也是最先進行的測試。基準測試 Benchmark Test： 和其它相似產(chǎn)品的質量比較 和給定的/設計的質量指標比較 和政府發(fā)布的標準/公布的行業(yè)數(shù)據(jù)比較10月-2290軟件測試的分類(九)還有：10月-22913.8軟件測試的術語和定義不要：混淆誤用理解：含義差別10月-22913.8軟件測試的術語和定義不要：10月-2292準確和精確舉例：飛鏢靶盤（圖）既不準確又不精確精確但不準確準確但不精確既準確又精確10月-2292準確和精確舉例：10月-2293既不準確又不

42、精確10月-2293既不準確又不精確10月-2294精確但不準確10月-2294精確但不準確10月-2295準確但不精確10月-2295準確但不精確10月-2296既準確又精確10月-2296既準確又精確10月-2297Verification&ValidationVerification: do the things rightValidation: do the right things.10月-2297Verification&Validatio10月-2298驗證與確認驗證(verification)為確定某一開發(fā)階段的產(chǎn)品是否滿足在該階段開始時提出的要求的評估過程。一般采用靜態(tài)測試的

43、方式(不基于程序的運行)。通過檢查并收集客觀的證據(jù)來確定特定的需求得到滿足。驗證對象包括所有選定的需求，包括客戶的、產(chǎn)品的以及產(chǎn)品部件的需求，對產(chǎn)品和中間工作產(chǎn)品進行驗證。驗證是一個漸進的過程。10月-2298驗證與確認驗證(verification)10月-2299驗證與確認確認(Validation)為確定系統(tǒng)或部件是否滿足需求的評估過程。一般采用動態(tài)測試的方式(基于程序的運行)。通過檢查并收集客觀的證據(jù)來確定針對某種特定需求在提供時滿足預期的使用。確認活動適用于產(chǎn)品在其諸如運行、培訓、制造、維護、以及支持服務等任何預期環(huán)境中的任何方面。確認活動即可以用于工作產(chǎn)品，也可以用于產(chǎn)品或產(chǎn)品部件

44、。確認活動常常需要用戶的參與。10月-2299驗證與確認確認(Validation)10月-22100驗證與確認驗證：構造的產(chǎn)品正確嗎？- 評審確認：是否構造了正確的產(chǎn)品？- 測試10月-22100驗證與確認驗證：構造的產(chǎn)品正確嗎？-10月-22101質量和可靠性錯誤觀點：軟件一直穩(wěn)定、可靠運行，就認定是高質量的產(chǎn)品。用戶對質量的看法：功能是否齊全；可靠性；易用性；文檔齊套性；產(chǎn)品外觀（包裝、界面等）；售前售后技術支持程度；等等。10月-22101質量和可靠性錯誤觀點：軟件一直穩(wěn)定、可靠運10月-22102質量和可靠性可靠性只是質量的一個方面。10月-22102質量和可靠性10月-22103QC和QA質量控制驗證產(chǎn)品的正確性，當發(fā)現(xiàn)與設計不一致的時候進行糾正。質量保證充當支持執(zhí)行全面質量管理的