美女主播变大妈：在bug翻车现场说测试策略
以下文章来源于轻松做软件 ，作者珍妮兔
戳蓝字“CSDN云计算”关注我们哦！
美女主播变大妈：
在bug翻车现场说测试策略
文 | 珍妮兔
这两天直播圈发生了一起严重的翻车事故。
一个一直以“颜值主播”自称的网红女主播“乔碧萝殿下”，因为平台bug，露出了自己的真容，上演了惊人的“美女变大妈”。
这个女主播，平时晒出来的照片是这样的：
她平时直播并不露脸，只是用一张图片遮住自己的头部，像下面这样：
但在这次和另一个女主播连麦的时候，平台出了bug，上面那遮脸的图没有出现，出现了下面这尴尬的一幕（右边那个，就是“乔碧萝殿下“）：
再感受一下这强烈的对比：
看到这一幕，粉丝们都惊呼上当受骗。一个曾经给这位“美女主播”打赏10万的土豪粉丝则直接怒销帐号。
现在问题来了，假如你是平台的测试人员，你会把这个bug归到哪一级？
P0: 导致系统崩溃，数据丢失，需要立即处理
P1: 导致主功能不工作，用户可以明显感知
P2: 导致次要功能不工作，用户可以明显感知
P3: 微小的问题，用户可能不会明显感知
有人可能说，这就是一个PS功能失效，不影响直播这样的主功能，所以是P2。
有人可能说，不对，PS也是直播的主要特性，尤其是这种美女直播，所以是P1。
从软件研发的角度，定成P1我觉得没毛病。不过要是让“乔碧萝殿下”来定级，她应该宁愿服务器宕机，也不愿意露出自己的真容吧——今天的最新消息，平台已经永久封停了她的账号。
假如我们换一个反差没那么大的美女主播。她平时直播也不挡脸，只是脸比较大，会用“瘦脸”这个功能。让她在“瘦脸”功能失效，和“服务器宕机”之间选择的话...
她还是会选择服务器宕机吧-_-||
那这究竟算是一个P1的bug, 还是算P0呢？
与其讨论这个已经发生的车祸怎么定级，我们来讨论一个更有建设性，也更直击根本的问题——如何制定测试策略，才能避免这样的人间惨剧发生？解答了这个问题，缺陷定级的问题也会迎刃而解。
测试策略听起来很高深莫测，其实是很实在的一个概念。我们知道，任何一个软件，你都无法穷尽它的所有测试用例。那么在无穷无尽的测试用例中，我们按照什么规则，来选择测试用例的集合来做测试？这个选择的规则，就是测试策略。
有人说：“我从来没有思考过什么策略不策略的。我就是直接写测试用例了。”这种情况，其实你也用了测试策略，就是基于需求分析的策略——你拿到一个需求文档，然后就开始照着这个需求文档写测试用例。
今天给大家重点介绍的一种测试策略，叫基于风险的测试策略。
风险是指负面事件发生的可能性。
应用基于风险的测试策略的步骤
1. 识别干系人
2. 请干系人识别出各种风险，并且评估对各个风险的重视程度
3.根据不同的风险，和干系人对这些风险的重视程度，分配测试资源和制定测试力度
采用这种策略，你会发现，同样是直播平台，你的测试策略会不同。
美女直播平台，最大的风险是美女不美了。你的测试策略就要围绕在PS美化效果上，包括各种场景下，比如连麦的场景下，美化效果是不是还在；带宽小的用户，他看到的压缩过的直播效果，压缩算法下的美女是否依然还是美的，诸如此类。
教育直播平台，最大的风险是学员没看清楚，导致学习效果不好。虽然这个平台可能也有PS美化讲师的功能，但你的测试重点更多要围绕课件展示的清晰度，和讲师的语音的清晰度上。
体育赛事直播平台，最大的风险是射门的时候视频卡住了-_-|| （球迷有可能把电脑砸了，后果很严重） 所以测试的重点在流畅度和滞后度上；清晰度反而不是第一要求。
现在你知道如何避免“美女变大妈”了吧？——使用基于风险的测试策略就可以。我们再回头看缺陷分级怎么分这个问题，是不是也简单了呢？同样按照风险来区分就可以。
再往前走一步，如果我们采用的是测试驱动设计（比测试驱动开发还要更近一步哟~），我们是不是可以在做软件设计的时候，就把软件直接设计成——如果美颜功能不生效，就直接静态展示主播的美丽头像呢？（因为我们可能认为“美女不美”这个风险的严重程度，大于“视频中断“这个风险的严重程度。）
最后做个小结，你可以用基于风险的测试策略来计划你的测试用例范围，甚至可以用这样的策略来驱动你的软件解决方案设计。
欢迎你在下面留言，说说你对“美女变大妈”事件的看法~~
参考资料：
百度百科“乔碧萝殿下”、“射门”、“葫芦娃”词条
ISTQB Foundation Level Syllabus
ISTQB Advanced Level Test Manger Syllabus
福利
扫描添加小编微信，备注“姓名+公司职位”，加入【云计算学习交流群】，和志同道合的朋友们共同打卡学习！
推荐阅读：