第一章軟件測試基本理論掌握軟件測試的概念，重點圍繞軟件測試的狹義定義和廣義定義展開；

了解軟件測試的目的，理解軟件測試的原則；

了解軟件測試的過程；

軟件測試和軟件開發(fā)的關(guān)系。本章要點1.1軟件測試的概念

1.2軟件測試的目的

1.3軟件測試的原則

1.4軟件測試的過程

1.5軟件測試與軟件開發(fā)的關(guān)系

目

錄1.1軟件測試的概念軟件測試就是在軟件投入運行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼實現(xiàn)的最終審查，它是軟件質(zhì)量保證的關(guān)鍵步驟。通常對軟件測試的定義有兩種描述：定義1：軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。定義2：軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計的一批測試用例，并利用這些測試用例運行程序以發(fā)現(xiàn)錯誤的過程。廣義的軟件測試是由確認、驗證、測試三個方面組成。確認：評估將要開發(fā)的軟件產(chǎn)品是否是正確無誤、可行和有價值的。這里包含了對用戶需求滿足程度的評價，意味著確保一個待開發(fā)軟件是正確無誤的，是對軟件開發(fā)構(gòu)想的檢測。驗證：檢測軟件開發(fā)的每個階段、每個步驟的結(jié)果是否正確無誤，是否與軟件開發(fā)各階段的要求或期望的結(jié)果相一致。驗證意味著確保軟件正確無誤地實現(xiàn)軟件的需求。測試：與狹隘的測試概念統(tǒng)一。通常是經(jīng)過單元測試、集成測試、確認測試和系統(tǒng)測試四個環(huán)節(jié)。1.2軟件測試的目的軟件測試的目的是為了發(fā)現(xiàn)盡可能多的缺陷。具體來說，應(yīng)有以下目標：測試是通過在計算機上執(zhí)行程序，暴露程序中潛在的錯誤的過程。一個好的測試用例能夠發(fā)現(xiàn)至今尚未發(fā)現(xiàn)的錯誤，最終消除軟件故障，保證程序的可靠運行。測試的目標是為了用最少的時間與工作量盡可能地找出軟件中存在的錯誤與缺陷，而且測試只能證明缺陷存在，而不能證明缺陷不存在。1.3軟件測試的原則軟件測試過程中，我們應(yīng)注意和遵循一系列的具體原則，在ISTQB軟件測試基礎(chǔ)認證大綱上，列出7項原則，但其中最后一項原則“不存在缺陷（就是有用系統(tǒng)）”的謬論不能算是一項合格的原則，所以可以認可的原則是6項。除此之外，在這里結(jié)合實際的測試經(jīng)歷，還列出比較重要的7項原則，合起來共13項原則。ISTQB的6項原則

（1）測試顯示缺陷不存在，但不能證明系統(tǒng)不存在缺陷。（2）窮盡測試是不可能的。（3）測試盡早介入。（4）缺陷集群性。（5）殺蟲劑悖論。（6）測試活動依賴于測試背景。其他重要的7項原則

（1）持續(xù)地測試、持續(xù)地反饋。（2）80/20原則。（3）建立清晰的階段性目標。（4）測試獨立性。（5）確保可測試性。（6）計劃是一個過程。（7）一切從用戶角度出發(fā)。1.4軟件測試的過程軟件測試過程按測試的先后順序可分為單元測試、集成測試、確認測試、系統(tǒng)測試、驗收測試。軟件測試過程流程如圖所示。圖1-1軟件測試過程流圖1.4軟件測試與軟件開發(fā)的關(guān)系

軟件開發(fā)與軟件測試都是軟件項目中非常重要的組成部分，軟件開發(fā)是生產(chǎn)制造軟件產(chǎn)品，軟件測試是檢驗軟件產(chǎn)品是否合格，兩者密切合作才能保證軟件產(chǎn)品的質(zhì)量。軟件中出現(xiàn)的問題并不是由編碼引起的，軟件在編碼之前都會經(jīng)過問題定義、需求分析、軟件設(shè)計等階段，軟件中的問題也可能是前期階段引起的，如需求不清晰、軟件設(shè)計有紕漏等，因此在軟件項目的各個階段進行測試是非常有必要的。測試人員從軟件項目規(guī)劃開始就參與其中，了解整個項目的過程，及時查找軟件中存在的問題，改善軟件的質(zhì)量。軟件測試在項目各個階段的作用如下所示：項目規(guī)劃階段：負責(zé)從單元測試到系統(tǒng)測試的整個測試階段的監(jiān)控。需求分析階段：確定測試需求分析，即確定在項目中需要測試什么，同時制訂系統(tǒng)測試計劃。概要設(shè)計與詳細設(shè)計階段：制訂單元測試計劃和集成測試計劃。編碼階段：開發(fā)相應(yīng)的測試代碼和測試腳本。測試階段：實施測試并提交相應(yīng)的測試報告。軟件測試是貫穿于整個軟件開發(fā)的過程。在軟件開發(fā)的各個階段，測試人員必須制訂本階段的測試方案，把軟件開發(fā)和測試活動集成到一起，如圖所示。圖1-2V模型的動態(tài)過程

本章首先從軟件測試概念、目的、原則和過程方面講解軟件測試，然后講解軟件測試與軟件開發(fā)的關(guān)系，重點講解軟件測試在軟件開發(fā)各階段的作用。本章要點第二章軟件質(zhì)量與軟件測試了解軟件質(zhì)量的基本概念，重點圍繞軟件質(zhì)量的定義和模型展開；

熟悉軟件質(zhì)量工程體系概念，理解軟件質(zhì)量工程體系CM模型；

了解軟件質(zhì)量的六個要素。本章要點

目

錄2.1軟件質(zhì)量定義

2.2軟件質(zhì)量模型

2.3軟件質(zhì)量工程體系

2.4軟件質(zhì)量度量

2.5軟件質(zhì)量標準體系2.1軟件質(zhì)量的定義概括地說，軟件質(zhì)量就是“軟件產(chǎn)品滿足用戶或規(guī)定顯性需求或隱性需求的程度”。具體地說，軟件質(zhì)量是軟件符合明確敘述的功能和性能需求、文檔中明確描述的開發(fā)標準以及所有專業(yè)開發(fā)的軟件都應(yīng)具有的隱含特征的程度，包括內(nèi)部質(zhì)量、過程質(zhì)量、外部質(zhì)量和使用質(zhì)量。軟件質(zhì)量定義強調(diào)以下三點：軟件需求是度量軟件質(zhì)量的基礎(chǔ)，與需求不一致意味著軟件質(zhì)量不高。制定的標準定義了一組指導(dǎo)軟件開發(fā)的準則，如果沒有遵守這些準則，幾乎肯定會導(dǎo)致質(zhì)量不高。通常有一組沒有展示的隱含性需求（如期望軟件容易維護）。如果軟件滿足明確描述的需求，但不滿足隱含的需求，那么軟件的質(zhì)量仍然值得懷疑。2.2軟件質(zhì)量模型早在1976年，由Boehm等人提出軟件質(zhì)量模型的分層方案。1979年，McCall等人改進Boehm質(zhì)量模型后又提出了一種軟件質(zhì)量模型。軟件質(zhì)量模型中的質(zhì)量概念基于11個特性，而這11個特性分別對應(yīng)軟件產(chǎn)品的運行、修正、轉(zhuǎn)移。McCall等人認為，特性是軟件質(zhì)量的反映，軟件屬性可用做評價準則，定量化地度量軟件屬性可知軟件質(zhì)量的優(yōu)劣。McCall等人的質(zhì)量特性屬性包括:正確性、可靠性、效率、完整性、可用性、可維護性、可測試性、靈活性、可移植性、可重用性、互聯(lián)性。2.3軟件質(zhì)量工程體系軟件質(zhì)量控制是一組由開發(fā)組織使用的程序和方法，使用它可在規(guī)定的資金投入和時間限制的條件下，提供滿足客戶質(zhì)量要求的軟件產(chǎn)品，并持續(xù)不斷地改善開發(fā)過程和開發(fā)組織本身，以提高將來生產(chǎn)高質(zhì)量軟件產(chǎn)品的能力。根據(jù)這個定義，我們可以看到：軟件質(zhì)量控制是開發(fā)組織執(zhí)行的一系列過程。軟件質(zhì)量控制的目標是以最低的代價獲得客戶滿意的軟件產(chǎn)品。對于開發(fā)組織本身來說軟件質(zhì)量控制的另一個目標是從每一次開發(fā)過程中學(xué)習(xí)，以便使軟件質(zhì)量控制一次比一次更好。2.3.1軟件質(zhì)量工程體系概念基于PDCA（即是計劃Plan、實施Do、檢查Check、處理Act四個詞英文前綴的縮寫）的全面統(tǒng)計質(zhì)量控制（TotalStatisticalQualityControl，TSQC，全面統(tǒng)計質(zhì)量控制）模型，是我國實際采用的模型之一，基于PDCA的全面統(tǒng)計質(zhì)量控制模型圖如圖所示。2.3.2軟件質(zhì)量工程體系模型圖2-1基于PDCA的全面統(tǒng)計質(zhì)量控制模型圖軟件質(zhì)量保證（SoftwareQualityAssure，SQA）是建立一套有計劃、有系統(tǒng)的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用。軟件質(zhì)量保證的目的是使軟件過程對于管理人員來說是可見的。由于軟件質(zhì)量保證（SQA）是CMM（軟件能力成熟度）2級中的一個重要關(guān)鍵過程部分，它是貫穿于整個軟件過程的第三方獨立審查活動，在CMM的過程中充當(dāng)重要角色。SQA的目的是向管理者提供對軟件過程進行全面監(jiān)控的手段，包括評審和審計軟件產(chǎn)品和活動，驗證它們是否符合相應(yīng)的規(guī)程和標準，同時向項目管理者提供這些評審和審計的結(jié)果。2.3.3軟件質(zhì)量保證體系2.4軟件質(zhì)量度量軟件業(yè)通過多年的實踐，總結(jié)出軟件質(zhì)量是人、過程和技術(shù)的函數(shù)，即Q={M，P，T}。其中，Q表示軟件質(zhì)量，M表示人，P表示過程，T表示技術(shù)。影響軟件質(zhì)量因素圖如圖所示。圖2-2軟件質(zhì)量影響因素圖2.4軟件質(zhì)量度量要進行軟件質(zhì)量評估，必須具備如下前提:目標質(zhì)量有足夠清晰明確的描述。合適的評估手段。常見的幾種軟件質(zhì)量保證模型有：McCall模型、Boehm模型、FURPS模型、ISO9126。

