软件评测师备考：每日一练错题集揭示测试设计与流程高频误区

1. 为什么我坚持用错题集备考评测师：从丢分习惯看复习重点

每天刷完题，我最大的感受是：软考评测科目的丢分，大多不是不会做，而是“以为自己会了”。

比如一道题目，四个选项里有两个长得非常像，都是教材里出现过的原话，你凭印象选了一个，对答案发现错了。翻开教材一查，才发现自己平时根本没把这两个概念放在一起对比过。这种情况我很熟悉，尤其是在软件评测师这种偏理论、偏概念辨析的科目里，文字陷阱多，数字标准多，术语相似度高。如果不把错题记录下来，第二天再碰到同样考点的变体，大概率还会选错。

这就是我坚持做“每日一练错题集”的直接原因。每一天的练习量不用大，关键是把做错的题、蒙对的题、犹豫很久的题，全部摊开来看一遍，找出背后的知识点漏洞。今天是我坚持的第3天，错题不多，但暴露的问题挺典型，我整理成了这篇文章，既是对自己的复盘，也给同样在备考软件评测师的朋友们一个参考。

先说下我给自己定的规则：

每日练习不求多，10到15道选择题加两道案例分析题为宜。做错的、蒙对的、超过两分钟还没把握的，全部进错题集。整理时写清楚：题干考的知识点、我当时选的答案、正确选项、完整解析、错因归类。

错因我会分成三类：概念混淆型、审题疏忽型、知识盲区型。分类不是为了好看，是为了后续复习时有针对性。概念混淆的题，需要把相似概念做成对比表；审题疏忽的题，提醒自己注意题干里的“不正确”“错误”“不包括”这类反向设问；知识盲区的题，才需要真正回到教材补课。

第3天的练习里，我遇到了几道还算典型的题，下面挑一些有代表性的展开说说。

1.1 从一道等价类划分题看测试用例设计的基本功

今天的第一道错题，考的是等价类划分法。题目本身难度不大，但我居然栽了，因为我漏掉了一个很基本的边界值判断。

题目大概是这样的：某系统要求用户输入年龄，有效范围是18至60岁，包含18岁和60岁。问下列哪个选项正确划分了有效等价类和无效等价类。

我当时的思路是，有效等价类就是大于等于18且小于等于60的整数，无效等价类就是小于18和大于60的整数。看着很简单，但是选项里有个干扰项，把有效等价类写成了“18到59岁”，理由是年龄通常是整数，60岁可能被排除在处理逻辑之外。我一犹豫，觉得好像也说得通，就选错了。

对答案时我才反应过来，题目已经明确写了“包含18岁和60岁”，那有效等价类就必须包含60。“18到59岁”这个说法，是出题人故意设计的边界陷阱，它在测试用例设计里属于典型的“想当然”错误。边界值分析时，我们会单独把18和60作为边界值来测，但等价类划分阶段，有效范围内的所有值应该视为一个整体，不能因为感觉“60岁比较特殊”就擅自缩小范围。

这道题我的错因是审题疏忽型，题干里明明白白的条件没抓住，反而被干扰项里的“合理猜测”带偏了。这也提醒我，做这类用例设计题，第一步一定是把题目给定的输入条件圈出来，不擅自加条件，也不随意改边界。

1.2 Beta测试与Alpha测试的区别，别再用“内外部”一刀切

今天的第二道错题，考的是Alpha测试和Beta测试的过程区别。我选错了，原因是把两者的“测试地点”和“测试人员身份”混淆了。

题目问的是：在某软件交付给用户之前，由用户在开发环境下进行的测试，属于哪种测试？

我选了Beta测试。理由是，用户参与测试，而且是交付之前测，那应该是Beta吧？但实际上，标准定义是：Alpha测试由用户在开发环境中进行，Beta测试由用户在真实环境中进行。关键区分维度不只是“用户是否参与”，而是“在什么环境下进行”。

Alpha测试发生在开发方的环境下，Beta测试发生在用户方的真实环境下。虽然两者都是用户在测，但环境不同，目的也不同：Alpha测试是在可控环境下发现缺陷，Beta测试是在真实场景中验证兼容性和稳定性。我答错，是因为脑子里只记住了“Alpha是内部测试，Beta是外部测试”这个粗糙的说法，却没有深入理解“内外部”到底指什么——它指的是测试环境的归属，不是测试人员的归属。

