1. 项目概述：为什么我们需要一份“最全”的Web测试清单？

干了十几年测试，从功能点点点做到自动化，再到带团队，我经手的Web项目少说也有上百个。每次新项目启动，或者带新人，最头疼的就是怎么确保测试覆盖得“全”。新人容易漏测，老手也可能因为思维定势忽略某些场景。网上资料倒是不少，但要么太零散，要么就是几年前的老黄历，跟不上现在前端框架满天飞、后端微服务遍地走的节奏。所以，我一直想整理一份能真正拿来即用、覆盖现代Web应用各个测试点的“作战地图”。

这份清单的目标很明确：它不是教科书，而是一份实战手册。无论你是刚入行的测试新人，想系统了解Web测试到底要测些什么；还是有一定经验的工程师，需要在项目复盘或测试方案设计时查漏补缺；甚至是开发同学，想在自测阶段做得更到位，这份清单都能提供一个清晰的框架。它围绕“质量”这个核心，从用户可见的界面，到深藏不露的服务端逻辑和基础设施，层层拆解，告诉你每个环节可能存在的“坑”以及该怎么去“探坑”。有了它，你至少能保证测试的大方向不会跑偏，关键风险点不会被遗漏。

2. Web测试全景图：从用户点击到数据落地的完整质量防线

在深入各个测试点之前，我们得先建立起一个整体的认知模型。一次普通的用户操作，比如在电商网站点击“加入购物车”，背后是一条漫长的技术链路。测试，就是为这条链路上的每一个环节设置检查点。

前端（客户端）：这是用户直接交互的部分，包括浏览器里运行的HTML、CSS、JavaScript代码，以及各种复杂的框架（React, Vue, Angular）。这里的测试关注的是表现层：页面长什么样，交互是否流畅，数据展示对不对。

网络传输：数据在前端和后端之间旅行，经过HTTP/HTTPS协议。这里的测试关注通信层：请求发得对不对，响应回得快不快，数据在路上是否安全。

后端（服务端）：接收请求、处理业务逻辑、读写数据库、调用其他服务。这是业务逻辑层和数据层的核心。测试关注接口行为是否正确、业务规则是否被遵守、数据处理是否准确高效。

基础设施：支撑应用运行的服务器、数据库、缓存、消息队列等。这是承载层。测试关注的是服务的稳定性、容量和在高压力下的表现。

安全：像一层保护罩，贯穿以上所有层面。测试关注是否存在漏洞，可能被恶意利用。

我们的测试清单，就是沿着这条链路，逐一设置检查项。下面，我们就从最贴近用户的前端开始。

2.1 前端功能测试：确保每一个交互都如你所愿

前端功能测试是验证Web应用能否正确完成其设计功能的过程。它不仅仅是“点按钮”，而是有策略地验证各种用户场景和输入组合。

核心测试点：

1. 链接测试：这是最基础也最容易出错的。需要测试：

   • 所有内部链接：是否指向正确的页面，并且没有死链（404错误）。
   • 外部链接：是否跳转到正确的第三方网站。
   • 锚点链接：页面内的快速跳转是否工作正常。
   • 邮件链接：mailto:链接是否能正确调起邮件客户端。
   • 下载链接：文件是否能被成功下载，并且文件类型和大小正确。

   实操心得：不要只用手点。对于大型站点，使用链接检查工具（如Xenu's Link Sleuth, Screaming Frog）进行批量扫描是必须的。同时，要特别注意动态生成的链接，比如通过AJAX加载的内容里的链接，这些在页面初始加载时可能检测不到。

2. 表单测试：Web应用的输入核心，坑最多。

   • 字段验证：测试必填项、格式限制（邮箱、电话、邮编）、长度限制、输入类型（数字、文本、日期）。不仅要输入正确的数据，更要系统性地输入错误数据：超长字符串、特殊字符、SQL注入片段、脚本片段等，看系统是给出友好的错误提示，还是直接崩溃或执行了危险操作。
   • 默认值：表单初始化时，下拉框、单选按钮等是否有合理的默认值。
   • 表单提交：提交后，数据是否被正确传递和处理？页面是跳转还是局部刷新？提交按钮在点击后是否有防重复提交的禁用状态？
   • 依赖字段：比如选择了某个省份后，城市下拉框的内容是否会动态更新。

