測試理論

歡迎使用Markdown編輯器寫部落格

一、基本概念

定義：軟體測試是為了發現錯誤而執行程式的過程，“尋找錯誤”是測試的目的

使用人工或自動手段運作或測定某個系統的過程，其目的在于檢驗它是否滿足規定的需求或是否弄清預期結果與實際結果之間的差别

軟體測試是一種重要的軟體品質保證活動，測試過程中的活動包括分析軟體和運作軟體，是在軟體投入運作前，對軟體需求分析、設計規格說明和編碼的最終複審，是軟體品質保證的關鍵步驟。

測試：找錯誤（證明程式有錯）

調試：該錯誤（使程式正确）

軟體測試的目的：

（1）測試是程式執行的過程，目的在于發現錯誤

（2）一個好的測試用例在于能發現至今未發現的錯誤

（3）一個成功的測試是發現至今未發現的錯誤的測試

（測試的成功與失敗在于能否發現錯誤，測試不能表能軟體中不存在錯誤，隻能說明軟體中存在錯誤）

通過對軟體錯誤的原因和分布進行歸納，來發現并排除目前軟體産品的缺陷，對在需求和設計過程中存在的問題查缺補漏，進而確定軟體産品的品質；
           

軟體測試的原則：

（1）所有的測試都應追索到使用者的需求：系統中最嚴重的錯誤是導緻程式無法滿足使用者需求的錯誤；

（2）盡早的和不斷的進行軟體測試：需求和設計時初心的缺陷占很大的比例；缺陷的修改成本随着階段的推移而急劇上升；缺陷具有放大的特點

（3）不可能完全的測試
     （4）80-20原則：測試發現的錯誤80%很可能起源于20%的子產品中，應孤立這些疑點子產品重點測試。
     （5）注意測試中的群集現象：在所測程式段中，若發現錯誤數目多，則殘存數目也比較多
     （6）避免測試自己的程式
     （7）設計周密的測試用例
              軟體測試的本質就是針對要測試的内容确定一組測試用例
              測試用例至少包括：
              執行測試用例前：應滿足的前提條件
              輸入
              預期輸出
              設計測試用例時應包括合理的輸入條件和不合理的輸入條件
     （8）回歸測試：程式修改錯誤後必須進行回歸測試，避免引入新的錯誤
     （9）嚴格執行測試計劃：排除測試的随意性
           

軟體測試的對象：

（1）軟體測試貫穿于定義與開發的整個期間

（2）軟體測試的對象

需求規格說明

概要設計規格說明

詳細設計規格說明

源程式

軟體測試分類

是否執行被測試軟體：

靜态測試：不運作被測程式本身，而是通過在對軟體進行分析、檢查和審閱達到測試目的

方法：代碼審查；代碼走查；桌面檢查；技術評審
           

動态測試：值通過運作被測程式，檢查運作結果與預期結果的差異，并分析運作效率和健壯性等性能。由三部分組成：編寫測試用例、執行測試結果、分析程式的輸出結果。

黑盒測試：功能測試/資料驅動測試，是在已知産品所應對應具有的功能的前提下，通過測試來檢測每個功能是否都能正常使用。

白盒測試：結構測試/邏輯驅動測試，是在知道産品内部工作過程的前提下，可通過測試來檢測産品内部動作是否按照規格說明書的規定正常進行。

按照軟體測試的政策和過程分（都是動态測試）：

單元測試：單元測試的對象軟體設計的最小機關——子產品。單元測試的依據是詳細設計描述，單元測試應對子產品内所有重要的控制路徑設計測試用例，以便發現子產品内部的錯誤。單元測試多采用白盒測試技術，系統内多個子產品可以并行的進行。

內建測試：組裝軟體的系統測試技術，按設計要求把通過單元測試的各個子產品組裝在一起之後，進行內建測試以便發現與接口有關的各種錯誤。

系統測試：是在真實或模拟系統運作的環境下，為驗證和确認系統是否達到需求規格說明書規定的需求而對內建的硬體和軟體系統進行的測試

驗收測試：按照項目任務書或合同、供需雙方約定的驗收依據文檔進行的整個系統的評測，決定是否接受或拒絕系統

按測試内容分：

功能測試：根據功能需求進行測試，以确定軟體與軟體功能需求的一緻，功能遺缺和多餘

性能測試：評價一個産品或元件與性能需求是否符合的測試

一、性能測試類型

　　性能測試是通過自動化的測試工具模拟多種正常、峰值以及異常負載條件來對系統的各項性能名額進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結合進行。通過負載測試，确定在各種工作負載下系統的性能，目标是測試當負載逐漸增加時，系統各項性能名額的變化情況。壓力測試是通過确定一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級别的測試。

　　2.負載測試(Load Testing)

　　在給定的測試環境下，通過在被測系統上不斷增加壓力，直到性能名額超過預定名額或某種資源使用已經達到飽和狀态，目的是了解系統性能容量和處理能力極限。負載測試的主要用途是發現系統性能的拐點，尋找系統能夠支援的最大使用者、業務等處理能力的限制。

　　負載測試是在固定測試環境，在其它測試角度(負載方面)不變的情況下，變化一個測試角度并持續增加壓力，檢視系統的性能曲線和處理極限，以及是否有性能瓶頸存在(拐點)。主要意義是從多個不同的測試角度去探測分析系統的性能變化情況，配合性能調優。測試角度可以是并發使用者數、業務量、資料量等不同方面的負載。

　　3.壓力測試(Stress Testing)

　　測試系統在一定飽和狀态下系統能夠處理的會話能力，以及是否出現錯誤，一般用于穩定性測試。

　　可以了解為資源的極限測試。測試關注在資源處于飽和或超負荷的情況下，系統能否正常運作，是一種在極端壓力下的穩定性測試。其主要意義是通過測試、調優保證系統即使在使用者的極端壓力下也不會出錯甚至系統崩潰。

　　壓力測試的目的是調查系統在其資源超負荷的情況下的表現，尤其是對系統的處理時間有什麼影響。這類測試在一種需要在反常數量、頻率或資源的方式下執行系統。目标是通過極限測試方法，發現系統在極限或惡劣環境中自我保護能力。主要驗證系統的可靠性。

　　4.配置測試(Configuration Testing)

　　通過對被測系統的軟硬體環境的調整，了解各種不同環境對性能影響的程度，進而找到系統各項資源的最有配置設定原則。

　　主要用于性能調優，在經過測試獲得了基準測試資料後，進行環境調整(包括硬體配置、網絡、作業系統、應用伺服器、資料庫等)，再将測試結果與基準資料進行對比，判斷調整是否達到最佳狀态。