这道题我的错因是概念混淆型。复习时要把这类成对概念放在一起对比记忆，不能只背一个缩略版本。

1.3 判断题里的“验收测试必须由用户参加”：对还是错？

还有一道判断题，说“软件验收测试必须由用户参加”，问是否正确。我选了“正确”，又错了。

回看教材的定义，验收测试是以用户为主的测试，目的是确认软件是否满足验收标准。但是“必须由用户参加”这个说法太绝对了。在某些合同约定或特定场景下，验收测试可能由第三方评测机构来执行，用户并不直接操作，而是通过评测报告来确认验收结果。所以正确表述应该是“验收测试通常以用户为主”，而不是“必须由用户参加”。

这类题目考的是对表述精准度的把握，软考评测里特别爱出这种“绝对词陷阱”。“必须”“一定”“总是”“所有”这类词出现在选项中时，最好多留一个心眼，回到标准定义里确认是否真的无例外。

2. 第3天错题复盘：测试用例与需求分析的几道“送命题”

这一节的错题，全部集中在测试用例设计的前置环节，也就是需求分析和用例设计上。按理说这是整个测试工作的起点，但恰恰是起点处最容易被忽视。我复盘时发现，这些题为什么会错，大多是因为我把知识学得太“孤立”了，没有把前后概念串起来。

2.1 需求分析阶段的输出物，不是测试用例

有一道多选题，问“在测试用例设计之前，测试人员应该先进行哪些工作”，选项中包括需求分析、风险评估、测试计划编写、测试用例执行。我多选了一个“测试用例执行”，觉得执行用例不也是测试工作的一部分吗？

但实际上，这道题限定的阶段是“测试用例设计之前”。在这个时间点，测试人员的主要任务是理解需求、识别测试需求点、进行风险分析，为后续设计用例做准备。而“测试用例执行”发生在用例设计和评审之后，明显不属于“之前”的工作。

这道题暴露的问题是：我把“测试工作的一般流程”和“某个特定步骤的前置条件”混为一谈了。做题时脑子里的知识是线性的，但没有标记先后关系，遇到阶段限定题就容易出错。复盘时，我特意把“测试计划 → 测试设计 → 测试执行 → 测试评估”这个流程在纸上画了一遍，把每个阶段的输入输出都补上，用这种方式来强化阶段感。

2.2 边界值分析：到底取几个点？为什么是这些点？

还有一道边界值分析的经典题：某输入条件规定取值范围是1到100，用边界值分析法设计测试用例，最少需要测几个值？

我看到这类题就条件反射地选了“1、100”两个边界值，结果答案是至少5个，分别是最小值1、略小于最小值0、略大于最小值2、最大值100、略小于最大值99。再极端一点，还要考虑略大于最大值101。

边界值分析法为什么要取“刚刚超过”和“刚刚低于”边界值的点？因为很多程序缺陷恰恰出现在边界的相邻区域，比如用>和>=写错一位，就会导致边界值本身被错误处理。只测1和100只能确认正常边界可用，测0和2才能确认下边界附近的越界判断是否正确，测99和101才能确认上边界附近的处理逻辑。如果程序里是“大于等于60为及格”，那么59和60这两个点，以及61这个刚刚超过的点，就是最容易翻车的地方。

这道题我的错因是概念混淆型。我记住了“边界值分析要关注边界”，却没记住“关注的是边界及其邻近值”，这两个说法差着好几个人。以后做这类题，我的判断标准统一为：最小值、最小值减1、最小值加1、最大值、最大值减1、最大值加1，最多再加一个正常中间值。

2.3 判定表法适用于什么场景？组合条件多且规则明确时

今天还有一道关于测试用例设计方法选择的题：某功能有3个条件，每个条件有两种取值，要求覆盖各种组合情况下的不同操作，问该用哪种方法。

选项里有等价类、边界值、判定表、因果图。我选了因果图，答案是判定表。

这两者确实容易混。因果图法适合分析多个条件组合与结果之间的逻辑关系，强调“因”和“果”的因果关系，常用于输入条件较多、输出结果也较多、关系复杂的场景，比如有“与或非”逻辑时。而判定表法适合条件组合数量有限、每个组合对应一个清晰动作的场景，它把条件列成表格，每一列是一种组合，每一行是条件或动作，直接就能看出覆盖情况。

