Ch1-軟件測試基礎知識

軟件測試方法和技術

-Ch.1軟件測試基礎知識1內(nèi)容概覽全書共分成三大部分軟件測試的原理，闡述軟件測試的重要性、基本概念和方法等軟件測試的技術，介紹軟件測試在各個階段（單元測試、集成測試、系統(tǒng)測試、驗收測試和安裝測試)的技術和方法，以及典型測試領域的特點和技術軟件測試的實踐，介紹軟件測試的團隊和環(huán)境的建立，以及如何設計測試用例、報告軟件缺陷、寫測試報告、測試項 目的管 理2機遇和挑戰(zhàn)并存TestEngineerQA/SupervisorProject/QualityManager目前國內(nèi)軟件業(yè)的弱點正是發(fā)展的前沿321世紀什么最貴——軟件測試工程師

軟件測試工程師，目前IT行業(yè)極端短缺的金貴人才，未來5年IT行業(yè)最炙手可熱的高薪職位。中國軟件業(yè)每年新增約20萬測試崗位就業(yè)機會，而企業(yè)、學校培養(yǎng)出的測試人才卻不足需求量的1/10，這種測試人才需求與供給間的差距仍在拉大。

軟件測試——產(chǎn)品質(zhì)量的保證軟件測試——控制成本的關鍵軟件測試——軟件可靠性確認軟件測試——讓企業(yè)具備國際競爭的實力

4人力市場的測試人員位置

？1800虛位以待…Onlyinonewebsite-51job.cob5職位描述制定測試計劃，根據(jù)需求分析和詳細設計，撰寫測試用例；執(zhí)行軟件測試，根據(jù)測試計劃和測試用例，檢測系統(tǒng)是否符合功能規(guī)格說明；進行錯誤跟蹤，承擔質(zhì)量保證；撰寫相關技術文檔（如測試計劃書、測試用例、測試報告、修改建議等）。6熟悉軟件工程、軟件測試理論和方法，了解相關的測試流程、測試文檔標準，并知曉軟件的開發(fā)過程；對基于Web軟件產(chǎn)品設計有較深的了解；能夠獨立撰寫測試計劃、測試用例，并完成測試任務，提交測試報告；熟悉錯誤跟蹤軟件,并能建立及維護錯誤跟蹤系統(tǒng)；熟悉基于Web系統(tǒng)自動化測試和性能測試工具（如：LoadRunner、QTP等）者優(yōu)先；熟悉SQL語句，熟悉Oracle、SQLServer、DB2者優(yōu)先。

任職資格7課程目標本課程是計算機或軟件專業(yè)課程，重在培養(yǎng)我們的實踐能力，適應軟件企業(yè)的工作環(huán)境和業(yè)界標準，并和國際先進的軟件開發(fā)理念和測試技術保持同步。通過本課程的學習，了解并掌握軟件產(chǎn)品質(zhì)量保證的基本思想和科學體系、軟件測試技術的基本內(nèi)容，以及軟件測試的方法、技術和工具的使用，為全面掌握軟件技術和軟件項目管理打下堅實的基礎。8課程目標通過本課程的學習，我們還可以了解并掌握：

有效的測試策略、方法和技術測試計劃和測試用例的設計測試自動化的引入、應用測試團隊的建立和測試項目的管理更清楚、準確地報告測試缺陷對軟件產(chǎn)品質(zhì)量的正確評估軟件測試和質(zhì)量保證的關系和區(qū)別

……9課程服務于-測試工程師TestengineerQA工程師/經(jīng)理

QAEngineer/Manager

軟件工程過程組成員ThememberofSEPG

項目經(jīng)理Projectmanager

……10課程考核課時：108平時成績占20％（到勤、作業(yè)、實訓）期中考試占20％期末考試占60％11第一章軟件測試基礎知識1.1軟件的概念1.2軟件測試基本概念1.3軟件測試的必要性1.4軟件測試的分類12了解軟件的含義了解軟件測試的重要性了解軟件測試的工作范疇掌握軟件質(zhì)量的定義、內(nèi)涵掌握軟件開發(fā)的基本過程理解軟件開發(fā)過程的模型理解軟件缺陷的定義、種類、產(chǎn)生和構成理解軟件測試的分類理解軟件測試的基本方法學習目標13學習重點軟件開發(fā)的基本過程軟件開發(fā)過程的模型軟件測試的重要性軟件測試的分類缺陷的定義、種類、產(chǎn)生和構成軟件測試的基本方法14軟件開發(fā)過程的模型軟件測試的基本方法軟件測試的分類學習難點151.1軟件的概念能夠完成預定功能和性能的、可執(zhí)行的指令(計算機程序)；使得程序能夠適當?shù)夭僮餍畔⒌臄?shù)據(jù)結構；描述程序的操作和使用的文檔。軟件=程序+數(shù)據(jù)（庫）+文檔+服務161.1軟件的含義軟件危機：在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題，軟件生產(chǎn)與市場需求出現(xiàn)極不適應的嚴重現(xiàn)象軟件工程：應用計算機科學、數(shù)學及管理科學等原理開發(fā)軟件的工程17軟件組成客戶需求-CustomerRequirements市場需求文檔-MRD(MarketingRequirementDocument)軟件規(guī)格說明書-Specifications技術設計文檔–TechnicalDesignDocs測試文檔TestDocuments在線幫助-Onlinehelp產(chǎn)品發(fā)布注釋-ReleaseNotes/ReadMe產(chǎn)品軟件包-ReleasepackagesReturn18軟件產(chǎn)品的其他內(nèi)容

