Ускоренные испытания агрегатов: РД 50-424-83 Методические указания. Надежность в технике. Ускоренные испытания. Основные положения

РД 50-424-83 Методические указания. Надежность в технике. Ускоренные испытания. Основные положения

ГОСУДАРСТВЕННЫЙ КОМИТЕТ СССР ПО СТАНДАРТАМ

МЕТОДИЧЕСКИЕ УКАЗАНИЯ

НАДЕЖНОСТЬ В ТЕХНИКЕ. УСКОРЕННЫЕ ИСПЫТАНИЯ.
ОСНОВНЫЕ ПОЛОЖЕНИЯ

 

РД 50-424-83

 

 

 

Москва

ИЗДАТЕЛЬСТВО СТАНДАРТОВ

1984

 

РАЗРАБОТАНЫ Государственным комитетом СССР по стандартам ИСПОЛНИТЕЛИ

В.Ф. Курочкин, А.И. Кубарев, Е.И. Бурдасов, И.З. Аронов, Ж.Н. Буденная, К.А. Криштоф, Н.А. Сачкова, Т.Н. Дельнова, А.И. Кусков, Р.В. Кугель, В.П. Важдаев, К.И. Кузьмин, Л.Я. Подольский, Л.П. Лозицкий, А.Н. Ветров, В.Ф. Лопшов, В.Н. Любушкина, В.К. Медвежникова

ВНЕСЕНЫ Государственным комитетом СССР по стандартам

УТВЕРЖДЕНЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 10 октября 1983 г. № 4903

 

РУКОВОДЯЩИЙ НОРМАТИВНЫЙ ДОКУМЕНТ

Утверждены Постановлением Госстандарта от 10 октября 1983 г. № 4903, срок введения установлен с 1 января 1985 г.

Настоящие методические указания распространяются на изделия машиностроения и приборостроения и устанавливают основные принципы ускорения испытаний на надежность, которые рекомендуется применять при разработке нормативно-методической (программы и методики) и технической (испытательное оборудование) основ системы государственных испытаний продукции по ГОСТ 25051.0-81.

Основные понятия в области ускоренных испытаний на надежность и их определения приведены в справочном приложении.

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

1.2. Установленные по п. 1.1 принципы ускорения должны применяться при разработке методов испытаний на надежность для включения в конструкторские (ПМ, ТУ) и нормативно-технические (стандарты вида ОТУ, ТУ, методов испытаний) документы на конкретные виды изделий.

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

1.4. План ускоренных испытаний должен быть построен с учетом погрешност

РД 50-424-83 Методические указания. Надежность в технике. Ускоренные испытания. Основные положения, РД от 10 октября 1983 года №50-424-83


РД 50-424-83



Дата введения 1985-01-01



РАЗРАБОТАНЫ Государственным комитетом СССР по стандартам

ИСПОЛНИТЕЛИ

В.Ф.Курочкин, А.И.Кубарев, Е.И.Бурдасов, И.З.Аронов, Ж.Н.Буденная, К.А.Криштоф, Н.А.Сачкова, Т.Н.Дельнова, А.И.Кусков, Р.В.Кугель, В.П.Важдаев, К.И.Кузьмин, Л.Я.Подольский, Л.П.Лозицкий, А.Н.Ветров, В.Ф.Лопшов, В.Н.Любушкина, В.К.Медвежникова

ВНЕСЕНЫ Государственным комитетом СССР по стандартам

УТВЕРЖДЕНЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 10 октября 1983 г. N 4903

ВВЕДЕНЫ ВПЕРВЫЕ


Настоящие методические указания распространяются на изделия машиностроения и приборостроения и устанавливают основные принципы ускорения испытаний на надежность, которые рекомендуется применять при разработке нормативно-методической (программы и методики) и технической (испытательное оборудование) основ системы государственных испытаний продукции по ГОСТ 25051.0-81.


Основные понятия в области ускоренных испытаний на надежность и их определения приведены в справочном приложении.

Содержание

1. ОБЩИЕ ПОЛОЖЕНИЯ

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

1.2. Установленные по п.1.1 принципы ускорения должны применяться при разработке методов испытаний на надежность для включения в конструкторские (ПМ, ТУ) и нормативно-технические (стандарты вида ОТУ, ТУ, методов испытаний) документы на конкретные виды изделий.

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

1.4. План ускоренных испытаний должен быть построен с учетом погрешности пересчета на нормальные условия испытаний, для которых в нормативно-технических документах на изделие заданы показатели надежности и требования к достоверности их контроля.

2. ОСНОВНЫЕ ПРИНЦИПЫ УСКОРЕНИЯ ОПРЕДЕЛИТЕЛЬНЫХ ИСПЫТАНИЙ

2.1. Различают ускоренные испытания в нормальном и форсированном режимах.

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

2.2.1. Уплотнение рабочих циклов осуществляют за счет:

сокращения перерывов в работе;


исключения холостых ходов;

устранения простоев;

сокращения времени на вспомогательные работы;

исключения нерабочих климатических периодов и т.п.

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

Коэффициент ускорения испытаний при уплотнении циклов

, (1)


где и — срок службы -гo объекта в выборке объема , упорядоченной по возрастанию, при нормальных и ускоренных испытаниях, соответственно;

— оператор математического ожидания.

Коэффициент пересчета показателей надежности, выраженных через календарную продолжительность, определяют по методу равных вероятностей (черт.1), который заключается в следующем. На стадии предварительных исследований берут две случайные выборки из одной и той же партии изделий. Одна из них испытывается в нормальных условиях, другая — в режиме ускоренных испытаний. В процессе испытаний фиксируются моменты отказа изделий. По полученным экспериментальным данным находится функция (см. черт.1) как геометрическое место точек, соответствующих равным квантилям . Чтобы убедиться, что функция будет инвариантом производства, необходимо повторить эксперимент на нескольких партиях. При наличии функции результаты ускоренных испытаний любой другой выборки приводятся к нормальным условиям.

Черт.1. Пересчет показателей надежности по методу равных вероятностей

