物理实验与软件测试

raining169

读理工科的人多多少少做过物理实验，从中学到大学有数不清的机会。对照书本的步骤一项一项做下来，看到预期的结果就收工走人，不然就找原因直到得到正确结果为止。
这就是物理实验吗？
从事科研工作的人对这种“实验”嗤之以鼻。这样做除了应付一下教育部一点价值都没有。
科学研究是要探索未知的世界，并没有一个先知可以断言某件事情，而我们不经证实就奉为真理。出发点不同，行为的效果便大相径庭。要探索未知的世界，除了试验既定的路线外，还须广历不同的路线，获得大量的信息来了解世界的真相；反之仅仅是重复的话，只需要走固定的步骤，如果结果不同还要想方设法为预期结果辩护，实在是南辕北辙。
有人会问，科学家重复同行的实验又作何论？那时实验结论尚未成为公论，需要重复已有实验，并辅以新的实验来证实怀疑；也有挑战现有理论，改变条件试图证明新的理论。这些都是为了探索证实未知的世界，出发点大不一样。
那么，软件测试是为了探索世界还是重复检验呢？
有人认为，程序员写的代码，设计目的是明确的，所用技术是清晰的。只要有领域内的专家，所有软件行为都是可预期的，软件测试就是例行公事再确认一下。
早期的计算机工作者的确是这样的，他们都是领域内的专家，根据代码能够准确指出程序的行为。如果说他们是上帝，程序就是他们完美的伊甸园，什么都在计划之内。
然而时过境迁，现在的软件团队里面不可能所有人都是专家，也不是所有领域都有专家。除了火箭控制之类要求高可靠性的系统，大多数的软件都是由非专家编写出来的。所以程序员不一定知道哪里有死锁和饿死，不一定知道哪里有资源泄漏，不一定知道哪里有兼容性问题。他们可能还是上帝，只是做出来的不再是伊甸园了。以今天软件系统的复杂度而言，每个团队都维护一大堆上帝成本太高。
因此，程序员很多对他们作品的假设，未经证实之前不一定正确：
“这个列表会列出所有结果” -- 没有或者很多结果的时候呢？
“这个列表不会有重复的对象” -- 删除A之后添加A，且异步的删除失败的时候呢？
“这个列表的输出不会错的“ -- 多个数据源同时对其输入大量的数据呢？
这个结论会导致软件测试的一个可怕悖论：测试用例不少是来自程序员的假设，不正确的假设使得这些用例可能是不正确或无意义的。
这正是很多测试书籍介绍的边界、性能、压力、可扩展和安全测试的由来：正是需要检验那些假设的真实性。
但是事情还没完。
测试员也不是上帝，他们做出来的也不是伊甸园。
如果程序员的产出是代码和bug修复，测试员的产出就是测试用例和bug报告。
我们刚才忽略了bug报告。
bug报告有两个最重要的部分，重现步骤和错误细节。而其中出现的不正确的假设和推理主要有三种：

如果A在B之前出现，A是B的原因
如果A和B同时出现，A与B有因果关系
如果A被证实是B的原因，A是B的唯一原因
我用一个几周前碰到的例子来说明不正确的假设和推理的影响。

用户报告说产品弹出了空白的窗口，于是登记一个bug，还没有重现步骤
到用户的机器（繁体中文Vista）上证实了某个插件开启和关闭后，这个bug出现和消失（事情很顺利吧），于是添加重现步骤：“繁体中文Vista，安装某插件，出现空白窗口；卸载或关闭插件后症状消失“
程序员说肯定是浏览器插件改变了某处打开窗口的行为，代码没有料到这一点，测试员觉得有道理
回到办公室在自己的Vista和XP上试图重现，失败，更坚定是繁体中文Vista的问题
于是在繁体中文Vista上试图重现，失败，傻眼，只好修改重现步骤，暂时去掉繁体中文Vista的字样
呼吁大家帮忙重现
好消息传来，在一台Vista Business Edition上得以重现，于是添加到重现步骤中
在另外两台Business Edition上尝试，一个能重现，另一个不能，又傻眼了
怀疑是CPU或内存负荷造成的竞争条件，发现不能重现的机器和第一台能重现的一样，继续傻眼
连Windows 2003 Server都能重现，无限傻眼
可能是插件版本的问题，发现所有地方都是安装最新的版本
程序员修复之后，所有地方都不重现了，不过被告知离发布时间太短，这个修复不添加到发布版本里了，改为写在已知问题里面
开始仔细检查系统、浏览器和插件的设置
好了，到现在为止13还在进行中。但是请留意几个细节：
12证实了3，如果到此为止，从4到11都不做，那么在用户数不清的平台组合下重现步骤就是个大笑话。错误假设3是一个危险的诱惑。
4、7、10都是有可能停止实验的地方，那样13就永远不会启动，离真正原因更是遥不可及。错误假设1和2都是危险的诱惑。
程序员不一定能做到3，那么在13之前得到的重现步骤都是在把程序员引入歧途。即使修复了，由于不了解真正原因，13所发现的特殊设置可能使这个bug沉渣泛起。
可见，反映真相的全部是重现步骤的灵魂，因为程序员构建出来的世界是未知的，我们需要知道哪些假设还是正确的，哪些已经不正确了。
那么反映全部真相就是测试员要做的全部吗？
请注意还有错误细节。这通常是帮助程序员定位错误的数据，一般是反映出错时系统各方面的状态。
很多软件系统在开发阶段都会输出log，测试员也被要求在bug报告里面提供log。
只是我见过的一个bug报告，把几乎所有东西，包括几百MB的log和crash dump都放进去。程序员看了半天愣是找不着北。后来的事实证明，只要再多做一个改变了条件的实验，问题根源就马上出现在一行log里面了（也就是说，程序员也知道这里要检验一些假设，关键是测试员要接触到）。未经筛选的大量信息等于没有信息。运用逻辑推理定位根本原因是探索未知世界的重要工作。测试员的懒惰浪费了程序员的大量时间。这如同罗列大量的数据，却不告诉读者要反映的意思蕴含在哪里一样。
所以，你会发现，软件测试其实和科研实验，不仅仅是物理，甚至与化学、生物、医学实验，有着高度的相似性。
有人会问，如果每个假设都要验证，测试工作量岂不是很大？
其实，这正是计算机工业发展的标志，从汇编语言、操作系统、高级程序语言到各种框架、架构，都是在使软件开发更专注于有价值的部分，而不用关注早已验证的部分。你不用关心内核/用户态转换的假设，因为有system API的承诺；你不用关心其他模块的实现假设，因为有对接口协议的承诺。但是很多来源于这个软件本身的假设，并没有经过验证，这些才是我们需要关注的假设。
而正是这些假设来源于软件本身，测试员需要从外到内全面了解整个软件，才能找到全部假设并一一加以验证。这同时也是白箱测试和黑箱测试并存的原因：只观察软件外部，不能检验内部实现的假设；只观察软件实现，不能检验用户交互的假设。


本文转自CSDN，papercrane发表于 2007年08月12日

119139107

对比一下 还真是这样
收藏学习了/。。。。。。。

linmi_010

收藏sdlkfj3