CC BY
26
ТЕХНИЧЕСКИЕ НАУКИ
«НАУКА. ИННОВАЦИИ. ТЕХНОЛОГИИ», №3, 2013
УДК 004.415.53
Солдатов А. П. [Soldatov A. P.], Мезенцева О. С. [Mezentseva O. S.]
ОСОБЕННОСТИ ТЕСТИРОВАНИЯ СИСТЕМ КОММЕРЧЕСКОГО УЧЁТА ЭЛЕКТРОЭНЕРГИИ
Features of testing of commercial electricity metering system
В статье рассматривается разработанная методика тестирования встроенного программного обеспечения в счётчики энергоресурсов, являющиеся важной частью системы коммерческого учёта электроэнергии.
Ключевые слова: тестирование программного обеспечения, АСКУЭ, тестирование «черного ящика», тестирование «белого ящика», жизненный цикл программного продукта.
The article show the technique of testing embedded software in energy counters, which are an important part of commercial electricity metering system.
Key words: software testing, AMR, from tests on a «black box» testing «white box», the life cycle of software.
Для решения проблемы автоматизации учёта электроэнергии на всех этапах - от производства до потребления - разрабатываются автоматизирование системы коммерческого учёта электроэнергии (АСКУЭ). Эти системы должны поддерживать следующие функции:
- измерение и многотарифный учет активной и реактивной электрической энергии и мощности;
- измерение параметров сети и диагностической информации с информированием о внештатных ситуациях;
- управление нагрузкой;
- установка и синхронизация времени на всех уровнях системы;
- измерение текущего времени;
- хранение данных в БД измеренных данных;
- аналитическая обработка собранных данных и расчет небалансов;
- визуальное предоставление данных и генерация отчетных форм;
- защита результатов измерений о несанкционированном доступе;
- обмен данными со сторонними системами коммерческого учета.
Общая структура АСКУЭ представлена на рисунке 1.
Важным этапом разработки подобного программного комплекса является этап тестирования. Причем следует уделять особое внимание как тестированию отдельных частей системы, так и тестированию её в целом. Одной из составляющих данной системы являются счётчики энергоресурсов. В настоящий момент разработаны различные методы и стратегии тестирования программного обеспечения.
Стратегия тестирования, или методы тестирования, - это систематические методы, используемые для отбора и/или создания тестов, которые должны быть включены в тестовый комплект [1]. Стратегия является эффективной, если тесты, включённые в неё, с большой вероятностью обнаружат ошибки тестируемого объекта. Эффективность стратегии зависит от комбинации природы тестов и природы ошибок, на поиск которых эти тесты направлены. Основные стратегии:
- стратегия поведенческого теста, основанная на технических требованиях; поведенческое тестирование называется также тестированием черного ящика или функциональное тестирование;
- стратегия структурного теста, определяемая структурой тестируемого объекта. Тестирование, выполненное с помощью стратегии структурного теста, называется также тестированием прозрачного ящика или тестированием белого ящика;
- стратегия гибридного теста, являющаяся комбинацией поведенческой и структурной стратегий [1].
Рис. 1. Общая структура АСКУЭ.
Продукт тестируют и исправляют практически на каждом этапе его жизненного цикла. Пять основных этапов жизненного цикла программного продукта: планирование, проектирование, кодирование и написание документации, тестирование и исправление недостатков, сопровождение и усовершенствование [2].
Программы как объекты тестирования имеют ряд особенностей, которые отличают процесс их тестирования от общепринятого, применяемого при разработке технических изделий. Особенностями тестирования ПП являются:
1) отсутствие эталона (программы), которому должна следовать тестируемая программа.
2) высокая сложность программ и принципиальная невозможность исчерпывающего тестирования.
3) практическая невозможность создания единой методики тестирования (формализация процесса тестирования) в силу большого числа различных программных продуктов по их сложности, функциональному назначению, области использования и т. д.
Для тестирования встроенного программного обеспечения в счётчики энергоресурсов не разработаны также и четкие методы и инструкции, следуя которым можно выявить и устранить полностью или основную часть ошибок. А от результатов тестирования во многом зави-
сит надёжность системы, способность находиться в работоспособном состоянии в течение некоторого времени.
Важной задачей является разработка методики тестирования встроенного программного обеспечения в счётчики энергоресурсов. В данной методике необходимо четко определить, на каком этапе какие задачи тестирования необходимо выполнить, а также какие стратегии использовать и какого рода ошибки на каком этапе необходимо выявить и исправить.
На этапах «планирование» и «проектирование» тестируются только идеи. Анализируя проектные документы, специалисты должны составить четкое представление о работе будущей системы. А также должно быть начато планирование системы будущих тестов.
На этапе кодирования, программист пишет программу и сам её тестирует. Применяется стратегия структурного теста. Протестировать все возможные пути выполнения программы абсолютно нереально, поэтому выделяются из всех возможных путей те группы, которые нужно протестировать обязательно. Для данного отбора используют специальные критерии, называемые критериями охвата. При тестировании данного программного обеспечения необходимо использовать три критерия охвата: строк, ветвлений и условий. Необходимо производить как статическое, так и динамическое тестирование. Для статического анализа существует множество инструментальных средств. Самое известное из них -компилятор.
Когда кодирование завершено, счётчик энергоресурсов со встроенным программным обеспечением передаётся группе тестирования. Стратегия структурного теста, которая выполнялась на этапе кодирования, не позволяет выявить ошибки, связанные со временем, неожиданные ошибочные ситуации, особые стечения данных, неверная информация на экране, проблемы связанные с пользовательским интерфейсом, взаимодействие с параллельно выполняемыми задачами, аппаратные ошибки, нестандартные ситуации и сбои.
При поступлении каждой новой версии программного продукта прежде всего проверяется, достаточно ли она стабильна. Такое первое беглое тестирование называют примерочным или квалификационным [3]. На данной стадии проверяются только основные функции счётчика энергоресурсов: индикация устройства, способность производить подсчёт и замер параметров энергоресурсов (электроэнергии), способность
накапливать показания по тарифам, способность обмена информацией с прикладным программным обеспечением. После проведения примерочного тестирования и проверки стабильности встроенного программного обеспечения выполняется функциональное и системное тестирование. Производится сравнение поведения программы с имеющимся руководством пользователя. Следуя руководству, необходимо делать всё, что в нём написано.
Составляется полный список функций и команд, которые поддерживаются устройством. Здесь же проверяется правильность их выполнения.
Выполняется анализ граничных условий, в соответствии с которым будут сформированы тесты. Учитываются ограничения: на вводимые в программу данные, параметры команд, поддерживаемые устройством, глубину хранения данных и проводятся тесты, в которых входящие значения являются граничными и выходят за границы условий.
Проверяется производительность. Измеряется время выполнения программой различных задач, особенно тех, которые пользователь будет выполнять чаще всего.
Производятся нагрузочные испытания. При нагрузочных испытаниях проверяется реакция программы на предельные условия эксплуатации. Это может быть непрерывный опрос (получения показаний за разные интервалы времени по всем тарифам) счётчика прикладным программным обеспечением.
Проверка на корректность обработки ошибок. Программа должна корректно реагировать на неправильные, нестандартные или не предусмотренные документацией действия пользователя. Для проведения подобного теста на счётчик отправляются недокументированные команды или допускаются синтаксические ошибки в наименовании команды. Также может быть отправлена на счётчик команда с неверным количеством параметров или неверным типом параметров.
Проверка защиты. Без авторизации пользователь не должен иметь возможности менять настройку конфигурации, считывать данные.
Для удобства тестирования счётчиков, осуществляющих обмен данными по протоколу ГОСТ Р МЭК 61107-2001 и каналу связи RS232, было разработано приложение «Тест МЭК RS232». Главное окно приложения представлено на рисунке 2.
Рис. 2. Главное окно приложения «Тест МЭК RS232».
Данное программное обеспечение позволяет: подключаться к счётчику по СОМ порту, создавать тестовые наборы команд, редактировать каждую команду отдельно (возможность нарочного допуска синтаксических ошибок), сохранять и загружать тестовые наборы команд, а также по средствам монитора обмена наблюдать за ходом обмена информацией и поведением встроенного программного обеспечения в счётчик. С помощью данной программы имеется возможность:
- проверить правильность выполнения команд встроенным программным обеспечением;
- выполнить анализ граничных условий, учитывая ограничения: на параметры команд, поддерживаемые устройством и глубину хранения данных;
- проверить на корректность обработки ошибок. Для проведения подобного теста на счётчик отправляются не-
документированные команды или допускаются синтаксические ошибки в наименовании команды. Также может быть отправлена на счётчик команда с неверным количеством параметров или неверным типом параметров. Редактируя команду можно изменить её структуру так, что она не будет соответствовать протоколу обмена. Примером подобного теста является проверка поведения встроенного программного обеспечения в счётчик электроэнергии (СЕ102М), при поступлении на него команды не соответствующей протоколу обмена «ГОСТ Р МЭК 61107-2001». Команда подтверждения/выбора опций в соответствии с протоколом представлено на рисунке 3.
АСК V Z Y CR LF
1 2 3 4 5 6
Рис. 3. Команда подтверждения / выбора опций.
Пояснение содержания сообщения:
1. Символ подтверждения (АСК, подтверждение, код 06Н);
2. Управляющие символы:
«0» - нормальная процедура протокола,
«1» - вторичная процедура протокола,
«2-9» - зарезервированы для будущих применений;
3. Идентификация скорости передачи информации (для переключения скорости передачи информации):
«0» - 300 Бод, «1» - 600 Бод, «2» - 1200 Бод, «3» - 2400 Бод, «4» - 4800 Бод, «5» - 9600 Бод,
«6», «7», «8», «9» - зарезервированы для будущих применений;
4. Режим команды:
«0» - считывание данных,
«1» - режим программирования,
«2-5» - зарезервированы для будущих применений,
«6-9» - использование, определяемое изготовителем;
5 и 6. Символ завершения (CR, возврат каретки, код 0DH; LF, перевод строки, код 0АН).
Добавив 1 «лишний» символ в начале команды (в данном тесте команда имеет вид «06 36 30 35 31 0D 0А»), отправляем её на счётчик после команды идентификации.
Получив такую команду, счётчик видит её несоответствие протоколу и не формирует ответ, ожидая повторного поступления правильной команды (рисунок 4).
В следующем тестовом прогоне изменим местоположение «лишнего» символа, расположив его в середине команды (команда имеет вид «06 30 35 31 36 0D 0А»). Также отправляем её на счётчик после команды идентификации. Получив такую команду, счётчик реагирует так, как будто она составлена правильно, и в ответ возвращает свой идентификатор (рисунок 5).
Подклюйте До&лм1»«ом4ид|> Полет» фгикця« Помощь Выход
Очередь коиаия 1001000/747!« || 2Р 14 37 21 01) РА 1001 ООО 1605Ш II 06 36 30 35 51 00 ОА 1 001 0001Р1[<777777)1! II 01 50 11 02 28 37 37 37 37 37 37 29 03 21 1 001 ооожиамимвд II 0152 31 02 53 4Е 65-Ю 42 20 г9 03&Е 1001 ООО 1В0[и II 01 42 30 03 75 Хранилице № ЧМП «ТЮ
У
в
и
кх
-> г* ЭР 34 3? 21 ОООА -> /747П <- № 43 74 35 43 45 31 30 32 40 76 30 31 00 ОА (- /Е>и5СЕ102МчЛ»1[[
-> 06 36 30 35 31 ОООА -> [6051 [Е
■> 1Р11С777777*1
Рис. 4. Тест первый, выполненный с помощью программы «Тест МЭК RS232».
Рис. 5. Тест второй, выполненный с помощью программы «Тест МЭК Р5232».
В этом случае программа некорректно обработала ошибку, что является ошибкой самой программы. По данному случаю создаётся инцидент и незамедлительно оповещается разработчик для устранения ошибки:
- проверить защиту. Без команды авторизации пользователь не должен иметь возможности менять настройку конфигурации и считывать данные;
- проводить нагрузочные испытания, составив большой список последовательных команд или какиелибо команды поместить в цикл, которые должен выполнить счётчик.
На этапе «сопровождение и усовершенствование» могут быть внесены изменения в программный код, что чревато побочными эффектами. Поэтому необходимо проверять не только изменённый фрагмент, но и всю программу в целом.
Выявив ошибку на любом из этапов жизненного цикла программы, необходимо сразу уведомить об этом разработчика. Чем раньше ошибка будет выявлена и устранена, тем менее затратное будет её устранение. После исправления ошибки необходимо убедиться, что выявленная ошибка полностью исправлена и больше не проявится. Такое тестирование называется регрессионным.
Данная методика поможет провести детальное тестирование и получить на выходе качественное встроенное программное обеспечение в счётчик энергоресурсов.
ЛИТЕРАТУРА 1. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем. СПб.: Питер, 2004. 318 с.
2. Канер Сэм и др. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / Сэм Канер, Джек Флок; пер. с англ. Изд-во «ДиаСофт», 2001. 544 с.
3. Тестирование объектно ориентированного программного обеспечения: практическое пособие / Джон Макгрегор, Девид Сайкс; пер. с англ. Издательство «ДиаСофт», 2002. 432 с.
ОБ АВТОРАХ Мезенцева Оксана Станиславовна, профессор кафедры информационных систем и технологий ФГАОУ ВПО «СевероКавказский федеральный университет», кандидат физико-математических наук, тел.: 88652956801. Е-mail: 28mos05@mail.ru.
Солдатов Александр Петрович, ФГАОУ ВПО «Северо-Кавказский федеральный университет», магистрант. Тел. 89886283838. Е-mail: Sashok_izob@mail.ru.
Mezentceva Oksana S., Professor of the Department of Information Systems and Technologies North Caucasian Federal University, candidate of physical and mathematical sciences.
Soldatov Alexander, North Caucasian Federal University, graduate student.
