總結是對某一特定時間段內的學習和工作生活等表現情況加以回顧和分析的一種書面材料，它能夠使頭腦更加清醒，目標更加明確，讓我們一起來學習寫總結吧。那么我們該如何寫一篇較為完美的總結呢？下面是小編為大家帶來的總結書優秀范文，希望大家可以喜歡。

軟件測試總結與建議 軟件測試總結自己的不足之處篇一

姓名：某某 學號：20090001 在大慶浦東軟件平臺有限公司經過一周的軟件測試實訓，從對軟件測試沒有什么經驗的我初步掌握了軟件測試的方法和技能，收獲頗多。

我在大學期間的專業是信息與計算科學，原本打算從事網絡方面的工作，對活動目錄、數據庫、操作系統等的知識比較感興趣。經過這次理論學習，了解到要做好軟件測試，要求掌握的知識并不僅僅是測試方面的，網絡、數據庫、操作系統等的知識對做好測試也是很有幫助的。這讓我明確了以后學習的目標，在不斷學習軟件測試的同時，也應該繼續其他相關知識的深入學習。通過此次學習，對整個軟件測試行業的了解大大的加深。以前認為軟件測試只是枯燥的反復的使用被測試軟件來發現異常的問題，以為軟件測試并不重要，低開發一等。現在認識到了軟件測試的重要性，軟件測試是軟件產業向軟件工業化生產時代邁進不可缺少的重要組成部分，是保證軟件質量達到客戶需求不可缺少的環節。軟件測試在國內是一個新的職業，發展得比較晚，但它的重要性正在為行業所重視。

在學習過程中，我了解了作為一個合格的測試人員所應具備的素質與技能。其中個人素質在測試工作中起到了非常重要的作用，它包括你的信心、耐心、細心和與人交流溝通的能力，它將貫穿你工作生涯的整個過程。在測試理論上，我們系統學習了軟件測試的流程，各種測試階段和測試方法，以及測試工具的使用。通過這些課程的學習，讓我們對軟件工程也有了更深刻的理解，為以后的測試工作作了很好的理論儲備和技能的提升。

軟件測試作為軟件開發過程中一個非常重要的環節，越來越成為軟件開發商和用戶關注的焦點。完善的測試是軟件質量的保證，因此軟件測試就成了一項重要而艱巨的工作，要做好這項工作當然也絕非易事，我在做軟件測試工作中總結出了一些經驗和技巧。1.功能點的細化

在進行測試前，先將所要測試的功能細分，填寫《測試用例表》，有針對性的運行功能測試案例，逐個對每個功能細分點進行測試。在每次運行測試案例之前，明確此次運行的目的和預期的輸出結果，并要做好記錄。2.注意測試中的錯誤集中發生的現象

有一些錯誤是和程序開發人員的編程水平和習慣有很大關系的。例如程序中的拼寫錯誤，習慣用法等。注意收集并記錄這些現象，有助于更快、更多地發現類似的錯誤。

3.盡可能多的使用非常規的測試 充分考慮到各種合法的輸入和不合法的輸入以及各種邊界條件。邊界值往往是最容易出現異常的情況，特殊的情況下甚至要制造極端的狀態和意外狀態，比如網絡突然中斷，和電源突然斷電等情況。

4.對測試錯誤結果一定要有一個確認的過程

一般有a測試出來的錯誤，一定要有一個b來確認。5.制定嚴格的測試計劃

測試時間安排的盡量寬松，不要希望在極短的時間內完成一個高水平的測試。6.回歸測試的關聯性一定要引起充分的注意

在開發人員剛修復bug之后的地方，再找一找，往往開發人員只修復報告出來的缺陷而不去考慮別的功能在修改時可能會重新造成錯誤。修改一個錯誤而引起更多的錯誤出現的現象并不少見。

7.測試文檔要盡可能詳細

《測試用例表》中的功能點可盡量的詳細，如實、詳細地記錄每次運行測試案例的輸入數據，輸出數據，出錯提示，進行測試的時間，完成測試的時間等，便于以后對測試工作的回溯。8.重視交流和溝通

包括和程序開發人員的交流，同是測試人員之間的交流，網上技術論壇和網友的交流，和客戶的交流等。多思考，多交流，多提問，通過多種溝通交流的途徑，可以少走很多彎路，同時可以學到很多東西。9.善于總結

在測試過程中發現的所有問題，異常情況，發現程序開發人員易犯，常犯的錯誤，各種有價值的經驗教訓，使用系統和操作數據庫時發現或者學到的技巧，使用測試工具時的心得等等，都可以隨手記錄在筆記本或者電腦上。這些都將是今后工作中可以參照的珍貴資料，同時也會成為自己的寶貴經驗。10.妥善保存一切測試過程文檔。

這次軟件測試實訓為我們以后從事軟件測試工作打下了良好的專業基礎，為我們的進一步學習提高打下了扎實的理論基礎。對測試過程有了初步的認識，測試計劃、測試設計、測試開發、測試執行、測試評估、測試報告貫穿整個軟件開發過程。單元測試、集成測試、系統測試、驗證測試每個階段都應以用戶需求為依據。這些基本的概念雖然比較抽象，但對以后的實踐是大有益處的。總的來說，這次培訓效果不錯，對自己有一定的提升，這完全不同與學校的學習，因為它更加貼近工作，針對以后工作的內容作了很多實例的練習與工具的使用，為我們更快的加入工作提供的很好的前提。接下來一段時間，我將利用假期進入相關測試部門進行實際項目的訓練，我相信在我有了很好的理論基礎后，會在工作中很好的加以應用，讓測試工作做得更好。同時，我會更加努力的學習與工作，遇到問題會及時多渠道尋找解決方法，積極上進，希望早日成為一名優秀的測試人員。

軟件測試總結與建議 軟件測試總結自己的不足之處篇二

面向對象程序的軟件測試方法

在軟件生命周期過程中，軟件測試是保證軟件質量的關鍵環節之一。面向對象方法學在軟件工程中的引入極大地方便了軟件的設計、開發和維護，為創建高可靠性的軟件系統提供了重要保證。但面向對象程序的封裝、繼承、多態和異常處理機制等新特性卻給測試帶來新的挑戰。一方面需要調整、改進傳統的測試策略和方法；另一方面探索出適應面向對象程序特征的測試理論與技術也尤為必要。

面向對象(object oriented,oo)是當前計算機界關心的重點，它是90年代軟件開發方法的主流。面向對象的概念和應用已超越了程序設計和軟件開發，擴展到很寬的范圍。如數據庫系統、交互式界面、應用結構、應用平臺、分布式系統、網絡管理結構、cad技術、人工智能等領域。

面向對象的定義或說明對象的定義的非常少。其初，“面向對象”是專指在程序設計中采用封裝、繼承、抽象等設計方法。可是，這個定義顯然不能再適合現在情況。面向對象的思想已經涉及到軟件開發的各個方面。如，面向對象的分析（ooa，object oriented analysis），面向對象的設計（ood，object oriented design）、以及我們經常說的面向對象的編程實現（oop，object oriented programming）。許多有關面向對象的文章都只是講述在面向對象的開發中所需要注意的問題或所采用的比較好的設計方法。看這些文章只有真正懂得什么是對象，什么是面向對象，才能最大程度地對自己有所裨益。這一點，恐怕對初學者甚至是從事相關工作多年的人員也會對它們的概念模糊不清。

1、面向對象的基本概念

(1)對象。

對象是人們要進行研究的任何事物，從最簡單的整數到復雜的飛機等均可看作對象，它不僅能表示具體的事物，還能表示抽象的規則、計劃或事件。

(2)對象的狀態和行為。

對象具有狀態，一個對象用數據值來描述它的狀態。

對象還有操作，用于改變對象的狀態，對象及其操作就是對象的行為。

對象實現了數據和操作的結合，使數據和操作封裝于對象的統一體中

(3)類。具有相同或相似性質的對象的抽象就是類。因此，對象的抽象是類，類的具體化就是對象，也可以說類的實例是對象。

類具有屬性，它是對象的狀態的抽象，用數據結構來描述類的屬性。

類具有操作，它是對象的行為的抽象，用操作名和實現該操作的方法來描述。

(4)類的結構。

在客觀世界中有若干類，這些類之間有一定的結構關系。通常有兩種主要的結構關系，即一般--具體結構關系，整體--部分結構關系。

①一般——具體結構稱為分類結構，也可以說是“或”關系，或者是“is a”關系。

②整體——部分結構稱為組裝結構，它們之間的關系是一種“與”關系，或者是“has a”關系。

(5)消息和方法。

對象之間進行通信的結構叫做消息。在對象的操作中，當一個消息發送給某個對象時，消息包含接收對象去執行某種操作的信息。發送一條消息至少要包括說明接受消息的對象名、發送給該對象的消息名（即對象名、方法名）。一般還要對參數加以說明，參數可以是認識該消息的對象所知道的變量名，或者是所有對象都知道的全局變量名。

類中操作的實現過程叫做方法，一個方法有方法名、參數、方法體。消

2、面向對象的特征

(1)對象唯一性。

每個對象都有自身唯一的標識，通過這種標識，可找到相應的對象。在對象的整個生命期中，它的標識都不改變，不同的對象不能有相同的標識。

(2)分類性。

分類性是指將具有一致的數據結構(屬性)和行為(操作)的對象抽象成類。一個類就是這樣一種抽象，它反映了與應用有關的重要性質，而忽略其他一些無關內容。任何類的劃分都是主觀的，但必須與具體的應用有關。

(3)繼承性。

繼承性是子類自動共享父類數據結構和方法的機制，這是類之間的一種關系。在定義和實現一個類的時候，可以在一個已經存在的類的基礎之上來進行，把這個已經存在的類所定義的內容作為自己的內容，并加入若干新的內容。繼承性是面向對象程序設計語言不同于其它語言的最重要的特點，是其他語言所沒有的。

在類層次中，子類只繼承一個父類的數據結構和方法，則稱為單重繼承。

在類層次中，子類繼承了多個父類的數據結構和方法，則稱為多重繼承。

在軟件開發中，類的繼承性使所建立的軟件具有開放性、可擴充性，這是信息組織與分類的行之有效的方法，它簡化了對象、類的創建工作量，增加了代碼的可重性。

采用繼承性，提供了類的規范的等級結構。通過類的繼承關系，使公共的特性能夠共享，提高了軟件的重用性。

(4)多態性(多形性)多態性使指相同的操作或函數、過程可作用于多種類型的對象上并獲得不同的結果。不同的對象，收到同一消息可以產生不同的結果，這種現象稱為多態性。

多態性允許每個對象以適合自身的方式去響應共同的消息。

多態性增強了軟件的靈活性和重用性。

面向對象方法的基本思想是一：面向對象方法是一種運用對象、類、封裝、繼承、多態和消息等概念來構造、測試、重構軟件的方法。

二： 面向對象方法是以認識論為基礎，用對象來理解和分析問題空間，并設計和開發出由對象構成的軟件系統（解空間）的方法。由于問題空間和解空間都是由對象組成的，這樣可以消除由于問題空間和求解空間結構上的不一致帶來的問題。簡言之，面向對象就是面向事情本身，面向對象的分析過程就是認識客觀世界的過程。

面向對象方法從對象出發，發展出對象，類，消息，繼承等概念。

面向對象方法的主要優點是：符合人們通常的思維方式；從分析到設計再到編碼采用一致的模型表示具有高度連續性；軟件重用性好。

面向對象軟件測試的特點是: 1.掌握代碼檢查、走查與評審的基本方法和技術； 2.掌握白盒測試和黑盒測試的測試用例的設計原則和方法； 3.掌握單元測試和集成測試的基本策略和方法；

4.了解系統測試、性能測試和可靠性測試的基本概念和方法； 5.了解面向對象軟件和web應用軟件測試的基本概念和方法； 6.掌握軟件測試過程管理的基本知識和管理方法； 7.熟悉軟件測試的標準和文檔；

8.掌握qesuite軟件測試過程管理平臺和qesat/c++軟件分析和工具的使用方法。

軟件測試總結與建議 軟件測試總結自己的不足之處篇三

1.軟件測試定義：由人工或自動方法來執行或評價系統或系統部分的過程，以驗證它是否滿足規定的需求，或識別出期望的結果和實際結果之間的差異。2.軟件測試的分類：

測試對象或范圍分類：需求評審、設計評審、單元測試、程序測試、系統

測試、文檔測試、web應用測試、客戶端測試、數據庫測試等；

測試目的分類：集成測試、功能測試、壓力測試、性能測試等等； 靜態測試、動態測試； 白盒測試、黑盒測試。3.軟件測試的基本流程與原則

基本流程：

測試用例設計-輸入數據、預期結果； 測試執行-輸入數據執行被測對象； 檢查實際輸出與預期結果。基本原則：

開始測試時認定軟件有錯，測試要證明有錯； 測試應該由獨立的測試團隊來完成； 測試設計必須設計對應的預期輸出；

要對合理、不合理（有效、無效）輸入數據都進行測試； 檢查軟件的完備性、多余； 完整保留測試文檔；

一個被測對象中有錯誤的概率與已發現錯誤的個數成正比。測試成熟度級別：

0級：沒有區分測試與調試；

1級：測試的目的是證明軟件能用； 2級：測試的目的是證明軟件不能用；

3級：測試的目的不是為了證明什么，而是為了降低軟件使用風險； 4級：測試是一種智能訓練，能夠幫助專業人員開發出更高質量的軟件。5.軟件測試與軟件工程，軟件過程的關系：

軟件工程：在給定的條件下（成本、時間）開發出高質量的軟件產品。軟件生產過程的特性決定了軟件產品中不可避免包含有錯誤。軟件測試則是盡可能多地發現錯誤，從而保障軟件產品的質量。的質量因素：

產品修改：

可維護性，靈活性，可測試性 產品轉移：

可移植性，可復用性，互操作性 產品運行：

正確性，易用性，可靠性，效率，完整性 7.軟件質量困境

軟件質量必須足夠好：存在價值

軟件產品無法完美：需要消耗過多的資源、時間、成本

軟件開發需要在兩個極端之間進行平衡：軟件足夠好的同時又不完美。8.質量控制、質量保證和質量管理

軟件質量控制其實是基本方法，通過一系列的技術來科學地測量過程的狀態。如缺陷率、測試覆蓋率等。

軟件質量保證則是過程的參考、指南的集合，如iso9000、cmm/cmmi等，著重內部的檢查，確保已獲取認可的標準和步驟都已經遵循。

軟件質量管理則是實際操作的思想，質量管理控制和協調組織的質量活動，包括質量控制、質量保證和質量改進。應用的屬性：

網絡密集型應用；并發性；大負載量；性能；高可靠性、高可用性；安全性-內容敏感；

10.軟件評審的目的，評審度量及其應用

評審的目標在于：盡早發現軟件過程中的錯誤，防止錯誤傳遞、蔓延至后續活動，防止錯誤轉化為缺陷。

