понедельник, 18 ноября 2013 г.

Формирование тестовых данных, хранящихся в базе данных MS SQL Server

   Хотелось бы немного поговорить на тему формирования тестовых данных для автотестов. 
  Дальше будут написаны довольно очевидные вещи насчет независимости тестов друг от друга, поэтому те, кто знаком с этой информацией, могут пропустить этот абзац :) Итак, ни для кого не секрет, что тесты у нас должны быть независимыми друг от друга. Рассмотрим простой пример. Предположим, у нас есть 2 теста - один проверяет добавление пользователя, другой редактирование информации о пользователе. В тесте на редактирование нельзя использовать в качестве тестовых данных (начальных данных) результат, полученный после теста на добавление пользователя. Допустим, если тест на добавление создает пользователя "flower", то в тесте на редактирование мы должны редактировать, например, свойства пользователя "fruit", а не "flower". Почему так? Во-первых, если вы решите в тесте на редактирование использовать пользователя "flower" в качестве тестовых данных, то вы не сможете выполнить этот тест отдельно, вам всегда придется сначала выполнять тест на добавление пользователя. Во-вторых, если добавление пользователя по каким-то причинам не будет работать, вы также не сможете выполнить тест на редактирование. Отсюда следует вывод, что для теста на редактирование вам нужны тестовые данные.

среда, 13 ноября 2013 г.

Тестирование при разработке с использованием Kanban. Пример из жизни.

    Друзья, всем привет!
  Хочу рассказать вам немного о нашем процессе разработки программного обеспечения и методологиях, которые мы применяем. А особенно о том, как у нас организуется тестирование при использовании этих методологий. Для организации процесса разработки мы начинали использовать Scrum, потом перешли на Kanban. Очень подробно и понятно эти методологии описаны в книге Хенрика Книберга и Маттиаса Скарина «SCRUM и Kanban: Выжимаем Максимум». Она небольшая и очень полезная, даже если вы уже работаете по одной из этих методологий, советую прочитать, чтобы упорядочить свои знания.
    Kanban - достаточно свободная методология, содержащая не так много правил:
- визуализация потока работ (работа разбивается на части, каждая часть находится на какой-то стадии выполнения - в каком-то столбце)
- ограничение НЗР (незавершенной работы) (определение возможного количества незавершенных пунктов на каждой стадии процесса разработки ПО)
- измерение времени выполнения задачи (нужно свести время выполнения задачи к минимуму и сделать его максимально прогнозируемым).

понедельник, 11 ноября 2013 г.

Установка Windows приложения в тихом режиме.

    Очередная статья моя блога так и хочет увидеть свет. Не могу ей отказать в этом, поэтому встречаем:)
   Предположим ситуацию, когда вам нужно обеспечить процесс сборки приложения, его деплоймента на какую-либо машину и последующего тестирования. И деплоится у вас не просто exe-файл приложения, а файл-установщик. Поэтому перед стадией тестирования у вас появляется еще одна небольшая задачка по установке вашего приложения на машину для тестирования. Установить такое приложение вам нужно в тихом режиме, т.е. без взаимодействия с пользователем. Как же это сделать?
   Все легко и просто. Для установки приложений у нас служит установщик Windows «msiexec.exe». Его и будем использовать.
  Чтобы сделать установку приложения в тихом режиме вручную, нужно в командной строке выполнить следующую команду:

        msiexec /q /i C:\MyProject\setup.exe

    На С# это выглядит так:

вторник, 5 ноября 2013 г.

