认识软件测试中的黑天鹅.docx

认识软件测试中的黑天鹅.docx

《认识软件测试中的黑天鹅.docx》由会员分享，可在线阅读，更多相关《认识软件测试中的黑天鹅.docx（8页珍藏版）》请在冰豆网上搜索。

认识软件测试中的黑天鹅

认识软件测试中的黑天鹅

1、软件测试中的“黑天鹅”

几年前，我带领的一个测试小组遗漏了一个严重的bug到网上，当用户反馈这个bug后，我们对它进行了深入的分析和重现，最终所有人一致认为，这个bug能够发生实在是机缘巧合，因为它需要多个条件同时发生才有可能触发，比如“XX算法开关必须打开、XX算法开关又必须关闭、XX参数必须取某个特定值、用户的使用环境必须是XX个场景、硬件必须是使用XX接口板、软件必须是XX版本、XX的带宽恰巧又不够。

。

。

”，在用户那里，这些条件有一条不满足，就不会发生这个bug。

由于这个bug的影响比较严重，又是用户报告的，照例要提交缺陷根因分析报告。

其中，报告里有一项“后续如何发现这类缺陷，确保不遗漏？

”我们不知道如何避免这样的缺陷再次发生，实际上，如果从正向设计的角度，我们无论如何也不会设计一个满足上述所有条件的用例，也不会去执行这样的测试。

不过，我们不得不费尽心思地去思考，这个bug的发生是如何有其合理性的、是可以解释的、因此也是可以预防的，以填补报告里这一项的空白。

前不久我阅读了一本书叫做《黑天鹅》。

数千年来，人们认为世界上只有白天鹅，但是发现第一只澳大利亚黑天鹅以后，这种牢不可破的观念被颠覆了。

作者指出“黑天鹅事件”满足三个特征：

-稀有性，或意外性，即它通常在预期之外；

-冲击性，即它会产生极端影响；

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

很多重要的线上bug不就是测试中的“黑天鹅”吗？

它们的发生在你的预期之外、产生了极端的影响、事后人们总是认为这些bug是可以避免的。

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

2、对“黑天鹅”视而不见

人们习惯于对“黑天鹅”视而不见。

“社会学家一直错误地以为他们的理论能够衡量不确定的事物”。

人们相信通过使用趋势分析工具和复杂的数学公式可以帮助我们很好地预测股票市场的风险、挑选一支好的股票，结果大失所望的人不在少数；人们相信复杂的科学仪器和先进的数学、物理学、天文学等理论可以帮助我们很好地预测地震、海啸、天气，结果经常有令人意想不到的自然灾害发生。

人们习惯于使用确定性的理论去推测那些不确定的事物，在这个处处都充满了“变数”的时代，“以不变应万变”的做法已不合适。

RBT（基于风险的测试）是个不错的方法，有些人会按照既定的套路使用RBT：

在项目的某个时间点，邀请相关人一起收集风险、分析风险，然后按照风险分析结果开展测试活动。

但是风险是时刻变化的、风险是不能确定的，你不可能提前预期所有的风险，领测国际告诉你要学会“以动制动”，动态地、持续地应用RBT技术。

哪怕如此，你仍然无法避免所有的风险，仍然会有“黑天鹅”发生，因为软件测试的过程充满了随机性。

ReqBT（基于需求的测试）是个至少从数学上说很严谨的测试技术，它会用因果图的方法把业务中的每一个原子逻辑规则都表达出来。

ReqBT的创始人RichardBender认为只要使用了ReqBT方法，不会遗漏一个从黑盒角度讲、功能上的、业务逻辑相关的、严重的bug。

我深知这套方法的妙处，但仍然对如上的陈述有所怀疑，原因无他，测试中的不确定性太多，没有哪个确定性的理论是银弹，可以保证没有某类的“黑天鹅”发生。

但这并不表示这些形式或模式确定类的技术没有任何用处、只要使用不确定性的技术比如ET（探索性测试）、RST（快速软件测试）等就好了。

应该说，这些确定性的方法（RBT、ReqBT等）和不确定性的方法（ET、RST等）结合起来使用的话，“动静结合”，会更有效地减少测试中“黑天鹅”的发生。

3、判断是否是“黑天鹅”

想知道哪些重要的软件缺陷是“黑天鹅”，哪些不是？

只要问一问，这些bug与出现之前所预期的相比较，是否是在预料之中的？

我们会发现，这些重要的bug大体可以分为两类：

一类是可以预期发生的，但是并没有采取及时的措施去规避；一类是不被预期发生的，认为不应该发生这种缺陷。

这就启发我们在做RCA（缺陷根因分析）时，对不同类bug的分析会带来不同的收获。

分析可以预期发生的严重缺陷，可以很好地帮助我们改进已经在实施的确定类方法或技术中的不足。

比如在实施RBT过程中，为什么没有识别出某个风险？

或者为什么对风险级别的估计不足？

或者为什么没有对已知的风险采取风险规避措施？

再比如在应用MBT（基于模型的测试技术）过程中，为什么某一个因子在建模时被遗漏了？

或者为什么基于模型生成测试条件或测试用例时某个重要的参数被忽略掉了？

再比如按照企业既定的流程管理软件测试的过程中，为什么在测试策略或测试方案中忽略了这一风险？

或者为什么在测试分析和测试设计中没有覆盖这个风险点？

或者为什么在测试执行环节没有发现这个缺陷？

等等。

通过这样对的RCA过程，可以更好地帮助我们改善既有的测试方法或流程。

分析不被预期发生的严重缺陷，可以为我们开展不确定类测试方法或技术提供更多的输入和想法。

例如本文开篇所举的那个关于某算法失效的例子，想通过确定类的测试方法、正向的方式提前设计（也就是预期）相关的测试用例，基本不大可能。

相反，我们换一个角度，也许在ET中探索出这个缺陷的几率更大一些，比如适当增加与用户应用环境相关的各种因子组合的复杂场景测试的session。

4、我们所不知道的更有意义

“黑天鹅的逻辑是，你不知道的事比你知道的事更有意义，因为许多黑天鹅事件正是由于它们不被预期而发生和加剧的。

”作者认为现在的世界由不确定性主导，不论这个结论正确与否，单就测试而言，这个结论是非常适用的，软件测试是由不确定性主导的。

测试就是寻找未知的过程，这些未知的事情包括未知的缺陷、未知的被测对象的质量状况、未知的真实的被测对象是什么样的以及所有那些你认为你已经知道的但实际上是你不知道的软件相关的信息，这些未知给予测试挑战的同时也赋予测试很大的意义。

可以这样说，所有的测试用例都是基于测试人员已知的知识设计出来的，执行这些用例有机会发现那些能够被预期的缺陷；而测试中的“黑天鹅”-那些重要的不被预期的缺陷，有多少是由测试用例发现的？

分析每一只“黑天鹅”，会帮助我们发现那些原本对于我们是“未知”的东西，每一只“黑天鹅”的遗漏，都是由于一些“未知”的因素，或者是未知的知识或信息、或者是不知道某些信息的重要程度而加以重视。

下一次测试中，就会有意识地尽量拓宽我们的已知领域，减少“黑天鹅”发生的次数。

探索性测试在拓宽“已知领域”方面功不可没。

当我们需要探索时、当我们不知道下一步测试什么时、当我们想要获得更多的想法时，我们使用探索性测试，ET有助于拓宽我们的测试深度和测试宽度，尽可能扩大已知领域的边界，缩小我们未知的领域。

5、结论

你看到一个后果很严重的缺陷，正是由于你认为它不应该发生？

这是不是很奇怪？

不管你采用什么样的测试方法、你的测试团队有多么强大、你在测试上投入了多少人力物力，测试中的“黑天鹅”总会发生。

作者在《黑天鹅》书中指出人性的一个弱点：

“习惯于学习精确的东西，而不是总体的东西”，并且把“由于只关注那些纯粹而有明确定义的‘形式’而导致的错误”称为‘柏拉图化’”。

测试的柏拉图化思想会让你只关注外在的形式，例如测试的流程是否遵守、测试的模板是否应用、测试方法的具体步骤是否实施，而开始忽略其他不那们具体不那么明确不那么美好和解释得清的事务，忽略那些显得有些混乱和不可琢磨的事务，比如在有些人眼里，探索性测试不容易管理、不好解释给别人、步骤不那么明确、有太多不可琢磨的东西在里面。

就像敏捷里承认变化总会存在而去拥抱变化一样，我们也应该正视测试中“黑天鹅”现象的存在，并尽最大可能地多尝试以减少“黑天鹅”发生的机会（拓展已知领域、减少未知领域），并且一旦“黑天鹅”发生了尽最大可能地把握黑天鹅机会（分析那些未知点，更好地应用不确定类的方法，寻求测试改进）。