这道题的关键信号是“各种组合情况下的不同操作”，没有提到复杂的因果关系，也没有“与或非”之类的逻辑关系描述，所以优先选判定表。用判定表的好处是结构清晰、不会漏组合，缺点是条件多时表格会爆炸，比如10个条件每个两值，那就是1024种组合，所以它适合条件数在4到5个以内的场景。这道题我的错因是知识盲区型，我对判定表和因果图的适用边界理解得不够细，只记得两个都有“组合”字样，就选了感觉更高级的那个。

2.4 测试用例的评审：谁来参与？关注什么？

最后一道题考的是测试用例评审。问测试用例评审时，评审人员主要关注哪些方面。选项里有用例对需求的覆盖程度、用例的可执行性、用例的预期结果是否明确、用例编写者的编程水平。

我选了前三个，还犹豫要不要选“编程水平”，最后没选，答案果然不包含它。测试用例评审关注的是用例能不能有效验证需求、步骤是否清晰、预期结果是否可判断、数据是否合理，一般不评审编写者的代码能力。这道题对错倒无所谓，但复盘时我意识到一个复习方法问题：软考评测的选择题考查的是“测试过程的规范化知识”，而不是“测试人员的个人技能”。答题时如果选项里有“个人能力”“个人偏好”这类主观色彩很强的表述，大概率是干扰项。

3. 从概念混淆到大题翻车：软件测试流程中的顽固误区

今天做题做到这里，我开始意识到一个问题：选择题里的丢分，往往不是单一知识点不会，而是一套流程逻辑没有建立起来。比如前面说的“验收测试必须由用户参加”，其实就是对“验收测试在整个开发流程中的位置和作用”理解不到位。所以这一节我想专门聊聊那些在测试流程中高频出现的顽固误区。

3.1 单元测试、集成测试、系统测试：测的对象到底是谁？

有一道题，问“集成测试的主要测试对象是什么”。我选了“整个系统”，错了，答案是“模块之间的接口”。

这三个测试层级本来就容易混淆。单元测试的对象是一个模块或一个函数，验证的是模块内部逻辑；集成测试的对象是模块与模块之间的接口，验证的是数据传递和调用关系是否正确；系统测试的对象才是整个系统，验证的是系统整体功能、性能、兼容性等是否满足需求。如果用盖房子来比喻：单元测试是检查每块砖的质量，集成测试是检查砖与砖之间的砂浆抹得是否到位，系统测试是检查整栋房子能不能住人。我当时选“整个系统”，相当于跳过了“检查砂浆”这一步，直接把“检查整栋房子”安到了集成测试头上。

这类题目的记忆锚点应该是“接口”两个字。看到“模块之间”“接口”“交互”这些关键词，优先对应集成测试。

3.2 回归测试怎么做？重点不是全量重测，而是验证“没被改坏”

另一道题考的是回归测试的策略。场景是某版本修复了一个严重缺陷，问此时应该优先执行的测试类型。我选了“执行全部测试用例”，答案是“重点验证缺陷修复相关的功能及可能受影响的功能”。

这里有个常见误区：很多人觉得回归测试就是“全部重测一遍”，最保险。但实际上，回归测试的核心目的是确认“修改没有引入新的缺陷”，它更强调针对性。全量回归成本太高，在有限的项目周期里不现实，合理做法是基于缺陷影响范围分析，优先测试被修改模块及其关联模块，再结合风险决定是否扩大范围。

教材上对回归测试的定义也包含了“选择合适测试用例”的策略。复盘时我觉得，这道题考的不只是知识点，还有在实际项目中的成本控制思维。软考评测里很多题，本质上是考一种“项目视角”，你得像一个真的测试负责人那样去权衡范围、风险、成本，而不是站在学生视角追求“最全面”。

3.3 缺陷生命周期管理：New、Open、Fixed、Closed到底怎么流转

今天晚上还刷到一道关于缺陷状态的题，问的是“缺陷被修复并验证通过后，状态应该变为哪个”。我不假思索地选了“Closed”，答案是“Verified”或“Closed”根据流程而定，单选里通常优先选“Verified（已验证）”。

