如何制定完美的测试用例标准模板元素？5个步骤让你的测试更高效

如何制定完美的测试用例标准模板元素？5个步骤让你的测试更高效

很多团队以为测试效率低，是因为测试人员写得不够快、用例数量不够多。我的实际观察恰恰相反：不少项目已经积累了几千条测试用例，回归测试仍然反复漏测，需求变更后也没人说得清哪些用例必须重跑。真正的问题通常不在“有没有模板”，而在模板是否让每条用例做到可执行、可判定、可追踪、可维护。制定测试用例标准模板时，最重要的不是把字段填满，而是让模板能够减少沟通成本，并帮助团队把有限的测试时间投向高风险场景。

一、先讲核心结论：好模板不是字段越多越专业

1. 一条合格用例必须回答四个问题

我评审测试用例时，不会先看它有多少列，而是先问四个问题：测试什么目标？执行前需要什么条件？具体怎么操作？什么现象可以判定为通过？如果一条用例不能清楚回答这四个问题，即使包含编号、版本、环境、备注等十几个字段，也只能算是一张信息表，不算真正可执行的测试资产。

例如，“验证用户登录功能”不是一个足够明确的用例标题，因为它没有说明登录场景和验证目标。更好的写法是“已注册用户使用正确账号密码登录成功”，或者“连续输入错误密码达到限制次数后账号被锁定”。后者能够直接指导测试人员准备数据、执行操作和判断结果。

2. 模板的核心字段可以分为三个层次

为了避免模板过度复杂，我通常把字段分成三层。第一层是执行必需字段，包括用例编号、用例标题、前置条件、测试数据、操作步骤和预期结果；第二层是管理字段，包括需求编号、模块、优先级、用例类型、版本和测试环境；第三层是追踪字段，包括实际结果、执行状态、缺陷编号、执行人和执行时间。

第一层决定“这条用例能不能被别人执行”，第二层决定“团队能不能排序和筛选”，第三层决定“测试结果能不能复盘”。如果团队刚开始规范化，不必一次性启用所有字段。先保证执行必需字段完整，再根据项目规模增加管理和追踪字段，通常比一开始设计一个极其复杂的模板更容易落地。

3. “完美模板”应该改成“适合当前风险的模板”

没有一套模板适用于所有软件项目。内部管理系统、支付系统、移动应用和嵌入式设备的测试重点不同，模板字段自然也应不同。比如支付系统更需要交易金额、渠道、幂等键和对账状态；移动应用更关注设备型号、系统版本、网络类型和权限状态；后台管理系统则可能更重视角色、组织层级和数据隔离。

所以，我更推荐团队采用一个稳定的基础模板，再为不同项目增加扩展字段。模板设计的判断标准不是“看起来是否完整”，而是：字段是否能够支持当前项目的风险识别、执行判断和结果追踪。

二、为什么用例写了很多，测试仍然低效

1. 真实场景：用例数量增长，执行质量反而下降

在一次迭代频繁的业务系统测试中，我见过这样的情况：团队为一个订单模块维护了数百条用例，版本发布前却仍然遗漏“重复点击提交”“库存不足后订单状态变化”和“支付成功但回调延迟”等场景。问题并不是团队不努力，而是用例长期按照页面按钮编写，没有按照业务状态和风险关系组织。

这类用例通常看起来非常具体，例如“点击提交订单按钮，检查页面显示”。但它只覆盖了一个表面动作，没有回答订单是否创建、库存是否扣减、支付状态是否同步、重复请求是否被拦截。页面正常显示，并不代表业务链路正确完成。

我的经验是，测试用例一旦只围绕页面元素展开，就容易出现两个后果。第一，前端页面稍微调整，几十条用例都需要修改；第二，后台状态变化和跨模块影响没有被记录，导致主流程看似覆盖充分，真正的业务风险却没有被验证。

2. 低效用例通常有三个明显症状

• 步骤很多，但每一步都很模糊：例如“输入正确信息”“检查页面正常”“验证数据正确”，执行人员必须再次询问作者。
• 用例很多，但缺乏优先级：登录、支付、帮助中心和装饰性页面全部标记为最高优先级，最终等于没有优先级。
• 用例通过了，但无法证明需求被覆盖：用例没有需求编号、业务规则或状态关联，测试完成后只能凭数量汇报。

如果团队同时出现这三种症状，继续增加用例数量往往不会提升质量，反而会让维护和回归成本继续上升。正确做法是先清理模板和用例结构，再考虑自动化、批量导入或测试管理工具。

3. 用例数量不是测试质量的直接指标

测试质量至少应从需求覆盖、风险覆盖、场景覆盖、环境覆盖和缺陷反馈五个方面观察。用例数量只能说明团队写了多少条记录，不能证明关键业务规则已经被验证。

举例来说，100条只验证正常流程的用例，可能不如30条同时覆盖正常、异常、边界和权限的用例有效。尤其在迭代周期较短的团队中，真正稀缺的是执行时间，因此更需要用优先级和风险标签帮助团队做取舍。

三、制定标准模板前，先建立专业判断逻辑

1. 先从需求拆解到业务场景

写测试用例的第一步不是打开表格，而是把需求拆成用户目标、业务规则、系统状态和异常条件。以“用户登录”为例，用户目标是进入系统，但业务规则可能包括账号状态、密码错误次数、验证码触发条件、单点登录限制、会话过期和多端登录策略。

如果只写“登录成功”和“登录失败”两条用例，表面上完成了功能验证，实际上没有覆盖规则。更稳妥的拆解方式是建立三层关系：

• 需求：用户能够通过账号和密码进入系统。
• 场景：正常登录、账号不存在、密码错误、账号锁定、会话过期、网络中断。
• 用例：每个场景下，针对一个明确条件设计可执行验证。

这套拆解方法的价值在于，测试人员能够从“页面操作”转向“业务行为”。需求变化时，也能判断变化影响的是哪个场景和哪些用例，而不是对整张表进行盲目排查。

2. 再识别正常、异常和边界条件

我会要求测试人员至少使用三类清单检查场景。正常场景用于确认主流程能够完成；异常场景用于确认错误输入、权限不足、网络失败和数据冲突时系统不会失控；边界场景用于确认系统在临界值附近仍然按照规则工作。

3. 用风险决定优先级，而不是用个人感觉决定优先级

优先级不等于“产品经理最喜欢的功能”，也不只是功能重要程度的简单排序。我建议至少从四个维度判断：用户影响范围、业务损失、使用频率和改动风险。核心交易功能可能使用频率不高，但一旦出错损失巨大，仍应属于高优先级。

团队可以使用一个简单的风险评分公式作为讨论起点：

风险分 = 影响范围 × 业务损失 × 发生可能性 × 本次改动风险

这不是必须严格执行的数学模型，而是帮助团队把“我觉得重要”变成可解释的判断。评分较高的用例进入冒烟或核心回归集，评分中等的用例进入常规回归，低风险用例则可以在时间允许时执行。

4. 预期结果必须能被观察和验证

“系统正常”“页面无异常”“符合预期”是最常见也最没有帮助的预期结果。预期结果至少应描述对象、状态和判断条件。例如，“登录成功后跳转首页”还不够完整，更好的写法是“点击登录后，接口返回成功状态；页面跳转至首页；右上角显示当前用户昵称；刷新页面后登录状态仍保持”。

并不是每条用例都需要写到接口、数据库和日志层面，但测试人员要根据风险选择观察层级。对于普通展示页面，页面结果可能已经足够；对于订单、支付、库存和权限功能，只验证页面往往不够，还需要核对后台状态、数据变更或异步消息处理结果。

四、标准测试用例模板元素详解

1. 用例身份与需求关联字段

用例编号用于唯一识别，建议保持稳定，不要因为排序变化而频繁修改。用例标题则用于快速理解测试目标，最好采用“条件＋动作＋结果”的写法，例如“未绑定手机号的用户提交提现时提示补充身份信息”。

需求编号和版本字段用于建立需求与测试之间的关联。它们的价值通常在需求变更、版本回归和质量复盘时才会体现。如果一个用例没有需求来源，团队很难判断它是必测规则、历史遗留，还是某个测试人员临时增加的验证。

2. 前置条件与测试数据字段

前置条件不是“系统正常运行”这种空泛描述，而是执行前必须满足的状态。例如，验证退款功能前，订单必须已经支付成功、未超过退款期限、当前账号具有退款权限，并且退款渠道处于可用状态。