　　5.并發測試(Concurrency Testing)

　　模拟并發通路，測試多使用者并發通路同一個應用、子產品、資料時是否産生隐藏的并發問題，如記憶體洩漏、線程鎖、資源争用問題。

　　6.可靠性測試(Reliability Testing)

　　通過給系統加載一定的業務壓力的情況下，讓應用持續運作一段時間，測試系統在這種條件下是否能夠穩定運作。

　　需要和壓力測試區分開，兩者的測試環境和測試目的不一樣。壓力測試強調在資源極限情況下系統是否出錯，可靠性測試強調在 一定的業務壓力下長時間(如24×7)運作系統，關注系統的運作情況(如資源使用率是否逐漸增加、響應時間是否越來越慢)，是否有不穩定征兆。

eg：

負載測試：測試一個應用在重負荷下的表現，例如測試一個web站點在大量負荷下，何時系統的響應會退化或失敗

壓力測試：用來評估在超越最大負載的情況下系統将應如何進行

壓力測試的目标就是發現在高負荷條件下應用程式的缺陷
           

疲勞測試：采用系統穩定運作情況下能夠支援的最大并發使用者數，持續一段時間業務，通過綜合分析交易執行名額和資源監控名額來确定系統處理最大量強度性能的過程

相容測試：測試軟體在一個特定的硬體/軟體/作業系統/網絡等環境下性能如何

安全性測試：針對程式中危險防止和危險處理設施進行的測試，以驗證其是否有效

安裝性測試

可用性測試：對“使用者友好性”的測試

主觀的：取決于目标最終使用者和可和

                使用者面談、調查、使用者對話的路線和其他一些技術

                程式員和測試員通常都不宜做可用性測試員
           

注：功能的重點在于能做什麼；性能在于做的如何

缺陷：最終産品和使用者的期望不一緻

功能錯誤

       功能遺漏

       超出需求的部分

       性能不符合要求
           

二、測試模型與過程

1-1 軟體生命周期

   a.大棒開發法

   b.邊改邊寫法

          優點：能夠較為迅速的展現結果，适合需要快速制作并且用完就扔的小項目，如示範程式、示範程式等。

          缺點：其編碼和測試可能是将長期的循環往複的過程



   c.  瀑布法:将軟體生命周期的各項活動，規定為按照固定順序相連的若幹個階段性工作，形如瀑布流水，最終得到軟體産品

   優點：易于了解；調研開發的階段性；強調早期計劃及需求調查；确定何時能傳遞産品及何時進行評審與測試；

   缺點：需求調查分析隻進行一次，不能适應需求變化；順序的開發流程，使得開發中的經驗教訓不能回報到該項目的開發中去；不能反映出軟體開發過程的反複與疊代性；沒有包含類型的風險評估；開發中出現的問題直到開發後期才暴露（測試在後期階段），是以失去及早糾正的機會。



   d. 快速原型法

   根據客戶需求在較短的時間内解決使用者最迫切解決的問題，完成可示範的産品。這個産品隻實作最重要的功能，在得到客戶更加明确的需求之後，原型将丢棄



   e. 螺旋瀑布法

   将瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特别适合于大型複雜的系統。 螺旋模型沿着螺線進行若幹次疊代，圖中的四個象限代表了以下活動：

          （1） 制定計劃：确定軟體目标，標明實施方案，弄清項目開發的限制條件

          （2） 風險分析：分析評估所選方案，考慮如何識别和消除風險；

          （3） 實施工程：實施軟體開發和驗證；

          （4） 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。
           

　　螺旋模型由風險驅動，強調可選方案和限制條件進而支援軟體的重用，有助于将軟體品質作為特殊目标融入産品開發之中。但是，螺旋模型也有一定的限制條件，具體如下：

　　（1） 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，并做出相關反應是不容易的，是以，這種模型往往适應于内部的大規模軟體開發。

　　（2） 如果執行風險分析将大大影響項目的利潤，那麼進行風險分析毫無意義，是以，螺旋模型隻适合于大規模軟體項目。

　　（3） 軟體開發人員應該擅長尋找可能的風險，準确地分析風險，否則将會帶來更大的風險

　　一個階段首先是确定該階段的目标，完成這些目标的選擇方案及其限制條件，然後從風險角度分析方案的開發政策，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最後，評價該階段的結果，并設計下一個階段。

優點：嚴格的全過程風險管理；強調個開發階段的品質；提供機會評估項目是否有價值繼續下去。

2.軟體測試模型

V模型的過程從左到右，描述了基本的開發過程和測試行為。V模型的價值在于它非常明确地标明了測試過程中存在的不同級别，并且清楚地描述了這些測試階段和開發過程期間各階段的對應關系；

   局限性：把測試作為最後一個活動，需求分析前期産生的錯誤直到後期的驗收測試才能發現。

   該模型容易使人了解主要是針對程式進行測試尋找錯誤

   實際中，由于需求變更較大，導緻要重複變更需求、設計、編碼、測試。返工量大。主要用在快速程式的開發





   在V模型中增加軟體開發各開發階段應同步進行的測試，演化為W模型

   開發的是V，測試是與此并行的V；相對于V模型，W模型更科學，強調的是測試伴随整個軟體開發周期，并且測試的對象不僅僅是程式，需求、功能、和設計同樣要測試。測試和開發是同步進行的，有利于盡早的發現問題

   缺點：W和V都把軟體的開發視為需求、設計、編碼等一系列串行的活動，無法支撐疊代、自發性以及變更挑戰

              主要應用在一些中型軟體并且業務邏輯關聯非常緊密的項目中



   H模型中，軟體測試活動完全獨立，貫穿于整個産品的周期，與其他流程并發的進行，某個測試點準備就緒時，就可以從測試準備階段進行到測試執行階段。軟體測試可以盡早的進行，并且可以根據被測物的不同而分層次進行。

   軟體測試是一個獨立的流程，貫穿産品整個生命周期，與其他流程并發進行

   H模型指出軟體測試要盡早準備，盡早執行，不同的測試活動可以是按照某次序先後進行，但也可能是反複的，隻要某個測試達到準備就緒點，測試執行活動就可以開展。



   很好的處理測試與開發的交接過程，交接的過程是一個時間段，而不是一個點。

   左邊描述的是針對單獨程式片段所進行的互相分離的編碼和測試，伺此後将進行頻繁的交接，通過內建最終合成為可執行的程式，然後再對這些可執行的程式進行測試。

   已認證內建測試的産品可以進行封裝并送出給使用者，也可以作為更大規模和範圍内內建的部分，多根并行的曲線表示變更可以在各個部分發生

   X模型還定位了探索性測試，這是不進行實作計劃的特殊測試，給有經驗的測試人員在測試計劃外發現更多軟體缺陷
           

