什么是软件测试中的黑天鹅

1，黑天鹅以及软件测试中的黑天鹅

　　在发现澳大利亚的黑天鹅之前，欧洲人认为天鹅都是白色的。所以说”黑天鹅“代表了一个小概率事件，它罕有发生，但一旦出现，就具有很大的影响力。“黑天鹅”有着高度不可能事件所应具备的三个特征：第一点是不可预知性；第二点是它所带来的影响是巨大的；第三点是，在此之后，人们总是试图编造理由来作解释，好让整件事情看起来不是那么的随意就发生了，而是事先能够被预测到的—— 通过这样那样的分析。（参考自百度百科）

　　那么什么是软件测试中的黑天鹅呢？

　　举个例子：

　　　　比如一个产品经过一系列测试工作之后，将此产品上线使用。用户在使用该产品后发现并上报了一个bug后，测试人员对其进行深入的分析和重现，最后发现，这个bug的发生是在是机缘巧合（是一个发生概率很小的事件），因为它需要多个条件同时满足才有可能触发这个bug。比如：比如“XX算法开关必须打开、XX算法开关又必须关闭、XX参数必须取某个特定值、用户的使用环境必须是XX个场景、硬件必须是使用XX接口板、软件必须是XX版本、XX的带宽恰巧又不够等等”，在用户那头，只要有一个条件不满足，那么都不会出现这个bug。

　　　　发现了用户上报的这个bug后，按例要记录下来并分析“后续如何发现这类缺陷，确保不遗留”。实际上我们并不知道如何避免这样的缺陷再次发生，实际上，如果从正向设计的角度，我们无论如何也不会设计一个满足上述所有条件的用例，也不会去执行这样的测试。不过，我们不得不费尽心思地去思考，这个bug的发生是如何有其合理性的、是可以解释的、因此也是可以预防的，以填补报告里这一项的空白。

　　上面描述的测试活动中的例子满足“黑天鹅事件”中的三个特征：

稀有性或者意外性（不符合预期）

冲击性，即它会产生比较严重的影响

事后(而不是事前)可预测性，人的本性促使我们在事后为它的发生编织理由，并且或多或少地认为它是可解释和可预测的。

　　很多重要的线上bug不就是测试中的“黑天鹅”吗？它们的发生在你的预期之外、产生了极端的影响、事后人们总是认为这些bug是可以避免的。仔细想一想，你所在的项目中是否有“黑天鹅”?

2，如何认识软件测试中的黑天鹅呢

　　造成“黑天鹅”现象的可能有很多种原因，从测试的角度讲，我们如何来认识软件测试中的“黑天鹅” – 那些总是让人意想不到又产生严重后果的bug呢?

　　2.1，人们习惯于用确定性的理论去推测那些不确定的事物。RBT(基于风险的测试)是个不错的方法，有些人会按照既定的套路使用RBT：在项目的某个时间点，邀请相关人一起收集风险、分析风险，然后按照风险分析结果开展测试活动。但是风险是时刻变化的、风险是不能确定的，你不可能提前预期所有的风险，你得学会“以动制动”，动态地、持续地应用RBT技术。哪怕如此，你仍然无法避免所有的风险，仍然会有“黑天鹅”发生，因为软件测试的过程充满了随机性。

　　2.2，ReqBT(基于需求的测试)是个至少从数学上说很严谨的测试技术，它会用因果图的方法把业务中的每一个原子逻辑规则都表达出来。ReqBT的创始人Richard Bender认为只要使用了ReqBT方法，不会遗漏一个从黑盒角度讲、功能上的、业务逻辑相关的、严重的bug。我深知这套方法的妙处，但仍然对如上的陈述有所怀疑，原因无他，测试中的不确定性太多，没有哪个确定性的理论是银弹，可以保证没有某类的“黑天鹅”发生。（从理论上将所有可能性组合起来就不会遗漏任何一个测试case，但这个操作难度和时间花费可想而知）

　　2.3，这些形式或模式确定的理论的用处是显而易见的、在测试活动中再加上使用不确定性的技术比如ET(探索性测试)、RST(快速软件测试)等等。应该说，这些确定性的方法(RBT、ReqBT等)和不确定性的方法(ET、RST等)结合起来使用的话，“动静结合”，会更有效地减少测试中“黑天鹅”的发生（只能说减少）。

3，结论

　　你看到一个后果很严重的缺陷，正是由于你认为它不应该发生?这是不是很奇怪?不管你采用什么样的测试方法、你的测试团队有多么强大、你在测试上投入了多少人力物力，测试中的“黑天鹅”总会发生。就像敏捷里承认变化总会存在而去拥抱变化一样，我们也应该正视测试中“黑天鹅”现象的存在，并尽最大可能地多尝试以减少“黑天鹅”发生的机会(拓展已知领域、减少未知领域)，并且一旦“黑天鹅”发生了尽最大可能地把握黑天鹅机会(分析那些未知点，更好地应用不确定类的方法，寻求测试改进)。

部分内容参考：http://www.tarena.com.cn/rjjswz/20130313/1653.html