作为一个做了5 年在线教培业务的老兵我来说下自己踩的一些坑先简单介绍一下我们的背景我们在开发系统之初主要做的是面向培训机构的教务系统的然后慢慢把教务系统升级成了教培机构独立的小教学平台后面觉得这个东西很有未来性我们就把这块业务拆出来做一个新的项目叫做X 系统这是一套专给线下培训机构用的教、学一体化的在线教育系统
当时我们在测试这一板块上投入了大量的时间和人力可是依然没逃过硬不起来各种奇奇怪怪的需求各种奇葩的情况都跑出来了比如说有的学校要加一些比较奇怪的数据规则或者流程比如说某个地方规定线下上课时间必须是固定的几类时间表而线上课程又要根据当地法规去适配我们就开始测试这条路了我得先跟你说说我们最开始是怎么掉进沟里的吧刚开始我们在设计的时候就觉得这个功能不复杂测试应该问题不大因为我们当时心里都在想测试不过就是看看功能对不对嘛结果到真测的时候就各种状况都出来了
当时的一个核心难点就是我们需要验证的东西特别多比如说课程有试听课体验这个事情大家都知道很多教育机构都会有这玩意试听功能测试里有很多点我们要确保课程开始结束的时间要严格和试听过课的安排匹配而且试听课的时间设置还不能超课程整体时长远的近端的东西都要对这个事情看似简单其实做着特别难特别是涉及到课程计费这个就更难了如果学生提前进入课堂导致试听了太长时间就会影响到付费用户真正上课那就有用户投诉隐患这个事情是我们一开始就完全没有考虑到的一件事
另一个比较搞笑的问题是在互动这块互动课是这种课很依赖直播技术这部分的技术对接难度也不一样比如说有个直播间的禁发消息的功能我们觉得很简单就是设置一下不让这个或者这几个学员发言就行了可问题在哪呢其实测试发现如果有人连续收到被禁言的消息这个机制会导致他们没办法接收到老师的信息还有可能看不到重要的班级文件这个是当时一个隐藏的大 bug 还有一个是学生之间互骂这个事我们以为简单的发个公告就够了其实学生之间的私信互动也要屏蔽不然真的可能会引发严重的客服工单这就提醒了我们测试不是单纯地验证单一接口的输入输出而是要考虑用户的场景需求
测试工作最大的困难其实是对一些非常复杂的规则的验证像是学员考勤这个点就麻烦透顶比如学生请假要走一个流程需要审批这东西看似小事情我们当时以为直接做个流程管理就行但是实际上这个逻辑复杂的地方就太多比如说申请审批完了学生请假当天能不能上课能不能排其他日子的这个过程里牵涉到现在时间、老师时间学生时间的对称性还有审批优先级什么的真是一个头两个大当时为了搞清楚这个流程调试了好久
现在回头来看当时我们的问题是把测试简单看成功能性验收了认为功能有无就好没想过用户体验其实测试应该不仅仅是检验功能点更重要是要看功能合不合理要从整个教学使用角度来看还有最重要一点就是一定要在真实环境下测试不能光靠人工推模拟情景我们总结了一些经验给后来团队测试新人看看吧
比如说遇到新的交互功能一定要模拟真人使用流程比如说学生报名课程缴费退费这些都是要一步一步照真实操作来如果漏过环节就很可能发现问题我们还建议所有涉及计费的场景都需要多版本迭代测试因为钱的问题真的是太敏感的最后一点也超级重要测试要注重长期运营稳定性这一点是最经常被遗漏的部分我们在项目上线后遇到最大问题是系统卡这是硬件配置优化的问题所以测试的时候除了看基本功能还要关注运行的性能稳定性
其实现在回过头再想想当时的很多错误也不是不可以避免的主要是当时对教育行业理解不太深刻如果再遇到新的机会做测试的话肯定要提前多了解教育行业的法律法规特别是跟课程时间规定收费结算规范相关的事情这方面的东西要是早摸清就能让项目开发少踩坑
总之测试这工作看似平淡实则是块难啃的大骨头尤其是涉及到复杂的在线教育这种业务要做的事情实在是巨复杂了从一开始简单的功能性检查再到后面对规则交互的考量还有到最后的稳定性评估真的每个阶段都有它的难题但是如果你能耐心地一步步解决就会有特别高的成就感这就是在线教育这种行业的特色啦