3. 导航测试：用户能否在网站中自由、正确地穿梭。

   • 菜单、面包屑、页脚链接、Logo返回首页等所有导航方式都需要测试。
   • 浏览器前进/后退按钮：操作后页面状态是否正确恢复？对于单页面应用（SPA）尤其要注意，路由是否能正确响应。
   • 直接URL访问：能否通过输入具体的URL直接访问深层页面？是否需要登录等权限校验？

4. 数据展示测试：确保从后端获取的数据被正确地渲染到页面上。

   • 内容准确性：文本、数字、日期、货币格式是否正确。
   • 排序与分页：列表数据是否按指定规则（时间、价格、名称）排序？分页功能是否正常，总条数、每页条数是否正确？
   • 数据为空/异常：当查询结果为空时，是否显示友好的空状态提示，而不是一个空白区域或错误信息？当后端返回数据异常（如null值）时，前端是否有容错处理，不至于页面白屏？

2.2 用户界面(UI)与用户体验(UX)测试：用用户的眼光挑剔细节

这部分测试关注应用“看起来怎么样”和“用起来感觉如何”。它非常主观，但又至关重要。

核心测试点：

1. 视觉与布局测试：

   • 跨浏览器/跨设备兼容性：这是UI测试的重中之重。你的网站在Chrome、Firefox、Safari、Edge等主流浏览器的最新版本上，表现是否一致？在IE（如果仍需支持）上是否严重错乱？在不同操作系统（Windows, macOS）上呢？
   • 响应式设计：页面在台式机、笔记本、平板（如iPad）、手机（不同尺寸的iPhone和Android设备）上，布局是否能自适应调整？元素是否错位、重叠或变得不可点击？不要只依赖浏览器开发者工具的设备模拟器，真机测试必不可少，因为模拟器无法完全还原触摸行为、性能等细节。
   • 样式一致性：字体、颜色、按钮样式、间距等在整个应用中是否遵循统一的设计规范（或设计系统）。
   • 图片与多媒体：图片是否正常加载（包括加载失败时的占位图）？alt属性是否正确？视频能否播放，控制条是否正常？

2. 内容测试：

   • 拼写与语法：所有用户可见的文本不应有拼写错误和明显的语法错误。
   • 内容准确性：确保文案内容符合产品需求和当前业务场景，没有过时或错误的信息。
   • 本地化/国际化：如果支持多语言，需要测试语言切换后，所有界面元素、日期、货币、数字格式是否都正确切换。特别注意文本长度变化导致的布局问题（例如，德语通常比英语长很多）。

3. 可用性测试：

   • 操作流暢度：用户完成一个关键任务（如注册、下单）需要几步？流程是否自然、符合直觉？
   • 反馈机制：用户操作后，系统是否有及时、清晰的反馈？例如，提交表单后显示“提交中...”，成功或失败后有明确的提示信息。
   • 可访问性：这是一个常被忽略但非常重要的领域。它确保残障人士（如视障、听障）也能使用你的网站。基础的可访问性测试包括：是否支持键盘完全操作？图片是否有有意义的alt文本？颜色对比度是否足够？是否使用了语义化的HTML标签（如用<button>而不是<div>模拟按钮）？虽然深度可访问性测试需要专业工具（如屏幕阅读器NVDA, JAWS），但关注这些基础点能大幅提升产品的包容性。

2.3 兼容性测试：让你的网站在“混沌”的环境中屹立不倒

用户的环境是五花八门的，兼容性测试就是确保你的应用在大多数主流环境下都能正常工作。

测试矩阵的搭建：你不需要测试所有可能的组合，那是不现实的。通常采用“风险驱动”的策略，优先覆盖用户量最大的组合。

• 浏览器：Chrome, Firefox, Safari, Edge的主流版本。根据产品用户统计数据确定优先级。
• 操作系统：Windows (10, 11), macOS (最新两个版本), 主流Linux发行版。
• 设备类型：台式机、笔记本电脑、平板、手机。
• 屏幕分辨率：常见分辨率如1920x1080, 1366x768, 1536x864, 以及移动端的各种尺寸。
• 其他：是否支持不同的语言环境、时区？

执行策略：

1. 核心功能全矩阵覆盖：对于登录、支付、核心业务流等关键功能，应在所有优先级较高的浏览器-设备组合上进行测试。
2. 非核心功能抽样测试：对于次要页面或功能，可以选择在1-2种最主要的组合（如Chrome on Windows, Safari on iPhone）上进行测试。
3. 利用云测试平台：对于需要覆盖大量设备但团队资源有限的情况，可以使用BrowserStack、Sauce Labs等云测试平台，它们提供了海量的真实设备和浏览器环境。

