CC BY
73
ПРОБЛЕМЫ ТЕСТИРОВАНИЯ СИСТЕМНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РАСПРЕДЕЛЕННЫХ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ А.О. Ключев, Н.А. Маковецкая
Рассматривается применимость классических подходов к тестированию системного программного обеспечения (ПО) распределенных информационно-управляющих систем (РИУС).
В настоящее время наблюдается повышение уровня автоматизации в различных сферах человеческой деятельности, переход на новые технологии построения систем автоматизации. В значительной мере этому способствует использование заказных встроенных систем управления объектами. Таким образом, проектирование встроенных вычислительных систем приобретает массовый характер.
Ко многим подобным системам предъявляются повышенные требования по надежности и безопасности функционирования. Так как тестирование - это основной метод измерения качества, определения корректности и реальной надежности функционирования программ [2], приобретает большое значение вопрос о применимости классических методов тестирования программ к ПО встроенных систем и в частности - ПО распределенных информационно-управляющих систем (РИУС).
В русскоязычной литературе превалируют описания методик тестирования вычислительных систем общего назначения, в области же проектирования и тестирования встроенных систем существует определенный информационный вакуум. Возникают опасения, что зарождающиеся в России направления проектирования встроенных систем могут быть серьезно дезориентированы общепринятыми на данный момент подходами к проектированию систем общего назначения.
В данной статье будет сделана попытка проанализировать проблему тестирования встроенных систем с помощью методик, используемых для систем общего назначения, на примере РИУС - одного из самых сложных видов встроенных систем. Перечислим классические задачи при тестировании ПО [1,2].
1. Тестирование функциональности (тестирование "черного ящика"): проверка функциональности системы на соответствие требованиям.
2. Тестирование производительности: определение характеристик производительности, поиск " узких мест".
3. Стрессовое тестирование системы при предельной нагрузке на различные ресурсы.
4. Проверка устойчивости системы к неполадкам и безопасного оперативного восстановления при сбоях: оценка эффективности защиты от аппаратных сбоев, последствий проявления невыявленных дефектов и ошибок программ и данных.
5. Тестирование совместимости ПО со всеми модификациями аппаратуры, для которых оно предназначено.
6. Анализ исходных текстов (просмотр экспертом и автоматический анализ).
7. Оценка удобства использования системы.
8. Тестирование способности модулей системы к взаимодействию, в том числе перераспределения нагрузки.
9. Тестирование надежности: проверка поведения при длительной непрерывной эксплуатации при большой нагрузке.
Тестирование подразделяют на прогрессивное, при котором проверяются новые компоненты, и регрессивное, когда контролируется качество и корректность изменений в программах и данных после внесения в них изменений. Согласно еще одной классификации, тестирование бывает восходящее, когда сначала тестируются объекты нижнего уровня, и нисходящее, при котором в первую очередь тестируются высшие иерархические уровни системы, а потом низшие.
Несмотря на многообразие методов и инструментов тестирования, как правило, некоторые ошибки все равно остаются невыявленными. Основной причиной этого является недостаток времени и сил для тестирования. Эффективность тестирования можно повысить, встроив средства тестирования в архитектуру системы уже на этапе проектирования; практикуется также создание тестов перед написанием тестируемого кода. Еще один путь - автоматическая генерация тестовых наборов и автоматическое проведение тестов, особенно регрессивных.
На процесс тестирования и отладки системного ПО РИУС влияют следующие факторы:
1. РИУС - сложный программно-аппаратный комплекс, состоящий из множества разнообразных компонентов, часто пространственно распределенный;
2. РИУС интегрирована в объект управления;
3. работа в реальном масштабе времени (РВ);
4. в реальных условиях доступ к модулям РИУС часто затруднен или невозможен, так как они устанавливаются в труднодоступных или вовсе недоступных местах (например, на космических станциях);
5. тяжелые климатические, механические и электромагнитные условия эксплуатации: высокая влажность, неблагоприятная температура, вибрация, сильные электромагнитные поля;
6. жесткие требования к надежности и безопасности функционирования: РИУС управляют такими критическими объектами, как АЭС, железные дороги, военная техника, медицинское оборудование;
7. тесная интеграция программного и аппаратного обеспечения РИУС: качественное тестирование ПО невозможно при отсутствии корректно функционирующей аппаратуры. В то же время на начальных стадиях разработки аппаратура работает нестабильно или не работает вообще. Таким образом, приходится тестировать сразу весь программно-аппаратный комплекс, каждый модуль которого может содержать ошибки. Это значительно усложняет интерпретацию результатов тестирования: во-первых, иногда некоторые ошибки компенсируют друг друга; во-вторых, из-за невозможности тестирования единичных модулей отдельно от всей системы очень трудно локализовать источник проблем.
8. некоторые аппаратные компоненты имеют ограниченный рабочий ресурс: E2PROM и FLASH имеют ограниченное число циклов записи, электромеханические механизмы (клапаны, реле и т.п.) постепенно изнашиваются.
Тестирование функциональности РИУС, а также проверка устойчивости системы к неполадкам и безопасного оперативного восстановления при сбоях затруднены по следующим причинам.
1. Сложность, модульность, распределенность, гетерогенность системы.
2. Для тестирования требуется широкий спектр дополнительной аппаратуры и ПО. При этом многие инструменты либо очень дороги, либо вообще не существуют, и их нужно разрабатывать с нуля, что может быть сопряжено с значительными затратами денег и времени.
3. Проведение испытаний на реальном объекте управления обычно невозможно. Даже если такая возможность существует, аварийная ситуация при проведении подобных испытаний может привести к катастрофическим последствиям. Симуляция объекта управления опасна дополнительными ошибками и требует специального дорогостоящего оборудования для имитации внешних воздействий.
4. Требование работоспособности РИУС в различных внешних условиях означает, что нужно повторить все тестовые испытания при высокой или низкой температуре, высокой влажности, в условиях вибрации, жесткого электромагнитного излучения
и т.д. Это значительно увеличивает трудозатраты на тестирование и требует сложного дорогого оборудования (термокамеры, вибростенды).
Тестирование производительности РИУС малозначимо на фоне остальных задач. Однако существует гораздо более серьезная проблема - проверка способности системы к работе в реальном масштабе времени. Способов формального доказательства соответствия системы требованиям РВ пока не существует, а проверка на практике усложняется тем, что сама система тестирования при совместной работе с целевой системой искажает временные показатели и содержимое памяти. Таким образом, проблема может быть замаскирована инструментальной погрешностью или наоборот, может быть выдано ложное сообщение о несоответствии системы требованиям РВ. Более того, анализ причин проблемы будет затруднен из-за порожденных системой тестирования искажений в дампах памяти. Чтобы избежать этих трудностей, система тестирования интегрируется в целевую систему, но тогда появляется другая проблема: система тестирования съедает ресурсы, которых и так не хватает.
Стрессовое тестирование в некоторых случаях затруднено, так как рабочий ресурс аппаратуры ограничен.
Тестирование совместимости: в отличие от тестирования ПО для универсальных персональных компьютеров, обычно не требуется проверки совместимости с широкой номенклатурой аппаратных и программных продуктов, а нужна только совместимость с продукцией этого же производителя и некоей базовой конфигурацией ПК. Таким образом, тестирование совместимости увеличивает общий объем работ по тестированию всего в несколько раз. Однако в случае, когда требуется протестировать совместимость ПО с продуктами сторонних фирм, возникают проблемы дороговизны этих продуктов и нежелания конкурирующих фирм предоставлять свои системы для подобных целей.
Хотя анализ исходных текстов позволил бы обнаружить потенциальные дефекты ПО на ранних стадиях разработки, для проведения подобного анализа вручную необходим эксперт по аппаратуре и ПО. Проблема выбора и подготовки такого эксперта усугубляется сложностью и частой сменой элементной базы. Автоматизированный просмотр исходных текстов не представляется целесообразным: как правило, системное ПО РИУС не содержит сложных алгоритмов, а основное количество ошибок кроется в неправильном использовании регистров специального назначения, несоблюдении временных соотношений и т.п. Автоматическая система анализа исходных текстов вряд ли сможет обнаружить подобные ошибки, а значит, будет практически бесполезна.
Оценка удобства использования системного ПО РИУС не столь актуальна, так как, как правило, с ним редко работают напрямую. Для интерфейсов оператора важна согласованность с пользовательской "моделью мира": интерфейс системы должен соответствовать представлению пользователя о ее устройстве и окружении, а не истинной архитектуре системы. Для РИУС удобство использования отходит на второй план по сравнению с такими показателями, как надежность и безопасность функционирования. Как правило, оценка удобства использования проводится уже на месте заказчиком.
Тестирование способности модулей системы к взаимодействию: несмотря на то, что эта способность является ключевой для РИУС, как правило, подобное тестирование проводится на малом числе модулей (воспроизведение необходимых внешних условий для большого числа модулей трудоемко и дорого).
Тестирование надежности не представляет особых технических проблем, но может отнять очень много времени.
Автоматической генерации тестов мешают такие факторы, как тесная связь ПО с аппаратурой, интеграция РИУС с ОУ, а также их модульность (это увеличивает объем
тестовых испытаний: нужно создать тесты не для одной системы, а для множества разнообразных модулей). Автоматическая генерация тестов для РИУС сложна и в некоторых случаях опасна: некоторые, на первый взгляд совершенно невинные, наборы тестовых значений могут привести к катастрофе. Поэтому перед запуском тесты обязательно должен проверять эксперт.
Регрессивное тестирование вручную очень трудоемко и требует использования сложного тестового оборудования. Практика показывает, что регрессивное тестирование одного контроллера только лишь для одного варианта внешних условий может длиться часами, при этом большое количество ручных операций делает возможным пропуск тестировщиком многих ошибок (человеческий фактор). Еще одним препятствием для регрессивного тестирования является ограниченность рабочего ресурса аппаратуры.
Автоматическое проведение тестов, в том числе регрессивных, ограничивается тем, что для генерации входных тестовых воздействий необходима дополнительная аппаратура и, возможно, ОУ.
В классическом варианте встраивание средств тестирования в архитектуру системы является необязательным; для РИУС это жизненно необходимо. Практика показывает, что тестирование РИУС требует создания соизмеримого с ней или даже превосходящего ее по сложности тестового комплекса.
Как видно из представленных примеров, применение классических способов тестирования либо не дает должного эффекта, либо приводит к очень большим материальным затратам. В связи с тем, что после распада СССР серьезно снизилась активность российских производителей встроенных систем и вся эта область проектирования долгое время находилась в кризисе, возникло значительное отставание от зарубежных методологий. Для ликвидации этого разрыва требуется переосмысление привычных подходов к проектированию встроенных систем.
Литература
1. Web-сайт компании Amphora Quality Technologies (www.aqt.ru).
2. Липаев В.В. Надежность программных средств. Серия «Информатизация России на пороге XXI века». М.: СИНТЕГ, 1998. 232 с.