幫助文件Helpfiles

示例Samplesandexamplestoillustratepoints

產(chǎn)品支持文檔Productsupportinformation

錯誤信息Errormessages

安裝手冊Setupandinstallationinstructions

用戶手冊Usermanual(s)

產(chǎn)品標簽Labelandstickers

產(chǎn)品廣告或宣傳材料Adsandmarketingmaterial……19軟件特點軟件則是邏輯的、知識性的產(chǎn)品集合，是對物理世界的一種抽象，或者是某種物理形態(tài)的虛擬化。

軟件是硬件的靈魂，硬件是軟件的基礎軟件，是智慧和知識的結晶軟件不會“磨損”，而是逐步完善

.20軟件開發(fā)過程的特性

軟件開發(fā)的基本過程軟件開發(fā)過程模型UML代表著軟件建模的發(fā)展趨勢21軟件開發(fā)的基本過程22軟件開發(fā)過程需求分析:

根據(jù)客戶的要求，清楚了解客戶需求中的產(chǎn)品功能、特性、性能、界面和具體規(guī)格等，然后進行分析，確定軟件產(chǎn)品所能達到的目標。設計:

根據(jù)需求分析的結果，考慮如何在邏輯、程序上去實現(xiàn)所定義的產(chǎn)品功能、特性等，可以分為概要設計和詳細設計，也可分為數(shù)據(jù)結構設計、軟件體系結構設計、應用接口設計、模塊設計、界面設計等。編程:

將設計轉(zhuǎn)換成計算機可讀的形式。測試:

對設計、編程進行驗證和用戶需求確認的過程維護：維持軟件運行，修改軟件缺陷、增強已有功能、增加新功能、升級等。23軟件開發(fā)過程模型

軟件開發(fā)過程中存在各種復雜因素，為了解決由此而帶來的種種問題，軟件開發(fā)者們經(jīng)過多年的摸索，給出了多種實現(xiàn)軟件工程的方式——軟件過程模型，如瀑布過程模型、螺旋過程模型和增量過程模型等。

24

瀑布過程模型反映了人們早期對軟件工程的認識水平，是人們所熟悉的一種線性思維的體現(xiàn)。瀑布過程模型強調(diào)階段的劃分及其順序性、各階段工作及其文檔的完備性，是一種嚴格線性的、按階段順序的、逐步細化的開發(fā)模式。

瀑布模型2526

螺旋過程模型的基本思路是，依據(jù)前一個版本的結果構造新的版本，這個不斷重復迭代的過程形成了一個螺旋上升的路徑。螺旋模型27圖1-2螺旋過程模型28有些時候可能會用一種幾乎連續(xù)的過程小幅度地推進項目，這就是增量過程模型。增量過程模型29

快速原型過程模型首先是快速進行系統(tǒng)分析，

在設計人員和用戶的緊密配合下，快速確定軟件系統(tǒng)的基本要求，盡快實現(xiàn)一個可運行的、功能簡單的原型系統(tǒng)，然后通過對原型系統(tǒng)逐步求精，不斷擴充完善得到最終的軟件系統(tǒng)?？焖僭湍Ｐ?0快速應用開發(fā)(RAD)–V模型31RAD-VModel(改進)32迭代模型增量開發(fā)迭代開發(fā)33UML代表著軟件建模的發(fā)展趨勢

敏捷開發(fā)（AgileDevelopment）

“極限編程”(eXtremeProgramming

泛型編程（GenericProgramming）

面向方面的編程（AspectOrientedProgramming，簡稱AOP）

UML(UnifiedModelingLanguage,統(tǒng)一建模語言)可以說代表軟件建模的今后5到10年的發(fā)展方向，成為面向?qū)ο蠹夹g領域內(nèi)占主導地位的標準建模語言，支持從需求分析開始的軟件開發(fā)的全過程?？偟膩碚f，UML是一種定義良好、易于表示、功能強大且普遍實用的建模語言34UML發(fā)展歷史