Сборка проектов с Coded UI тестами во время билда на TFS без установленной Visual Studio

   Дааа, друзья мои, понадобилось однажды мне сделать и такое. Администратор билд-сервера TFS был против того, чтобы устанавливать студию на сервер во избежание присутствия лишних зависимостей. И в один прекрасный солнечный денек, когда он удалил студию с билд-сервера, билд для сборки решения с Coded UI тестами перестал проходить. Далее я расскажу вам, как мы решили эту проблему.
   Когда мы создаем новый проект с тестами, наши ссылки на сборки выглядят так:

   Все сборки Visual Studio, на которые ссылается данный проект, расположены в установочной папке студии. 
  1. Первое, что нам нужно сделать, это скопировать эти сборки в какую-то папку с библиотеками в нашем проекте и положить эти сборки под source control. Для каждой сборки смотрим ее расположение, и затем копируем сборку из ее расположения в специально созданную для этого папку. Расположение можно посмотреть в окне свойств.
  2. Затем, удаляем эти ссылки на сборки из нашего проекта. После выгружаем проект, чтобы отредактировать файл проекта.

   3. В файле проекта нам нужно закомментировать выделенную часть, иначе ссылки на сборки будут автоматически добавляться в наш проект каждый раз, когда мы снова будем загружать его.

4. Все, что нам осталось - это сохранить файл проект, сделать «Reload Project» и вручную добавить ссылки на эти же сборки, которые находятся в специально созданной нами папке библиотек (в п.1).

Примечание. Единственное, где у вас выйдет ошибка, это в следующей ситуации


Хотя, если мы будем добавлять новый файл с Coded UI тестами через «Add - New Item...» и там уже выбрать тип файла - Coded UI тест - то все пройдет успешно.

вторник, 22 октября 2013 г.

Trello - доска для организации работы по методологии Kanban

Привет, мои дорогие читатели!
Что я вам давно хотела рассказать, но не рассказывала - это то, что мы на моей работке работаем (во всяком случае стараемся) по гибкой методологии Kanban. И в этом нам очень помогает доска Trello.
Цель этого сообщения - не рассказать вам о возможностях Trello. Погуглив, вторая и третья ссылки выведут вас на статьи, в полной мере раскрывающие возможности этой программы. Просто вдруг вы еще не слышали про Trello, а оно может сделать вашу жизнь чуточку лучше :)

пятница, 11 октября 2013 г.

Как быстрее проверять автотесты во время их разработки

    Ни для кого не секрет, что процесс выполнения UI автотестов не очень быстрый. А во время создания автотеста часто приходится запускать его на выполнение несколько раз и ждать, пока он пройдет. В целях экономии времени я использую несколько способов для сокращения времени проверки работоспособности теста во время его создания, о которых и хочу рассказать. Все примеры взяты из моего опыта, надеюсь, что-то будет полезно.
    Для начала опишу немного архитектуру тестового фреймворка. Инструменты - Visual Studio, C#, CodedUITest, MsTest.

Архитектура тестового фреймворка.

     Допустим, мы тестируем desktop-приложение, требующее определенное время на свою загрузку после запуска, например, 10-15 секунд. Нам невыгодно запускать приложение перед каждым тестом, и закрывать после каждого теста, поэтому мы решаем построить наш фреймворк по такой простой схеме:

  • все классы с тестами наследуются от базового класса RunAppTestFixtureBase
  • у этого класса есть метод, помеченный атрибутом [TestInitialize] (для unit-testing фрейморка Visual Studio, для других фреймворков атрибут может называться по-другому), который проверяет, запущено ли наше приложение, и в случае, если нет, запускает его.
    Таким образом, общую инициализацию тестов мы выносим в базовый класс. Этот метод инициализации может содержать какие-либо дополнительные действия, специфичные для тестирования вашего приложения.
  • В методе [TestCleanup] базового класса мы не указываем, что приложение должно закрываться. По окончании выполнения всех тестов оно закроется автоматически средствами MsTest.
    Отсюда сразу вытекает первый способ сокращения времени выполнения теста при его написании и отладке:

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

2 способ
     В самом простом случае тест у нас состоит из трех логических частей - Setup, Execute и Assert - т.е. какие-то действия по установке начальных значений, непосредственно сами действия, которые мы тестируем, и проверки. 
     Предположим, у вас успешно прошли первые две логические части, а в последней части, части проверок, вы допустили ошибку - например, указали неверные тестовые данные. Вы ее исправляете, и нужно опять проверить, что тест работает хорошо. Поскольку части Setup и Execute уже отлажены, можно просто закомментировать их на время в тесте, привести приложение в то состояние, в котором оно будет после выполнения этих двух частей и запустить тест, в котором фактически выполнится только часть Assert. Это также сэкономит вам время.

