Google软件测试之道(6)—风险分析

发表于:2013-10-16 16:16

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:51Testing    来源:51Testing软件测试网

分享:
  图3.7所示为另外一种视图。
  
▲图3.7  另外一种Google+的ACC电子表格
  3.2.2  风险
  风险无处不在--在家里,在路上,在办公室。我们所做的任何一件事情都有风险相伴,软件交付也不例外。我们购买更安全的汽车、使用防御性驾驶(defensive driving)方法可以降低驾驶的风险。在单位,我们在会议中小心说话,在选择项目时考虑技能的匹配程度,以便减少失业的风险。如何降低软件交付的风险呢?如何应对软件发生故障,并给公司声誉带来难以估量的伤害这一极大可能事件呢?毕竟,没有完美的软件。
  显然,不交付软件不是一条可选之策。尽管这是一种完全消除了故障风险的方法,而且公司是从可以掌控的风险中盈利的。
  注意我们并没有说"准确量化的"风险。至少就我们的目的而言,风险没有数学上的精度要求。我们行走在人行道上而不是大街中央,并不是因为有什么公式计算出59%的风险降低,而只是凭借一个常识:对行人来说,大街中央不是一个安全的地方。我们购买带安全气囊的汽车,并不是因为我们理解提高事故幸存概率的数学知识,而是因为安全气囊显然可以降低脸被方向盘撞烂的风险。无需太高的精度,风险缓解即可以发挥强大的作用。确定风险的过程称为风险分析。
  1.风险分析
  在软件测试中,我们按照一个常识性的过程来理解风险,下面是一些可供参考的因素。
  - 哪些事件需要担心?
  - 这些事件发生的可能性有多大?
  - 一旦发生,对公司产生多大影响?
  - 一旦发生,对客户产生多大影响?
  - 产品具备什么缓解措施?
  - 这些缓解措施有多大可能会失败?
  - 处理这些失败的成本有哪些?
  - 恢复过程有多困难?
  - 事件是一次性问题,还是会再次发生?
  影响风险的因素很多,试图精确地、定量地计算风险比缓解风险还要麻烦。在Google,我们确定了两个要素:失败频率(frequency of failure)和影响(impact)。测试人员用这两个要素给每项能力打分。我们发现,风险实际上是一个定性的相对值,而非一个定量的绝对值。风险分析的目标不是要给出一个精确的值,而是要识别一个能力与另一个相比风险是大是小。这对于决定以何种顺序测试哪些能力足够了。GTA提供了这一选项,如图3.8所示。
  GTA中的风险发生频率有4个预定义值。
  - 罕见(rarely):发生故障的可能性很小,发生问题后的恢复也很容易。
  示例:Chrome的下载页面(http://www.google.com/chrome)。绝大部分内容是静态的,可以自动检测客户端OS。即使页面的核心HTML或脚本发生了崩溃,也很容易通过监视代码发现。
  
▲图3.8  GTA中对Google+依照失败频率和影响所做的风险估计
43/4<1234>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号