開源軟件測試模型

　　一、模型概覽
　　開放源碼軟件測試模型以“滿意測試”為基本原則，強調迭代發展。

　　· “滿意測試”基本定義

　　是一個過程，通過該過程可以合理的成本獲取足夠的產品質量評價信息，從而使得與產品有關的決策更為明智和及時。

　　· 模型基本需求

　　以下給出開源軟件測試模型應滿足的一些基本要求，將在實踐中不斷豐富和完善：

　　1. 應充分考慮開放源碼的早發布和常發布特點，對每一次代碼的提交、滯后、變更能夠作出適當反應，允許對仍處于開發、尚未集成的元素進行及時測試；

　　2. 明確鼓勵測試人員在進行測試設計時充分利用各種信息源，而不僅限于項目文檔；

　　3. 允許測試工作由于較差的或滯后的項目文檔而受負面影響，但應防止完全阻塞測試工作的情況發生；

　　4. 允許每個測試案例可以利用不同的信息源進行設計，允許在獲得新的信息源時對測試進行重新設計；

　　5. 應包含反饋機制，使得測試執行過程中的發現可被及時考慮到測試設計中；

　　· 開放源碼軟件測試模型框架

　　以上述需求為基礎并結合開放源碼特點，給出開放源碼軟件測試模型。該模型是一個軟件測試啟發式模型，基本目標是用于提醒測試人員在創建測試時應著重考慮的各種因素，進而可被用來定制測試。

　　1. 協商并理解項目的測試目標；

　　2. 理解并協商與測試技術選擇相關的各種因素，理解與測試工作有關的限制、要求和可用資源，從而使得測試更為高效；

　　3. 在充分考慮和利用其他各種因素的前提下選擇合適的測試技術以達到測試目標；

　　4. 隨時監控項目項目的狀態，并在需要時調整測試計劃，以使得目標、測試技術的選擇和各種因素保持統一。

　　測試目標 明確項目測試應優先考慮的任務和側重點。

　　測試環境 包括資源、限制和其他可能影響測試執行效果的外部力量，應確保在限制范圍內充分利用了各種可用資源。

　　產品元素 指被測試的對象，應確保檢查了產品所有方面，包括軟件、硬件和操作。

　　質量準則 包括各種可用來確定產品是否存在問題的規則和數值，具有多維特點，并且常常是隱含的或相互矛盾的。

　　測試技術選擇 給出各種創建測試的策略和方法，在對測試目標、測試環境、產品元素和質量準則進行綜合分析的情況選擇和使用，并根據測試執行情況及時調整。

　　二、測試目標
　　· 發現重要問題 · 評估質量 / 風險

　　· 標準符合性認證 · 完成過程委托監理

　　· 讓受益人滿意 · 責任擔保

　　· 針對 QA 的改進建議 · 針對測試的改進建議

　　· 針對質量的改進建議 · 效率最大化

　　· 成本最小化 · 時間最小化

　　三、測試環境
　　有許多因素對于項目測試工作能否成功完成具有重要影響，在此將這些因素統稱為測試環境。下面給出一些通用的信息類別，考慮其中各個因素對于測試工作是起促進作用還是阻礙作用，最大限度利用各種可用資源，同時將各種阻礙因素的影響最小化。

　　3.1 受益人
　　指任何對于產品質量能夠發表意見以施加影響的人。所有的需求都直接或間接地來源于一個或多個受益人，軟件測試人員在整個測試過程中作為受益人的代理。

　　3.2 測試信息
　　指測試工作所需要的與產品或項目有關的信息。

　　· 進度

　　測試： 何時 開始測試以及要持續多長時間？

　　開發 : 何時構建可以被測試、何時增加新功能、何時凍結代碼，等等？

　　文檔 : 何時用戶文檔可被評審？

　　· 預算

　　需要購買或開發的測試資源和材料的費用如何？

　　· 過程

　　項目管理： 項目采用的生命周期模型、項目計劃和監控手段如何。

　　配置管理： 項目配置管理方法和實施如何？