3 способ
     У меня не раз случались ситуации, при которых были проблемы с действиями с некоторыми контролами. Например, CodedUI-фреймворк иногда считает контрол заблокированным и выдает исключение, что не может выполнить с ним необходимое действие, например, кликнуть мышкой. Или другая ситуация, когда не может найтись какой-то контрол. Представим, что действие с этим контролом у вас находится в середине или ближе к концу теста, и пока до него дойдет дело, вам нужно пройти кучу форм. Тут можно либо воспользоваться способом 2, либо создать отдельный проект, Sandbox, в котором проводить эксперименты с такими контролами. А потом найденное решение просто перенести в ваш проект.

среда, 9 октября 2013 г.

Работа с TFS. Определение тест-кейсов, несвязанных с тестовыми методами.

Привет, друзья!
Чтобы не заскучать на работе, и, конечно, быстрее выполнять поставленные передо мной задачи, я периодически думаю, как их можно автоматизировать, чтобы  в итоге сделать работу быстрее и интереснее. 
Как я рассказывала здесь, у нас настроен процесс автоматического запуска тестов на виртуальной машине. Одним из условий для успешного запуска является связь тест-кейса как Work Item из TFS с тестовым методом в какой-либо сборке с тестами. В Microsoft Test Manager это выглядит так:

Процесс связывания тест-кейса с тестовым методом достаточно нудный, я еще подумаю/погуглю насчет того, как его улучшить, обещаю :)
У меня иногда бывали случаи, когда я забывала связать уже имеющиеся тест-кейсы с методами. Либо наоборот, были написаны автотесты, но тест-кейсы для них еще не созданы. Проверять, какой же тест-кейс или тестовый метод не имеет привязки, очень скучно и долго. Поэтому я решила написать для этого несколько хелперов. Не забудьте подключить в проекте сборку Microsoft.TeamFoundation.TestManagement.Client.dll.

среда, 2 октября 2013 г.

Обходные пути в автоматизации тестирования при работе с TFS. Использование авторизации.

Всем привет.
В этот пасмурный (даже в Ростове-на-Дону) осенний денек хочется внести некоторые уточнения в мою предыдущую статью.
Там приводился код для работы с TFS, который успешно проходил в том случае, если вы уже подключены к TFS с использованием учетной записи, которая имеет соответствующие права доступа. В случае, если это не так, нужно выполнить аутентификацию в коде. Тогда наш код будет выглядеть следующим образом:

вторник, 27 августа 2013 г.

Обходные пути в автоматизации тестирования при работе с TFS.

       Привет, мой дорогой читатель. Вот очередная история из моего мира автоматизации тестирования.
       На автоконфетке весной 2012 года Дмитрий Жарий выступал с докладом об обходных путях в автоматизации тестирования. Я пыталась найти видео доклада в его блоге, не нашла. Дима, если ты читаешь это, то может дашь ссылочку людям, очень хороший доклад :)
Так вот, о чем это я. Очень мне тогда понравилась эта идея. Вот как я ее вижу.
       У нас на проекте есть определенное количество багов (о которых мы знаем), из-за которых падают автотесты. Причем баги эти в ближайшее время фикситься не будут. Учитывая, что в UI автотестах часто бывает не 1, а гораздо больше проверок, то те проверки, которые идут после падающей, уже не выполняются. Еще один минус состоит в том, что проверяя результаты запуска UI тестов каждый день , ты уже не концентрируешь внимание на этих падающих тестах - они же всегда падают. А эти тесты могут упасть уже по другой причине, которую ты не заметишь. Но основная идея для меня заключается в том, что тесты служат для нахождения новых багов, а не подтверждения существования уже известных. Для решения перечисленных проблем и служит обходной путь в автоматизации тестирования. Все, что нам нужно - это проверять в конкретном тесте, пофикшен баг или нет. Если не пофикшен, то мы можем пропустить эту проверку. Если пофикшен - то выполнить (либо таким же образом определять ожидаемый результат, а не факт выполнения проверки). Таким образом, тесты у нас всегда будут зелеными. А если станут красными - значит мы поймали какой-то новый баг.
      Поскольку я работаю с TFS, моя задача определения состояния бага значительно облегчается.
1 шаг - подключим в проект необходимые сборки



2 шаг - создадим класс со статическим методом, который проверяет состояние бага:


3 шаг - используем этот метод в тесте, например, так:

Таким образом, когда баг пофиксят, вам ничего не придется менять в тестах, потому что автоматически подхватится корректное значение для проверки.
А вообще конечно, лучше бы тесты всегда были зелененькими, потому что багов нет :)) Эх, мечты, мечты :)

вторник, 6 августа 2013 г.

Генерация C# тестов для Windows приложений при помощи Coded UI

Все привет! Делюсь с вами записью моего выступления на автоконфетке 2013, где я рассказывала, как использовать Coded UI для генерации тестов.




среда, 17 июля 2013 г.

Расширения для Coded UI Test

     И снова здравствуй, мой дорогой читатель. Что-то я зачастила сюда) Просто ручки дошли наконец сделать то, что давно хотела.
    Всем поклонникам Coded UI посвящается - небольшая библиотечка расширений для классов Wpf контролов, которые очень мне помогают.
   Ссылочка вот - https://codeduitestextensions.codeplex.com/.
   Пока их немного, но надеюсь, проект будет обновляться и пополняться новыми расширениями.

вторник, 16 июля 2013 г.

C# хелперы для автоматизации тестирования

     Привет, мой дорогой читатель. Давно я не баловала тебя своим вниманием. Сейчас лето, так что не будь в обиде :)
     Во время автоматизации все мы пишем какие-то хелперы. Давно у меня зрела мысль объединить их в один проект и развивать дальше, чтобы эти хелперы можно было переиспользовать и в других проектах. И наконец-то ручки дошли это сделать. Надеюсь, что-то окажется для вас полезным в настоящем или будущем.
   Ссылочка вот - https://uitestinghelpers.codeplex.com/.
   Пока их немного, но надеюсь, проект будет обновляться и пополняться новыми хелперами.
 

понедельник, 17 июня 2013 г.

вторник, 4 июня 2013 г.

Использование Specflow для автоматизации тестов на русском языке

Всем привет! Сегодня меня 2 раза спросили про Specflow. Затем я увидела пост на хабре про Specflow. И поняла - вот он тот драгоценный момент, чтобы поделиться с вами записью моего выступления на автоконфетке осенью 2012 года, где я рассказывала про использование Specflow в автоматизации тестирования. Другого шанса судьба мне может не дать =))
Ловите презенташку и видео.




среда, 8 мая 2013 г.

Рефакторинг. Предварительные приемы.

   Наверняка многие из нас, особенно те, кто пишет программный код,  слышали о рефакторинге. Хочу поделиться с вами предварительными приемами рефакторинга, взятыми из замечательной книжки - "Рафакторинг в C# и Asp.Net для профессионалов", Даниэль Арсеновски. Отличная книга, в ней все разложено по полочкам с объяснениями на практических примерах, всем советую.
   Для начала, определение.
 Рефакторинг - это набор приемов, используемых для идентификации потока дизайна и модификации внутренней структуры кода с целью совершенствования дизайна без изменения видимого поведения кода.
    Рефакторинг состоит из трех шагов:
1. Идентификация кода с душком.
2. Применение подходящего рефакторинга.
3. Выполенение unit-тестов.

   Предварительные приемы рефакторинга обычно выполняются на уровне синтаксиса. К ним относятся следующие:
1. Исключение мертвого кода.
Он может быть в виде закомментированных участков кода, игнорируемых параметров и возвращаемых значений методов, неиспользуемых методов и т.д.. Такой мертвый код вносит путаницу и дополнительную сложность и должен быть удален.

2. Сокращение области видимости и уровня доступа излишне открытых элементов.
Открытие ненужных внутренних деталей противоречит принципу хорошо инкапсулированного кода - принципу сокрытия информации/реализации.

3. Использование явного импорта.
При чтении кода вы полагаетесь на раздел импорта, чтобы выявить зависимости, присутствующие в коде. Использование полностью уточненных имен вместо раздела импорта может значительно затруднить понимание зависимостей в коде. Поэтому предпочтение стоит отдавать явному импорту.
Пример:
вместо
  System.Xml.XmlDocument doc = new System.Xml.XmlDocument();
использовать
  using System.Xml;
  ......
  XmlDocument doc = new XmlDocument();

4. Удаление неиспользуемых ссылок на сборки.
Неиспользуемые ссылки - это почва для излишних зависимостей. Эта зависимость говорит разработчикам, что они могут использовать службы, предоставленные ссылаемой сборкой. Если ссылка не будет удалена из проекта, то в какой-то момент в будущем она будет использована вновь. Такой путаницы нужно избегать.

вторник, 30 апреля 2013 г.

Coded UI Test. Работа с глубоко вложенными контролами в WPF.

        Хочу поделиться с вами ссылкой о том, как тестировать окно WPF-приложения в случае, когда присутствует глубокая иерархия контролов. Мне эта статья в свое время очень помогла. Благодаря ей получается красивая UIMap окна, соответствующая реальной структуре его контролов.
       Всех с наступающими праздниками :)

суббота, 20 апреля 2013 г.

Coded UI Test. Увеличение скорости работы с контролами.

      В одной из статей своего блога я писала про то, как увеличить работу с текстовым полем. И хотя определенное решение было найдено, меня не оставлял в покое вопрос, почему же в текстовое поле так долго вводится текст. Даже бесплатный фреймворк White вводит текст очень быстро. А тут платный, крутой Coded UI, от самих Microsoft, чьей преданной поклонницей я являюсь)) Я гуглила не один раз, и в различных блогах натыкалась на такие же жалобы и различные варианты решения этой проблемы.
     И все-таки решение нашлось. А всего-то надо было внимательнее читать msdn. Еще раз убедилась, что там можно найти практически все, что  надо для успешной работы. Все оказалось так просто и очевидно, что я удивилась, как это решение не нашлось раньше.
    В CodedUI есть специальный класс Playback, который отвечает за различные настройки проигрывателя ваших тестов. Все, что требуется, это установить одно его свойство:

          Playback.PlaybackSettings.WaitForReadyTimeout = 100;

где 100 - это количество мс, тут уже играйтесь с настройками так, как вам нужно.

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

пятница, 19 апреля 2013 г.

Расширения для Coded UI Test

     Данная статья будет полезна тем, кто разрабатывает C# тесты для автоматизации UI приложения. При разработке тестов часто бывает так, что средств, предоставляемых выбранным фреймворком для тестирования (в нашем случае UI) недостаточно для решения конкретной задачи, и приходится подпиливать его под свои нужды. Раньше я уже описывала несколько способов решения таких проблем касательно Coded UI. Хочу рассказать еще об одном, самом универсальном способе - создании методов расширения для работы с контролами.
     Рассмотрим самый простой пример.
     Я сталкивалась с такой ситуацией, когда UI приложения был сформирован таким образом, что реальный пользователь мог кликнуть мышкой по кнопке, но при использовании стандартного метода Mouse.Click(control) выходило исключение, говорящее о том, что это контрол заблокирован (хотя на самом деле он не был заблокирован). Эту проблему можно решить, создав метод расширения для класса Mouse фреймворка Coded UI, который позволит сделать клик на таком контроле:


    /// <summary>
    /// Класс расширений для работы с мышью.
    /// </summary>
    public static class MouseExtension
    {
        /// <summary>
        /// Осуществляет Click() левой кнопкой мыши, служит для заблокированых контролов.
        /// </summary>
        /// <param name="mouse">Мышь.</param>
        /// <param name="controlBoundingRect">BoundingRect контрола.</param>
        public static void ClickOnBlockingControl(this Mouse mouse, Rectangle controlBoundingRect)
        {
            Point clickablePoint = Point.Add(controlBoundingRect.Location,
                new Size(controlBoundingRect.Width / 2, controlBoundingRect.Height / 2));
            Mouse.Click(clickablePoint);
        }
    }

