Протоколы тестирования 8212 Комплексное тестирование 8212 Тестирование программного средства



Протоколы тестирования — Комплексное тестирование — Тестирование программного средства

Протоколы по каждому тесту должны содержать информа­цию, достаточную для повторения теста. Данная информация должна включать:

• план тестирования или технические требования (спецификацию) к тестированию, содержащие контрольные примеры (для каж­дого контрольного примера указаны его цели);

• все результаты, связанные с контрольными примерами, включая все ошибки, выявленные при выполнении теста;

• штат персонала, вовлеченного в тестирование.

Отчет о тестировании

В отчете о тестировании должны быть суммированы цели и результаты тестирования (описанные в протоколах тестирования для каждого теста). Отчет о тестировании должен иметь сле­дующую структуру.

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. Если это функциональные тесты, то такой информации становится недостаточно, потому что нужно сохранять логи, тайминги и другие данные о выполнении теста. Хорошо, если используется тестовый фреймворк, в котором есть поддержка одного из распространённых форматов. А если нет, то в мире появляется ещё один формат для хранения результатов тестирования.

Благодаря изобретательности инженеров в мире разработки ПО существует множество форматов отчётов. Но одни получили большее распространение, чем другие. Все форматы можно поделить на две категории:

  1. закрытые форматы, изобретённые компаниями для своих коммерческих продуктов
  2. открытые форматы

Это может показаться удивительным, но открытость поспособствовала распространению форматов из второй категории. Как это получилось выяснить? Я проанализировал полсотни наиболее распространённых открытых проектов и получил следующие данные: 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.

Теперь подробнее о каждом из трёх форматов.

Похожее:  Дополнительный налоговый контроль 2017

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:

<testcase name=»(init)» time=»0.180249929428101″ />

<testcase time=»0.00193119049072266″ name=»1 — inet allow all»>

message=»not ok 1 — inet allow all»><![CDATA[not ok 1 — inet allow all]]></failure>

<testcase name=»2 — inet allow unix» time=»0.00225496292114258″>

message=»not ok 2 — inet allow unix»><![CDATA[not ok 2 — inet allow unix]]></failure>

<testcase time=»0.00211286544799805″ name=»3 — inet deny all»></testcase>

<testcase name=»4 — inet deny unix» time=»0.00119209289550781″>

message=»not ok 4 — inet deny unix»><![CDATA[not ok 4 — inet deny unix]]></failure>

Плюсы и минусы разных форматов

Несмотря на то, что все три формата создавались для одной цели — юнит-тестирования, они имеют различия. В таблице ниже проводится сравнение эти форматов.

Нет (несмотря на то, что форматы

тестовых отчётов всех фремйворков 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. Если это функциональные тесты, то такой информации становится недостаточно, потому что нужно сохранять логи, тайминги и другие данные о выполнении теста. Хорошо, если используется тестовый фреймворк, в котором есть поддержка одного из распространённых форматов. А если нет, то в мире появляется ещё один формат для хранения результатов тестирования.

Благодаря изобретательности инженеров в мире разработки ПО существует множество форматов отчётов. Но одни получили большее распространение, чем другие. Все форматы можно поделить на две категории:

  1. закрытые форматы, изобретённые компаниями для своих коммерческих продуктов
  2. открытые форматы

Это может показаться удивительным, но открытость поспособствовала распространению форматов из второй категории. Как это получилось выяснить? Я проанализировал полсотни наиболее распространённых открытых проектов и получил следующие данные: 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:

<testcase name=»(init)» time=»0.180249929428101″ />

<testcase time=»0.00193119049072266″ name=»1 — inet allow all»>

message=»not ok 1 — inet allow all»><![CDATA[not ok 1 — inet allow all]]></failure>

<testcase name=»2 — inet allow unix» time=»0.00225496292114258″>

message=»not ok 2 — inet allow unix»><![CDATA[not ok 2 — inet allow unix]]></failure>

<testcase time=»0.00211286544799805″ name=»3 — inet deny all»></testcase>

<testcase name=»4 — inet deny unix» time=»0.00119209289550781″>

message=»not ok 4 — inet deny unix»><![CDATA[not ok 4 — inet deny unix]]></failure>

Плюсы и минусы разных форматов

Несмотря на то, что все три формата создавались для одной цели — юнит-тестирования, они имеют различия. В таблице ниже проводится сравнение эти форматов.

Нет (несмотря на то, что форматы

тестовых отчётов всех фремйворков 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. Ростехнадзор;
  2. Росстандарт;
  3. Россвязь;
  4. Росреестр;
  5. Роспотребнадзор;
  6. Росатом;
  7. МЧС России.

Лаборатория может быть аккредитована для проведения испытаний как одного, так и разных видов продукции.

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

Методики проведения испытаний

Основные цели проведения испытания:

  1. независимая оценка качественных и количественных характеристик образцов;
  2. определение степени соответствия продукции параметрам, заявленным производителем, и требованиям стандартов;
  3. идентификация и анализ прилагаемой технической документации.

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

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

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

Правила сертификации продукции

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

Товары, ввозимые на территорию Российской Федерации, подпадают под действие Единых требований Таможенного союза России, Беларуси и Казахстана по проведению сертификации, действующих с 1 июля 2007 года. Сертификат и декларация соответствия включают в себя протокол испытаний, свидетельство о регистрации в Роспотребнадзоре, пожарный сертификат и ряд других документов.

Правила оформления протокола испытаний

В протоколе испытаний указывают следующую информацию:

  1. экспертную оценку сопроводительной документации, в том числе технической ее части;
  2. идентификацию продукции;
  3. указание методики проведения исследований;
  4. описание лабораторных тестов;
  5. результаты испытаний.

На основании данных протокола испытаний можно получить заключения эксперта по сертификации о соответствии продукции действующей нормативной документации, стандартов и технических условий.

Источник

Adblock
detector