ГОСТРМЭК 62304—2013
цели. Тестирование методом «белого ящика» не может гарантировать, что была осуществлена полная специ
фикация. поскольку оно сфокусировано на тестировании реализации ПРОГРАММНОГО ЭЛЕМЕНТА. Тестирова
ние «черного ящика», также известное как поведенческое, функциональное, тестирование непрозрачного ящика
или тестирование закрытого ящика, сфокусировано на тестировании функциональной спецификации и не гло жет
гарантировать, что были протестированы все реализованные части. Таким образом, тестирование «черного
ящика» является тестированием на спецификацию и обнаруживает дефекты пропусков, определяя, какая часть
спецификации не была выполнена. Тестирование «белого ящика» является тестированием на реализацию и об
наруживает дефекты выполнения, указывая, какая часть реализации неисправна. Чтобы полностью протести
ровать ПРОГРАММНЫЙ ПРОДУКТ, могут потребоваться как тестирование «черного ящика», так и тестирование
«белого ящика».
Планы и документация тестирования, определенные в 5.6 и 5.7. могут быть отдельными документами, при
вязанными к конкретным фазам разработки ипи эволюционным прототипам. Они также могут быть объединены в
единый документ или набор документов, охватывающих требования множества подразделов. Все документы или
часть документов могут быть включены в документы проекта более высокого уровня, такие как план обеспечения
качества проекта или ПО. или план комплексного тестирования, который охватывает все аспекты тестирования
аппаратных средств и ПО. В таких случаях следует создавать перекрестную ссылку, которая определяет, как раз
личные документы проекта связаны с каждой из ЗАДАЧ интеграции ПО.
Тестирование интеграции ПО гложет быть осуществлено в моделируемой среде, на имеющемся оборудова
нии. или на полном МЕДИЦИНСКОМ ИЗДЕЛИИ.
В 5.6.2 от ИЗГОТОВИТЕЛЯ требуется ВЕРИФИЦИРОВАТЬ выходные данные деятельности по интегра
ции ПО. Выходные данные деятельности интеграции ПО — это интегрированные (встроенные) ПРОГРАММНЫЕ
ЭЛЕМЕНТЫ.
Эти интегрированные ПРОГРАММНЫЕ ЭЛЕМЕНТЫ должны правильно функционировать для всего ПО МЕ
ДИЦИНСКОГО ИЗДЕЛИЯ, чтобы оно функционировало правильно и надежно.
В.5.7 Тестирование ПО СИСТЕМЫ
Эта РАБОТА требует от ИЗГОТОВИТЕЛЯ проверить функциональность ПО путем проверки того, что требо
вания к ПО были успешно выполнены.
Тестирование ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ демонстрирует, что указанные функции суще
ствуют. Это тестирование ВЕРИФИЦИРУЕТ функциональность и характеристики программы как встроенной в от
ношении требований к ПО. Тестирование ПРОГРАММНОЙ СИСТЕМЫ ориентировано на функциональное («чер
ный ящик») тестирование, хотя может быть желательно использовать метод «белого ящика» (см. выше), чтобы
эффективно выполнять определенные тесты, выделять стрессовые условия или дефекты, или увеличивать охват
кодом квалификационных тестов. Организация тестирования по типам и этапам теста является гибкой, но охват
требований, УПРАВЛЕНИЕ РИСКОМ, эксплуатационная пригодность и типы тестов (например, отказ, установка,
работа в сложных ситуациях) должны быть продемонстрированы и задокументированы.
Тестирование ПРОГРАММНОЙ СИСТЕМЫ проверяет интегрированное ПО и гложетбыть выполнено вмоде
лируемой среде, на имеющемся оборудовании или на полном МЕДИЦИНСКОМ ИЗДЕЛИИ.
Когда в ПРОГРАММНУЮ СИСТЕМУ вносят изменения (даже небольшие), должна быть определена степень
РЕГРЕССИОННОГО ТЕСТИРОВАНИЯ (но не только тестирования отдельных изменений), чтобы удостовериться,
что не были введены никакие непредусмотренные побочные эффекты. Это РЕГРЕССИОННОЕ ТЕСТИРОВАНИЕ
(и обоснованиедля неполностью повторяемого тестирования ПРОГРАММНОЙ СИСТЕМЫ) должно быть заплани
ровано идокументировано.
Ответственность за тестирование ПРОГРАММНОЙ СИСТЕМЫ может быть распределена, осуществляться в
разных местах и быть проведена различными организациями. Однако, независимо от распределения ЗАДАЧ, дого
ворных отношений, источника компонентов или среды (условий) разработки, ИЗГОТОВИТЕЛЬ изделия сохраняет
окончательную ответственность за обеспечение правильного функционирования ПО в соответствии с предназна
ченным применением.
Если АНОМАЛИИ, обнаруженные в течение тестирования, могут повториться, но было принято решение
не фиксировать их, тогда эти АНОМАЛИИ должны быть ОЦЕНЕНЫ в отношении анализа ОПАСНОСТИ, чтобы
убедиться, что они не оказывают влияние на БЕЗОПАСНОСТЬ изделия. Причина и признаки АНОМАЛИЙ должны
быть поняты, и должно быть в наличии документированное объяснение того, что эти АНОМАЛИИ не фиксируются.
В 5.7.4 требуется, чтобы РЕЗУЛЬТАТЫ тестирования ПРОГРАММНОЙ СИСТЕМЫ были ОЦЕНЕНЫ для обе
спечения получения ожидаемых РЕЗУЛЬТАТОВ.
В.5.8 Выпуск ПО
Этадеятельность требует от ИЗГОТОВИТЕЛЯ документировать ВЕРСИЮ выпускаемого ПО МЕДИЦИНСКО
ГО ИЗДЕЛИЯ, указать, как оно было создано, и следовать необходимым для выпуска ПО процедурам.
ИЗГОТОВИТЕЛЬ должен быть способен продемонстрировать, что ПО. которое было разработано, с исполь
зованием ПРОЦЕССА разработки, — это то ПО. которое было выпущено. ИЗГОТОВИТЕЛЬ должен иметь возмож
ность восстановить ПО и инструменты, использованные для его создания, в случае, если это будет необходимо в
будущем, и хранить, упаковывать идоставлять ПО способом, минимизирующим возможность повреждения или
неправильного применения. Должны быть установлены определенные процедуры, чтобы обеспечить выполнение
ЗАДАЧ надлежащим образом и с последовательными результатами.
30