Тогда в коде какого-то метода, осуществляющего клик по контролу, этот метод расширения можно использовать следующим образом:

Mouse.Instance.ClickOnBlockingControl(UIMyButton.BoundingRectangle);
           
Аналогично можно делать методы расширения для любых контролов. По такому принципу построены библиотеки утилит для работы с CodedUI тестами, о которых я писала ранее.


среда, 10 апреля 2013 г.

Про тестировщиков в картинках

Вот и прошла очередная конференция FunConfeT&QA. Она была очень интересной. Я принимала в ней участие благодаря победе в конкурсе, который проводился на сайте software-testing.ru.


А вот и моя работа, благодаря которой я в этом конкурсе выиграла, надеюсь, она заставит вас улыбнуться :)

четверг, 4 апреля 2013 г.

Краткое описание использования White для автоматизации тестирования Windows приложений

Как и обещала в предыдущем посте, расскажу самые основные моменты в использовании White для тестирования Windows приложений. Фактически, все рассказанное является кратким содержанием документации.

Работа с приложением и окном.

Запуск приложения и нахождение его окна

   Application application = Application.Launch("MyApp.exe");
   Window window = application.GetWindow("MyWindowTitle", InitializeOption.NoCache);

Нахождение модальных окон для главного окна:
Window childWindow = mainWindow.ModalWindow("СhildWindowTitle");

Закрытие окна

window.Close(); 

Закрытие приложения

application.Kill();


вторник, 26 марта 2013 г.

White - фреймворк для автоматизации UI desktop-приложений

White - это бесплатный фреймворк для автоматизации UI desktop-приложений. Найти его можно тут. Некоторое время назад он был передан на поддержку другим ребятам, старую документацию, и что самое главное, обсуждения и решения проблем, можно найти тут. Это .Net фреймворк, поэтому автоматические тесты можно писать с использованием любого .Net языка программирования. Я в своей практике использовала C#. Построен он на базе библиотеки Microsoft UIAutomation.
К плюсам я бы отнесла следующее:
- бесплатность
- возможность скачать исходники и подпилить его под свои нужды

К минусам можно отнести следующее:
- непонятная ситуация с поддержкой, какое-то время вообще не поддерживался, сейчас в него пытаются вдохнуть вторую жизнь

Я пользовалась им для автоматизации UI небольших WPF desktop-приложений со стандартными контролами, для этих нужд его вполне хватало, и скорость работы была приемлемой.

Если кого-то заинтересует этот фреймворк, пишите, могу расписать поподробнее основные его возможности, поиск контролов, работу с ними и т.д. :)


четверг, 21 марта 2013 г.

Ревизии в тестировании

Все мы знаем такое понятие, как code review. Чаще всего оно конечно используется у программистов для проверки кода, написанного каким-то одним программистом, другими разработчикам. Но ревизии кода (и не только кода) можно использовать и в тестировании.

Я бы выделила несколько вариантов возможных ревизий в тестировании.
1. Ревизия кода автотестов разработчиком.
Автоматизатор, создающий фреймворк для тестирования приложения, пишет программный код, значит его тоже можно проревизировать.
Мне такие ревизии больше всего помогали прокачивать скилы в языке программирования, архитектуре тестов и т.д. Разработчик больше смотрит с точки зрения именно кода.

2. Ревизия кода автотестов другим тестировщиком/автоматизатором.
От таких ревизий больше знаний можно получить именно со стороны автоматизации тестирования.