2.4軟件質(zhì)量度量McCall模型圖2-3McCall模型圖McCall定義了一些評價準則，這些準則可對反映質(zhì)量特性的軟件屬性進行分級，并以此來估計軟件質(zhì)量特性的值。軟件屬性一般分級范圍是從0（最低）到10（最高）。主要評價準則有可跟蹤性、完備性、一致性、安全性、容錯性、準確性、可審查性、可操作性、可訓(xùn)練性、簡潔性、模塊性、自描述性、通用性、可擴展性、硬件獨立性、通信共用性和數(shù)據(jù)共用性2.5軟件質(zhì)量標準體系2.5.1軟件質(zhì)量標準概述經(jīng)過數(shù)十年的發(fā)展，軟件行業(yè)形成的標準分工細，體系繁多。根據(jù)軟件工程標準制定機構(gòu)的類別和標準適用的范圍，將軟件質(zhì)量標準分為5個級別，即國際標準、國家標準、行業(yè)標準、企業(yè)標準和項目規(guī)范。很多標準的原始狀態(tài)可能是項目標準或企業(yè)標準，但隨著行業(yè)發(fā)展與推進，它的權(quán)威性可能促使它發(fā)展成為行業(yè)、國家或國際標準，因此這里所說的層次具有一定的相對性。2.5.2能力成熟模型能力成熟度模型（CapabilityMaturityModelforSoftware，英文縮寫為SW-CMM，簡稱CMM），是對于軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發(fā)展階段的描述。在美國國防部的指導(dǎo)下，由軟件開發(fā)團體和軟件工程學(xué)院（SEI）及CarnegieMellon大學(xué)共同開發(fā)的。CMM的核心是把軟件開發(fā)視為一個過程，并根據(jù)這一原則對軟件開發(fā)和維護進行過程監(jiān)控和研究，以使其更加科學(xué)化、標準化、使企業(yè)能夠更好地實現(xiàn)商業(yè)目標。2.5.3軟件質(zhì)量標準與全面質(zhì)量管理美國的B.W.Boehm和R.Brown先后提出了三層次的評價度量模型：軟件質(zhì)量要素、準則、度量。隨后G.Mruine提出了自己的軟件質(zhì)量度量SQM技術(shù)，波音公司在軟件開發(fā)過程中采用了SQM技術(shù)，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在成本控制和進度安排方面取得了良好的效果。第一層是軟件質(zhì)量要素，軟件質(zhì)量可分解成六個要素，這六個要素是軟件的基本特征：功能性、可靠性、易用性、效率性、可維護性、可移植性。

本章首先從軟件質(zhì)量定義和模型方面講解軟件質(zhì)量，然后詳細講解軟件質(zhì)量工程體系，最后重點講解軟件質(zhì)量度量和軟件質(zhì)量標準體系。本章要點第三章軟件測試的方法了解測試方法的分類；

掌握黑盒和白盒測試方法；

集成測試方法；

理解面向?qū)ο鬁y試方法和自動化測試方法。本章要點3.1軟件測試方法綜述

3.2基于策略和過程的測試

3.3基于源代碼可見性的測試

3.4非功能測試

3.5面向?qū)ο鬁y試

3.6自動化測試目

錄3.1軟件測試方法綜述針對測試策略和過程可以將測試分為：單元測試、集成測試、確認測試、系統(tǒng)測試和驗收測試。針對源代碼可見性可以將測試劃分為：黑盒測試、白盒測試和灰盒測試。針對軟件系統(tǒng)的性能或可用性可從非功能角度將測試劃分為：性能測試、壓力測試、負載測試、低資源測試、容量測試和重復(fù)性測試。針對軟件工程方法學(xué)劃分的角度分為：傳統(tǒng)軟件測試和面向?qū)ο筌浖y試。針對是否運用測試工具測試分為：自動化測試和手工測試。3.2基于策略和過程的測試從策略和過程的角度出發(fā)可以將測試分為：單元測試、集成測試、確認測試、系統(tǒng)測試和驗收測試。3.2.1單元測試單元測試是指，對軟件中的最小可測試單元在與程序其他部分相隔離的情況下，進行檢查和驗證的測試過程。單元測試的主要內(nèi)容包括：模塊接口測試、局部數(shù)據(jù)結(jié)構(gòu)測試、路徑測試、錯誤處理測試、邊界測試等。集成測試階段是對每個模塊進行單元測試后，按照總體設(shè)計時確定的軟件結(jié)構(gòu)圖和一定策略將測試完成的單元連接起來進行的測試，也稱為綜合測試。1.集成測試分為四個階段：計劃、設(shè)計、實現(xiàn)和執(zhí)行階段。2.集成測試的策略：集成測試，按照是否一次性按照軟件結(jié)構(gòu)圖集成最終產(chǎn)品將測試策略分為非漸增式集成策略和漸增式集成策略分別進行測試。而在以漸增式集成為策略的測試中，根據(jù)集成方向?qū)y試分為自頂向下、自底向上和三明治法。每種策略有其適用場景和優(yōu)缺點。3.2.2集成測試（1）非漸增式集成測試策略如圖3-1a所示，主控模塊需要調(diào)用下級模塊A、B、C和D，在集成測試過程中，將每個模塊完成單元測試后，一次性集成，進行集成測試。而在這樣的集成測試過程中，需要兩種模塊輔助完成單元測試，分別是驅(qū)動模塊和樁模塊。驅(qū)動模塊：用以模擬被測模塊的上級模塊。驅(qū)動模塊在集成測試中接受測試數(shù)據(jù)，把相關(guān)的數(shù)據(jù)傳送給被測模塊，用以啟動被測模塊，并輸出相應(yīng)的結(jié)果。如圖3-1b所示，D1、D2、D3、D4為驅(qū)動模塊。樁模塊：也稱為存根程序，用以模擬被測模塊工作過程中所調(diào)用的模塊。樁模塊由被測模塊調(diào)用，它們一般只進行很少的數(shù)據(jù)處理，例如打印入口和返回，以便于檢驗被測模塊與其下級模塊的接口。如圖3-1b所示，S為樁模塊。圖3-1（a）驅(qū)動模塊和樁模塊演示圖3-1（b）驅(qū)動模塊和樁模塊演示（2）增量式集成測試策略增量式集成測試策略主要有：自頂向下集成、自底向上集成、三明治集成；除以上幾種外，還有如下策略：基于功能集成，基于風(fēng)險集成，基于分布式集成等。增量式集成測試是一種按照軟件結(jié)構(gòu)圖運用不同的集成策略逐步集成以及逐步測試的方法。在集成的過程中，隨著不同集成策略的逐步推進，就可能將錯誤分散暴露出來，便于找出問題，并且及時修改，能夠及時發(fā)現(xiàn)錯誤，并且對錯誤進行定位1）自頂向下集成功能分解是集成測試的基礎(chǔ)，軟件結(jié)構(gòu)圖是總體設(shè)計的成果，集成測試是在軟件結(jié)構(gòu)圖的基礎(chǔ)上進行集成。無論是在何種各種集成策略中，每個獨立單元均已經(jīng)完成了單元測試。那么，基于軟件結(jié)構(gòu)圖的集成策略，其目標是測試已通過獨立測試的單元，集成起來后的接口。在集成測試中，集成順序上需要確保編譯正確，并且有可參考的變量取值范圍和單元名稱。自頂向下集成首先要集成主控模塊，然后從軟件控制層次結(jié)構(gòu)出發(fā)，按照由頂層到底層的集成策略進行集成，可以采用深度優(yōu)先或者廣度優(yōu)先進行測試，主要驗證接口的穩(wěn)定性。具體實施過程如下：①確定所有的將要集成在一起的單元已經(jīng)通過了單元測試。②選擇的集成測試的策略，在這里采用深度優(yōu)先的方法。③對主控制軟件單元A進行測試，使用測試用被調(diào)用模擬子模塊S1和S2來代替單元A原本實際所調(diào)用的軟件單元B和C，然后對軟件單元A進行測試，如圖3-3所示。④使用實際的軟件單元B代替中的被調(diào)用模擬子模塊S1，并使用S3代替軟件單元B原本實際所調(diào)用的軟件單元D，然后對集成B后的軟件結(jié)構(gòu)進行測試，在集成的過程中，必須進行回歸測試，如圖3-4所示。圖3-3被調(diào)用模塊S1和S2

圖3-4模塊B代替S1⑤使用實際的軟件單元D代替被調(diào)用模擬子模塊S3，然后對集成D后的軟件結(jié)構(gòu)進行測試，如圖3-5所示。⑥使用實際的軟件單元E代替被調(diào)用模擬子模塊S2，然后對集成C后的軟件結(jié)構(gòu)進行測試，并使用S4代替C模塊的下級調(diào)用子模塊，如圖3-6所示。⑦使用實際的軟件單元E代替被調(diào)用模擬子模塊S4，然后對整個軟件系統(tǒng)進行測試，如圖3-7所示。圖3-5模塊D代替S3圖3-6模塊C代替S2圖3-7模塊E代替S4自頂向下集成優(yōu)點是：