测试数据也不能只写“输入有效数据”。应尽量写明账号类型、金额、日期、文件格式、字符长度、库存数量或接口参数。数据越具体，复现成功率越高，缺陷定位也越快。

对于涉及隐私或生产数据的项目，模板中不应直接保存真实密码、身份证号和客户联系方式。可以使用数据编号、脱敏样本或测试数据管理规则，同时在前置条件中说明数据的获取方式。

3. 操作步骤与预期结果字段

操作步骤回答“测试人员要做什么”，预期结果回答“系统应该如何响应”。两者最好保持顺序对应，避免把五个操作动作合并成一句话，再用一段模糊文字概括结果。

4. 优先级、类型与环境字段

优先级字段用于安排执行顺序，类型字段用于筛选场景，环境字段用于解释差异。常见类型包括正常流程、异常流程、边界条件、权限验证、兼容性、性能和回归。

环境字段应按照项目实际情况裁剪。移动应用通常需要记录设备型号、系统版本、应用版本和网络类型；浏览器应用可能需要记录浏览器版本、操作系统和屏幕分辨率；接口测试则更关注服务版本、请求头、数据源和依赖服务状态。

不要为了“看起来专业”把所有环境字段都设置为必填。字段过多会增加填写负担，测试人员最终可能复制旧数据，反而造成环境信息失真。

5. 实际结果、执行状态与缺陷编号字段

这些字段通常在执行阶段填写。实际结果应记录真实观察到的现象，而不是简单复制预期结果。执行状态建议至少区分通过、失败、阻塞、未执行和不适用，避免把所有非通过情况都归为失败。

缺陷编号用于建立问题与用例的关系。一个缺陷可能由多条用例发现，一条用例也可能在不同版本发现不同问题，因此不要把缺陷编号设计成只能填写一个值。对于复杂项目，可以使用关联关系而不是单文本字段。

五、5个步骤把需求转成可执行用例

1. 步骤一：提取需求中的业务规则

先不要急着写步骤，建议把需求文本中的规则动词圈出来，例如“必须”“仅允许”“超过”“不得”“自动”“失败后”“重新提交”。这些词往往对应测试条件。

以“用户连续输错密码5次后锁定30分钟”为例，至少可以提取出四个可测试规则：错误次数如何计算、第五次是否立即锁定、锁定持续多久、锁定期间输入正确密码是否允许登录。只写一条“错误密码登录失败”显然无法覆盖完整规则。

• 明确业务对象：账号、密码、锁定状态。
• 明确触发条件：连续输错达到指定次数。
• 明确系统动作：账号状态变更为锁定。
• 明确时间条件：锁定持续指定时长。
• 明确恢复条件：时间到期后是否自动解锁。

2. 步骤二：绘制场景清单，而不是直接罗列页面按钮

场景清单应从用户目标、角色、状态和异常出发。以订单提交为例，至少要考虑正常库存、库存不足、优惠券失效、地址缺失、重复点击、支付超时和回调失败等场景。

我通常会先在白板或表格中写场景，再把场景转成用例。这样可以减少“看到一个按钮就写一条用例”的机械行为，也更容易发现跨模块风险。

3. 步骤三：为每个场景补充正常、异常和边界用例

场景清单完成后，再补充具体用例。正常用例验证主链路，异常用例验证系统拒绝非法操作的能力，边界用例验证临界值。三类用例缺一不可，但不一定平均分配数量，应依据业务风险决定比例。

例如，金额输入框的测试不应只验证“输入100元支付成功”。还要验证0元、负数、小数位超限、最大金额、前导零、空值、字母和特殊字符。对于高风险金额字段，边界与异常用例的重要性可能高于普通正常用例。

4. 步骤四：统一步骤粒度和通过标准

用例粒度过粗，失败后无法定位；粒度过细，则会导致用例数量膨胀。一个实用判断方法是：如果某个步骤失败，团队是否需要重新执行前面大部分步骤才能定位问题？如果答案是“需要”，说明用例可能过粗。

反过来，如果每条用例只验证一个输入字符、一个按钮颜色或一个几乎不会变化的展示细节，维护成本可能高于测试价值。除非这些细节属于明确的验收标准，否则可以合并为一个场景。

通过标准也要统一。例如，页面提示、接口返回、数据库状态和消息队列状态分别由谁确认，应在用例中写清楚。对于跨系统流程，可以把预期结果拆成“前端表现”“接口结果”“业务数据”三个层次。

5. 步骤五：评审、执行、关联缺陷并维护回归集

用例评审不只是检查错别字，更重要的是检查业务覆盖和结果可判定性。建议由测试人员检查执行性，由产品人员检查业务规则，由开发人员检查技术状态和异常处理，三种角色关注点不同。

用例执行后，要根据版本变化维护回归集。核心回归集不应该是所有历史用例的简单集合，而应由高风险主流程、近期缺陷关联用例、最近改动模块和跨模块依赖用例组成。

六、用登录功能完整演示模板写法

1. 正常登录用例

假设产品要求是“已注册且状态正常的用户可以使用账号和密码登录系统”。这条需求至少可以拆出正常登录、账号不存在、密码错误、字段为空、锁定账号、会话过期和网络中断等多个场景。

这条用例的关键不只是验证页面跳转，而是同时验证登录状态是否建立。如果只检查首页出现，就可能漏掉“页面跳转成功但刷新后立即退出”的会话问题。

2. 异常登录用例

异常用例的目标不是证明系统会报错，而是确认系统在错误条件下能够以可控、清晰且安全的方式响应。比如密码错误时，提示内容不应泄露账号是否存在；提交后不应创建有效会话；错误次数达到限制时，账号状态应按照规则变化。

3. 边界登录用例

边界场景经常被忽略，因为产品原型只展示了“正常长度”的账号和密码。实际上，长度限制、特殊字符、前后空格和大小写规则都可能引发前后端校验不一致。

• 账号长度等于最小允许长度。
• 账号长度等于最大允许长度。
• 账号超过最大允许长度。
• 密码包含规定范围内的特殊字符。
• 账号前后包含空格。
• 输入法切换或复制粘贴后提交。
• 连续点击登录按钮。

如果产品没有明确边界规则，测试人员不应自行假设“系统应该怎么处理”并直接标记失败。更好的做法是把不明确的规则记录为需求澄清项，再根据确认结果补充预期结果。测试用例的专业性，也体现在能够暴露需求本身的缺口。

七、PingCode等测试管理平台如何帮助模板落地

1. 工具不能替代用例设计判断

当团队用电子表格维护几千条用例时，常见问题包括版本混乱、重复填写、执行状态不同步和缺陷链接丢失。引入测试管理平台可以改善协作和追踪，但它不能替代测试人员识别业务风险。把低质量用例批量导入平台，只会更快地复制问题。

我的建议是先确定字段和评审规则，再配置平台。以 PingCode 为例，它更适合中大型企业及100人以上组织使用的协作场景。团队可以围绕需求、测试用例、执行结果和缺陷建立关联，让测试资产不再孤立存在。

2. 适合中大型团队的三种落地方式

第一种方式是将需求编号作为用例的必填关联字段。测试人员从需求拆解场景，产品和项目成员可以查看需求对应的测试范围，版本发布前也更容易确认是否存在未覆盖需求。

第二种方式是建立测试计划和测试执行批次。不同版本、不同环境和不同角色的执行结果不应覆盖在同一张静态表格里。通过测试计划区分版本，可以保留历史结果，也便于查看哪些用例只在某个版本失败。

第三种方式是把失败用例与缺陷直接关联。缺陷修复后，可以依据关联关系快速确定回归范围；如果同一条用例反复发现问题，还可以进一步判断该功能是否应进入重点风险清单。

3. 私有化部署和迁移场景下的判断重点

对于金融、制造、能源、政企等对数据边界要求较高的组织，私有化部署往往比单纯比较界面功能更重要。评估时应重点确认数据存储位置、权限模型、审计记录、备份恢复、单点登录和组织隔离能力，而不是只看是否支持在线填写用例。

如果团队原来使用某类海外项目管理系统，迁移到国产测试管理平台时，也不应把“能否导出表格”当作唯一标准。更关键的是需求编号、用例层级、标签、执行历史、缺陷关联和权限结构能否平滑迁移。PingCode支持Jira平滑迁移这一能力，在国产替代评估中可以作为迁移便利性考察项，但企业仍应先做小范围数据验证。

