CC BY
41
■■■
РЧН
и информационные
технологии
В.О. НОВИЦКИИ,
д.т.н., проф. кафедры «Информатика и вычислительная техника пищевых производств» ФГБОУ ВО «МГУПП», Генеральный директор ООО «Диакеа-Софт», [email protected] Я.К. НОВИКОВА,
специалист по тестированию ООО «Диакеа-Софт», магистрант ФГБОУ ВО «МГУПП», г. Москва, Россия, [email protected]
ПРОЦЕСС ТЕСТИРОВАНИЯ МЕДИЦИНСКОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ НА ПРИМЕРЕ ИНФОРМАЦИОННО-АНАЛИТИЧЕСКОЙ СИСТЕМЫ УПРАВЛЕНИЯ ЛЕЧЕБНО-ДИАГНОСТИЧЕСКИМ ПРОЦЕССОМ MAXIMUS
УДК 004.415.53
Новицкий В.О., Новикова Я.К. Процесс тестирования медицинского программного обеспечения на примере информационно-аналитической системы управления лечебно-диагностическим процессом Maximus
(ФГБОУ ВО «МГУПП», ООО «Диакеа-Софт», г. Москва, Россия)
Аннотация. Тестирование медицинского ПО рассматривается как деятельность, которую необходимо проводить на протяжении всего процесса разработки и сопровождения МИС. Описываемая система тестирования направлена на повышение качества разрабатываемого ПО путём организации процесса обнаружения, документирования и проверки устранения ошибок и является важной частью проектирования и технической поддержки внедрения, эксплуатации и развития программных продуктов.
Ключевые слова: тестирование медицинского ПО, виды тестирования, алгоритм, процесс, стратегическая карта отдела тестирования, критерий эффективности, количество пропущенны/х ошибок.
UDC 004.415.53
Novitskiy V.O., Novikova Y.K. The process of medical software testing in the context of «Maximus» — the information analytical system of management of the treatment and diagnostics process (Moscow state university of food production, «DiaCare soft Ltd», Moscow, Russia)
Abstract. The process of medical software testing shall be regarded as an activity which has to be performed during the whole development and technical support process of any medical information system. The testing system described is being aimed to increase the quality of developed software via establishing discovering process, documenting and verifying the clearing of errors, and is an important part of design and technical support on implementation, operation and software evolution.
Keywords: medical software testing, testing types, algorithm, process, strategic map of testing department, efficiency
criteria, number of mistakes missed. >-
ВВЕДЕНИЕ
Тестирование представляет собой процесс анализа программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта [1]. Тестирование не подразумевает работ, связанных с устранением ошибок. В него не входят отладка и действия по устранению последствий ошибок [2].
© В.О. Новицкий, Я.К. Новикова, 2018 г.
■ ■■
F4H
2018, № 1
Тестирование основывается на проведении тестовых процедур с конкретными входными данными, начальными условиями и ожидаемым результатом, разработанными для определенной цели, такой, например, как проверка отдельного программного модуля или верификация в соответствие с определенными требованиями. Тестовые процедуры могут проверять различные аспекты функционирования программы - от правильной работы отдельной функции до адекватного выполнения комплекса бизнес-требований.
При выполнении проекта необходимо учитывать, в соответствии с какими стандартами и требованиями будет проводиться тестирование продукта. Какие инструментальные средства будут (если будут) использоваться для поиска и для документирования найденных дефектов? Если помнить о тестировании с самого начала выполнения проекта, то тестирование разрабатываемого продукта не доставит неприятных неожиданностей. А значит и качество продукта, скорее всего, будет достаточно высоким.
С точки зрения ISO 9126 качество ПО можно определить как совокупную характеристику исследуемого ПО с учетом составляющих:
1. Функциональность - набор атрибутов, характеризующий соответствие возможностей ПО набору требуемой пользователем функциональности.
2. Надёжность - набор атрибутов, относящихся к способности ПО сохранять свой уровень качества функционирования в установленных условиях за определенный период времени.
3. Практичность (применимость) - набор атрибутов, относящихся к объему работ, требуемых для исполнения и индивидуальной оценки такого исполнения определенным или предполагаемым кругом пользователей.
4. Эффективность - набор атрибутов, относящихся к соотношению между уровнем качества функционирования ПО и объемом
используемых ресурсов при установленных условиях.
5. Сопровождаемость - набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций).
6. Мобильность - набор атрибутов, относящихся к способности ПО быть перенесенным из одного окружения в другое [3].
Тестирование программных средств заключается в динамической проверке поведения продукта на определенном наборе тестов-кейсов, обеспечивающих проверку соответствия ожидаемому поведению системы.
Основные виды тестирования:
]. Функциональное - выяснение так ли работает система, как ожидается. Оно, в свою очередь, делится на следующие подвиды:
1.1. регрессионное тестирование, которое предназначено для проверки того, что программа после изменений продолжает соответствовать поставленным требованиям и успешно взаимодействовать с другими компонентами и системами;
1.2. тестирование безопасности, которое проводится с целью оценки устойчивости системы к противоправным действиям;
1.3. системное тестирование, предназначенное для проверки готового ПО в том состоянии, в котором оно будет внедряться в опытно-промышленную эксплуатацию;
1.4. интеграционное тестирование, предназначенное для проверки корректности взаимодействия системы со смежными системами;
1.5. дымовое-тестирование ^токе-тести-рование), которое необходимо для выявления явных ошибок функциональности и проводится обычно самим разработчиком, поскольку нет смысла отдавать программный модуль, не готовый для более глубокого тестирования.
2. Нагрузочное тестирование - это определение границы производительности системы. В свою очередь оно делится на:
>
Врач «и
' и информационные
технологии
>2.1. тестирование производительности -позволяет определить максимальную интенсивность операций, при которой система удовлетворяет требованиям ко времени отклика;
2.2. объемное тестирование - позволяет проверить использование системных ресурсов при увеличении объема данных и принять меры для предотвращения отказа системы в будущем;
2.3. тестирование стабильности - предназначено для оценки возможности системы работать длительное время под нагрузкой;
2.4. стресс-тестирование - необходимо для проверки поведения системы в условиях стресса (внешних возмущений) и оценки способности системы к восстановлению после прекращения воздействия стресса.
3. Конфигурационное тестирование - проверка поведения системы в различных условиях. Оно включает кроссбраузерное и/или кроссплатформенное тестирование, то есть проверку работы web-приложения на возможность работы в различных браузерах и/ или на различных платформах.
4. Приемочное тестирование - комплексная проверка перед вводом ПО в эксплуатацию. В свою очередь включает:
4.1. операционное тестирование - для убеждения в том, что система выполняет свою роль в среде эксплуатации согласно бизнес-модели;
4.2. пользовательское тестирование, которое проводят конечные пользователи системы с целью определить пригодность для внедрения;
4.3. альфа-тестирование/бета-тестирование, представляющие собой проверку программы независимой командой тестирования [4].
Результатом применения описанной системы тестирования является интеллектуальная медицинская информационная система Mаximus.
Система Maximus - это автоматизированная информационная система управления, анализа и поддержки принятия решений для лечебно-диагностических процессов (ЛДП) в области
нефрологии, гемодиализа и осложнений. Система является комплексной, масштабируемой, сервис-ориентированной и включает: автоматический сбор информации и результатов измерений, анализ динамики параметров состояния пациентов, оборудования, автоматизированную диагностику, выработку программ лечения, регламентирование ЛДП, обучение и скрининг компетенций мед. персонала, КР1, удалённое консультирование и онлайн мониторинг ЛДП, управление административными процессами, первичный учёт и логистику пациентов, материалов, ведение регистра пациентов и др. Система внедрена в нескольких десятках ЛПУ первичного и специализированного звеньев, связанных с нефрологией и гемодиализом, урологией, кардиологией, эндокринологией и др. областями медицины. Используется в поликлиниках, амбулаториях и лечебных отделениях стационаров, реанимациях, лабораториях всех видов и других организациях здравоохранения.
Для верификации такой системы необходимо детально и точно представлять процесс тестирования, так как Maximus является сложной и многофункциональной системой. Из-за незнания процесса возможно пропустить важные проверки, тем самым не заметив ошибок. В дальнейшем это может повлиять на работу пользователей - врачей, менеджеров, пациентов и медицинской организации в целом. Одним из ключевых клиентов системы Maximus является МЧУ ДПО «Нефрологический экспертный совет», объединяющий 9 областных филиалов и около 30 региональных клиник России.
Также проблемой является то, что при появлении в штате нового сотрудника отдела тестирования его приходится обучать и объяснять работу и задачи, которые он должен выполнять лично на словах, не имея какого-то конкретного документа или процесса, по которому можно было бы увидеть все задачи и этапы тестирования.
Была поставлена задача - описать процесс тестирования так, чтобы человек, незнакомый
■ ■■
РЧН
с текущим процессом тестирования компании разработчика, смог понять, из чего состоит данный процесс, какие задачи должен выполнять и с кем взаимодействовать. Таким образом, новый сотрудник сможет самостоятельно приобрести знания о том, что входит в его обязанности и как это правильно делать. Документ, который грамотно описывает работу отдела тестирования и к которому в свободном доступе могут обращаться тестировщики, поможет сократить количество пропущенных ошибок. Естественно, таким образом невозможно све-
Рис. 1. Алгоритм функционального тестирования модуля
2018, № 1
сти количество пропущенных ошибок к нулю, поскольку на количество пропущенных ошибок во многом влияет опыт тестировщика.
На основе анализа текущего процесса тестирования с помощью знаний и накопленного опыта сотрудниками отдела функционального и интеграционного тестирования совместно с кафедрой «Информатика и вычислительная техника» ФГБО ВО «МГУПП» разработан, опробован и внедрён в практику компании ООО «Диакеа-Софт» алгоритм тестирования функциональных модулей (рис. 1).
Бизнес процесс и процедура функционального тестирования модулей были прописаны в программной нотации BPMN (см. рис. 2 и 3) [7] и утверждены в виде соответствующих регламентов компании. В них описаны задачи тестировщика на протяжении всего жизненного цикла процесса тестирования модуля. Помимо этого показана взаимосвязь отделов на разных стадиях процесса.
Для оценки эффективности алгоритма была собрана статистика о количестве пропущенных ошибок до его применения и после. 1. Результаты до:
За последние 7 версий их число варьируется от 30 до 40 на каждую версию.
Из общего числа выявленных ошибок некоторые ошибки:
- Отклонены по причине неповторимости.
- На ошибки уже были заведены задачи.
- Улучшения нерациональны для системы.
Статистика:
1. Версия 1.48 = 29.
2. Версия 1.49 = 44.
3. Версия 1.50 = 39.
4. Версия 1.51 = 45.
>
■■■
РЧН
и информационные
технологии
Рис. 2. Процесс функционального тестирования модуля
Рис. 3. Процедура тестирования модуля
■ ■■
РЧН
5. Версия 1.52 = 31.
6. Версия 1.53 = 42.
7. Версия 1.54 = 27.
2. Результаты после:
Согласно собранной информации, в версии 1.55 было пропущено 23 ошибки, что меньше чем в предыдущих версиях.
Также было учтено, что на количество пропущенных ошибок влияет не только знание процесса, а еще и опыт тестировщика и сложность разработанного функционала.
Еще одним достоинством созданного процесса является отсутствие затрат времени на обучение при появлении новых сотрудников в отделе.
2018, № 1
На основании стратегической карты отдела тестирования (см. рис. 4) и исходя из задач данной работы, были выделены критерии для оценки эффекта [8].
Главной задачей системы тестирования является снижение количества пропущенных ошибок. Её результаты на рисунке 4 оцениваются по следующим критериям:
1. Количество пропущенных ошибок.
2. Опыт работы с системой Mаximus.
3. Количество полученных сертификатов.
Из этих критериев необходимо было выбрать тот, по которому можно количественно оценивать эффективность. При этом стоит учитывать, что критерии находятся в разных
Рис. 4. Стратегическая карта отдела тестирования
>
Врач Ли
' и информационные
технологии
> блоках (внутренние бизнес-процессы, обучение и развитие), а также то, что необходимо выбрать критерий, который мы можем измерять. Таковым является только критерий - Количество пропущенных ошибок.
Для оценки результатов эффективности системы тестирования ПО по данному критерию было посчитано, сколько в среднем было пропущенных ошибок до применения алгоритма. Применимо к выпуску версий системы Mаximus получено следующее:
Т" я
_ N ,
где qn, п= 1, N - количество пропущенных ошибок в п версии;
п - Индекс версии, N=общее количество версий ^ = 7).
1. Версия 1.48 = 29
2. Версия 1.49 = 44
3. Версия 1.50 = 39
4. Версия 1.51 = 45
5. Версия 1.52 = 31
6. Версия 1.53 = 42
7. Версия 1.54 = 27 29+44+39+45+31+42+27 п/ ^
После применения алгоритма и получения результатов в версии 1.55 количество пропущенных ошибок равно 23.
Сравнив эти оба значения, мы получаем, что количество пропущенных ошибок уменьшилось в 1,5 раза.
Подводя итог, можно утверждать, что после применения созданного алгоритма количество пропущенных ошибок уменьшилось, стало легче обучать сотрудников. Результаты внедрения вышеописанных процессов и процедур тестирования (регламентов) являются эффективными, поэтому целесообразность применения созданного алгоритма несомненна.
Также при визуализации процесса тестирования в нотации BPMN человек, не знакомый с тестированием, может понять, из чего состоит данный процесс, и какие задачи должен выполнять тестировщик. Имеются также описания процессов и регламенты не только функционального тестирования, но и приемочного тестирования и других подпроцессов, которые должны выполнять тестировщи-ки: процесс создания и актуализации тестовых стендов, процесс обработки ошибок на этапе опытной эксплуатации и др.
ЛИТЕРАТУРА
¿у | I 1. Куликов Святослав. Тестирование программного обеспечения. Базовый курс. - ЕРАМ iltU' ■ Systems: 2015-2017-289 с.
V^ ' 2. Тестирование объектно-ориентированного программного обеспечения. Практическое / пособие: Пер. с англ./Джон Макгрегор, Девид Сайке - К.: ООО «ТИД «ДС», 2002. - 432 с.
3. ISO/IEC TR9126-2 Техника программного обеспечения - Качество продукции - Часть 2: Внешние метрики-2000 г.
4. [Электронный ресурс] Тестирование. Фундаментальная теория - Режим доступа: https:// habrahabr.ru/post/279535/ (Дата обращения 11.11.2017 г.)
5. Рекс Блэк. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование - Москва: Издательство «Лори», 2006 - 544 с.
6. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений: Пер. с англ./ Сэм Канер, Джэк Фолк, Енг Кек Нгуен. - К.: Издательство «ДиаСофт», 2001 - 544 с.
7. Кулябов Д.С., Королькова А.В. Введение в формальные методы описания бизнес-процессов: Учеб. пособие. - М.: РУДН, 2008. - 202 с.
8. Гершун А.М., Нефедьева /О.С.Разработка сбалансированной системы показателей. Практическое руководство с примерами - 2-е изд., расшир. - М.: ЗАО «Олимп-Бизнес», 2005. - 128 с.