注意事项：兼容性问题不仅仅是“能不能打开”，更多表现为样式错乱、布局崩坏、交互失效（如点击无反应）、性能差异巨大。测试时，要像真正的用户一样去操作，而不仅仅是看一眼页面。

3. 性能测试：速度与稳定性的双重考验

性能不佳是导致用户流失的最主要原因之一。性能测试不仅仅是测“快不快”，更是测“稳不稳”。

3.1 前端性能测试：关乎用户的第一印象

前端性能直接影响用户的感知速度。核心指标包括：

• 首次内容绘制：页面从空白到出现第一个内容元素的时间。
• 最大内容绘制：页面中最大内容元素渲染完成的时间。
• 首次输入延迟：用户第一次与页面交互（点击、输入）到浏览器实际响应该交互的时间。

测试方法与工具：

1. 使用浏览器开发者工具：Chrome DevTools 中的Lighthouse和Performance面板是首选。Lighthouse 能提供一份全面的性能、可访问性、SEO等评估报告，并给出优化建议。Performance面板可以录制页面加载和交互过程，生成详细的时间线，让你精确找到性能瓶颈（是JavaScript执行太久，还是图片加载太慢）。
2. 模拟真实网络环境：在DevTools的Network面板中，可以模拟慢速3G、4G等网络条件，测试网速不佳时页面的表现。这对于移动端用户尤为重要。
3. WebPageTest 等在线工具：提供更丰富的测试场景，比如从全球不同地点测试你的网站速度，并提供视频录像和详细的水位图，直观展示加载过程。

优化检查点：

• 图片优化：是否使用了WebP等现代格式？是否设置了合适的尺寸（不要用2000px的大图显示在100px的区域内）？是否懒加载？
• 资源压缩：CSS、JavaScript文件是否进行了压缩和合并？是否开启了Gzip/Brotli压缩？
• 缓存策略：静态资源（图片、CSS、JS）是否设置了正确的HTTP缓存头，让浏览器能有效缓存？
• 第三方脚本：引入的第三方分析、广告、社交插件脚本是否拖慢了页面？能否异步或延迟加载？

3.2 后端性能（负载与压力）测试：支撑业务洪流的关键

当大量用户同时访问时，你的服务器、数据库和应用程序能否扛得住？这就是后端性能测试要回答的问题。

核心测试类型：

1. 负载测试：模拟在正常和预期的峰值负载下（比如促销期间的用户量），系统的性能表现。目标是验证系统能否处理预期的流量，并监控响应时间、吞吐量、错误率等指标是否在可接受范围内。
2. 压力测试：逐步增加负载，直到超过系统的承受能力，找到系统的性能瓶颈和极限点。比如，系统在每秒处理1000个请求时正常，那2000个呢？3000个呢？什么时候响应时间急剧上升或开始大量报错？
3. 稳定性/耐力测试：在一定的负载压力下（通常是正常负载的80%-120%），让系统持续运行较长的时间（如8小时、24小时）。目的是发现内存泄漏、资源逐渐耗尽（如数据库连接池）、性能随时间下降等问题。

测试工具与流程：

• 工具选择：JMeter, Gatling, Locust, k6 都是流行的选择。JMeter功能全面但资源消耗大；Gatling和k6基于Scala/Go，性能更好，脚本也更易维护。
• 关键步骤：
  1. 识别关键业务场景：如用户登录、商品搜索、下单支付。
  2. 录制或编写测试脚本：模拟用户在这些场景下的完整HTTP请求序列。
  3. 配置负载模型：定义虚拟用户数、 ramp-up（用户逐渐增加）时间、持续时间、思考时间等。
  4. 定义监控指标：明确要监控哪些指标，如：
     • 响应时间：平均响应时间、百分位数响应时间（如P95， P99， 表示95%/99%的请求响应时间低于此值）。
     • 吞吐量：每秒处理的请求数。
     • 错误率：失败请求的百分比。
     • 服务器资源：CPU、内存、磁盘I/O、网络I/O使用率。
  5. 执行与分析：运行测试，收集数据。分析性能瓶颈在哪里：是应用服务器CPU满了？是数据库查询慢？还是缓存命中率低？

实操心得：性能测试环境要尽可能贴近生产环境（硬件配置、网络拓扑、数据量级）。用完全不同的环境得到的测试结果几乎没有参考价值。另外，不要只关注平均值，P95、P99响应时间更能反映真实用户体验——少数慢请求会严重影响用户感受。