三、 黑盒測試常用方法

1. 邊界值測試：

   1-1 邊界

   a. 數值邊界值：數值範圍
   
         b. 字元邊界值 ：ASCII表
   
          c. 其他邊界條件：預設值、空白、空值、零值、無輸入等情況
              

   1-2 基本思想

   使用輸入變量的最小值、略大于最小值、正常值、略小于最大值和最大值來設計測試用例（min，min+，nom，max-，maz）
   
         單缺陷假設：隻讓一個變量取邊界值，其餘變量取正常值
   
         多缺陷假設：同時讓多個變量取邊界值
   
         （1）邊界值分析（單缺陷）（4N+1）
   
   
   
         （2）健壯性邊界值分析（在異常情況下，軟體還具有正常運作的能力）（增加一個取異常值，其他都正常值的測試用例，6N+1）
   
   
   
         （3）最壞情況測試（多個變量出現極值，最最小值，略大于最小值，正常值，最大值，略小于最大值做笛卡爾乘積，5N）
   
   
   
      （3）健壯性最壞情況測試（7N）
              

2. 等價類測試

   2-1 等價類劃分

   劃分是指互不相交的一組子集，這些子集的并是整個集合
              

   2-2 有效等價類

   是指對于程式的規格說明來說是合理的、有意義的輸入資料構成的集合。利用有效等價類可以驗證程式是否實作了規格說明中的功能和性能。
              

   2-3 無效等價類

   對程式的規格說明來說是不合理的或無意義的輸入資料所構成的集合。為了驗證程式做其不應做的事情。
              

   2-4 等價類劃分方法

   （1）按照區間劃分。在輸入條件規定了取值範圍或值得個數的情況下，則可以确立一個有效等價類和兩個無效等價類。
   
   
   
         （2）按照數值劃分。在規定了輸入資料的一組值（假定n），并且程式要對每一個輸入值分别處理的該情況下，可确立n個有效等價類和一個無效等價類。
   
        （3）按照數值集合劃分。在輸入條件規定了輸入值的集合或者規定了“必須如何”的情況下，可确立一個有效等價類和一個無效等價類。
   
         （4）在輸入條件是一個布爾量的情況下，可确定一個有效等價類和一個無效等價類。
   
         （5）進一步細分等價類。在确知已劃分的等價類中各元素在程式進行中的方式不同的情況下，則應再将該等價類進一步地劃分為更小的等價類。
   
         （6）等價類劃分還應特别預設值、空值、NULL、零值的情況。
              

   2-5 等價類的特點

   （1）完備性（全集）（2）無備援性（互不相交的子集） （3）等價性
              

   2-6 等價類測試類型

   單/多缺陷：弱/強等價類
   
        是/否考慮無效等價類：健壯性/一般等價類測試
   
        eg  a≤x1≤d，區間為 [a，b) [b，c) [c，d]；e≤x2≤g ，區間為 [e，f)  [f，g]
   
         （1）弱一般等價類測試：單缺陷，要求選取的測試用例覆寫所有的有效等價類
              

（2）弱一般等價類測試：多缺陷，要求将每個變量的有效等價類做笛卡爾積，設計測試用例覆寫笛卡爾積的每個元素。

（2）弱健壯性等價類測試：弱指基于單缺陷假設，健壯性指考慮了無效值。對有效輸入，使用每個有效等價類的一個值；對無效輸入，測試用例将擁有一個無效值。補充輸入域邊界以外的值（略小于最小值min-1，略大于與最大值max+1）

（3）基于多缺陷假設，并考慮無效輸入

3 基于判定表的測試

3-1 判定表

（1）條件樁：列出了問題的所有條件。

（2）動作樁：列出了問題規定可能采取的操作。（1、2的排列順序通常沒有限制）

（3）條件項：列出針對它的左列條件的取值

（4）動作項：列出在條件項的各種取值情況下應該采取的動作

4.其他測試方法

4-1 因果圖方法：從用自然羽然書寫的程式規格說明的描述中找出因（輸入條件）和果（輸入或程式狀态的改變）之間的關系繪制出因果圖，然後通過因果圖轉換為判定表。

4-2 正交實驗設計法：使用已經造好的正交表來安排适應并進行資料分析的一種方法，目的使用最小的測試用例達到最高的測試覆寫率。

4-3 錯誤推測設計方法：基于經驗和直覺推測程式中所有可能存在的各種錯誤，進而有針對性的設計測試用例

四、 白盒測試常用方法

1.邏輯覆寫測試：根據被測試程式的邏輯結構設計測試用例。

1. 語句覆寫：測試時設計若幹測試用例，運作被測試程式，使程式中的每條可執行語句至少執行一次。

優點：檢查所有語句；結構簡單的代碼測試效果好；容易實作自動測試；代碼覆寫率高；如果是程式塊覆寫，則不涉及程式塊中的源代碼。

缺點：不能檢查出條件語句錯誤、循環語句錯誤；語句率覆寫率看似很高，卻有嚴重缺陷（分支覆寫率）

1. 判定覆寫/分支覆寫：設計若幹測試用例，運作被測試程式，使得程式中每個判斷的取真分支和取假分支至少經曆一次，即判斷的真假值均曾被滿足。（while/switch/異常處理/跳轉語句）

判定覆寫率：已取過“真”和“假”兩個值的判定程式占程式中所有條件判定個數的百分比

優點：分支覆寫比語句覆寫查錯能力強一些：執行了分支覆寫，實際也就執行了語句覆寫

缺點：不能查出條件語句錯誤/邏輯運算錯誤/循環次數錯誤/循環條件錯誤

1. 條件覆寫：設計若幹測試用例，執行被測程式後，要使每個判斷中每個條件的可能取值至少滿足一次，即每個條件至少有一次為真值，有一次為假值

優點：能夠檢查所有的條件錯誤；

缺點：不能實作對每個分支的檢查，用例數量的增加

做到了完全的條件覆寫，并不能保證達到完全的判定覆寫。

做到了完全的判定覆寫也并不能保證達到了完全的條件覆寫==》條件和分支兼顧