Пересчет показателей надежности по методу равных вероятностей


и — срок службы при нормальных и ускоренных испытаниях, соответственно; — вероятность недостижения предельного состояния; — функция пересчета

Черт.1



Если же показатель надежности подсчитывают по наработке, то коэффициент пересчета равен единице.

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

Различают модели отказов, основанные на изучении закономерности изменения выходных параметров и статистики отказов изделия.

2.2.2.1 Параметрическая модель (вариант) представлена на черт.2. Здесь вероятность отказа определяется характером изменения выходного параметра . В начальный момент (=0) для выборки изделий объемом имеет место рассеивание выходного параметра относительно среднего значения . По мере увеличения наработки выходной параметр изменяется в соответствии с протеканием деградационных процессов. В общем случае существенное изменение параметра может начаться после некоторой наработки и протекать со случайной скоростью, изменяющейся во времени, . Измеряя выходной параметр изделий в момент усечения испытаний , можно получить плотность распределения значений выходного параметра , которая определяет вероятность выхода параметра за границу

ОСТ 26-07-2040-81 Арматура трубопроводная. Испытания ускоренные ресурсные. Общие требования к построению методик ускоренных испытаний
На главную | База 1 | База 2 | База 3
Поиск по реквизитамПоиск по номеру документаПоиск по названию документаПоиск по тексту документа
Искать все виды документовДокументы неопределённого видаISOАвиационные правилаАльбомАпелляционное определениеАТКАТК-РЭАТПЭАТРВИВМРВМУВНВНиРВНКРВНМДВНПВНПБВНТМ/МЧМ СССРВНТПВНТП/МПСВНЭВОМВПНРМВППБВРДВРДСВременное положениеВременное руководствоВременные методические рекомендацииВременные нормативыВременные рекомендацииВременные указанияВременный порядокВрТЕРВрТЕРрВрТЭСНВрТЭСНрВСНВСН АСВСН ВКВСН-АПКВСПВСТПВТУВТУ МММПВТУ НКММПВУП СНЭВУППВУТПВыпускГКИНПГКИНП (ОНТА)ГНГОСТГОСТ CEN/TRГОСТ CISPRГОСТ ENГОСТ EN ISOГОСТ EN/TSГОСТ IECГОСТ IEC/PASГОСТ IEC/TRГОСТ IEC/TSГОСТ ISOГОСТ ISO GuideГОСТ ISO/DISГОСТ ISO/HL7ГОСТ ISO/IECГОСТ ISO/IEC GuideГОСТ ISO/TRГОСТ ISO/TSГОСТ OIML RГОСТ ЕНГОСТ ИСОГОСТ ИСО/МЭКГОСТ ИСО/ТОГОСТ ИСО/ТСГОСТ МЭКГОСТ РГОСТ Р ЕНГОСТ Р ЕН ИСОГОСТ Р ИСОГОСТ Р ИСО/HL7ГОСТ Р ИСО/АСТМГОСТ Р ИСО/МЭКГОСТ Р ИСО/МЭК МФСГОСТ Р ИСО/МЭК ТОГОСТ Р ИСО/ТОГОСТ Р ИСО/ТСГОСТ Р ИСО/ТУГОСТ Р МЭКГОСТ Р МЭК/ТОГОСТ Р МЭК/ТСГОСТ ЭД1ГСНГСНрГСССДГЭСНГЭСНмГЭСНмрГЭСНмтГЭСНпГЭСНПиТЕРГЭСНПиТЕРрГЭСНрГЭСНсДИДиОРДирективное письмоДоговорДополнение к ВСНДополнение к РНиПДСЕКЕНВиРЕНВиР-ПЕНиРЕСДЗемЕТКСЖНМЗаключениеЗаконЗаконопроектЗональный типовой проектИИБТВИДИКИМИНИнструктивное письмоИнструкцияИнструкция НСАМИнформационно-методическое письмоИнформационно-технический сборникИнформационное письмоИнформацияИОТИРИСОИСО/TRИТНИТОсИТПИТСИЭСНИЭСНиЕР Республика КарелияККарта трудового процессаКарта-нарядКаталогКаталог-справочникККТКОКодексКОТКПОКСИКТКТПММ-МВИМВИМВНМВРМГСНМДМДКМДСМеждународные стандартыМетодикаМетодика НСАММетодические рекомендацииМетодические рекомендации к СПМетодические указанияМетодический документМетодическое пособиеМетодическое руководствоМИМИ БГЕИМИ УЯВИМИГКМММНМОДНМонтажные чертежиМос МУМосМРМосСанПинМППБМРМРДСМРОМРРМРТУМСанПиНМСНМСПМТМУМУ ОТ РММУКМЭКННАС ГАНБ ЖТНВННГЭАНДНДПНиТУНКНормыНормы времениНПНПБНПРМНРНРБНСПНТПНТП АПКНТП ЭППНТПДНТПСНТСНЦКРНЦСОДМОДНОЕРЖОЕРЖкрОЕРЖмОЕРЖмрОЕРЖпОЕРЖрОКОМТРМОНОНДОНКОНТПОПВОПКП АЭСОПНРМСОРДОСГиСППиНОСНОСН-АПКОСПОССПЖОССЦЖОСТОСТ 1ОСТ 2ОСТ 34ОСТ 4ОСТ 5ОСТ ВКСОСТ КЗ СНКОСТ НКЗагОСТ НКЛесОСТ НКМОСТ НКММПОСТ НКППОСТ НКПП и НКВТОСТ НКСМОСТ НКТПОСТ5ОСТНОСЭМЖОТРОТТПП ССФЖТПБПБПРВПБЭ НППБЯПВ НППВКМПВСРПГВУПереченьПиН АЭПисьмоПМГПНАЭПНД ФПНД Ф СБПНД Ф ТПНСТПОПоложениеПорядокПособиеПособие в развитие СНиППособие к ВНТППособие к ВСНПособие к МГСНПособие к МРПособие к РДПособие к РТМПособие к СНПособие к СНиППособие к СППособие к СТОПособие по применению СППостановлениеПОТ РПОЭСНрППБППБ-АСППБ-СППБВППБОППРПРПР РСКПР СМНПравилаПрактическое пособие к СППРБ АСПрейскурантПриказПротоколПСРр Калининградской областиПТБПТЭПУГПУЭПЦСНПЭУРР ГазпромР НОПРИЗР НОСТРОЙР НОСТРОЙ/НОПР РСКР СМНР-НП СРО ССКРазъяснениеРаспоряжениеРАФРБРГРДРД БГЕИРД БТРД ГМРД НИИКраностроенияРД РОСЭКРД РСКРД РТМРД СМАРД СМНРД ЭОРД-АПКРДИРДМРДМУРДПРДСРДТПРегламентРекомендацииРекомендацияРешениеРешение коллегииРКРМРМГРМДРМКРНДРНиПРПРРТОП ТЭРС ГАРСНРСТ РСФСРРСТ РСФСР ЭД1РТРТМРТПРУРуководствоРУЭСТОП ГАРЭГА РФРЭСНрСАСанитарные нормыСанитарные правилаСанПиНСборникСборник НТД к СНиПСборники ПВРСборники РСН МОСборники РСН ПНРСборники РСН ССРСборники ценСБЦПСДАСДАЭСДОССерияСЗКСНСН-РФСНиПСНиРСНККСНОРСНПСОСоглашениеСПСП АССП АЭССправочникСправочное пособие к ВСНСправочное пособие к СНиПСправочное пособие к СПСправочное пособие к ТЕРСправочное пособие к ТЕРрСРПССНССЦСТ ССФЖТСТ СЭВСТ ЦКБАСТ-НП СРОСТАСТКСТМСТНСТН ЦЭСТОСТО 030 НОСТРОЙСТО АСЧМСТО БДПСТО ВНИИСТСТО ГазпромСТО Газпром РДСТО ГГИСТО ГУ ГГИСТО ДД ХМАОСТО ДОКТОР БЕТОНСТО МАДИСТО МВИСТО МИСТО НААГСТО НАКССТО НКССТО НОПСТО НОСТРОЙСТО НОСТРОЙ/НОПСТО РЖДСТО РосГеоСТО РОСТЕХЭКСПЕРТИЗАСТО САСТО СМКСТО ФЦССТО ЦКТИСТО-ГК «Трансстрой»СТО-НСОПБСТПСТП ВНИИГСТП НИИЭССтП РМПСУПСССУРСУСНСЦНПРТВТЕТелеграммаТелетайпограммаТематическая подборкаТЕРТЕР Алтайский крайТЕР Белгородская областьТЕР Калининградской областиТЕР Карачаево-Черкесская РеспубликаТЕР Краснодарского краяТЕР Мурманская областьТЕР Новосибирской областиТЕР Орловской областиТЕР Республика ДагестанТЕР Республика КарелияТЕР Ростовской областиТЕР Самарской областиТЕР Смоленской обл.ТЕР Ямало-Ненецкий автономный округТЕР Ярославской областиТЕРмТЕРм Алтайский крайТЕРм Белгородская областьТЕРм Воронежской областиТЕРм Калининградской областиТЕРм Карачаево-Черкесская РеспубликаТЕРм Мурманская областьТЕРм Республика ДагестанТЕРм Республика КарелияТЕРм Ямало-Ненецкий автономный округТЕРмрТЕРмр Алтайский крайТЕРмр Белгородская областьТЕРмр Карачаево-Черкесская РеспубликаТЕРмр Краснодарского краяТЕРмр Республика ДагестанТЕРмр Республика КарелияТЕРмр Ямало-Ненецкий автономный округТЕРпТЕРп Алтайский крайТЕРп Белгородская областьТЕРп Калининградской областиТЕРп Карачаево-Черкесская РеспубликаТЕРп Краснодарского краяТЕРп Республика КарелияТЕРп Ямало-Ненецкий автономный округТЕРп Ярославской областиТЕРрТЕРр Алтайский крайТЕРр Белгородская областьТЕРр Калининградской областиТЕРр Карачаево-Черкесская РеспубликаТЕРр Краснодарского краяТЕРр Новосибирской областиТЕРр Омской областиТЕРр Орловской областиТЕРр Республика ДагестанТЕРр Республика КарелияТЕРр Ростовской областиТЕРр Рязанской областиТЕРр Самарской областиТЕРр Смоленской областиТЕРр Удмуртской РеспубликиТЕРр Ульяновской областиТЕРр Ямало-Ненецкий автономный округТЕРррТЕРрр Ямало-Ненецкий автономный округТЕРс Ямало-Ненецкий автономный округТЕРтр Ямало-Ненецкий автономный округТехнический каталогТехнический регламентТехнический регламент Таможенного союзаТехнический циркулярТехнологическая инструкцияТехнологическая картаТехнологические картыТехнологический регламентТИТИ РТИ РОТиповая инструкцияТиповая технологическая инструкцияТиповое положениеТиповой проектТиповые конструкцииТиповые материалы для проектированияТиповые проектные решенияТКТКБЯТМД Санкт-ПетербургТНПБТОИТОИ-РДТПТПРТРТР АВОКТР ЕАЭСТР ТСТРДТСНТСН МУТСН ПМСТСН РКТСН ЭКТСН ЭОТСНэ и ТЕРэТССЦТССЦ Алтайский крайТССЦ Белгородская областьТССЦ Воронежской областиТССЦ Карачаево-Черкесская РеспубликаТССЦ Ямало-Ненецкий автономный округТССЦпгТССЦпг Белгородская областьТСЦТСЦ Белгородская областьТСЦ Краснодарского краяТСЦ Орловской областиТСЦ Республика ДагестанТСЦ Республика КарелияТСЦ Ростовской областиТСЦ Ульяновской областиТСЦмТСЦО Ямало-Ненецкий автономный округТСЦп Калининградской областиТСЦПГ Ямало-Ненецкий автономный округТСЦэ Калининградской областиТСЭМТСЭМ Алтайский крайТСЭМ Белгородская областьТСЭМ Карачаево-Черкесская РеспубликаТСЭМ Ямало-Ненецкий автономный округТТТТКТТПТУТУ-газТУКТЭСНиЕР Воронежской областиТЭСНиЕРм Воронежской областиТЭСНиЕРрТЭСНиТЕРэУУ-СТУказУказаниеУказанияУКНУНУОУРврУРкрУРррУРСНУСНУТП БГЕИФАПФедеральный законФедеральный стандарт оценкиФЕРФЕРмФЕРмрФЕРпФЕРрФормаФорма ИГАСНФРФСНФССЦФССЦпгФСЭМФТС ЖТЦВЦенникЦИРВЦиркулярЦПИШифрЭксплуатационный циркулярЭРД
Показать все найденные Показать действующие Показать частично действующие Показать не действующие Показать проекты Показать документы с неизвестным статусом
Упорядочить по номеру документаУпорядочить по дате введения
Виды испытаний по продолжительности: нормальные, ускоренные, сокращенные.

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

По продолжительности испытания, которые проводятся лабораториями, бывают:

  • Нормальными. Такие испытания, исследования и измерения выполняются лабораторией в условиях  и с использованием методов,  которые обеспечивают получение нужного объема данных о свойствах и характеристиках объекта в тот же интервал времени, то и при его обычной эксплуатации. Например, это могут быть стендовые испытания техники или отдельных агрегатов на надежность.
  • Ускоренными. При проведении таких испытаний в лаборатории создаются условия и используются методы, которые позволяют получить нужный объем данных о свойствах и характеристиках объекта в сокращенный  по сравнении с нормальной эксплуатацией  срок.  Ускоренные испытания бывают сокращенными (без интенсификации условий, которые вызывают повреждения или отказы объекта) и форсированными (с интенсификацией условий, которые вызывают повреждения или отказы объекта).
  • Сокращенными. Это испытания, которые проводятся лабораторией по сокращенной программе для получения меньшего количества сведений об испытываемом объекте, нежели нормальные и ускоренные.

Испытательная лаборатория в своей деятельности прибегает к разным типам исследований, измерений и испытаний. Но в любом случае для их выполнения нужна аккредитация. Чтобы получить ее с минимальными финансовыми и временными затратами, обращайтесь в Nice Consulting: http://www.nice-consulting.ru.ru/services/akkreditacziya-laboratorij/.

Методы ускоренных испытаний — Студопедия

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

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

Форсированные испытания – ускоренные испытания с интенсификацией процессов, вызывающих отказы или повреждения. Результаты форсированных испытаний представительны для нормальных условий эксплуатации объекта тогда, когда имеются однозначные зависимости между воздействующим фактором и показателем надежности. Такие зависимости называю базовыми зависимостями.

Ускорение испытаний характеризуется коэффициентом ускорения – числом, показывающим, во сколько раз продолжительность ускоренных испытаний меньше продолжительности нормальных испытаний (по наработке или по календарному времени). Форсируемый в испытаниях параметр называется ускоряющим фактором испытаний.

На практике применяются различные методы ускоренных испытаний:

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


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

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


Метод одноступенчатого нагружения («доламывания») – метод испытаний, в котором объект подвергается повышенной нагрузке после длительной работы при нормальной нагрузке. Применение этого метода правомерно при условии корректности принципа суммирования повреждений. На практике этот режим реализуется следующим образом: после нормальных испытаний объект подвергают форсированным испытаниям до исчерпания ресурса работоспособного состояния. Оценивают остаточный ресурс при форсированном режиме. Сравнивают его с полным средним ресурсом объекта в форсированном режиме. Если этих сведений нет, то проводят испытания новых объектов в форсированном режиме для оценки среднего ресурса. Сравнение полного и остаточного ресурса позволяет оценить степень исчерпания ресурса в проведенных нормальных испытаниях объекта и его полный ресурс в условиях эксплуатации.

Метод интенсификации приработки – метод испытаний, в котором форсируется период приработки. Применим, когда объекту присущ длительный период приработки.

Метод эквивалентных испытаний – метод, в котором испытания проводятся при повышенных нагрузках с анализом влияния на надежность каждого вида нагружения.

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

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

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

Результаты ускоренных и нормальных испытаний должны быть сопоставимы, т.е. при идентичной природе отказа получаемые в этих испытаниях значения показателей надежности должны быть одинаковы. Например, равенство вероятности безотказной работы, получаемой в ускоренных (индекс «у») и нормальных (индекс «н») испытаниях, при экспоненциальном законе ее распределения означает выполнение равенства: ехр(-λнtн)=ехр(-λуtу). Получив в ускоренных испытаниях значение интенсивности отказов, можно оценить интенсивность отказов в нормальных условиях из соотношения λу=λнk, полагая при этом, что коэффициент ускорения испытаний по времени k=tн/tу при выбранных нагрузках эквивалентен коэффициенту ускорения испытаний по показателю надежности (вероятности безотказной работы).

Основной вопрос планирования ускоренных испытаний заключается в наличии базовой зависимости, отражающей влияние воздействующего фактора или нагрузки на показатель надежности. Источниками базовых зависимостей могут быть доступные сведения об аналогах. Если таковых нет, то для нахождения базовой зависимости проводятся исследовательские испытания в требуемом диапазоне изменения параметров испытаний. Следующий шаг – выбор ускоряющего фактора и режима ускоренных испытаний. В любом случае при планировании и проведении ускоренных испытаний учитываются результаты всех видов испытаний, проведенных при разработке и постановке на производство данного изделия.

Основное условие при выборе ускоряющего фактора – неизменность по сравнению с нормальными условиями физико-химических процессов, влияющих на надежность. Ускоряющий фактор должен хорошо контролироваться, легко меняться и воспроизводиться. Чаще всего этим требованиям удовлетворяет повышенная температура. Например: При отказах под воздействием термоактивируемых процессов средняя интенсивность отказов (и средняя наработка до отказа тоже) зависит от температуры по закону Аррениуса: λ=λ0ехр(-Е/kТ). Или, общепринятая зависимость длительной прочности от температуры Т и напряжения σ при сроке службы более 100 тыс. часов имеет вид: Тр=аТ2σ-nехр(b-сσ).

Планирование ускоренных контрольных испытаний основывается на проверке гипотез по критерию Неймана – Пирсона. При абсолютной уверенности в правильности и достоверности базовой зависимости нормативы в ускоренных испытаниях можно найти простым пересчетом установленного норматива (для нормальных условий) на условия форсированных по определяющему параметру испытаний. Однако это идеальный случай, не реализующийся на практике. Неабсолютная точность базовой зависимости увеличивает неопределенность результата ускоренных испытаний с точки зрения рисков неправомерного принятия гипотез. Существуют процедуры вычисления рисков в ускоренных испытаниях, соответствующих нормативным для нормальных условий. В объеме настоящего курса они не рассматриваются.

Ускоренные испытания — это… Что такое Ускоренные испытания? 
Ускоренные испытания

150. Ускоренные испытания

Коррозионные испытания, проводимые в условиях, близких к эксплуатационным, но дающие результаты в более короткий срок

60. Ускоренные испытания

E. Accelerated test

F. Essais accélerés

Испытания, методы и условия проведения которых обеспечивают получение необходимой информации о характеристиках свойств объекта в более короткий срок, чем при нормальных испытаниях

Смотри также родственные термины:

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

3.1.5 Остальные термины — по ГОСТ 27674.

10.7. Ускоренные испытания на надежность

Accelerated test

Лабораторные (стендовые) испытания, методы и условия проведения которых обеспечивают получение информации о надежности в более короткий срок, чем при нормальных испытаниях

Словарь-справочник терминов нормативно-технической документации. academic.ru. 2015.

  • ускоренное старение
  • ускоренные испытания на износостойкость

Смотреть что такое «Ускоренные испытания» в других словарях:

  • ускоренные испытания — Испытания, методы и условия проведения которых обеспечивают получение необходимой информации о характеристиках свойств объекта в более короткий срок, чем при нормальных испытаниях. [ГОСТ 16504 81] Тематики испытания и контроль качества продукции… …   Справочник технического переводчика

  • Ускоренные испытания — Accelerated testing Ускоренные испытания. Применяются для материалов или их соединений с использованием тех же механизмов отказа, как ожидается и в рабочих условиях, но в значительно более короткий промежуток времени. Механизм отказа ускоряется… …   Словарь металлургических терминов

  • ускоренные испытания — spartieji bandymai statusas T sritis Standartizacija ir metrologija apibrėžtis Bandymai, kuriuos atliekant reikiama informacija apie objekto savybių parametrus gaunama sparčiau negu normaliaisiais bandymais. atitikmenys: angl. accelerated test;… …   Penkiakalbis aiškinamasis metrologijos terminų žodynas

  • ускоренные испытания (в коррозионных испытаниях) — ускоренные испытания Коррозионные испытания, проводимые в условиях, близких к эксплуатационным, но дающие результаты в более короткий срок [ГОСТ 5272 68] Тематики коррозия металлов …   Справочник технического переводчика

  • ускоренные испытания на коррозионную стойкость — Метод испытания, разработанный для того, чтобы приблизительно, в короткий промежуток времени смоделировать и оценить результат воздействия тех или иных рабочих условий, имеющих место при нормальной долгосрочной эксплуатации. [http://sl3d.ru/o… …   Справочник технического переводчика

  • ускоренные испытания на надежность — Лабораторные (стендовые) испытания, методы и условия проведения которых обеспечивают получение информации о надежности в более короткий срок, чем при нормальных испытаниях. [ГОСТ 27.002 89] Тематики надежность, основные понятия EN accelerated… …   Справочник технического переводчика

  • Ускоренные испытания на коррозионную стойкость — Accelerated corrosion test Ускоренные испытания на коррозионную стойкость. Метод испытания, разработанный для того, чтобы приблизительно, в короткий промежуток времени, смоделировать и оценить результат воздействия тех или иных рабочих условий,… …   Словарь металлургических терминов

  • ускоренные испытания на износостойкость — 3.1.4 ускоренные испытания на износостойкость: Испытания, методы и условия проведения которых обеспечивают получение необходимой информации об износостойкости элементов изделия в более короткие сроки, чем в предусмотренных условиях и режимах… …   Словарь-справочник терминов нормативно-технической документации

  • Ускоренные испытания на надежность — 10.7. Ускоренные испытания на надежность Accelerated test Лабораторные (стендовые) испытания, методы и условия проведения которых обеспечивают получение информации о надежности в более короткий срок, чем при нормальных испытаниях Источник: ГОСТ… …   Словарь-справочник терминов нормативно-технической документации

  • ускоренные испытания на надежность — spartieji patikimumo bandymai statusas T sritis Standartizacija ir metrologija apibrėžtis Laboratoriniai patikimumo bandymai, kurių metodai ir atlikimo sąlygos leidžia objekto patikimumo parametrų vertes gauti sparčiau negu atliekant… …   Penkiakalbis aiškinamasis metrologijos terminų žodynas


1. РЕКОМЕНДАЦИИ ПО ОРГАНИЗАЦИИ И ПРОВЕДЕНИЮ КОМПЛЕКСНЫХ ИСПЫТАНИЙ НА НАДЕЖНОСТЬ

НАДЕЖНОСТЬ В ТЕХНИКЕ.

КОМПЛЕКСНЫЕ ИСПЫТАНИЯ ИЗДЕЛИЙ
МАШИНОСТРОЕНИЯ НА НАДЁЖНОСТЬ.

ОБЩИЕ ПОЛОЖЕНИЯ

 

Р 50-54-80-88

 

 

ГОСУДАРСТВЕННЫЙ КОМИТЕТ СССР ПО СТАНДАРТАМ
(ГОССТАНДАРТ СССР)

 

 

ВСЕСОЮЗНЫЙ НАУЧНО-ИССЛЕДОВАТЕЛЬСКИЙ ИНСТИТУТ
ПО НОРМАЛИЗАЦИИ В МАШИНОСТРОЕНИИ
(ВНИИНМАШ)

 

Утверждены

Приказом ВНИИНМАШ

№ 231 от 29.08.1988 г.

Москва 1988

РЕКОМЕНДАЦИИ

Надежность в технике.

Комплексные испытания изделий машиностроения на надежность. Общие положения

Р 50-54-80-88

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

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

В данных Р не рассматриваются специфические вопросы контроля показателей ремонтопригодности и сохраняемости, регламентированные ГОСТ 27.410-87.

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

1.2. Комплексные испытания на надежность проводят с целью:

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

определения соответствия показателей надежности требованиям, установленным в НТД;

Unit Testing — Основы тестирования программного обеспечения

UNIT TESTING — это уровень тестирования программного обеспечения, на котором тестируются отдельные модули / компоненты программного обеспечения. Цель состоит в том, чтобы проверить, что каждая единица программного обеспечения работает так, как задумано. Единица является самой маленькой тестируемой частью любого программного обеспечения. Обычно он имеет один или несколько входов и обычно один выход. В процедурном программировании единицей может быть отдельная программа, функция, процедура и т. Д. В объектно-ориентированном программировании наименьшей единицей является метод, который может принадлежать базовому / суперклассу, абстрактному классу или производному / дочернему классу.(Некоторые рассматривают модуль приложения как единое целое. Это не рекомендуется, поскольку в этом модуле, вероятно, будет много отдельных юнитов.) Для помощи в юнит-тестировании используются платформы юнит-тестирования, драйверы, заглушки и фиктивные / поддельные объекты. ,

Определение по ISTQB

  • модульное тестирование: См. тестирование компонентов.
  • тестирование компонентов: Тестирование отдельных компонентов программного обеспечения.

Метод модульных испытаний

Это выполняется с использованием метода тестирования белого ящика.

Когда это выполняется?

Unit-тестирование

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

Кто это выполняет?

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

Задачи модульного тестирования

    План модульных испытаний
    • Подготовить
    • Обзор
    • Переработка
    • Базовая линия
    • Модульные тестовые сценарии / сценарии
    • Подготовить
    • Обзор
    • Переработка
    • Базовая линия
    • Модульный тест
Преимущества модульного тестирования


  • Модульное тестирование повышает уверенность в изменении / поддержании кода.Если написаны хорошие модульные тесты, и если они запускаются каждый раз, когда изменяется какой-либо код, мы сможем быстро отследить любые дефекты, внесенные в результате изменения. Кроме того, если коды уже сделаны менее взаимозависимыми, чтобы сделать возможным модульное тестирование, непреднамеренное влияние изменений в любом коде будет меньше.
    • Коды
  • более пригодны для повторного использования. Чтобы сделать возможным модульное тестирование, коды должны быть модульными. Это означает, что коды легче использовать повторно.
  • Разработка быстрее. Как? Если у вас нет модульного тестирования, вы пишете свой код и выполняете этот нечеткий «тест разработчика» (вы устанавливаете некоторые контрольные точки, запускаете графический интерфейс, предоставляете несколько входных данных, которые, как мы надеемся, попали в ваш код, и надеются, что все готово.) Но если у вас есть модульное тестирование, вы пишете тест, пишете код и запускаете тест. Написание тестов занимает время, но время компенсируется меньшим количеством времени, которое требуется для выполнения тестов; Вам не нужно запускать графический интерфейс и предоставлять все эти входные данные. И, конечно же, модульные тесты более надежны, чем «тесты разработчика». Развитие в конечном итоге происходит быстрее. Как? Усилия, необходимые для поиска и устранения дефектов, обнаруженных в ходе модульного тестирования, значительно меньше по сравнению с усилиями, необходимыми для устранения дефектов, обнаруженных в ходе тестирования системы или приемочных испытаний.
  • Стоимость исправления дефекта, обнаруженного во время модульного тестирования, меньше по сравнению со стоимостью дефектов, обнаруженных на более высоких уровнях. Сравните стоимость (время, усилия, разрушение, унижение) дефекта, обнаруженного во время приемочного тестирования или когда программное обеспечение работает.
  • Отладка — это просто. Если тест не пройден, необходимо отладить только последние изменения. При тестировании на более высоких уровнях изменения, сделанные в течение нескольких дней / недель / месяцев, необходимо сканировать.
    • Коды
  • более надежны.Зачем? Я думаю, что нет необходимости объяснять это здравомыслящему человеку.

Советы по модульному тестированию

  • Найдите инструмент / рамки для вашего языка.
  • Не создавайте тестовых случаев для всего. Вместо этого сосредоточьтесь на тестах, которые влияют на поведение системы.
  • Изолировать среду разработки от тестовой среды.
  • Используйте тестовые данные, близкие к данным производства.
  • Прежде чем исправить дефект, напишите тест, который выявит дефект.Зачем? Во-первых, позже вы сможете обнаружить дефект, если не исправите его должным образом. Во-вторых, ваш тестовый набор стал более полным. В-третьих, вам, скорее всего, будет лень писать тест после того, как вы уже исправили дефект.
  • Напишите контрольные примеры, которые не зависят друг от друга. Например, если класс зависит от базы данных, не пишите случай, который взаимодействует с базой данных для проверки класса. Вместо этого создайте абстрактный интерфейс вокруг этого соединения с базой данных и реализуйте этот интерфейс с помощью фиктивного объекта.
  • Цель — покрыть все пути через блок. Обратите особое внимание на условия цикла.
  • Убедитесь, что вы используете систему контроля версий для отслеживания ваших тестовых сценариев.
  • В дополнение к написанию кейсов для проверки поведения, напишите кейсы, чтобы обеспечить производительность кода.
  • Проводите юнит-тесты непрерывно и часто.

Еще одна причина

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

  • Ошибка из-за ошибки в блоке 1?
  • Ошибка из-за ошибки в блоке 2?
  • Ошибка из-за ошибок в обоих блоках?
  • Ошибка из-за ошибки интерфейса между устройствами?
  • Ошибка из-за ошибки в тесте или тестовом примере?

Модульное тестирование часто игнорируется, но на самом деле это самый важный уровень тестирования.

,

Что, типы, инструменты, пример

Guru99
  • Главная

  • Испытание

      • Назад
      • Agile тестирование
      • BugZilla
      • Огурцы
      • База данных Тестирование
      • ETL Тестирование
      • Jmeter
      • JIRA
      • Назад
      • JUnit
      • LoadRunner
      • Ручное тестирование
      • Mobile Тестирование
      • Mantis
      • Почтальон
      • QTP
      • Назад
      • Quality Center (ALM)
      • RPA
      • SAP Тестирование
      • Селен
      • SoapUI
      • Test Management
      • TestLink

  • SAP

      • Назад
      • ABAP
      • APO
      • Новичок
      • Основа
      • Bods
      • BI
      • BPC
      • CO
      • Назад
      • CRM
      • Crystal Reports
      • КУКИШ
      • HANA
      • HR
      • MM
      • QM
      • Расчет заработной платы
      • 9000 9000
      • Apache
      • Android
      • AngularJS
      • ASP.Net
      • C
      • C #
      • C ++
      • CodeIgniter
      • СУБД
      • Назад
      • Java
      • JavaScript
      • JSP
      • Kotlin
      • M000 M000 js
      • Назад
      • Perl
      • PHP
      • PL / SQL
      • PostgreSQL
      • Python
      • ReactJS
      • Ruby & Rails
      • Scala
      • SQL5000
      • SQL000
      • UML
      • VB.Net
      • VBScript
      • Веб-сервисы
      • WPF

  • Необходимо учиться!

      • Назад
      • Учет
      • Алгоритмы
      • Blockchain
      • Бизнес-аналитик
      • Сложение Сайт
      • CCNA
      • Cloud Computing
      • COBOL
      • Compiler Design
      • Embedded Systems
      • Назад
      • Ethical Hacking
      • Excel Учебники
      • Go Программирование
      • IoT
      • ITIL
      • Дженкинс
      • MIS
      • Networking
      • Операционная система
      • Prep
      • Назад
      • PMP
      • Photoshop Управление
      • Проект
      • Отзывы
      • Salesforce
      • SEO
      • Разработка программного обеспечения
      • VBA

  • Big Data

      • Назад
      • AWS
      • BigData
      • Cassandra
      • Cognos
      • Складирование данных
      • 000000000 HBB000500040005000 HB
      • MongoDB
      • NiFi
      • OBIEE
      • Pentaho
      • Назад
      • Мощность BI
,
5 причин, почему вы должны использовать модульное тестирование Есть и противники, и сторонники такого рода тестирования. В этой статье я расскажу об основных преимуществах модульного тестирования и объясню, почему это так важно.

Что такое юнит-тесты? Зачем их писать? Как они могут помочь разработчикам и владельцам бизнеса? Ответы на эти и другие вопросы читайте дальше.

Давайте начнем с определения: модульное тестирование — это метод тестирования программного обеспечения, при котором тестируются «модули» — отдельные компоненты программного обеспечения.Разработчики пишут модульные тесты для своего кода, чтобы убедиться, что код работает правильно. Это помогает обнаруживать и защищать от ошибок в будущем.

Иногда разработчики пишут юнит-тесты сначала , а затем пишут код. Этот подход также известен как разработка через тестирование (TDD). В TDD требования превращаются в конкретные тестовые случаи, затем программное обеспечение улучшается, чтобы пройти новые тесты. При таком подходе не добавляется код, который, как было доказано, не отвечает определенным требованиям.Модульное тестирование похоже на то, что оно позволяет разработчикам изменять код, не влияя на функциональность других модулей или продукта в целом.

Юнит-тесты обычно пишутся в виде функций и проверяют значение и поведение этих функций в различных сценариях. Например, давайте представим функцию для деления двух чисел: разработчик решает следовать подходу TDD, сначала написав тест с вводом значений «4» и «2» (4, разделенных на 2) с ожидаемым «2» в результате.Другой пример: когда делитель равен нулю, мы не ожидаем, что функция выдаст значение — мы ожидаем, что она сгенерирует исключение. Можно ожидать, что функция уведомит некоторый компонент о попытке деления на ноль. Таким образом, мы тестируем два случая:

  1. В недопустимой ситуации функция уведомит нас о том, что мы делаем что-то не так (исключительная ситуация)
  2. Функция определит эту недопустимую ситуацию и зарегистрирует ее

Четыре преимущества устройства Тестирование

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

Любые ошибки легко и быстро обнаруживаются

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

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

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

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

Юнит-тестирование экономит время и деньги

В своей книге «Выполнение кода» Стив Макконнелл делится таблицей с ошибками и стоимостью их исправления на разных этапах жизненного цикла продукта.Из таблицы видно, что чем раньше обнаружен дефект, тем ниже стоимость его исправления.

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

Модульное тестирование

является неотъемлемой частью экстремального программирования

Модульное тестирование

является необходимым условием для методологии экстремального программирования.Экстремальное программирование — это, по сути, стратегия «тестируй все, что может быть сломано». Написание модульных тестов с этой методологией упрощает разработку и рефакторинг кода, облегчает интеграцию и создает живую документацию. Что подводит нас к следующему пункту …

Unit-Testing предоставляет документацию

Unit-тесты являются своего рода живой документацией к продукту. Чтобы узнать, какие функциональные возможности предоставляет тот или иной модуль, разработчики могут обратиться к модульным тестам, чтобы получить базовую картину логики модуля и системы в целом.Модульные тесты представляют собой индикаторы, которые несут информацию о надлежащем или нецелевом использовании программного компонента. Таким образом, эти случаи обеспечивают идеальную документацию для этих показателей.

R2: многоразовые и надежные

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

Сопроводительный код с тестами

Хорошо, поэтому модульное тестирование — это хорошо, но какой объем тестового покрытия необходим? Американский разработчик программного обеспечения Роберт С. Мартин, также известный как дядя Боб, утверждает, что цель охвата тестами должна заключаться в том, чтобы охватить 100 процентов кода. Мнения разработчиков по этому вопросу различаются: некоторые поддерживают полную политику покрытия кода, другие считают эту практику излишней — тема слишком длинная для целей этой статьи.В любом случае при написании модульных тестов вы можете использовать из множества инструментов, которые определяют общий процент покрытия проекта, отдельного модуля или функции. Эти инструменты также могут графически отображать разделы кода, покрытые тестами, и указывать, какие разделы в коде наиболее целесообразны для написания модульных тестов.

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

Как автоматизировать модульное тестирование и API-тестирование
  • Редактировать

    • Гол

    Цель этого руководства — поделиться опытом тестирования, знаниями и шаблонами тестирования, чтобы упростить внедрение тестирования в проектах OutSystems.

    В этом руководстве используется демонстрационное приложение «Cases» и приложение «Cases_Tests». Оба могут быть загружены из кузницы.

    С чего начать?

    Для эффективного тестирования, 5 основных элементов должны быть на месте.Это:

    • Хорошая стратегия тестирования , которая определяет типы и объем тестирования

    • План тестирования , в котором указаны задачи, которые необходимо выполнить для реализации стратегии тестирования

    • Контрольные примеры с подробными примерами использования, которые будут использоваться для проверки соответствия программного обеспечения требованиям

    • Определение тестовых данных , которое включает в себя как входные данные, так и существующие «производственные» данные, используемые во время выполнения теста;

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

    Если один из этих элементов отсутствует, эффективность тестирования будет значительно снижена.

    Основы тестирования

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

    Существует много «типов» тестирования: в этом руководстве мы создадим:

    • Юнит-тесты (тесты для небольших независимых частей функциональности),

    • API тесты (для API компонентов),

    Тестируемое приложение обозначается как AUT (тестируемое приложение).

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

    Ручные тесты не рассматриваются, потому что это руководство ориентировано на автоматизацию тестирования.

    Дополнительные рекомендации по тестированию проекта OutSystems можно найти на веб-сайте OutSystems.

    Стратегия испытаний и План испытаний

    Если ваше приложение уже построено в соответствии с 4-уровневой архитектурой Canvas, вы можете перейти к разделу «Модульное тестирование» ниже.Если нет, продолжайте чтение, чтобы понять, как настроить тестовую стратегию.

    Первая задача — разделить функциональность приложения от самой простой до самой сложной. Создайте список модулей, действий сервера, экранов, веб-блоков, методов API и т. Д. В электронной таблице со следующими столбцами: тип объекта (действие сервера, веб-экран и т. Д.), Папка (или поток пользовательского интерфейса), имя, риск. Вы также можете использовать OutDoc для извлечения этой информации.

    Как только список заполнен, классифицируйте каждый элемент с точки зрения риска.Если какой-либо компонент или действие дает сбой, насколько серьезным это будет для приложения? Например, бизнес-объекты должны быть устойчивыми, поскольку они являются основой бизнес-правил, в то время как редко используемая функциональность «системного администратора» не обязательно должна быть такой надежной.

    Чем выше риск функциональности приложения, тем тщательнее его следует проверить.

    Для каждой части функциональности приложения можно выбрать один или несколько типов тестирования. Например, действие сервера может быть протестировано с помощью модульного теста или интеграционного теста (потому что действие сервера вызывает много других функций) или с обоими (потому что можно пропустить «внешнюю» функциональность для модульного тестирования и потому что оно протестировано в бизнес-процессе).Экран должен быть протестирован с помощью пользовательского интерфейса.

    После того, как вы классифицировали все функциональные возможности приложения, пришло время разработать контрольные примеры. В интернете достаточно информации о разработке тестовых примеров (хорошие стартовые точки — tutorialspoint.com, stackoverflow.com и martinfowler.com).

    Просто имейте в виду, что у каждого теста есть следующие атрибуты:

    • Заголовок

    • Понятное описание

    • Допущения и / или предварительные условия

    • Набор тестовых шагов

    • Тестовые данные, которые будут использоваться для выполнения функциональности

    • Ожидаемый результат

    Вся информация должна быть простой и точной.Сделайте тестовые случаи максимально простыми и небольшими.

    . Поймите, что иметь большое количество маленьких тестовых наборов обычно лучше, чем иметь небольшое количество больших тестовых наборов, потому что большие тестовые наборы очень трудно поддерживать.

    Вот выдержка из тестовой стратегии для приложения Cases.

    Тесты обычно проводятся в циклах тестирования, во время которых выполняются тестовые примеры и сравниваются фактические результаты с ожидаемыми.В конце цикла тестирования нежелательные побочные эффекты должны быть устранены (это также называется тестовым демонтажем).

    Вот простая диаграмма, относящаяся к этим понятиям.

    Неудачные тесты должны быть проанализированы, а обнаруженные дефекты должны быть зарегистрированы в инструменте управления дефектами.

    Управление испытаниями

    Прежде чем мы приступим к созданию тестов, давайте представим Test Framework, инструмент, созданный с OutSystems для управления автоматизированными тестами. Этот инструмент доступен в Forge и поддерживает самые распространенные потребности тестирования.Для более богатого набора функций тестирования рассмотрим коммерчески доступные платформы тестирования.

    Test Framework поддерживает два типа тестовых случаев:

    • Модульные тесты, для быстрой обратной связи на небольшие кусочки кода (действия сервера)

    • API тесты, для обратной связи по REST или SOAP API

    Тестирование структур

    Framework Framework в соответствии со следующей иерархией:

    • Test Suites, группа связанных тестовых случаев;

    • Тестовые случаи — это реальные тесты; каждый тестовый набор содержится в одном тестовом наборе и может иметь один или несколько тестовых шагов;

    • Test Steps — это тестовые действия, выполняемые «тестовым движком».

    Можно создавать переменные для наборов тестов. Они могут быть использованы для пров

    .

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *