Web类系统的测试保障体系
The following article is from 学而思网校技术团队 Author 贾艳丽
作者：贾艳丽，2020年11月份加入好未来学而思网校质量研发部，现任学服测试组测试开发资深工程师。
导读：Smart Student Service System，智慧学员服务平台，简称4S，是一款网校服务于辅导老师的Web平台，在网校“双师”教学模式下占有举足轻重的位置。辅导老师可根据实际需求登录系统对名下学生进行课上课下学习指导、作业安排以及触达工作。据内部数据统计，每日登录平台的辅导老师近万人（7-8月平均水平），随着时间的推移，入驻的辅导老师将越来越多，4S作为一款B/S架构的Web系统，为最终交付给辅导老师一款流畅化、科学化、智能化的辅导平台，QA在测试过程中需要考虑诸多保障方法，因此本文结合4S平台的测试实践，针对Web类系统保障体系进行一个综述。
01
Web系统基础理论
12.1.1 B/S-Web系统产品形态
B/S结构（Browser/Server，浏览器/服务器模式），是WEB兴起后的一种网络结构模式，产品形态如图12.1所示，在这种结构下的主流工作原理：用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，主要事务逻辑在服务器端实现。浏览器通过Web Server同数据库进行数据交互如图12.2所示。实际工作中，各大互联网公司自有Web产品会根据各自情况进行不同的改造升级，让其性能适应实际使用环境。
图12.1 B/S产品形态概述
图12.2 常见的三层B/S结构图
1.2 Web系统通用技术架构
大型网站的运行需要一个可靠、安全、可扩展、易维护的应用系统平台做为支撑，以保证网站应用的平稳运行。结合4S平台，Web系统通用技术架构如图1.3所示，同时业界大型网站在提高各自系统的灵活性以及稳定性上均有一定的投入，如Web展示模版可配化，分布式服务部署等等。
图1.3 Web通用技术架构
1.3 Web系统通用测试方法
Web系统的特点是，不需要你安装任何的程序原件，只要通过浏览器访问，能够上网的话就可以使用，在测试工程师的视角Web系统的主要特点如图1.4所示，主要划分为B（Browser）端和S（Service）端。
图1.4 Web系统特点
QA在做Web测试时通常会覆盖用户界面验证，功能测试，性能测试，安全测试，兼容性测试，详细的测试点如图1.5所示。
图1.5 Web测试通用测试点
1.4 Web测试工程师通用技能
一个优秀的测试工程师的成长需要从初级->中级->高级->资深最后进阶为专家，整个过程中会get到很多技能，大致可概括为图1.6所示，测试初级阶段我们需要学习的是基础测试理论，了解软件开发的生命周期，熟悉基础工具的应用，随着经验的积累，最后可以精通测试工程用的技能，掌握主流的开发语言，协助开发找到程序中的漏洞，最后达到可以白盒测试的水平，如图1.6所示。
图1.6 Web测试开发工程师技能图谱
02
4S平台测试保障体系
为让4S平台适应各种场景，以及给辅导老师带来更好的用户体验，4S平台不仅在传统Web系统架构上进行改造，平台上汇聚大量功能，如智能辅导工具，学习报告，矩阵等功能；同时对接了集团内外其他多个团队，如学习中心，集团中台，运营商等等。这样就给测试带来一些痛点难点，总结如图2.1所示。测试时需要投入足够的人力和物力，才能保证项目高质量的上线。
图2.1 4S平台测试难点痛点
有痛我们就解决痛，这样才能顺利推进测试工作。如图2.2所示，一段时间以来，我们不断摸索，借鉴道家思想总结出一套适合我们的Web系统保障体系，目标做到赋能业务，辐射周边，提升测试效率。
2.1 保障之“法”
如果版本开发测试过程中没有流程的约束，会出现什么样的情况？如果不管版本大小、不考虑版本特性强制使用标准流程约束，又会是什么样？我经常听到的抱怨是流程太厚重了，流程导致了版本开发周期变长、成本增加了。可是如果某个产品抛开流程，它是不是可以运转的很好？这个问题你知道，我想对于优秀团队来说，可能可以。但是对于大多团队来说，离开流程的约束或者管控，大概率情况下会出现更多的问题，耗费更多的成本。4S目前实行的项目流程规范如图2.3，目前版本双周迭代，让产品开发测试三方的工作节奏都感觉很舒适。
图2.3 4S项目测试流程
2.2 保障之“术”
1）测试金字塔
我们在测试的时候，不仅要关注需求文档中的需求，还要考虑一些隐藏的需求，以及开发的实现；开发采用不同的实现方式，会产生不一样的测试点，我们要更多的站在用户的角度去考虑用户的使用场景，流程设计是否合理，交互是否顺畅，文字是否有歧义，提示是否明确而友好，开发采用了什么技术，什么框架，设计是否合理，是否高效，是否有扩展性，流程是否可控，是否考虑了异常情况，数据处理是否合理，是否存在性能问题，安全性有没有考虑等等，针对项目的测试有很多分类，比如单元测试、集成测试、组件测试、端到端测试以及探索性测试等，测试金字塔，可以针对各部分投入多少精力给出一定的指导，如图2.4所示。
图2.4 测试金字塔
2）4S分层测试
测试金字塔中引入的一种思想即分层测试，更多的时候我们做不到理想中的人力投入，当前做的比较多的是大头的UI测试，中间多的接口测试，再加上很少的单元测试。因此在4S中我们根据实际情况分了数据层。服务层，业务层，前端UI测试，这样分层测试的优势是：
问题定位简单化，测的是哪一层，出问题的就是哪一层，如果从最上层的页面测试，排查问题需要逐层向下排查;
节约时间，可以让项目快速迭代，底层提前接入测试，无需等上层都开发完毕后一起提测；
针对性强，分层测试在用例设计和执行测试的时候，更具有针对性，思维更加清晰，不容易遗漏；
项目分层测试主要关注的功能点，如图2.5所示。
图2.5 4S平台分层测试方法
3）4S测试项目实践
A. 需求介绍
需求名称：招生服务场景支持，业务全流程如图2.6所示。
需求紧急程度：高优
需求描述：网校leads重构，招生场景下（转化课）的学员服务由单点服务（班级服务）转化为长线服务（学员服务），尽可能保证学员在网校只有一个招生转化服务者。同时原非课leads及精品课的lp服务会被取消，只有转化课带来的leads才做学员服务，所以需要招生服务在4S进行支持。
图2.6 4S某需求业务流程图
B. 分层测试
在招生服务中4S侧我们引入分层测试，具体层次划分如图2.7所示，这样做的好处是在上线时间紧急的情况下数据层提前介入测试，提前上线部署，为后续业务->前端->灰度->线上环境测试打下一定的数据基础。
图2.7 分层测试功能拆解
C. 问题排查思路
问题：同一学员在供应链中先购买特训班，再购买精品课，4S-我的客户-课程列表中不见特训班和精品课数据展示；
排查方法：为了提高bug的有效率，QA内部会进行严格的定位，最后将问题报给RD，有了分层的结构概念，如图2.8所示，可通过以下步骤排查问题。
图2.8 线下问题排查步骤
2.3 保障之“道”
1）测试左移和测试右移理论
2）测试左移/右移在4S落地
4S测试在测试左移右移中的投入如下：
A. 测试左移
需求阶段，参与需求评审，针对需求文档中的缺陷提出有效意见。
开发阶段，参与开发设计评审，参与开发单元测试讨论。
持续测试，已引入UI/接口自动化，暂未实现全链路持续集成。
B. 测试右移
灰度发布，新功能上线前灰度环境全方位回归测试，减少线上问题。
监控，加入报警监控群，通知开发排查频发报警问题。
用户反馈，参与客诉值班，为线上问题排查主力。
3）线上客诉问题分析
A. 问题描述
问题描述：学生id：68049705 讲次id：1036512 班级id：3220268 课堂巩固无数据 查询是已经有课堂巩固分数的，但4S显示未提交。
B. 排查流程
根据平时客诉值班的经验总结可将该问题归为一类：数据问题，该问题排查流程，如图2.10所示。
总体分为以下几步：
确认问题是否属实。根据问题描述，无法得知该学生的课堂巩固状态是否为未提交，所以需要向客服索要辅导老师id，绑定辅导老师账号查看该学生课堂巩固的状态是否为未提交。
底层数据查询。第一步：4S系统自有数据查询，第二步：4S对接数据源数据查询。
痛点是数据排查链路长，不熟悉数据存储/查询规则将无从下手；没有底层数据查询权限时会有其他耗时。
C. 开发智能诊断工具
针对以上痛点引入首屈一指工具查询平台，快速查询数据，快速得出问题原因，使用方法如图2.11所示。
图2.11 首屈一指查询结果展示
D. 查询结果分析
dataserivce-esmysql-elasticsearch-4S平台前端数据一致，问题原因：数据延迟导致用户使用时数据没有及时更新。
dataserivce-esmysql-elasticsearch-4S平台前端数据一致，与实际数据不符，问题原因：作业端数据没有及时同步给数仓，通知数仓向上拉取最新数据。
dataserivce与esmysql数据不一致，esmysql与elasticsearch数据一致（与实际数据符合），通知数据组开发同学或者使用修复数据脚本同步ES数据。
dataserivce-esmysql-elasticsearch一致与4S前台数据不一致，仅4S前台数值状态显示不对，问题原因：业务数据缓存更新失败，通知4S业务同学排查。
2.4 保障之“器”
QA在测试过程中如果没有提效意识，在人力少，项目急的情况下就很被动，提高测试效率可以从以下几个方面着手：
1）功能测试优先级划分
可以从新功能测试->回归测试->特殊功能测试的顺序着手测试以提高效率。
2）合理分配测试人员
避免全用新人，这样会出现很多新人无法解决的问题；避免全用牛人，因为牛人都有各自独到的见解，会出现意见不统一影响进度情况。
3）优化测试用例
测试用例设计的好也可以提升一部分效率，比如测试用例的执行步骤和数据的冗余；测试用例可读性高，通俗易懂，这样可以减少测试执行人员的学习时间，从而提升效率。
4）借助工具提效
4S在整个测试过程中虽然没有做到全自动化测试，但是特定一些场景中会引入工具提效，如接口测试时使用postman，数据测试时将向kafka中发送数据接口封装成可视化界面，相信后续会有更多的工具运用到4S测试中助我们事半功倍，如图2.12所示。
图2.12 测试提效实施
03
总结与展望
以上是对基于4S平台对Web系统测试方法做了一些总结，不同的人看该文章可能还存在不同的理解，但是我们希望的是通过这篇文章介绍一套完整解决方案对读者起到指导和帮助的作用，抛砖引玉，此外会继续努力，不断优化我们的测试解决方案。
我知道你“在看”哟～