在实时操作系统中，任务优先级直接影响调度行为。对于支持动态优先级调整的 RTOS，除了保证正常修改功能可用，还需要考虑非法任务 ID、越界优先级、异常参数以及不规范命令输入等情况。
近期，我对 HRTOS Shell 的任务优先级修改命令 PR（Priority）进行了边界条件完善与回归验证，重点关注命令参数的合法性检查、异常输入的拒绝处理，以及相关功能在连续操作下的稳定性。
这项工作并不是增加一个新的 Shell 功能，而是进一步完善已有功能的输入约束与异常处理。
一、为什么需要完善优先级修改命令？
RTOS 的任务优先级并不是一个普通的显示参数，它与系统调度行为直接相关。
如果优先级修改命令缺少必要的参数检查，非法输入就可能进入后续处理流程。例如，任务 ID 超出允许范围、优先级超过系统定义的上限，或者用户输入了非数字参数，都可能导致错误的操作行为。
因此，一个可靠的优先级修改命令至少需要明确以下问题：
-
哪些任务 ID 可以接受？
-
哪些优先级数值属于有效范围？
-
非数字、负数以及超出数值范围的输入如何处理？
-
参数数量不正确时，是否会拒绝执行？
-
一次错误输入之后，Shell 能否继续正常工作？
这些问题看似细小，却直接影响命令接口的可靠性。
对于嵌入式系统而言，不能只关注正常输入时的执行结果，还需要明确异常输入的处理规则。
二、优先级修改命令的边界条件
本次完善重点围绕任务标识、优先级参数以及命令格式展开。
1. 任务 ID 合法性检查
优先级修改操作首先需要定位目标任务，因此任务 ID 必须经过有效性检查。
需要考虑的情况包括：
-
任务 ID 不存在或超出允许范围；
-
输入负数形式的 ID；
-
输入非数字字符；
-
输入超出目标数据类型表示范围的数值。
对于非法任务 ID，命令应当拒绝执行，而不是继续操作不合法的任务索引。
这类检查的核心在于：在访问任务相关数据之前，先确认目标标识合法。
2. 优先级取值范围检查
任务优先级通常受到系统配置约束，并非任意整数都可以使用。
因此，优先级参数需要检查是否处于系统允许的范围内。对于超过上限、低于下限或者无法正确转换为数值的输入，应当按照命令定义进行拒绝处理。
这里还需要注意，参数解析正确并不等于参数值合法。
例如，字符串能够转换成整数，只能说明它在语法层面可能是一个数值，并不能证明这个数值符合 HRTOS 的优先级约束。
因此，参数处理应当区分两个层面：
-
格式合法性：输入能否被正确识别为预期类型。
-
取值合法性：转换后的数值是否处于允许范围内。
只有同时满足要求，才应该继续执行优先级修改。
3. 非法数字与溢出输入
命令行参数来自外部输入，不能默认用户一定按照要求输入。
本次边界条件验证覆盖了非数字、负数以及数值溢出等情况，同时检查数字后缀等不规范输入。
例如，下面这些输入形式需要区别处理：
-
abc：非数字输入； -
-1：负数形式； -
超出数值类型表示范围的数字；
-
3abc：数字后面带有非数字后缀。
对于要求完整数字参数的命令，不能只解析字符串的前半部分，就把整个参数当成合法数值。
参数解析必须符合命令规定的格式，并在必要时检查完整输入是否被正确消费，避免部分转换造成误判。
4. 参数数量检查
除了参数内容本身，参数数量同样属于边界条件。
参数缺失可能导致命令无法完成操作，而多余参数则可能说明用户输入了错误的命令格式。
因此，优先级修改命令需要对参数数量进行约束。对于不符合命令定义的输入，应当拒绝执行，避免忽略多余参数后仍然执行修改操作。
通过参数数量检查，可以使命令行为更加明确，也有助于减少误操作。
三、从异常输入拒绝到回归验证
边界条件完善不能只停留在代码审查阶段，还需要通过实际输入验证处理结果。
本次测试除了验证正常的优先级修改，还覆盖了多种非法输入，并对 Shell 的其他功能进行了回归检查。
主要验证内容如下：
| 测试类别 | 验证内容 |
|---|---|
| 正常修改 | 合法任务 ID 与优先级的修改 |
| 优先级恢复 | 修改后恢复原优先级 |
| 非法任务 ID | 不存在或超出允许范围的 ID |
| 非法优先级 | 超出允许范围的优先级 |
| 非法数值 | 非数字、负数及数值溢出 |
| 参数格式 | 数字后缀等不规范输入 |
| 参数数量 | 多余参数 |
| 回归测试 | wait/msg 查询及连续命令执行 |
通过这些测试，可以从正常功能、参数边界和异常恢复三个方面检查命令行为。
其中，正常修改与恢复用于验证基本功能；非法输入测试用于检查参数校验是否有效；wait/msg 查询及连续命令执行则用于确认优先级命令的测试没有影响其他 Shell 操作。
需要强调的是，测试通过说明这些已覆盖场景符合预期，并不意味着所有潜在输入组合都已经得到穷尽验证。对于底层软件，测试范围和实际验证结果应当保持清晰。
四、为什么这些细节值得关注？
任务优先级修改本身并不是一个复杂的 Shell 功能，但它连接着用户输入、参数解析、任务管理接口和调度行为。
任何一个环节缺少约束，都可能让不合法的输入进入后续流程。
完善边界条件的意义，主要体现在三个方面。
第一，降低非法输入造成异常行为的风险。
在执行修改之前验证任务 ID、优先级及参数格式，可以减少不合法参数进入任务管理流程的机会。
第二，让命令行为更加明确。
对于合法输入执行操作，对于非法输入拒绝执行，有助于形成清晰的接口约定，避免命令行为受到不规范输入的影响。
第三，提高组件的可维护性。
当命令具备明确的参数约束和针对性的测试用例后，后续修改解析逻辑或扩展功能时，就可以围绕已有边界进行回归验证。
这些工作未必会增加新的功能入口，却能够让已有功能更加可靠。
五、HRTOS Shell 的持续完善
对于 HRTOS，Shell 不只是一个简单的命令行界面，它也是用户查看系统状态、操作任务和验证系统行为的重要工具。
因此，Shell 的完善不能只看命令数量，还需要关注每条命令的参数约束、错误处理和回归测试。
这次任务优先级修改命令的边界条件完善，就是一次针对已有功能的工程化打磨。
从正常修改和优先级恢复，到非法 ID、非法优先级、异常数字、数字后缀及多余参数的拒绝处理，再到其他命令的回归验证，整个过程体现的是对已有功能进行更细致的检查。
我希望 HRTOS 的开发能够逐步从功能实现走向更细致的工程维护：不仅让功能可以使用，也尽可能明确它的适用范围、异常行为与验证依据。
总结
本次 HRTOS Shell 任务优先级修改命令的完善，重点在于处理参数边界与异常输入，并通过实际测试验证正常操作和相关回归功能。
对于 RTOS 这样的基础软件，可靠性不仅体现在调度器和内核机制中，也体现在 Shell 这些直接面向用户的接口上。
功能实现决定系统能做什么，边界条件处理则帮助明确系统在面对非预期输入时应该怎么做。
持续完善这些细节，是 HRTOS 长期维护过程中值得坚持的一部分。