掌握分類樹測試方法

1.分類樹測試方法
（1） 分類樹的概念
分類樹測試方法是由 Grochtmann 和 Grimm 在 1993 年提出，是軟件功能測試方面一種有效的測試方法，通過分類樹把測試對象的整個輸入域分割成獨立的類
（2） 分類樹測試法的引入背景
（3）分類樹測試方法的概念
分類樹測試方法以適合測試的方式來評估測試對象的不同特性，并以此為基礎考慮測試的輸入域。
針對測試對象的每個特性進行部分的或完全的分類（Classification），并可根據需要對分類后的特性作進一步的細分，通過將測試對象不同特性的分類組合而得到不同的測試用例。
按照分類樹方法，測試對象的輸入域被認為是由各種不同的方面組成并且都與測試相關
分類樹測試方法的***主要優點***是將測試用例設計變為結構化和系統的過程，使得測試用例設計更加容易處理、理解和實現文檔化
（4）使用分類樹測試方法設計測試用例
分類樹測試方法有兩個重要步驟：
第一，根據測試對象規格說明設計分類樹
第二，根據測試要求創建測試用例
引入分類樹方法的工具幫助測試者創建和選擇測試用例
邏輯擴展分類樹編輯器 CTE-XL
2.分類樹編輯器CTE-XL
CTE-XL 能方便地實現設計分類樹與根據測試要求創建測試用例這兩個重要步驟，并針對兩個步驟分別提供相應功能，系統且有效地確定測試用例。

分類樹 ：創建分類樹區域
組合表格：根據分類樹得到測試對象的輸入參數的組合表格，根據表中不同取值 創建相應的測試用例
屬性窗口：修改激活對象的不同屬性如名稱
測試用例列表：最終生成的測試用例列表
*3.分類樹測試方法的應用
（1）生成分類樹
（2） 創建完全組合的測試用例 ***
（3）創建特定要求組合的測試用例
（4）生成測試用例報告斜體樣式

基于結構的測試有：邏輯覆蓋測試法、路徑測試 基于規格說明的測試：等價類劃分法、邊界值分析法、因果圖和決策表法、配對測試法、分類樹測試法

掌握狀態轉換測試法

1． 狀態轉換測試法原理
(1) 關于具有狀態轉換特性的測試對象的識別
針對，如：針對GUI系統；面向對象的系統；Web應用系統等。這些特定軟件的測試用例設計大多采用狀態轉換測試法來完成。
在采用狀態轉換測試法時
首先要獲得軟件（系統）的狀態轉換 圖
狀態圖是狀態機的圖解形式。
狀態轉換圖是設計狀態轉換測試用例的基礎，而基于狀態轉換圖實施的測試就是狀態轉換測試
2. 狀態轉換測試法
（1） 將狀態圖轉換為狀態樹
采用這種策略，首先需要將狀態圖轉換為狀態轉換樹，將可能具有無限多的 狀態循環的狀態圖轉換為不含循環的、具有一定數目狀態的狀態轉換樹。
轉換的基本步驟
步驟1：將初始（開始）狀態作為狀態轉換樹的根根在整個狀態轉換樹中的層次為1
步驟 2：設當前生成狀態轉換樹的層次為 N, 從左到右檢查所有層次為 N 的節點，將該節點對應的下一可能的狀態作為其子節點， 狀態之間轉換作為兩狀態的邊。
步驟 3： 重復步驟，直到位于層次 N 上的節點出現在層次 M 上，且 M≤N。則，該節點成為最終的葉節點，無須繼續生成其他子節點；若該節點狀態已是結束，則停止進行狀態轉換
該狀態轉換數可根據不同的測試強度或覆蓋率得到測試用例： 1）至少覆蓋所有狀態一次。
2）至少覆蓋所有事件一次。
但覆蓋循環的測試用例對發現一些累計的計算錯誤或資源使用方面的缺陷很重 要，如內存泄露。所以在設計測試用例時，需確定合適的覆蓋率
（2） 狀態轉換表
狀態轉換表可直接從狀態轉換圖中得到，或根據測試對象的規格說明得到。
狀態轉換表由4個部分組成：當前狀態、事件、活動、后續狀態
創建狀態轉換表能夠發現被測試對象規格說明中可能遺漏的組合，或沒有文檔化的組合。
（3） 關于N-Switch 的說明
他將N-Switch定義為程序流圖中長度為 n+1 的連續的邊或弧線 （這通常表示在狀態圖中的循環）的序列。因此，單獨的一條邊（或轉換）就是一個 0-Switch，兩條連續的邊的序列就是 1
Switch。
（4） 狀態轉換測試的覆蓋率準則（測試強度）
1）狀態覆蓋：每個狀態至少執行一次。
2）事件覆蓋：每個事件至少執行一次。
3）狀態轉換覆蓋：每個狀態轉換至少執行一次。
4）路徑覆蓋：每個路徑至少執行一次
3. 狀態轉換測試法的應用舉例
（1）堆棧的狀態轉換測試
堆棧有三種不同的狀態：空（empty）、非空(filed)和滿(full)。（2）具備健壯性的堆棧測試轉換樹 (0-Switch)
這種情況實際上是考慮到了堆棧對于異常情況的處理，通過增減健壯性測試來確認是否會出現不應出現的狀態轉換
（4）狀態轉換樹（1-switch
如要求得到覆蓋率達到1-switch，需要擴展0-switch的狀態轉換樹得到
體方法是：1-switch的狀態轉換樹需要在狀態‘空’后面增加兩條轉換，在狀態‘非 空’后面增加5條轉換，在狀態‘滿’后面增加3條轉換

