近几年直播迅速崛起，电商直播相较于传统的图文卖场具有互动社交属性，其优点是流量转化率高，可以让观众充分了解商品，所以直播已经成为电商业务的重中之重。转转自6.9版本上线直播功能，首先将文玩玉翠作为直播的第一批类目，上线后有显著效果，后续又扩展到手机，奢侈品等，推出直播间鉴定能力，为用户提供更加全面的直播服务。
业务介绍
首先介绍下整个直播的架构，直播简单来说，就是录制->编码->网络传输->解码->播放的过程，主播端负责推流，观众端负责拉流。转转的直播是使用Native的直播基础能力+M页面提供业务能力的形式，Native给用户带来更好的直播体验，M页更方便业务拓展。
下图是转转直播主播开播和观众进入直播间的流程图：
测试重点
现在市场上绝大多数直播间，大致可以分为三个关注点，直播流，直播间消息，直播间业务功能。这三点也是转转直播测试最重要的测试点。
1、直播流，我们需要关注以下几点：秒开展示直播页面(1s左右)，清晰度(流畅，标清，高清)的切换，网络状况，切换对于流的影响，直播的延迟等，以及异常断流，来电等特殊情况的考虑。
2、直播间消息，使用IM进行发送，主要有两部分，一是直播间弹幕消息，二是直播间展示信息，例如：直播间观看人数，点赞数等，对于其边界情况需要特别注意，因为会产生UI和功能上的问题，对于直播间弹幕要关注弹幕的滑动以及弹幕数量的并发、弹幕对于直播间商品卡片的影响等。
3、直播间业务，首先要完成PM的需求，其次还需要关注需求对于直播间基础功能的影响，比如分享直播间到微信后再回到直播间是否会出现断流的情况，以及观众或主播点击跳转到全屏M页面，其直播流的处理；正在观看直播的观众进入到短视频时，两个视频流的处理逻辑等等。
解决方案
我们的解决方案，也是主要针对上面三个测试重点进行的。
1、直播流解决方案，目前还是使用人工的方式去检查和回归，就现在来看回归成本不是特别大，不过这部分的自动化测试已经提上日程。
2、直播间消息，测试难点主要是直播间消息无法模拟，直播间内的消息是socket消息，其不像接口数据，可以修改返回值，从而可以关注直播间前端的展示逻辑和样式。所以我们需要测试人员自己主动发送和控制消息，这样就可以覆盖到更多场景，比如：
直播间观看人数过多、点赞数过多等对于Native的展示问题
弹幕的数量，我们正常发送弹幕最快估计也要一秒一条，但是大量的弹幕并发，对于测试人员来说不是很好模拟。
所以急需一个可以发送直播间消息的服务，于是开发了一个模拟向直播间发送消息的功能，可以很方便的模拟场景和构造直播间消息数据。
3、直播间业务流程，对于基本和复杂的场景，开发了直播间的数据构造，例如：将一个普通用户变成一个主播、修改直播间的状态、发送直播间的商品等，这些数据构造现在已经满足我们日常测试的需要，提高了测试效率。
针对于直播间内的M页，因为我们的M页是主要承接业务的，所以M页的质量也非常重要，项目前期会出现修改直播间外的M页功能影响直播间内的M页，或者底层方法的修改对直播间内M页产生影响，这些都是我们不能接收的。
针对这些问题，我搭建了一套基于Python+Pupptter框架的前端自动化巡检，针对直播间内的M页项目，在其上线时，触发任务自动化检查，主要检查：直播间内M页是否有空白页，M页的基本展示，输入框的输入以及按钮的点击等，从而提高直播间内M页的质量。
后续优化
加强对Native的自动化测试，包括直播流的检测，以及直播基础能力的检查。接口层测试比较弱，需要对单接口进行更多测试，积累更多接口测试场景，从一个单接口变成一个测试场景，实现接口自动化流程，从而提高整体直播质量和效率。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