这个细节很容易被忽略。在标准缺陷管理流程中，缺陷状态按顺序大致是：New（新建）→ Open（打开/确认）→ Fixed（修复）→ Verified（验证通过）→ Closed（关闭）。如果验证不通过，则从Fixed重新回到Open。如果开发拒绝修改，则可能进入Rejected或Deferred等状态。

“Verified”和“Closed”的区别是：Verified表示测试人员已经确认缺陷被修复了，但缺陷是否彻底关闭、是否要做回归测试、是否要发布说明等后续步骤还没完成；Closed才是流程终点。所以流程严谨的系统里，先置为Verified，再走关闭流程。这道题告诉我，复习缺陷管理时，不能只记状态名，要记状态之间的流转条件和每个状态的语义。

3.4 测试计划里的“测试停止标准”：不是想停就能停

还有一道题，问“测试执行到什么程度可以停止”。我选了“所有测试用例全部执行完毕”，错了，答案是“达到测试退出标准”。

这个也是典型的项目管理思维题。实际测试中，停机标准通常包括：测试用例执行率达到一定比例（如95%以上）、剩余缺陷严重级别较低、缺陷收敛趋势明显、风险评估可接受等。单看“所有用例执行完毕”来定义停止，太过理想化。有些用例可能因为环境限制没法执行，有些高风险区域需要追加测试，这些都可能让“全部执行完”不等于“可以停止”，而“没全部执行完”也不一定不能停。关键是看是否满足预先制定的退出准则。

这类题目考的是对测试过程整体把控的理解。选择题里只要出现“所有”“全部”“绝对”这类词，结合前面提到的绝对词陷阱，我现在的反射动作是先打个问号。

4. 自动化与性能测试错题：为什么越熟悉的题越容易踩坑

今天还涉及几道自动化测试和性能测试相关的点，这块我平时自以为比较熟，但做题时还是踩了两个没想到的坑。复盘下来有一个共同的规律：基础概念越熟悉，越容易在细节上掉以轻心。

4.1 自动化测试能替代手工测试吗？这道题的答案很明确

有一道判断题，说“当自动化测试覆盖了所有手工测试用例后，手工测试可以被完全替代”，问我支持还是反对。我选了“支持”，觉得自动化测试既然能覆盖所有用例，那手工测试当然可以放手了。

这个答案错得很典型。自动化测试的优势是快速、重复执行、适合回归，但它无法替代手工测试中的人工探索和直觉判断。手工测试能发现预期之外的缺陷，比如可用性问题、界面布局问题、需要主观判断的交互体验等；自动化测试只能验证已经预设好的预期结果。就算用例覆盖率达到100%，仍然需要人工进行探索性测试、易用性测试、兼容性中的主观感受评估等。

这道题我的错因是“对自动化的定位理解偏了”。自动化是一个执行工具，不是测试思维的替代品。测试的核心是人去理解需求、设计用例、分析缺陷，自动化只是把一部分重复劳动交给机器。备考时，凡是涉及“完全替代”“完全无需人工”这类极端表述的选项，基本可以快速排除。

4.2 性能测试并发用户数：是“同时操作的人数”吗？

另一道关于性能测试的题，问“并发用户数”的准确定义。我选了“系统同时在线的用户数”，错了，答案是“同时发起请求或操作的用户数”。

这两个概念的区别很微妙，但实际中非常关键。一台服务器可能有1000人在线，但真正在同一瞬间点击页面、提交请求的，可能只有50人。性能测试关注的并发数，是后面这个“正在和系统交互”的数量，而不只是“登录后挂在那里”的在线数量。设计性能测试场景时，如果按在线用户数压测，会导致压力失真，测试结果无法反映真实风险；按并发请求数压测，才能真正暴露系统在高压力下的瓶颈。

这里我还学到一个小经验：性能测试里常提到的“并发数”通常指请求级别的并发，而不是用户会话级别。概念不清会导致压测场景设计错误，这是实际项目里很常见的问题。备考时，这类相近术语一定不能偷懒，要逐字对标准定义。

4.3 压力测试与负载测试的分界线：压力是“超负荷”，负载是“预期内”

还有一道题考压力测试和负载测试的区别。题目问“逐步增加系统负载，直到系统崩溃或资源耗尽，以确定系统最大承受能力，这属于哪种测试”。