掌握用例/場景測試法;

1. 用例的相關概念
用例是描述軟件（程序）系統需求的一種方法，使用該方法來描述系統需求的過程就是用例建模
采用用例方法能解決傳統需求描述方式 （如需求規格說
明）的某些缺點，如傳統的需求規格說明很容易混淆需求和設計的界限，造成不清楚系統需求應詳細到何種程度。
其次，傳統需求描述的一個缺點是需求分割了各個系統功能的應用環境，使開發者較難理解這些功能輸入和相關聯來實現一個完整的系統服務或功能
用例模型主要由模型元素組成
（1） 參與者（Actor）
（2） 用例（Use case）
用于表示軟件系統所提供的服務，定義系統如何被參與者所用，描述的是參 與者為了使用軟件系統提供的某個功能而與系統之間發生的一段“對話”。
2．用例規格
用例規格說明主要包括以下內容：

（3）通信關聯
用于表示參與者和用例之間的對應關系
? 簡要說明：概述該用例的作用和目的
? 事件流： 包含基本流與備選流，所有場景都需要通過事件流表示
? 用例場景：包含成功場景與失敗場景。場景主要由基本流和備選流組合
而成
? 特殊需求：描述與該用例相關的非功能性需求。它包含性能、可靠性、
可用性、可擴展性等和設計約束（指所使用的操作系統及開發工具等）
? 前置條件：執行用例之前系統必須所處的狀態
? 后置條件：用例執行完畢后系統可能處于的一組狀態
3.用例/場景測試法的應用

動態分析指的是在組件（單元）或系統的執行過程中評估其行為的過程

復習第二單元軟件測試經典技術所學知識
完成第二單元軟件測試經典技術測驗；

了解自動化測試基本概念

1，自動化測試原理