4. 安全测试：构筑应用防火墙

安全漏洞可能带来灾难性后果。安全测试旨在发现并修复这些漏洞。

常见漏洞与测试方法：

1. 注入漏洞：最危险的漏洞之一。

   • SQL注入：通过在输入字段中插入恶意的SQL代码，来操纵后端数据库。测试方法：在所有输入点尝试输入' OR '1'='1、'; DROP TABLE users; --等Payload，观察应用行为。
   • 命令注入：通过输入操纵系统命令。测试方法类似。
   • 防护：永远使用参数化查询或预编译语句，避免直接拼接SQL字符串；对输入进行严格的验证和过滤。

2. 跨站脚本：攻击者将恶意脚本注入到网页中，当其他用户浏览时，脚本会在其浏览器中执行，可能盗取Cookie、会话令牌或进行其他恶意操作。

   • 测试方法：在输入框、URL参数等处尝试输入<script>alert('XSS')</script>等脚本，看是否会被浏览器执行。
   • 防护：对用户输入进行输出编码，确保其被当作数据显示，而非代码执行。设置HTTP头的Content-Security-Policy是更强大的现代防御手段。

3. 跨站请求伪造：诱骗已登录的用户在不知情的情况下，向一个他们已认证的Web应用提交恶意请求。

   • 测试方法：检查关键操作（如修改密码、转账）的请求是否使用了CSRF Token等不可预测的令牌进行验证。
   • 防护：使用CSRF Token，并验证请求的Referer头或Origin头。

4. 敏感数据暴露：

   • 传输中：是否全程使用HTTPS？测试HTTP请求是否被强制跳转到HTTPS。
   • 存储中：密码等敏感信息是否明文存储？是否使用了强哈希算法（如bcrypt, Argon2）加盐存储？
   • 客户端：是否在客户端代码、本地存储中泄露了API密钥、数据库连接信息等？

5. 身份认证与授权漏洞：

   • 弱密码策略：系统是否允许设置“123456”这样的弱密码？
   • 暴力破解：登录接口是否有验证码、失败次数限制等防爆破机制？
   • 权限绕过：普通用户能否通过修改URL参数（如/user/123/profile改为/user/456/profile）访问他人数据？普通用户能否访问仅管理员可见的页面或调用其API？

测试工具辅助：

• 自动化扫描工具：如 OWASP ZAP, Burp Suite 的主动扫描功能，可以自动发现一些常见漏洞，是一个很好的起点。
• 手动渗透测试：自动化工具无法替代有经验的安全工程师进行深入的手动测试。他们能结合业务逻辑，发现更复杂的逻辑漏洞。

重要提示：安全测试务必在授权和隔离的环境中进行，切勿对生产系统或未经授权的系统进行测试，否则可能触犯法律。

5. 接口（API）测试：现代Web应用的骨架检验

如今，前后端分离是主流，前端通过调用API与后端交互。API的稳定性和正确性，直接决定了整个应用的功能。

测试层次：

1. 功能性测试：验证API是否按照接口文档（如Swagger/OpenAPI）的约定工作。
   • 正向用例：使用有效的参数调用，验证返回的状态码（如200 OK）、响应体数据结构、数据内容是否正确。
   • 反向用例：使用无效的参数（错误类型、超出范围、必填项为空）、错误的身份凭证等调用，验证API是否返回了预期的错误状态码（如400 Bad Request, 401 Unauthorized, 404 Not Found）和清晰的错误信息。
2. 数据验证测试：不仅检查状态码，更要深入检查返回数据的准确性。比如，创建订单的API返回后，要去数据库核对订单信息是否完全一致。
3. 边界值与异常测试：针对数字参数，测试最小值、最大值、边界外值；针对字符串，测试空字符串、超长字符串、特殊字符。
4. 性能测试：类似于后端性能测试，但专注于API端点。测试单个API的响应时间，以及在并发调用下的表现。
5. 安全测试：对API进行注入测试、越权测试（用普通用户的Token去访问管理员的API）、敏感信息泄露检查等。

工具与自动化：

• Postman/Insomnia：强大的API测试客户端，可以方便地构建请求、组织测试集合、编写测试脚本（使用JavaScript），并支持自动化运行。
• 自动化测试框架：在CI/CD流水线中集成API自动化测试。可以使用Pytest + Requests(Python),JUnit/TestNG + RestAssured(Java),Mocha/Chai + Supertest(Node.js) 等组合，将API测试用例代码化，实现持续验证。