準備工作量ep-實際評審會之前所需工作量； 評估工作量ea-實際評審所花費的工作量 返工工作量er-修改評審所發現錯誤的工作量 工作產品規模wps-評審對象的規模

發現的主要錯誤數errmajor-多于預期的改錯工作量的錯誤數目 發現的次要錯誤數errminor-少于預期的改錯工作量的錯誤數目 總評審工作量ereview = ep+ea+er 錯誤總數errtot = errmajor+errminor 錯誤密度：評審的每單位工作產品發現的錯誤數ed = errtot / wps 錯誤密度數值的含義：較小（產品質量非常好或評審不夠徹底）；較大（產品質量存在缺陷）

11.軟件測試計劃：描述對計算機軟件配置項、子系統、系統進行測試的計劃安排，內容包括測試的環境、測試工作的標識及測試工作的時間安排。

軟件測試報告：是對計算機軟件配置項、軟件系統或子系統，或與軟件相關項目執行合格性測試的記錄 12.軟件測試活動

制訂測試計劃（測試分析員）

測試設計（測試設計人員）－方案設計 測試及測試用例設計 測試過程

樁模塊、驅動模塊設計

測試實施（測試設計員）－實現測試設計 單元測試（測試員）集成測試（測試員）系統測試（測試員）

評估測試（測試設計人員）

13.無向圖的相關定義：

連接性：節點ni、nj是連接的，當且僅當ni、nj在同一條路徑上。組件：圖的組件是相連節點的最大集合

圖g的圈復雜度v（g)＝e－n＋2p，其中e為g的邊數，n為節點數，p為組件數。14.圖覆蓋：給定一個關于圖g的準則c的測試需求集合tr，測試集合t在圖g上滿足準則c當且僅當對tr中每個測試需求tr，path(t)中至少存在一條測試路徑p滿足tr。

簡單路徑：如果從ni到nj的一條路徑中，除了始節點和終節點可以相同外，沒有任何節點出現次數多于一次，則該路徑為簡單路徑。

主路徑：如果從ni到nj是一條簡單路徑，并且它不作為任何其他簡單路徑的子路徑出現，則稱之為主路徑。

主路徑覆蓋（ppc）準則：tr包含圖中每一條主路徑。

指定路徑覆蓋（spc)：tr包含一個測試路徑集s，s為指定參數。15.白盒測試方法

白盒測試：根據被測對象的內部結構和運行機制來設計測試用例的方法，又稱為結構測試、邏輯驅動測試、覆蓋測試

被測對象的獨立路徑至少覆蓋一次； 所有邏輯取值測試[真、假]； 循環邊界測試；

檢查內部數據結構、邊界條件。16.黑盒測試方法

黑盒測試方法又稱功能測試方法、數據驅動測試方法，測試設計時不考慮被測對象的內部結構，以檢查系統功能（功能的正確、完整、邏輯流程、人機界面、文檔內容、系統安裝/初始化）

以被測對象的外部特征為測試依據。17.模糊測試方法

模糊測試方法：構造大量的隨機數據作為系統的輸入，從而檢驗系統在各種數據情況下是否出現問題。

18.增量測試：單元測試、調用依賴的模塊集成測試，逐步擴展直到形成整個軟件系統。

19.突擊測試：所有模塊一次性集成為一個完整的系統，然后進行完全測試。20.等價類劃分：

等價類劃分基于對輸入或輸出數據情況的評估，劃分成兩個或多個子集（等價類），然后從每個子集中選取一定的代表進行測試的測試用例設計方法。21.極限測試

極限編程：利用輕量、敏捷的開發過程，使開發人員能夠更快地完成應用程序的開發。強調頻繁測試、測試驅動的方式保證軟件質量。

極限測試：為滿足極限編程思想和過程而設計的一套測試策略和流程，原來的測試技術、方法均可以使用 22.配置項測試的內容

功能: 適合性

準確性：功能的準確與精度要求 互操作性：與外部設備、系統的接口 安全保密性：數據訪問的可控制性 可靠性: 成熟性：容錯處理、平均無故障時間

容錯性：邊界條件、功能、性能的降級情況、誤操作模式、故障模式 易恢復性：自動修復能力/時間、平均宕機時間、平均恢復時間、恢復能力等 易用性

易理解性：功能描述清晰、準確；界面含義精確

易學性：在線幫助、幫助定位、各類手冊的易學、易用 易操作性：數據的有效檢查、解釋信息明確、界面切換 吸引性：人機界面定制 效率

時間特性：響應時間、平均響應時間、響應極限時間、吞吐量、平均吞吐量、極限吞吐量，多任務并行測試

資源利用：大量并發任務下i/o設備利用、極限負載下i/o設備的負載、大量并發任務下用戶等待時間、內存使用情況、數據傳輸能力等

維護性

易分析性：運行狀態數據易分析 易變更性：軟件的可配置、修改能力 易測試性：變更之后的易測試情況 可移植性

適應性：不同軟件、硬件環境的適應能力 易安裝性：安裝、配置的復雜程度、難以程度 共存性：與其他軟件協同的能力 易替換性：版本的替換難以程度 依從性

以上所有特性遵循標準、規范的情況測試

23系統測試：系統非功能性測試，以檢驗系統在超常數據規模或負載下，線程、cpu、內存資源的利用和響應時間、數據傳輸等性能指標是否滿足要求

24.測試計劃

確定測試充分性要求：覆蓋范圍、覆蓋程度 確定測試終止要求； 確定測試所需資源； 確定測試的軟件特性； 確定測試技術、方法； 確定測試準出條件； 確定測試進度計劃； 測試風險分析。

25.測試設計：測試設計人員、測試程序員

測試用例設計：依據測試特性； 獲取測試數據；

確定測試順序：資源、被測特性； 獲取測試資源：軟硬件、工具； 編寫測試程序； 建立測試環境； 撰寫測試設計說明。

26.測試總結：

測試分析員－測試報告

總結測試計劃、測試說明的變化情況； 異常終止時測試未覆蓋范圍； 未能解決的測試問題； 總結測試結果（發現問題）； 編寫測試報告；

根據問題報告、測試記錄，編寫測試問題報告。

27.軟件可靠性：在給定的運行時間內和給定的系統配置環境下，運行給定的軟件功能時所 表現出來的質量能力 28.系統性能指標

系統資源利用率：分析性能指標，改善性能系統行為指標 請求響應時間：一次請求完成時間

事務響應時間：一個事務所有請求完成的總時間

數據吞吐量：單位時間內服務器接收、發送的數據量。

29.驗收測試：用戶執行的、使用真實數據進行的測試，依據需求規格中的確認標準進行測試。回歸測試：驗證已測試過的內容不受變更影響，確認變更沒有引入新的錯誤。

30.α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操 作環境下進行的測試。

beta測試由軟件的最終用戶在一個或多個客戶場所進行，開發者通常不在beta測試的現場。

測試關注的主要內容 web內容測試 界面 構件

導航測試 安全性 性能

32.測試用例（test case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。

33.軟件生存期定義：從軟件產品設計到軟件被淘汰的時間段。又稱軟件生命周期、生存周期。進一步劃分為兩個階段：開發階段和維護階段（40%+60%）。

34.軟件安全定義：一種軟件質量保證活動，他主要用來識別和評估可能對軟件產生負面影響并促使整個系統失效的潛在災難。

35.軟件評審的目標在于：盡早發現軟件過程中的錯誤，防止錯誤傳遞、蔓延至后續活動，防止錯誤轉化為缺陷。36.v模型

優點：既有底層測試又有高層測試。底層：單元測試。高層：系統測試。

將開發階段清楚的表現出來，便于控制開發的過程。當所有階段都結束時，軟件開發就結束了。

缺點：容易讓人誤解為測試是在開發完成之后的一個階段。

由于它的順序性，當編碼完成之后，正式進入測試時，這時發現的一些bug可能不容易找到其根源。

實際中，由于需求變更較大，導致要重復變更需求、設計、編碼、測試，返工量大。37.w模型：

優點：

將測試貫穿到整個軟件生命周期中，且除了代碼要測試，需求、設計等都要測試。更早介入軟件開發中，能盡早發現缺陷并修復。

測試與開發獨立起來，并與開發并行。缺點：

對有些項目，開發過程中根本沒有文檔產生，故w模型無法使用。

對于需求和設計的測試技術要求很高，實踐起來很困難。

從n0中某節點開始到nf中某節點結束的一條路徑稱為一條測試路徑。

1.軟件缺陷：（符合下列規則的叫軟件缺陷)：

１）．軟件未達到產品說明書的功能

２）．軟件出現了產品說明書指明不會出現的錯誤

３）．軟件功能超出產品說明書指明范圍

４）．軟件未達到產品說明書雖未指出但應達到的目標

５）．軟件測試員認為難以理解、不易使用、運行速度緩慢、或者最終用戶認為不好

2.單元測試：單元測試是對軟件設計的最小單元——模塊進行正確性檢驗的測試工作，主要測試模塊在語法、格式和邏輯上的錯誤。3.回歸測試

指軟件系統被修改或擴充（如系統功能增強或升級）后重新進行的測試，是為了保證對軟件所做的修改沒有引入新的錯誤而重復進行的測試。

4.等價類：指某個輸入域的子集合，在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的。

軟件測試總結與建議 軟件測試總結自己的不足之處篇四

軟件測試的目的是盡可能發現并改正被測試軟件中的錯誤，提高軟件的可靠性。

測試的目的就是為了保證軟件質量

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

軟件缺陷

軟件缺陷是對軟件產品預期屬性的偏離現象 1.對產品規格說明的偏離

2.對用戶期望的偏離，即用戶要求未體現在產品中（可能是規格說明有疏漏，也可能是實現中的問題）

注意：軟件缺陷不可能完全避免

軟件質量

軟件需求是衡量軟件質量的基礎

規定了的標準是軟件開發必須遵循的準則

如果已開發的軟件已經滿足了那些明文規定的需求，卻沒有滿足隱含的需求，軟件產品的質量仍然是有問題的