1．自動化測試技術的產生
軟件自動化測試技術的產生，首先源于軟件產品的開發過程呈現出不斷改進的特點和發展
轉向和發展最主要的特點就是軟件開發過程呈現不斷迭代的過程，
軟件自動化測試已是現代軟件測試的重要策略與技術手段。
目前，自動化測試工作正在呈現職業化（系列）的特征，自動化測試規劃設 計工程師、自動化測試架構（部署）工程師、自動化測試執行工程師等崗位及工 作分類在軟件發達國家和涉及軟件開發和運行的各類企業里比比皆是。
2. 自動化測試概念
1） 自動化測試的概念
? 使用自動化測試工具來驗證各種軟件測試需求，測試活動實施與管理； 通過自動化測試工具運用，按測試管理者預定計劃自動運行。
? 自動化測試通常指測試的自動化過程，在預設條件下自動運行被測軟件 或程序（被測對象）并自動分析、評估測試的結果。
? 自動化測試是指測試過程的自動化。。這個概念意味著測試手段以非手工 方式逐個對測試用例進行設計或測試的執行 自動化測試的一個顯著特點是：測試不會因測試人員的不同而產生不致的測試結果。
***自動化測試作描述性的定義：***使用一種自動化測試工具來驗證
各種測試需求，包括測試活動的實施與管理。自動化測試通過運用自動化測試工具，并結合其他手段，按照測試管理的預定計劃自動進行，以減輕手工測試工作量或手工無法完成的測試目標
2） 自動化測試的適用范圍和其優勢
1對涉及非常重要的測試和范圍寬廣的測試；
2 期望測試結果完全可以預料，測試的復用性要求較強的情形；
3 要求加快軟件開發周期，期望通過自動化測試縮短測試周期，并通過自 動化測試希望增加軟件信度的測試。如安全性測試等 ；
4? 執行某些手工測試困難或不可能進行的測試。如性能測試的負載測試等。
? 對運行頻繁的測試，或在較少時間內需更多測試。如敏捷開發中的每日 構建中的測試。
? 需要進行全面、準確、快速響應的測試，并進行全面的測試管理運用。 如實施測試管理的全過程。
3. 自動化測試原理
自動化測試是軟件測試領域的分支，它是自動化理論、人工智能與軟件測試技術理論的綜合運用
1）自動化測試的實現機理

• 通過測試的自動執行。
• 狀態的自動識別
• • 自動的邏輯處理
    - 2）自動化測試的通用流程
    ? 創建和更新測試用例文檔
    ? 測試框架設計
    測試框架是自動化測試開發過程中的最重要環節，測試
    腳本基于測試框架
    ? 開發測試腳本
    ? 執行自動化測試用例
    ? 腳本維護
    4. 自動化測試的局限
    ? 當針對不現實的期望
    ? 當缺乏自動化測試的經驗時
    ? 當軟件開發或測試的相關文檔較少或兩者不一致時，其自動化測試發現 缺陷或錯誤的能力將大大降低
    ? 期望通過自動化測試能夠發現大量新的缺陷。
    ? 錯覺自動化測試的可靠性一定高。
    ? 認為自動化測試無需維護。
    ? 自身技術問題的影響因素

2.自動化測試流程組織框架

1．測試框架
1）框架的概念
這里所說的框架（Framework），通常是指軟件應用與軟件開發中的一種基礎架構。它包含一組供開發使用的組件和公共服務的平臺。如，對數據庫訪問、安全性的功能、消息通信等等的服務和保障
框架定義每個組件之間的通信方式以及對外服務的接口。
所謂架構是指對基礎設施所提供的各種功能，它與具體的（軟件）業務邏輯無直接的關聯。
廣義的測試框架包括對測試流程和測試規范的設計的服務和支持。
2）測試框架的作用
測試框架能夠實現復用，有兩層含義：
① 同一項目內的復用
② 針對某一測試的自動化測試框架，可直接或通過一定修改后被其他同類
型自動化測試項目使用。

測試框架不僅為簡單的類庫和工具包的集成，還必須通過一定的設計模式來實現其開發形成框架。是其具有結構清晰(松耦合)、易維護(依賴關系小)、易擴展的機制和特點。
3）測試框架的分類
如果按照不同的測試領域劃分，有：單元測試框架；功能測試框架；性能測試框架；
如果按照編程語言劃分，有：Java測試框架；. NET測試框架等；
如果按照框架使用授權劃分，有：開源框架和非開源框架。
2．測試框架的解析
1）功能測試框架
軟件的功能是其質量體系的重要組成部分，在自動化測試框架中，基本上都會體現出這個基礎和服務。
2）基于數據驅動（Data Driven）的框架
基于數據驅動（Data Driven）的框架是目前較流行且應用廣泛的一種測試框架
基于數據驅動的框架的設計思想是使用較少的腳本來產生大量的測試用例。將這種數據驅動的技術應用到自動化測試框架中就形成數據驅動測試框架。

