【IT168 技术文章】

    读理工科的人多多少少做过物理实验，从中学到大学有数不清的机会。对照书本的步骤一项一项做下来，看到预期的结果就收工走人，不然就找原因直到得到正确结果为止。
    这就是物理实验吗？
    从事科研工作的人对这种“实验”嗤之以鼻。这样做除了应付一下教育部一点价值都没有。
    科学研究是要探索未知的世界，并没有一个先知可以断言某件事情，而我们不经证实就奉为真理。出发点不同，行为的效果便大相径庭。要探索未知的世界，除了试验既定的路线外，还须广历不同的路线，获得大量的信息来了解世界的真相；反之仅仅是重复的话，只需要走固定的步骤，如果结果不同还要想方设法为预期结果辩护，实在是南辕北辙。
    有人会问，科学家重复同行的实验又作何论？那时实验结论尚未成为公论，需要重复已有实验，并辅以新的实验来证实怀疑；也有挑战现有理论，改变条件试图证明新的理论。这些都是为了探索证实未知的世界，出发点大不一样。
    那么，软件测试是为了探索世界还是重复检验呢？
    有人认为，程序员写的代码，设计目的是明确的，所用技术是清晰的。只要有领域内的专家，所有软件行为都是可预期的，软件测试就是例行公事再确认一下。
    早期的计算机工作者的确是这样的，他们都是领域内的专家，根据代码能够准确指出程序的行为。如果说他们是上帝，程序就是他们完美的伊甸园，什么都在计划之内。
    然而时过境迁，现在的软件团队里面不可能所有人都是专家，也不是所有领域都有专家。除了火箭控制之类要求高可靠性的系统，大多数的软件都是由非专家编写出来的。所以程序员不一定知道哪里有死锁和饿死，不一定知道哪里有资源泄漏，不一定知道哪里有兼容性问题。他们可能还是上帝，只是做出来的不再是伊甸园了。以今天软件系统的复杂度而言，每个团队都维护一大堆上帝成本太高。
    因此，程序员很多对他们作品的假设，未经证实之前不一定正确：
    “这个列表会列出所有结果” -- 没有或者很多结果的时候呢？
    “这个列表不会有重复的对象” -- 删除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的承诺；你不用关心其他模块的实现假设，因为有对接口协议的承诺。但是很多来源于这个软件本身的假设，并没有经过验证，这些才是我们需要关注的假设。
    而正是这些假设来源于软件本身，测试员需要从外到内全面了解整个软件，才能找到全部假设并一一加以验证。这同时也是白箱测试和黑箱测试并存的原因：只观察软件外部，不能检验内部实现的假设；只观察软件实现，不能检验用户交互的假设。
    最后，有一个相通的问题，如果现有高考制度的弊端看成是一个bug，你又可以改变不同条件检验你的设想，你将通过哪些实验找出根源所在？
    我在《读者》2007年第12期看到一篇文章，它所列出来的高考制度相关因素之多，会令你觉得需要做的实验实在是一个天文数字。这会令你觉得，从事计算机行业比起从事行政管理，实在是要简单不少。