可用性测试

肾虚道长

　　如今的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展示了测试用例。