如今的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中的利益相關者是：
▪功能管理
▪審計員
▪安全員
▪財務管理
▪技術管理
▪服務水平管理（業主）
▪業務
IT服務水平協議也會影響系統的規格。
沒有各方的參與不能達成協議。
因此，SLA將在UCS和OLA變得有形。這些合同也將影響系統規范。
例如，3秒的最大響應時間的要求僅通過基礎設施不能實現。也需要性能優化的軟件去滿足這一要求。
在V模型中，開發測試被描述為一個不同的測試水平。
開發測試將基于SLA （測試基準）上，并由IT服務管理的組織執行。
業務可能為了接受所提供的IT服務，執行不同的開發測試（開發驗收測試） 。
表1展示了：執行以檢查是否服務供應商能夠提供與SLA中所描述一致的議定質量的測試。
表1.被執行的測試
第一列顯示了SLA項，第二列顯示方法/技術，它可用于以檢查是否可以滿足需求。
SLA項被描述為一個ISO 25010質量屬性（ISO 25010質量屬性能讓測試人員理解SLA項并可選擇一個測試技術來測試SLA項）。
可維護性可以在一個靜態的方式通過審查的規范和源代碼的完整性（可用性版本歷史記錄，版本說明等）和可理解性（可用性的設計決策，等等）進行測試。
它也可以通過在其他測試的執行過程中監視和分析解決時間來被隱式地檢查。
為了能夠執行這些檢查，支持組織必須盡可能的逼真。
該系統的安全性，也可以通過審查規格和源代碼來檢查，例如在外部通信使用加密檢查，使用雙因授權方法及其他安全協議。它也可通過“滲透測試”來動態測試。
還有很多工具都可以通過執行上千稱為“黑客”的嘗試來檢查你的系統的脆弱性。
很好的例子是工具Nessus和AppScan。該組織OWASP （開放式Web應用程序安全項目），其重點是提高軟件的安全性，且通過其網站（www.owasp.org)提供關于安全性的有用信息。
系統功能相關或系統效率相關的測試更廣為人知。
已有不少關于這一主題的文章了。
因此，本文的重點不是測試該項。
系統可用性和可靠性相關的SLA項（例如，在系統的正常運行時間和過程中無丟失數據）可以通過使用狀態轉換測試技術來測試。
使用狀態轉換測試技術來測試可用性
下面你可以看到用在測試用例中測試系統可用性的步驟。
測試規范步驟：
1 。詳述系統組件影響系統的可用性
首先必須識別：可能影響系統可用性的不同（基礎的）組件。這可以通過使用一種風險管理技術來完成。組件例子是路由器和服務器。
2 。詳述可能會發生的故障
下一步是定義可能發生在該組件的故障。
風險識別技術，如使用魚骨圖可以幫助識別可能出現的故障。
3 。詳述用來防止這些故障的措施
可以采取不同的措施防止這些故障，如負載平衡（防止因負載峰值造成的停機）和故障轉移機制（防止由不可用的服務器造成的系統停機期） 。
這一步也可能導致額外的識別措施（防止尚未被識別的風險）。
4 。準備狀態轉換圖
狀態轉換圖可以基于在上一步中相熟的措施來準備。這個步驟可以分為兩個子步驟：
A.定義關于這些措施的狀態
措施根據不同的系統狀態做出反應。當一個有效的服務器失效了，故障轉移機制將被激活。這些不同的狀態需要在這一步中定義。
B.可視化之間的狀態和轉換
在第二個子步驟中，需要可視化這些狀態之間的關系（一個狀態轉換圖內）。
在這兒定義導致從一個狀態過渡到另一種的觸發器。
5 。詳述測試用例
狀態轉換圖完成后，可詳述測試用例。
下一個例子可以明確使用狀態轉換測試以測試可用性。
1 。詳述系統組件影響系統可用性
在一個公司的基礎架構里，對系統的可用性至關重要的應用程序和數據庫服務器都確定了。
表2.測試用例
2。詳述可能發生的故障
這些服務器可能是由于交流電源中斷而不可用。
3。詳述為防止這些故障采取的措施
為防止這種電源中斷的度量可能是引進的不間斷電源（UPS）。
4。準備狀態轉換圖
a.定義關于這些措施的狀態
一個簡單的UPS可以有四種狀態：
I.基本電源（或待機模式），其中該系統有正常的交流電源。
II.開，其中，所述交流電源是關閉的或低的。
III.關，其中UPS電源已經用完了。
IV.充電，在UP使用可用交流電源充電。
b.準備狀態轉移圖
下面是屬于這個UPS的狀態轉換圖：
圖2。狀態轉換圖
5。詳述測試用例
最后的步驟是詳述基于所述狀態轉換測試的測試用例。如BS7925-2中所述，狀態轉換測試中的完整性水平可以因使用的不同級別switch覆蓋率而變化。在這個例子中，用了一個0-switch覆蓋，即1個記錄所有有效序列進行了測試。表2展示了測試用例。