6. 数据库测试：数据的最后守护者

所有业务操作最终都指向数据的增删改查。数据库测试确保数据操作的正确性、完整性和一致性。

核心测试点：

1. 数据完整性测试：
   • 约束验证：数据库定义的主键、外键、唯一约束、非空约束、检查约束是否生效？尝试插入违反这些约束的数据，看数据库是否会拒绝。
   • 级联操作：当删除或更新主表记录时，相关的从表记录是否按照设定的规则（级联删除、置空、禁止）正确操作？
2. 事务测试：测试需要原子性执行的一系列数据库操作。
   • 事务提交：一系列操作要么全部成功，数据被持久化。
   • 事务回滚：如果中间某一步失败，之前的所有操作是否都被撤销，数据库状态恢复到事务开始前？这对于金融、订单类业务至关重要。
3. 存储过程/函数测试：如果业务逻辑封装在数据库层的存储过程中，需要像测试代码一样测试它们，验证其输入输出和内部逻辑。
4. 性能测试：针对执行缓慢的SQL查询进行优化。使用EXPLAIN命令（在MySQL/PostgreSQL中）分析查询执行计划，查看是否使用了正确的索引，是否存在全表扫描等性能瓶颈。

测试策略：

• 使用测试数据库：绝对不要在开发或生产数据库上直接运行测试，必须使用独立的、结构相同的测试数据库。
• 数据准备与清理：每个测试用例开始前，通过脚本或工具（如DBUnit）将数据库置于一个已知的、干净的状态（插入测试所需数据）；测试结束后，清理测试数据，避免影响后续测试。这是保证测试独立性和可重复性的关键。

7. 探索性测试与回归测试：人类智慧的闪光点与质量基线守护

7.1 探索性测试：像用户一样思考，像黑客一样攻击

在完成所有计划内的测试用例后，探索性测试是发现那些“意料之外”的缺陷的利器。它强调测试人员同时设计测试和执行测试，在探索软件行为的过程中不断学习并调整测试思路。

如何进行：

• 设定一个任务或目标：例如，“作为一个新用户，完成从注册到购买第一件商品的全程”。
• 自由探索：在没有任何具体步骤指导的情况下，尝试去完成这个任务。在这个过程中，你可以：
  • 尝试非常规操作：快速连续点击提交按钮；在输入时频繁切换标签页再回来；使用浏览器的自动填充功能。
  • 组合异常条件：在网络缓慢的情况下，提交一个包含大量图片的表单。
  • 关注交互边界：在两个功能模块的衔接处进行操作。
• 记录发现：随时记录下任何奇怪的行为、错误信息、或者你认为可以改进的地方。

探索性测试高度依赖测试人员的经验、创造力和对产品的深度理解，往往能发现自动化测试和常规用例无法覆盖的、与用户体验和复杂交互相关的深层次问题。

7.2 回归测试：确保新的变化不会破坏旧的功能

每当应用发布新功能或修复了旧缺陷，都需要进行回归测试，以确保这些修改没有引入新的问题。

策略：

1. 构建回归测试用例集：从整个测试用例库中，挑选出最核心、最常用、最可能被影响的业务流程对应的用例，组成一个“回归测试包”。这个包应该能在合理的时间内（例如一个晚上）运行完毕。
2. 自动化是王道：对于回归测试，自动化是必须的。手动重复执行几百个核心用例是低效且容易出错的。将回归测试包自动化，并集成到CI/CD流水线中，每次代码提交后自动运行，能快速给出质量反馈。
3. 分级测试：
   • 冒烟测试：在每次构建后立即运行的一组最最核心的用例（通常5-10分钟跑完），用于快速判断本次构建是否“基本可用”。如果失败，就不必进行更耗时的测试。
   • 完整回归测试：在版本发布前，对回归测试包进行完整执行。

8. 测试环境的治理与持续集成

再好的测试，也需要在正确的环境中执行。混乱的测试环境是测试失效的主要原因之一。

测试环境管理要点：

• 环境一致性：尽可能让测试环境（包括操作系统、中间件版本、数据库版本、网络配置）与生产环境保持一致。容器化技术（如Docker）是解决环境一致性问题的利器。
• 数据管理：测试数据需要精心准备和维护。要有数据构造和清理的自动化脚本。对于性能测试，需要准备和生产环境量级、分布特征相似的仿真数据。
• 环境隔离：不同的测试活动（功能测试、性能测试、安全测试）应尽可能使用独立的环境，避免相互干扰。

