软件可测性系列1(Testability)

parrotking51

Overview

• 1.为什么软件可测性很重要
• 2.可控性和可见性
• 3.难以预料的不可测性
• 4.白盒可测性
• 5.黑盒可测性
  

1. 软件可测性概念

软件可测性是指一个软件系统可被测试的困难程度

软件可测性既取决于被测系统，又取决于该系统的开发方式。

• 高可测性：同样的成本，更多更好的测试。
• 低可测性：同样的成本，更少更脆弱的测试。
  

2. 为什么需要提高软件可测性

从经济学方面考虑,我们假设下面的软件开发过程，其他条件都是相等的，并且处于平均水平

• 开发和测试过程都是在特定的预算下进行的，所以最关键的问题是如何最优化最终产出的价值。
• 测试以最少化发布系统的bug的方式来提升价值。
• 越早越好:发布系统越早对我们更有利。
• 遗留问题代价高:遗留问题越晚,修复它的成本就越高。
• 测试的越少意味着遗留问题更多:假设我们的测试找到bug的几率是1/100,系统有1000个潜在bug。我们要运行至少100000个测试才能找出这些bug.假设我们只跑了50000个测试然后发布了，我们的系统可能带着500个潜在的bug。
  

软件可测性能保证系统所隐含的高风险问题数或者高危险的bug数能减少到可以接受的水平内。

也就是说，差的可测性意味着你的系统并不可靠，很可能隐藏了更多的严重的bug 大概有130个因素决定可测性。所有的因素对可测性的影响可以从两个方面衡量

• 效率:平均一个单位的资源所带来的可执行的测试数。翻译略生涩，原文是大概是If you look at the total cost of doing a test,that's all the resources that are consumed in doing testing and divide that by the number of tests,that's the average efficiency. 如果你进行一项测试的总成本,就是在测试过程中所消耗的资源,除以所完成的测试数(可以理解为执行的用例数),即效率。
• 有效性:一个单位的资源所带来的找到一个bug的平均可能性 Effectiveniss is the average probability that when you run that test,you'all find a bug. 有效性是指，在运行测试用例的时候，能找到bug的平均概率。
  

提升软件可测性意味着我们可以执行更多的测试或者提高我们找到bug的概率

接下来在第二部分,我将介绍什么原因导致软件不可测 >

• 参考原文链接：http://robertvbinder.com/software-testability-part-1-what-is-it/
• 2010GTAC分享视频:https://www.youtube.com/watch?v=1keyEiJHqPw
• 结合作者文章以及分享课程综合翻译而成。视频和文档都是比较老的东西，但是思想可以再深度了解一下
  

fhhh_eyou

值得认真学习，查看，谢谢！

parrotking51

fhhh_eyou 发表于 2015-12-16 14:15
值得认真学习，查看，谢谢！

谢谢亲的支持，我会持续更新下去的有些地方翻译的还不太到位，欢迎指点

parrotking51

更新第二部分，关于可控性和可观测性

软件可测性系列2(Testability)

Overview

• 1.为什么软件可测性很重要
• 2.可控性和可见性
• 3.预料之外的不可测性
• 4.白盒可测性
• 5.黑盒可测性
  

1. 可控性

可控性决定了搭建测试环境,运行测试用例所花费的工作量以及在测试过程中,被测系统特定功能和特性对测试用例进行响应所能达到的程度

这一段翻译比较生涩，暂时没有找到合适的句子，可以通过下面列的几项来理解。

考虑系统可控性的时候,可以通过下面的方式进行提问:

• 1、如果要运行我们的测试用例，我们必需要做什么?
• 2、为了做这些事情，我们将要付出多大的代价?
• 3、我们有些测试用例是否很难在被测系统上运行?
• 4、给定一个测试目标,我们是否了解足够多的知识以编写充分完整的用例?
• 5、我们能提供多少测试工具?
  

2. 可观测性

可观测性决定了搭建测试环境,运行测试用例所花费的工作量以及在执行测试用例过程中,运行被测系统特定功能和特性时的系统表现能被评估的程度

• 为了评估测试结果是通过还是失败,我们必需做什么?
• 为了做这些事情，我们将要付出多大的代价?
• 是否很难充分确定对被测系统进行测试的结果?
• 我们是否了解足够的信息来决定测试结果是成功还是失败?
  

我(原作者)在我1993年CACM文章里定义了130个决定可测性的独立点。有6大主要的因子

• 概述 :我们怎么知道要测什么?有项目需求和详细设计吗?他们是否完整?他们是否是最新的?
• 实现:被测系统是什么结构?——它是否很复杂，以至于会隐藏缺陷?为测试目标功能特性而进行环境准备和与其交互是否很困难?
• 内置测试: 被测系统是否有一些内置的功能可以协助我们准备测试环境和评估测试结果?它提供日志吗?它是否进行自检?
• 测试套件: 在构造测试套件的时候是否以高扩展性去构造的,还是完全是一个庞然大物?
• 测试工具: 测试工具是否能够用于自动化回归测试?当我们需要修改测试套件的时候,是否轻松易行?
• 测试过程: 测试工作流程是否补充了开发工作流程?测试工作是被视为跟需求及功能开发一样地位还是作为事后工作来考虑的(地位靠后)?
  

