Back to Details

edge-hunt

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Edge Hunt

Edge Hunt

Корнер редко выглядит необычно по частям. Обычно ломается пересечение обычного состояния, обычного действия и неучтённого порядка событий. Не пытаться просто «подумать внимательнее»: построить пространство задачи и системно столкнуть его измерения.
Сначала убедиться, что задача и масштаб уже выбраны. Этот скилл укрепляет края решения, но не доказывает, что выбрано правильное решение. Если направление ещё обсуждается, вернуться к 
nodumb
или 
ask-nodumb
.
边缘情况很少在单个环节上表现异常。通常是常规状态、常规操作和未考虑到的事件顺序的交叉点导致问题。不要试图只是“更仔细思考”：构建任务的维度空间，系统性地交叉各个维度。
首先确保已确定任务和规模。该技能用于强化解决方案的边缘覆盖，但无法证明所选方案是否正确。若方向仍在讨论中，请返回使用
nodumb
或
ask-nodumb
。

1. Зафиксировать нормальный контракт

1. 确定正常契约

Одной короткой цепочкой записать:
исходное состояние → действие → видимый результат → что обязано сохраниться
Последний элемент обязателен. Неявные гарантии вроде «закрыл временную панель — вернулся к прежней работе» чаще выпадают из постановки, чем основной результат.
Не изобретать контракт только по тикету. Проверить релевантные код, тесты, документацию, историю решений и соседние сценарии. Разделить:
  • подтверждённое текущее поведение;
  • выбранное новое поведение;
  • предположение без источника;
  • вопрос, требующий продуктового решения.
用简短的链条记录：
初始状态 → 操作 → 可见结果 → 必须保留的内容
最后一项为必填项。诸如“关闭临时面板后返回原工作状态”这类隐含保障，比主要结果更容易被遗漏在任务说明之外。
不要仅根据工单凭空构建契约。需检查相关代码、测试、文档、决策历史和相邻场景。区分：
  • 已确认的当前行为；
  • 选定的新行为；
  • 无依据的假设；
  • 需要产品决策的问题。

2. Выделить измерения именно этой задачи

2. 提取当前任务的维度

Выбрать только те оси, которые физически участвуют в изменении:
  • состояние до действия;
  • способ входа и вариант действия;
  • порядок, повтор, отмена и прерывание;
  • форма, объём и свежесть данных;
  • роль, права и смена доступа;
  • этап жизненного цикла: первый случай, следующий, спустя время, после restart, update, миграции или отзыва доступа;
  • время ответа, retry и поздний результат;
  • устройство, вкладка, процесс или внешняя интеграция;
  • параллельное действие другого участника или воркера.
Для каждой выбранной оси назвать 2–5 различающихся классов, а не перечислять все возможные значения. Отметить невозможные сочетания и основание, которое их исключает.
仅选择实际参与变更的维度：
  • 操作前的状态；
  • 进入方式和操作选项；
  • 顺序、重复、取消和中断；
  • 数据的形式、量和新鲜度；
  • 角色、权限和访问变更；
  • 生命周期阶段：首次使用、后续使用、一段时间后、重启、更新、迁移或权限撤销后；
  • 响应时间、重试和延迟结果；
  • 设备、标签页、进程或外部集成；
  • 其他参与者或工作线程的并行操作。
为每个选定的维度定义2–5个不同的类别，而非枚举所有可能值。标记不可能的组合及其排除依据。

3. Породить корнеры

3. 生成边缘情况

Применить к выбранным осям пять операций:
  1. Пересечение. Скрестить пары условий. Для потери данных, прав, платежей, синхронизации и необратимых действий проверить также тройки.
  2. Перестановка. Поменять порядок связанных действий; повторить действие; вставить отмену, возврат, перезапуск или продолжение после паузы.
  3. Нарушение инварианта. Попытаться потерять то, что должно сохраняться: основную работу, идентичность, выбор, данные, права или возможность вернуться.
  4. Разрез сбоя. Поместить ошибку до эффекта, во время частичного эффекта и после эффекта, но до подтверждения пользователю.
  5. Сдвиг по жизненному циклу. Повторить сценарий не только сразу, но для второго и последующего объекта, после истечения времени, перезапуска, обновления, миграции или отзыва внешнего права.
Не останавливаться на названиях вроде «ошибка сети». Описывать полную ситуацию: что уже произошло, что не произошло, что видит человек и что случится при повторе.
Подробный механизм и примеры — 
references/generation-methods.md
.
对选定维度应用以下五种操作：
  1. 交叉组合：将条件两两交叉。对于数据丢失、权限、支付、同步和不可逆操作，还需检查三者组合的情况。
  2. 顺序调整：改变相关操作的顺序；重复操作；插入取消、返回、重启或暂停后继续的操作。
  3. 破坏不变量：尝试破坏必须保留的内容：核心工作、身份、选择、数据、权限或返回能力。
  4. 故障切入：在效果发生前、部分效果发生时、效果发生后但未向用户确认前引入错误。
  5. 生命周期偏移：不仅在立即执行时重复场景，还要针对第二个及后续对象、过期后、重启、更新、迁移或外部权限撤销后的场景进行重复。
