软件测试中的黑天鹅（三）——测试的平均斯坦与极端斯坦

1. 突破性与非突破性

《黑天鹅》里谈到了突破性与非突破性的概念。

这世界上有些职业的收入是不具突破性的，比如面包师、咨询师、按摩师、牙医等等，其收入受到既定时间内所服务的客人的数量的限制，这种工作在很大程度上是可以预测的，面包师必须为每一位客户烤出新面包，不论他出售的面包单价有多贵，其收入总是受到限制的。

而另外一些职业如录音师、电影演员、作家、投机师等等，他们只需花费单次的投入而不必过多劳动就有可能使得收入后面增加几个零，《哈利·波特》的作者不必每次有读者想读这本书的时候就得为其重写一遍，这种职业属于收入具有突破性的职业。

仔细想想，就会发现，突破性的工作往往是那些更擅长运用和组织创造性思维和创新技术的工作，而不那么具有突破性的部分往往可以被剥离出去，交给那些按照计件取酬、或按时取酬的人去做。

测试是否是具有突破性的工作？这个不能一概而论，测试的范畴太大了，包含了太多的内容，我们在后面的部分会持续讨论这个话题。

2. 平均斯坦与极端斯坦

这种突破性与非突破性的差异与另外两个概念有关：平均斯坦与极端斯坦。

人的身高、体重等物理属性是不具有突破性的，体现的是一种叫做“平均斯坦（Mediocristan）”的现象。拿《黑天鹅》里的例子为例：假如从普通人群里随机挑选 1000 人并排站着，然后把你能想到的最重的人加入样本，假设他的体重是平均体重的 5 倍，在总体重中也不过占了 0.5% 而已，假设你挑选了 10000 人，他的体重所占比例几乎可以忽略不计。“在理想的平均斯坦，特定事物的单独影响很小，只有群体影响才大。”实际上，对于平均斯坦而言，“当样本量足够大时，任何个例都不会对整体产生重大影响。”

而人的收入是具有突破性的，体现的是一种叫做“极端斯坦（Extremistan）”的现象。假如考虑的是这 1000 个人的收入，如果把比尔·盖茨放入样本，那么他的资产占总资产的比例是多少？可能所有其他 1000 人资产总和也不过是比尔·盖茨的资产的零头。在极端斯坦，个体对整体产生的作用是具有突破性的，可以产生不成比例的影响。值得注意的是，“极端斯坦能够制造黑天鹅现象”。

对软件测试而言，由于黑天鹅的影响巨大，我们需要时刻注意区分，哪些是极端斯坦的问题，哪些是平均斯坦的问题，并利用我们收集到的信息，帮助判断如何避免黑天鹅现象的发生、或者是促成黑天鹅现象的发生。

3. 测试里的平均斯坦

关键字：平均斯坦，大数定律，N 的平方根定律

假如你是一名测试经理，每天有无数的数据涌入你的大脑，你需要学会如何判断和使用这些数据，来帮助你更好的管理你的测试项目。

假如你需要为一个新的测试项目制定一个测试计划，你需要先做测试估计，这个项目需要投入多少测试人月？大概能执行多少个手工测试用例？测试计划、测试设计、测试执行的时间大概各占多少？等等。有一种做法是参考这个产品的各历史版本的产品规模和测试投入情况，从而估算出当前版本的测试投入。

当你这么做的时候，你要知道：

• 你面对的是一个平均斯坦的问题；
• 也许某个历史版本的数据显得异常突出（偏大或偏小），但你不必特别在意，甚至估算的时候会忽略掉这些畸点数据；
• 你估算的准确程度受所选择的历史样本数据量的影响，如果你只有一个历史版本可供参考，你估算的偏差可能会很大；
• 你关心的是这些数据总体上对你要做的决策的参考价值，而不是在追求一个绝对准确的估计值，因为你知道，不论你多么努力，都不可能制定一个绝对准确的测试计划。

类似的平均斯坦的例子有，如果你想了解你的测试团队平均生产力，比如“日执行用例数”、“日设计用例数”、“日提交问题单数”等等，你不妨观察一段时间，记录数据，算个平均值。当然，你这么做是因为你此时更关注集体事件、平均事件、常规事件和已预测到的事件对你的影响，并且容许有一定的误差存在。

Gerald M. Weinberg 在《An Introduction to General Systems Thinking》里谈到的“大数定律”与平均斯坦有关。19 世纪的物理学家希望研究瓶子里空气分子的运动，他们没有办法搞明白每一个分子的运动情况，因为分子的数量实在是太大了，而不得不假设他们所感兴趣的观察特性是大量分子的一些平均特性，而不是其中任何个体的特性。由于分子的数量特别大，他们的研究也满足所谓的“大数定律”：观测样本的数目越多，观测值越接近于预测的平均值。而 SchrÖdinger 更是给出了预测准确程度的“N 的平方根定律”：