35問題：生活中有測試（質(zhì)檢）的例子？36對軟件產(chǎn)品進行充分測試，找出其中的缺陷(Bug),并進行修復(Fix)。軟件測試是測試的一種，顧名思義就是對軟件進行測試。軟件測試是由于軟件缺陷的存在而產(chǎn)生的。我們將所有軟件問題統(tǒng)稱作軟件缺陷，不管他們的規(guī)模和危害有多大，由于它們都會產(chǎn)生使用障礙，而都稱為軟件缺陷。1.2軟件測試的基本概念37軟件測試的基本概念軟件測試就是在軟件投入運行前，對軟件需求分析、設計規(guī)格說明和編碼實現(xiàn)的最終審查，它是軟件質(zhì)量保證的關鍵步驟。實踐證明：對軟件進行充分的測試 才能夠有效的保證軟件質(zhì)量38軟件測試的基本概念軟件測試的定義軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結構而精心設計的一批測試用例，并利用這些測試用例運行程序以及發(fā)現(xiàn)錯誤的過程，即執(zhí)行測試步驟。測試用例為特定的目的而設計的一組測試輸入、執(zhí)行條件和預期的結果；測試用例是執(zhí)行測試的最小實體。

測試步驟：測試步驟詳細規(guī)定了如何設置、執(zhí)行、評估特定的測試用例。

39軟件測試的對象軟件測試不等于程序測試。軟件開發(fā)過程中所產(chǎn)生的需求規(guī)格說明、概要設計規(guī)格說明、詳細設計規(guī)格說明以及源程序都是軟件測試的對象。

軟件測試的基本概念40軟件測試的目的“程序測試是為了發(fā)現(xiàn)錯誤（BUG）而執(zhí)行程序的過程”。測試的目的是發(fā)現(xiàn)程序中的錯誤，是為了證明程序有錯，而不是證明程序無錯。在軟件開發(fā)過程中，分析、設計與編碼等工作都是建設性的，惟獨測試是帶有“破壞性”，測試可視為分析、設計和編碼3個階段的“最終復審”，在軟件質(zhì)量保證中具有重要地位。

41Bug缺點（defect）偏差（variance）謬誤（fault）失?。╢ailure）問題（problem）矛盾（inconsistency）錯誤（error）毛?。╥ncident）異常（anomy）42什么是Bug?軟件缺陷(Bug)是什么Anyproblem/disfigurement/limitationinproductdesign&development

Featureorfunctioncan’tworkUnreasonabledesignPartlyrealizationinfunctionDataerrorRunerrorLimitationinfeaturesDifferencebetweenactualresultsandexpectedresultsUnfriendlyUI,LowperformanceOthers任何程序、系統(tǒng)中的問題，和產(chǎn)品設計書的不一致性，不能滿足用戶的需求43軟件缺陷IEEE軟件缺陷一個標準的定義：從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護過程中所存在的錯誤、毛病等各種問題；從外部看，軟件缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。

軟件缺陷的主要類型/現(xiàn)象：功能、特性沒有實現(xiàn)或部分實現(xiàn)設計不合理，存在缺陷實際結果和預期結果不一致運行出錯，包括運行中斷、系統(tǒng)崩潰、界面混亂數(shù)據(jù)結果不正確、精度不夠用戶不能接受的其他問題，如存取時間過長、界面不美觀

44致命的：致命的錯誤，造成系統(tǒng)或應用程序崩潰，死機或造成數(shù)據(jù)丟失、主要功能完全喪失。嚴重的：嚴重錯誤，指功能或特性沒有實現(xiàn)，主要功能部分喪失，次要功能完全喪失。一般的：不太嚴重的錯誤，不影響基本使用但沒有很好的實現(xiàn)功能，沒有達到預期效果。微小的：一些小問題，對功能幾乎沒有影響。軟件缺陷錯誤級別45激活狀態(tài)（OPEN）：問題還沒有解決，測試人員新報的BUG，或驗證后的BUG仍然存在。已修正狀態(tài)（FIXED）：開發(fā)人員針對所存在的缺陷，修改程序，認為問題已解決。關閉或非激活狀態(tài)：測試人員驗證FIXEDBUG后，確認BUG不存在之后的狀態(tài)。BUG狀態(tài)46軟件缺陷的產(chǎn)生技術問題算法錯誤，語法錯誤，計算和精度問題，接口參數(shù)傳遞不匹配團隊工作誤解、溝通不充分軟件本身文檔錯誤、用戶使用場合(userscenario)，時間上不協(xié)調(diào)、或不一致性所帶來的問題;系統(tǒng)的自我恢復或數(shù)據(jù)的異地備份、災難性恢復等問題47軟件缺陷構成