1. 判定-條件覆寫：将判定覆寫和條件覆寫結合起來，即設計足夠的測試用例，使得判斷條件中的每個條件的所有可能取值至少執行一次，并且每個判斷本身的可能判定結果也至少執行一次。

優點：既考慮了每一個條件，又考慮了每一個分支，發現錯誤能力強于分支覆寫和條件覆寫。

缺點：并不能全面覆寫所有路徑；用例數量增加

1. 條件組合覆寫：設計足夠的測試用例，運作被測程式，使得所有可能的條件取值組合至少執行一次

優點：滿足了判定覆寫、條件覆寫和條件-判定覆寫

缺點：不能全面覆寫所有路徑

1. 路徑覆寫：設計足夠多的測試用例來覆寫程式中所有可能的路徑（不可能：循環、、、、）

8.路徑測試

1. 基路徑測試：把覆寫的路徑數壓縮到一定限度内，例如程式中的循環體隻執行0次和1次

1-1 程式環路複雜性

a. 設E為控制流圖的邊數，N為圖的節點數，則定義環路複雜性為V（G）=E-N+2

b. 設P為控制流圖中的判定節點數，則由V（G）=P+1

c. 将環路複雜性定義為控制流圖中的區域數（控制流圖外面也要算一個區域）

2-1 獨立路徑：包括一組以前沒有處理的語句或條件的一條路徑

3-1 基本路徑集：控制流圖中所有獨立路徑的集合（路徑數=環路複雜性）

4-1 基路徑測試法：通過分析控制構造的環路複雜性，導出基本可執行路徑集合，進而設計測試用例。設計出的測試用例要保證在測試中的每個可執行語句至少執行一次（路徑數=環路複雜性）。

缺點：測試覆寫并不充分（循環）

1. 循環測試：針對循環的測試

3.資料流測試：基于程式的控制流，從建立的資料目标狀态的序列中發現異常的結構測試方法，資料的定義/引用缺陷。

三、 單元測試

單元：一個可獨立運作的代碼段

    獨立運作：這個工作不受前一次或接下來的程式運作的結果影響，即不與上下文發送關系。

    單元測試方法：靜态/動态

    靜态測試：不需要運作單元代碼，而是對代碼進行逐行的檢測

    動态測試：需要運作被測單元代碼，由于被測單元需要調用其他單元，或者會被其他單元調用。
           

3-1 單元測試的環境

靜态測試：無需搭建測試環境

     動态單元測試：用一些輔助子產品來模拟與所測子產品相聯系的其他子產品，需要在測試之前搭建相應測試環境



      輔助子產品分兩種：

     （1）驅動子產品（Driver）：相當于所測子產品的主程式

     （2）樁子產品（stub）：用于代替所測子產品調用的子子產品

      單元測試三個步驟：模拟輸入->執行單元->檢查驗證輸出
           

3-2 單元測試的政策和方法

1、靜态代碼分析

           代碼走讀：一種交叉檢查，就是自己的代碼由他人來檢查

           代碼審查：以會議的形式展開，由大家根據缺陷檢查表共同稽核代碼的品質

           代碼評審：通常在審查會後進行，審查小組根據記錄和報告進行評估

      2、單元結構測試（主要采用白盒測試）

            關注代碼内部的執行情況，關注代碼執行的覆寫率。

            基于路徑的測試、基于資料流測試。

      3、單元功能測試（基本方法時黑盒測試）

            常用測試方法：邊界測試、等價類測試、因果圖測試
           

四、內建測試

4-1. 基本概念

        內建：把多個單元組合起來形成更大的單元

        內建測試：在假定各個軟體單元已經通過單元測試的前提下，檢查各個軟體單元之間的互相接口是否正确，也叫組裝測試或聯合測試

                         具體檢測包括：功能性驗證、接口測試、全局資料結構的測試以及計算精度檢測等在內建測試時可能出現的錯誤

 4-2. 方法政策

非增量型內建測試：将所有軟體統一內建後才進行整體測試（大棒內建）

增量型內建測試：從一個子產品開始，測一次添加一個子產品，邊組裝邊測試，以發洩與結構相聯系的問題（需要驅動程式或樁程式）

 4-3.基于功能分解的內建

       （1） 自頂向下內建：從最具控制力的主要子產品開始，按照軟體的控制層次結構，以深度優先或廣度優先的政策，向系統中增加子產品，直至實作整個系統， 需要設計樁子產品

      優點：有助于最大限度減少對驅動程式的需求

      缺點：不能很好地支援有限功能的早期釋出

      樁       子產品不能反映真實情況，重要資料不能及時會送到上層子產品，則測試可能并不充分

       （2）自底向上繼承：從程式子產品結構中最底層的子產品開始組裝，按控制層次增強的順序向系統中增加子產品并測試，直至實作整個系統，不需要再編制樁子產品

   優點：減少了對樁子產品的需求

              自底向上增值的方式可以實施多個子產品的并行測試，提高測試效率，且管理友善，測試人員能較好地鎖定軟體故障所在位置。

   缺點：對驅動程式的需求使得測試管理變得複雜起來。進階别的邏輯和資料流在晚期測試，隻有程式最後一個子產品加入時才具有整體形象。

             不能很好地支援有限功能的早期釋出。

       （3） 三明治內建：1和2的結合

 4-4.基于調用圖的內建：以功能分解樹為基礎
           

七、案例

5-1 如何測試一個杯子

5-2 測試web登入界面

   5-3 自動販售機

   5-4 CP指令設計測試用例

       主要從異常、功能、性能三方面考慮

       （1）異常

                參數異常：源和目标參數異常；包含特殊字元；參數超長；指定的位置實際不存在

                拷貝對象異常：非法的執行權限；存儲媒體有破壞；非法的檔案格式和内容；

                執行過程異常：拷貝到一半斷電；拷貝過程中硬碟滿；拷貝過程中源或目的被删除

        （2）功能

                 檔案：不同的檔案大小：1k，2k，10k...；不同的檔案類型：文本，二進制，裝置檔案

                 目錄：包含各種檔案類型；包含子目錄，目錄深度；目錄檔案數量很多；針對檔案和目錄分别驗證拷貝的準确性，完整性

         （3）性能

                  場景：拷貝大檔案；拷貝目錄中存在很多小檔案

                             跨檔案系統間拷貝；跨存儲媒體間拷貝（硬碟到U盤）；構造源的各種磁盤分布（硬碟扇區分布）；并發的執行拷貝

                  關注的性能點：拷貝時間、CPU、記憶體、磁盤IO
           

一、基本概念

定義：軟體測試是為了發現錯誤而執行程式的過程，“尋找錯誤”是測試的目的

