--- title: "Тестов пакет за резолвери: DPP-връзките да бъдат надеждно проверени преди пускане в продукция — qr3.app Blog" description: "Стабилният тестов пакет на GS1 позволява проверка на Resolver 1.2. Така можете да тествате пренасочвания, набори от връзки, CORS, езици и грешки преди пускане в продукция." canonical: "https://qr3.app/bg/blog/gs1-resolver-test-suite-dpp-links/" lang: "bg" robots: "index,follow,max-image-preview:large,max-snippet:-1" --- # Тестов пакет за резолвери: DPP-връзките да бъдат надеждно проверени преди пускане в продукция — qr3.app Blog > Стабилният тестов пакет на GS1 позволява проверка на Resolver 1.2. Така можете да тествате пренасочвания, набори от връзки, CORS, езици и грешки преди пускане в продукция. Canonical: [← Блог](/bg/blog/) [Ръководства](/bg/blog/category/tutorials/) 9 август 2026 г. 6 мин четене [Ръководства](/bg/blog/category/tutorials/) [gs1-resolver](/bg/blog/tag/gs1-resolver/)[gs1-digital-link](/bg/blog/tag/gs1-digital-link/)[linkset](/bg/blog/tag/linkset/)[konformitaetstests](/bg/blog/tag/konformitaetstests/)[dpp](/bg/blog/tag/dpp/) # Тестов пакет за резолвери: DPP-връзките да бъдат надеждно проверени преди пускане в продукция Стабилният тестов пакет на GS1 позволява проверка на Resolver 1.2. Така можете да тествате пренасочвания, набори от връзки, CORS, езици и грешки преди пускане в продукция. от **QR3 Redaktion** ![Тестов пакет за резолвери: DPP-връзките да бъдат надеждно проверени преди пускане в продукция](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/gs1-resolver-test-suite-dpp-links/hero.png) QR код, който отваря страница в браузъра, все още не доказва надежден резолвер. За резолвер на технологията за идентификатори на GS1 е важно цялостното HTTP поведение: Какви идентификатори се приемат? Коя цел е стандартната? Предоставя ли услугата машинночетим набор от връзки? Работи ли достъпът от браузър през други домейни? И съобщават ли невалидните или недостъпните заявки правилната грешка? От **16 януари 2026 г.** е наличен [GS1-Conformant Resolver Standard 1.2.0](https://ref.gs1.org/standards/resolver/archive). Свързаният с него [публичен тестов пакет на GS1](https://ref.gs1.org/test-suites/resolver/) вече се счита за стабилен; кодът му е актуализиран за последно на **29 юни 2026 г.** Така една абстрактна норма може да се превърне в конкретен приемателен тест. В тази статия е показано какво трябва да се провери преди пускане в продукция, къде са границите на тестовия пакет и какви доказателства трябва да влязат в техническото одобрение. ## Успешното сканиране е само началото Един GS1 Digital Link съдържа GS1 идентификатор в HTTPS URI. Резолверът свързва този идентификатор с един или повече ресурси, например продуктова страница, ръководство, информационен лист или програмен интерфейс. Нашата основна статия обяснява [резолвера за идентификатори на GS1 с пример на живо](https://qr3.app/de/blog/gs1-digital-link-resolver/). За пускане в продукция обаче не е достатъчно успешно стандартно пренасочване. [Стандартът за резолвери 1.2.0](https://ref.gs1.org/standards/resolver/) изисква, наред с другото, HTTPS, поддръжка на `GET`, `HEAD` и `OPTIONS`, Cross-Origin Resource Sharing (CORS), разпознаваема стандартна връзка и изход във формат набор от връзки. При `linkType=linkset` или заглавка Accept `application/linkset+json` резолверът не трябва да пренасочва. Вместо това той трябва да върне наличните типизирани връзки като самостоятелно представяне. Това разделение е важно: пътят през човешкия браузър може да работи, докато машинният достъп, езикът, типовете връзки или сценариите с грешки са неизправни. Точно такива отклонения остават невидими при обикновен тест със сканиране. ## Планът за приемане в седем стъпки ### 1. Определете представителни тестови URI Не започвайте с един-единствен примерен продукт. Съставете малка, версионирана тестова колекция: - поне един валиден идентификатор за всеки поддържан първичен ключ на GS1; - случай с GTIN без квалификатор; - случаи с партида или сериен номер, ако тази детайлност се поддържа; - синтактично невалиден идентификатор; - валиден, но непознат идентификатор; - познат идентификатор без заявения тип връзка. Стандартът позволява на един резолвер да поддържа само подмножество от първичните ключове на GS1. За всеки поддържан първичен ключ обаче неговите квалификатори и атрибути на данните трябва да се обработват изцяло. Затова тестовият набор трябва да съответства на действително декларираните възможности, а не на общо маркетингово твърдение. ### 2. Проверете стандартното пренасочване и методите Първо тествайте нормалното извикване без специални заглавки. Очаква се детерминирана стандартна връзка. Следват `HEAD` и `OPTIONS`: `HEAD` не трябва да използва различна логика за маршрутизиране от `GET`, а `OPTIONS` трябва да прави поддържаните методи разбираеми. Минимален ръчен тест изглежда така: ``` curl -sS -D - -o /dev/null \ "https://id.gs1.org/01/09506000134352" curl -sS -I \ "https://id.gs1.org/01/09506000134352" ``` Документирайте кода на състоянието, `Location`, заглавките за кеширане и броя на пренасочванията. Цикъл на пренасочване, случайна цел или път, който се различава според метода, е грешка при приемането, дори ако смартфонът в крайна сметка покаже страница. ### 3. Заявете набор от връзки вместо уебстраница Най-важната машинна проверка е наборът от връзки: ``` curl -sS \ -H "Accept: application/linkset+json" \ "https://id.gs1.org/01/09506000134352" ``` [RFC 9264](https://datatracker.ietf.org/doc/html/rfc9264) определя `application/linkset+json` като самостоятелно JSON представяне на множество типизирани уеб връзки. GS1 затяга изискванията: изходът трябва да преминава валидация спрямо [нормативната схема за набор от връзки за версия 1.2.0](https://ref.gs1.org/standards/resolver/1.2.0/linkset-schema). Затова проверявайте не само дали се връща JSON, но и типа на медията, схемата, абсолютните целеви URI, Anchor и релациите на връзките. Особено коварни са формално валидните, но съдържателно неправилни набори от връзки: например ръководство под типа връзка за продуктова информационна страница или цел, свързана със серия, на ниво GTIN. Затова валидацията на схемата и съдържателните тестови фикстури трябва да се използват заедно. ### 4. Контролирайте описанието на резолвера Съответстващият на стандарта резолвер предоставя машинночетимо описание на `/.well-known/gs1resolver`. То посочва, наред с другото, основата на резолвера и поддържаните първични ключове. Файлът трябва да преминава валидация спрямо [схемата на GS1 за файлове с описания на резолвери](https://ref.gs1.org/standards/resolver/1.2.0/description-file-schema). Този тест предотвратява често срещано несъответствие: услугата може да може повече или по-малко, отколкото твърди собственото ѝ описание. Затова включете в приемането както валидация на схемата, така и сравнение с реални тестови случаи. ### 5. Тествайте CORS и договарянето на съдържанието CORS не е удобна екстра. Стандартът го изисква, за да могат браузърните приложения да се обръщат към резолвера от различни домейни. Тествайте поне един разрешен браузърен Origin и пътя за предварителната заявка. Проверете също дали `Accept: application/linkset+json` и `linkType=linkset` дават съгласувани резултати. Добавете отрицателен тест за неподдържан тип медия. Услуга, която независимо от заглавката `Accept` винаги изпраща HTML, е достъпна за хора, но не е надеждно машинночетима. ### 6. Обхванете език, контекст и детайлност Стандартът предвижда `Accept-Language`, както и параметъра на заявката `context`, като средства за разграничаване между няколко подходящи връзки. Не всеки резолвер трябва да предлага всеки вариант. Ако се поддържат език или контекст, правилата за избор обаче трябва да бъдат възпроизводими. Затова тествайте наличен език, неналичен език и определена последователност за резервен избор. За GTIN, партида и сериен номер важи същият принцип: По-детайлен идентификатор може да взема предвид релевантни връзки от по-високи нива, без да размива съдържателното съответствие. Запишете очаквания брой връзки като фикстура; чистите snapshot тестове на последователността са твърде крехки. ### 7. Разграничете грешките семантично Кодовете за грешки са част от договора. Стандартът за резолвери предвижда за синтактично невалидни GS1 идентификатори съобщение с HTTP 400. Когато е заявен конкретен недостъпен тип връзка, пренасочването към стандартната цел не е правилният отговор. Тези случаи трябва да се разграничават от непознат, но синтактично валиден идентификатор. Проверете също дали отговорите за грешки не разкриват вътрешни подробности, токени или stack trace и дали `GET`, `HEAD` и браузърните заявки запазват една и съща семантика. Атрактивен HTML документ за грешка не може да компенсира неправилен код на състоянието. ## Как да използвате правилно тестовия пакет на GS1 Публичният тестов пакет приема URI на Digital Link и проверява поведението спрямо Resolver 1.2.0. Той е подходящ като независима проверка за димни тестове и съответствие. За одобрението запазвайте датата на теста, тествания URI, версията на стандарта, резултата и евентуално възпроизводимите случаи на грешка. Пакетът обаче не заменя собствената регресия. GS1 изрично посочва, че понастоящем той не проверява компресията. Ако резолверът ви обработва EPC двоични низове или други компресирани форми, ще са ви нужни отделни тестови вектори. Публичният пакет също не познава вашите съдържателни типове връзки, нито изискванията ви за оторизация, мултитенантност или наличност. Затова надеждният процес комбинира три нива: 1. публичният пакет на GS1 като външна проверка за съответствие; 2. тестове на схемите за набора от връзки и описанието на резолвера в CI; 3. собствени end-to-end тестове за реални идентификатори, роли, езици и откази. ## Какво трябва да съдържа доказателството за одобрение Приемането може да се повтори едва когато резултатът не само се вижда в браузъра, но и е документиран. Доказателството за одобрение трябва най-малкото да съдържа версията на стандарта и пакета, момента на теста, целевата среда, тестовите URI, очакваните типове връзки, HTTP резултатите, валидацията на схемата, проверката на CORS и известните изключения. Автоматизирайте стабилните части в CI, но преди всяка съществена промяна на резолвера извършвайте целенасочено външно изпълнение спрямо публичния пакет. Така „QR кодът се отваря“ се превръща в проверимо твърдение за идентичността, маршрутизирането и машинночетимата продуктова информация. ## Източници - [GS1-Conformant Resolver Standard 1.2.0](https://ref.gs1.org/standards/resolver/) - [Архив на стандарта за резолвери на GS1 – публикуван на 16 януари 2026 г.](https://ref.gs1.org/standards/resolver/archive) - [GS1 Digital Link Resolver Test Suite – кодът е актуализиран за последно на 29 юни 2026 г.](https://ref.gs1.org/test-suites/resolver/) - [Артефакти и нормативни схеми за GS1 Resolver 1.2.0](https://ref.gs1.org/standards/resolver/artefacts) - [IETF RFC 9264 – Linkset: Media Types and a Link Relation Type for Link Sets](https://datatracker.ietf.org/doc/html/rfc9264) ## Свързани статии - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/dpp-battery-passport-2027-20260715/hero.png) Новини от бранша BatteryPass-Ready стартира тестова среда за цифровия паспорт на батерията На 24 юни 2026 г. консорциумът BatteryPass-Ready стартира публична тестова среда за цифровия паспорт на батерията с оглед на задължението на ЕС от февруари 2027 г.](/bg/blog/dpp-battery-passport-2027-20260715/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/sector-20260713/hero.png) Новини от бранша Дигитален паспорт на батерията 2027: Какво трябва да знаят производителите сега Уебинари, инструменти с отворен код и нови стандарти: паспортът на батерията на ЕС набира скорост. Преглед на състоянието през юли 2026 г. и откритите въпроси до февруари 2027 г.](/bg/blog/sector-20260713/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/sector-20260711/hero.png) Новини от бранша Цифров паспорт на батерията 2026: тестови среди, стандарти и нерешени въпроси Какъв е напредъкът на индустрията по отношение на цифровия паспорт на батерията? Преглед на тестови среди, стандарти CEN/CENELEC, инструменти с отворен код и регулаторни решения през юли 2026 г.](/bg/blog/sector-20260711/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/regulation-20260708/hero.png) Регулации Дигитален паспорт на батерията 2027: какво всъщност изисква регламентът на ЕС От февруари 2027 г. Дигиталният паспорт на батерията става задължителен. Какво конкретно изисква (ЕС) 2023/1542, къде браншът все още не успява и кои стандарти вече са в сила.](/bg/blog/regulation-20260708/) [← Всички статии](/bg/blog/) [Започни безплатно](https://app.qr3.app/sign-up)