以上总则提供了一个分析的框架。下面是关于实际工作中系统如何降低系统可测性的特定实例

测试领域	降低可控性方面	降低可观测性方面
GUI页面	需要设置/获取抽象的小部件;比较脆弱的界面;延迟;动态部件和定制化部件	格式化后的内容的游标;无文字的输出的干扰,无法下定论;专有的锁定;
操作系统异常	成百上千的操作系统异常,很难触发	沉默失效(自己默默失效,无法观测具体数据)
Objective-C	测试驱动程序无法提前获取运行时定义的对象	运行时对象插桩????（还不太理解）
DBMS和众多单元测试工具	场景太丰富而难以进行mock,为进行可伸缩性测试无法复制事务锁????(不太理解)	必须开发单独的查询数据库语句,有跟事务锁交叉的可能
多层corba	识别一个事务路径；获取所有分布式对象的期望状态	在节点处无法跟踪信息传递(像路径跟踪程序一样)
蜂窝基站	射频加载/传播随着基站数量变化而变化；实际系统只是环境和真实的负载(难以模拟真实的环境)	专有锁；从来不“下线”

接下来在第三部分,我将介绍预料之外的不可测性 >

• 参考原文链接：http://robertvbinder.com/softwar ... -and-observability/
• 2010GTAC分享视频:https://www.youtube.com/watch?v=1keyEiJHqPw 结合作者文章以及分享课程综合翻译而成。
  

parrotking51

第3部分，偶然不可测性


# 软件可测性系列3(Testability)
## Overview
* 1.为什么软件可测性很重要
* 2.可控性和可见性
* 3.偶然不可测性
* 4.白盒可测性
* 5.黑盒可测性


###偶然不可测性

![Mou icon]()

这些舞动的仓鼠是不是很有趣?
如果你不得不测试一些代码，而这些代码的稳定性和可控性让你感觉像转呼啦圈一样，你就不会觉得有趣了。

*为了发现一枚bug，测试人员必须:*

* 1、到达有缺陷的代码
* 2、触发这个bug
* 3、将错误的结果传递到一个可观察的界面上
* 4、错误的结果必须能被观察到
* 5、错误的结果必须被承认是缺陷

少了这些条件的任意一个都意味着一项测试在执行暴露bug的这项任务时失败了。
Jeff Voas在他精彩的可测性分析中提供了一个权威的例子，说明了即算简单的代码也很难被测试。

        int scale(int j) {
    j = j - 1;             // should be j = j + 1
    j = j/30000;
    return j;
    }

#####偶然性正确
对这个细微的功能进行穷尽测试是可能的:总共只有65,536种可能的输入j,所以在一个循环里面嵌套进它,并产生所有的值是简单而快速的。

但是其中有多少测试将会暴露bug?只有6个测试用例会产生错误的结果:-30001,-30000,-1,0,29999以及30000.所有的其他65,530个输入运行都不会有任何失败,这个bug不会被暴露.有多少开发人员会打算进行穷尽测试?这些bug很容易被遗漏。

所以即使很微不足道的程序也会限制可测性,甚至(掩盖)细微的bug.为什么会这样?只是执行带bug的代码,不一定总是能导致可观测的失败(技术术语是"偶然性正确").

是否记得2000年的计算机千年虫?系统已经正常运行了数十年,当运行到1999年12月31号之后,突然失败了。这是一类bug的例子,只有在一些特定的数据值才会产生错误的结果——那种情况下,当年字段从99进位截断到00.许多系统理解00为1900(不是2000)从而导致许多系统的失败。


#####复杂度
复杂难懂也会降低可测性。针对这个的技术定义有很多种,但是在我的演讲中,我想以视觉的和听觉的作为复杂性的象征。作为视觉感受我喜欢Jackson Pollock的《秋颂》:
![Mou icon]()


对于复杂性我们能做些什么?基本的复杂度即函数和特性的实现独立化程度.简单的堆叠,越来越多。但是这个"更多"目前来说为解决应用的问题是有必要,就难以被避免.


偶然的复杂性经常能被避免,然而一般是粗心的业余开发过程或者自私的本地优化造成的结果。实际上，这太常见了，它有它自己的反抗模式:大泥团.当然,这自然就降低了可测性，并且掩盖了很多的bug.

其他降低可测性的方面实例:

* 不确定的依赖
* 竞态条件
* 消息延迟
* 非同步的更新共用的未受保护的数据


舞动的仓鼠是一个很好的视觉比喻——可爱但是非常不稳定.为了避免构建一个会产生不稳定性负面影响的系统,第4部分将讲解,怎样利用白盒技术提高可测性。