который добавляется в общий массив выполняемых программой авто-
матизированного тестирования сценариев.
Как бы ни было высоко стремление к автоматизации всех рутин-
ных процессов, связанных с тестированием, полностью исключить
ручную работу тестировщика-оператора не представляется возмож-
ным. Основной причиной возникновения таких ситуаций является не-
обходимость проверки визуальных составляющих ПО либо сложных
алгоритмов работы, на которые невозможно или слишком трудоемко
писать тестовые скрипты. Тест-кейс для ручного тестирования пред-
ставляет собой в упрощенном виде таблицу с двумя колонками: в пер-
вой описано действие, которое необходимо выполнить тестировщику,
а во второй — результат, который должен показать, что тестовый шаг
выполнен успешно, в случае несоответствия полученного результата
формируется отчет для группы разработчиков.
При нынешней структуре построения регрессионных тестовых на-
боров, практически на всех этапах формирования теста необходимо
наличие высококвалифицированного персонала, что сказывается на
стоимости проекта либо на качестве производимого продукта.
Основной задачей является минимизация средств на формирование
наиболее адекватных, полных тестов. При текущей схеме формирова-
ния регрессионных тестов минимизировать затраты не получается.
Большинство автоматизированных учетных систем в настоящее
время разрабатываются с использованием специальных конфигура-
торов, это позволяет значительно сократить время разработки при-
кладных решений, а также обеспечивает функционирование в едином
информационном пространстве. Изменение законов, нормативных ак-
тов, организационно-распорядительных документов, формы собствен-
ности — все это приводит к необходимости внесения большого числа
изменений в существующую конфигурацию. В рамках каждой конфи-
гурации выделяется ряд подсистем, каждая из которых автоматизирует
работу определенного структурного подразделения. Как правило, за-
явки на адаптацию или доработку функционала не согласовываются с
другими подразделениями, поэтому велик риск частичной или полной
блокировки работоспособности отдельных подсистем учета. Останов-
ка работы подразделения в крупных компаниях может повлечь значи-
тельные материальные потери, поэтому остро стоит вопрос регресси-
онного тестирования для данной области ПО.
Верификацию таких автоматизированных систем можно прово-
дить, используя обычный метод регрессионного тестирования, и ис-
пользовать встроенный язык конфигуратора в качестве скриптового
языка, но это нецелесообразно и слишком трудоемко. Использование
специфических особенностей среды разработки [2] позволит миними-
зировать затраты на создание и сопровождение регрессионного тести-
рования.
124
ISSN 0236-3933. Вестник МГТУ им. Н.Э. Баумана. Сер. “Приборостроение”. 2012
1,2 4,5,6,7,8,9,10,11