我一向不喜欢凑热闹的，但最近 网上美女主播变大妈此事，不仅仅影响到娱乐群众，还影响到我们软件过程改进专业圈了。我最喜欢的一个公众号“轻松做软件” 号主 珍妮兔 发了一篇文章《美女主播变大妈：在bug翻车现场说测试策略》，发出第一时间，我就拜读了，在实际场景中也让大家了解一种测试策略的制定方法，生动、有趣，挺好。而她的这篇文章，也启发我在质量哲学层面的思绪。质量管理学界至今，一直存在争论。克劳斯比 零缺陷 为代表的绝对哲学，与朱兰、戴明为首的统计学派的相对哲学思维之争。
1
对于此事的经过，我就直接复制 号主 的原文了，我想她不会找怪我的。
这两天直播圈发生了一起严重的翻车事故。
一个一直以“颜值主播”自称的网红女主播“乔碧萝殿下”，因为平台bug，露出了自己的真容，上演了惊人的“美女变大妈”。
这个女主播，平时晒出来的照片是这样的：
她平时直播并不露脸，只是用一张图片遮住自己的头部，像下面这样：
但在这次和另一个女主播连麦的时候，平台出了bug，上面那遮脸的图没有出现，出现了下面这尴尬的一幕（右边那个，就是“乔碧萝殿下“）：
再感受一下这强烈的对比：
看到这一幕，粉丝们都惊呼上当受骗。一个曾经给这位“美女主播”打赏10万的土豪粉丝则直接怒销帐号。
2
现在问题来了，假如你是平台的测试人员，你会把这个bug归到哪一级？假如是 事件中的 乔碧萝 殿下，你又会把这个bug归到哪一个级别呢？我们通常在软件问题会分4个级别，关键、严重、一般、轻微，具体描述
P0: 导致系统崩溃，数据丢失，需要立即处理
P1: 导致主功能不工作，用户可以明显感知
P2: 导致次要功能不工作，用户可以明显感知
P3: 微小的问题，用户可能不会明显感知
珍妮兔，公众号：轻松做软件美女主播变大妈：在bug翻车现场说测试策略
根据我多年测试管理经验，我认为此bug最可能定级为P1/P2级都有可能，取决于产品设计的底层价值观，和对需求特性的分级，因为不是实际团队成员，不臆测了。好了，这么大一个平台出一个这种级别的缺陷，对开发团队来说有什么影响吗？ 可能有影响，但感觉应该也不大，因为，至少平台没有出来为出这个BUG而声明、公关或者道歉。但对这位，乔碧萝 殿下 影响可就大了，直接封号T出主播行列了,可谓，损失巨大，积累巨大粉丝群体 和可能的经济收益，一朝灰飞烟灭了。
如果，我再做一个调查，对于 乔碧萝 殿下对此bug的判定到底是哪一级呢？我想这个答案太明确了，即使平台宕机，也不可以出这种bug。
针对同一个bug，站在不同的立场，会显示出不同的风险等级和标准。
在平台提供者认为，这个bug比例，还是可接受的，快速迭代修复就好。
使用平台的用户认为，这个bug，是 0 接受的。
所以，我们站在不同立场上就会出现对风险不同的判断。无论，你是用DFMEA设计风险识别工具，还是 基于风险的测试设计，都没有办法解决这个底层立场问题。我们回顾2种质量哲学，
第一种，克劳士比的零缺陷理论，质量就是符合要求。100%符合要求，质量只有0,1区别。
另一种，ISO标准组织及统计学派认为，质量是固有属性符合要求的程度，0缺陷是天堂才有的事，现实永远是做不到的，至于是95%，98%，还是90%，需要考虑制造者的经济性了。
克劳士比，在几十年前就论述过，这就是典型的双重标准。我们常常挂在嘴边的用户为中心，以客户价值为依托，用户思维，在具体的工作场景中，可能早就忘记了，或者又夹杂了私货。
3
我其实在6年前，就开始接触和在测试团队中应用基于风险的测试的方法也，是从华为一位资深测试专家那里学习过来的。
这里做个简单介绍， James Bach 在1995年以更时髦的方式第一次介绍了基于风险的测试(RBT)，然后在1999年在一篇叫做《启发式基于风险的测试》中得到更详细的描述：
1. 列出一个风险的列表
2. 进行考察每项风险的测试
3. 当风险消失而新的风险出现的时候，调整测试策略
自那以后，RBT得到了广泛的关注，ISTQB在他们针对基础级别和进阶级别的测试认证中，将RBT认定为一种重要的测试方式。
RBT的最后一个步骤是基于风险的等级，用一组适合的测试用例来覆盖每一个风险项。在实践中，通常给出了一组指导性方针。例如，每一个高风险必须被正向测试用例及负向测试用例所覆盖。另外，至少50%与高风险相关的测试用例应该具有最高等级的测试用例优先级。中间等级的风险主要由正向测试用例覆盖，并且可以分布于最高的三个测试用例优先级中。
基于风险测试的设计方法没问题，但是我问题是在测试策略层面，也就是，不同的风险等级为什么，要用不同测试覆盖度吗？从效率角度，投入产出比，看是有必要。但从质量角度未必。
底层逻辑如果是，提供给客户的产品应该是零缺陷的，完全符合客户的要求（这里零缺陷不是0bug，而是承诺和确定的质量标准）。所以，测试用例的设计，基于零缺陷要求，在可能想到的范畴内进行完全覆盖，策略层级，首先是全覆盖，而不是先就去考虑风险高和低，哪里可以省点事。
但是，项目执行过程中，由于非系统变异的原因，导致需要带风险发出时，这时才会动态根据风险的排序和需求价值来调整测试用例集的抽取，体现基于风险的策略。并且会要求，公司最高管理层进行决策和制定风险应对方案。
所以，在项目计划中，我通常是要求，测试用例设计必须全覆盖，必须完全执行完毕、缺陷要修改到达到准出标准，否则，测试结论是不通过。
但是，如果我们一开始，就是基于风险的策略来制定，测试用例，这就有问题了。也就是我们认为，有些质量风险，我们是可以接受的，可以妥协一部分质量，因为，我们认为这些风险比较小。但客户是否也认为如此呢？以手机为例，对于做到0.1%的返修率，算是非常好的了，但对于，买到这台坏手机的人来说，可能就是100%的返修率了。我们可以承认不足，持续改进。但不能认为，这是理所当然，都不承认有问题，哪里还会去优化和改善问题呢？
我们制造业吐槽的：检验中的AQL的使用，给了所有人犯错的机会，这是一个允许犯错的标准。在软件行业中，我要时刻，警惕双重标准，是否会借助不同的形式，借死还魂。
