Web类系统的测试保障体系

原创贾艳丽学而思网校技术团队

Smart Student Service System，智慧学员服务平台，简称4S，是一款网校服务于辅导老师的Web平台，在网校“双师”教学模式下占有举足轻重的位置。辅导老师可根据实际需求登录系统对名下学生进行课上课下学习指导、作业安排以及触达工作。为最终交付给辅导老师一款流畅化、科学化、智能化的辅导平台，QA在测试过程中需要考虑诸多保障方法。本文结合4S平台的测试实践，针对Web类系统保障体系进行一个综述。

一、Web系统基础理论

B/S-Web系统产品形态

B/S结构（Browser/Server，浏览器/服务器模式），是WEB兴起后的一种网络结构模式，产品形态如图1.1所示，在这种结构下的主流工作原理：用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，主要事务逻辑在服务器端实现。浏览器通过Web Server同数据库进行数据交互如图1.2所示。实际工作中，各大互联网公司自有Web产品会根据各自情况进行不同的改造升级，让其性能适应实际使用环境。

图1.1 B/S产品形态概述

图1.2 常见的三层B/S结构图

Web系统通用技术架构

大型网站的运行需要一个可靠、安全、可扩展、易维护的应用系统平台作为支撑，以保证网站应用的平稳运行。结合4S平台，Web系统通用技术架构如图1.3所示，同时业界大型网站在提高各自系统的灵活性以及稳定性上均有一定的投入，如Web展示模板可配化，分布式服务部署等等。

图1.3 Web通用技术架构

Web系统通用测试方法

Web系统的特点是，不需要你安装任何的程序原件，只要通过浏览器访问，能够上网的话就可以使用，在测试工程师的视角Web系统的主要特点如图1.4所示，主要划分为B（Browser）端和S（Service）端。

图1.4 Web系统特点

QA在做Web测试时通常会覆盖用户界面验证，功能测试，性能测试，安全测试，兼容性测试，详细的测试点如图1.5所示。

图1.5 Web测试通用测试点

Web测试工程师通用技能

一个优秀的测试工程师的成长需要从初级->中级->高级->资深最后进阶为专家，整个过程中会get到很多技能，大致可概括为图1.6所示，测试初级阶段我们需要学习的是基础测试理论，了解软件开发的生命周期，熟悉基础工具的应用，随着经验的积累，最后可以精通测试工程用的技能，掌握主流的开发语言，协助开发找到程序中的漏洞，最后达到可以白盒测试的水平，如图1.6所示。

图1.6 Web测试开发工程师技能图谱

二、4S平台测试保障体系

为让4S平台适应各种场景，以及给辅导老师带来更好的用户体验，4S平台不仅在传统Web系统架构上进行改造，平台上汇聚大量功能，如智能辅导工具，学习报告，矩阵等功能；同时对接了集团内外其他多个团队，如学习中心，集团中台，运营商等等。这样就给测试带来一些痛点难点，总结如图1.7所示。测试时需要投入足够的人力和物力，才能保证项目高质量的上线。

图1.7 4S平台测试难点痛点

有痛我们就解决痛，这样才能顺利推进测试工作。如图1.8所示，一段时间以来，我们不断摸索，借鉴道家思想总结出一套适合我们的Web系统保障体系，目标做到赋能业务，辐射周边，提升测试效率。

图1.8 Web测试保障之道术法器

保障之“法”

如果版本开发测试过程中没有流程的约束，会出现什么样的情况？如果不管版本大小、不考虑版本特性强制使用标准流程约束，又会是什么样？我经常听到的抱怨是流程太厚重了，流程导致了版本开发周期变长、成本增加了。可是如果某个产品抛开流程，它是不是可以运转得很好？这个问题你知道，我想对于优秀团队来说，可能可以。但是对于大多团队来说，离开流程的约束或者管控，大概率情况下会出现更多的问题，耗费更多的成本。4S目前实行的项目流程规范如图1.9，目前版本双周迭代，让产品开发测试三方的工作节奏都感觉很舒适。