測試目的

測試是程序執行的過程，目的在于發現錯誤（缺陷）

好的測試用例能有效地發現別的測試用例未發現的錯誤（缺陷）成功的測試是發現了未曾發現的錯誤

確保軟件的功能符合用戶的需求，把盡可能多的問題在發布或交付前發現并改正： 確保軟件完成了它所承諾或公布的功能 確保軟件滿足性能的要求

確保軟件是健壯的和適應用戶環境的

一些原則：

一個好的測試用例具有較高的發現過去未被發現過的錯誤的概率； 自己不能測試自己編寫的程序；

對期望結果的描述是每個測試用例的必要組成部分； 杜絕不能重現或匆忙的測試；

既要編寫使用有效輸入條件的測試用例，也要編寫使用非法輸入條件的測試用例； 深入細致地審查測試結果 充分注意測試中的集群現象：測試后程序中殘存的錯誤數目與該程序中已發現的錯誤數目成正比；

讓最優秀的人員去完成測試；

保證軟件的可測試性是軟件設計的一個重要目標； 不要為了測試方便而修改程序；

測試工作必須在任務建立之初就確定目標。good-enough: 一種權衡投入/產出比的原則； 保證測試的覆蓋程度，但窮舉測試是不可能的； 所有的測試都應該追朔到用戶需求；

越早測試越好，測試過程與開發過程應該是相結合的； 測試的規模由小而大，從單元測試到系統測試；

為了盡可能多的發現錯誤，應該由獨立的第三方來測試； 不能為了便于測試修改程序

既應該測試軟件該做什么，也應該測試軟件不該做什么

測試方法

（1）測試方法分類：

根據軟件測試的策略分類：

黑盒測試與白盒測試（功能性測試和結構性測試）,靜態測試與動態測試,手工測試與自動測試

根據測試的階段分類: 單元測試,集成測試,系統測試

（2）功能性測試和結構性測試 a、功能性測試 基本觀點：任何程序都可以看作是將從輸入定義域取值映射到輸出值域的函數（工程中的黑盒）。

測試在軟件的接口處進行，測試人員完全不考慮程序內部的邏輯結構和內部特征，只根據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明（也稱“數據驅動測試”）。

黑盒測試一般為了發現以下幾類錯誤： 是否有不正確或遺漏的功能？

在接口上，輸入能否正確地接受？能否輸出正確的結果？ 是否有數據結構錯誤或外部信息（如數據文件）訪問錯誤？ 性能上是否能夠滿足要求？ 是否有初始化或終止行錯誤？ ??

常用方法：邊界值分析，健壯性分析，最壞情況分析，特殊值測試，輸入（輸出）等價類，基于決策樹的測試??

功能性測試的優點：

功能性測試與軟件如何實現無關，所以如果實現發生變化，測試用例仍然有效； 測試用例開發可以與實現并行，可以壓縮總的項目開發時間。缺點：

測試用例的冗余

b 結構性測試

對軟件的過程性細節做細致的檢查，對所有的邏輯路徑進行測試（也稱邏輯驅動測試）。結構性測試一般對程序模塊做如下的檢查：

對程序模塊的所有獨立的執行路徑至少測試一次；

對所有的邏輯判定，取“真”與“假”的情況都能至少測試一次； 在循環的邊界和運行界限內執行循環體； 測試內部數據的有效性 ??

（3）功能性測試與結構性測試的比較 測試用例的基礎：

功能性測試：需求規格說明

結構性測試：程序源代碼（實現）兩種方法單獨使用都是不充分的

如果所有已描述行為都沒有被實現，結構性測試永遠也發現不了； 如果程序實現了沒有被描述的行為，功能性測試用也發現不了；

測試級別與功能性和結構性測試存在現實的關系： 結構性測試最適合在單元級別上進行； 功能性測試最適合在系統級別上進行；

完全測試程序是不可能的: 原因： 輸入量太大 輸出結果太多 軟件實現途徑太多

軟件說明書沒有客觀標準

邊界值分析 程序與函數: 程序的輸入——定義域 程序的輸出——值域 程序中變量的值域: 強類型語言 非強類型語言

邊界值測試的基本原理: 錯誤更可能出現在輸入變量的極值附近.單缺陷假設：失效極少由兩個（或多個）缺陷的同時發生引起的。min、min＋、nom、max-和max。

次邊界條件：

有些邊界條件在軟件內部，最終用戶幾乎看不到，但是軟件測試仍有必要檢查。這樣的邊界條件稱為次邊界條件或者內部邊界條件。如2的乘方和ascⅱ。

邊界值分析的特點和局限性

對于一n個變量函數，邊界值分析會產生4n＋1個測試用例。邊界值的取值取決于變量本身的性質。邊界值分析對布爾變量沒有什么意義。邊界值分析假設變量是完全獨立的。

邊界值分析的問題 測試用例存在大量冗余 存在不完備現象 等價類測試

希望進行完備性測試 同時又希望避免冗余 等價類測試考慮的因素 單/多缺陷假設 健壯性

等價類劃分：

把所有可能的輸入數據，即程序的輸入域劃分成若干部分，然后從每一部分中選取少數有代表性的數據做為測試用例。希望進行完備性測試 同時又希望避免冗余

等價類測試步驟

使用這一方法設計測試用例要經歷劃分等價類（列出等價類表）和選取測試用例兩步。（1）劃分等價類

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的。測試某等價類的代表值就等價于對這一類其它值的測試。等價類的劃分有兩種不同的情況：

① 有效等價類：是指對于程序的規格說明來說，是合理的，有意義的輸入數據構成的集合。② 無效等價類：是指對于程序的規格說明來說，是不合理的，無意義的輸入數據構成的集合。

在設計測試用例時，要同時考慮有效等價類和無效等價類的設計。

(2）等價類測試--等價類劃分原則 ①如果輸入條件規定了取值范圍，或值的個數，則可以確立一個有效等價類和兩個無效等價類。

②如果輸入條件規定了輸入值的集合，或者是規定了“必須如何”的條件，這時可確立一個有效等價類和一個無效等價類。

③如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類。④如果規定了輸入數據的一組值，而且程序要對每個輸入值分別進行處理。

⑤如果規定了輸入數據必須遵守的規則，則可以確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。

（3）等價類測試—選取測試用例 在確立了等價類之后，建立等價類表，列出所有劃分出的等價類。再從劃分出的等價類中按以下原則選擇測試用例： ① 為每一個等價類規定一個唯一編號；

② 設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止；

③ 設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。

基于決策表的測試

在所有功能測試方法中，基于決策表的測試方法是最嚴格的，因為決策表具有邏輯嚴格性。

決策表很適合描述不同條件集合下采取行動的若干組合的情況。

決策表的組成

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

動作樁：列出了問題規定可能采取的操作。

條件項：列出針對它所列條件的取值，在所有可能情況下的真假值。動作項：列出在條件項的各種取值情況下應該采取的動作。規則：任何一個條件組合的特定取值及其相應要執行的操作。在決策表中貫穿條件項和動作項的一列就是一條規則。

功能性測試的選擇規則

如果變量引用的是物理量，可采用定義域測試和等價類測試。如果變量是獨立的，可采用定義域測試和等價類測試。如果變量不是獨立的，可以采用決策表測試。

如果可保證是單缺陷假設，可以采用邊界值分析和健壯性測試。

如果可保證是多缺陷假設，可采用最壞情況測試、健壯最壞測試和決策表測試。如果程序包含大量例外處理，可采用健壯性測試和決策表測試。如果變量引用的是邏輯量，可以采用等價類測試用例和決策表測試。

結構性測試 靜態測試: 括代碼檢查、靜態結構分析、代碼質量度量等。它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具自動進行。

檢查項： * 代碼風格和規則審核 * 程序設計和結構的審核 * 業務邏輯的審核

靜態白盒測試是在不執行的條件下有條理地仔細審查軟件設計、體系結構和代碼，從而找出軟件缺陷的過程。好處：

盡早發現軟件缺陷。

dd路徑測試

該測試方法的突出特點，是它們都基于被測程序的源代碼，而不是基于定義。由于這種絕對化的基礎，結構性測試方法支持嚴格定義、數據分析和精確度量。

程序圖 定義

給定一個采用命令式程序設計語言編寫的程序，其程序圖是一種有向圖，其中：節點是程序語句，邊表示控制流。從節點i到節點j有一條邊，當且僅當對應節點j的語句可以立即在節點i對應的語句之后執行。

dd路徑

決策到決策的路徑（dd-路徑）是指語句的一個序列，從決策語句的“出路”開始，到下一個決策語句的“入路”結束。在這種序列中沒有內部分支，因此對應的節點像排列起來的一行多米諾骨牌，當第一塊牌推倒后，序列中的其他牌也會倒下。

鏈是一條起始節點和終止節點不同的路徑，并且每個節點都滿足內度＝１、外度＝１。初始節點與鏈中的所有其他節點有２－連接，不會存在１－連接或３－連接。(p55, 4.2.6)有一種長度為０的退化鏈情況，即鏈有一個節點和０條邊組成。

dd路徑測試定義 定義

dd-路徑是程序圖中的一條鏈，使得：

情況1：由一個節點組成，內度=0。

情況2：由一個節點組成，外度=0。

情況3：由一個節點組成，內度≥2或外度≥2。

情況4：由一個節點組成，內度=1并且外度=1。

情況5：長度≥1的最大鏈。

對于給定的程序，可以使用多種不同的程序圖，所有這些程序圖都可以簡化為惟一的dd-路徑。

dd-路徑圖定義

給定采用命令式語言編寫的一段程序，其dd-路徑圖是有向圖。其中，節點表示其程序圖的dd-路徑，邊表示連續dd-路徑之間的控制流。

實際上dd-路徑圖是一種壓縮圖，在這種壓縮圖中，2-連接組件被壓縮為對應情況5 dd-路徑的單節點。

如果每條dd-路徑都被遍歷（c1指標），則我們知道每個判斷分支都被執行，這要求遍歷dd-路徑圖中的每一條邊。

較長的dd-路徑一般代表復雜計算，可以合理地認為是單獨的函數。對于這樣的dd-路徑，應用多個功能性測試可能比較合適，尤其是邊界值和特殊值。

dd-路徑的依賴對偶

dd-路徑對偶之間的最常見得依賴關系是定義/引用關系，其中變量在一個dd-路徑中定義（接受值），在另一個dd-路徑中引用。這種依賴關系的重要性在于，它們與不可行路徑問題有關。

定義/使用測試覆蓋指標

t是擁有變量集合v的程序p的程序圖g（p)中的一個路徑集合。定義

集合t滿足程序p的全定義準則，當且僅當所有變量v∈v，t包含從v的每個定義節點到v的一個使用的定義清除路徑。定義

集合t滿足程序p的全使用準則，當且僅當所有變量v∈v，t包含從v的每個定義節點到v的所有使用，以及到所有use（v,n）后續節點的定義清除路徑。定義

集合t滿足程序p全謂詞使用/部分計算使用準則，當且僅當所有變量v∈v，t包含從v的每個定義節點到v的所有謂詞使用的定義清除路徑，并且如果v的一個定義沒有謂詞使用，則定義清除路徑導致至少一個計算使用。定義

集合t滿足程序p全計算使用/部分謂詞使用準則，當且僅當所有變量v∈v，t包含從v的每個定義節點到v的所有計算使用的定義清除路徑，并且如果v的一個定義沒有計算使用，則定義清除路徑導致至少一個謂詞使用。定義

集合t滿足程序p的全定義-使用路徑準則，當且僅當所有變量v∈v，t包含從v的每個定義節點到v的所有使用，以及到所有use（v,n）后續節點的定義清除路徑，并且這些路徑要么有一次的環經過，要么沒有環路。

單元測試

單元測試時對軟件基本組成單元進行的測試，這里的基本單元不一定是指一個具體的函數或一個類的方法。

單元具有一些基本屬性，如：明確的功能、規格定義，與其他部分明確的接口定義等，可以清晰地與同一程序的其他部分單元劃分開來。

單元測試的目的

驗證代碼是與設計相符合的； 跟蹤需求和設計的實現；

發現設計和需求中存在的錯誤； 發現在編碼過程中引入的錯誤。

對單元測試的錯誤認識

單元測試浪費了太多的時間；

單元測試僅僅是證明這些代碼做了什么； 很棒的編程人員的工作不需要單元測試； 不管怎樣，集成測試將會抓住所有的bug； 單元測試的成本效率不高。

單元測試應堅持的原則

對全新的代碼或修改過的代碼進行單元測試； 對被測試單元需達到的一定的代碼覆蓋率要求； 當程序進行了修改，要進行回歸測試。

集成測試

也叫做組裝測試、聯合測試、子系統測試和部件測試。是在單元測試的基礎上，將所有模塊按照概要設計要求組裝成為子系統或系統，進行集成測試。

集成測試關注的重點

在把各個模塊連接起來時，穿越模塊接口的數據是否會丟失。各個子功能組合起來，能否達到預期要求的父功能。

一個模塊的功能是否會對另一個模塊的功能產生不利的影響。全局數據結構是否有問題，會不會被異常修改。

單個模塊的誤差積累起來，是否會放大，從而達到不可以接受的程度。

集成測試策略

功能分解法，調用圖法，mm路徑法

基于功能分解的集成測試：

自頂向下集成，自底向上集成，三明治集成，大爆炸集成

自頂向下集成

自頂向下集成從主程序（樹根）開始。所有被主程序調用的下層單元都作為“樁”出現，樁就是模擬被調用單元的一次性代碼。

自底向上集成

自底向上集成是自頂向下順序的“鏡像”，不同的是，樁由模擬功能分解樹上一層單元的驅動器模塊替代。需要編寫驅動器。

三明治集成

三明治是自頂向下和自底向上集成的組合。

樁和驅動器的開發工作都比較小，不過代價是有大爆炸的后果。

大爆炸集成

這種方法最容易：這種集成將所有單元在一起編譯并進行一次性測試。這種方法的缺點是，當發現缺陷時，沒有多少線索能夠用來幫助確定缺陷位置。

因果圖是從用自然語言書寫的程序規格說明的描述中找到因（輸入條件）和果（輸出或程序狀態的改變），通過因果圖轉化為判別表。因果圖方法最終生成的就是判定表。因果圖的適用范圍

如果在測試時必須考慮輸入條件的各種組合，可使用一種適合于描述對于多種條件的組合，相應產生多個動作的形式來設計測試用例，這就需要利用因果圖。因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。

用因果圖生成測試用例的基本步驟:(1)分析軟件規格說明描述中，哪些是原因(即輸入條件或輸入條件的等價類)，哪些是結果(即輸出條件)，并給每個原因和結果賦予一個標識符。

(2)分析軟件規格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的是什么關系? 根據這些關系，畫出因果圖。

(3)由于語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。(4)把因果圖轉換成判定表。

(5)把判定表的每一列拿出來作為依據，設計測試用例。