ГОСТ Р МЭК 61508-7—2012
В.5.2 Тестирование методом «черного ящика»
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.З. В.5 и В.6)
и в МЭК 61508-3 (таблицы А.5 — А.7 и С.5 — С.7).
Цель. Проверка динамического поведения системы в реальных условиях функционирования. Выявление не
соответствия функциональной спецификации и оценка ее полезности и устойчивости.
Описание. Функции системы или программы выполняются в заданном окружении с заданными данными
тестирования, которые систематически формируются из спецификации в соответствии с установленными крите
риями. Это позволяет сравнить поведение системы с ев спецификацией. При проведении тестирования никакие
сведения о внутренней структуре системы не используются. Основная цель состоит в том. чтобы определить, пра
вильно ли выполняет функциональный модуль функции, требуемые спецификацией. Метод формирования экви
валентных классов служит примером критерия тестирования данных методом «черного ящика». Массив входных
данных подразделяется на конкретные диапазоны входных значений (эквивалентные классы) на основе специфи
кации. После этого формируются тестовые примеры из:
- данных из допустимых диапазонов:
- данных из недопустимых диапазонов:
- данных предельных значений диапазонов:
- экстремальных значений и
- комбинаций из перечисленных выше классов.
Могут оказаться эффективными также другие критерии выбора тестовых примеров в различных режимах
тестирования (модуля, интеграции и системы). Например, критерий «экстремальные эксплуатационные условия»
используется при тестировании системы в процессе подтверждения соответствия.
Литература:
Software Testing and Quality Assurance. К. Naik. P. Tripathy. Wiley Interscience. 2008. Print ISBN: 9780471789116
Online ISBN: 9780470382844.
Essentials of Software Engineering. Frank F. Tsui. Orlando Karam. Jones & Bartlett. 2006. ISBN 076373537X.
9780763735371.
The Art of Software Testing. Second Edition. G. Myers et al.. Wiley & Sons. New York. 2004. ISBN 0471469122,
9780471469124.
Systematic Software Testing. Rick D. Craig. Stefan P. Jaskiel. Artech House. 2002. ISBN 1580535089,
9781580535083.
B.5.3 Статистическое тестирование
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.З. В.5 и В.6).
Цель. Проверка динамического поведения системы, связанной с безопасностью, и оценка ее полезности
и устойчивости.
Описание. При этом подходе тестируется система или программа с входными данными, выбранными в соот
ветствии с предполагаемым статистическим распределением реальных эксплуатационных входных данных — экс
плуатационный профиль.
Литература:
A discussion of statistical testing on a safety-related application. S Kuball. J. H. R. May. Proc. IMechE Vol. 221
Part O: J. Risk and Reliability, Institution of Mechanical Engineers. 2007.
Practical Reliability Engineering. P.O’Connor. D. Newton. R. Bromley. John Wileyand Sons. 2002. ISBN 0470844639,
9780470844632.
DependabilityofCritical ComputerSystems3. P.G. Bishopetal., ElsevierAppliedScience. 1990. ISBN 1-85166-544-7.
Dependability of Critical Computer Systems 1. F.J. Redmill. ElsevierApplied Science. 1988. ISBN 1-85166-203-0.
B.5.4 Полевые испытания
П р и м е ч а н и я
1 Ссылка на данный метод/средство приведена в МЭК 61508-2 (таблицы В.З. В.5 и В.6).
2 См. также приложение С. С.2.10 — аналогичные средства, а в приложении D — статистический подход —
то и другое в контексте программного обеспечения.
Цель. Использование результатов полевых испытаний из различных областей применения в качестве одного
из средств исключения сбоев во время интеграции Э/Э/ПЭ системы и/или в процессе подтверждения соответ
ствия Э/Э/ПЭ системы безопасности.
Описание. Использование компонентов или подсистем, которые при их использовании показали путем испы
таний отсутствие или наличие только несущественных ошибок и существенно не изменялись в течение достаточно
длительного периода времени во многих различных применениях. В частности, для сложных компонентов с мно
жеством функций (например операционной системы, интегральных схем) разработчик должен обратить внимание
на функции, которые были фактически протестированы методом полевых испытаний. Например, должны быть
рассмотрены подпрограммы самотестирования для обнаружения сбоев: при отсутствии сбоев аппаратных средств в
период эксплуатации о подпрограммах нельзя сказать, что они протестированы, поскольку они никогда не вы
полняли функций обнаружения своих сбоев.
26