1.历史与三重迷雾

在“认识软件测试中黑天鹅”一文中，我描述了什么是软件测试中的黑天鹅及其特点，本文将探讨测试中的黑天鹅发生之前、之后、以及正在发生之中的故事。

《黑天鹅》一书的作者Nassim指出“历史是模糊的。

你看到了结果，但看不到导致历史事件发生的幕后原因。

”其实，测试何尝不是这样，假如把测试看成一个盒子，这个盒子也是模糊的，你看不到盒子里面是什么，整个机制是如何运行的。

书中描述：

“对待历史问题，人类思维会犯三个毛病，我称之为三重迷雾。

他们是：

--假想的理解，也就是人们都以为自己知道在一个超出他们认知的更为复杂（或更具随机性）的世界中正在发生什么。

--反省的偏差，也就是我们只能在事后评价事务，就像只能从后视镜里看东西（历史在历史书中比在经验现实中显得更加清晰和有调理）。

--高估事实性信息的价值，同时权威和饱学之士本身有缺陷，尤其是在他们进行分类的时候，也就是进行‘柏拉图化’的时候。

”我很容易联想到，这三重迷雾分别对应测试中的黑天鹅发生之前、之后、以及黑天鹅形成之中的故事，即：

发生之前的“盲目预测”、发生之后的“假想解释”、以及黑天鹅形成之中的“柏拉图化”。

2.黑天鹅发生之前的“盲目预测”

“第一重迷雾就是我们以为我们生活的这个世界比它实际上更加可理解、可解释、可预测”。

打开收音机或电视机，你就会听到或看到，每天都有无数的人在信心满满地预测着各种各样的事情：

股市的走势、房价的走势、战争是否会爆发、疾病是否会流行……

正向Nassim指出的那样，“几乎所有关心事态发展的人似乎都确信自己明白正在发生什么。

每一天都发生着完全出乎他们预料的事情，但他们就是认识不到自己没有预测到这些事。

很多发生过的事情本来应该被认为是完全疯狂的，但在事情发生之后，看上去就没有那么疯狂。

这种事后合理性在表面上降低了事件的稀有性，并使事件看上去具有可理解性。

”就拿我所生活的这座城市-上海来说，近来的许多事件都在证实着这点：

黄浦江上打捞出数千头病死猪、H7N9的流行，昨天突然看到一条“上海自来水中添加了XX”的微博更是令人触目惊心，我们内心都预测这些事情不应该发生，可是实际上却发生了。

这种黑天鹅发生之前的“盲目预测”让我想到软件测试中版本发布之前的“测试评估（testevaluation）”。

一个产品经过测试团队的集中测试后，发布到用户那里，谁能准确预测是否会出现“黑天鹅”呢？

在你的团队，在版本对外发布之前，是否需要测试团队填写一个关于产品质量的测试评估表？

下图是测试评估表的一个样例。

这里的特性指的是“测试特性（testfeature）”。

根据各团队上下文的不同，这个测试特性可能与开发特性直接对应，也可能不与开发特性一一对应，每个测试特性对应一条到多条需求（用户需求或系统设计需求）。

我最常看见的质量评估说明是“XX特性基本功能正常。

”有些人会在后面附上所发现的比较严重的bug。

这样的描述显然并不令人满意。

问题是：

每个特性质量的A/B/C/D的结论是否准确？

所有特性的A/B/C/D的结论加一起又如何判别整个系统的质量？

是否所有特性的质量都是A或B，版本就可以对外发布，并且发布以后不会出现令人意想不到的“黑天鹅”现象？

测试人员给出的A/B/C/D有多大成分是基于一种feeling给出的？

对于任何一条需求，开发人员的任务就是实现它，无论是由一个项目组实现，还是多个项目组配合实现。

但是，对于测试人员，考虑的事情就复杂一些。

我们除了要验证这条需求本身的功能实现是否正确，还要验证该需求和其它功能之间的交互，还要考虑客户可能使用的各种场景（Scenario），包括各种组网场景、各种参数的配置等。

如果把测试场景和测试特性交互起来，测试就无穷无尽了，并且也没有必要在每一种测试场景下，都验证被测特性的基本功能、异常功能、与其它功能的交互、非功能属性等各方面。

如何设计更有效的、有限数目的用例尽量做到最大的测试覆盖，这属于另外一个话题，本文不做探