图1.9 4S项目测试流程

保障之“术”

(1）测试金字塔

我们在测试的时候，不仅要关注需求文档中的需求，还要考虑一些隐藏的需求，以及开发的实现；开发采用不同的实现方式，会产生不一样的测试点，我们要更多的站在用户的角度去考虑用户的使用场景，流程设计是否合理，交互是否顺畅，文字是否有歧义，提示是否明确而友好，开发采用了什么技术，什么框架，设计是否合理，是否高效，是否有扩展性，流程是否可控，是否考虑了异常情况，数据处理是否合理，是否存在性能问题，安全性有没有考虑等等，针对项目的测试有很多分类，比如单元测试、集成测试、组件测试、端到端测试以及探索性测试等，测试金字塔，可以针对各部分投入多少精力给出一定的指导，如图1.10所示。

图1.10 测试金字塔

(2）4S分层测试

测试金字塔中引入的一种思想即分层测试，更多的时候我们做不到理想中的人力投入，当前做得比较多的是大头的UI测试，中间多的接口测试，再加上很少的单元测试。因此在4S中我们根据实际情况分了数据层。服务层，业务层，前端UI测试，这样分层测试的优势是：

①问题定位简单化，测的是哪一层，出问题的就是哪一层，如果从最上层的页面测试，排查问题需要逐层向下排查;；

②节约时间，可以让项目快速迭代，底层提前接入测试，无须等上层都开发完毕后一起提测；

③针对性强，分层测试在用例设计和执行测试的时候，更具有针对性，思维更加清晰，不容易遗漏；

项目分层测试主要关注的功能点，如图1.11所示。

图1.11 4S平台分层测试方法

（3）4S测试项目实践

A. 需求介绍

需求名称：招生服务场景支持，业务全流程如图1.12所示。

需求紧急程度：高优

需求描述：

网校leads重构，招生场景下（转化课）的学员服务由单点服务（班级服务）转化为长线服务（学员服务），尽可能保证学员在网校只有一个招生转化服务者。同时原非课leads及精品课的lp服务会被取消，只有转化课带来的leads才做学员服务，所以需要招生服务在4S进行支持。

图1.12 4S某需求业务流程图

B. 分层测试

在招生服务中4S侧我们引入分层测试，具体层次划分如图1.13所示，这样做的好处是在上线时间紧急的情况下数据层提前介入测试，提前上线部署，为后续业务->前端->灰度->线上环境测试打下一定的数据基础。

图1.13 分层测试功能拆解

C. 问题排查思路

问题：同一学员在供应链中先购买特训班，再购买精品课，4S-我的客户-课程列表中不见特训班和精品课数据展示；

排查方法：为了提高bug的有效率，QA内部会进行严格的定位，最后将问题报给RD，有了分层的结构概念，如图1.14所示，可通过以下步骤排查问题。

图1.14 线下问题排查步骤

结论：通过WEB前端展现的现象，通过业务API->筛选服务->数据底层逐层排查哪层没有数据存储则为哪层的问题。

保障之“道”

（1）测试左移和测试右移理论

大家熟悉的测试工作一般都是接到项目后参与需求评审，然后根据需求文档写写用例和准备脚本，等开发提测之后正式开始测试、提bug、回归，测试通过后就结束上线，之后投入下一个项目继续重复这样的流程。这样的流程看似没什么问题，但缺点是测试同学非常被动，当需求质量、开发质量差的时候你只能被动接受，结果就是你会进行漫长痛苦的测试过程以及因为质量差导致上线延期。如果引入测试左移以及测试右移（模型如图1.15所示），能够让测试拥有更多的主动权，有更充足的时间进行测试，同时不会像之前因为质量差风险高每次都延期上线，并且产品的线上质量也能有保证。