3. Ревизия тест-кейсов.
Такие ревизии в команде тестировщиков мы проводим регулярно. Всегда оказывается очень полезно, когда кто-то посмотрел твои тест-кейсы и вы потом все вместе их обсудили. Можно быть более спокойным, что ты ничего не пропустил.

И вообще надо помнить, что цель ревизии - не указать на ошибки, а основываясь на опыте и знании всех, кто принимает участие в ревизии, получить наиболее правильный и качественный результат :)

четверг, 7 марта 2013 г.

С 8 марта!

Хочется в этот прекрасный весенний день поздравить всех девушек, а особенно девушек, работающих в сфере разработки программного обеспечения, с 8 марта!!!
Желаю всего-всего-всего, что обычно желают на 8 марта :)))
А еще, чтобы каждая из нас совмещала красоту Пенни, ум Эми и зарплату Бернадетт (это из Теории Большого Взрыва... как, ты не знаешь про Теорию Большого Взрыва?... а ты точно в IT работаешь?..). А цветочки пусть нам дарят  не только по праздникам :)

И напоследок для любителей студии небольшая картиночка ^_^


вторник, 5 марта 2013 г.

Backup & Restore базы данных Sql Server 2008 на C#

Если ты, мой дорогой друг, читаешь эту статью, значит тебя заинтересовал ее заголовок. Что в свою очередь значит, что ты знаком с такими операциями Microsoft Sql Server, как создание резервной копии базы данных (backup) и разворачивание базы данных из бэкапа (restore). Мне тоже приходилось не один, и даже не два раза проделывать эти операции из Management Studio.   Некоторым людям приходится делать эти операции каждый день. И вот что я скажу, мой дорогой читатель, вручную это делать реально надоедает. Вот как это можно автоматизировать на C#.

Создание резервной копии базы данных:

Создадим консольное приложение и подключим следующие библиотеки:

понедельник, 4 марта 2013 г.

Что нового ты узнал за последнее время?

Проводилось у нас сегодня в фирме собеседование на должность программиста. Я сидела себе за стеночкой, работала, и в полуха слушала, какие вопросы задаются и какие ответы отвечаются :) И очень понравился мне вопрос, который спросил один сотрудник: "Что нового ты узнал за последние 2-3 месяца?". Я сразу перевела этот вопрос на себя, а что нового я узнала по своей любимой профессиональной деятельности. Сначала даже испугалась - а вдруг ничего?.. Это же значит, что я совсем не развиваюсь, стою на месте. Но потом мгновенный испуг прошел, и я стала вспоминать одну за другой несколько полезных вещей - узнала то-то по используемому тестовому фреймворку, прочитала книжку, послушала доклады, прочитала полезную статью и т.д.. Фууух))


Но вопрос все равно заставил задуматься - иногда в череде рабочих дней не остается время на самообразование. Хочешь что-то прочитать, посмотреть - и все время откладываешь. Я стараюсь каждый день выделять немножко времени, чтобы почитать полезное из блогов, прочесть хотя бы главу из какой-то книги, и посмотреть доклад с последней конференции по тестированию (правда не всегда получается). Классно, когда изучаешь что-то новое в процессе работы, но такое бывает не всегда, поэтому нужно всегда толкать себя вперед. Мир информационных технологий не стоит на месте, и мы не должны :)
А вы узнали что-нибудь новое за последние несколько месяцев?

вторник, 19 февраля 2013 г.

Юмор. Релиз в картинках

В моей компании работают веселые и оригинальные люди, вот результат творчества некоторых из них.

1. Радость от регресса перед релизом, когда определенная его часть выполняется вручную.


2. Релиз



среда, 13 февраля 2013 г.

CodedUITest. Работа с ComboBox.


Продолжу рассказывать про работу с разными контролами в CodedUITest. Теперь настала очередь ComboBox. Для работы с этим контролом в CodedUITest служит класс WpfComboBox.
Будем работать со следующим небольшим приложением, содержащим два контрола ComboBox:


  

