Выбрать время и "заточить" лопату

Опубликовано Feb 14, 2011 в Наш опыт | 3 коммент.

,

Выбрать время и "заточить" лопату

Автор: сотрудник компании FulcrumWeb, Сергей.

Июль 2010 года, в Харькове жара до +40, лежу себе на пляже, никого не трогаю, играю в волейбол. Вдруг звонит шеф и произносит слова: «Тут намечается твоя поездка в Штаты на неделю. Хочешь? Можешь?». Естественно и хотел и мог. Это было уже мое второе путешествие через Атлантику за время работы в компании. Цель стандартная – отчитаться о проделанной за год работе, обсудить насущные проблемы, набрать комплект заданий на следующий год, а главное – увидеть заказчика вживую и предоставить ему такую же возможность.

Через пару недель уже с коллегой сидим по ту сторону океана в кабинете для совещаний. Закончена первая часть визита: полностью отчитались о проделанной работе, выяснили спорные моменты, начинаем обсуждать проекты на будущее. Один из сотрудников со стороны заказчика произносит следующие слова: «Мы так устали использовать текстовый скрипт для тестирования системы, нужно придумать что-нибудь более удобное».

Вкратце обрисую ситуацию. Давным-давно в тридевятом царстве, в тридесятом государстве всезнающими волшебниками был разработан медицинский аппарат. Аппарат этот состоит из двух частей, и, как ни странно, эти части называются «аппаратная» и «программная». Аппаратную я описывать не буду, так как сам ее не знаю, но программная часть представляет собой оболочку над Window XP Embedded, наподобие тех, которые ставятся на обычные банкоматы, только намного более тяжеловесная. Реализовано все это волшебство на С++.

Естественно со временем система развивалась. Естественно перед выпуском каждой новой версии необходимо было проводить тестирование этой самой системы. Тестирование состоит из двух частей: ручного тестирования и автоматизированного. Я думаю все уже догадались, что речь пойдет не о первом из этих двух.

Так вот для автоматизированного тестирования был разработан целый скриптовый язык, на котором можно писать тестовые сценарии. Соответственно для аппарата был создан интерпретатор этого языка, который подгружает эти сценарии из текстовых файлов, строит из них последовательность команд и непосредственно выполняет. С тех пор, а прошло уже приличное количество лет, как для программного обеспечения, ничего не менялось.

Теперь представьте себе ситуацию: 2010 год, мощности мобильных телефонов вполне сравнимы с мощностью моего первого компьютера, Интернет есть практически в любой точке Земного шара, средства для разработки ПО чуть ли не сами создают за разработчика программы, а в это время кто-то сидит в «Блокноте» и набирает текстовые скрипты, не имея при этом ни IntelliSense, ни отладчика. Звучит удручающе.

Итак, после недолгих размышлений было принято решение заменить текстовый скрипт на .NET (C#).

Теперь вкратце попытаюсь объяснить как все это работает.

Система состоит из COM-модулей, реализованных на С++. Каждый модуль представляет собой обычный класс, реализующий специальный интерфейс (IPackage), который в свою очередь унаследован от IDispatchImpl. Обычно класс-реализация интерфейса помещается в отдельную библиотеку. Таким образом получается, что каждая библиотека содержит в себе отдельный модуль.  Все эти модули регистрируются в Windows и во время запуска системы главный модуль (Loader) загружает в память нужные.

Модуль может представлять собой что угодно: конфигурационное диалоговое окно, кнопку, визуализатор медицинских данных и т.д. Между собой модули могут обмениваться сообщениями посредством метода HandleEvent(), объявленного в интерфейсе IPackage. В этом методе передается имя события и сопутсвующие служебные данные. Естественно каждый модуль обязан реализовать этот метод. Таким образом достигается гарантия того, что каждый модуль может обрабатывать сообщения, сгенерированные другими модулями а также генерировать собственные сообщения и предоставлять возможность другим модулям их обрабатывать. Вот такой вот свиду незамысловатый способ общения позволяет уживаться вместе более 60 модулям.

Например была нажата кнопка на клавиатуре. За обработку сообщения от Windows отвечает один модуль (назовем его KeyboardPackage). Этот модуль ловит сообщение от Windows, формирует на основе этого сообщение во внутреннем формате, а дальше бросает обработку этого сообщения на растерзание других модулей. При генерировании одного и того же сообщения поведение системы может очень сильно варьироваться, в зависимости от того, какие модули загружены в данный момент.

Я думаю читатель уже догадался, что тестирование осуществляется именно на основе генерирования сообщений. Для этого был создан еще один COM-модуль (TestPackage), который реализует интерфейс IPackage, но реализует он этот интерфейс на .NET-e. Самое интересное, что именно благодаря тому, что используется подсистема COM, TestPackage, реализованный на .NET, способен как сам генерировать сообщения, так и обрабатывать сообщения, сгенерированные другими модулями, написанными на С++. Используя подобные возможности взаимодействия COM и .NET, а также архитектурное построение самой системы, TestPackage генерирует необходимые сообщение точно также, как это бы сделал пользователь при помощи клавиатуры и мыши. Система при этом абсолютно адекватно все обрабатывает.

Этим проектом мы занимаемся уже почти 6 месяцев, и за это время мы успели написать множество классов, которые автоматизируют отсылку специфических сообщений и проверку правильности их обработки.

Конечной целью является предоставить будущим инженерам возможность писать на .NET свои тестовые сценарии, используя набор удобных .NET-классов над чем мы сейчас и работаем. Уверен, что мы сможем избавить будущих инженеров от необходимости проводить приличное количество времени для написания тестовых сценариев в «Блокноте» и отлаживать их, имея единственный инструмент – лог-файл, а предоставим им соответствующий набор классов, а Visual Studio предоставит все свои расширенные возможности по написанию программ и их отладке. Так стоит иногда отвлечься от рутиной работы и как говорится “заточить лопату” заложив хорошую архитектуру для более быстрой разработки в будущем.


3 Коммент. : “Выбрать время и "заточить" лопату”

  1. Смотря как был реализован текстовый скрипт – но я так понял, что на нем было сложнее составлять сценарии, чем писать объектно-ориентированные программы, иначе бы не имело смысла что-то менять. Хотя в принципе, текстовый сценарий мог бы быть даже проще, чем написание .NET программы – все зависит от правильной реализации.
    Вот если бы вы писали скрипт-рекордер, где нажатия мышкой на определенные кнопки и ввод с клавиатуры хаписывались, а потом воспроизводились – тогда безусловно было бы удобнее.

    Ну а удобный парсер-визуализатор логов – это отдельная песня, – его можно написать даже оставив старый скриптовый язык.

  2. А как будете бороться с народными привычками?
    Или, вернее, уже побороли :) , с момента публикации статьи уже пару лет прошло. Может, конечно, американцы честнее и сознательнее наших и переучиваются на что-то новое быстрее.
    В наших реалиях фраза типа “мы в блокноте набираем скрипты”, очень похожа на отмазку, оправдывающую любые затраты рабочего времени.
    И , скорее всего , после внедрения нового способа написания сценариев, возникнут новые отмазки и не одна. Собственно, на нововведения нерадивые товарищи первое время смогут валить все, начиная от собственной тупости и заканчивая собственной ленью.

    • Галина says:

      Если речь идет о наших народных привычках, то их, в целом, уже перебороли. Давно работая с теми же американцами приходится перенимать их народные привычки. Лучше ли они по всем пунктам – это уже совсем другой вопрос…

Оставить комментарий

Ваш адрес email не будет опубликован.


*