1、历史与三重迷雾
在“认识软件测试中黑天鹅”一文中，我描述了什么是软件测试中的黑天鹅及其特点，本文将探讨测试中的黑天鹅发生之前、之后、以及正在发生之中的故事。
《黑天鹅》一书的作者Nassim指出“历史是模糊的。你看到了结果，但看不到导致历史事件发生的幕后原因。”其实，测试何尝不是这样，假如把测试看成一个盒子，这个盒子也是模糊的，你看不到盒子里面是什么，整个机制是如何运行的。
书中描述：“对待历史问题，人类思维会犯三个毛病，我称之为三重迷雾。他们是：
1）假想的理解，也就是人们都以为自己知道在一个超出他们认知的更为复杂（或更具随机性）的世界中正在发生什么。
2）反省的偏差，也就是我们只能在事后评价事务，就像只能从后视镜里看东西（历史在历史书中比在经验现实中显得更加清晰和有调理）。
3）高估事实性信息的价值，同时权威和饱学之士本身有缺陷，尤其是在他们进行分类的时候，也就是进行‘柏拉图化’的时候。”
我很容易联想到，这三重迷雾分别对应测试中的黑天鹅发生之前、之后、以及黑天鹅形成之中的故事，即：发生之前的“盲目预测”、发生之后的“假想解释”、以及黑天鹅形成之中的“柏拉图化”。
2、黑天鹅发生之前的“盲目预测”
“第一重迷雾就是我们以为我们生活的这个世界比它实际上更加可理解、可解释、可预测”。打开收音机或电视机，你就会听到或看到，每天都有无数的人在信心满满地预测着各种各样的事情：股市的走势、房价的走势、战争是否会爆发、疾病是否会流行。。。
正向Nassim指出的那样，“几乎所有关心事态发展的人似乎都确信自己明白正在发生什么。每一天都发生着完全出乎他们预料的事情，但他们就是认识不到自己没有预测到这些事。很多发生过的事情本来应该被认为是完全疯狂的，但在事情发生之后，看上去就没有那么疯狂。这种事后合理性在表面上降低了事件的稀有性，并使事件看上去具有可理解性。”就拿我所生活的这座城市-上海来说，近来的许多事件都在证实着这点：黄浦江上打捞出数千头病死猪、H7N9的流行，昨天突然看到一条“上海自来水中添加了XX”的微博更是令人触目惊心，我们内心都预测这些事情不应该发生，可是实际上却发生了。
这种黑天鹅发生之前的“盲目预测”让我想到软件测试中版本发布之前的“测试评估（test evaluation）”。一个产品经过测试团队的集中测试后，发布到用户那里，谁能准确预测是否会出现“黑天鹅”呢？在你的团队，在版本对外发布之前，是否需要测试团队填写一个关于产品质量的测试评估表？下图是测试评估表的一个样例。
这里的特性指的是“测试特性（test feature）”。根据各团队上下文的不同，这个测试特性可能与开发特性直接对应，也可能不与开发特性一一对应，每个测试特性对应一条到多条需求（用户需求或系统设计需求）。我最常看见的质量评估说明是“XX特性基本功能正常。”有些人会在后面附上所发现的比较严重的bug。这样的描述显然并不令人满意。
问题是：
每个特性质量的A/B/C/D的结论是否准确？所有特性的A/B/C/D的结论加一起又如何判别整个系统的质量？是否所有特性的质量都是A或B，版本就可以对外发布，并且发布以后不会出现令人意想不到的“黑天鹅”现象？测试人员给出的A/B/C/D有多大成分是基于一种feeling给出的？
对于任何一条需求，开发人员的任务就是实现它，无论是由一个项目组实现，还是多个项目组配合实现。但是，对于测试人员，考虑的事情就复杂一些。我们除了要验证这条需求本身的功能实现是否正确，还要验证该需求和其它功能之间的交互，还要考虑客户可能使用的各种场景（Scenario），包括各种组网场景、各种参数的配置等。如果把测试场景和测试特性交互起来，测试就无穷无尽了，并且也没有必要在每一种测试场景下，都验证被测特性的基本功能、异常功能、与其它功能的交互、非功能属性等各方面。如何设计更有效的、有限数目的用例尽量做到最大的测试覆盖，这属于另外一个话题，本文不做探讨。
毫无疑问，尽管测试设计人员和测试执行人员精疲力尽的试图覆盖该特性的所有可能的场景，测试人员仍然只覆盖了一小部分的场景下的该特性的部分测试用例，如果没有Fatal的遗留问题，是否该特性的质量就可以评价为A或B，并且认为可以对外发布了呢？这种测试评估工作，与其说是让测试人员对被测对象的质量进行测试评价，不如说是让测试人员对被测对象进行质量预测，因为测试人员所了解的只是部分信息，而不是全部。Nassim说“在这些错误的预测和盲目的希望中，有一些愿望的成分，但也有知识的问题。”我更愿意相信，测试人员对产品质量的预测主要是“知识的问题”，毕竟完整测试是不可能的。
既然测试无法做到完整覆盖，不如在有限的时间和资源内，尽可能覆盖典型的场景，测试评估中针对已经覆盖到的典型场景进行评估，具体地，James Bach和Michael Bolton在RST（Rapid Software Testing）课程里提出的三步法可以供参考：
● 测试中发现了哪些问题；
● 做了哪些测试活动发现了这些问题；
● 测试活动本身的有效性如何，哪些地方可以改善。
那么对于典型场景之外的其他场景又如何评估呢，这与测试评价之前的那些测试活动息息相关，也就是与黑天鹅正在形成之中的那些故事有关，我们在后面第四部分再探讨。
