51Testing软件测试论坛

标题: 软件可测性系列1(Testability) [打印本页]

作者: parrotking51    时间: 2015-12-15 23:36
标题: 软件可测性系列1(Testability)
Overview
1. 软件可测性概念
软件可测性是指一个软件系统可被测试的困难程度
软件可测性既取决于被测系统,又取决于该系统的开发方式。
2. 为什么需要提高软件可测性
从经济学方面考虑,我们假设下面的软件开发过程,其他条件都是相等的,并且处于平均水平
软件可测性能保证系统所隐含的高风险问题数或者高危险的bug数能减少到可以接受的水平内。
也就是说,差的可测性意味着你的系统并不可靠,很可能隐藏了更多的严重的bug 大概有130个因素决定可测性。所有的因素对可测性的影响可以从两个方面衡量
提升软件可测性意味着我们可以执行更多的测试或者提高我们找到bug的概率

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


作者: fhhh_eyou    时间: 2015-12-16 14:15
值得认真学习,查看,谢谢!
作者: parrotking51    时间: 2015-12-22 00:18
fhhh_eyou 发表于 2015-12-16 14:15
值得认真学习,查看,谢谢!

谢谢亲的支持,我会持续更新下去的有些地方翻译的还不太到位,欢迎指点
作者: parrotking51    时间: 2015-12-22 00:26
更新第二部分,关于可控性和可观测性

软件可测性系列2(Testability)
Overview
1. 可控性
可控性决定了搭建测试环境,运行测试用例所花费的工作量以及在测试过程中,被测系统特定功能和特性对测试用例进行响应所能达到的程度
这一段翻译比较生涩,暂时没有找到合适的句子,可以通过下面列的几项来理解。
考虑系统可控性的时候,可以通过下面的方式进行提问:
2. 可观测性
可观测性决定了搭建测试环境,运行测试用例所花费的工作量以及在执行测试用例过程中,运行被测系统特定功能和特性时的系统表现能被评估的程度
我(原作者)在我1993年CACM文章里定义了130个决定可测性的独立点。有6大主要的因子
以上总则提供了一个分析的框架。下面是关于实际工作中系统如何降低系统可测性的特定实例
测试领域
降低可控性方面
降低可观测性方面
GUI页面
需要设置/获取抽象的小部件;比较脆弱的界面;延迟;动态部件和定制化部件
格式化后的内容的游标;无文字的输出的干扰,无法下定论;专有的锁定;
操作系统异常
成百上千的操作系统异常,很难触发
沉默失效(自己默默失效,无法观测具体数据)
Objective-C
测试驱动程序无法提前获取运行时定义的对象
运行时对象插桩????(还不太理解)
DBMS和众多单元测试工具
场景太丰富而难以进行mock,为进行可伸缩性测试无法复制事务锁????(不太理解)
必须开发单独的查询数据库语句,有跟事务锁交叉的可能
多层corba
识别一个事务路径;获取所有分布式对象的期望状态
在节点处无法跟踪信息传递(像路径跟踪程序一样)
蜂窝基站
射频加载/传播随着基站数量变化而变化;实际系统只是环境和真实的负载(难以模拟真实的环境)
专有锁;从来不“下线”
接下来在第三部分,我将介绍预料之外的不可测性 >



作者: parrotking51    时间: 2016-1-6 00:04
第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部分将讲解,怎样利用白盒技术提高可测性。








欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2