Ступени доказательств для приёмки интеграции

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

Пять разных вопросов

1. Метаданные каталога. Какая возможность описана и откуда взято описание? Каталог интеграций помогает выбрать кандидатов. В нём описаны 772 приложения и 8 300 действий и триггеров; эти числа относятся к документации, а не к включённым подключениям.
2. Локальная реализация. Существует ли реализация или настройка нужной операции? Запишите её версию и заявленные границы. Само наличие ещё не означает вызов клиентом.
3. Проверка протокола или клиентской библиотеки. Обменялся ли настоящий клиент ожидаемым запросом и ответом с реализацией? Сохраните вход, результат и случаи ошибок. Проверка на имитации хоста подтверждает ограниченный обмен, но не подключение к реальной учётной записи.
4. Настоящий хост или IDE. Загрузила ли интеграцию нужная среда и использовала ли её? Зафиксируйте среду, настройку и наблюдение. Проверка библиотеки этого шага не подтверждает.
5. Чтение из названного тестового контура поставщика. Авторизовался ли нужный клиент в конкретном тестовом контуре и получил ли ожидаемую нечувствительную запись? Укажите разрешённый объект, ответ и сверку с ожидаемым. Это доказательство одного ограниченного чтения, а не всех операций и внедрений у клиентов.

Эти вопросы удобно проходить последовательно, хотя свидетельства могут появиться в другом порядке. Оценивайте каждую строку отдельно. Изолированная проверка, записанная 30 октября 2026 года, на имитации хоста охватывала четыре инструмента каталога только для чтения. Она не проверила полный путь через IDE или CLI, реальную авторизацию поставщика и чтение его данных.

Упражнение: разберите пять вымышленных записей

Для условного поиска товара создайте таблицу: запись, ступень, критерий приёмки, результат и следующее доказательство. Возьмите такие придуманные примеры:

• Карточка описывает поиск товара. Ступень 1: засчитайте метаданные при наличии источника и даты. Далее изучите реализацию.
• Определение локального инструмента содержит функцию поиска. Ступень 2: засчитайте наличие, если можно проверить версию и определение. Далее вызовите функцию через клиент.
• Клиент обращается к имитации и получает ожидаемый учебный товар. Ступень 3: засчитайте обмен при совпадении запроса и ответа. Далее проверьте нужный хост.
• Нужная IDE загружает инструмент и показывает учебный результат. Ступень 4: засчитайте путь через среду при записи реального вызова. Далее подготовьте разрешённое чтение тестового контура.
• Названный тестовый контур возвращает ожидаемый вымышленный товар через нужный клиент. Ступень 5: засчитайте чтение, если объект и ответ соответствуют заранее записанному критерию. Другие операции проверяйте отдельно.

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

Для решений о доступе прочитайте практику проверки разрешений. Руководство по Odoo описывает конкретный предлагаемый путь; примените те же различия к фактической среде. Карточки доказательств помогут сопоставить критерии, не выдавая учебный результат за результат клиента.

Каталог кратко обозначает общую готовность. Эта таблица подробнее разделяет проверки клиентской библиотеки, хоста и поставщика; она не заменяет статус каталога.