Протоколы тестирования — Комплексное тестирование — Тестирование программного средства
Протоколы по каждому тесту должны содержать информацию, достаточную для повторения теста. Данная информация должна включать:
• план тестирования или технические требования (спецификацию) к тестированию, содержащие контрольные примеры (для каждого контрольного примера указаны его цели);
• все результаты, связанные с контрольными примерами, включая все ошибки, выявленные при выполнении теста;
• штат персонала, вовлеченного в тестирование.
Отчет о тестировании
В отчете о тестировании должны быть суммированы цели и результаты тестирования (описанные в протоколах тестирования для каждого теста). Отчет о тестировании должен иметь следующую структуру.
1. Обозначение продукта.
2. Вычислительные системы, использованные при тестировании (технические средства, программные средства и их конфигурация).
3. Использованные документы (включая их обозначения).
4. Результаты тестирования описания продукта, документации пользователя, программ и данных.
5. Перечень несоответствий требованиям.
6. Перечень несоответствий рекомендациям либо перечень не учтенных в продукте рекомендаций, либо формулировка того, что продукт не был протестирован на соответствие рекомендациям.
7. Дата окончания тестирования.
Дополнительное тестирование
Когда продукт, который уже был протестирован, тестируется повторно (с учетом результатов предыдущего тестирования), тогда выполняются следующие требования:
• все измененные части документов, функций и данных должны быть протестированы как новый продукт;
Источник
Результаты тестирования протокол анализ результатов
Что пишут в блогах
- Отчет по митапу от Контура в июне 2021
- Июньская лента: лучшее за месяц
- Коучинг и супервизия. Инструменты развития
- Рабочее место тестировщика/рабочее место на балконе
- Расписание курсов для QA от «Лаборатории Качества» на июль-август 2021
- QA-процессы: какие инструменты и как можно использовать в своей ежедневной работе
- Анонс митапа по тестированию от Контура
- Мигающие тесты
- Курс для начинающих тестировщиков ПОИНТ: когда мужу-тестировщику показываю, чему я научилась, он удивляется и гордится!
- Отзывы об онлайн-курсе «Английский для тестировщиков» от компании «Лаборатория Качества»
Онлайн-тренинги
Что пишут в блогах (EN)
- The waves of Agile – Full registration of the book launch webinar
- Working with Requirements
- Talking about Automation in Australia / New Zealand
- Testing Webhooks with JS – Part 2
- Agile-thougths July edition: Waves of Agile
- Learning while Testing
- Unboxing my new book: The waves of agile
- Testing Webhooks with JS
- The books arrived: The waves of Agile
- Social Programming Approaches
Разделы портала
Про инструменты
Автор: Сергей Бронников
Каждый раз, когда я встречаюсь с проектом, в котором без причины изобрели свой новый формат отчётов мне хочется сделать что-то ещё для популяризации существующих форматов. За последнее время таких случаев было несколько. В первый раз я добавил поддержку подсветки синтаксиса TAP в библиотеку highlight.js, потом добавил поддержку синтаксиса формата SubUnit. Ну и в последний раз после встречи с одним из таких проектов я собрал воедино всю информацию по этим форматам в одном месте и получилась небольшая книжка. Таким образом этот текст — мой крестовый поход против разножопицы с тестовыми результатами в разработке ПО 🙂
В наше время ни один серьёзный программный проект не обходится без тестирования. Тестирование может быть ручное и автоматизированное, компонентное и системное, регулярное и не очень, но оно должно быть. А если тестирование регулярное, то вместе с ним появляются отчёты о результатах тестирования. И чем больше ваш проект, тем больше у вас данных о проведенном тестировании. В современных проектах темпах темп разработки ПО настолько высокий, что некоторые продукты успевают релизиться несколько раз в неделю, а некоторые и несколько раз в день. При правильном подходе отчёты о тестировании могут принести много пользы при разработке. Из этой статьи вы узнаете какая польза от отчётов о результатах тестирования, какие форматы отчётов существуют и как навести порядок с хранением и анализом таких отчётов в вашем проекте.
Зачем вообще нужны отчёты?
В каких случаях вам может потребоваться хранение отчёта о выполненном тестировании:
- оценка текущего качества проекта на основе покрытия тестами и получение ответов на вопросы: Закончено ли тестирование? Готов ли продукт к релизу? С какой скоростью разработка сходится к релизу?
- получение статистики о частоте воспроизведения дефекта
- оценка эффективности тестов (насколько полезен тест и находит ли дефекты?)
- обмен данными между командами, если роли в команде разделены (например разработчики и тестировщики)
- стабильность тестов и функциональности в продукте (PASS/FAIL rate) с течением времени
К тому же данные о тестировании можно использовать для постоянного улучшения самого тестирования.
Обзор существующих форматов
Зачастую разработчики даже не задумываются о том, в каком формате тесты сохраняют отчёты. Если это простые тесты, то достаточно вывода в формате PASS/FAIL. Если это функциональные тесты, то такой информации становится недостаточно, потому что нужно сохранять логи, тайминги и другие данные о выполнении теста. Хорошо, если используется тестовый фреймворк, в котором есть поддержка одного из распространённых форматов. А если нет, то в мире появляется ещё один формат для хранения результатов тестирования.
Благодаря изобретательности инженеров в мире разработки ПО существует множество форматов отчётов. Но одни получили большее распространение, чем другие. Все форматы можно поделить на две категории:
- закрытые форматы, изобретённые компаниями для своих коммерческих продуктов
- открытые форматы
Это может показаться удивительным, но открытость поспособствовала распространению форматов из второй категории. Как это получилось выяснить? Я проанализировал полсотни наиболее распространённых открытых проектов и получил следующие данные: 24 проекта хранят тестовые результаты и эти данные доступны публично, половина проектов если и использует какой-то формат для тестовых отчётов, то это один из трёх форматов: TAP, JUnit и SubUnit.
| Формат | Количество проектов |
| TAP | 19 |
| JUnit | 8 |
| SubUnit | 3 |
| Собственный | 29 |
А что с популярностью этих же форматов в коммерческих проектах? Результаты опроса об использовании форматов тестовых данных в разработке коммерческого ПО (36 голосов):
- TAP — 3%
- JUnit — 58%
- SubUnit — 3%
- Другой формат — 36%
Вообще в природе помимо форматов TAP, JUnit, SubUnit существуют и другие форматы, но я их не буду здесь рассматривать и приведу список только в качестве информационной справки: DejaGnu, Selenium, TAPOUT, Microsoft Test, HP QuickTest Professional, IBM Rational Functional Tester, Gallio Test Report, Parasoft C/C++test, Ranorex, TestRail.
Теперь подробнее о каждом из трёх форматов.
Test Anything Protocol (TAP)
Самый старый формат для представления результатов тестирования. По сути lingua franca для тестирования [2]. Формат был создан для тестирования первой версии интерпретатора Perl в 1987 году [4]. Позднее Tim Bunce и Andreas König написали модуль Test::Harness, что позволило использовать формат для тестирования модулей Perl. Сейчас формат имеет поддержку не только в Perl, но и в других языках программирования [3] и фреймворках для тестирования [1]. В 2008 году на конференции YAPC::Europe была предпринята попытка разработать IETF стандарт для TAP, но эта попытка не увенчалась успехом. Но есть текстовое описание формата на сайте testanything.org, а модули TAP::Spec::Parser и TAP::Parser::Grammar считаются референсной реализацией TAP.
Пример вывода результатов теста в формате TAP:
# Hardware architecture: x86_64
# Timestamp: 2016-06-16 06:23 (GMT+1)
ok 1 — zdtm/static/conntracks # SKIP manual run only
ok 2 — zdtm/static/maps03 # SKIP manual run only
ok 3 — zdtm/static/mlock_setuid
ok 4 — zdtm/static/groups
ok 5 — zdtm/static/maps05
ok 6 — zdtm/static/pdeath_sig
ok 7 — zdtm/static/xids00
ok 8 — zdtm/static/proc-self
ok 9 — zdtm/static/file_fown
ok 10 — zdtm/static/eventfs00
ok 11 — zdtm/static/uptime_grow # SKIP manual run only
ok 12 — zdtm/static/signalfd00
ok 13 — zdtm/static/inotify_irmap
ok 14 — zdtm/static/fanotify00
ok 15 — zdtm/static/session00
ok 16 — zdtm/static/rlimits00
ok 17 — zdtm/static/maps04
ok 18 — zdtm/static/pty03
ok 19 — zdtm/static/pty02
Пример отчёта с дополнительными полями:
not ok 1 Wrong length
time: 2011-02-01 00:09:01-07
SubUnit
SubUnit является потоковым форматом. Изначально был разработан в 2005 году Робертом Коллинсом году для юнит-тестирования. Для SubUnit доступны утилиты для анализа результатов (subunit-stats, subunit-ls и т.д.) и библиотеки для Python, C, C++ и Shell. Формат активно используется в тестировании компонентов проекта OpenStack, Linux дистрибутива Ubuntu и Samba. Есть две версии формата: первая версия хранит результаты в текстовом представлении, вторая в двоичном. Для обоих версий доступна подробная спецификация формата.
Пример вывода результатов теста в формате SubUnit:
time: 2011-05-23 22:49:38.856075Z
Traceback (most recent call last): File «/media/windows/dev/java/qaworkspace/pythonnosetests/src/mytest.py», line
11, in runTest self.assertEqual(len(s), 4, ‘Wrong length’) AssertionError: Wrong length
JUnit
xUnit — это собирательное название семейства фреймворков для модульного тестирования, структура и функциональность которых основана на SUnit, предназначавшегося для языка программирования Smalltalk. SUnit, разработанный Кентом Беком в 1998 году получил широкую популярность и был адаптирован для множества других языков. Названия фреймворков этого семейства образованы аналогично «SUnit», обычно заменяется буква «S» на первую букву (или несколько первых) в названии предполагаемого языка («JUnit» для Java, «NUnit» для программной платформы .NET и т. д.). Несмотря на общие корни форматы для всех фреймворков основаны на XML, но структура может отличаться (см. xunit-plugin).
Пример вывода результатов теста в формате JUnit:
message=»not ok 1 — inet allow all»>
message=»not ok 2 — inet allow unix»>
message=»not ok 4 — inet deny unix»>
Плюсы и минусы разных форматов
Несмотря на то, что все три формата создавались для одной цели — юнит-тестирования, они имеют различия. В таблице ниже проводится сравнение эти форматов.
Нет (несмотря на то, что форматы
тестовых отчётов всех фремйворков JUnit
похожи друг на друга, эти форматы имеют отличия)
Perl, Python, PHP, Java, C, C++, C#, Lua, Shell, Ruby,
Javascript, Pascal, PostgreSQL, Haskell, Lisp, Forth и другие
Есть референсная реализация формата в Perl
модуле Test::Harness , также была попытка разработать
Описание обоих версий
Официального описания стандарта
Да, можно добавлять
Однозначно можно сказать, что даже если у вас сейчас не стоит цели анализа результатов и разделения ролей в разработке, то имеет смысл не изобретать колесо и использовать существующие форматы для отчётов. В большинстве случаев их более чем достаточно для отчётов, а поддержка каждого из них есть во всех популярных языках программирования и добавление их поддержки не потребует много времени. Для тех, кому нужен анализ результатов и в чьих проектах разделяются роли предлагаю перейти к следующей части статьи.
Инструменты для хранения и анализа результатов в тестировании ПО
Зачастую тестирование встраивают в процесс разработки с помощью инструментов непрерывной интеграции (Jenkins CI, BuildBot, Travis CI, Teamcity и т.д.) и их же используют для анализа результатов. Мой опыт показывает, что отдельные сервисы хранения и анализа результатов с возможностью интеграции с системами CI удобнее, чем плагин в одной из них. Другие опытные тестировщики это подтверждают. Хотя я понимаю, что эти два случая не показательны 🙂
В таблице перечислены системы для анализа отчётов о тестировании в одном из трёх стандартных форматов.
Формат: TAP (Test Anything Protocol).
Форматы: JUnit, TAP (Test Anything Protocol).
Расширение для Jenkins CI.
Полезные ссылки
Список библиотек и инструментов с подсветкой синтаксиса стандартных тестовых форматов:
Источник
Результаты тестирования протокол анализ результатов
Что пишут в блогах
- Отчет по митапу от Контура в июне 2021
- Июньская лента: лучшее за месяц
- Коучинг и супервизия. Инструменты развития
- Рабочее место тестировщика/рабочее место на балконе
- Расписание курсов для QA от «Лаборатории Качества» на июль-август 2021
- QA-процессы: какие инструменты и как можно использовать в своей ежедневной работе
- Анонс митапа по тестированию от Контура
- Мигающие тесты
- Курс для начинающих тестировщиков ПОИНТ: когда мужу-тестировщику показываю, чему я научилась, он удивляется и гордится!
- Отзывы об онлайн-курсе «Английский для тестировщиков» от компании «Лаборатория Качества»
Онлайн-тренинги
Что пишут в блогах (EN)
- The waves of Agile – Full registration of the book launch webinar
- Working with Requirements
- Talking about Automation in Australia / New Zealand
- Testing Webhooks with JS – Part 2
- Agile-thougths July edition: Waves of Agile
- Learning while Testing
- Unboxing my new book: The waves of agile
- Testing Webhooks with JS
- The books arrived: The waves of Agile
- Social Programming Approaches
Разделы портала
Про инструменты
Автор: Сергей Бронников
Каждый раз, когда я встречаюсь с проектом, в котором без причины изобрели свой новый формат отчётов мне хочется сделать что-то ещё для популяризации существующих форматов. За последнее время таких случаев было несколько. В первый раз я добавил поддержку подсветки синтаксиса TAP в библиотеку highlight.js, потом добавил поддержку синтаксиса формата SubUnit. Ну и в последний раз после встречи с одним из таких проектов я собрал воедино всю информацию по этим форматам в одном месте и получилась небольшая книжка. Таким образом этот текст — мой крестовый поход против разножопицы с тестовыми результатами в разработке ПО 🙂
В наше время ни один серьёзный программный проект не обходится без тестирования. Тестирование может быть ручное и автоматизированное, компонентное и системное, регулярное и не очень, но оно должно быть. А если тестирование регулярное, то вместе с ним появляются отчёты о результатах тестирования. И чем больше ваш проект, тем больше у вас данных о проведенном тестировании. В современных проектах темпах темп разработки ПО настолько высокий, что некоторые продукты успевают релизиться несколько раз в неделю, а некоторые и несколько раз в день. При правильном подходе отчёты о тестировании могут принести много пользы при разработке. Из этой статьи вы узнаете какая польза от отчётов о результатах тестирования, какие форматы отчётов существуют и как навести порядок с хранением и анализом таких отчётов в вашем проекте.
Зачем вообще нужны отчёты?
В каких случаях вам может потребоваться хранение отчёта о выполненном тестировании:
- оценка текущего качества проекта на основе покрытия тестами и получение ответов на вопросы: Закончено ли тестирование? Готов ли продукт к релизу? С какой скоростью разработка сходится к релизу?
- получение статистики о частоте воспроизведения дефекта
- оценка эффективности тестов (насколько полезен тест и находит ли дефекты?)
- обмен данными между командами, если роли в команде разделены (например разработчики и тестировщики)
- стабильность тестов и функциональности в продукте (PASS/FAIL rate) с течением времени
К тому же данные о тестировании можно использовать для постоянного улучшения самого тестирования.
Обзор существующих форматов
Зачастую разработчики даже не задумываются о том, в каком формате тесты сохраняют отчёты. Если это простые тесты, то достаточно вывода в формате PASS/FAIL. Если это функциональные тесты, то такой информации становится недостаточно, потому что нужно сохранять логи, тайминги и другие данные о выполнении теста. Хорошо, если используется тестовый фреймворк, в котором есть поддержка одного из распространённых форматов. А если нет, то в мире появляется ещё один формат для хранения результатов тестирования.
Благодаря изобретательности инженеров в мире разработки ПО существует множество форматов отчётов. Но одни получили большее распространение, чем другие. Все форматы можно поделить на две категории:
- закрытые форматы, изобретённые компаниями для своих коммерческих продуктов
- открытые форматы
Это может показаться удивительным, но открытость поспособствовала распространению форматов из второй категории. Как это получилось выяснить? Я проанализировал полсотни наиболее распространённых открытых проектов и получил следующие данные: 24 проекта хранят тестовые результаты и эти данные доступны публично, половина проектов если и использует какой-то формат для тестовых отчётов, то это один из трёх форматов: TAP, JUnit и SubUnit.
| Формат | Количество проектов |
| TAP | 19 |
| JUnit | 8 |
| SubUnit | 3 |
| Собственный | 29 |
А что с популярностью этих же форматов в коммерческих проектах? Результаты опроса об использовании форматов тестовых данных в разработке коммерческого ПО (36 голосов):
- TAP — 3%
- JUnit — 58%
- SubUnit — 3%
- Другой формат — 36%
Вообще в природе помимо форматов TAP, JUnit, SubUnit существуют и другие форматы, но я их не буду здесь рассматривать и приведу список только в качестве информационной справки: DejaGnu, Selenium, TAPOUT, Microsoft Test, HP QuickTest Professional, IBM Rational Functional Tester, Gallio Test Report, Parasoft C/C++test, Ranorex, TestRail.
Теперь подробнее о каждом из трёх форматов.
Test Anything Protocol (TAP)
Самый старый формат для представления результатов тестирования. По сути lingua franca для тестирования [2]. Формат был создан для тестирования первой версии интерпретатора Perl в 1987 году [4]. Позднее Tim Bunce и Andreas König написали модуль Test::Harness, что позволило использовать формат для тестирования модулей Perl. Сейчас формат имеет поддержку не только в Perl, но и в других языках программирования [3] и фреймворках для тестирования [1]. В 2008 году на конференции YAPC::Europe была предпринята попытка разработать IETF стандарт для TAP, но эта попытка не увенчалась успехом. Но есть текстовое описание формата на сайте testanything.org, а модули TAP::Spec::Parser и TAP::Parser::Grammar считаются референсной реализацией TAP.
Пример вывода результатов теста в формате TAP:
# Hardware architecture: x86_64
# Timestamp: 2016-06-16 06:23 (GMT+1)
ok 1 — zdtm/static/conntracks # SKIP manual run only
ok 2 — zdtm/static/maps03 # SKIP manual run only
ok 3 — zdtm/static/mlock_setuid
ok 4 — zdtm/static/groups
ok 5 — zdtm/static/maps05
ok 6 — zdtm/static/pdeath_sig
ok 7 — zdtm/static/xids00
ok 8 — zdtm/static/proc-self
ok 9 — zdtm/static/file_fown
ok 10 — zdtm/static/eventfs00
ok 11 — zdtm/static/uptime_grow # SKIP manual run only
ok 12 — zdtm/static/signalfd00
ok 13 — zdtm/static/inotify_irmap
ok 14 — zdtm/static/fanotify00
ok 15 — zdtm/static/session00
ok 16 — zdtm/static/rlimits00
ok 17 — zdtm/static/maps04
ok 18 — zdtm/static/pty03
ok 19 — zdtm/static/pty02
Пример отчёта с дополнительными полями:
not ok 1 Wrong length
time: 2011-02-01 00:09:01-07
SubUnit
SubUnit является потоковым форматом. Изначально был разработан в 2005 году Робертом Коллинсом году для юнит-тестирования. Для SubUnit доступны утилиты для анализа результатов (subunit-stats, subunit-ls и т.д.) и библиотеки для Python, C, C++ и Shell. Формат активно используется в тестировании компонентов проекта OpenStack, Linux дистрибутива Ubuntu и Samba. Есть две версии формата: первая версия хранит результаты в текстовом представлении, вторая в двоичном. Для обоих версий доступна подробная спецификация формата.
Пример вывода результатов теста в формате SubUnit:
time: 2011-05-23 22:49:38.856075Z
Traceback (most recent call last): File «/media/windows/dev/java/qaworkspace/pythonnosetests/src/mytest.py», line
11, in runTest self.assertEqual(len(s), 4, ‘Wrong length’) AssertionError: Wrong length
JUnit
xUnit — это собирательное название семейства фреймворков для модульного тестирования, структура и функциональность которых основана на SUnit, предназначавшегося для языка программирования Smalltalk. SUnit, разработанный Кентом Беком в 1998 году получил широкую популярность и был адаптирован для множества других языков. Названия фреймворков этого семейства образованы аналогично «SUnit», обычно заменяется буква «S» на первую букву (или несколько первых) в названии предполагаемого языка («JUnit» для Java, «NUnit» для программной платформы .NET и т. д.). Несмотря на общие корни форматы для всех фреймворков основаны на XML, но структура может отличаться (см. xunit-plugin).
Пример вывода результатов теста в формате JUnit:
message=»not ok 1 — inet allow all»>
message=»not ok 2 — inet allow unix»>
message=»not ok 4 — inet deny unix»>
Плюсы и минусы разных форматов
Несмотря на то, что все три формата создавались для одной цели — юнит-тестирования, они имеют различия. В таблице ниже проводится сравнение эти форматов.
Нет (несмотря на то, что форматы
тестовых отчётов всех фремйворков JUnit
похожи друг на друга, эти форматы имеют отличия)
Perl, Python, PHP, Java, C, C++, C#, Lua, Shell, Ruby,
Javascript, Pascal, PostgreSQL, Haskell, Lisp, Forth и другие
Есть референсная реализация формата в Perl
модуле Test::Harness , также была попытка разработать
Описание обоих версий
Официального описания стандарта
Да, можно добавлять
Однозначно можно сказать, что даже если у вас сейчас не стоит цели анализа результатов и разделения ролей в разработке, то имеет смысл не изобретать колесо и использовать существующие форматы для отчётов. В большинстве случаев их более чем достаточно для отчётов, а поддержка каждого из них есть во всех популярных языках программирования и добавление их поддержки не потребует много времени. Для тех, кому нужен анализ результатов и в чьих проектах разделяются роли предлагаю перейти к следующей части статьи.
Инструменты для хранения и анализа результатов в тестировании ПО
Зачастую тестирование встраивают в процесс разработки с помощью инструментов непрерывной интеграции (Jenkins CI, BuildBot, Travis CI, Teamcity и т.д.) и их же используют для анализа результатов. Мой опыт показывает, что отдельные сервисы хранения и анализа результатов с возможностью интеграции с системами CI удобнее, чем плагин в одной из них. Другие опытные тестировщики это подтверждают. Хотя я понимаю, что эти два случая не показательны 🙂
В таблице перечислены системы для анализа отчётов о тестировании в одном из трёх стандартных форматов.
Формат: TAP (Test Anything Protocol).
Форматы: JUnit, TAP (Test Anything Protocol).
Расширение для Jenkins CI.
Полезные ссылки
Список библиотек и инструментов с подсветкой синтаксиса стандартных тестовых форматов:
Источник
Протокол испытаний: основные понятия
Протокол испытаний — это документ, составленный и выданный независимой лабораторией, имеющей соответствующую аккредитацию. Он составляется на основе результатов, полученных при исследовании образцов продукции. В протоколе должны быть указаны методы проведения испытаний, полученные результаты и конечная оценка качества.
Протокол испытаний — это документ, составленный и выданный независимой лабораторией, имеющей соответствующую аккредитацию. Он составляется на основе результатов, полученных при исследовании образцов продукции. В протоколе должны быть указаны методы проведения испытаний, полученные результаты и конечная оценка качества.
Сертификационные испытания должны включать всестороннее исследование образцов с помощью соответствующих методик и анализ предоставленной заявителем нормативной документации, позволяющей идентифицировать продукцию.
Данные протокола испытаний являются основанием для получения деклараций, свидетельств, сертификатов соответствия.
Ответственность за достоверность данных, полученных в результате анализа и занесенных в протокол испытаний, положена на лабораторию.
Результаты проводимых испытаний должны оставаться в ведении лаборатории. Для публикации данных протокола испытаний необходимо согласие заявителя и проводившей испытания лаборатории. Для полной уверенности в безопасности товара, допускается обращение в ряд лабораторий и проведение каждой из них независимого исследования и составления отдельного протокола.
Аккредитация лаборатории
К проведению сертификационных испытаний допускаются лаборатории, аккредитованные Федеральным агентством по техническому регулированию и метрологии Российской Федерации. Аккредитацию лабораторий проводят следующие официальные ведомства:
- Ростехнадзор;
- Росстандарт;
- Россвязь;
- Росреестр;
- Роспотребнадзор;
- Росатом;
- МЧС России.
Лаборатория может быть аккредитована для проведения испытаний как одного, так и разных видов продукции.
Для получения разрешения на проведение экспертных испытаний лаборатория должна быть оборудована соответствующим оборудованием, средствами контроля и измерений, необходимыми для тестирования продукции и установки степени ее соответствия международным и российским стандартам, требованиям технической документации или других нормативных документов.
Методики проведения испытаний
Основные цели проведения испытания:
- независимая оценка качественных и количественных характеристик образцов;
- определение степени соответствия продукции параметрам, заявленным производителем, и требованиям стандартов;
- идентификация и анализ прилагаемой технической документации.
Как правило, экспертной оценке подвергаются эксплуатационные показатели и безопасность продукции, особенности ее влияния на экологию и взаимодействие с различными внешними факторами.
Программы исследований должны соответствовать техническому заданию и типовым методикам проведения испытаний. Для анализа продукции, требующей нестандартной программы, могут быть разработаны новые методики, согласованные с органами сертификации или организациями, имеющими полномочия органа государственного надзора.
Независимо от выбранной методики проведения испытаний и типов применяемого оборудования, необходимо соблюдать ряд обязательных критериев: указание условий проведения исследований; составление перечня параметров, которые должны быть подвергнуты оценке в ходе анализа; утверждение перечня технических средств, необходимых для проведения измерений и контроля во время анализа.
Правила сертификации продукции
Для проведения экспертной оценки, заявитель должен предоставить образцы продукции и сопроводительную документацию, в том числе технические условия на данный вид продукции. После проведения анализа образцы продукции могут сохранять или изменять свои свойства, в зависимости от выбранной методики исследования. В случае выявления в ходе испытаний расхождения с заявленными в технической документации показателями, лаборатория должна уведомить об этом производителя в письменном виде.
Товары, ввозимые на территорию Российской Федерации, подпадают под действие Единых требований Таможенного союза России, Беларуси и Казахстана по проведению сертификации, действующих с 1 июля 2007 года. Сертификат и декларация соответствия включают в себя протокол испытаний, свидетельство о регистрации в Роспотребнадзоре, пожарный сертификат и ряд других документов.
Правила оформления протокола испытаний
В протоколе испытаний указывают следующую информацию:
- экспертную оценку сопроводительной документации, в том числе технической ее части;
- идентификацию продукции;
- указание методики проведения исследований;
- описание лабораторных тестов;
- результаты испытаний.
На основании данных протокола испытаний можно получить заключения эксперта по сертификации о соответствии продукции действующей нормативной документации, стандартов и технических условий.
Источник