48軟件缺陷在不同階段的分布

在真正的程序測試之前，通過審查、評審會可以發(fā)現(xiàn)更多的缺陷。規(guī)格說明書的缺陷會在需求分析審查、設計、編碼、測試等過程中會逐步發(fā)現(xiàn)，而不能在測試一個階段發(fā)現(xiàn)49缺陷成本50軟件測試和修復軟件測試和修復是不同意義的行為過程，最能體現(xiàn)修復行為的是調(diào)試和修正。經(jīng)過測試發(fā)現(xiàn)錯誤后，往往不能直覺從測試結果中找到錯誤的根源，這就需要充分利用測試結果和測試過程中提供的信息進行全面分析，通過調(diào)試發(fā)現(xiàn)錯誤，并修正這些發(fā)現(xiàn)的錯誤。

51第一類標準：測試超過了預定時間，則停止測試。這類標準不能用來衡量測試質(zhì)量。第二類標準：執(zhí)行了所有的測試用例，但并沒有發(fā)現(xiàn)故障，則停止測試。第三類標準：使用特定的測試用例設計方案作為判斷測試停止的基礎。第四類標準：正面指出停止測試的具體要求。第五類標準：根據(jù)單位時間內(nèi)查出故障的數(shù)量決定是否停止測試。

測試停止的依據(jù)（標準）52軟件測試的原則（1）所有測試的標準都是建立在用戶需求之上。軟件測試必須基于“質(zhì)量第一”的思想去開展各項工作，當時間和質(zhì)量沖突時，時間要服從質(zhì)量。事先定義好產(chǎn)品的質(zhì)量標準，只有有了質(zhì)量標準，才能根據(jù)測試的結果，對產(chǎn)品的質(zhì)量進行分析和評估。軟件項目一啟動，軟件測試也就是開始，而不是等程序?qū)懲辏砰_始進行測試。窮舉測試是不可能的。甚至一個大小適度的程序，其路徑排列的數(shù)量也非常大，因此，在測試中不可能運行路徑的每一種組合。

53軟件測試的原則（2）第三方進行測試會更客觀，更有效。軟件測試計劃是做好軟件測試工作的前提。測試用例是設計出來的，不是寫出來的，所以要根據(jù)測試的目的，采用相應的方法去設計測試用例，從而提高測試的效率，更多地發(fā)現(xiàn)錯誤，提高程序的可靠性。對發(fā)現(xiàn)錯誤較多的程序段，應進行更深入的測試。一般來說，一段程序中已發(fā)現(xiàn)的錯誤數(shù)越多，其中存在的錯誤概率也就越大。重視文檔，妥善保存一切測試過程文檔（測試計劃、測試用例、測試報告等）54軟件測試的注意事項應當把“盡早和不斷地測試”作為測試人員的座右銘回歸測試的關聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現(xiàn)的現(xiàn)象并不少見測試應從“小規(guī)?！遍_始，逐步轉(zhuǎn)向“大規(guī)?！?。不可將測試用例置之度外，排除隨意性。必須徹底檢查每一個測試結果。一定要注意測試中的錯誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習慣有很大的關系對測試錯誤結果一定要有一個確認的過程。55軟件測試誤區(qū)

誤區(qū)一：如果發(fā)布出去的軟件有質(zhì)量問題，都是軟件測試人員的錯誤區(qū)二：軟件測試技術要求不高，至少比編程容易多了誤區(qū)三：有時間就多測試一些，來不及就少測試一些誤區(qū)四：軟件測試是測試人員的事，與開發(fā)人員無關誤區(qū)五：根據(jù)軟件開發(fā)瀑布模型，軟件測試是開發(fā)后期的一個階段56軟件測試學科發(fā)展從測試的思想導向來劃分為4個階段:1957～1978年，以功能驗證為導向，測試是證明軟件是正確的（正向思維）。

1978～1983年，以破壞性為為導向，測試是為了找到軟件中的錯誤（逆向思維）。

1983～1987年，以質(zhì)量評估為導向，測試是提供產(chǎn)品的評估和質(zhì)量度量。

1988年起，以缺陷預防為導向，測試是為了展示軟件符合設計要求，發(fā)現(xiàn)缺陷、預防缺陷。57更好的階段劃分….分為3個階段——初期階段、發(fā)展階段和成熟階段初級階段（1957～1971）測試通常被認為是對產(chǎn)品進行事后檢驗，缺乏有效的測試方法發(fā)展階段（1972～1982），1972年第一次關于軟件測試的正式會議，促進了軟件測試的發(fā)展成熟階段（1983到現(xiàn)在），國際標準Std829-1983，形成一門獨立的學科和專業(yè)，成為軟件工程學科中的一個重要組成部分

