Назначение: Проверка и критерии приёмки. Продукт: ShariX Open · Общий компонент.

Для кого: Разработчик · Рецензент и приёмщик · Оператор развёртывания · Нейросеть.

Темы: Разработка → Проверка · База знаний → Основания сведений.

Эта страница описывает, как проверить изменение ShariX Open и передать результат следующему участнику. Перед проверкой нужно знать, какое поведение меняется, в какой версии приложения и при каких условиях оно должно работать.

Проверку выбирают по изменению:

• Поле формы: проверить на самой форме ввод, подпись, сообщение об ошибке, сохранение и вид на узком экране.
• API: выполнить запросы с допустимыми данными, неверным вводом и недостаточными правами.

Одной проверки синтаксиса для этих задач недостаточно.

1. Назвать задачу и ожидаемый результат: что пользователь сможет сделать или какая ошибка исчезнет.
2. Указать продукт, репозиторий и commit. Если проверяется сервер — также конкретную установку и работающую версию.
3. Описать роль пользователя, исходные данные и необходимые настройки. Для общей библиотеки перечислить приложения, которые её используют.
4. Выбрать проверки по изменённому поведению, затем записать результат каждой и оставшиеся вопросы.

Перед проверкой определить не только продукт и роль модуля, но и его лицензию. Основание — LICENSE и COMPLIANCE конкретного репозитория; слово shared и наличие модуля в установке не подтверждают открытый статус.

В публичном отчёте приводят код, проверки и детали открытых компонентов. Если результат зависит от закрытого модуля, назвать эту границу и передать необходимую проверку ответственному со стороны Platform. Его внутренние данные, алгоритм и результаты с ограниченным доступом описываются в intrawiki. Публичный отчёт не должен требовать от читателя получить закрытый код, чтобы повторить проверку открытой части.

Не нужно механически запускать все возможные проверки для правки текста. Но если изменение затрагивает права или данные, успешный импорт Python не проверяет этот риск. Проверка с имитацией внешней службы подтверждает поведение в такой имитации; взаимодействие с настоящей службой проверяется отдельно. Рабочую конфигурацию не меняют только ради теста, а действия с последствиями выполняют в предназначенной для этого среде и в согласованном объёме.

Тестовая заготовка (fixture) — заранее подготовленные данные для проверки конкретного участка. Например, Ticket сразу в нужном статусе. Такая заготовка помогает исследовать обработчик, но может не содержать связей, которые появляются при штатном создании заказа.

Перед выводом о баге выясняют, какие обязательные связи были пропущены в заготовке. Если недопустимое состояние получилось обычным разрешённым действием или найдено на реальной установке, фиксируют путь возникновения и обращаются к ответственному за безопасность. Неполная fixture сама по себе не является доказательством такого обхода. Расширение прав ради успешного теста скрывает проблему, а не проверяет её.

Для выбранного сценария указать начало, участников, исходные объекты, последовательность действий и наблюдаемый итог. Например, проверка обработки вручную созданного Ticket не подтверждает, что пользователь может создать заказ через форму, пройти требования и завершить услугу.

Отдельно отмечать сохранение данных и внешние действия. Статус мог сохраниться в БД, даже если уведомление не доставлено. При неизвестном результате сетевой записи сначала выясняют фактическое состояние, затем решают, допустим ли повтор.

Если весь путь ShariX Open пройти не удалось, сохранить:

• последний успешный шаг;
• точку остановки;
• сообщение системы;
• недостающее условие.

Частичная проверка полезна, когда её граница названа. При изменении shared-модуля отдельно фиксируют передачу опубликованного результата ответственному за Platform; его проверка и принятие выполняются по внутренним инструкциям и не объявляются завершёнными по тестам ShariX Open.

Для каждого существенного требования записать:

1. Источник и область применения.
2. Репозиторий, файл и операцию.
3. Проверку и полученный результат.
4. Оставшийся вопрос.

Если требование не выполнено, указать, какое действие или сохранённое состояние отсутствует.

Общий отчёт не заменяет чтения доступного кода. Наличие похожего поля не является достаточным подтверждением всей процедуры. Для юридического требования техническое сопоставление и вывод о правовой применимости разделяются. Ветвь «ошибка API» на BPMN может обозначать предусмотренный отказ — сначала проверяют её условие.

В итоговом сообщении перечислить:

• Что проверено.
• Где и как.
• Что не проверено и почему.

Чтение кода, локальный тест, проверка интеграции и проверка установленного сервиса должны быть различимы. Следующему участнику нужны конкретная точка продолжения и доступные ссылки.

HTTP-диагностика после restart рекомендательная: timeout, сетевой отказ или HTTP-код сохраняются как WARNING. Они не заменяют результат перезапуска и не доказывают доступность сайта. Ошибки прав, состояния служб, соответствия исходников и происхождения сгенерированных файлов блокируют продолжение по действующей процедуре.

Не объединять наблюдение, догадку и подтверждённый результат. Для каждого вывода дать файл или воспроизводимый шаг. Не объявлять изменение установленным по результату другого продукта, не скрывать предупреждения и не выдавать запланированное действие за выполненное. Человек должен понимать, какое решение можно принять по этим данным.

Подготовка исходного контекста: архив исходников и Graphify. Передача результата: инструкция для оператора.

Проверены опубликованные исходники указанных ревизий. Это source-анализ; он не подтверждает применённую версию, конфигурацию или успешный сценарий конкретного сервера.

• sharix-open-webapp-base: CODING_POLICY.md — f65376cdb5a3.
• sharix-open-webapp-base: bin/repositories.sh — f65376cdb5a3.
• sharix-open-webapp-base: bin/install.sh — f65376cdb5a3.
• sharix-open-webapp-base: bin/utils/install_modes.sh — f65376cdb5a3.
• sharix-open-webapp-base: bin/check_acceptance.sh — f65376cdb5a3.
• sharix-open-handlers-backend: ticket_blockly_codegen.py — 50baf376e224.
• sharix-open-handlers-backend: tools/check_canonical_ticket_codegen.py — 50baf376e224.

Сверены опубликованные исходники. Это анализ кода, а не подтверждение успешной установки на конкретном сервере.

• sharix-open-webapp-base: bin/check_acceptance.sh.