如果假定由 n 个分子组成的某种气体在一定压力和温度下具有一定的密度，如果在某个特殊时刻检验它，结果表明上面的表述是不准确的，其偏离的数量级大约为 n 的平方根。如果 n 为 100，则偏离值约为 10，相对误差为 10%；如果 n 为 1000000，则偏离值约为 1000，相对误差为 0.1%。

所以，当我们需要关注整体的特性，而不是某个个体的特性时，我们所基于的这个样本数量必须足够大，否则不足以建立据此判断的信心。记得有一个团队开始尝试敏捷开发模式时，一个迭代下来，只发现了少量的 bug，这样的情况持续了数个迭代。这与他们之前使用瀑布模式开发时总是有大量的 bug 冒出来差别较大。无论是开发人员还是测试人员，无论是项目经理还是测试经理，都不确定这个现象到底是好还是不好：是产品质量确实提高了所以 bug 更少了？是敏捷确实使得大量 bug 在过程中被提前发现并预防了？还是紧凑的迭代过程使得测试人员没有足够的精力和时间做更深入的测试？确实，如果仅通过有限的 bug 数、有限的测试时间内执行的有限的测试用例数，来评估整个被测系统的质量，确实难以建立起评估的信心，因为所参考数据的基数 n 不够大。

这让我想起那个“测试何时可以结束”的问题，答案可能是“No ending”，只要还有时间，只要条件还允许，我们应该继续测试，增加 n 的测试样本量，扩大 n 的覆盖范围，多一些对系统未知领域的了解，那么，测试为利益相关者提供的质量相关的信息就更为准确。

这也提醒我们，如果你希望通过快速而少量的测试活动来获得对整个系统质量的初步认识，那么尽可能的增大 n 的覆盖范围，让其更具有随机性和普遍意义。比如要做一个 1 天的针对被测系统的验收测试，那么验收测试用例的选取要尽可能覆盖的特性更多一些、验收测试用例的数量尽可能多一些。同样地，应用“大数定律 ”的原理，不论你选取的验收测试用例多么多，1 天里能够执行的验收用例的个数是受限的，相对于要很好地了解被测系统的质量应该执行的用例数而言，这个 n 还是小的可怜，这是个平均斯坦的问题，在这里，我们更关注的是整个系统是否可以被“验收”通过，而这 1 天的验收测试的结果和被测系统的真实质量关系并不大。

在软件测试中，当你更关注数据的整体趋势，而不关注单个数据的影响时，你面临的是平均斯坦的问题，此时单个数据是不具有突破性的影响的。那么，至少有两点需要知晓：

• 数据样本量的多少会影响你做判断的准确程度；
• 不论样本量多么大，最终的结论都不可能成为绝对的基准，而仅能作为相对的参考。

4. 测试里的极端斯坦

我一直认为，不论是在软件测试领域还是在其他某个学科领域，数字仅能衡量一部分信息，甚至还不一定是最重要的部分，定量的方法只能作为人们决策中的辅助手段，不应成为主导甚或是唯一的手段。

如果你是一名测试经理，你可能对很多数字很感兴趣，比如：

• 每日发现的缺陷数
• 每日解决的缺陷数
• 每个版本挂起的缺陷数
• 每个迭代或版本发现的致命缺陷数
• 每个迭代或版本发现的严重缺陷数
• 每个迭代或版本发现的一般缺陷数
• 每个迭代或版本发现的提示缺陷数
• 每个迭代或版本发现的资料问题的缺陷数
• 每个迭代或版本非用例发现的缺陷数
• 每个版本探索性测试发现的缺陷数
• 每个版本执行的探索性测试的 session 数
• 每次探索性测试 session 的时长
• 每次探索性测试 session 花在测试准备上的时间
• 每次探索性测试 session 花在测试设计和执行上的时间
• 每次探索性测试 session 花在测试问题调查和测试记录上的时间
• 每日执行用例数
• 每日测试用例 pass 数
• 每日测试用例 fail 数
• 每日测试用例 block 数
• 每日设计用例数
• 每个版本或迭代测试期间新增的测试用例数
• 每个版本或迭代测试期间修改的测试用例数
• 每个版本或迭代测试期间删除的测试用例数
• 每个版本或迭代由于测试本身的原因导致的以非问题关闭的缺陷数
• 每个版本测试与开发的成本投入比
• 每个版本或迭代千行代码缺陷数
• 每个版本或迭代千行代码用例数
• 每个测试人员发现的 bug 数
• 每日处于 open 状态的 bug 数
• 每日处于 new 状态的 bug 数
• 每日处于 retest 状态的 bug 数
• 每日自动化用例的个数
• 每天每个测试人员用于测试执行的时长
• 每个测试用例的设计时长
• 每个测试用例的执行时长
• 每个版本投入的测试人员数
• 每个迭代的测试时长
• 每天测试执行用于搭建测试环境的时长
• 每个版本的缺陷数
• 每个版本用户报告的缺陷数
• 提交一个缺陷报告的时长
• 回归一个缺陷的时长
• 每个阶段的 DDP
• 每个特性的测试设计与测试执行的时长比
• 每个特性的用例发现缺陷的比率
• 每个特性的代码覆盖率
• 每个版本的代码覆盖率
• 每个特性的代码更新率
• 每个版本的代码更新率
• 每个特性的代码圈复杂度
• 每个版本的代码圈复杂度
• 每个版本的测试人员更新率
• 每个版本的开发人员更新率
• 开发阶段版本新增需求比率
• 开发阶段版本修改需求比率
• 开发阶段版本删除需求比率
• 每个迭代的延迟交付时长
• 每个版本的迭代按时交付率
• 。。。。。。

