可用性测试

发表于:2015-04-30来源:uml.org.cn作者:火龙果软件点击数: 标签:可用性测试
如今的ICT解决方案的复杂性正在增加,由于位于多个地点并由不同方来管理的集成系统的存在。而他们常常部分由云管理的事实使得事情变得更加复杂。因为组织提供24/7的企业对企业

  如今的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