四个选项是压力测试、负载测试、容量测试、稳定性测试。我选了容量测试，答案是压力测试。其实这道题我犹豫了很久，因为“确定系统最大承受能力”听起来很像容量测试。但仔细看题，重点是“逐步增加负载直到系统崩溃或资源耗尽”，这强调的是超负荷状态下的表现，属于压力测试的范畴。容量测试更侧重于“系统在不降低性能的前提下能处理的最大数据量或用户数”，它关注的是容量边界，不是崩溃行为。压力测试的关注点是系统在极限和超载条件下是否稳定、能否优雅降级，而不是只看它能承受多少。

现在我把这两者的记忆锚点定为：负载测试在预期负载下看性能表现；压力测试在超负荷下看系统极限和崩溃行为；容量测试在最大可处理量上看资源利用。三者有重叠，但考核角度不同，出题人经常用“逐步加压到极限”这个表述来定向压力测试。

4.4 自动化测试脚本的可维护性：为什么我总是忽略这层

最后一道题，考的是自动化测试脚本设计时要考虑哪些因素，选项里有脚本的可维护性、可重用性、稳定性，还有一个干扰项我选了“脚本的运行速度越快越好”。对答案时我明白了，速度快不是脚本设计的第一要务，稳定和可维护才是。

这个道理想想也简单：自动化脚本要长期使用，项目迭代后功能变了，脚本就要跟着改。如果脚本没有清晰的封装、没有合理的数据驱动结构，改动成本会非常高，反而比手工测试还费时。常见做法是采用Page Object模式，把页面元素定位和业务操作分离，这样页面结构变了，只需要改对应的页面对象，业务脚本基本不用动。我复盘这道题时觉得，它看起来是考概念，其实是在提醒备考者：自动化测试不是“把手工用例翻译成代码”，而是“对测试资产进行工程化设计”。

5. 一道综合场景题完整复盘：我如何把错题拆成知识点清单

今天的练习里，还有一道综合性较强的场景题，我花了比较长的时间，虽然最后大致方向是对的，但有几个细节还是丢了分。这一节我用它来做一个完整拆解，展示我怎么把一道大题拆成一张知识点复查清单。

5.1 场景题原文与我的初答思路

题目大概描述：某电商平台改版了购物车功能，涉及结算金额计算、优惠券叠加规则、库存扣减逻辑三处核心改动，测试团队需要设计测试方案。要求在以下工作中选择合适的安排。

我当时的思路是：先把测试重点放在结算金额计算上，因为这里最容易出现精度问题，比如金额四舍五入、折扣顺序等。优惠券叠加规则也要重点测，因为不同优惠券的组合条件复杂。库存扣减的逻辑改动则放到集成测试阶段去测，理由是它涉及前后台接口交互。

这个思路大方向没有错，但我在细节上暴露了几个问题。第一，库存扣减如果放到集成测试阶段才重点测，前端的购物车页面异常流程就会漏掉很多，比如库存不足时前端提示、下单时库存刚好被扣完的边界情况等。第二，优惠券叠加规则不只要测功能正确性，还要考虑并发场景，比如多个用户同时使用同一张限量优惠券。这两个点我当时完全没想到。

5.2 正确答案里的关键安排与我的差距

参考答案给出的合理测试安排大概是这样的：

• 单元测试层面：重点验证结算金额计算模块的各类输入组合，尤其是精确到分后两位的边界情况，如金额为0、负数、极大值、浮点误差累积等。
• 集成测试层面：重点验证购物车模块与订单模块、库存模块、优惠券模块之间的接口，关注数据传递是否正确、并发扣库存是否会出现超卖。
• 系统测试层面：覆盖用户完整购物流程，从加购、改数量、选优惠券、结算、下单、支付，每一步都要跑通，同时验证异常场景，比如优惠券过期、商品下架、库存不足等。
• 回归测试层面：改版后重点关注原有核心流程是否有受影响，特别是结算金额计算逻辑，必须做全量回归。

对比之后，我的差距主要在两个地方：一是对“什么时候测什么层级”的边界还不够敏感，二是把“库存扣减”想当然地归入集成测试，忽视了它在单元和系统层面的表现。这正是我前面说过的“流程阶段感”问题，知识背了，但是遇到实际场景就串联不起来。

5.3 由此整理的知识点复查清单

我把这道题复盘出的考点全部拉了出来，作为后续复习清单：

