測試理論

一、基本概念

定義:軟體測試是為了發現錯誤而執行程式的過程,“尋找錯誤”是測試的目的
           使用人工或自動手段執行或測定某個系統的過程,其目的在於檢驗它是否滿足規定的需求或是否弄清預期結果與實際結果之間的差別
          軟體測試是一種重要的軟體質量保證活動,測試過程中的活動包括分析軟體和執行軟體,是在軟體投入執行前,對軟體需求分析、設計規格說明和編碼的最終複審,是軟體質量保證的關鍵步驟。
測試:找錯誤(證明程式有錯)
除錯:該錯誤(使程式正確)
軟體測試的目的:
       (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.邏輯覆蓋測試:根據被測試程式的邏輯結構設計測試用例。

2. 語句覆蓋:測試時設計若干測試用例,執行被測試程式,使程式中的每條可執行語句至少執行一次。

優點:檢查所有語句;結構簡單的程式碼測試效果好;容易實現自動測試;程式碼覆蓋率高;如果是程式塊覆蓋,則不涉及程式塊中的原始碼。

缺點:不能檢查出條件語句錯誤、迴圈語句錯誤;語句率覆蓋率看似很高,卻有嚴重缺陷(分支覆蓋率)

3. 判定覆蓋/分支覆蓋:設計若干測試用例,執行被測試程式,使得程式中每個判斷的取真分支和取假分支至少經歷一次,即判斷的真假值均曾被滿足。(while/switch/異常處理/跳轉語句)

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

優點:分支覆蓋比語句覆蓋查錯能力強一些:執行了分支覆蓋,實際也就執行了語句覆蓋

缺點:不能查出條件語句錯誤/邏輯運算錯誤/迴圈次數錯誤/迴圈條件錯誤

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

優點:能夠檢查所有的條件錯誤;

缺點:不能實現對每個分支的檢查,用例數量的增加

做到了完全的條件覆蓋,並不能保證達到完全的判定覆蓋。

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

5. 判定-條件覆蓋:將判定覆蓋和條件覆蓋結合起來,即設計足夠的測試用例,使得判斷條件中的每個條件的所有可能取值至少執行一次,並且每個判斷本身的可能判定結果也至少執行一次。

優點:既考慮了每一個條件,又考慮了每一個分支,發現錯誤能力強於分支覆蓋和條件覆蓋。

缺點:並不能全面覆蓋所有路徑;用例數量增加

6. 條件組合覆蓋:設計足夠的測試用例,執行被測程式,使得所有可能的條件取值組合至少執行一次

優點:滿足了判定覆蓋、條件覆蓋和條件-判定覆蓋

缺點:不能全面覆蓋所有路徑

7. 路徑覆蓋:設計足夠多的測試用例來覆蓋程式中所有可能的路徑(不可能:迴圈、、、、)

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 基路徑測試法:通過分析控制構造的環路複雜性,匯出基本可執行路徑集合,從而設計測試用例。設計出的測試用例要保證在測試中的每個可執行語句至少執行一次(路徑數=環路複雜性)。

缺點:測試覆蓋並不充分(迴圈)

2. 迴圈測試:針對迴圈的測試

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.邏輯覆蓋測試:根據被測試程式的邏輯結構設計測試用例。

2. 語句覆蓋:測試時設計若干測試用例,執行被測試程式,使程式中的每條可執行語句至少執行一次。

優點:檢查所有語句;結構簡單的程式碼測試效果好;容易實現自動測試;程式碼覆蓋率高;如果是程式塊覆蓋,則不涉及程式塊中的原始碼。

缺點:不能檢查出條件語句錯誤、迴圈語句錯誤;語句率覆蓋率看似很高,卻有嚴重缺陷(分支覆蓋率)

3. 判定覆蓋/分支覆蓋:設計若干測試用例,執行被測試程式,使得程式中每個判斷的取真分支和取假分支至少經歷一次,即判斷的真假值均曾被滿足。(while/switch/異常處理/跳轉語句)

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

優點:分支覆蓋比語句覆蓋查錯能力強一些:執行了分支覆蓋,實際也就執行了語句覆蓋

缺點:不能查出條件語句錯誤/邏輯運算錯誤/迴圈次數錯誤/迴圈條件錯誤

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

優點:能夠檢查所有的條件錯誤;

缺點:不能實現對每個分支的檢查,用例數量的增加

做到了完全的條件覆蓋,並不能保證達到完全的判定覆蓋。

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

5. 判定-條件覆蓋:將判定覆蓋和條件覆蓋結合起來,即設計足夠的測試用例,使得判斷條件中的每個條件的所有可能取值至少執行一次,並且每個判斷本身的可能判定結果也至少執行一次。

優點:既考慮了每一個條件,又考慮了每一個分支,發現錯誤能力強於分支覆蓋和條件覆蓋。

缺點:並不能全面覆蓋所有路徑;用例數量增加

6. 條件組合覆蓋:設計足夠的測試用例,執行被測程式,使得所有可能的條件取值組合至少執行一次

優點:滿足了判定覆蓋、條件覆蓋和條件-判定覆蓋

缺點:不能全面覆蓋所有路徑

7. 路徑覆蓋:設計足夠多的測試用例來覆蓋程式中所有可能的路徑(不可能:迴圈、、、、)

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 基路徑測試法:通過分析控制構造的環路複雜性,匯出基本可執行路徑集合,從而設計測試用例。設計出的測試用例要保證在測試中的每個可執行語句至少執行一次(路徑數=環路複雜性)。

缺點:測試覆蓋並不充分(迴圈)

2. 迴圈測試:針對迴圈的測試

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