數據驅動測試是將測試過程和測試數據進行分離，其核心思想是將測試用的測試場景與測試數據進行解耦，從而可以有效重用測試邏輯，提高測試覆蓋率，從而提高測試用例開發效率的測試方法。
常用驅動方法有：隨機驅動；順序迭代驅動和隨機驅動；順序選擇驅動
迭代驅動就是將整個或部分驅動數據集合以循環的方式同測試場景進行動態地耦合，將數據一個個的送入場景。
選擇驅動是將測試數據作為整體或經選擇子集之后同測試場景進行動態耦合，將選擇的數據作為集合送入場景。
基于數據驅動這種測試框架的主要功能或作用是將測試的數據（即輸入/輸出）是從數據文件中進行讀取。
3）關鍵字驅動（表驅動） 框架
該框架是建立在數據驅動基礎之上的一種測試機制，是提高自動化測試的靈活性和擴展性的一種測試框架解決方案

關鍵字驅動的自動化測試框架是對數據驅動的邏輯擴展，用關鍵字的形式將測試邏輯封裝在數據文件中，測試工具只要能夠解釋這些關鍵字即可對其應用自動化，它的核心思想可概括為三個分離
? 界面元素名與測試內部對象名的分離
? 測試描述與具體實現細節的分離
? 腳本與數據的分離
關鍵字驅動測試框架的優點：
? 測試腳本基本等同于手工測試過程的描述，簡明、易讀。
? 測試腳本建立與維護不需要編程知識和技巧。
? 框架的實現和腳本編寫可同步實施，腳本編寫不依賴于任何框架的實現 和程序語言，只需了解關鍵字的定義即可。
? 腳本一次編寫，可多處適用。更換測試工具只需要重新啟用新的工具實 現關鍵字解釋器即可。
關鍵字驅動測試框架的缺點：
? 框架的開發比較困難。
? 關鍵字解釋器的編寫需要更高的技巧和專業能力。
關鍵字描述測試腳本的缺點：
? 無法表示復雜的測試邏輯，僅適合順序的操作流，靈活性較差。
? 因為腳本比較簡單，則必然會增加對框架的依賴，因此，將會提高框架 的復程度，使開發框架難度加大。
? 在框架中，不僅要正確解釋各種不同操作對象的不同關鍵字，還需考慮 那些在其他框架中可以在腳本里實現的對不同錯誤的恢復和處理的邏輯。

3，自動化測試用例與測試腳本

1．數據驅動測試對自動化測試的影響
數據驅動是以對被測軟件的數據模型的測試代替了對功能的測試。從而測試場景的復雜度則會大幅降低，而測試數量則大幅提升。測試腳本的結構得到簡化，測試腳本內部的‘硬編碼’內容大幅的減少，使得測試的穩定性得到提高，測試用例組獲得增加。

2．測試數據的設計
自動化測試數據的設計，主要有幾個步驟：
? 測試數據規劃：結構要符合業務模型，并有效的去重，對有效數據整體 分類。對單一數據劃分等價類，可運用在通常劃分等價類的所有原則，對數據的修飾，規劃測試策略。
? 測試數據生成，有三種：采用隨機生成方法；將數據組排列；基于統計 學要求的數據生成方法。
? 測試數據存儲在通用測試工具中，數據的存儲方式往往由測試框架內 置來實現。如，使用數據池（Datapool）方法。
? 測試數據維護：主要針對數據池進行。
? 測試檢驗：主要是針對著測試點的檢驗。
3. 自動化測試用例及測試腳本
自動化測試必須要有測試腳本或測試用例的支撐，否則無法進行具體測試。
1）自動化測試用例
自動化測試用例是指在測試執行過程中引用的一個個具體的測試用例。通常為以一個測試用例的集合。或是腳本編輯時指定的測試數據。
2）自動化測試腳本
測試腳本是能夠被重復執行的
3）自動化測試腳本的特點
? 測試腳本與測試一樣，將隨著測試模式和測試方法的不同，將以多種形 式出現
? 測試腳本是可以變化。
? 測試腳本在脫離所依附的系統時，將不能夠獨自運行。
? 自動化測試腳本生成工具，可協助測試人員編制或生成測試腳本。
4）自動化測試腳本種類
? 結構化腳本
腳本側重描述腳本中控制流程的結構化特性。
? 共享腳
共享腳本側重描述腳本中共性的特性。

