这是一篇记录了Web测试点文章，随着技术的不断发展，后续碰到未收录的Web测试点也会收录到此篇文章中，尽量做到汇总全面，最重要的是持续更新中。本篇文章适用于中后台管理系统的测试。

按照测试优先级，Web测试范围可以分为下列几类：

1、功能测试
2、界面测试
3、接口测试
4、兼容测试
5、性能测试
6、安全测试

功能测试

这类测试范围中包含子分类，如：业务流程、页面组件、异常场景、浏览器相关等。在所有测试范围中优先级最高，因为首要保证交付出去的产品用户可以正常使用，故功能测试排第1名。以下将按照子分类逐一介绍。

业务流程

这类测试范围是所有测试范围中最基础、最核心的，依据产品设计等相关资料，须考虑到正常流程、分支流程和异常流程，在设计测试用例时需覆盖所有流程。另外这些用例也可以用于已有产品的回归测试，所以它是重中之重！下图是知乎桌面端的登录页面，从中可以看出有6种登录方式，篇幅有限我挑选验证码登录方式为例，画一张流程图就可以清晰表达业务流程的测试点！

 

知乎桌面版验证码登录流程图：

 

里面并没有关于不符合手机号规范的测试点以及不符合验证码规范的测试点，因为这些不属于业务流程范围内的测试点，故不在此范围内详细说明，它应当属于页面组件测试，请继续往下看！

页面组件

首先需要明白什么是组件？简单的可以认为一个按钮、一个链接、一个输入框等等，这些被成为基础组件，那么对应还有复杂组件，如：日期选择器、地区选择器、文件上传、视频播放、图片预览等组件。拿知乎桌面版登录页面来举例，这就是一个复杂且通用的组件。

为什么要把页面组件拆分出来测试？记得10年前搞测试工作的时候这部分并没有明确划分为一个范围的概念，基本在测试用例的分类里都划分到业务流程类别里。随着技术的发展，很多互联网大厂在增效减能的过程中，页面中某些通用的组件会被高度封装，每一个组件可能都会有专人维护，其他研发人员调用即可，随着这种生产方式流行，慢慢就形成企业自有的一套前端UI组件规范。整个平台中调用这个组件的地方很多，从代码的角度不管从哪里调用，都是调用同一段代码，所以对于测试我们只需对其做专项测试，在后面的迭代中如果没有改动则可以不测，这样会增加测试效率减少重复性工作。

手机号可以采用等价类边界值的方法来验证，这里注意不同国家的手机号对应手机号规范也是不一样的，具体的规范可以详细在网上查查。同理，验证码同样也是采用等价类边界值的方法来验证。

在制定测试计划的时候需要与产品、设计、开发沟通，确定网站都有哪些组件，这样做的目的是在保证测试覆盖度的同时降低冗余的测试工作量。比如：网站中有多个页面使用了自定义的文件上传组件，那么我们只需单独测试一个页面的文件上传，其余页面则不用测试，而关于其他页面组件与当前页面的存在的一些交互则放在如业务流程等等相关测试范围内。

异常场景测试

这个异常场景该怎么理解？主要是针对业务操作异常、网络异常的情况下程序是否能够做出正确处理，下面详细说明一下：

1、系统不允许多端登录、密码错误多次错误会触发安全策略、短时间内多次登录会触发安全策略、极快的时间点击一个按钮是否会触发多次重复请求等等，这些都属于业务操作异常场景；

2、断网的情况下程序是否有给用户友好提示、弱网的情况下程序是否有超时机制，断网和弱网对于编程会分开判断，这些都属于网络异常场景；

浏览器相关

这部分测试点主要是验证网站在能否于浏览器正常的协同工作，比如点击前进、后退、强制刷新等按钮，或者清除缓存、Cookie等操作，网站的表现能否满足预期？

举一个我曾经遇到过的问题，在网页上正常操作跳转是正常的，但是一操作前进、后退、强制刷新就报404，最后经查是Nginx配置问题。

界面测试

在此我需要强调一下界面测试为什么会排名第2，人靠衣装马靠鞍装，界面的美观与整齐性对于用户很重要，我们假设一下你看到一个网页各个元素都不齐，你内心的感受是什么？这个网页做的很Low，视觉上感觉很乱，任何一个人都是颜值控！所以界面测试主要从美观、视觉体验、易用性上来测试，如下：

1、检查整体视觉是否跟视觉规范或者UI设计高保真效果图一致，并且通过更改窗口大小检查页面元素是否按规范布局排列；

2、常规该有的交互必须要有，比如请求过程中的进度动效或者例如下载必须要有进度条展示进度；

3、从用户体验角度给出测试的建议，比如按钮触摸焦点区太小不容易完成点击动作等等；

接口测试

接口测试就是服务端，其目的主要是2个，如下：

1、整套系统提测前，让测试人员尽早介入项目流程，提前发现Bug，减少提测后的Bug数；

2、对前端功能测试覆盖率不足的补充，毕竟只在页面上点点有些功能是测不到的；

测试点如下：

1、单接口测试 正常场景：对软件来说是合理的 异常场景 1）数据异常：参数类型和长度，不满足业务需求 2）参数异常：多参、少参、无参、错误参数 3）业务异常：各种异常状态码的测试 2、多接口测试 将多个接口按照业务流程进行组合测试，就比如知乎验证码登录，先测试获取验证码再测试登录/注册接口，其实就是业务流程测试

兼容性测试

软件在特定的软硬件环境中运行时的测试过程称之为兼容性测试。Web端的兼容性测试主要包括：操作系统、浏览器、分辨率、网速、数据兼容这几个分类。

操作系统