581.3軟件測試的重要性1.3.1軟件所帶來的悲劇1.3.2其他一些例子1.3.3測試是軟件開發(fā)重要環(huán)節(jié)之一59千年蟲

(Y2K)在上個世紀70年代，程序員為了節(jié)約非常寶貴的內(nèi)存資源和硬盤空間，在存儲日期時，只保留年份的后兩位，如“1980”被存為“80”。當2000年到來的時候，問題就會出現(xiàn)，比如銀行存款程序在計算利息時，應該用現(xiàn)在的日期“2000年1月1日”減去當時存款的日期，比如“1989年1月1日”，結果應該是11年，如果利息是3%，銀行要付給顧客每100元，大約56元利息。如果程序沒有糾正年份只存儲兩位的問題，其存款年數(shù)就變?yōu)?89年，變成顧客反要付銀行1288元的巨額利息，就是為了這樣一個簡單的設計缺陷，全世界付出幾十億美元。

60奔騰芯片缺陷

(4195835/3145727)*3145727–41958350$450million=4.5億美元損失.

61其他一些例子軟件風暴召回淘寶手機軟件事件

………….62終極目標滿足客戶要求,保證軟件質(zhì)量。63軟件質(zhì)量的內(nèi)涵

軟件質(zhì)量是客戶滿意度的體現(xiàn)客戶+

質(zhì)+量?64軟件質(zhì)量范圍-3AAccountability

(可說明性)–用戶可以基于產(chǎn)品或服務的描述和定義進行使用.

(例如:

市場需求說明書,功能設計說明書.)Availability(有效性)–產(chǎn)品或服務對于99.999%客戶總是有效的(例如:性能測試和恢復測試)Accessibility(易用性)–對于用戶,產(chǎn)品或服務非常容易使用并且一定是非常有用的功能.(例如:確認測試和用戶可用性測試)

65高質(zhì)量的軟件應該是相對的無產(chǎn)品缺陷(BugFree)或只有極少量的缺陷,它能夠準時遞交給用戶并且所用的費用都是在預算內(nèi)的并且滿足客戶需求，是可維護的。但是,有關質(zhì)量的好壞最終評價依賴于用戶的反饋?！翱蛻簟睆V義定義

:內(nèi)在的定義:下一個環(huán)節(jié)/工序的接收者，更廣的服務的對象，周圍有任何聯(lián)系或影響的團隊、人。

-廣泛的定義:最終用戶，客戶管理。66軟件質(zhì)量不同的視點

先驗論觀點：質(zhì)量是產(chǎn)品一種可以認識但不可定義的性質(zhì)

用戶觀點：質(zhì)量是產(chǎn)品滿足使用目的之程度;

制造者的觀點：質(zhì)量是產(chǎn)品性能和規(guī)格要求的符合度

產(chǎn)品觀點：質(zhì)量是聯(lián)結產(chǎn)品固有性能的紐帶;

基于價值觀點：質(zhì)量依賴于顧客愿意付給產(chǎn)品報酬的數(shù)量67產(chǎn)品質(zhì)量的標準-功能性Functionality-可用性Usability(簡單安裝;輕松使用;友好界面)-可靠性Reliability(用戶使用的根本)-性能Performance-容量Capacity-可測量性Scalability-可維護性Servicemanageability-兼容性Compatibility-可擴展性

Extensibility68軟件質(zhì)量特征(ISO9126)

功能：與一組功能及其指定性質(zhì)有關的一組屬性，這里的功能是滿足明確或隱含的需求的那些功能。

可靠：在規(guī)定的一段時間和條件下，與軟件維持其性能水平的能力有關的一組屬性。

易用：由一組規(guī)定或潛在的用戶為使用軟件所需作的努力和所作的評價有關的一組屬性。

效率：與在規(guī)定條件下軟件的性能水平與所使用資源量之間關系有關的一組屬性。

可維護：與進行指定的修改所需的努力有關的一組屬性。

可移植：與軟件從一個環(huán)境轉(zhuǎn)移到另一個環(huán)境的能力有關的一組屬性。

其中每一個質(zhì)量特征都分別與若干子特征相對應。69軟件過程質(zhì)量軟件能力成熟度模型CMM(CapabilityMaturityModel).國際標準過程模型ISO9000軟件過程改進和能力決斷SPICE(SoftwareProcessImprovementandCapabilitydEtermination)

70質(zhì)量保證的策略主要分三個階段：

以檢測為重：產(chǎn)品制成之后進行檢測，只能判斷產(chǎn)品質(zhì)量，不能提高產(chǎn)品質(zhì)量。

