戳蓝字“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
福利
扫描添加小编微信,备注“姓名+公司职位”,加入【云计算学习交流群】,和志同道合的朋友们共同打卡学习!
推荐阅读:
真香,朕在看了!