在Web测试的经历中，我没有遇到过需要测试跟操作系统的兼容性，但是见过网上有不少小伙伴记录这一点，所以也将其记录下来，这里的兼容测试主要是针对Web端调用系统的某些功能函数时是否能正常调用，并且因操作系统不一样或者同一操作系统的版本不一样这些功能函数的调用方式也会不一样，不过我总觉的这一测试点有写别扭的地方，就是Web端的JS应该是调用浏览器的Api，然后由浏览器完成与系统层面的交互，不应该是JS直接与系统层交互，这点我是存疑的，但是看到很多测试同学关于这点的记录，所以先记录下来，如果某位大佬能给出一个场景案例，为我解惑，不胜感激。

下面记录了需主要覆盖的操作系统：

1、windows：win7、win8、win10、win11（重点是Windows系列，毕竟这套系统使用率是最高的）

2、macOS

3、Linux

浏览器

目前国内主流浏览器包括：IE浏览器、Chrome、Firefox、Safari、360安全浏览器、360极速浏览器、搜狗浏览器、QQ浏览器、百度浏览器、猎豹浏览器，如果测试人力有限主要覆盖微软系列和谷歌系列的浏览器即可，因为这两个厂家的浏览器使用率最多！作为测试工程师对于浏览器的兼容性测试要注意以下几点：

1、尽量跟进主流厂家的浏览器迭代更新内容，没发布一个版本可以通过官网订阅消息获得内容，了解更新点，判断对现有软件是否有影响，下载最新版本的浏览器进行验证，做到提前发现；

2、在测试过程中养成合理提高测试效率的工作方式，比如：不同的模块在不同厂家的浏览器中做业务功能测试，这样尽量最大覆盖浏览器的兼容测试。因为假设业务功能测试用例1000条，逐个在N多种浏览器里做测试是一件很费劲而且公司也不会给予这么多时间去做一个优先级比较低的事情；

3、举一反三，多思考，如果你发现有一个兼容性的问题，要思考一下这个功能在其他页面有没有，是不是也存在这个问题，尽量做到不遗漏；

4、多跟开发沟通，这点跟第3点有共同之处；

分辨率

使用不同的分辨率设备检查页面显示的效果，这里的分辨率测试跟调整浏览器窗口大小无关，具体原因可以查阅分辨率的相关资料了解。

网速

现如今随着科技的发展，很多PC机都不使用网线改用Wifi，所以网络的不确定性也随之增加，可以使用Fiddler、Charles等软件做限速或者断网测试。

举一个例子，如果前端设置的超时时间或者Api设置的超时时间为5s，但是由于网速慢的原因造成页面提示当前网络环境不好，请稍候再试这样的提示，那么超时间就显得过短，可以提出建议进行修改。

数据兼容

由于某些原因数据库做了调整，那么调整之后是否会影响到已存在的数据，这些需要做数据兼容测试。

版本升级

假设公司决定对站定进行热升级，那么用户当前是阻断暂停使用还是可以继续使用，这些要依据公司版本升级策略进行测试。

性能测试

响应测试

用户打开一个页面或者执行了操作请求了一个接口，从动作开始到服务器响应回浏览器的时间我们称之为响应时间，业内有个2/5/8原则，2代表2s内响应完成用户能接受、5代表5s内响应完成用户勉强接受，8超过5s或者超过8s响应完成用户很难接受。

所以响应测试指的是测试一个请求开始到响应结束的时间，应当注意那些数据量较大的页面或者接口有些测试，同时也要注意高频使用页面和接口，重点对这两类做测试，再测试资源充裕的情况下，当然是进行全量页面和接口测试。

负载测试

服务器达到同一时刻一定数量级用户访问时的处理请求能力的测试称为负载测试，我们假设一台服务器可以同时处理1000个用户访问，我们模拟1000个用户访问，检查服务器能否正常处理业务请求，比如网页能否正常打开，接口能否正常响应，如果一切整成即测试通过，反之就需要交给开发进行优化。

实际中的负载情况需要考虑很多因素，比如我们需要固定设备硬件运算能力、还有固定网速、也分复杂查询和简单查询，这个负载能力既要参考业内标准也需要测试和开发共同讨论确定一个合理的预期负载情况。

压力测试

压力测试是指验证当服务器遭遇过量用户访问时自我处理故障且恢复的能力或者限制此种场景的能力，防止遭受正规和非正规访问时导致服务器瘫痪，例如DOS攻击，黑客操纵成千上万的木马机进行大规模访问，导致站点无法正常打开，后台服务器瘫痪，或者利用工具模拟大批量用户同一时刻访问，服务器是否具有甄别和限制访问的策略等等。

安全测试

1、敏感数据

类似于手机号、身份证号等私密信息是否加敏显示，接口中是否加密等等

2、SQL注入

SQL注入攻击的基本原理是通过构建特殊的输入参数，迫使后台数据库执行额外的SQL语句，从而达到获取数据库数据的目的。

3、横向越权

不同用户之间session共享，可以非法操作对方的数据

4、纵向越权

很多应用简单的通过前端判断，或者低权限角色看不到对应的菜单，但并未在后台去做当前登录用户是否有权限

5、XSS测试

跨站脚本攻击(Cross Site Scripting)：恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的

这种场景比较常见，比如服务端恶意植入js脚本、公用wifi拦截植入恶意脚本等

6、CSRF

CSRF（Cross-site requestforgery），中文名称：跨站请求伪造。用户C在为退出A的情况下，浏览B，B使用C的session非法访问A。

7、目录遍历

在web应用中，如下图所示的显示目录文件列表，会带来一定的安全隐患（服务器文件列表）

8、CRLF

CRLF就是HTTP响应头拆分漏洞。是对用户输入的CR 和LF字符没有进行严格的过滤导致的。