　　· 測試條目

　　可用性： 能否獲得被測產品？能否從開發人員或其他人員那里獲得測試所需信息？

　　易變性： 獲取的 信息是否最新？如何獲得有關新信息或信息變更方面的通知？產品設計和實現經常變更嗎？

　　可測試性： 產品是否足夠可靠以便于進行有效測試？

　　交付性： 需要生成何種的報告，是否要共享中間測試結果還是僅提交最終結果？

　　3.3 測試團隊
　　指任何將要執行或支持測試的人員。

　　· 工作負載

　　是否有足夠人力按來照期望時間完成所有計劃好的測試工作？

　　· 專家能力

　　是否擁有與項目有關的正確知識以很好地完成計劃好的測試工作？

　　· 組織

　　所有測試工作是否得到有效協調并目標一致？

　　3.4 測試工作平臺
　　指用于支持和管理測試的軟硬件平臺。

　　· 測試平臺

　　是否擁有測試執行所需的全部設備和平臺？

　　· 測試工具

　　需要那些測試工具？他們是否可用？

　　· 測試庫

　　是否測試過程中的任意文檔和結果均要保存并進行跟蹤嗎？

　　· 錯誤跟蹤系統

　　如何進行錯誤報告和跟蹤？

　　四、產品元素
　　軟件產品最終體現為提供給客戶的一種操作經歷或解決方案，包括 支撐平臺 、 軟件元素 和用戶 操作 ，以及相互之間的數據交互，具有多維的特點。為了測試工作取得成效，必須綜合考慮這些層面。以下給出軟件產品應包含的一些重要的元素類別，如果僅注意測試其中幾個類別則可能會遺漏重要錯誤。這些類別提供了一個起始點，需要在特定環境中細化。

　　4.l 支撐平臺
　　指軟件產品所依賴的任何事物。

　　· 外部硬件

　　用于支撐軟件產品工作的硬件元素和配置，不作為產品的組成部分，如 CPU 、內存、鍵盤、外設等等。

　　· 外部軟件

　　用于支撐軟件產品工作的其他軟件元素和配置，不作為產品的組成部分，如操作系統、驅動程序、字體等等。

　　4.2 軟件元素
　　· 結構

　　指組成軟件產品的任何事物。

　　代碼： 組成產品的任何代碼結構，從可執行碼直至單個例程。

　　接口： 子系統之間的連接和通信點。

　　硬件： 任何作為為產品組成部分的硬件元素。

　　非執行文件： 除程序外的任何文件如文本文件、樣本數據、幫助文件等等。

　　其他介質： 軟件和硬件之外的任何介質，如紙面文檔、 Web 連接和內容、包裝、許可證協議等等。

　　· 功能

　　指產品要完成的任何事情。

　　用戶接口： 任何協調與用戶交換數據的功能。

　　系統接口： 任何協調與用戶之外的其他實體（如其他程序、硬盤、網絡、打印機等等）交換數據的功能。

　　應用： 任何用于定義產品、區分產品或完成核心需求的功能。

　　錯誤處理： 任何檢測錯誤和從錯誤中恢復的功能，包括所有的錯誤消息。

　　可測試性： 任何支持測試該產品的功能如診斷程序、日志文件、聲明、測試菜單等等。

　　· 數據

　　指產品要處理的任何任何事物。

　　輸入： 產品要處理的任何數據。

　　輸出： 經產品處理后產生的任何結果數據。

　　預置值： 要作為產品的一部分提供給客戶、或直接構建在產品內部的任何數據如預制數據庫，缺省值等等。

　　固定值： 存儲在內部、在多個操作中應保持一致的任何數據，包括產品模式或狀態如選項設置、視圖模式、文檔內容等等。

　　時序： 數據和時間之間的任何關系，如每秒擊鍵次數、文件的時間戳、或分布式系統的同步。

　　非法： 任何能夠觸發錯誤處理函數的數據或狀態。

　　4.3 操作
　　指產品將被如何使用。

　　· 使用情景

