1、软件测试中的“黑天鹅”
几年前，我带领的一个测试小组遗漏了一个严重的bug到网上，当用户反馈这个bug后，我们对它进行了深入的分析和重现，最终所有人一致认为，这个bug能够发生实在是机缘巧合，因为它需要多个条件同时发生才有可能触发，比如“XX算法开关必须打开、XX算法开关又必须关闭、XX参数必须取某个特定值、用户的使用环境必须是XX个场景、硬件必须是使用XX接口板、软件必须是XX版本、XX的带宽恰巧又不够。。。”，在用户那里，这些条件有一条不满足，就不会发生这个bug。
由于这个bug的影响比较严重，又是用户报告的，照例要提交缺陷根因分析报告。其中，报告里有一项“后续如何发现这类缺陷，确保不遗漏？”我们不知道如何避免这样的缺陷再次发生，实际上，如果从正向设计的角度，我们无论如何也不会设计一个满足上述所有条件的用例，也不会去执行这样的测试。不过，我们不得不费尽心思地去思考，这个bug的发生是如何有其合理性的、是可以解释的、因此也是可以预防的，以填补报告里这一项的空白。
前不久我阅读了一本书叫做《黑天鹅》。数千年来，人们认为世界上只有白天鹅，但是发现第一只澳大利亚黑天鹅以后，这种牢不可破的观念被颠覆了。作者指出“黑天鹅事件”满足三个特征：
- 稀有性，或意外性，即它通常在预期之外；
- 冲击性，即它会产生极端影响；
- 事后（而不是事前）可预测性，人的本性促使我们在事后为它的发生编织理由，并且或多或少地认为它是可解释和可预测的。
很多重要的线上bug不就是测试中的“黑天鹅”吗？它们的发生在你的预期之外、产生了极端的影响、事后人们总是认为这些bug是可以避免的。
仔细想一想，你所在的项目中是否有“黑天鹅”？2013年1月31日，亚马逊主页瘫痪近1小时，你是否提前预期到了（《黑天鹅》书中写到，“从对称的角度讲，一个高度不可能事情的发生，与一个高度可能事件的不发生是一样的”）？12306网站的瘫痪、高铁事故、ATM取款系统故障。。。，你是否能提前预期到？其实，你可能已经发现，“黑天鹅”离我们并不遥远，总是有那么多被认为不应该发生的现象实际发生了。
造成“黑天鹅”现象的可能有很多种原因，从测试的角度讲，我们如何来认识软件测试中的“黑天鹅” – 那些总是让人意想不到又产生严重后果的bug呢？
2、对“黑天鹅”视而不见
人们习 惯于对“黑天鹅”视而不见。“社会学家一直错误地以为他们的理论能够衡量不确定的事物”。人们相信通过使用趋势分析工具和复杂的数学公式可以帮助我们很好地预测股票市场的风险、挑选一支好的股票，结果大失所望的人不在少数；人们相信复杂的科学仪器和先进的数学、物理学、天文学等理论可以帮助我们很好地预测地震、海啸、天气，结果经常有令人意想不到的自然灾害发生。
人们习惯于使用确定性的理论去推测那些不确定的事物，在这个处处都充满了“变数”的时代，“以不变应万变”的做法已不合适。RBT（基于风险的测试）是个不错的方法，有些人会按照既定的套路使用RBT：在项目的某个时间点，邀请相关人一起收集风险、分析风险，然后按照风险分析结果开展测试活动。但是风险是时刻变化的、风险是不能确定的，你不可能提前预期所有的风险，你得学会“以动制动”，动态地、持续地应用RBT技术。哪怕如此，你仍然无法避免所有的风险，仍然会有“黑天鹅”发生，因为软件测试的过程充满了随机性。
ReqBT（基于需求的测试）是个至少从数学上说很严谨的测试技术，它会用因果图的方法把业务中的每一个原子逻辑规则都表达出来。ReqBT的创始人Richard Bender认为只要使用了ReqBT方法，不会遗漏一个从黑盒角度讲、功能上的、业务逻辑相关的、严重的bug。我深知这套方法的妙处，但仍然对如上的陈述有所怀疑，原因无他，测试中的不确定性太多，没有哪个确定性的理论是银弹，可以保证没有某类的“黑天鹅”发生。
但这并不表示这些形式或模式确定类的技术没有任何用处、只要使用不确定性的技术比如ET（探索性测试）、RST（快速软件测试）等就好了。应该说，这些确定性的方法（RBT、ReqBT等）和不确定性的方法（ET、RST等）结合起来使用的话，“动静结合”，会更有效地减少测试中“黑天鹅”的发生。
3、判断是否是“黑天鹅”
想知道哪些重要的软件缺陷是“黑天鹅”，哪些不是？只要问一问，这些bug与出现之前所预期的相比较，是否是在预料之中的？
我们会发现，这些重要的bug大体可以分为两类：一类是可以预期发生的，但是并没有采取及时的措施去规避；一类是不被预期发生的，认为不应该发生这种缺陷。这就启发我们在做RCA（缺陷根因分析）时，对不同类bug的分析会带来不同的收获。