不要停留在“网络错误”这类笼统名称上。描述完整场景：已发生什么、未发生什么、用户看到什么以及重复操作时会发生什么。
详细机制和示例请参考
references/generation-methods.md
。

4. Отобрать важное

4. 筛选重要场景

Оставить обычно 5–10 сценариев. Поднимать выше случаи, где:
  • несколько обычных условий создают неожиданный результат;
  • возможны тихая потеря данных, нарушение прав или необратимое действие;
  • граница проходит между двумя компонентами, устройствами или моментами времени;
  • поведение существует в продукте, но не записано в постановке;
  • проверка способна опровергнуть решение, а не только подтвердить реализацию.
Не добавлять корнер только потому, что он теоретически возможен. Назвать связь с реальным состоянием, веткой кода, контрактом, прошлым багом или внешней гарантией. Невозможные, уже закрытые нижним слоем и не относящиеся к изменению случаи отбросить.
通常保留5–10个场景。优先保留以下情况：
  • 多个常规条件组合产生意外结果；
  • 可能出现静默数据丢失、权限违规或不可逆操作；
  • 边界存在于两个组件、设备或时间点之间；
  • 产品中存在该行为但未记录在任务说明中；
  • 验证能够推翻解决方案，而非仅确认实现。
不要仅因理论上可能就添加边缘情况。需说明其与实际状态、代码分支、契约、过往缺陷或外部保障的关联。排除不可能的、已由底层处理的以及与当前变更无关的情况。

5. Превратить находку в решение

5. 将发现转化为解决方案

Для каждого оставшегося корнера определить один статус:
  • поддержать сейчас — без него задача не выполняет свой контракт;
  • сохранить прежнее — новое решение не должно менять существующий сценарий;
  • оставить за границей — случай реален, но его цена не входит в эту задачу;
  • нужен новый факт — сначала наблюдение, лог, решение человека или живая проверка.
Не перекладывать на пользователя обратимые локальные решения. Рекомендовать поведение по существующему контракту; спрашивать только там, где выбор меняет продукт, данные, права или скоуп.
为每个保留的边缘情况确定一个状态：
  • 当前支持：没有该场景，任务无法履行其契约；
  • 保留原有行为：新解决方案不应改变现有场景；
  • 排除在范围外：该情况真实存在，但处理成本不在本次任务范围内；
  • 需要新事实：需先进行观察、记录、人工决策或实际验证。
不要将可逆的本地解决方案推给用户。建议遵循现有契约的行为；仅在选择会改变产品、数据、权限或范围时才询问。

6. Проверить, а не только перечислить

6. 验证而非仅列举

Если доступны код или живой продукт, безопасно проверить 1–3 самых рискованных сценария до реализации либо включить их в план проверки. Предпочитать пробу, которая может опровергнуть гипотезу: воспроизведение, state-machine test, property-based test, fault injection или минимальную последовательность событий.
Выбрать сигнал, который физически наблюдает сломанный слой: визуальное поведение проверять в живом интерфейсе, сохранность данных — повторным чтением из хранилища, права — запросом с нужной ролью, восстановление — реальным restart. Зелёная проверка не считается подтверждением, если она не могла увидеть дефект.
Не выдавать придуманный сценарий за найденный дефект. Отдельно помечать: подтверждено кодом, воспроизведено, следует из контракта или остаётся гипотезой.
若有代码或可用产品，在实现前安全验证1–3个风险最高的场景，或将其纳入验证计划。优先选择能够推翻假设的测试方法：复现、状态机测试、基于属性的测试、故障注入或最小事件序列。
选择能够直接观察故障层的信号：在实际界面中检查视觉行为，通过重新读取存储验证数据完整性，通过对应角色的请求验证权限，通过实际重启验证恢复能力。若验证无法发现缺陷，即使结果为通过也不能视为确认。
不要将虚构场景当作已发现的缺陷。需单独标记：已代码确认、已复现、符合契约或仍为假设。

Результат

结果

Начать с самого опасного пропуска. Для каждого корнера кратко дать:
СитуацияОжидаемое поведениеПочему её легко пропуститьСтатусПроверка
В конце назвать, какие измерения проверены, какие сознательно исключены и какое одно неизвестное сильнее всего ограничивает уверенность. Не превращать ответ в ритуальный чеклист и не расширять задачу молча.
从最危险的遗漏情况开始。为每个边缘情况简要填写：
场景预期行为为何容易被遗漏状态验证方式
最后说明已验证的维度、故意排除的维度，以及哪一个未知因素最限制信心。不要将答案变成例行检查表，也不要擅自扩大任务范围。