持续集成中的测试： 现代软件开发中，测试不再是开发完成后才进行的阶段，而是贯穿始终的活动。在CI流水线中，可以分层嵌入自动化测试：

1. 代码提交触发：运行静态代码分析、单元测试。
2. 构建后：运行集成测试、API测试。
3. 部署到测试环境后：运行自动化冒烟测试、核心功能回归测试。
4. 定期/发布前：运行完整的回归测试套件、性能测试、安全扫描。

这种“测试左移”和持续反馈的机制，能将问题尽早暴露和修复，极大提升交付效率和质量信心。

9. 常见问题与排查技巧实录

在实际测试工作中，你会遇到各种各样的问题。这里记录了一些典型场景和我的排查思路。

问题1：前端页面上，一个按钮点击后偶尔无反应，如何排查？

• 排查步骤：
  1. 打开浏览器开发者工具，切换到Console面板，查看点击时是否有JavaScript错误抛出。
  2. 切换到Network面板，查看点击按钮后，是否发起了预期的网络请求（XHR/Fetch）。如果没有，可能是前端事件绑定有问题。
  3. 如果有请求发出，查看请求的状态码。如果是4xx（如401未授权，403禁止访问），可能是权限或token问题；如果是5xx，是服务端错误。
  4. 如果请求成功（状态码200），但页面没变化，检查响应内容是否正确，以及前端JavaScript代码是否正确处理了响应并更新了DOM。
  5. 使用Performance面板录制点击操作，查看是否有长时间阻塞主线程的JavaScript任务，导致页面“卡死”。
• 常见原因：JS报错、网络请求失败或超时、响应数据格式不符合前端预期、复杂的计算或渲染阻塞了交互。

问题2：性能测试中，发现某个API接口的P99响应时间异常高，如何定位瓶颈？

• 排查步骤：
  1. 从应用日志入手：查看该接口在处理慢请求时的日志，是否有异常（如慢SQL、外部服务调用超时）。
  2. 分析数据库：如果日志指向数据库，使用数据库的监控工具或慢查询日志，定位是哪个SQL语句慢。用EXPLAIN分析其执行计划。
  3. 检查应用服务器：监控服务器的CPU、内存、线程池状态。是否因为线程池耗尽，请求在排队？是否有内存泄漏导致频繁GC？
  4. 检查依赖服务：该API是否调用了其他微服务或第三方接口？使用分布式追踪工具（如SkyWalking, Jaeger）查看整个调用链，定位耗时最长的环节。
  5. 检查代码逻辑：是否存在低效的算法（如多层嵌套循环）？是否在循环中进行了不必要的数据库查询或远程调用（N+1查询问题）？
• 常见原因：未加索引的数据库查询、循环中的远程调用、锁竞争、资源（数据库连接、HTTP连接）耗尽、算法复杂度高。

问题3：在兼容性测试中，页面在IE11上布局混乱，但在Chrome上正常，如何高效调试？

• 排查步骤：
  1. 使用IE开发者工具：虽然简陋，但可以检查元素样式、查看控制台错误。
  2. 隔离问题：尝试简化页面，移除部分CSS和JS，定位是哪个文件或哪段代码导致的问题。
  3. 检查CSS特性支持：使用Can I use网站查询有问题的CSS属性（如Flexbox, Grid）在IE11中的支持情况。IE对现代CSS的支持很差。
  4. 检查JavaScript语法和API：IE11不支持ES6及以后的许多语法（如箭头函数、let/const、Promise）和Web API。确保你的代码已通过Babel等工具正确转译，并引入了必要的polyfill。
  5. 使用条件注释或特性检测：对于无法通过转译/polyfill解决的兼容性问题，可能需要为IE编写特定的CSS Hack或使用条件注释加载额外的补丁文件。
• 根本解决思路：如果项目不再需要支持IE等老旧浏览器，应在项目初期明确技术选型，并利用构建工具（如Webpack + Babel）和垫片库（如core-js）做好兼容性处理。对于仍需支持的项目，考虑提供“降级体验”或使用渐进增强的策略。

这份清单就像一张详尽的地图，它不能代替你走遍每一个角落，但能确保你在Web测试的复杂疆域里不会迷失方向。测试的本质是风险管理和质量保障，这份地图帮你系统地识别风险。真正的功力，在于你如何根据项目特点，灵活运用这些知识点，设计出高效的测试策略，并最终通过或自动化、或探索性的手段去执行它。测试之路，始于覆盖，精于思考，成于实践。