以過程管理為重：把質(zhì)量的保證工作重點放在過程管理上，對制造過程中的每一道工序都要進行質(zhì)量控制。

以新產(chǎn)品開發(fā)為重：在新產(chǎn)品的開發(fā)設計階段，采取強有力的措施來消滅由于設計原因而產(chǎn)生的質(zhì)量隱患。71質(zhì)量管理發(fā)展五個階段1900手工操作者專職檢驗員1920過程統(tǒng)計技術1931全面質(zhì)量管理1960以顧客為中心階段時間2000721.4軟件測試的分類

黑盒測試和白盒測試（測試用例設計方法）靜態(tài)測試和動態(tài)測試（執(zhí)行程序）單元測試、集成測試、系統(tǒng)測試、驗收測試和確認測試（策略和過程）73靜態(tài)與動態(tài)按照是否需要執(zhí)行程序，軟件測試可劃分為靜態(tài)測試和動態(tài)測試靜態(tài)測試：并不真正運行被測試程序，只是進行特征分析動態(tài)測試：通過選擇適當?shù)臏y試用例，實際運行所測程序，比較實際運行結果和預期結果，以找出錯誤。

74靜態(tài)測試主要是對軟件的編程格式、結構等方面進行評估。靜態(tài)測試包括代碼檢查、靜態(tài)結構分析、代碼質(zhì)量度量等。它可以由人工進行，也可以借助軟件工具自動進行。靜態(tài)測試方法也可利用計算機作為對被測程序進行特性分析的工具，但與人工測試方式有著根本區(qū)別。另一方面，因它并不真正運行被測程序，只進行特性分析，這又與動態(tài)方法不同。所以，靜態(tài)方法常常稱為“分析”，靜態(tài)測試是對被測程序進行特性分析方法的總稱。靜態(tài)測試75代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結構的合理性等方面。代碼檢查的具體內(nèi)容：變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等。代碼檢查的優(yōu)點：在實際使用中，代碼檢查比動態(tài)測試更有效率，能快速找到缺陷，發(fā)現(xiàn)30%～70%的邏輯設計和編碼缺陷；代碼檢查看到的是問題本身而非征兆。代碼檢查的缺點：非常耗費時間，而且代碼檢查需要知識和經(jīng)驗的積累。代碼檢查76

靜態(tài)結構分析主要是以圖形的方式表現(xiàn)程序的內(nèi)部結構。例如函數(shù)調(diào)用關系圖、函數(shù)內(nèi)部控制流圖。其中：

——函數(shù)調(diào)用關系圖以直觀的圖形方式描述一個應用程序中各個函數(shù)的調(diào)用和被調(diào)用關系；

——控制流圖顯示一個函數(shù)的邏輯結構，由許多節(jié)點組成，一個節(jié)點代表一條語句或數(shù)條語句，連接結點的叫邊，邊表示節(jié)點間的控制流向。靜態(tài)結構分析77軟件質(zhì)量包括六個方面：功能性、可靠性、易用性、效率、可維護性和可移植性。軟件的質(zhì)量是軟件屬性的各種標準度量的組合。代碼質(zhì)量度量78（1）檢查算法的邏輯正確性。（2）檢查模塊接口的正確性。（3）檢查輸入?yún)?shù)是否有合法性檢查。（4）檢查調(diào)用其他模塊的接口是否正確。（5）檢查是否設置了適當?shù)某鲥e處理。（6）檢查表達式、語句是否正確，是否含有二義性。（7）檢查常量或全局變量使用是否正確。（8）檢查標識符的使用是否規(guī)范、一致。（9）檢查程序風格的一致性、規(guī)范性。（10）檢查代碼是否可以優(yōu)化，算法效率是否最高。（11）檢查代碼注釋是否完整，是否正確反映了代碼的功能。靜態(tài)測試階段的任務79（1）發(fā)現(xiàn)下列程序的錯誤：錯用局部變量和全局變量；未定義的變量、不匹配的參數(shù)；不適當?shù)难h(huán)嵌套或分支嵌套、死循環(huán)、不允許的遞歸；調(diào)用不存在的子程序，遺漏標號或代碼。（2）找出以下問題的根源：從未使用過的變量；不會執(zhí)行到的代碼、從未使用過的標號；潛在的死循環(huán)。（3）提供程序缺陷的間接信息：所用變量和常量的交叉應用表；是否違背編碼規(guī)則；標識符的使用方法和過程的調(diào)用層次。（4）為進一步查找做好準備。（5）選擇測試用例。（6）進行符號測試。靜態(tài)測試可以完成以下工作：80動態(tài)方法的主要特征是：