　　與時間相關的操作模式，包括產品在相關領域要典型處理的數據模式，隨用戶而變化。

　　· 物理環境

　　產品運行的物理環境，比如噪音、照明等等。

　　五、質量準則
　　當聲稱一個產品是“高質量”時，意味著“高度”滿足了該產品的受益人所定義的質量準則。測試工作常常不得不在質量準則不很明確的情況下進行，以下所給出的準則類別可幫助進行“頭腦風暴式”思考或揭示那些需要知道的問題，尤其適合根據實際項目進行定制。建 議同時參考 ISO 9126 質量特性標準或其他相關軟件工程標準。

　　5.1 操作準則
　　· 能力

　　產品能否執行要求的功能？

　　· 可靠性

　　在所有要求的情況下產品均能正常工作并抵御失敗嗎？

　　錯誤處理： 產品在錯誤的情況下可抵御失敗，失敗時能夠妥善應對并很容易恢復。

　　數據完整性： 產品可 防止系統數據的丟失或損壞。

　　安全（ Security ）： 產品可防止未授權用戶的訪問。

　　保險（ Safety ）： 產品的失敗不會造成生命或財產的損失。

　　· 可用性

　　產品是否很容易被真實用戶使用？

　　易學習性： 產品操作可很快被潛在用戶掌握。

　　易操作性： 產品的操作只需付出很少努力，不會引起混亂。

　　· 性能

　　速度和相應能力如何？

　　· 可安裝性

　　是否能很容易地安裝在目標平臺上？

　　· 兼容性

　　能否與外部元素和配置協同一致地工作？

　　應用兼容性： 產品能夠與其他軟件產品一起工作。

　　操作系統兼容性： 產品可與某種特定操作系統協同工作。

　　硬件兼容性： 產品可與某種特定硬件平臺元素和配置協同工作。

　　后向兼容性： 產品能夠與其早期版本協同工作。

　　資源使用： 產品不會濫用內存、存儲介質或其他系統資源。

　　5.2 開發準則
　　· 可支持性

　　產品技術支持工作的經濟性如何？

　　· 可測試性

　　產品測試工作的有效性如何？

　　· 可維護性

　　產品構建、糾錯或功能增強的經濟性如何？

　　· 可移植性

　　移植或在其他環境下重用產品相關技術的經濟性如何？

　　· 可定域性

　　以其他語言發布產品的經濟性如何？

　　六、測試技術選擇
　　需求： 包括產品元素、質量準則、測試環境和參考資料，從總體上表達了受益人的愿望以及各種資源限制。完整需求的獲得決非易事，并隨著受益人經驗的增加或環境的改變而處于連續變化當中。 參考資料是任何可用作需求來源的文檔或實體，包括顯式參考（由受益人明確指定）和隱式參考（任何其他未指定的有用資料）。

　　定義測試預期： 測試預期是用于判定一個測試通過與否的策略，測試的主要任務之一就是根據產品真實需求來確定測試預期，受到測試目標的影響。

　　定制測試模型： 根據項目特點構造一個測試模型——描述將采用何種測試方法，以及該方法相配合的測試“覆蓋”內容。比如：采用基于風險的測試方法時，同時應制定相應的風險領域列表。在后面羅列一些 通用測試技術 以供選擇使用。

　　選擇覆蓋范圍： 確定產品的哪些部分必須被測試，哪些可暫不考慮。

　　配置系統： 為測試工作準備產品和平臺，確保系統處于開始測試的正確狀態。

　　操作系統 : 為系統提供必需的輸入和控制以執行測試，對于某些測試類型可能需要特殊工具支持。

　　觀察系統： 監控系統操作過程中的輸出或任何其他相關結果。對于哪些隱含變量或微妙結果的觀察可能需要特殊工具支持。

　　評估結果： 利用測試預期來評估測試結果，需要時執行附加的測試以驗證評估。及時反饋評估結果給開發人員，必要 時應調整測試計劃。