使用人工或自動手段運作或測定某個系統的過程，其目的在于檢驗它是否滿足規定的需求或是否弄清預期結果與實際結果之間的差别

軟體測試是一種重要的軟體品質保證活動，測試過程中的活動包括分析軟體和運作軟體，是在軟體投入運作前，對軟體需求分析、設計規格說明和編碼的最終複審，是軟體品質保證的關鍵步驟。

測試：找錯誤（證明程式有錯）

調試：該錯誤（使程式正确）

軟體測試的目的：

（1）測試是程式執行的過程，目的在于發現錯誤

（2）一個好的測試用例在于能發現至今未發現的錯誤

（3）一個成功的測試是發現至今未發現的錯誤的測試

（測試的成功與失敗在于能否發現錯誤，測試不能表能軟體中不存在錯誤，隻能說明軟體中存在錯誤）

通過對軟體錯誤的原因和分布進行歸納，來發現并排除目前軟體産品的缺陷，對在需求和設計過程中存在的問題查缺補漏，進而確定軟體産品的品質；
           

軟體測試的原則：

（1）所有的測試都應追索到使用者的需求：系統中最嚴重的錯誤是導緻程式無法滿足使用者需求的錯誤；

（2）盡早的和不斷的進行軟體測試：需求和設計時初心的缺陷占很大的比例；缺陷的修改成本随着階段的推移而急劇上升；缺陷具有放大的特點

（3）不可能完全的測試
     （4）80-20原則：測試發現的錯誤80%很可能起源于20%的子產品中，應孤立這些疑點子產品重點測試。
     （5）注意測試中的群集現象：在所測程式段中，若發現錯誤數目多，則殘存數目也比較多
     （6）避免測試自己的程式
     （7）設計周密的測試用例
              軟體測試的本質就是針對要測試的内容确定一組測試用例
              測試用例至少包括：
              執行測試用例前：應滿足的前提條件
              輸入
              預期輸出
              設計測試用例時應包括合理的輸入條件和不合理的輸入條件
     （8）回歸測試：程式修改錯誤後必須進行回歸測試，避免引入新的錯誤
     （9）嚴格執行測試計劃：排除測試的随意性
           

軟體測試的對象：

（1）軟體測試貫穿于定義與開發的整個期間

（2）軟體測試的對象

需求規格說明

概要設計規格說明

詳細設計規格說明

源程式

軟體測試分類

是否執行被測試軟體：

靜态測試：不運作被測程式本身，而是通過在對軟體進行分析、檢查和審閱達到測試目的

方法：代碼審查；代碼走查；桌面檢查；技術評審
           

動态測試：值通過運作被測程式，檢查運作結果與預期結果的差異，并分析運作效率和健壯性等性能。由三部分組成：編寫測試用例、執行測試結果、分析程式的輸出結果。

黑盒測試：功能測試/資料驅動測試，是在已知産品所應對應具有的功能的前提下，通過測試來檢測每個功能是否都能正常使用。

白盒測試：結構測試/邏輯驅動測試，是在知道産品内部工作過程的前提下，可通過測試來檢測産品内部動作是否按照規格說明書的規定正常進行。

按照軟體測試的政策和過程分（都是動态測試）：

單元測試：單元測試的對象軟體設計的最小機關——子產品。單元測試的依據是詳細設計描述，單元測試應對子產品内所有重要的控制路徑設計測試用例，以便發現子產品内部的錯誤。單元測試多采用白盒測試技術，系統内多個子產品可以并行的進行。

內建測試：組裝軟體的系統測試技術，按設計要求把通過單元測試的各個子產品組裝在一起之後，進行內建測試以便發現與接口有關的各種錯誤。

系統測試：是在真實或模拟系統運作的環境下，為驗證和确認系統是否達到需求規格說明書規定的需求而對內建的硬體和軟體系統進行的測試

驗收測試：按照項目任務書或合同、供需雙方約定的驗收依據文檔進行的整個系統的評測，決定是否接受或拒絕系統

按測試内容分：

功能測試：根據功能需求進行測試，以确定軟體與軟體功能需求的一緻，功能遺缺和多餘

性能測試：評價一個産品或元件與性能需求是否符合的測試

一、性能測試類型

　　性能測試是通過自動化的測試工具模拟多種正常、峰值以及異常負載條件來對系統的各項性能名額進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結合進行。通過負載測試，确定在各種工作負載下系統的性能，目标是測試當負載逐漸增加時，系統各項性能名額的變化情況。壓力測試是通過确定一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級别的測試。

　　2.負載測試(Load Testing)

　　在給定的測試環境下，通過在被測系統上不斷增加壓力，直到性能名額超過預定名額或某種資源使用已經達到飽和狀态，目的是了解系統性能容量和處理能力極限。負載測試的主要用途是發現系統性能的拐點，尋找系統能夠支援的最大使用者、業務等處理能力的限制。

　　負載測試是在固定測試環境，在其它測試角度(負載方面)不變的情況下，變化一個測試角度并持續增加壓力，檢視系統的性能曲線和處理極限，以及是否有性能瓶頸存在(拐點)。主要意義是從多個不同的測試角度去探測分析系統的性能變化情況，配合性能調優。測試角度可以是并發使用者數、業務量、資料量等不同方面的負載。

　　3.壓力測試(Stress Testing)

　　測試系統在一定飽和狀态下系統能夠處理的會話能力，以及是否出現錯誤，一般用于穩定性測試。

　　可以了解為資源的極限測試。測試關注在資源處于飽和或超負荷的情況下，系統能否正常運作，是一種在極端壓力下的穩定性測試。其主要意義是通過測試、調優保證系統即使在使用者的極端壓力下也不會出錯甚至系統崩潰。

　　壓力測試的目的是調查系統在其資源超負荷的情況下的表現，尤其是對系統的處理時間有什麼影響。這類測試在一種需要在反常數量、頻率或資源的方式下執行系統。目标是通過極限測試方法，發現系統在極限或惡劣環境中自我保護能力。主要驗證系統的可靠性。

　　4.配置測試(Configuration Testing)

　　通過對被測系統的軟硬體環境的調整，了解各種不同環境對性能影響的程度，進而找到系統各項資源的最有配置設定原則。

　　主要用于性能調優，在經過測試獲得了基準測試資料後，進行環境調整(包括硬體配置、網絡、作業系統、應用伺服器、資料庫等)，再将測試結果與基準資料進行對比，判斷調整是否達到最佳狀态。