——計算機必須真正運行被測試的程序，通過輸入測試用例，對其運行情況即輸入與輸出的對應關系進行分析，以達到檢測的目的。動態(tài)測試包括：（1）功能確認與接口測試（2）覆蓋率分析（3）性能分析（4）內(nèi)存分析動態(tài)測試81黑盒和白盒功能測試數(shù)據(jù)驅(qū)動測試結構測試邏輯驅(qū)動測試

客戶需求事件驅(qū)動輸入輸出82若測試規(guī)劃是基于產(chǎn)品的功能，目的是檢查程序各個功能是否能夠?qū)崿F(xiàn)，并檢查其中的功能錯誤，則這種測試方法稱為黑盒測試(Black-boxTesting)方法。

——黑盒測試又稱為功能測試、數(shù)據(jù)驅(qū)動測試和基于規(guī)格說明的測試。它是一種從用戶觀點出發(fā)的測試，一般被用來確認軟件功能的正確性和可操作性。若測試規(guī)劃基于產(chǎn)品的內(nèi)部結構進行測試，檢查內(nèi)部操作是否按規(guī)定執(zhí)行，軟件各個部分功能是否得到充分使用，則這種測試方法稱為白盒測試(White-boxTesting)方法。

——白盒測試又稱為結構測試、邏輯驅(qū)動測試或基于程序的測試，一般用來分析程序的內(nèi)部結構。

黑盒和白盒83白盒測試黑盒測試兩種測試方法從完全不同的角度出發(fā)，反映了測試思路的兩方面情況，適用于不同的測試階段。黑盒和白盒84黑盒測試的基本觀點是：任何程序都可以看作是從輸入定義域映射到輸出值域的函數(shù)過程，被測程序被認為是一個打不開的黑盒子，黑盒中的內(nèi)容（實現(xiàn)過程）完全不知道，只明確要做到什么。黑盒測試主要根據(jù)規(guī)格說明書設計測試用例，并不涉及程序內(nèi)部構造和內(nèi)部特性，只依靠被測程序輸入和輸出之間的關系或程序的功能設計測試用例。黑盒測試的特點：（1）黑盒測試與軟件的具體實現(xiàn)過程無關，在軟件實現(xiàn)的過程發(fā)生變化時，測試用例仍然可以使用。（2）黑盒測試用例的設計可以和軟件實現(xiàn)同時進行，這樣能夠壓縮總的開發(fā)時間。黑盒測試85輸入輸出黑盒測試是在程序接口進行測試，它只是檢查程序功能是否按照規(guī)格說明書的規(guī)定正常使用。也被稱為用戶測試。黑盒測試86黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤：是否有不正確或遺漏了的功能？在接口上，輸入能否正確地接受？能否輸出正確的結果？是否有數(shù)據(jù)結構錯誤或外部信息訪問錯誤？性能上是否能夠滿足要求？是否有初始化或終止性錯誤？黑盒測試的難點：在哪個層次上進行測試？黑盒測試的具體技術方法：邊界值分析法等價類劃分法因果圖法決策表法黑盒測試87白盒測試將被測程序看作一個打開的盒子，測試者能夠看到被測源程序，可以分析被測程序的內(nèi)部結構，此時測試的焦點集中在根據(jù)其內(nèi)部結構設計測試用例。白盒測試要求是對某些程序的結構特性做到一定程度的覆蓋，或者說這種測試是“基于覆蓋率的測試”。通常的程序結構覆蓋有：語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋路徑覆蓋白盒測試88白盒測試需要完全了解程序結構和處理過程，它按照程序內(nèi)部邏輯測試程序，檢驗程序中每條通路是否按預定要求正確工作。也被稱為程序員測試。應用程序白盒測試89？X=2

y=2xY=4X=2Y=4未知等式與已知等式黑盒白盒黑盒與白盒測試的比較90黑盒測試：

——以用戶的觀點，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應關系，即根據(jù)程序外部特性進行測試，而不考慮內(nèi)部結構及工作情況。

——黑盒測試技術注重于軟件的信息域（范圍），通過劃分程序的輸入和輸出域來確定測試用例。

——若外部特性本身存在問題或規(guī)格說明的規(guī)定有誤，則應用黑盒測試方法是不能發(fā)現(xiàn)問題的。白盒測試：

——只根據(jù)程序的內(nèi)部結構進行測試。

——測試用例的設計要保證測試時程序的所有語句至少執(zhí)行一次，而且要檢查所有的邏輯條件。

——如果程序的結構本身有問題，比如說程序邏輯有錯誤或者有遺漏，那也是無法發(fā)現(xiàn)的。黑盒與白盒測試的比較91項目黑盒測試法白盒測試法規(guī)劃方面功能的測試結構的測試優(yōu)點方面能確保從用戶的角度出發(fā)進行測試能對程序內(nèi)部的特定部位進行覆蓋測試缺點方面無法測試程序內(nèi)部特定部位；當規(guī)格說明有誤，則不能發(fā)現(xiàn)問題無法檢查程序的外部特性；無法對未實現(xiàn)規(guī)格說明的程序內(nèi)部欠缺部分進行測試應用范圍邊界分析法等價類劃分法決策表測試語句覆蓋，判定覆蓋，條件覆蓋，判定/條件覆蓋，路徑覆蓋，循環(huán)覆蓋，模塊接口測試黑盒與白盒測試的比較92按軟件測試過程劃分：單元測試集成測試確認（有效性）測試系統(tǒng)測試驗收（用戶）測試93單元測試單元測試的對象是程序系統(tǒng)中的最小單元---模塊或組件上，在編碼階段進行，針對每個模塊進行測試，主要通過白盒測試方法，從程序的內(nèi)部結構出發(fā)設計測試用例，檢查程序模塊或組件的已實現(xiàn)的功能與定義的功能是否一致、以及編碼中是否存在錯誤。多個模塊可以平行地、對立地測試，通常要編寫驅(qū)動模塊和樁模塊。單元測試一般由編程人員和測試人員共同完成。

94單元測試針對每個程序的模塊，主要測試5個方面的問題：

——模塊接口、局部數(shù)據(jù)結構、邊界條件、獨立的路徑和錯誤處理。模塊模塊接口局部數(shù)據(jù)結構路徑測試出錯處理邊界條件單元測試的主要任務95這是對模塊接口進行的測試，檢查進出程序單元的數(shù)據(jù)流是否正確。模塊接口測試必須在任何其它測試之前進行。模塊接口測試至少需要如下的測試項目：（1）調(diào)用所測模塊時的輸入?yún)?shù)與模塊的形式參數(shù)在個數(shù)、屬性、順序上是否匹配；（2）所測模塊調(diào)用子模塊時，它輸入給子模塊的參數(shù)與子模塊中的形式參數(shù)在個數(shù)、屬性、順序上是否匹配；（3）是否修改了只做輸入用的形式參數(shù)；（4）調(diào)用標準函數(shù)的參數(shù)在個數(shù)、屬性、順序上是否正確；（5）全局變量的定義在各模塊中是否一致。模塊接口96在模塊工作過程中，必須測試模塊內(nèi)部的數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關系不發(fā)生錯誤。對于局部數(shù)據(jù)結構，應該在單元測試中注意發(fā)現(xiàn)以下幾類錯誤：（1）不正確的或不一致的類型說明。（2）錯誤的初始化或默認值。（3）錯誤的變量名，如拼寫錯誤或書寫錯誤。（4）下溢、上溢或者地址錯誤。局部數(shù)據(jù)結構97在單元測試中，最主要的測試是針對路徑的測試?；韭窂綔y試法是在程序控制流圖的基礎上，通過分析控制構造的環(huán)路復雜性，導出基本可執(zhí)行路徑集合，從而設計測試用例的方法。設計出的測試用例要保證在測試中程序的每個可執(zhí)行語句至少執(zhí)行一次。測試用例必須能夠發(fā)現(xiàn)由于計算錯誤、不正確的判定或不正常的控制流而產(chǎn)生的錯誤。常見的錯誤有：誤解的或不正確的算術優(yōu)先級；混合模式的運算；錯誤的初始化；精確度不夠精確；表達式的不正確符號表示。針對判定和條件覆蓋，測試用例還要能夠發(fā)現(xiàn)如下錯誤：不同數(shù)據(jù)類型的比較；不正確的邏輯操作或優(yōu)先級；應當相等的地方由于精確度的錯誤而不能相等；不正確的判定或不正確的變量；不正確的或不存在的循環(huán)終止；當遇到分支循環(huán)時不能退出；不適當?shù)匦薷难h(huán)變量。路徑測試98邊界測試是單元測試的最后一步，必須采用邊界值分析方法來設計測試用例，認真仔細地測試為限制數(shù)據(jù)處理而設置的邊界處，看模塊是否能夠正常工作。一些可能與邊界有關的數(shù)據(jù)類型如數(shù)值、字符、位置、數(shù)量、尺寸等，還要注意這些邊界的首個、最后一個、最大值、最小值、最長、最短、最高、最低等特征。在邊界條件測試中，應設計測試用例檢查以下情況：（1）在n次循環(huán)的第0次、1次、n次是否有錯誤。（2）運算或判斷中取最大值、最小值時是否有錯誤。（3）數(shù)據(jù)流、控制流中剛好等于、大于、小于確定的比較值是否出現(xiàn)錯誤。邊界條件99測試出錯處理的重點