这个清单对我接下来几天的复习很有用。错题集的意义不只是“记录错题”，而是要从每道错题中抽出考点，合并同类项，形成一张属于自己的查漏补缺地图。

5.4 场景题的复盘方法：从错因倒推行动计划

面对这种综合题，我现在的复盘动作分三步。第一步，把题干里的测试对象、条件、限制全部提取出来，写在草稿上。第二步，逐条对照标准流程，标出我做题时忽视或混淆的地方。第三步，把每处失误对应到一个具体的复习行动，比如找几道边界值分析的题目做专项练习，或者把测试层级的概念重新梳理一遍。

用这个方式处理错题，会比单纯“看一遍解析，觉得自己会了”有效得多。解析告诉你正确答案是什么，三步复盘法告诉你下次遇到同类题该用什么思维路径去解答。

6. 第3天错题整理的三个方法性收获与后续计划

今天是每日一练的第3天，三天的错题累积下来，我开始摸到一些自己的“固定丢分模式”，也找到了一些整理错题的具体方法。这一节不聊具体的题了，聊一聊方法层面的收获。

6.1 方法性收获一：按“错因”而不是按“知识点”归类错题

最开始我把错题按章节分类，比如“测试基础”“用例设计”“性能测试”，整理完发现一个问题：同一个章节里的错题，错误原因完全不同，有的考记忆，有的考理解，有的考干扰项判断。后来我改成按错因分类，把“概念混淆”“审题疏忽”“知识盲区”分开放，复习效果明显好很多。

概念混淆的题，我会把两个容易混的概念做成对比表格，比如Alpha测试和Beta测试、压力测试和容量测试，对比维度包括测试环境、测试人员、测试目的、典型场景。审题疏忽的题，我在题干关键词上做标记，把“不正确”“不包括”“错误”等反向词用醒目颜色圈出来，提醒自己审题时先看设问方向。知识盲区的题，我单独列出来，回教材补课，再用几道同类题验证是否真正掌握了。

6.2 方法性收获二：错题集一定要“可检索”

刚开始我错题抄得很随意，只写了题干和答案，没有标注考点，也没有写解析，过了两天翻回去看，根本想不起来当时为什么错。今天整理时我调整了格式，每道题统一记录五个要素：

1. 考点标签，比如“用例设计-边界值分析”
2. 原题题干和选项
3. 我选的答案和正确答案
4. 简要解析，拆解题目的关键判断点
5. 错因标签和自己的一句话总结

这种结构化记录方便后面按标签检索，也方便快速重刷。我计划每积累到20道错题，就把它们重新做一遍，能连续做对的题就从错题集移除，只保留仍然会错的题。这样错题集越来越薄，复习负担越来越小，这是一个很有成就感的正向循环。

6.3 方法性收获三：每天错题控制在三五道，重在消化

“每日一练”这个形式，容易让人陷入一种“今天刷够量就算完成”的错觉。但我的体会是，做完题不对答案不算完成，对了答案不写解析也不算完成，写了解析不标记错因还不算完成。真正完成一道错题，是要能用自己的话把错误原因讲清楚，并且找到一个下次不再犯的具体动作。

所以我宁愿每天的练习量少一点，也要保证每道错题都被完整消化。第3天的错题消化完，我明显感觉到自己在做场景题时，对“测试层级”“边界条件”“并发场景”这几个概念的边界感更清晰了。这比单纯刷题量的提升重要得多。

6.4 接下来几天的复习安排

基于第3天的错题情况，我制定的近期练题方向是：把测试用例设计方法里的等价类、边界值、判定表、因果图做一组对比训练；把测试流程中的“层级”与“阶段”概念用流程图方式重新梳理；再找几道综合场景题，专门训练自己拆解题干条件的习惯。错题集继续按“错因优先、考点其次”的方式整理，计划在第7天做一次周期回顾，把前7天的错题统一重刷一遍，检验纠正效果。

备考软考评测是一条需要耐住性子慢慢钻研的路。每天记录三五道错题，看起来微不足道，但坚持几十天之后累计的错误样本量，足以描绘出自己完整的知识薄弱图谱。到那时，考前最有效的复习材料，不是厚厚的教材，而是这本自己一题一题攒出来的专属错题本。我已经在期待第7天的周期回顾了。