共享腳本維護開銷低于線性腳本（簡單的錄制-回放），能刪除明顯的重復，在腳本中增加更智能的功能。
共享腳本開發的配套文檔需注意規
范性和完整性。
? 數據驅動腳本
腳本式是參數化的。
? 關鍵字驅動腳本
腳本使用采用說明性與描述性的方法。描述的被測軟件知識建立在自動化測試環境中，知識是在腳本當中。

關鍵字驅動腳本的數量不隨測試用例數量變化，僅隨軟件規模而變動
? 線性腳本（簡單錄制/回放）線性腳本是錄制手工執行的測試用例得到。
需要很明確該系統的測試機制（原理）是什么，這將決定了要運用什么樣的測試腳本的類型。
4. 測試腳本的自動生成
4，自動化測試工具（平臺）及應用
1. 自動化測試工具（平臺
自動化測試工具或平臺的體現的功能和作用，這里歸納如下：
1）自動化測試工具作用和功效
支持軟件的關鍵元素
能記錄業務的流程并生成腳本程序
對各種網絡設備（客戶/服務器）模仿能力，用有限資源生成高質量虛擬 用戶
對整個軟、硬件系統中各部分具有監控的能力，對測試結果表現和分析。

2) 自動化測試工具功能類型
? 支持不同測試環境的測試平臺或是測試模擬器。
? 提供軟件（程序）變更分析和軟件風險及復雜度評價的靜態分析器和比較器。
? 測試執行和回歸的測試驅動及捕獲/回放工具。
? 度量和報告測試結果及覆蓋率動態分析工具。
? 幫助開發和測試人員了解重要的軟件系統信息。
? 確定系統最優硬件配置，提供最好的系統性能。
? 檢查系統的可靠性。系統在負載（壓力）下可靠運行時間及系統性能如 何變化。檢查系統硬、軟件升級對系統性能的影響。
? 評估新產品的最佳運行環境與條件。
? 能否正確選擇工具關系到測試的效率、成本及測試的成敗。
2）自動化測試工具的分類
? 自動化測試工具也可根據其來源的不同，分為開源工具和非開源工具 （一般為商品化工具）。
? 從自動化測試工具能夠完成的測試工作或任務來說，有單一功能的特性 工具、多功能綜合特性的工具等
? 根據測試方法不同，測試工具又分白盒測試工具和黑盒測試工具。
? 根據測試對象不同，測試工具分為Web測試工具、數據庫測試工具、
移動測試測試工具、嵌入式測試工具和測試管理工具等等。
2. 自動化測試工具簡介
1） 白盒測試工具
白盒測試工具通常用于作接口測試、覆蓋率分析、復雜度計算、內存分析等。
? 可作代碼審查
? 進行一致性檢查
? 白盒測試工具能實現
① 作程序的錯誤檢查
② 作接口分析。
③ 輸入輸出規格說明分析檢查
④ 作數據流分析
⑤ 作類型分析，
⑥ 作單元分析，檢查單元或者構成實體的物理元件是否定義正確和使 用一致
⑦ 作程序復雜度的分析，并精確規劃測試用例的設計。
商用白盒測試工具：如 IBM LogiScope、IBM Rational PurifyPlus、Klocwork、Parasoft C/C++等等, 以及開源測試工具。
2）黑盒測試工具
其主要的功能和作用：
? 功能測試工具
作軟件或程序的預定功能的確認。用于檢測程序能否達
到預期功能要求，并能正常地運行。
? 非功能測試工具
。主要是以軟件的性能測試、安全性測試、質量度量測
試內容為主的工具。如性能測試，主要是查找影響軟件或程序性能的瓶頸
? 業界主流的黑盒測試工具
3) 用于測試管理的工具
IBM Rational 系列 DOORS，Rational Team Concert（RTC

總結

以上是生活随笔為你收集整理的软件测试笔记三的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。