软件测试入门，很多朋友一开始就把精力扑在测试理论、用例设计、缺陷管理工具上，结果一进项目组就懵了：开发扔过来一个页面让你提bug，你打开源码一看，满屏的尖括号标签，根本分不清哪块对应页面上的哪个位置。报bug的时候只能描述"页面上那个输入框好像有问题"，开发反问一句"哪个输入框，name是什么？"你就答不上来了。
这就是我在带实训营时反复强调的一个观点：软件测试人员可以不写页面，但必须能看懂页面的"骨架"。HTML就是网页的骨架，是测试人员定位问题、描述缺陷、后续学习自动化测试（尤其是Selenium、Playwright的定位器）的基础。这篇Day4的内容，就是把测试人员真正用得上的HTML知识点过一遍，重点放在常用标签和表单上，不讲那些测试中用不到的冷门玩法，全部围绕"测试视角"来拆解。
1. 为什么测试人员要先学HTML：不是让你写网页，而是让你能"看病"
先纠正一个常见的思维误区。很多零基础的朋友一听要学HTML，第一反应是"我又不当开发，学这个干嘛？"或者"我是不是得先学会写一个漂亮网页才能做测试？"都不用。测试人员学HTML，目标只有一个：看懂页面结构，能精准定位问题，能和开发在同一套语言体系里沟通。
1.1 测试人员读HTML的三种核心场景
你在实际测试工作中，读HTML基本逃不出下面三个场景，我一个个说清楚。
第一个场景是提bug时要说清楚"问题出在哪"。比如你测一个注册页面，发现点击提交按钮后邮箱格式校验没生效。如果你只会说"页面上那个填邮箱的框有问题"，开发大概率要自己找半天。但如果你能说出"邮箱输入框对应的input标签的type属性是text，不是email，所以浏览器内置的格式校验没有触发"，开发立刻就能定位问题，对你的信任感也会完全不一样。这就是专业度的体现。
第二个场景是用手工测试补充自动化测试的定位信息。做UI自动化时，不管用Selenium还是Playwright，都需要通过元素的id、name、class或者XPath来定位页面元素。如果你连HTML标签的基本结构都不认识，写自动化脚本就是空中楼阁。我在Day6讲元素定位时会大量复用今天的内容，所以今天的基础打不牢，后面会很吃力。
第三个场景是快速判断前端缺陷是"结构问题"还是"样式问题"。比如页面上的按钮错位了，你用开发者工具看一下，如果是标签嵌套错了，那就是HTML结构问题；如果是class对应的CSS样式没生效，那就是样式问题。定位到根因再提交，开发处理起来效率翻倍，测试和开发的关系也会和谐很多。
1.2 测试人员学HTML应该把握的深度
这个话题很关键，因为很多朋友容易走极端：要么觉得HTML不重要，要么一头扎进去研究HTML5的新特性、Canvas动画，这都属于用力过猛。测试人员对HTML的掌握程度，我的建议是掌握到下面这个标准就行：
- 看到一段HTML代码，能说清楚页面上会呈现出什么效果；
- 看到页面上的一个元素，能在开发者工具里快速找到它对应的HTML源码；
- 知道常见的表单元素有哪些类型，每种类型的校验规则和输入限制是什么；
- 理解标签的嵌套关系，能判断结构错误大概会导致什么表现；
- 不需要能手写一个漂亮的网页，也不需要记住所有HTML标签。
按这个标准，你花半天时间把常用标签过一遍，完全够用。今天这篇我就按这个标准来带你速通。
2. HTML文档结构：测试人员看页面最先该看的部分
很多零基础的朋友刚接触HTML时，最容易犯的毛病是急着去记各种标签，结果看到一段完整的HTML代码反而懵了。其实你应该先掌握HTML文档的整体骨架——就像看病要先看人的整体状态，而不是一上来就盯着某个器官。
2.1 最小HTML文档里每个部分的职责
先看一段最基础的HTML文档结构，这是任何网页的"地基"：
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>用户注册页面</title> </head> <body> <h1>欢迎注册</h1> <p>请填写以下信息完成注册。</p> </body> </html>从测试的角度，这几部分的信息量其实很大。先说<!DOCTYPE html>，它的作用是告诉浏览器"当前页面采用的是HTML5标准"。测试中如果你发现同一个页面在不同浏览器里表现不一样，首先要看的就包括DOCTYPE有没有写对。缺失或写错DOCTYPE会导致浏览器进入"怪异模式"，盒模型计算方式都变了，表现就可能出现差异。这类bug在旧系统改造项目中特别常见。
再看<html>标签，它是整个文档的根元素，所有其他标签都要放在它里面。lang="zh-CN"声明页面内容主要是中文，这个属性平时不太起眼，但对无障碍测试和部分浏览器翻译功能有影响。
然后是<head>区域，这里的内容不会显示在页面主体上，但对测试来说有两个点值得关注。一个是<meta charset="UTF-8">，声明字符编码。我在实际项目中遇到过好几次乱码bug，最后根因都是charset没有声明或者声明的编码和服务器返回的实际编码不一致。你测试一个中文页面时，如果发现页面出现乱码，优先检查这个标签。另一个是<title>标签，很多测试新人会忽略它——页面标题看起来是小事，但浏览器标签页上显示什么、搜索引擎收录时显示什么、自动化测试断言页面标题时是什么，统统依赖这个标签。我写过不少用例里的第一步就是"断言页面标题是否包含预期关键词"，那时还不熟悉HTML，直到后来才明白title为什么重要。
2.2 用开发者工具把HTML"翻译"成界面
对于测试人员来说，看HTML文档结构还有一种更直观的方式：直接在浏览器里按F12打开开发者工具，切到Elements（元素）面板。你在页面上看到的任何文字、图片、按钮、输入框，在Elements里都能找到对应的HTML代码。鼠标悬停在代码上时，页面上对应的区域还会高亮显示——这个联动功能是测试定位元素最常用的手段，没有之一。
我建议你今天就把这个"翻译"过程练熟：打开任意一个你常访问的网站，按F12，先看<head>里有什么，再看<body>里有什么，把页面上的标题、段落、按钮、图片、输入框，一个个在Elements里找到对应位置。练完几个网站，你对HTML结构的陌生感就会消除大半。
2.3 body区域里的块级元素与行内元素
在body区域里，几乎你能看到的所有可见内容，都可以归到两类元素中：块级元素和行内元素。这个分类不是考试知识点，它直接影响测试中的布局判断。
块级元素的特点是：独占一行，默认宽度占满父容器，从上到下排列。常见的块级元素有<div>、<p>、<h1>~<h6>、<ul>、<li>、<form>、<table>等。行内元素的特点是：不独占一行，多个行内元素可以在同一行展示，宽度由内容决定。常见的行内元素有<span>、<a>、<img>、<input>、<label>、<strong>、<em>等。
测试中的实际意义在哪里？举个例子，你发现页面上两个按钮"注册"和"登录"不在预期的一行，而是被挤到两行去了。用开发者工具一看，如果其中一个按钮被包在了<div>里，另一个被包在<span>里，那布局异常的原因很可能就找到了——因为<div>是块级元素，它会强迫后面的内容换行。你不需要会修改它，但你能定位到问题属于结构层级，这就是测试人员学HTML的价值。
3. 常用标签速通：测试工作中最高频见到的那批
现在进入实践部分。HTML标签有上百个，但测试人员在日常工作中真正高频遇到的，其实不超过二十个。下面我按测试场景来分组讲解，每组都带具体的测试关注点，这样你学了马上能用到。
3.1 文本标签组：h1~h6、p、span、strong、em、br、hr
文本是页面内容的主体，测试中最常见的文本相关缺陷包括标题层级错误、内容漏显示、换行错乱、关键词没有正确强调等等。常见的文本标签有这么几类：
<h1>到<h6>是六级标题，从大到小。<h1>一个页面通常建议只有一个，对应页面的主标题；<h2>到<h6>依次用于子标题。测试时要注意标题的文字大小是否清晰可见、层级是否符合逻辑。还有个容易被忽略的点：自动化测试里断言页面内容时，经常用标题标签的文本作为定位依据，尤其是xpath=//h1[contains(text(),'注册')]这类写法，所以标题标签的文本内容是测试断言的关键抓手。
<p>是段落标签，用于承载一段独立的文字内容。<span>是行内容器标签，本身没有任何默认样式，经常用于给一段文字中的某个词做特殊标记。<strong>表示重要文字，默认加粗显示；<em>表示强调文字，默认斜体显示。这里要注意，<strong>和<em>是语义化标签，它们的存在本身就说明这些文字需要强调——测试时要关注强调效果是否在页面上正确体现了。
<br>是换行标签（单标签，不需要闭合），<hr>是水平分割线标签（也是单标签）。这两个标签本身内容很简单，但在测试中经常因为数量错误导致页面布局异常。我见过一个项目，一段地址信息用了十几个<br>来强行占位，结果在不同分辨率的屏幕上显示效果完全错乱。所以测试文本类页面时，看到大量<br>或<hr>要留个心眼。
3.2 链接标签a：href、target、title里的测试门道
<a>标签是超链接，测试中的出现频率极高。它最核心的属性是href，表示链接指向的地址。测试链接时有一个容易踩的坑：href会写javascript:void(0);或者#，表示点击不跳转、只执行js行为。如果你测一个按钮看起来像链接，点击后页面没有任何反应，先看看href是不是这两种占位写法——这往往不是bug，而是链接本来就承载了js事件。反过来，如果一个链接的href指向的地址是空的或写错了，点击后会出现404或空白页，这才是真正的链接缺陷。
target属性控制链接的打开方式。target="_blank"表示在新标签页中打开，target="_self"表示在当前页打开。测试中要核实：需要新开页面的链接是否真的新开了标签页，不需要新开的是否在当前页跳转了。这个细节看起来不起眼，但恰恰是测试用例里经常覆盖到的功能点。
title属性是链接的悬停提示文字。鼠标悬停在链接上时会出现一个小气泡提示，如果产品需求里写了要支持这个提示，那么测试时就不要漏掉悬停这个动作。另外<a>标签里的文字内容就是链接在页面上展示的文本，自动化测试中直接用link_text来点击链接，也是最高效的定位方法。
3.3 图片标签img：src、alt、width/height那些事
<img>是图片标签，单标签，不需要闭合。它的几个属性在测试中几乎每天都会遇到。src指定图片的地址，地址写错或资源不存在时，页面上会显示一个破损的图片图标。这时你要区分是html里src引用就写错了，还是服务器上的图片文件确实丢失了——用开发者工具看请求状态就能判断，404就是文件不存在。
alt是图片加载失败时显示的替代文本，也对无障碍访问很重要。用屏幕阅读器的用户会通过alt文本来感知图片内容。如果图片加载失败时页面显示的是"图片"两个字而不是一段有意义的内容，说明alt属性没设置到位的可能性很大。
width和height控制图片的显示尺寸。测试时关注两点：一是图片是否因缺少宽高属性导致加载时页面抖动；二是设置了宽高后，图片是否被拉伸或压缩变形。我遇到过设计给的图片是方形的，开发忘记加object-fit: cover样式，结果变成椭圆形，这类视觉缺陷很容易被测试忽略，实际上通过检查图片标签的宽高属性和实际显示效果能快速定位。
3.4 列表标签：ul、ol、li的层级与序号的坑
列表在页面中大量用于菜单、选项、步骤、新闻列表等场景。<ul>是无序列表，默认用圆点作为列表项标记；<ol>是有序列表，默认用数字编号；<li>是列表项，必须放在<ul>或<ol>内。测试时列表相关的关注点包括：列表项是否完整展示、有序列表的序号是否正确递增、嵌套列表的层级关系是否清晰、以及列表项目过多时是否出现滚动或分页。
这里有一个常见的列表嵌套坑：很多测试新人看到页面上某个菜单分组显示不正常，不知道该怎么描述。如果你能看出来它是嵌套在<ul>里的<li>层级错乱导致的，或者在开发者工具里看到某个<li>没有正确闭合，导致后面的内容被包进了列表项里，这类问题就能精准地上报给开发。列表标签是理解页面结构的好样本，建议你在F12里多找几个列表看看它的嵌套层级。
3.5 无语义容器：div与span，测试中的"万能盒子"
<div>和<span>是没有任何语义的容器标签，纯用于布局和样式挂钩。<div>是块级容器，<span>是行内容器。它们在测试中之所以重要，是因为绝大多数自动化的定位器都依赖这两个标签的class或id属性。
比如你写自动化脚本，想定位"登录按钮"，在HTML里看到的是<button id="loginBtn" class="btn-primary">登录</button>，那你就可以用id=loginBtn或class=btn-primary或xpath=//button[text()='登录']三种方式来定位它。选择哪种方式取决于页面元素的稳定程度和唯一性。这就是为什么我在讲定位器之前，先要求你搞懂div/span和它们的属性——没有这个基础，后面全是空中楼阁。
同时，div和span也是"页面结构混乱重灾区"。如果一个页面嵌套了很多层div，层级过深，开发在维护时很容易出现样式错乱或选择器失效的问题。你测试时发现界面在某些操作后布局异常，先看是不是容器标签的嵌套或class切换出了问题。
4. 表单元素全解：测试人员的"主战场"
不少软件系统里，核心功能就是各类表单：注册、登录、下单、填写资料、提交工单……表单的测试几乎覆盖了功能测试、兼容性测试、安全性测试、易用性测试的方方面面。可以说，读不懂表单，就做不好功能测试。这部分我会掰开揉碎讲清楚，因为它实在太重要了。
4.1 form标签的三要素：action、method、name
<form>标签是表单的容器，它本身在页面上看不到任何视觉效果，但它的三个关键属性直接决定了表单提交的行为。action属性指定表单数据提交到哪个地址。测试时需要关注：是否提交到了正确的后端接口，如果action为空或写错，点提交按钮后可能页面刷新了但数据根本没发出去。
method属性指定提交方式，get或post。get方式数据会拼接到URL上，肉眼可见，有长度限制，适合不敏感的数据提交；post方式数据放在请求体中，相对安全，适合敏感或大量数据的提交。测试时要特别关注：登录表单、支付表单这类敏感场景绝不能使用get提交，否则用户名和密码会明文出现在浏览器地址栏里，这是严重的安全问题。我早年测试过一个小系统，登录后地址栏里明晃晃地挂着密码，当场就提了高优bug。
name属性是表单控件的名称。这个属性在自动化测试中极其重要，尤其是input输入框和select下拉框，提交到后台时，后台就是靠name来获取数据值的。你去看开发者工具，任何一个输入框没有name属性，或者name值拼写有误，提交的数据里就少了这个字段。测试时可以在开发者工具里模拟提交并查看请求参数，核对每个字段的name和值是否完整。
4.2 input标签全类型：text、password、email、radio、checkbox、file、hidden、number、date
input是表单里最核心的标签，type属性决定它的类型和表现。我一个一个过一遍，重点放在测试关注点。
type="text"是单行文本框，用于输入文本内容。测试关注最大长度限制、特殊字符（比如单引号、尖括号、emoji）是否被正确处理、输入内容是否被正确编码。这里要对单引号和尖括号格外敏感，它们是SQL注入和XSS攻击的主要载体。type="password"是密码框，输入内容以圆点或星号遮盖。测试要确认遮盖生效、密码不存储在cookie或URL中、是否在页面源码中被明文暴露。
type="email"是邮箱输入框。现代浏览器对email类型有内置的格式校验：输入内容不含@就不让通过，点击提交时会弹提示。测试时要验证：合法邮箱格式能通过、非法格式被拦截、如果页面同时写了自定义校验规则，两者的校验顺序和提示是否冲突。type="radio"是单选框，必须配合name使用——同一组单选框的name必须相同，才能实现互斥选择。测试时点击一个选项，另一个应该自动取消选中，同一组内name不一致会导致多选，这是radio最常见的bug。
type="checkbox"是复选框，可以多选，适合"爱好""选项"类场景。测试关注选中与取消是否正常、默认选中状态是否符合需求。type="file"是文件上传框。测试关注：文件类型、大小限制是否生效；能否上传重名文件；上传过程中的进度提示；取消上传是否正常。文件类型限制在代码里改配置就能绕过，所以还需要在测试用例里覆盖"改了后缀名的违规文件"是否能被拦截。
type="hidden"是隐藏域。它不在页面上显示，但会随表单一起提交。测试时用开发者工具才能看到它的值。业务中常用于传递用户id、token、来源标识等不可见数据。测隐藏域要留意值是否被篡改——有些系统把金额或权限信息放在隐藏域中，这是严重的安全漏洞，应当放在服务器端校验，而不是依赖前端的隐藏域。
type="number"是数字输入框，只允许输入数字。测试注意：部分浏览器允许你输入e、+、-等符号，导致边界值场景难以控制；输入超大的数或超小的数时的溢出表现；步进按钮（上下箭头）的递增递减是否按设定的step。type="date"是日期选择器。测试关注日期格式、默认值、选择范围限制（比如不能选过去日期或未来日期）、不同浏览器下的日期控件形态差异。
4.3 select、textarea、label、button的使用场景
<select>是下拉选择框，内部包含<option>选项。测试关注：默认选中的是哪个选项、选项内容是否完整、下拉框是否支持多选（multiple属性）、选项过多时是否支持搜索（部分框架实现）。自动化测试时，用Select类定位器处理下拉框是高频操作。<option>的value属性是提交到后台的值，<option>的文本是页面上显示的值，两者经常不一致，测试时要在请求参数里核验提交的是value而不是文本。
<textarea>是多行文本输入框，适合留言、简介、备注等场景。测试关注：最大字符数限制是否生效、输入超长内容时是否能正常继续输入或提示、换行是否正确保存并回显、是否支持自动缩放。
<label>是标签元素，它通常与某个输入控件绑定。绑定方式有两种：一种是把控件嵌套在<label>内，另一种是用for属性指向控件的id。绑定的作用非常大：点击label对应的文字时，会触发绑定的输入控件获得焦点或选中状态。在测试无障碍和易用性时，验证小圆的单选框是否能通过点击文字来切换，就是一个典型用例。没绑定的label点击没反应，很多人觉得是"小问题"，但对用户来说体验影响很大，尤其是移动端小屏幕上，点文字没反应，点圆点又容易误触。
<button>是按钮，type属性有submit、reset、button三种。submit是提交按钮，默认在你的表单内，点击后触发表单提交；reset是重置按钮，点击后清空表单内容；button是普通按钮，不会主动触发提交，需要绑定js事件来执行逻辑。测试时我见过很多次"点击按钮页面刷新了，但数据没提交"的bug，有时候就是因为按钮type写成了submit或reset导致的。所以看到按钮，先看开发者工具里它的type到底是什么，再决定预期行为。
4.4 表单校验机制：浏览器内置vs自定义规则
测试表单校验是功能测试的高频内容。校验分两类：浏览器内置校验和自定义校验。内置校验是HTML5规范自带的，比如required（必填）、maxlength（最大长度）、pattern（正则表达式）、min/max（数值范围）、type="email"的格式校验。这些规则写在HTML标签属性里，浏览器会在表单提交时自动执行校验和提示，测试时只要在页面里触发提交按钮，就能看到浏览器弹出的气泡提示。
自定义校验则是通过JavaScript编码实现的，比如密码两次输入是否一致、验证码是否正确、用户名是否已被占用。这类校验的提示样式通常和浏览器内置气泡不一样。测试时要尤其注意两类校验的叠加效果：一个输入框既有required又有自定义校验，先触发内置校验还是先触发自定义校验，顺序是怎么样的，提示是否会被覆盖。这些细节都是用例设计的绝佳素材。我还建议大家在测试表单时，专门验证一种场景：用开发者工具临时删掉某个输入框的required属性，再点击提交。如果后端没有做相应校验，数据就能被成功提交，说明这道校验防线有隐患。当然这只建议在测试环境验证，别在生产环境乱来。
4.5 从测试视角看"空表单提交"和"异常值提交"
表单测试有一种很实用但经常被忽略的思路：空表单提交和异常值提交。空表单提交就是登录注册页面所有输入框都不填，直接点提交按钮，观察系统的反应。一个考虑周到的系统应该提示"请填写XX"，并且焦点定位到第一个未填的输入框。如果点击提交没有任何反应，或者刷新页面清空了已经填好的内容，这就是体验问题。
异常值提交包括：超长文本、负数、小数、特殊符号、中文、表情符号、极端的Unicode字符等。测试时可以逐个在输入框里塞入这些数据，点击提交，看系统如何响应。如果后端没有做长度限制，超长内容可能撑破页面布局或导致数据库报错；如果后端没有做类型校验，负数或小数可能被写入不该包含这些值的字段中。这类测试不需要会编程，只需要你会构造异常数据、能看懂提交结果，但这些恰恰是初入行的测试人员最应该练的基本功。
5. 用开发者工具实操：HTML不再只是"看"，而是能"动手验"
前面讲了很多HTML的理论和测试关注点，但最终你要落到一个工具上：浏览器开发者工具。这是测试人员看HTML的"显微镜"，不熟练地用它，前面学的都是纸上谈兵。今天我带你过一遍测试中最常用的几个实操方法。
5.1 在Elements面板里快速定位页面元素：Ctrl+Shift+C的妙用
打开开发者工具后，在Elements面板附近有个"箭头"图标（或者直接按Ctrl+Shift+C）。点击它之后，鼠标挪到页面上任意一个元素上，对应HTML源码会自动高亮到这里。这个功能叫"检查元素"，是测试工作中使用频率最高的功能，没有之一。
用法示例：你看到一个输入框，想确认它的类型、id、name，按Ctrl+Shift+C点它，右侧就能看到对应的input标签信息。想确认某个按钮是用button还是a标签实现的，点一下马上见分晓。想确认报错文案是不是写死在HTML里而不是通过js动态渲染的，也能看到。开发问"你确定这个按钮是a标签吗"，你截图甩过去就行，不用争辩。
5.2 直接在面板里"临时改"HTML来验证判断
Elements面板不仅可以看，还可以直接编辑HTML。双击某个标签的属性或内容，就能修改。这个功能在测试中极其好用。
举个例子：你怀疑某个输入框的type写错了，导致原本应该是数字输入框却可以输入文字。你直接在面板里把type="text"改成type="number"，刷新后看看数字输入框的行为是否会恢复。这种"改了验证再改回来"的操作，能帮你快速确认bug的根因，因为你的修改只是临时改了浏览器端HTML，不影响服务器上的代码，刷新后也不会保存。
再举一个例子：你想验证某个字段的校验是否完全依赖前端required属性。你把required临时删掉，点提交按钮，如果数据直接提交成功了，说明后端的校验不完整，这是一个值得上报的缺陷。这类验证方式，在你写测试用例、和开发沟通缺陷复现路径时，能帮上大忙。
5.3 通过Console和Network面板验证表单提交数据
表单提交相关的bug，有时光看界面表现还不够，还得看数据到底发出去了什么。切到Network面板，勾选Preserve log（保留日志），然后触发一次表单提交，找到刚才那条提交请求，在Payload或Request中就能看到提交的参数列表。这正好对应前面反复强调的：表单字段提交时，有没有带上正确的name，值是否正确。有些系统前端把字段名改了但后端没有同步改，导致提交后接口报错或字段丢失，你在界面端不一定能看出来，但看请求参数就能秒懂。
另外，如果遇到页面报错但界面没什么提示，可以在Console面板看有没有红色的JavaScript报错。有些前端错误虽然不影响界面显示，但会影响后续交互，把Console里的报错截图发给开发，开发大概率能很快定位问题。这个习惯越早养成越好。
5.4 认识"渲染后的HTML"和"源码HTML"的区别是测试的一堂必修课
最后我想提醒一句：你在开发者工具Elements里看到的HTML，是浏览器渲染之后的最终DOM结构，可能和服务器最初返回的HTML源码不一样。因为现代前端框架（Vue、React等）会在运行时动态生成和修改DOM，你在Elements里看到的往往是渲染结果，而不是最初的模板代码。
这个区别在测试时的意义是：如果你要判断"页面上某个元素是否存在"，要以渲染后的DOM为准；如果你要判断"服务器端返回的源码里有没有某个敏感字段"，要看Response里的原始HTML或接口返回，而不是Elements面板。比如我们之前讲的隐藏域安全问题，如果你的敏感数据是在模板源码里就在，还是js渲染后才出现，严重程度是不同的。这个认知需要你在实践中慢慢体会，但方向先立起来，后面遇到具体问题就不会迷惑。
6. 测试视角的HTML常见缺陷库：看一眼就能报bug的那种
前几节讲的是知识，这一节以实际缺陷案例为主。这些案例是我多年测试工作中总结出来的高频问题，按出现频率和隐蔽性排序，适合你对照自查。
6.1 高频缺陷清单：6个必查项
如果你刚接触HTML相关测试，建议把这6个必查项写进自己的用例模板里，每次测页面都过一遍。
第一个是字符集缺失导致的乱码。中文页面没写<meta charset="UTF-8">，或者写法错误，页面上的中文全部变成"鈥斺€?"这类乱码。测试时看到任何乱码，第一反应检查charset。
第二个是图片加载失败后的alt文本缺失。页面上多个图片，其中一个挂了，如果alt为空，用户看到的就是一个空白框或者破损图标，体验很差。测所有图片时都顺手验证一下：断网或改错src，看页面上会不会给出有意义的替代文字。
第三个是隐藏域里放了敏感数据。前面反复强调，用开发者工具搜索页面源码或请求参数，看看有没有把id、金额、权限字段写在hidden里。这不是普通的功能问题，而是数据安全问题。
第四个是表单的label没有绑定输入控件。最常见的表现是页面上有个单选框，后面的文字点了没反应。通过for属性和控件id的匹配关系来判断，非常快速。
第五个是按钮的type属性和预期行为不一致。点了提交结果页面刷新了，或者数据没提交成功，先看按钮是不是type="submit"，再想其他可能性。
第六个是链接使用javascript:void(0);或#作为href，却没有任何js事件绑定。点击后按钮毫无反应，用户以为页面卡死了。测这类链接时，得看有没有绑定事件。如果确认没绑，这也是个体验bug。
6.2 从HTML层面识别部分"前端安全风险"（合规内容）
作为测试人员，在测试HTML时需要注意一些与安全相关的风险点。这些风险点不涉及任何敏感内容，只属于常规的Web应用安全测试范畴。
第一类是输入框未做输入长度和特殊字符限制。如果一个输入框的maxlength没有设置，或者后端没有校验长度，用户可以提交超长内容。实际上在测试中，超长内容可能导致页面布局错乱、数据库字段溢出、甚至接口报错。建议对所有输入框都测一下超长内容提交、特殊字符提交。特殊字符比如单引号'、尖括号<>、反引号`、双引号"等，在提交时应被正确转义或拦截。如果你提交的内容在页面上被原样渲染了，说明前端防XSS的措施可能缺失，这类问题要及时上报。
第二类是加密传输缺失的隐患。对于涉及密码、手机号、身份证号等敏感信息的表单，通过开发者工具Network面板查看提交请求时，如果数据是以明文形式传输（尤其是非HTTPS环境下），需要关注是否应用了加密措施。例如密码字段是否在提交前做了加密处理。若完全没有加密，敏感信息一旦在网络传输中被截获，会直接泄露用户隐私。
第三类是验证码和防重复提交机制。表单提交中，如果没有验证码、或者未对重复点击提交按钮做防重复限制，用户可能多次提交重复订单、重复注册等。测试时双击提交按钮，观察是否会生成多条记录，这是一个常见的测试点。
第四类是文件上传的格式限制只在前端做校验。如果文件上传框只在前端限制了图片类型，后端没有做格式校验，攻击者可以伪造Content-Type或改后缀名上传恶意文件。测试时尝试将.txt改成.jpg后缀上传，如果后端校验到位，会被拒绝；如果通过了，说明存在风险。这类测试在入门阶段可能不太容易理解，但建议在测试环境中逐步尝试。
这些内容都属于常规的Web安全测试范畴，不涉及任何敏感话题，你完全可以放心地在工作中实践。
6.3 聊聊HTML和CSS、JavaScript的"三角色配合"
HTML是骨架，CSS是皮肤，JavaScript是肌肉和大脑。测试人员理解这三者怎么配合很重要，因为一个bug可能出在任何一个环节。
举几个例子帮你建立这个认知。如果页面上文字重叠、排版混乱，那大概率是CSS问题；如果点击按钮后没有反应、弹窗没出现，那大概率是JavaScript问题；如果页面内容缺失、链接跳转地址错了，那大概率是HTML问题。实际情况下可能更复杂——结构、样式、行为相互影响，但你先从这个大方向上判断，能省很多排查时间。
测试人员在定位问题时，可以先在Elements面板里看HTML结构是否正确，再看Styles面板里看CSS样式是否生效，最后在Console面板里看JS是否有报错。按这个顺序排查，思路会清晰很多，也不会像无头苍蝇一样乱试一通。
7. 给测试新人的最后建议：HTML速通后的下一步方向
今天的内容如果你能全部消化，并且跟着在开发者工具里实操一遍，你已经有能力看懂绝大部分网页的HTML结构、表单元素和常见缺陷了。对于软件测试入门来说，这个阶段的目标已经达成。在设计下一步学习路径前，给你三个方向参考。
第一个值得优先做的是把表单校验的测试用例设计能力练扎实。表单是软件测试中出现频率最高的业务模块，掌握了表单就等于掌握了一类产品的通用测试思路。每次拿到一个注册页/登录页/资料填写页，都可以按必填项、格式校验、边界值、重复提交、异常数据、前后端校验一致性等维度来写用例。这套思路和你今天学到的HTML表单知识完全契合，可以马上用在平时的工作或练习中。
第二个方向是学习用XPath和CSS选择器定位页面元素。做UI自动化测试时，90%的功夫都花在元素定位上。你今天已经知道id、name、class这些属性的作用，学XPath会轻松很多。到时候看到//input[@name='username']这种表达式，你就能立刻反应出来"它是在找那个name属性等于username的输入框"。这就是今天这节课为后续铺的路。
第三个方向是理解一门编程语言。软件测试做到中后期，完全不懂编程会非常受限。不一定要成为开发那样的大神，但Python或Java的基础语法、简单的接口测试脚本、自动化测试框架的使用，是需要逐步掌握的。今天的HTML是纯静态标记语言，不涉及编程逻辑，是零基础转测试最好的切入口，你会觉得难度不大、容易建立信心。
最后想和大家强调一下学习方法。HTML的内容看起来多，但真的不需要你把每一个标签都背下来。测试人员最重要的是"看得懂、查得到、用得上"——遇到不认识的标签，用开发者工具看一下它渲染出来的效果，再查一下它的含义和常用属性，基本就能掌握。我在实际工作中带过不少零基础的实训生，他们最大的学习障碍往往不是知识点难，而是"觉得一定要背熟才能开始用"。千万别这么想，一边用一边学，效果远好于死记硬背。你今天跟着文章操作的每个步骤，就是在用最短的时间把HTML从"陌生的符号"变成"顺手的工具"，这条路我已经带着很多人走通过了，你也可以。