是的，这个关于测试中各种数字的表单可以很长。当这些数字摆到你的面前，该如何分析和对待呢？

例如你一直在观察这个指标“每日发现缺陷数”，随着测试天数的增加，这个值呈现平稳增长然后又平稳下降的态势，临近版本对外交付前一周内的每日发现缺陷数均小于等于 1，整个版本的缺陷总数为 99，除了少数几个严重缺陷早已解决外，其他缺陷均为一般或提示性问题且已得到修复。也许你的结论是：版本可以如期对外交付了。可是在版本发布前一天，突然发现了一个致命问题，这个问题只占所有缺陷的 1%，但是它产生的影响不可小觑，你也许要因此推迟版本发布日期、重新制定测试计划、甚至影响到需求的调整。。。

这一个致命问题无疑是个黑天鹅，它对你来讲是单个事件、意外事件、未知事件、和未预测到的事件，这个个体事件以不成比例的方式影响着整体的决策，你面临的是极端斯坦的问题。极端斯坦问题意味着：很难从过去的信息中做出预测、具有突破性、需要花很长时间了解情况、整体取决于少数极端事件、易于制造出黑天鹅事件。

这让我联想到一个关于火鸡的故事。想象一下火鸡每天都有主人喂食，这样持续了很多天，比如说 1000 天，于是火鸡得到了一个结论，生活就是这样安全而幸福的，随着喂食次数的增加，它的这个信念也增强了。可是到了感恩节前的一天，一件意想不到的事将会发生，从此改变了火鸡的命运，也改变了它坚守很长时间的信念。

测试中类似的极端斯坦现象还有很多。比如你观察某个测试人员“每日执行用例数”来判断每天测试的实际投入情况和测试的生产力，那些异常大的数据不一定就代表着这一天测试工作很饱满、成果很丰硕；那些每日执行用例数为 0 或 1 的日子，也不一定就代表着测试人员投入很少、没有什么收获；有可能测试人员花了整整一天的时间执行了 1 个用例，连午饭都来不及吃，但他发现了软件的一个很大的漏洞、发现了搭建测试环境的秘诀、解决了一个系统性能瓶颈问题。缺少这一天，这个测试人员的成绩平平；有了这一天的这一个用例，这个测试人员成了人们心中的英雄！

您可能已经看出来了，针对同一个指标，如果你希望通过它的变化趋势来获得一个平均值，估计团队的执行能力，那么这是个平均斯坦的问题；如果你希望通过它来做质量相关的决策，比如版本质量是否稳定、测试是否可以结束、测试效率如何、测试效果好不好等，那么这是个极端斯坦的问题。对于极端斯坦问题，仅看表面的数字可能让你觉得很困惑，可能让你做出错误的判断，你得考虑每一个数字背后隐藏的故事，看是否有可能存在某个个体会以不成比例的方式影响整体的决策和判断。当然，极端斯坦有可能制造黑天鹅，但不一定总会制造黑天鹅，对于决策者而言，你需要做好黑天鹅发生的准备。

5. 结论

在一个软件测试项目里，当你需要做一个决策或解决一个问题时，需要：

• 判断这个问题是平均斯坦问题还是极端斯坦问题：即是否存在某个个体会以不成比例的方式影响整体；
• 若是平均斯坦问题，关注集体事件、平均事件、常规事件对你的影响，所选取的样本量尽可能大，且容许存在一定的误差；
• 若是极端斯坦问题，关注个体事件、极端事件、未知事件对你的影响，不是每个个体都同等重要，要找寻那些有重大影响的个体事件重点关注，预测和准备迎接黑天鹅事件的发生。

参考文献

Nassim Nicholas Taleb, The Black Swan: Second Edition: The Impact of the Highly Improbable, 2008

Gerald M. Weinberg, An Introduction to General Systems Thinking, Silver Anniversary Edition

作者简介

邰晓梅：软件测试独立顾问

网址： www.sharetesting.com

博客: www.taixiaomei.com