четверг, 24 января 2013 г.

CodedUITest. Увеличение скорости работы с текстовым полем.

Комментарий к предыдущему посту про утилиты для CodedUITest заставил меня задуматься о том, как же увеличить скорость работы coded UI tests, потому что не секрет, что они работаю небыстро.
Первая операция, про которую я хочу рассказать, и которая выполняется иногда ну ооооочень долго, это ввод текста в текстовое поле. Хотя такая распространенная операция, ай-ай-ай. Скорость выполнения этой операции непостоянная, бывает, что она выполняется быстро, но также часто бывает, что она выполняется очень долго. Стандартными средствами текст в текстовое поле вводится так:

WpfEdit UINameTextBox;
UINameTextBox.Text = "Иван"

Или второй способ:

Keyboard.SendKeys(UINameTextBox, "Иван");

Но оба они работают не очень быстро, а иногда и очень долго.
Как можно ускорить эту операцию? По сути, операция ввода в текстовое поле состоит из следующих - кликнуть в текстовое поле, удалить старый текст (если он есть) и ввести в новый. Мы можем создать наследника класса WpfEdit и переопределить у него свойство Text нужным нам образом:

    /// <summary>
    /// Класс для работы с контролом текстового поля.
    /// </summary>
    public class WpfEditEx : WpfEdit
    {
        /// <summary>
        /// Создает и инициализирует класс текстового поля.
        /// </summary>
        /// <param name="parentControl">Родительский контрол.</param>
        public WpfEditEx(WpfControl parentControl)
            : base(parentControl)
        {
        }
 
        /// <summary>
        /// Создает и инициализирует класс текстового поля.
        /// </summary>
        public WpfEditEx()
        {
        }
 
        /// <summary>
        /// Возвращает/устанавливает текст текстового поля.
        /// </summary>
        public override string Text
        {
            get
            {
                return base.Text;
            }
            set
            {
                Mouse.Click(this);
                Keyboard.SendKeys("A"ModifierKeys.Control);
                string text = (value.Length == 0) ? "{DELETE}" : value;
                Keyboard.SendKeys(text);
            }
        }
    }

Теперь текст вводится следующим образом - происходит клик мышкой в текстовом поле, выделяется весь текст и с клавиатуры вводится новый текст вместо старого.
Теперь  для работы с текстовым полем вместо класса WpfEdit мы используем класс WpfEditEx.

WpfEditEx UINameTextBox;
UINameTextBox.Text = "Иван"

Выигрыш по времени, который дает такой подход, зависит от производительности компьютера, на котором выполняются тесты, но факт того, что ввод текста в текстовое поле выполняется быстрее - налицо.

понедельник, 21 января 2013 г.

Набор полезных утилит для CodedUITest

При автоматизации UI приложений можно использовать полезный набор утилит для CodedUITest, который упрощает работу с контролами.
Например, такая операция, как поиск контрола, стандартными средствами записывается так:

WpfButton button = new WpfButton(ParentControl);
button.SearchProperties[WpfButton.PropertyNames.AutomationId] = "buttonId";

Используя этот набор утилит, поиск можно переписать следующим образом:

WpfButton button = UITestControlFactoryUtility.FromAutomationId<WpfButton>(ParentControl, "buttonId"));

В следующих сообщениях своего блога я планирую более подробно рассказать об опыте работы с CodedUITest для автоматизации тестирования UI и остальными продуктами Microsoft, облегчающими процесс тестирования.

пятница, 11 января 2013 г.

Юмор. Реакции разработчиков


Веселенький сайт про реакции разработчиков http://devopsreactions.tumblr.com/. Многое будет знакомо и интересно как автоматизаторам, так и ручным тестировщикам. Что мне особенно понравилось:

Code review недокументированного кода



Code review - тот, чей код на review



Code review - тот, кто проводит review



Отдел разработки, когда заказчик зашел в офис:



В офисе, когда code freeze



В офисе, когда выпущен успешный релиз



Как я представляю себя на следующем собеседовании на работу: