Ch1-軟件測(cè)試基礎(chǔ)知識(shí)

軟件測(cè)試方法和技術(shù)

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

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

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

4人力市場(chǎng)的測(cè)試人員位置

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

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

有效的測(cè)試策略、方法和技術(shù)測(cè)試計(jì)劃和測(cè)試用例的設(shè)計(jì)測(cè)試自動(dòng)化的引入、應(yīng)用測(cè)試團(tuán)隊(duì)的建立和測(cè)試項(xiàng)目的管理更清楚、準(zhǔn)確地報(bào)告測(cè)試缺陷對(duì)軟件產(chǎn)品質(zhì)量的正確評(píng)估軟件測(cè)試和質(zhì)量保證的關(guān)系和區(qū)別

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

QAEngineer/Manager

軟件工程過程組成員ThememberofSEPG

項(xiàng)目經(jīng)理Projectmanager

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

幫助文件Helpfiles

示例Samplesandexamplestoillustratepoints

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

錯(cuò)誤信息Errormessages

安裝手冊(cè)Setupandinstallationinstructions

用戶手冊(cè)Usermanual(s)

產(chǎn)品標(biāo)簽Labelandstickers

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

軟件是硬件的靈魂，硬件是軟件的基礎(chǔ)軟件，是智慧和知識(shí)的結(jié)晶軟件不會(huì)“磨損”，而是逐步完善

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

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

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

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

將設(shè)計(jì)轉(zhuǎn)換成計(jì)算機(jī)可讀的形式。測(cè)試:

對(duì)設(shè)計(jì)、編程進(jìn)行驗(yàn)證和用戶需求確認(rèn)的過程維護(hù)：維持軟件運(yùn)行，修改軟件缺陷、增強(qiáng)已有功能、增加新功能、升級(jí)等。23軟件開發(fā)過程模型

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

24

瀑布過程模型反映了人們?cè)缙趯?duì)軟件工程的認(rèn)識(shí)水平，是人們所熟悉的一種線性思維的體現(xiàn)。瀑布過程模型強(qiáng)調(diào)階段的劃分及其順序性、各階段工作及其文檔的完備性，是一種嚴(yán)格線性的、按階段順序的、逐步細(xì)化的開發(fā)模式。

瀑布模型2526

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

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

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

敏捷開發(fā)（AgileDevelopment）

“極限編程”(eXtremeProgramming

泛型編程（GenericProgramming）

面向方面的編程（AspectOrientedProgramming，簡(jiǎn)稱AOP）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1978～1983年，以破壞性為為導(dǎo)向，測(cè)試是為了找到軟件中的錯(cuò)誤（逆向思維）。

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

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

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

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

60奔騰芯片缺陷

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

61其他一些例子軟件風(fēng)暴召回淘寶手機(jī)軟件事件

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

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

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

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

(例如:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

可維護(hù)：與進(jìn)行指定的修改所需的努力有關(guān)的一組屬性。

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

其中每一個(gè)質(zhì)量特征都分別與若干子特征相對(duì)應(yīng)。69軟件過程質(zhì)量軟件能力成熟度模型CMM(CapabilityMaturityModel).國(guó)際標(biāo)準(zhǔn)過程模型ISO9000軟件過程改進(jìn)和能力決斷SPICE(SoftwareProcessImprovementandCapabilitydEtermination)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

——以用戶的觀點(diǎn)，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對(duì)應(yīng)關(guān)系，即根據(jù)程序外部特性進(jìn)行測(cè)試，而不考慮內(nèi)部結(jié)構(gòu)及工作情況。

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

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

——只根據(jù)程序的內(nèi)部結(jié)構(gòu)進(jìn)行測(cè)試。

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

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

94單元測(cè)試針對(duì)每個(gè)程序的模塊，主要測(cè)試5個(gè)方面的問題：

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