Я работаю в автоматизации тестирования уже более пяти лет. Более всего я работал с ОС Windows. Мы пишем скрипты на Borland SilkTest. Я знаком и с другими средами разработки автоматизированных тестов, такими как QTP и TestComplete – у каждого продукта есть свои достоинства, но, к сожалению, и свои недостатки. Возникают проблемы, которые очень сложно решить «не выходя из системы»*Не буду хвастаться. Я не самый умный и не самый опытный человек на этой Планете, но моего опыта вполне хватает для решения повседневных задач. Еще 5 лет назад, я получил 3 простых и основных навыка, которыми пользуюсь при решении новых задач до сих пор.
В 10-ом классе я прочел про команды DOS
Это произошло даже 7 лет назад. Я заинтересовался тем, как работают стандартные команды DOS, и о том, что потоки ввода и вывода консольных команд можно выводить в текстовый файл.
Как это может быть полезно? Все очень просто. Вот пример.
Предположим, в одном из тестов вам необходимо получить список всех файлов на диске C:\ до инсталляции тестируемого приложения, и сравнить их со списком файлов после инсталляции. Таким образом, можно будет понять, какие файлы были изменены/добавлены в процессе инсталляции.
Делается это просто следующей командой cmd.exe:
dir C: /B /S > initial_c.txt
Команда dir C: /B /S соберет все файлы, папки и подпапки на диске C: и запишет содержимое в файл initial_c.txt используя функцию перенаправления потокового вывода «>».
Я уже чувствую, как бородатые программисты возмущенно кричат «Автора на кол! Да чтобы мы так программы писали… Да никогда! ». Но, позвольте мне все объяснить.
Первоначально, на SilkTest (язык 4 Test Script) я уже пытался написать рекурсивную функцию, которая путешествовала по дереву каталогов. В итоге получилось, что:
- Функция была сложной. Использование хендлеров на директории, структур с информацией про директории, рекурсии – все это не может быть простым.
- Функция часто спотыкалась об права доступа к некоторым директориям на некоторых системах.
- Как выяснилось позже, работала в 25 раз медленнее, чем dir C: /B /S
Автоматизированное тестирование сродни программированию. Но, в отличии от разработчиков, которые создают продукт, который увидит весь мир – наши тесты не покинут стены компании. Поэтому можно и нужно, чтобы тесты оставались простыми.
Замена тела сложной рекурсивной функции для получения дерева каталогов на простую команду dir C: /B /S – это эффективная и хорошая практика для тестеровщика.
А еще оказалось, что команда xcopy работает стабильней, чем стандартная функция SilkTest SYS_CopyFile, а команда md dir1\dir2\dir3 способна создать директорию несуществующею директорию dir3 в несуществующей директории dir2…
Командная строка таит в себе еще много вкусностей. Стоит упомянуть systeminfo, которая выдает краткую, но очень полезную информацию о системе; wmic – команда, способная выдать полную информацию о конфигурации системы; msiexec – отдельная песня, позволяющая автоматизировать установку Windows приложений на тестовую систему, семейство команд reg *, которые позволяют очень просто получить информацию из реестра Windows; семейство команд net *, используемых для любых необходимых сетевых настроек.
Командная строка – это очень эффективно. Но, я пишу об этом потому, что, по моим наблюдениям, 80% людей ее либо не знают, либо избегают.
Если бы я придумал тайм-менеджмент, то первым постулатом я бы написал:
«Изучи командную строку».
Я написал Блокнот на чистом Win 32 API
Я не просто прочитал книгу П. В. Румянцева «Азбука программирования в Win 32 API». Я тут же пробовал реализовать прочитанное. Скажу сразу, создавать графические приложения на Win API – это вам не сахар. Тут я приклоняю голову перед теми бородатыми программистами, которые писали под Win 3.11/ Win 95 на Win API, и хотели посадить меня на кол вначале этой статьи.
Но, мне было это безумно интересно. После знакомства с Delphi, спрыгнуть от этой абстракции VCL – это было круто. Оказалось, что в Windows всё Окна. Да, любой элемент управления, любой диалог и даже Рабочий стол – это окно. О, поверьте, – это было прозрение. Я научился пользоваться SendMessage, понял, как же все эти окна идентифицируются…
Вскоре, когда я начал работу с SilkTest – познания в Win 32 API мне очень помогли. Сейчас, когда я сталкиваюсь с любой проблемой, которую не могу решить обычными средствами SilkTest – я обращаюсь к экспорту функций Win API.
Свежий пример из моей практики. Перед началом следующего теста, необходимо было собрать список открытых окон сторонних приложений и их дочерних окон. Оказалось, что в SilkTest нет такое функции, которая бы вернула список всех открытых окон. А наш существующий механизм сбора открытых окон, был на костылях, работал очень медленно и часто давал сбои. После того, как мы применили WinAPI функции EnumWindows и EnumChildWindows, время закрытия всех окон уменьшилось 20 раз, с 20 минут, до одной. И новый и значительно упрощенный алгоритм уже не давал огромного количества сбоев, как это было раньше.
Я понимаю, что сегодня программирование под Windows обложено абстракциями .NET Framework WinForms и Windows Presentation Foundation. Но, опыт программирования в спартанских условиях WinAPI, вам будет чрезвычайно полезен. Кроме того, бородатые программисты знают, что тот же .Net Framework 4 не может вам предоставить всего того функционала, который предоставляет Windows API, так что очень часто, в серьезных проектах используется импорт Windows API функций, так называемый P/Invoke.
Так что не поленитесь добыть навык программирования Win32 API.
Я изучил Perl
Это было 5 лет назад, и много воды утекло с того времени, и много взглядов поменялось. Сейчас я уже не хочу яростно заверять вас, что Perl – это лучший язык программирования на этой Планете. Возможно, он будет вновь популярен на какой-нибудь другой планете, на которой он официальный международный язык программирования. Но, я хочу дать один совет – изучите любой динамический язык программирования, который вам понравиться. Сейчас, я чувствую огромный потенциал у Ruby. Возможно потому, что это гремучая смесь Питона и Перла. Перед тем как я начал писать на Перле, у меня за плечами был старый добрый лабораторный Паскаль и немного Си. Вы себе не представляете, насколько много кусков разлетелся, взорвавшись, мой мозг. На Перле для меня было дико интересно писать скрипты. Я начал с небольших веб-скриптов из учебника, и через год создал сайт своего колледжа на собственном кривом движке. Но, это было очень интересно. Через год, после того, как я устроился на работу, я написал систему мониторинга и отчетности для нашего процесса автоматизированного тестирования. Мы ей до сих пор пользуемся.
Подчеркиваю, не я один ей пользуюсь, а вся наша команда и начальство, а это безумно приятно.
А все благодаря негативной мотивации. Да, если бы я этого не сделал, то до сих пор сидел бы и дергал отчеты из Outlook в Excel. Нет, скорее все благодаря Перлу. Потому что, в тот момент, это было очень просто получить отчет о тестировании из почты, распарсить данные и поместить их в таблицу MySQL. А дальше – поднять свой сервер, и выводить данные, используя свой, но уже менее кривой движок.
Кроме того, не раз Перл спасал мне очень много времени и спасал меня от смерти от рутинной работы. Один раз мне дали задание перенести 3 мегабайт текстовых данных из старого формата в новый, при этом необходимо было быть очень внимательным, чтобы не допустить ошибки. И старый и новый формат данных был очень прост. За полдня я написал и оттестировал скрипт, который перегнал все нужные данные за следующие 3 секунды. Следующие 3 дня я занимался более интересными делами, а задание сдал заказчику на день раньше.
Вторым постулатом тайм-менеджмента я бы сделал: «Изучи Perl!», ну ладно, более политкорректно:
«Изучи любой динамический язык программирования»
* Невозможно решить проблему на том же уровне, на котором она возникла. Нужно стать выше этой проблемы, поднявшись на следующий уровень.
Альберт Эйнштейн