在測試過程中，能夠相對較早地驗證主控模塊和判斷點。在一個功能劃分合理的模塊結(jié)構(gòu)中，關(guān)鍵判斷一般出現(xiàn)在較高的層次的模塊中的情況比較多，所以在較上層次的模塊中，會較早的遇到判斷結(jié)構(gòu)。如果在軟件中存在控制問題，盡早發(fā)現(xiàn)這類問題能夠減少之后的返工，所以這是十分必要的。

如果選用深度優(yōu)先組裝方式，可以按照軟件結(jié)構(gòu)圖首先呈現(xiàn)和驗證一個完整的功能，可先對邏輯輸入分支進行組裝和測試，檢查并避免潛在的錯誤和缺陷，驗證其功能的正確性，為以后對主要分支的組裝和測試提供了保證。

在測試的過程中，部分功能可較早得到證實，能夠給開發(fā)者和用戶對于項目的實現(xiàn)帶來較大的信心。最多只需要一個驅(qū)動模塊，減少了驅(qū)動器開發(fā)的費用。特定單元的驅(qū)動器一般使用難以編碼的測試用例，并且與單元的接口高度耦合，這種設(shè)置限制了驅(qū)動器和測試包的復(fù)用。而采用自頂向下的策略，最多只需要維護一個頂層模塊的驅(qū)動器，盡管也會遇到不可復(fù)用的問題，但維護工作量相對較小。由于增量式測試和設(shè)計順序的一致性，因此可以和設(shè)計并行進行。如果目標環(huán)境存在變化，該方法可以比較靈活地適應(yīng)該環(huán)境變化。支持故障隔離。例如，假設(shè)A模塊的測試正確執(zhí)行，但是加入B模塊后，測試執(zhí)行失敗，那么可以確定，要么B模塊有問題，要么A模塊和B模塊的接口有錯誤。自頂向下集成測試策略缺點是：樁的開發(fā)和維護成本較高。因為在每個測試中都必須提供樁，并且隨著測試配置中使用的樁的數(shù)目增加，所以維護樁的成本將急劇上升。當(dāng)測試到底層模塊時，當(dāng)?shù)讓幽K出現(xiàn)無法預(yù)計的錯誤時，可能會導(dǎo)致許多頂層模塊的修改，這破壞了已知完成的測試組件。推遲了底層模塊的驗證，同時為了能夠有效地進行測試，需要控制模塊具有比較高的可測試性。隨著底層模塊的不斷增加，整個系統(tǒng)越來越復(fù)雜，導(dǎo)致底層模塊的測試不充分，尤其是那些重用的模塊。自頂向下集成測試策略使用場景包括：

軟件結(jié)構(gòu)相對比較清晰和穩(wěn)定。

高層接口變化比較小。

底層接口未定義或經(jīng)常可能被修改。

控制模塊具有較大的風(fēng)險，需要盡早測試和驗證。

希望能夠盡早看到產(chǎn)品的系統(tǒng)基于需求的功能。

在極限編程中使用探索式開發(fā)風(fēng)格時，也可以采用自頂向下的集成測試策略。2）自底向上集成在自底向上測試中不再使用樁，而使用模擬被測模塊上一層單元模塊的驅(qū)動器或稱之為驅(qū)動模塊。自底向上集成首先從軟件結(jié)構(gòu)圖的最底層，即葉子結(jié)點著手，在每個模塊進行單元測試的前提下，并用專門編寫的驅(qū)動程序與底層被測模塊相結(jié)合進行測試。隨著測試的進行，驅(qū)動模塊被不斷替換，直到根據(jù)整個軟件結(jié)構(gòu)圖進行測試結(jié)束以后。在自底向上的集成測試中很少產(chǎn)生額外代碼，但接口問題仍然存在。現(xiàn)以軟件結(jié)構(gòu)圖（如前圖所示）為例進行集成測試，具體實施過程如下所示：①確定所有的將要集成在一起的軟件單元都已經(jīng)通過了單元測試。②設(shè)計開發(fā)驅(qū)動模塊D1，用來模擬軟件單元B調(diào)用軟件單元D的關(guān)系，然后把測試用驅(qū)動模塊D1和軟件單元D集成到一起進行測試，具體實施過程如圖3-9所示。③開發(fā)測試用驅(qū)動模塊D2，用來模擬軟件單元A調(diào)用軟件單元B的關(guān)系，然后把測試用驅(qū)動模塊D2與已經(jīng)通過測試的B和模塊D集成起來進行測試，具體實施過程如圖3-10所示。④設(shè)計開發(fā)驅(qū)動模塊D3，用來模擬軟件單元C調(diào)用軟件單元E的關(guān)系，然后把測試用驅(qū)動模塊D3和軟件單元E集成到一起進行測試，具體實施過程如圖3-11所示。⑤開發(fā)測試用驅(qū)動模塊D4，用來模擬軟件單元A調(diào)用軟件單元C的關(guān)系，然后把測試用驅(qū)動模塊D4與已經(jīng)通過測試的C和模塊E集成起來進行測試，具體實施過程如圖3-12所示。圖3-9驅(qū)動模塊D1圖3-10驅(qū)動模塊D2圖3-11驅(qū)動模塊D3圖3-12驅(qū)動模塊D4⑥把軟件單元A與其他軟件單元一起集成，對整個系統(tǒng)進行測試，具體實施過程如圖3-13所示。圖3-13整合測試優(yōu)點：能夠盡早測試底層模塊功能。可以在任何一個葉子節(jié)點已經(jīng)就緒的情況下進行集成測試。在工作的最初可能對結(jié)構(gòu)圖中，不同分支并行進行集成測試，在這一點上比使用自頂向下的集成效率高。由于驅(qū)動模塊是額外編寫的，而不是實際模塊，因此對實際被測模塊的可測試性要求比自頂向下的集成策略要小得多。減少了開發(fā)樁模塊的工作量，在集成測試中，開發(fā)樁模塊的工作量遠比開發(fā)驅(qū)動模塊的工作量大。但為了模擬一些中斷或異常，可能還需要設(shè)計一定的樁模塊。支持故障隔離。缺點：驅(qū)動模塊的開發(fā)工作量較大。對高層模塊的驗證推遲到最后階段，整個系統(tǒng)的功能在測試進入最后階段才呈現(xiàn)出來。設(shè)計上的錯誤不能及時發(fā)現(xiàn)，尤其對于那些控制結(jié)構(gòu)在整個體系中非常關(guān)鍵的產(chǎn)品。隨著集成測試進行到了頂層，整個系統(tǒng)將變得越來越復(fù)雜，并且對于底層的一些異常將很難覆蓋以及被發(fā)現(xiàn)，而使用樁模塊將簡單得多。使用場景：自底向上的集成測試方法適用于大部分采用結(jié)構(gòu)化方法設(shè)計的軟件產(chǎn)品，且產(chǎn)品的結(jié)構(gòu)相對比較簡單。一般對于大型復(fù)雜的項目往往會綜合采用多種集成測試方法。對于具有如下屬性的產(chǎn)品，可以優(yōu)先考慮自底向上的集成測試策略。3）三明治集成三明治集成也稱混合式集成。由于自頂向下的集成測試策略和自底向上的集成測試策略都有各自的缺點，因此綜合這兩者優(yōu)點的混合測試策略。三明治法便結(jié)合了二者的優(yōu)點。三明治集成法把系統(tǒng)劃分成3層，即頂層、目標層（中間層）和底層，中間層為目標層。測試時，對目標層上面的一層使用自頂向下的集成測試策略，對目標層下面的一層使用自底向上的集成測試策略，最后測試在目標層匯合。現(xiàn)以結(jié)構(gòu)圖3-14為例進行集成測試，具體實施過程如下所示：圖3-14三明治軟件結(jié)構(gòu)圖①首先選擇分界層，在此選擇M2-M3-M4層為界，在M2-M3-M4層以上采用自頂向下測試方法，在M2-M3-M4層以下采用自底向上測試方法。②M2-M3-M4層以上采用自頂向下測試方法，如圖3-15所示，即對M1模塊采用自頂向下測試，使用測試用被調(diào)用模擬子模塊S1、S2和S3來代替單元M1原本實際所調(diào)用的軟件單元M2、M3和M4，然后對軟件單元M1進行測試，如圖3-16所示；然后將圖與中間層結(jié)合起來進行集成測試。圖3-15頂層測試圖3-16

M1的樁模塊③在M2-M3-M4層以下采用自底向上測試方法，如圖3-17所示，即對M5、M6和M7采用自底向上測試，設(shè)計開發(fā)驅(qū)動模塊D1，用來模擬軟件單元M3調(diào)用軟件單元M5的關(guān)系，然后把測試用驅(qū)動模塊D1和軟件單元M5集成到一起進行測試;同理設(shè)計開發(fā)驅(qū)動模塊D2，用來模擬軟件單元M6調(diào)用軟件單元M7的關(guān)系，然后把測試用驅(qū)動模塊D2和軟件單元M7集成到一起進行測試具體實施過程如圖3-18所示：接下來，開發(fā)測試用驅(qū)動模塊D3，用來模擬軟件單元M3調(diào)用軟件單元M6的關(guān)系，然后把測試用驅(qū)動模塊D3與已經(jīng)通過測試的M6和M7集成起來進行測試，具體實施過程如圖3-18所示；然后將通過測試的各個部分與中間層結(jié)合起來進行測試。圖3-17底層測試圖3-18驅(qū)動模塊④整合后測試策略如圖3-19所示。圖3-19三明治整個測試但上述方案不能充分測試中間層；比如，容易忽略M2和M4。所以，一般將策略做如下改進：選擇M3模塊為界，對模塊M3層（M3即M2-M3-M4層）上面使用自頂向下集成測試策略，模塊M3層下面使用自底向上集成測試策略，對M3層使用獨立測試策略（即對該層模塊設(shè)計樁模塊和驅(qū)動模塊完成對目標層的測試）。具體策略如圖3-20所示。圖3-20完善的整合策略優(yōu)點：綜合了自頂向下和自底向上的兩種集成測試策略的優(yōu)點。缺點：中間層在集成前測試不充分。三明治集成的使用范圍是大部分軟件開發(fā)項目。最大的缺點就是對中間層的測試不夠充分。適用場景：大部分軟件開發(fā)項目都可以使用這種集成策略。4)基于功能的集成。基于功能角度出發(fā)，按照功能的關(guān)鍵程度對功能模塊進行集成。優(yōu)點：采用該方法，可以盡快看到關(guān)鍵功能的實現(xiàn)，并驗證關(guān)鍵功能的正確性。由于該方法在驗證某個功能的時候，可能會同時加入多個組件，因此在進度上比自底向上，自頂向下或三明治集成要短。可以減少驅(qū)動的開發(fā)，原因與自頂向下的集成策略類似。缺點：對有些接口的測試不充分，會丟失許多接口錯誤。可能會有較大的冗余測試。5)基于風(fēng)險集成基于風(fēng)險的集成式基于這樣一個假設(shè)，既系統(tǒng)風(fēng)險最高的組件間接口往往是錯誤集中的地方的假設(shè)，因此盡早驗證這些接口有助于加速系統(tǒng)的穩(wěn)定，從而增加對系統(tǒng)的信心。優(yōu)點：具有風(fēng)險的組件最早進行驗證，有助于系統(tǒng)的快速穩(wěn)定。缺點：需要對各組件的風(fēng)險有一個清晰的分析。其他還有基于分布式集成測試、分層集成策略、基干集成策略等等3.2.3確認測試確認測試又稱有效性測試。確認測試的目的是向用戶表明系統(tǒng)能夠像預(yù)定的需求那樣工作。基本方法：通過上一步集成測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，確認測試即可開始。確認測試的結(jié)果有兩種可能，一種是功能和性能指標滿足軟件需求說明，用戶可以接受；另一種是軟件不滿足軟件需求說明，用戶無法接受。3.2.4系統(tǒng)測試系統(tǒng)測試是在所有單元、集成測試后，對系統(tǒng)的功能及性能的總體測試。系統(tǒng)測試的目的是驗證最終軟件系統(tǒng)是否滿足用戶規(guī)定的需求。系統(tǒng)測試方法包括：功能測試、協(xié)議一致性測試、性能測試、壓力測試、容量測試、安全性測試、失效恢復(fù)測試、備份測試、GUI測試、健壯性測試、兼容性測試、易用性測試、安裝測試、文檔測試、在線幫助測試、數(shù)據(jù)轉(zhuǎn)換測試。3.2.5驗收測試驗收測試是部署軟件之前的最后一個測試操作。在軟件產(chǎn)品完成了單元測試、集成測試和系統(tǒng)測試之后，產(chǎn)品發(fā)布之前所進行的軟件測試活動。它是最后一個測試階段，也稱為交付測試。實施驗收測試的常用策略有：正式驗收、非正式驗收或Alpha測試、Beta測試。3.3基于源代碼可見性的測試從策略和過程的角度出發(fā)可以將測試分為：單元測試、集成測試、確認測試、系統(tǒng)測試和驗收測試。3.3.1黑盒測試1.黑盒測試的概念：黑盒測試(Black-boxTesting)又稱為數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明的測試。黑盒測試就是把程序看作一個不能打開的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，注重于測試軟件的功能性需求，測試者在軟件接口進行測試，它只檢查程序功能是否按照規(guī)格說明書的規(guī)定正常使用、程序是否能接收輸入數(shù)據(jù)而產(chǎn)生正確的輸出信息，并且保持數(shù)據(jù)庫或文件的完整性。3.3.1黑盒測試2.黑盒測試方法：黑盒測試原則上采用窮舉輸入測試，只有把所有可能的輸入都作為測試數(shù)據(jù)，才能查出程序中幾乎全部的錯誤。常用的黑盒測試方法有等價類劃分法、邊界值法、因果圖法、決策表法、正交測試法、錯誤推測法和場景法等，需要應(yīng)針對軟件開發(fā)項目的具體特點，選擇合適的測試方法。（1）等價類劃分法圖3-22等價類劃分圖劃分等價類的6條原則在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下，可以確定一個有效等價類和兩個無效等價類。例如：要求學(xué)生年齡為10~20歲，則10~20歲之間為有效等價類，小于10歲和大于20歲為兩個無效的等價類。在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”或“不可如何”的條件下，可確定一個有效等價類和一個無效等價類。在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。在規(guī)定了輸入數(shù)據(jù)的一組值（假定為若干個），并且程序要對每一個輸入值分別處理的情況下，可確定若干有效等價類和一個無效等價類。例如：輸入條件說明學(xué)生的學(xué)位可為學(xué)士、碩士、博士三種之一。等價類劃分為：分別取學(xué)士、碩士、博士這三個值作為三個有效等價類。另外，把三種學(xué)位之外的任何學(xué)位作為無效等價類。在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可確定一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。在確定已劃分的等價類中各元素在程序處理中的方式不同的情況下，則應(yīng)再將該等價類進一步地劃分為更小的等價類。5）確定測試用例。等價類表建立后，從劃分出的等價類中按以下步驟確定測試用例。①為每一個等價類規(guī)定一個唯一的編號。②設(shè)計新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效的等價類，重復(fù)這一步。直到所有的有效等價類都被覆蓋為止。③設(shè)計新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效的等價類，重復(fù)這一步。直到所有的無效等價類都被覆蓋為止。3.3.1黑盒測試等價類劃分法實例例1

設(shè)計學(xué)生檔案管理系統(tǒng)，對于入學(xué)年份設(shè)置“日期檢查功能”，請運用等價類測試法設(shè)計測試用例，繪制出等價類表，并為等價類編號，并且設(shè)計測試用例，給出預(yù)期輸入，對于合理的輸入應(yīng)有必要提示，非法輸入也要進行提醒。對于該系統(tǒng)的日期檢查功能說明如下：要求輸入以年月表示的日期。假設(shè)日期限定在2000年1月~2030年12月，并規(guī)定日期由6位數(shù)字字符組成，前4位表示年，后2位表示月。現(xiàn)用等價類劃分法設(shè)計測試用例，“日期檢查功能”的測試用例等價類表見表3-1。設(shè)計等價類表，并進行編號。3.3.1黑盒測試設(shè)計等價類表，并進行編號。設(shè)計測試用例。表3-1中列出了編號分別為①、②、③的3個覆蓋所有的有效等價類和編號分別為④、⑤、⑥、⑦、⑧、⑨、⑩的7個覆蓋所有的無效等價類，設(shè)計的測試用例結(jié)果見表3-2。3.3.1黑盒測試劃分等價類的要求有如下幾點：

測試完備合理、避免冗余。

劃分輸入條件、有效等價類和無效等價類重要的是將集合劃分為互不相交的一組子集。

整個集合完備。

子集互不相交，保證一種形式的無冗余性。

同一類中標識（選擇）一個測試用例。同一等價類中，往往處理相同，“相同處理”映射到“相同的執(zhí)行路徑”。3.3.1黑盒測試（2）邊界值分析法邊界值分析法是以邊界情況的處理作為主要目標專門設(shè)計測試用例的方法。

1）標準邊界值分析法。定義：有n個輸入變量，設(shè)計測試用例使得一個變量在數(shù)據(jù)有效區(qū)域內(nèi)取最大值(Max)、略小于最大值(Max-)、中間任一正常值(Normal)、略大于最小值(Min+)和最小值(Min)。對于有n個輸入變量的程序，一般性邊界值分析的測試用例個數(shù)為4n+1。例如：兩個輸入變量為a≤x≤b，d≤y≤c，且為整數(shù)，采用上述測試方法進行測試，其取值如圖3-24所示。圖3-24標準邊界值3.3.1黑盒測試標準邊界值分析法實例。例2使用標準邊界值分析法測試一個函數(shù)Test(intx，inty),該函數(shù)有兩個變量x和y均為整數(shù)，x和y的取值范圍分別是100≤x≤200，50≤y≤150。解：相應(yīng)的測試用例表見表3-3。3.3.1黑盒測試2）健壯性邊界值分析法。健壯性是指在異常情況下，軟件還能正常運行的能力。對于有n個輸入變量的程序，健壯性測試的測試用例個數(shù)為6n+1。例如兩個輸入變量為a≤x≤b，d≤y≤c，且為整數(shù)，采用上述測試方法進行測試，其取值如圖3-25所示。例3使用標準邊界值分析法測試一個函數(shù)Test(intx，inty),該函數(shù)有兩個變量x和y均為整數(shù)，x和y的取值范圍分別是100≤x≤200，50≤y≤150。圖3-25健壯性邊界值分析3.3.1黑盒測試健壯性邊界值分析法實例。解：相應(yīng)的測試用例表見表3-4。只要有數(shù)據(jù)輸入的地方，一般就可以使用邊界值一般情況下等價類和邊界值共同使用，形成一套較為完善的方案。邊界值的數(shù)據(jù)，本質(zhì)上屬于等價類的范疇，但是需要單獨進行測試，這種冗余在工程中是必要的。3.3.1黑盒測試健壯性邊界值分析法實例。例4一個四位整數(shù)加法器，需求分析中要求：

第一個數(shù)和第二個數(shù)都是只能輸入-8888到8888之間的整數(shù)；

對于輸入的小于-8888的數(shù)據(jù)或者大于8888的數(shù)據(jù)，程序應(yīng)給出明確提示；

對于輸入的小數(shù)、字符等非法數(shù)據(jù)，程序應(yīng)給出明確提示。請采用等價類方法，并且結(jié)合邊界值法設(shè)計測試用例，不考慮超出邊界的情況。3.3.1黑盒測試健壯性邊界值分析法實例例4解：①繪制等價類劃分表，見表3-5。3.3.1黑盒測試健壯性邊界值分析法實例。例4解：②按照上表給出有效測試用例和無效測試用例,見表3-6和表3-7。邊界值法需要測試以下數(shù)據(jù)：-8888,-8887,1000.8887,8888一般，有數(shù)據(jù)輸入的地方，基本都可以使用邊界值法。3.3.1黑盒測試（2）因果圖法1）因果圖基本概述。因果圖法是一種適合于描述對于多種輸入條件的組合，對應(yīng)產(chǎn)生多個動作的形式的方法。它利用圖解法分析輸入條件的各種組合情況，從而設(shè)計測試用例的，適合于檢查程序輸入條件的各種組合情況。2）因果圖符號。因果圖的4種關(guān)系符號如下：

恒等關(guān)系符號如圖3-26a所示。若c1是1，則e1也為1，否則e1為0。

非關(guān)系符號如圖3-26b所示。若c1是1，則e1也為1，否則e1為0。

或關(guān)系符號如圖3-26c）所示。若c1或c2或c3是1，則e1為1，否則e1為0。

與關(guān)系符號如圖3-26d所示。若c1和c2都是1，則e1為1，否則e1為0。3.3.1黑盒測試（3）因果圖法2）因果圖符號。因果圖的4種關(guān)系符號如下：輸入約束如下：lE約束符號（異）：a和a中至多有一個可能為1,即不能同時為1。E約束符號如圖3-28（a）所示。lI約束（或）：a、b和c中至少有一個必須是1，即a、b、和c不能同時為0。I約束符號如圖3-28（b）所示。lO約束符號（唯一）：4和6必須有一個，且僅有一個為1。O約束符號如圖3-28（c）所示。lR約束符號（要求）：4是1時，b必須是1，即不可能a是1時b是0。R約束符號如圖3-28d所示。輸出約束如下：M輸出條件的約束符號（強制）：若結(jié)果0是1,則結(jié)果b強制為0。M約束符號如圖3-28e所示。圖3-28因果圖約束符號利用因果圖導(dǎo)出測試用例需要經(jīng)過以下幾個步驟：①分析程序需求規(guī)格說明描述，找出原因和結(jié)果（原因常常是輸入條件或是輸入條件的等價類，結(jié)果是輸出條件），并且為每個原因和結(jié)果賦予一個標識符。②分析程序需求規(guī)格說明描述中語義的內(nèi)容，找出原因和結(jié)果之間、原因和原因之間的關(guān)系，根據(jù)這些關(guān)系，繪制出因果圖。③在因果圖上用規(guī)定的圖形符號表明約束或限制條件。④把因果圖轉(zhuǎn)換為判定表。⑤以判定表的每一列作為依據(jù)，根據(jù)其設(shè)計測試用例。圖3-30基本步驟3.3.1黑盒測試因果圖法實例。例5用因果圖法測試以下程序。程序的規(guī)格說明要求：輸入的第一個字符必須是A或B，第二個字符必須是一個數(shù)字，此情況下進行文件的修改；如果第一個字符不是A或B，則給出信息L，如果第二個字符不是數(shù)字，則給出信息M。解：①根據(jù)題意。原因和結(jié)果如下：

原因

結(jié)果c1：第一列字符是A；

e1：修改文件；c2：第一列字符是B；

e2：給出信息L；c3：第二列字符是一數(shù)字。結(jié)果

e3：給出信息M。3.3.1黑盒測試因果圖法實例例5解：②程序規(guī)格說明因果圖如圖3-31所示。其中，11為中間狀態(tài)，考慮到c1和c2不可能同時為1，因此，在c1和c2上施加E約束。圖3-31因果圖3.3.1黑盒測試因果圖法實例例5解：③根據(jù)因果圖繪制決策表，見表3-8。3.3.1黑盒測試因果圖法實例例5解：④對決策表化簡，并給出測試用例，見表3-9。3.3.1黑盒測試（4）決策表法

判定表由四個部分組成，如圖3-32所示。

條件：列出規(guī)格說明中的所有條件；一般認為，條件的順序不影響組合結(jié)果。

動作：列出了各種條件組合可能采取的操作（結(jié)果），這些操作的排列順序沒有約束。

條件組合：根據(jù)規(guī)格說明，進行條件組合；即將所有可能情況下的真假值進行組合。

動作結(jié)果：列出在條件項的各種取值情況下應(yīng)該采取的動作（結(jié)果）。圖3-32決策表四部分任何一個條件組合的特定取值及其相應(yīng)要執(zhí)行的動作，在判定表中貫穿條件組合和動作結(jié)果的一列，稱之為規(guī)則，如圖。判定表中列出多少組條件組合的取值，也便對應(yīng)多少條規(guī)則，即條件項和動作項有多少列。判定表的化簡，即規(guī)則合并就是由兩條或多條規(guī)則合并為一條規(guī)則。如圖所示，兩規(guī)則動作結(jié)果項一致，條件項類似，在1、2條件項分別取Y、N時，無論條件3取何值，都執(zhí)行同一動作。即要執(zhí)行的動作與條件3無關(guān)。于是可合并。“-”表示與取值無關(guān)。與圖3-33a類似，在圖3-33b中，無關(guān)條件項“一”可包含其他條件項取值，具有相同動作的規(guī)則可合并。考慮規(guī)則合理性的前提下的相同動作是否具有合并的意義，合并后是否破壞規(guī)格說明合理性。圖3-33(a)化簡前圖3-33(b)化簡后判定表的建立步驟如下：①確定規(guī)則的個數(shù)。假如有n個條件（原因），每個條件有兩個取值真和假（即0和1)，故有2n種規(guī)則。②列出所有的條件和動作。③根據(jù)規(guī)格說明進行條件組合，并填入表中。④根據(jù)規(guī)格說明條件組合對應(yīng)的動作結(jié)果，將對應(yīng)的結(jié)果填入表中。⑤簡化判定表，合并相似規(guī)則。適合使用判定表設(shè)計測試用例的條件如下：規(guī)格說明以條件組合形式給出，很容易轉(zhuǎn)換成判定表。條件的排列順序不影響執(zhí)行哪些操作。規(guī)則的排列順序不影響執(zhí)行哪些操作。每當(dāng)某一規(guī)則的條件已經(jīng)滿足，并確定要執(zhí)行的操作后，不必檢驗別的規(guī)則。如果某一規(guī)則得到滿足要執(zhí)行多個操作，這些操作的執(zhí)行順序無關(guān)緊要。例6某倉庫發(fā)貨方案如下：欠款時間在20天以內(nèi)（含）的，如果需求量不大于庫存量，則立即發(fā)貨，否則先按庫存發(fā)貨，進貨后再補發(fā)；欠款時間在20天以上60天以內(nèi)（含）的，如果需求量不大于庫存量，則先付款再發(fā)貨，否則不發(fā)貨；欠款時間在60天以上的，通知先還款。3.3.1黑盒測試

解：①確定條件和動作。條件如下：<=20天；>60天；<庫存量行動如下：先按庫存發(fā)，進貨后補貨；先付款再發(fā)貨；不發(fā)貨②確定決策表。決策表見表3-10。3.3.1黑盒測試

解：③化簡決策表。化簡結(jié)果見表3-11。3.3.1黑盒測試（5）錯誤推測法錯誤推測法的基本思想：基于直覺和經(jīng)驗推測出錯的可能類型，列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的情況的清單，然后依據(jù)清單來編寫測試用例；并且在閱讀規(guī)格說明時聯(lián)系程序員可能做的假設(shè)來確定測試用例。錯誤猜測法并沒有固定的測試策略，而是一般依賴于測試人員的經(jīng)驗、能力以及態(tài)度。如以下案例所示：3.3.1黑盒測試（5）錯誤推測法

例7成績報告的程序中，采用錯誤推測法還可補充設(shè)計一些測試用例。

程序是否把空格作為回答。

在回答記錄中混有標準答案記錄。

除了標題記錄外，還有一些的記錄最后一個字符即不是2也不是3。

有兩個學(xué)生的學(xué)號相同。

試題數(shù)是負數(shù)。3.3.1黑盒測試（5）錯誤推測法

例8對線性表（比如數(shù)組）排序的程序進行測試，可推測列出以下幾項需要特別測試的情況。

輸入的線性表為空表。

表中只含有一個元素。

輸入表中所有元素已排好序。

輸入表已按逆序排好。

輸入表中部分或全部元素相同。3.3.1黑盒測試（5）錯誤推測法

例9測試手機終端的通話功能，可以設(shè)計各種通話失敗的情況來補充測試用例。

無SIM卡插入時進行呼出（非緊急呼叫）。

插入已欠費SIM卡進行呼出。

射頻器件損壞或無信號區(qū)域插入有效SIM卡呼出。

網(wǎng)絡(luò)正常，插入有效SIM卡，呼出無效號碼（如1、888、333333、不輸入任何號碼等）。

網(wǎng)絡(luò)正常，插入有效SIM卡，使用“快速撥號”功能呼出設(shè)置無效號碼的數(shù)字。3.3.2白盒測試白盒測試又稱為邏輯結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序的測試。它一般用來分析程序的內(nèi)部結(jié)構(gòu)。它依賴于程序邏輯結(jié)構(gòu)，針對特定條件和循環(huán)設(shè)計測試用例，對程序的邏輯路徑進行測試。通過在程序的不同點檢驗程序，從而判斷實際運行是否和預(yù)期一致。白盒測試原理如圖3-34所示。圖3-34白盒測試原理