　　5.并發測試(Concurrency Testing)

　　模拟并發通路，測試多使用者并發通路同一個應用、子產品、資料時是否産生隐藏的并發問題，如記憶體洩漏、線程鎖、資源争用問題。

　　6.可靠性測試(Reliability Testing)

　　通過給系統加載一定的業務壓力的情況下，讓應用持續運作一段時間，測試系統在這種條件下是否能夠穩定運作。

　　需要和壓力測試區分開，兩者的測試環境和測試目的不一樣。壓力測試強調在資源極限情況下系統是否出錯，可靠性測試強調在 一定的業務壓力下長時間(如24×7)運作系統，關注系統的運作情況(如資源使用率是否逐漸增加、響應時間是否越來越慢)，是否有不穩定征兆。

eg：

負載測試：測試一個應用在重負荷下的表現，例如測試一個web站點在大量負荷下，何時系統的響應會退化或失敗

壓力測試：用來評估在超越最大負載的情況下系統将應如何進行

壓力測試的目标就是發現在高負荷條件下應用程式的缺陷
           

疲勞測試：采用系統穩定運作情況下能夠支援的最大并發使用者數，持續一段時間業務，通過綜合分析交易執行名額和資源監控名額來确定系統處理最大量強度性能的過程

相容測試：測試軟體在一個特定的硬體/軟體/作業系統/網絡等環境下性能如何

安全性測試：針對程式中危險防止和危險處理設施進行的測試，以驗證其是否有效

安裝性測試

可用性測試：對“使用者友好性”的測試

主觀的：取決于目标最終使用者和可和

                使用者面談、調查、使用者對話的路線和其他一些技術

                程式員和測試員通常都不宜做可用性測試員
           

注：功能的重點在于能做什麼；性能在于做的如何

缺陷：最終産品和使用者的期望不一緻

功能錯誤

       功能遺漏

       超出需求的部分

       性能不符合要求
           

二、測試模型與過程

1-1 軟體生命周期

   a.大棒開發法

   b.邊改邊寫法

          優點：能夠較為迅速的展現結果，适合需要快速制作并且用完就扔的小項目，如示範程式、示範程式等。

          缺點：其編碼和測試可能是将長期的循環往複的過程



   c.  瀑布法:将軟體生命周期的各項活動，規定為按照固定順序相連的若幹個階段性工作，形如瀑布流水，最終得到軟體産品

   優點：易于了解；調研開發的階段性；強調早期計劃及需求調查；确定何時能傳遞産品及何時進行評審與測試；

   缺點：需求調查分析隻進行一次，不能适應需求變化；順序的開發流程，使得開發中的經驗教訓不能回報到該項目的開發中去；不能反映出軟體開發過程的反複與疊代性；沒有包含類型的風險評估；開發中出現的問題直到開發後期才暴露（測試在後期階段），是以失去及早糾正的機會。



   d. 快速原型法

   根據客戶需求在較短的時間内解決使用者最迫切解決的問題，完成可示範的産品。這個産品隻實作最重要的功能，在得到客戶更加明确的需求之後，原型将丢棄



   e. 螺旋瀑布法

   将瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特别适合于大型複雜的系統。 螺旋模型沿着螺線進行若幹次疊代，圖中的四個象限代表了以下活動：

          （1） 制定計劃：确定軟體目标，標明實施方案，弄清項目開發的限制條件

          （2） 風險分析：分析評估所選方案，考慮如何識别和消除風險；

          （3） 實施工程：實施軟體開發和驗證；

          （4） 客戶評估：評價開發工作，提出修正建議，制定下一步計劃。
           

　　螺旋模型由風險驅動，強調可選方案和限制條件進而支援軟體的重用，有助于将軟體品質作為特殊目标融入産品開發之中。但是，螺旋模型也有一定的限制條件，具體如下：

　　（1） 螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，并做出相關反應是不容易的，是以，這種模型往往适應于内部的大規模軟體開發。

　　（2） 如果執行風險分析将大大影響項目的利潤，那麼進行風險分析毫無意義，是以，螺旋模型隻适合于大規模軟體項目。

　　（3） 軟體開發人員應該擅長尋找可能的風險，準确地分析風險，否則将會帶來更大的風險

　　一個階段首先是确定該階段的目标，完成這些目标的選擇方案及其限制條件，然後從風險角度分析方案的開發政策，努力排除各種潛在的風險，有時需要通過建造原型來完成。如果某些風險不能排除，該方案立即終止，否則啟動下一個開發步驟。最後，評價該階段的結果，并設計下一個階段。

優點：嚴格的全過程風險管理；強調個開發階段的品質；提供機會評估項目是否有價值繼續下去。

2.軟體測試模型

V模型的過程從左到右，描述了基本的開發過程和測試行為。V模型的價值在于它非常明确地标明了測試過程中存在的不同級别，并且清楚地描述了這些測試階段和開發過程期間各階段的對應關系；

   局限性：把測試作為最後一個活動，需求分析前期産生的錯誤直到後期的驗收測試才能發現。

   該模型容易使人了解主要是針對程式進行測試尋找錯誤

   實際中，由于需求變更較大，導緻要重複變更需求、設計、編碼、測試。返工量大。主要用在快速程式的開發





   在V模型中增加軟體開發各開發階段應同步進行的測試，演化為W模型

   開發的是V，測試是與此并行的V；相對于V模型，W模型更科學，強調的是測試伴随整個軟體開發周期，并且測試的對象不僅僅是程式，需求、功能、和設計同樣要測試。測試和開發是同步進行的，有利于盡早的發現問題

   缺點：W和V都把軟體的開發視為需求、設計、編碼等一系列串行的活動，無法支撐疊代、自發性以及變更挑戰

              主要應用在一些中型軟體并且業務邏輯關聯非常緊密的項目中



   H模型中，軟體測試活動完全獨立，貫穿于整個産品的周期，與其他流程并發的進行，某個測試點準備就緒時，就可以從測試準備階段進行到測試執行階段。軟體測試可以盡早的進行，并且可以根據被測物的不同而分層次進行。

   軟體測試是一個獨立的流程，貫穿産品整個生命周期，與其他流程并發進行

   H模型指出軟體測試要盡早準備，盡早執行，不同的測試活動可以是按照某次序先後進行，但也可能是反複的，隻要某個測試達到準備就緒點，測試執行活動就可以開展。



   很好的處理測試與開發的交接過程，交接的過程是一個時間段，而不是一個點。

   左邊描述的是針對單獨程式片段所進行的互相分離的編碼和測試，伺此後将進行頻繁的交接，通過內建最終合成為可執行的程式，然後再對這些可執行的程式進行測試。

   已認證內建測試的産品可以進行封裝并送出給使用者，也可以作為更大規模和範圍内內建的部分，多根并行的曲線表示變更可以在各個部分發生

   X模型還定位了探索性測試，這是不進行實作計劃的特殊測試，給有經驗的測試人員在測試計劃外發現更多軟體缺陷
           

三、 黑盒測試常用方法

1. 邊界值測試：

   1-1 邊界

   a. 數值邊界值：數值範圍
   
         b. 字元邊界值 ：ASCII表
   
          c. 其他邊界條件：預設值、空白、空值、零值、無輸入等情況
              

   1-2 基本思想

   使用輸入變量的最小值、略大于最小值、正常值、略小于最大值和最大值來設計測試用例（min，min+，nom，max-，maz）
   
         單缺陷假設：隻讓一個變量取邊界值，其餘變量取正常值
   
         多缺陷假設：同時讓多個變量取邊界值
   
         （1）邊界值分析（單缺陷）（4N+1）
   
   
   
         （2）健壯性邊界值分析（在異常情況下，軟體還具有正常運作的能力）（增加一個取異常值，其他都正常值的測試用例，6N+1）
   
   
   
         （3）最壞情況測試（多個變量出現極值，最最小值，略大于最小值，正常值，最大值，略小于最大值做笛卡爾乘積，5N）
   
   
   
      （3）健壯性最壞情況測試（7N）
              

2. 等價類測試

   2-1 等價類劃分

   劃分是指互不相交的一組子集，這些子集的并是整個集合
              

   2-2 有效等價類

   是指對于程式的規格說明來說是合理的、有意義的輸入資料構成的集合。利用有效等價類可以驗證程式是否實作了規格說明中的功能和性能。
              

   2-3 無效等價類

   對程式的規格說明來說是不合理的或無意義的輸入資料所構成的集合。為了驗證程式做其不應做的事情。
              

   2-4 等價類劃分方法

   （1）按照區間劃分。在輸入條件規定了取值範圍或值得個數的情況下，則可以确立一個有效等價類和兩個無效等價類。
   
   
   
         （2）按照數值劃分。在規定了輸入資料的一組值（假定n），并且程式要對每一個輸入值分别處理的該情況下，可确立n個有效等價類和一個無效等價類。
   
        （3）按照數值集合劃分。在輸入條件規定了輸入值的集合或者規定了“必須如何”的情況下，可确立一個有效等價類和一個無效等價類。
   
         （4）在輸入條件是一個布爾量的情況下，可确定一個有效等價類和一個無效等價類。
   
         （5）進一步細分等價類。在确知已劃分的等價類中各元素在程式進行中的方式不同的情況下，則應再将該等價類進一步地劃分為更小的等價類。
   
         （6）等價類劃分還應特别預設值、空值、NULL、零值的情況。
              

   2-5 等價類的特點

   （1）完備性（全集）（2）無備援性（互不相交的子集） （3）等價性
              

   2-6 等價類測試類型

   單/多缺陷：弱/強等價類
   
        是/否考慮無效等價類：健壯性/一般等價類測試
   
        eg  a≤x1≤d，區間為 [a，b) [b，c) [c，d]；e≤x2≤g ，區間為 [e，f)  [f，g]
   
         （1）弱一般等價類測試：單缺陷，要求選取的測試用例覆寫所有的有效等價類
              

（2）弱一般等價類測試：多缺陷，要求将每個變量的有效等價類做笛卡爾積，設計測試用例覆寫笛卡爾積的每個元素。

（2）弱健壯性等價類測試：弱指基于單缺陷假設，健壯性指考慮了無效值。對有效輸入，使用每個有效等價類的一個值；對無效輸入，測試用例将擁有一個無效值。補充輸入域邊界以外的值（略小于最小值min-1，略大于與最大值max+1）

（3）基于多缺陷假設，并考慮無效輸入

3 基于判定表的測試

3-1 判定表

（1）條件樁：列出了問題的所有條件。

（2）動作樁：列出了問題規定可能采取的操作。（1、2的排列順序通常沒有限制）

（3）條件項：列出針對它的左列條件的取值

（4）動作項：列出在條件項的各種取值情況下應該采取的動作

4.其他測試方法

4-1 因果圖方法：從用自然羽然書寫的程式規格說明的描述中找出因（輸入條件）和果（輸入或程式狀态的改變）之間的關系繪制出因果圖，然後通過因果圖轉換為判定表。

4-2 正交實驗設計法：使用已經造好的正交表來安排适應并進行資料分析的一種方法，目的使用最小的測試用例達到最高的測試覆寫率。

4-3 錯誤推測設計方法：基于經驗和直覺推測程式中所有可能存在的各種錯誤，進而有針對性的設計測試用例

四、 白盒測試常用方法

1.邏輯覆寫測試：根據被測試程式的邏輯結構設計測試用例。

1. 語句覆寫：測試時設計若幹測試用例，運作被測試程式，使程式中的每條可執行語句至少執行一次。

優點：檢查所有語句；結構簡單的代碼測試效果好；容易實作自動測試；代碼覆寫率高；如果是程式塊覆寫，則不涉及程式塊中的源代碼。

缺點：不能檢查出條件語句錯誤、循環語句錯誤；語句率覆寫率看似很高，卻有嚴重缺陷（分支覆寫率）

1. 判定覆寫/分支覆寫：設計若幹測試用例，運作被測試程式，使得程式中每個判斷的取真分支和取假分支至少經曆一次，即判斷的真假值均曾被滿足。（while/switch/異常處理/跳轉語句）

判定覆寫率：已取過“真”和“假”兩個值的判定程式占程式中所有條件判定個數的百分比

優點：分支覆寫比語句覆寫查錯能力強一些：執行了分支覆寫，實際也就執行了語句覆寫

缺點：不能查出條件語句錯誤/邏輯運算錯誤/循環次數錯誤/循環條件錯誤

1. 條件覆寫：設計若幹測試用例，執行被測程式後，要使每個判斷中每個條件的可能取值至少滿足一次，即每個條件至少有一次為真值，有一次為假值

優點：能夠檢查所有的條件錯誤；

缺點：不能實作對每個分支的檢查，用例數量的增加

做到了完全的條件覆寫，并不能保證達到完全的判定覆寫。

做到了完全的判定覆寫也并不能保證達到了完全的條件覆寫==》條件和分支兼顧