　　附錄：通用測試技術
　　每種測試技術是一種創建測試的方式，其種類難以勝數。以下給出一些簡單、實用的通用測試技術，每種技術既可以通過所謂“快速但不潔（ quick and dirty ）”的方式執行，也可以更為正式地執行，還可以相互結合（比如基于風險的回歸測試等）。

　　域測試 —— 依據等價類和邊界值對產品不同域測試

　　1. 確定要測試的域；

　　2. 分析每個域的限制和特性；

　　3. 確定要測試的域組合；

　　4. 應用所選擇的測試策略。

　　例如，窮盡值，典型值，邊界值，隨機值，非法值。

　　容量測試 —— 在“超負荷”狀態下使用系統

　　1. 選擇要“超負荷”測試的條目和功能；

　　2. 確定與其相關的數據和平臺元素；

　　3. 選擇或生成用來運行測試的具有挑戰性的數據和平臺配置。

　　例如，很大或復雜的數據結構，高負載，長時間運行，大量測試用例，低內存條件

　　線索測試 —— 按照某種邏輯順序對系統進行測試

　　1. 定義測試程序或高層測試用例，將多個測試按照一個接一個的方式結合在一起；

　　2. 不要在測試之間重置系統；

　　3. 將時間因素考慮進來；

　　4. 與其它技術結合。

　　例如，用戶線索，容量線索，基于風險的線索。典型情況下，線索測試通過“場景”來定義。所謂“場景”，就是一步一步的詳細指令序列，它描述了哪些數據要輸入哪些字段，以及要按下什么按鈕等。一般應包含：（ 1 ）該場景使用的數據描述（ 2 ）描述該場景的前提：那些動作必須在之前執行；（ 3 ）動作序列描述：如，按下“確認”按鈕，在用戶號字段內輸入 456 等；（ 4 ）預期結果描述；（ 5 ）與某功能有關的場景可能要跨越“幾天”時間：數據進入系統后可能今天后結果才有效，后續動作也才能執行?！皥鼍啊睉敻采w系統所有應完成的功能。

　　用戶測試 —— 模擬真實用戶的操作方式、數據

　　1. 確定用戶分類；

　　2. 確定每一類用戶要做什么、如何做以及怎樣評價；

　　3. 獲得真實的用戶數據，或讓真實用戶進行測試；

　　4. 否則，系統化地模擬真實用戶的行為（注意：不要誤以為自己就是真實用戶）。

　　回歸測試 —— 對于變更及影響部分的重復測試

　　1. 確定哪些產品元素發生變更；

　　2. 確定哪些元素受到這些變更的影響；

　　3. 選擇測試內容，比如最近修復的錯誤，以前修復的錯誤，新代碼，敏感代碼，或所有代碼。

　　基于風險的測試 —— 依據產品潛在風險的高低確定測試重點，首先發現重大錯誤

　　1. 分析測試環境、產品元素和質量準則以確定各種風險源；

　　2. 將測試集中在具有潛在高風險的領域；

　　3. 利用測試結果來精練風險分析結果；

　　4. 注意不要完全忽視低風險領域——因為風險分析結果可能是錯誤的。

　　聲明測試 ——驗證每一個與產品有關的聲明

　　1. 確定那些包括產品聲明（顯式的和隱式的）的參考資料；

　　2. 分析每一個聲明，澄清模糊的聲明；

　　3. 驗證每個聲明；

　　4. 如果是利用顯式的規格說明進行測試，保證它與產品本身保持一致。

　　探索式測試 —— 在不斷探索的過程中（迭代和并發行為）進行測試設計和執行

　　1. 產品探索，發現和記錄產品目標、功能、處理的數據類型和潛在不穩定域；

　　2. 測試設計，確定產品操作、觀察和評估的策略；

　　3. 測試執行，操作產品，觀察結果，并使用這些信息形成產品應如何工作的假設；

　　4. 啟發式規則，利用各種指導性原則幫助決定應做什么；

　　5. 可評審的結果，探索式測試是一個結果導向的過程，應確保測試結果可被評審以資證明。

原文轉自：http://www.anti-gravitydesign.com