1.白盒測試的關(guān)鍵點在不同的測試階段，白盒測試的重點是不同的。主要針對以下幾個階段：（1）在單元測試階段：以程序語法檢查、程序邏輯檢查、代碼檢查、邏輯覆蓋為主。（2）在集成測試階段：需要增加靜態(tài)結(jié)構(gòu)分析、靜態(tài)質(zhì)量度量、以接口測試為主。（3）在系統(tǒng)測試階段：在真實系統(tǒng)工作環(huán)境下通過與系統(tǒng)的需求規(guī)格說明書作比較，檢驗完整的軟件配置項能否和系統(tǒng)正確連接，發(fā)現(xiàn)軟件與系統(tǒng)；子系統(tǒng)設(shè)計文檔和軟件開發(fā)合同規(guī)定不符合或與之相矛盾或者違背的地方；驗證系統(tǒng)是否滿足了需求規(guī)格說明的定義，找出與需求規(guī)格不相符合的地方，從而提出相對準確和完善的方案，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計的標準和規(guī)定，提高軟件質(zhì)量。（4）驗收測試階段：按照需求開發(fā)，體驗該產(chǎn)品是否能夠滿足最終用戶的使用要求，用戶是否擁有良好的體驗，有沒有達到原設(shè)計水平，完成的功能怎樣，是否符合用戶的需求，以達到預(yù)期目的為主。3.3.2白盒測試2.白盒測試的目的：

保證程序中所有關(guān)鍵路徑均得到測試，防止由于沒有執(zhí)行的路徑在實際投入運行后執(zhí)行到的意外情況發(fā)生。

衡量測試完整性。

程序內(nèi)部所有條件的邏輯值真、假兩個分支的覆蓋。

檢查內(nèi)存泄漏。

異常處理的分支語句的執(zhí)行。

解決實驗條件下很難搭建真實測試環(huán)境的問題。

檢查代碼符合一定的編碼規(guī)范，減少由于編碼不規(guī)范而引入的錯誤3.3.2白盒測試3.白盒測試的分類：白盒測試可以分為靜態(tài)測試技術(shù)和動態(tài)測試技術(shù)。靜態(tài)測試：不要求在計算機上實際執(zhí)行所測試的程序，主要以一些人工的模擬技術(shù)對軟件進行分析和測試，如代碼檢查法、靜態(tài)結(jié)構(gòu)分析法等；動態(tài)測試：是通過輸入一組預(yù)先按照一定的測試準則構(gòu)造實際數(shù)據(jù)來動態(tài)運行程序，達到發(fā)現(xiàn)程序錯誤的過程。白盒測試中的動態(tài)分析技術(shù)主要有邏輯覆蓋法和基本路徑測試法。3.3.2白盒測試3.白盒測試的分類：（1）靜態(tài)測試技術(shù)1)代碼檢查法。①代碼走查；②桌面檢查；③代碼審查。（2）靜態(tài)結(jié)構(gòu)分析法：1）數(shù)據(jù)流分析（DataFlowAnalysis）法2）基于約束的分析（Constraint-basedAnalysis）法3）抽象解析(AbstractInterpretation)法4）類型與結(jié)果分析（TypeandEffectAnalysis）法3.3.2白盒測試3.白盒測試的分類：（3）動態(tài)測試技術(shù)1）邏輯覆蓋法設(shè)計測試用例。可以將邏輯覆蓋技術(shù)分為以下幾種：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、路徑覆蓋。程序如下：publicclassTest{publicvoidtest(intx,inty,intz){doublem=0;doublen=0;//語句塊1if((x>4)&&(z<13)){m=x*y-1;n=Math.sqrt(m);}//語句塊2if((x==6)||(y>5)){n=x*y+10;}//語句塊3n=n%3;}}3.3.2白盒測試3.白盒測試的分類：根據(jù)上述程序繪制程序的軟件流程圖，并對相應(yīng)的控制流進行編號，如圖3-35所示。該程序中分別有兩個判定條件：M={x>4andz<13}和N={x==6ory>5}；圖3-35程序流程圖3.3.2白盒測試3.白盒測試的分類：①語句覆蓋語句覆蓋就是設(shè)計若干測試用例使得程序中每一個語句至少被執(zhí)行一次。語句覆蓋在測試中主要發(fā)現(xiàn)缺陷或錯誤語句。該方法具有以下特點：程序中每個語句至少執(zhí)行一次。對程序執(zhí)行邏輯的覆蓋率低，屬于邏輯覆蓋方法中最弱的覆蓋方式。無須測試程序邏輯中的分支情況。無須測試程序邏輯分支中的判斷和判定組合情況。無須測試程序執(zhí)行邏輯中的不同路徑。3.白盒測試的分類：②判定覆蓋判定覆蓋是設(shè)計若干測試用例使得每個判定的真假分支至少被執(zhí)行一次。判定覆蓋只考慮整個表達式的取值，并不考慮到表達式內(nèi)部變量（條件）的取值。特點：滿足判定覆蓋的測試用例一定滿足語句覆蓋對整個判定的最終取值（真或假）進行測試，但判定內(nèi)部每一個子表達式（條件）的取值未被考慮3.白盒測試的分類：③條件覆蓋條件覆蓋是設(shè)計若干測試用例，使得條件中的每個判定語句中的每個表達式（條件）的真假至少執(zhí)行一次。特點：彌補了判定覆蓋的不足——對整個判定的最終取值（真或假）進行度量條件覆蓋不一定能滿足判定覆蓋條件覆蓋不一定能滿足語句覆蓋3.3.2白盒測試3.白盒測試的分類：④條件/判定覆蓋判定條件覆是設(shè)計若干測試用例，使判定中的每個條件的所有可能(真/假)至少出現(xiàn)一次，并且每個判定本身的判定結(jié)果（真/假）也至少出現(xiàn)一次。特點：綜合了條件覆蓋和判定覆蓋的特點滿足條件判定覆蓋的用例一定滿足語句覆蓋滿足條件判定覆蓋的用例一定滿足條件覆蓋滿足條件判定覆蓋的用例一定滿足判定覆蓋條件判定覆蓋沒有考慮各判定結(jié)果（真/假）組合情況，不滿足路徑覆蓋未考慮判定中各條件不同取值的組合情況，不滿足條件組合覆蓋3.3.2白盒測試3.白盒測試的分類：⑤條件組合覆蓋條件組合覆蓋使得每個判定中條件的各種可能組合都至少出現(xiàn)一次。條件組合只針對同一個判斷語句內(nèi)存在多個條件的情況，讓這些條件的取值進行笛卡爾乘積組合。不同的判斷語句內(nèi)的條件取值之間無須組合。對于單條件的判斷語句，只需要滿足自己的所有取值即可。覆蓋一定滿足判定覆蓋、條件覆蓋、判定條件覆蓋。條件組合情況如下所示：x>4,z<13 x>4,z>=13 x<=4,z<13 x<=4,z>=13x==6,y>5 x==6,y<=5 x!=6,y>5 x!=6,y<=5測試用例編號輸入數(shù)據(jù)預(yù)期輸出執(zhí)行路徑CASE1x=6,z=5,y=6m=35,n=1P1(a-c-e)CASE2x=6,z=15,y=5m=0,n=1P2(a-b-e)CASE3x=3,z=11,y=7m=0,n=1P3(a-b-e)CASE4x=3,z=14,y=5m=0,n=0P4(a-b-d)特點：滿足條件組合覆蓋的用例一定滿足語句覆蓋。滿足條件組合覆蓋的用例一定滿足條件覆蓋。滿足條件組合覆蓋的用例一定滿足判定覆蓋。滿足條件組合覆蓋的用例一定滿足條件判定覆蓋。條件組合覆蓋沒有考慮各判定結(jié)果（真或假）組合情況，不滿足路徑覆蓋。條件組合數(shù)量大，設(shè)計測試用例的時間花費較多。3.白盒測試的分類：⑥路徑覆蓋選取足夠多的測試數(shù)據(jù)，使程序的每條可能路徑都至少執(zhí)行一次（如果程序圖中有環(huán)，則要求每個環(huán)至少經(jīng)過一次）。3.3.2白盒測試2）基本路徑測試法設(shè)計測試用例。基本路徑測試法是在程序控制流圖的基礎(chǔ)上，通過分析控制構(gòu)造的環(huán)路復(fù)雜性（環(huán)形復(fù)雜度），導(dǎo)出基本可執(zhí)行路徑集合，從而設(shè)計測試用例的方法。控制流圖是退化了的流程圖，簡稱流圖。將流程圖中執(zhí)行語句、判定語句、開始、結(jié)束等退化成節(jié)點，將流程線退化成一個節(jié)點到另一個節(jié)點的帶箭頭的弧線。流圖基本結(jié)構(gòu)如圖3-36所示.圖3-36流圖基本結(jié)構(gòu)3.3.2白盒測試3.白盒測試的分類：2）基本路徑測試法設(shè)計測試用例。基本路徑測試法的重點內(nèi)容如下：

程序的控制流圖：描述程序控制流的一種圖示方法。

程序環(huán)形復(fù)雜度：McCabe復(fù)雜性度量。從程序的環(huán)路復(fù)雜性可導(dǎo)出程序基本路徑集合中的獨立路徑條數(shù)，這是確定程序中每個可執(zhí)行語句至少執(zhí)行一次所必需的測試用例數(shù)目的上界。

導(dǎo)出測試用例：根據(jù)圈復(fù)雜度和程序結(jié)構(gòu)設(shè)計用例數(shù)據(jù)輸入和預(yù)期結(jié)果。

準備測試用例：確保基本路徑集中的每一條路徑的執(zhí)行。程序控制流圖（可簡稱流圖）是對程序流程圖進行簡化后得到的，它突出表示程序控制流的結(jié)構(gòu)。程序控制流圖是描述程序控制流的一種方式，其要點如下；

圖形符號：圓圈代表一個結(jié)點，表示一個或多個無分支的語句或源程序語句。

3.3.2白盒測試

3.白盒測試的分類：2）基本路徑測試法設(shè)計測試用例。程序控制流邊和點圈定的閉合部分叫作區(qū)域。當(dāng)對區(qū)域計數(shù)時，圖形外的一個部分也應(yīng)記為一個區(qū)域。

判斷語句中的條件為復(fù)合條件（即條件表達式由一個或多個邏輯運算符連接的邏輯表達式（aandb）時，則需要改變復(fù)合條件的判斷為一系列只有單個條件的嵌套的判斷。在規(guī)劃測試路徑之前，要將復(fù)雜條件分解。圖為將符合條件“與”和“或”轉(zhuǎn)化為簡單條件的過程如圖3-37所示。圖3-373.3.2白盒測試3.白盒測試的分類：2）基本路徑測試法設(shè)計測試用例。基本路徑測試方法包括以下4個步驟：①畫出程序的控制流圖。②計算程序的環(huán)形復(fù)雜度，導(dǎo)出程序基本路徑集中的獨立路徑條數(shù)，這是確定程序中每個可執(zhí)行語句至少執(zhí)行一次所必需的測試用例數(shù)目的上界。可用如下三種方法之一來計算環(huán)形復(fù)雜度：控制流圖中區(qū)域的數(shù)量對應(yīng)于環(huán)形復(fù)雜度。

給定控制流圖G的環(huán)形復(fù)雜度V(G)，定義為V(G)=E-N+2其中，E是控制流圖中邊的數(shù)量，N是控制流圖中的節(jié)點數(shù)量。

給定控制流圖G的環(huán)形復(fù)雜度V(G)，也可定義為V(G)=P+1其中，P是控制流圖G中判定節(jié)點的數(shù)量。3.3.2白盒測試3.白盒測試的分類：2）基本路徑測試法設(shè)計測試用例。基本路徑測試方法包括以下4個步驟：③導(dǎo)出基本路徑集，確定程序的獨立路徑。④根據(jù)步驟③中的獨立路徑，設(shè)計測試用例的輸入數(shù)據(jù)和預(yù)期輸出。仍然采用上一小節(jié)的程序繪制程序流程圖，現(xiàn)根據(jù)程序畫出其控制流圖，具體如圖3-38所示。3.3.2白盒測試3.白盒測試的分類：2）基本路徑測試法設(shè)計測試用例。①畫出如圖3-38所示的程序控制流圖。圖3-38控制流圖3.3.2白盒測試3.白盒測試的分類：2）基本路徑測試法設(shè)計測試用例。②計算程序的環(huán)形復(fù)雜度，導(dǎo)出程序基本路徑集中的獨立路徑條數(shù)；將環(huán)路復(fù)雜度定義為控制流圖中的區(qū)域數(shù)，如圖3-39所示。圖3-39控制流圖區(qū)域數(shù)3.3.2白盒測試3.白盒測試的分類：2）基本路徑測試法設(shè)計測試用例。③導(dǎo)出基本路徑集，確定程序的獨立路徑：①—②—⑤—⑦—⑧①—②—③—⑤—⑦—⑧①—②—③—④—⑤—⑦—⑧①—②—③—⑤—⑥—⑧①—②—③—④—⑤—⑥—⑦—⑧3.3.2白盒測試3.白盒測試的分類：2）基本路徑測試法設(shè)計測試用例。④根據(jù)步驟③中的獨立路徑，設(shè)計測試用例的輸入數(shù)據(jù)和預(yù)期輸出，測試用例見表3-18。3.3.3灰盒測試灰盒測試方法是在合適的測試階段或者節(jié)點采用黑白結(jié)合，互相彌補的測試方法，達到恰到好處，互補盲點的作用。灰盒測試也稱作灰盒分析。灰盒測試在現(xiàn)代測試理論中，反映了在白盒測試中交叉使用黑盒測試的方法，在黑盒測試中交叉使用白盒測試的方法，灰盒測試是介于白盒測試和黑盒測試之間的測試。3.4非功能測試非功能測試包括性能、負載、安全、可靠性和其他很多方面。非功能測試有時也被稱作行為測試或質(zhì)量測試。非功能測試的眾多屬性的一個普遍特征是一般不能直接測量。這些屬性是被間接地測量，例如用失敗率來衡量可靠性或圈復(fù)雜度，用設(shè)計審議指標來評估可測性。3.4.1性能測試性能測試目的是驗證軟件系統(tǒng)是否能夠達到用戶提出的性能指標，同時發(fā)現(xiàn)軟件系統(tǒng)中存在的性能瓶頸，優(yōu)化軟件，最后起到優(yōu)化系統(tǒng)的目的。性能測試類型包括壓力測試、負載測試，強度測試，容量測試等。因為各屬性之間在范圍上有重疊，很多非功能屬性的名字是可以通用的。3.4非功能測試3.4.2壓力測試一般來說，壓力測試的目的是要通過模擬比預(yù)期要大的工作負載來讓只在峰值條件下才出現(xiàn)的缺陷曝光。內(nèi)存泄漏、競態(tài)條件、數(shù)據(jù)庫中的線程或數(shù)據(jù)行之間的死鎖條件、和其他同步問題等等，都是壓力測試能發(fā)掘出來的常見缺陷。壓力測試主要是為了測試硬件系統(tǒng)是否達到需求文檔設(shè)計的性能目標，譬如在一定時期內(nèi)，系統(tǒng)的cpu利用率，內(nèi)存使用率，磁盤I/O吞吐率，網(wǎng)絡(luò)吞吐量等。

3.4非功能測試3.4.3負載測試負載測試是要探討在高峰或高于正常水平的負載下，系統(tǒng)或應(yīng)用軟件會發(fā)生什么情況。例如，一個網(wǎng)絡(luò)服務(wù)的負載測試會試圖模擬幾千名用戶同時連線使用該服務(wù)。測試的主要是軟件系統(tǒng)的性能，譬如軟件在一定時期內(nèi)，最大支持多少并發(fā)用戶數(shù)，軟件請求出錯率等。

3.4非功能測試3.4.4低資源測試低資源測試是要確定當(dāng)系統(tǒng)在重要資源（內(nèi)存、硬盤空間或其他系統(tǒng)定義的資源）降低或完全沒有的情況下會出現(xiàn)的狀況。重要的是要預(yù)估將會發(fā)生什么，例如為文件存盤而無足夠空間或一個應(yīng)用程序的內(nèi)存分配失敗時將會發(fā)生什么。3.4非功能測試3.4.5容量測試與負載測試非常相似，容量測試一般是用來執(zhí)行服務(wù)器或服務(wù)測試。目的是要確定系統(tǒng)最大承受量，譬如系統(tǒng)最大用戶數(shù)，最大存儲量，最多處理的數(shù)據(jù)流量等。容量模型通常建立在容量測試數(shù)據(jù)基礎(chǔ)上。有了這些數(shù)據(jù)，運營團隊(Operations)就能定計劃什么時候增加系統(tǒng)容量：要么增加單機資源，如RAM、CPU和磁盤空間等；要么干脆增加計算機數(shù)目。3.4非功能測試3.4.6重復(fù)性測試重復(fù)性測試是為了確定重復(fù)某一程序或場景的效果而采取的一項簡單而“粗暴”（bruteforce）的技術(shù)。這個技術(shù)的精髓是循環(huán)運行測試直到達到一個具體界限或臨界值，或者是不妙的境況。舉個例子，一個操作也許會泄漏20字節(jié)的內(nèi)存。這并不足以在軟件的其他地方產(chǎn)生任何問題，但如果測試連續(xù)運行2000次，泄漏就可以增長到4萬字節(jié)。如果是提供核心功能的程序有泄漏，那么這個重復(fù)性測試就抓到了只有長時間連續(xù)運行該軟件才能發(fā)現(xiàn)的內(nèi)存泄漏。通常有更好的辦法來發(fā)現(xiàn)內(nèi)存泄漏，但有時候，這種簡單“粗暴”的方法也可以很有效。3.5面向?qū)ο鬁y試軟件工程兩大方法學(xué)分別為結(jié)構(gòu)化方法和面向?qū)ο蠓椒āＴ诤诎缀袦y試方法介紹過程中，是以結(jié)構(gòu)化方法為依據(jù)進行具體方法講解。3.5.1面向?qū)ο鬁y試的概念面向?qū)ο筌浖y試以面向?qū)ο蠓治鲈O(shè)計方法為依據(jù)，對項目進行面向?qū)ο鬁y試，主要針對類級測試、場景法測試、基于狀態(tài)測試三個方面展開。3.5.2面向?qū)ο鬁y試的理論基礎(chǔ)在面向?qū)ο鬁y試中，類是最小的可測試單位。對象擁有狀態(tài)，測試方法必須考慮這些。類測試和單元測試是等價的，在測試過程中，要測試類中的操作和類的狀態(tài)行為。3.5.3面向?qū)ο鬁y試與傳統(tǒng)測試理論的關(guān)系傳統(tǒng)測試方法和面向?qū)ο鬁y試方法基礎(chǔ)理論是具有一致性和適用性的。3.5.4面向?qū)ο鬁y試的方法面向?qū)ο篌w系結(jié)構(gòu)導(dǎo)致封裝了協(xié)作類的一系列分層子系統(tǒng)的產(chǎn)生。面向?qū)ο筌浖臏y試用例設(shè)計方法還在不斷改進，然而，對于面向?qū)ο鬁y試用例的設(shè)計，Berard已經(jīng)提出了總體方法［Ber93］：每個測試用例都應(yīng)該被唯一地標識，并明確地與被測試的類相關(guān)聯(lián)。3.5.5面向?qū)ο鬁y試的過程傳統(tǒng)的測試計算機軟件的策略是從小到大，即從小型測試到大型測試，從部分到整體的過程。3.5.5面向?qū)ο鬁y試的過程根據(jù)面向?qū)ο蠓治雠c設(shè)計特點，面向?qū)ο蟮拈_發(fā)模型突破了傳統(tǒng)的瀑布模型，將開發(fā)分為面向?qū)ο蠓治觯∣OA），面向?qū)ο笤O(shè)計（OOD），和面向?qū)ο缶幊蹋∣OP）三個階段。針對這種開發(fā)模型，結(jié)合傳統(tǒng)的測試步驟的劃分，我們把面向?qū)ο蟮能浖y試分為：面向?qū)ο蠓治龅臏y試，面向?qū)ο笤O(shè)計的測試，面向?qū)ο缶幊痰臏y試，面向?qū)ο髥卧獪y試，面向?qū)ο蠹蓽y試，面向?qū)ο笙到y(tǒng)測試。1.面向?qū)ο蠓治龅臏y試：面向?qū)ο蠓治觯∣OA）是運用面向?qū)ο蠓椒ㄟM行系統(tǒng)分析。其基本任務(wù)即運用面向?qū)ο蠓椒ǎ瑢栴}域和系統(tǒng)責(zé)任進行分析和理解，找出描述問題域及系統(tǒng)責(zé)任所需的對象，定義對象的屬性、操作以及它們之間的關(guān)系。其目標是建立一個符合問題域、滿足用戶需求的OOA模型。對OOA的測試，應(yīng)從以下方面考慮：