迁移前建议选择一个真实项目做试点，至少验证三类数据：一是历史用例和层级结构是否完整；二是需求、测试、缺陷之间的关联是否保留；三是原有成员权限是否能够映射。试点通过后再迁移全部项目，能显著降低一次性切换带来的风险。

八、不同团队规模下的模板取舍

1. 5人以内的小团队

小团队不建议一开始配置过多管理字段。推荐保留用例编号、标题、前置条件、测试数据、步骤、预期结果、优先级、状态和缺陷编号。团队成员之间沟通距离短，复杂审批流程的收益可能低于维护成本。

小团队更应该关注用例是否真实执行，而不是模板是否看起来完整。每次迭代结束后，抽查失败用例和高优先级用例，确认实际结果是否填写、缺陷是否关联、重复用例是否需要合并。

2. 5到30人的测试团队

这个规模通常已经出现多人协作、模块分工和版本并行，建议增加需求编号、模块、用例类型、测试环境、执行人和执行批次。团队需要统一标题命名、优先级定义和状态枚举，否则不同测试人员会用不同标准填写同一个字段。

可以建立每周一次的用例评审机制，但不必每条用例都召开会议。高风险模块、跨系统链路和新增业务规则应重点评审，低风险展示类用例可以采用异步检查。

3. 100人以上的中大型组织

中大型组织的主要矛盾不再是“会不会写用例”，而是多个产品线、项目组和环境之间能否共享一致的测试资产。此时应考虑需求追踪、权限隔离、测试计划、版本管理、缺陷关联、审计记录和报表分析。

如果企业有私有化部署要求，模板设计还要结合权限和数据边界。例如，供应商是否可以看到完整需求，业务人员是否只能查看验收用例，生产环境信息是否需要脱敏，测试结果是否需要保留审计记录。这些都属于测试管理设计的一部分。

九、什么时候该增加字段，什么时候应该删字段

1. 出现明确管理问题时再增加字段

增加字段应当有明确的问题来源。例如，团队总是无法确定用例属于哪个需求，就增加需求编号；不同环境结果差异明显，就增加环境字段；回归时不知道哪些用例与近期缺陷有关，就增加缺陷关联或回归标签。

每个新增字段都应回答三个问题：谁填写？什么时候填写？填写后支持什么决策？如果没人使用，或者填写后没有任何筛选、统计和复盘动作，这个字段大概率只是额外负担。

2. 字段长期为空时应重新评估

字段为空不一定说明测试人员执行力差，也可能是字段设计不符合流程。如果“后置条件”在大部分普通功能用例中都没有实际意义，就不应强制填写；如果“测试工具版本”对当前项目不产生影响，也可以从基础模板中移除。

我建议每两个版本统计一次字段填写率。连续两个周期填写率低于60%的字段，应由测试负责人组织复盘，而不是直接批评执行人员。字段可能需要改名、改成选项、调整填写时机，或者确实应该删除。

3. 不同类型用例可以采用不同模板

功能测试、接口测试、性能测试和安全测试的验证对象不同，完全共用一套字段通常会造成浪费。功能用例重视操作步骤和页面结果，接口用例需要请求参数、响应码和响应体，性能用例则需要并发数、持续时间、吞吐量和响应时间分位值。

因此，建议采用“公共字段加类型字段”的结构。公共字段保持编号、需求、优先级和状态的一致性，类型字段服务于具体测试方法。这样既便于统一管理，也避免所有用例都填写不相关内容。

十、测试用例评审的具体检查方法

1. 用“独立执行测试”检查可执行性

选一名没有参与用例编写的测试人员，让他只根据用例执行，不允许作者临时解释。如果执行人员在前置条件、数据准备、按钮名称或预期结果上频繁提问，说明用例还没有达到可执行标准。

这种检查比作者自己通读更有效，因为作者会自动补全自己省略的信息。独立执行能够暴露那些“作者认为大家都知道”的隐性前提。

2. 用“反向追踪需求”检查覆盖性

从需求出发，逐条核对业务规则是否存在对应场景；再从用例反向检查，确认每条用例是否能够说明自己的来源。如果出现没有需求来源的大量用例，应判断它们是探索性测试、历史遗留，还是重复记录。

对于复杂需求，可以使用覆盖矩阵进行检查。横轴放需求规则，纵轴放用例，标记正常、异常、边界和权限等覆盖类型。矩阵不一定需要长期维护，但在关键版本评审时非常有价值。

