可用性測試

　　如今的ICT解決方案的復雜性正在增加，由于位于多個地點并由不同方來管理的集成系統的存在。而他們常常部分由云管理的事實使得事情變得更加復雜。因為組織提供24/7的企業對企業的服務，這些集成解決方案的可用性也變得越來越重要。

　　在互聯網上，你會發現數百個銷售同種產品的網店。萬一不可用，客戶就很容易切換到另一家店。

　　因此，一個解決方案的可用性對業務至關重要。大多數情況下，在生產中監測可用性，如果服務不可用就采取改進措施。防止被看作是這種質量特性的業務指標的可用性問題是有必要的。

　　這篇文章介紹了可用性測試使用的測試設計技術：措施可用性的“狀態轉換測試” ( STT )。

　　狀態轉換測試

　　最正式的測試設計技術是基于工藝流程或數據的(根據可能的輸入或設計技巧劃分，因為他們檢測不同的問題。)所以經常去試著用工藝流程導向和數據輸出導向的設計技術的組合。

　　狀態轉換測試設計技術的強大之處在于它是基于機器狀態的，因此，它不同于大多數正式的測試設計技術。

　　可用性

　　在ISO 25010里 ，可用性被定義為： “當需要用到時，一個軟件組件可操作和可使用的程度” 。

　　它還提到，可用性可以由軟件產品處于升級狀態時的總時間比例來外部評估。因此可用性是成熟(控制故障率)，容錯性及可復原性(控制每次故障后停機時間的長度)的組合。

　　大多數解決方案可用性的相關問題是由解決方案運行上的基礎設施事件造成的。每個人都至少可以給出一個他或她由此事件造成的故障的親身體驗的例子，例如：電源故障或從互聯網斷開。這類故障的影響普遍很大。

　　然而，由于它們主要涉及基礎設施(不在項范圍之內)，相關業務風險往往在軟件開發項目中沒有確定且沒有被測試。

　　開發測試

　　負責解決方案“業務管理”或“開發”的部門是“開發測試”的利益相關者。

　　開發測試是基于荷蘭術語“Exploitatie testen ” 。這不是最終的翻譯，但它是最恰當的。

　　也可以翻作 “業務就緒測試”，但這只覆蓋ITIL /服務管理的業務部分，所以，不匹配。“生產驗收測試”也是一種翻譯，但在我看來，它更關注生產環境的驗收。

　　因此，我把 “Exploitatie testen” 翻譯為“開發測試” 。

　　開發測試的定義：

　　檢查是否關于應用程序和底層IT基礎架構的同意或預期的服務水平可以實現。

　　這些協議和/或期望在一個所謂的服務水平協議(SLA )的合同是正式的。

　　一個SLA的定義：

　　一方為客戶另一方為服務提供商的雙方協議。

　　SLA描述了IT服務，文件服務水平目標，并詳細說明了IT服務提供商和客戶的責任。

　　SLA中對解決方案可用性的相關要求進行了描述。

　　圖1顯示了開發測試在V模型中的位置。

　　圖1.開發測試在V模型中的位置

　　(當然)這個過程業務需求的收集。

　　該系統的規格是基于功能和一些非功能的需求。一些業務要求(例如可用性和安全性需求)也將影響與IT服務提供商的合同( SLA)。

　　測試管理技術“風險管理”通過識別并優先考慮關于IT服務管理的業務風險提高了這一過程。

　　SLA中的利益相關者是：

　　1.功能管理

　　2.審計員

　　3.安全員

　　4.財務管理

　　5.技術管理

　　6.服務水平管理(業主)

　　7.業務

　　IT服務水平協議也會影響系統的規格。

　　沒有各方的參與不能達成協議。

　　因此，SLA將在UCS和OLA變得有形。這些合同也將影響系統規范。

　　例如，3秒的最大響應時間的要求僅通過基礎設施不能實現。也需要性能優化的軟件去滿足這一要求。

　　在V模型中，開發測試被描述為一個不同的測試水平。

　　開發測試將基于SLA (測試基準)上，并由IT服務管理的組織執行。

　　業務可能為了接受所提供的IT服務，執行不同的開發測試(開發驗收測試) 。

　　表1展示了：執行以檢查是否服務供應商能夠提供與SLA中所描述一致的議定質量的測試。

原文轉自：http://www.uml.org.cn/Test/201406165.asp