對認定的對象的測試。對認定的結(jié)構(gòu)的測試。對認定的主題的測試。對定義的屬性和實例關(guān)聯(lián)的測試。對定義的服務(wù)和消息關(guān)聯(lián)的測試。3.5.5面向?qū)ο鬁y試的過程3.5.5面向?qū)ο鬁y試的過程2.面向?qū)ο笤O(shè)計的測試：面向?qū)ο笤O(shè)計（OOD）以O(shè)OA為基礎(chǔ)歸納出類，并建立類結(jié)構(gòu)或進一步構(gòu)造成類庫，實現(xiàn)分析結(jié)果對問題空間的抽象。由此可見，OOD是對OOA的進一步細化和更高層的抽象。所以，OOD與OOA的界限通常是難以嚴格區(qū)分的。OOD確定類和類結(jié)構(gòu)不僅是滿足當(dāng)前需求分析的要求，即通過OOA進行分析的成果，更重要的是通過重新組合或加以適當(dāng)?shù)难a充，能方便實現(xiàn)功能的重用和擴增，以不斷適應(yīng)用戶的要求。對OOD的測試，應(yīng)從如下四方面考慮：

對認定的類的測試。

對構(gòu)造的類層次結(jié)構(gòu)的測試。

對類庫的支持的測試。

面向?qū)ο缶幊痰臏y試。3.5.5面向?qū)ο鬁y試的過程3.面向?qū)ο蟮膯卧獪y試：單元測試的依據(jù)是詳細設(shè)計，單元測試應(yīng)對模塊內(nèi)所有重要的控制路徑設(shè)計測試用例，以便發(fā)現(xiàn)模塊內(nèi)部的錯誤。單元測試多采用白盒測試技術(shù)，系統(tǒng)內(nèi)多個模塊可以并行地進行測試。4.面向?qū)ο蟮募蓽y試對OO軟件的集成測試有兩種不同策略，第一種稱為基于線程的測試，集成對回應(yīng)系統(tǒng)的一個輸入或事件所需的一組類，每個線程被集成并分別測試，應(yīng)用回歸測試以保證沒有產(chǎn)生副作用。第二種稱為基于使用的測試，通過測試那些幾乎不使用服務(wù)器類的類(稱為獨立類)而開始構(gòu)造系統(tǒng)，在獨立類測試完成后，下一層的使用獨立類的類（稱為依賴類）被測試。這個依賴類層次的測試序列一直持續(xù)到構(gòu)造完整個系統(tǒng)。3.5.5面向?qū)ο鬁y試的過程5.面向?qū)ο蟮南到y(tǒng)測試通過單元測試和集成測試，僅能保證軟件開發(fā)的功能得以實現(xiàn)。但不能確認在實際運行時，它是否滿足用戶的需要。為此，必須進行系統(tǒng)測試。系統(tǒng)測試是將通過確認測試的軟件，作為整個計算機系統(tǒng)的一個元素，與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試。系統(tǒng)測試時，應(yīng)該參考OOA分析的結(jié)果，對應(yīng)描述的對象、屬性和各種服務(wù)，檢測軟件是否能夠完全重現(xiàn)問題空間。系統(tǒng)測試不僅是檢測軟件的整體行為表現(xiàn)，從另一個側(cè)面看，也是對軟件分析和設(shè)計的再確認。面向?qū)ο鬁y試的整體目標是以最小的工作量發(fā)現(xiàn)最多的錯誤——和傳統(tǒng)軟件測試的目標是一致的，但是OO測試的策略有很大不同。測試的視角擴大到包括復(fù)審分析和設(shè)計模型，此外，測試的焦點從結(jié)構(gòu)化分析方法中的模塊移向了面向?qū)ο蠓椒ㄖ械念悺?.5.6類級測試在面向?qū)ο筌浖y試中，類是最小的可測試單元，類測試是由封裝在類中的操作和類的狀態(tài)行為驅(qū)動的。由于面向?qū)ο蟮某绦蛑锌瑟毩⒈粶y試的單元通常是一個獨立的類，按照測試思路可以將其分為幾個層次進行測試：方法層次的測試、類層次的測試、類樹層次的測試。1.方法層次的測試對于類當(dāng)中的一個方法，可以將其看作關(guān)于輸入?yún)?shù)和該方法所在類的成員變量中的一個函數(shù)，如果該方法內(nèi)聚性很高，功能也比較復(fù)雜，可以對其單獨測試。一般只有少數(shù)方法需要進行單獨測試，一般很多方法與成員變量具有很強的耦合性。對單個成員方法的測試類似于傳統(tǒng)軟件測試中對單個函數(shù)的測試，很多基于結(jié)構(gòu)化方法的傳統(tǒng)測試技術(shù)，可以應(yīng)用于類當(dāng)中的方法測試中。2.類層次的測試類中的很多方法會通過成員變量產(chǎn)生相互依賴的關(guān)系，這將導(dǎo)致很難對單個方法進行充分的測試。相對合理的測試是將相互依賴的成員方法放在一起進行測試，這就是類層次測試。3.類樹層次的測試面向?qū)ο笾杏欣^承和多態(tài)現(xiàn)象，所以對子類的測試通常不能限定在子類中定義的成員變量和成員方法上，還要考慮父類對子類的影響。3.5.7場景法測試基于場景的測試關(guān)心用戶做什么，而不是產(chǎn)品做什么。這意味著需要通過面向?qū)ο蠓治鲞^程中用例圖中的用例捕獲用戶必須完成的任務(wù)，然后在測試時使用它們及其變體。場景可以發(fā)現(xiàn)交互錯誤。基于場景的測試傾向于用單一的測試檢查多個子系統(tǒng)，用戶并不限制自己一次只使用一個子系統(tǒng)。場景法的使用步驟如下:1）分析用戶需求，在面向?qū)ο蠓治鲈O(shè)計中，以用例圖腳本說明中的正常腳本和異常腳本為依據(jù)。根據(jù)需求陳述描述出程序的基本流以及備選流；2）根據(jù)基本流和備選流的組合生成不同的場景；3）針對每一個場景生成對應(yīng)的測試用例；4）把多余的測試用例去掉，針對測試用例設(shè)計測試數(shù)據(jù)。場景是事件流的一個實例,由基本流或基本流和備選流中的步驟組成，表明了用戶執(zhí)行系統(tǒng)的操作序列。根據(jù)業(yè)務(wù)調(diào)研，將用例圖以及用例腳本中的基本流和異常流提取出來，對應(yīng)繪制出如圖所示的方案，將基本流程和備選流程進行組合，具體測試路徑如圖3-40所示：圖3-40場景拆分3.5.7場景法測試例1：在某購物網(wǎng)站用例圖中，針對“添加購物車”用例進行用例腳本說明，詳細說明如下：用例名稱:添加購物車。用例描述:顧客有購買傾向，但由于某種情況不立即進行購買，可執(zhí)行添加購物車商品操作。參與者：顧客。優(yōu)先級：3。前置條件：①正確登錄賬號；②勾選對應(yīng)商品的屬性；③添加數(shù)量正確且?guī)齑孀銐颉：笾脳l件：①添加成功；②庫存不足；③添加數(shù)量錯誤。基本操作流程：顧客正確登錄賬號，瀏覽商品時對有意向的商品進行屬性勾選，選擇添加數(shù)量進行添加，顯示添加購物車成功。3.5.7場景法測試可選操作流程：①顧客瀏覽商品并進行添加購物車操作時，提示請先登錄賬號；②進行添加購物車操作時沒有對商品的相應(yīng)屬性進行選擇；③顧客進行添加購物車操作時，在添加數(shù)量因為誤操作輸入了非正數(shù)，提示輸入正確數(shù)量；④顧客進行添加購物車操作時，所添加數(shù)量超過庫存數(shù)，顯示庫存不足。結(jié)合上述腳本說明，確定場景法中的基本流和備選流見表3-20。3.5.7場景法測試根據(jù)基本流和備選流的組合生成不同的場景，見表3-21所示：根據(jù)場景生成對應(yīng)的測試用例，見表3-22：3.5.7場景法測試根據(jù)場景生成對應(yīng)的測試用例，見表3-22：3.5.7場景法測試針對測試用例設(shè)計測試數(shù)據(jù)，見表3-23。3.5.8基于狀態(tài)測試基于狀態(tài)的測試，是一種基于模型的測試，一般是用狀態(tài)圖來描述事件序列；常用于事件驅(qū)動的系統(tǒng)中，這些系統(tǒng)往往具有實時狀態(tài)變化的特點。基于狀態(tài)測試的使用步驟如下：

列出所有對象包含的狀態(tài)圖（可以以面向?qū)ο蠼Ｖ械臓顟B(tài)圖為依據(jù)）。

列出不同狀態(tài)之間的轉(zhuǎn)換。

確定引起各個狀態(tài)轉(zhuǎn)換的事件。

分析各個狀態(tài)轉(zhuǎn)換過程中發(fā)生的事件，并繪制狀態(tài)轉(zhuǎn)換圖。

根據(jù)狀態(tài)轉(zhuǎn)換圖編寫測試用例。3.5.8基于狀態(tài)測試例2：圖為車票預(yù)售系統(tǒng)中，“車票”類的狀態(tài)圖。（