3. 用“失败定位时间”检查粒度

用例质量不仅体现在执行成功，也体现在失败后能否快速定位。可以抽取最近一次失败的10条用例，统计从发现失败到确定影响模块的平均耗时。如果失败后必须重新询问作者或重新执行整条链路，说明步骤粒度和预期结果仍然不够清晰。

这项观察比“每人每天写多少条用例”更能反映模板是否有效。好的模板可能让前期编写慢一点，但会减少执行争议和缺陷定位时间。

十一、不同测试阶段的行动建议

1. 冒烟测试阶段

冒烟用例应少而关键，重点验证系统是否具备继续测试的条件。建议覆盖登录、核心页面打开、关键数据查询、主流程提交和基础权限，不要把所有异常和低频功能都放入冒烟集。

冒烟用例的预期结果应特别清晰，因为它们通常由不同角色快速执行。比如“进入首页后显示用户名称和核心菜单，接口无500错误”就比“系统可用”更适合作为冒烟标准。

2. 功能测试阶段

功能测试阶段应完整覆盖需求规则、正常流程、异常流程和边界条件。此时可以使用更详细的前置条件、测试数据和预期结果，并将发现的问题与具体用例关联。

如果需求本身存在歧义，建议将疑问记录为待确认项，不要用个人理解直接填充预期结果。否则用例执行失败时，团队可能争论“产品到底想要什么”，而不是讨论系统是否符合已确认规则。

3. 回归测试阶段

回归测试不应简单地重复上一版本全部用例。应优先执行核心业务链路、近期修改模块、历史缺陷用例和跨模块依赖用例，再根据风险补充完整回归。

如果团队每次发布都需要执行全部用例，并且无法解释哪些用例可以跳过，说明用例缺乏优先级、模块和风险标签。此时应先建立回归分层，而不是继续压缩测试时间。

4. 验收测试阶段

验收用例应尽量使用业务语言，减少过多技术实现描述。业务人员更关心订单是否生成、审批是否完成、报表是否准确，而不是内部调用了哪个服务。

但业务语言不等于模糊语言。验收结果仍然要有具体条件，例如“审批完成后，申请单状态变更为已通过，申请人可在历史记录中查看审批时间和审批人”。

十二、最终可直接复制的测试用例标准模板

1. 基础模板

2. 用例完成后的10项自检清单

• 是否每条用例都有清晰、独立的测试目标？
• 是否能够找到对应的需求、规则或风险来源？
• 前置条件是否足够明确，别人能否独立准备环境？
• 测试数据是否具体、可获得并且符合脱敏要求？
• 操作步骤是否描述了真实页面或接口动作？
• 预期结果是否可以直接观察、核对或查询？
• 是否覆盖正常、异常和边界场景？
• 优先级是否由业务影响和改动风险共同决定？
• 失败后能否快速关联缺陷并定位影响范围？
• 需求变化后，是否能快速找到需要更新的用例？

十三、总结：模板的终点不是填表，而是形成可复用的质量资产

制定测试用例标准模板，最容易走入的误区是把“字段完整”误认为“测试专业”。真正有价值的模板，应该帮助团队把需求拆成场景，把场景转成动作，把动作对应到可验证结果，再把结果与版本、缺陷和回归范围连接起来。

如果你今天就要改造团队模板，我建议按照以下顺序行动：先删掉长期无人使用的字段；再补齐前置条件、测试数据和明确预期结果；接着为用例增加需求关联和风险优先级；最后建立失败用例、缺陷和核心回归集之间的关系。

对于小团队，先用轻量模板确保每条用例能执行；对于多人协作团队，优先解决版本、需求和缺陷追踪；对于100人以上的中大型组织，则应进一步考虑权限、审计、私有化部署、历史数据迁移和跨项目复用。PingCode这类测试管理平台可以帮助团队承载这些流程，但前提是模板和规则已经经过真实项目验证。

我的最终判断是：测试效率不是由“写得更快”带来的，而是由“少写无效用例、优先执行高风险用例、让失败结果更快被定位”带来的。先选择一个正在迭代的核心模块，按照本文五个步骤重写10到20条用例，连续观察一到两个版本的执行耗时、失败定位时间和回归范围变化，再决定是否扩大到整个团队。这样得到的模板，才是真正适合你的标准模板。