1. 判定-條件覆寫：将判定覆寫和條件覆寫結合起來，即設計足夠的測試用例，使得判斷條件中的每個條件的所有可能取值至少執行一次，并且每個判斷本身的可能判定結果也至少執行一次。

優點：既考慮了每一個條件，又考慮了每一個分支，發現錯誤能力強于分支覆寫和條件覆寫。

缺點：并不能全面覆寫所有路徑；用例數量增加

1. 條件組合覆寫：設計足夠的測試用例，運作被測程式，使得所有可能的條件取值組合至少執行一次

優點：滿足了判定覆寫、條件覆寫和條件-判定覆寫

缺點：不能全面覆寫所有路徑

1. 路徑覆寫：設計足夠多的測試用例來覆寫程式中所有可能的路徑（不可能：循環、、、、）

8.路徑測試

1. 基路徑測試：把覆寫的路徑數壓縮到一定限度内，例如程式中的循環體隻執行0次和1次

1-1 程式環路複雜性

a. 設E為控制流圖的邊數，N為圖的節點數，則定義環路複雜性為V（G）=E-N+2

b. 設P為控制流圖中的判定節點數，則由V（G）=P+1

c. 将環路複雜性定義為控制流圖中的區域數（控制流圖外面也要算一個區域）

2-1 獨立路徑：包括一組以前沒有處理的語句或條件的一條路徑

3-1 基本路徑集：控制流圖中所有獨立路徑的集合（路徑數=環路複雜性）

4-1 基路徑測試法：通過分析控制構造的環路複雜性，導出基本可執行路徑集合，進而設計測試用例。設計出的測試用例要保證在測試中的每個可執行語句至少執行一次（路徑數=環路複雜性）。

缺點：測試覆寫并不充分（循環）

1. 循環測試：針對循環的測試

3.資料流測試：基于程式的控制流，從建立的資料目标狀态的序列中發現異常的結構測試方法，資料的定義/引用缺陷。

三、 單元測試

單元：一個可獨立運作的代碼段

    獨立運作：這個工作不受前一次或接下來的程式運作的結果影響，即不與上下文發送關系。

    單元測試方法：靜态/動态

    靜态測試：不需要運作單元代碼，而是對代碼進行逐行的檢測

    動态測試：需要運作被測單元代碼，由于被測單元需要調用其他單元，或者會被其他單元調用。
           

3-1 單元測試的環境

靜态測試：無需搭建測試環境

     動态單元測試：用一些輔助子產品來模拟與所測子產品相聯系的其他子產品，需要在測試之前搭建相應測試環境



      輔助子產品分兩種：

     （1）驅動子產品（Driver）：相當于所測子產品的主程式

     （2）樁子產品（stub）：用于代替所測子產品調用的子子產品

      單元測試三個步驟：模拟輸入->執行單元->檢查驗證輸出
           

3-2 單元測試的政策和方法

1、靜态代碼分析

           代碼走讀：一種交叉檢查，就是自己的代碼由他人來檢查

           代碼審查：以會議的形式展開，由大家根據缺陷檢查表共同稽核代碼的品質

           代碼評審：通常在審查會後進行，審查小組根據記錄和報告進行評估

      2、單元結構測試（主要采用白盒測試）

            關注代碼内部的執行情況，關注代碼執行的覆寫率。

            基于路徑的測試、基于資料流測試。

      3、單元功能測試（基本方法時黑盒測試）

            常用測試方法：邊界測試、等價類測試、因果圖測試
           

四、內建測試

4-1. 基本概念

        內建：把多個單元組合起來形成更大的單元

        內建測試：在假定各個軟體單元已經通過單元測試的前提下，檢查各個軟體單元之間的互相接口是否正确，也叫組裝測試或聯合測試

                         具體檢測包括：功能性驗證、接口測試、全局資料結構的測試以及計算精度檢測等在內建測試時可能出現的錯誤

 4-2. 方法政策

非增量型內建測試：将所有軟體統一內建後才進行整體測試（大棒內建）

增量型內建測試：從一個子產品開始，測一次添加一個子產品，邊組裝邊測試，以發洩與結構相聯系的問題（需要驅動程式或樁程式）

 4-3.基于功能分解的內建

       （1） 自頂向下內建：從最具控制力的主要子產品開始，按照軟體的控制層次結構，以深度優先或廣度優先的政策，向系統中增加子產品，直至實作整個系統， 需要設計樁子產品

      優點：有助于最大限度減少對驅動程式的需求

      缺點：不能很好地支援有限功能的早期釋出

      樁       子產品不能反映真實情況，重要資料不能及時會送到上層子產品，則測試可能并不充分

       （2）自底向上繼承：從程式子產品結構中最底層的子產品開始組裝，按控制層次增強的順序向系統中增加子產品并測試，直至實作整個系統，不需要再編制樁子產品

   優點：減少了對樁子產品的需求

              自底向上增值的方式可以實施多個子產品的并行測試，提高測試效率，且管理友善，測試人員能較好地鎖定軟體故障所在位置。

   缺點：對驅動程式的需求使得測試管理變得複雜起來。進階别的邏輯和資料流在晚期測試，隻有程式最後一個子產品加入時才具有整體形象。

             不能很好地支援有限功能的早期釋出。

       （3） 三明治內建：1和2的結合

 4-4.基于調用圖的內建：以功能分解樹為基礎
           

七、案例

5-1 如何測試一個杯子

5-2 測試web登入界面

   5-3 自動販售機

   5-4 CP指令設計測試用例

       主要從異常、功能、性能三方面考慮

       （1）異常

                參數異常：源和目标參數異常；包含特殊字元；參數超長；指定的位置實際不存在

                拷貝對象異常：非法的執行權限；存儲媒體有破壞；非法的檔案格式和内容；

                執行過程異常：拷貝到一半斷電；拷貝過程中硬碟滿；拷貝過程中源或目的被删除

        （2）功能

                 檔案：不同的檔案大小：1k，2k，10k...；不同的檔案類型：文本，二進制，裝置檔案

                 目錄：包含各種檔案類型；包含子目錄，目錄深度；目錄檔案數量很多；針對檔案和目錄分别驗證拷貝的準确性，完整性

         （3）性能

                  場景：拷貝大檔案；拷貝目錄中存在很多小檔案

                             跨檔案系統間拷貝；跨存儲媒體間拷貝（硬碟到U盤）；構造源的各種磁盤分布（硬碟扇區分布）；并發的執行拷貝

                  關注的性能點：拷貝時間、CPU、記憶體、磁盤IO