2013-03-23

Cамотренинг по автоматизации. Подходы: ключесловный и поведенческий(keyword-driven, behaviour-driven).

Содержание.

Тесты на основе ключевых слов(кeyword-driven).
 Практически всегда автоматизированное тестирование это штука дорогая и сложная, а "экономика должна быть экономной". Автотесты на основе ключеслов (keyword-driven testing) это как раз та техника, что призвана снизить стоимость за счёт привлечения к написанию собственно тестов технически слабоподготовленных лиц разнообразной национальности.

Ключесловное тестирование (называемое також "чрезтабличное", "на основе действий", "деесловное"(table-driven, action-driven or action-word)) очень схоже с тестированием управляемым данными, является в какой-то степени его продолжением и расширением. Основная идея - разделить автоматизацию тестирования на две неравные по времени и стоимости части: написание собственно тестов в виде последовательности ключевых действий и реализацию(создание инфраструктуры).




 Написание тестов подразумевает описание тестовых сценариев в табличном виде, где каждая строка состоит из ключевого слова описывающего некое действие и каких-либо данных. Возможны, естественно, вариации: нет данных, добавлены комментарии и пр.. Такую задачу могут выполнять технически слабые специалисты, знакомые с предметной областью тестируемого приложения. За счёт этого написание собственно тестов становится относительно недорогим.

 Создание инфраструктуры заключается в
  1. написании реальных классов, методов, скриптов тестирующих приложение;
  2. трансляции ключевых слов из просто текста в вызовы тех методов, запуск нужных скриптов и т.д. .
Эта часть подхода требует технически грамотных (читаем "дорогих") сотрудников. Зато таких "грамотеев" нужно много меньше, чем писателей тестов.

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


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

Test Case
  Valid Login
Step
  Given login page is open
  When valid username and password are inserted
  and credentials are submitted
  Then welcome page should be open [9]

Given, When, Then - фактически зарезервированные слова, определяющие структуру, описывающее то самое поведение.

Тесты теперь могут писать вообще кто угодно, например аналитики, главное чтоб соблюдали структуру.


"За".
+ Можно быстро создавать новые тесты(при наличии инфраструктуры);
+ "Не-технари" могу писать тесты, что снижает стоимость и теоретически ускоряет процесс;
+ благодаря популярности этих подходов появилось приличное количество практически готовых к немедленному использованию инструментов. С ними создание инфраструктуры упрощается на порядки.

"Против".
- Создание гибких решений может быть трудным;
- Те немногие технари, пишущие инфраструктуру, должны быть достаточно сильны в программировании.


С помощью чего?
1. FitNesse - уже ветеран ключесловного тестирования от ветеранов же тестирования и разработки.
2. RobotFramework - каркас для ключесловного, на основе поведений и т.д. тестирования. Рождён на сумрачных берегах не менее снежной Финляндии.
3. Cucumber - подозрительно пафосный каркас для тестов на основе поведений.
4. JBehave - ещё один поведенческий каркас.



Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects
[8] В поисках качества кода: Знакомство с Behavior Driven Development (BDD)
[9] Пример поведенческого теста: http://robotframework.googlecode.com/hg/doc/userguide/RobotFrameworkUserGuide.html?r=2.7.6#different-test-case-styles

Содержание.

2013-03-18

Cамотренинг по автоматизации. Подходы: данные правят(data-driven).


Тесты управляемые данными (data-driven).
Представьте, что пишете тест для странички входа в систему. Какие шаги в этом тесте? Скорее всего что-то в духе:
1. Open Login Page;     
2. Type in %username% in the @usernamField     
3. Type in %password% in the @passwordField     
4. {Verify} Current page is the expected one.

Это обобщённое описание, т.е. на шаге 4 ожидаемой может быть домашняя страница(если имя/пароль были верными) или страница с ошибкой, если имя/пароль были неверны. Шаги одни и те же, только вводимые символы и ожидаемые результаты разные - разница в данных. Логично разделить код (шаги) и данные, чтобы можно было один и тот же тестовый скрипт прогонять для разных входных и выходных значений - тест будет управляться данными.


Для таких тестов (data-driven tests) обычно существует некий источник данных (Экселевский файл, БД, CSV-шный файл и т.д.) и параметризованный скрипт/тест, которому данные из источника "скармливаются"  строчка за строчкой (по факту 1 строка = 1 тест ).

Самый яркий пример использования этой техник - в модульной тестировании. Например, есть метод, делящий одно число на другое. Модульный тест рационально написать "ведомым", подавая на вход 3 значения: делитель, делимое и ожидаемый результат.

"За".
+ один и тот же код для множества случаев - легко поддерживать;
+ легко изменить(увеличить или уменьшить) покрытие, надо лишь изменить таблицу с данными, обычно не требуется даже компилировать код тестов.

"Против".
- прогон лишь части  всего набора данных может быть невозможен;
- обнаружение конкретной строчки, приводящей к ошибке может быть трудным;
- не для всех тестов можно использовать.

С помощью чего?
1. TestNG и JUnit: http://blog.varunin.com/2011/10/data-driven-testing-using-junit-and.html

2. NUnit начиная с версии 2.5.0 поддерживает некоторое количество полезных атрибутов:  http://nunit.org/index.php?p=testCaseSource&r=2.6.1



Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects


Содержание.


Cамотренинг по автоматизации. Подходы: функциональная декомпозиция.

Содержание.

Функциональная декомпозиция.
"Термин 'функциональная декомпозиция' описывает процесс выделения модульных компонентов(функций определяемых пользователем) при котором авто-тесты создаются преимущественно комбинированием уже существующих компонентов."[1].

Функции-модули это строительные блоки, "кирпичики", из которых собираются новые тесты. Т.е. не стоит в каждый скрипт, класс и т.д. "напихивать" один и тот же код(да, да, любимый шаблон разработки "скопировать/вставить" использовать вредно). А стоит выделять переиспользуемые функции/процедуры(registerAUser(), login()) которые напрямую соотносятся с функциями тестируемого приложения. А уже авто-тесты будут состоять из вызовов этих процедур в требуемой последовательности.

Различают:
- Утилитные(вспомогательные) функции/скрипты - повторно используемые подпроцедуры, используемые более чем одним авто-тестом. Например процедура login() скорее всего будет использоваться большинством тестов;
- Навигационные скрипты - набор подпроцедур вида “goToPage/Screen()”. По большому счёту это те же вспомогательные функции, только узкоспециализированные;
- Процедуры проверки(верификации) - содержат код для проверки(верификации) бизнес-логики;
- "Водители"(Driver scripts) - вспомогательные функции, которые не относятся к тестированию напрямую, но обеспечивают собственно прогон тестов: инициализацию, выполнение пред- и пост-условий, выполнение других скриптов/шагов в требуемом порядке.

"За" и "против":
+ повторно используемый код;
+ независимость скриптов (сами тесты независимы и не переиспользуются).

- технически сложнее, чем "записал/выполнил";
- смешиваются данные и код.

Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects


Содержание.

2013-03-09

Cамотренинг по автоматизации. Подходы, техники и каркасы.

Содержание.

Подходы.
Два основных глобальных подхода к автоматизации тестирования:

- На уровне кода/Программного интерфейса приложения (Code-driven/API based);
- Посредством ГИП (GUI-based).

Первое (тестирование на уровне кода) подразумевает использование того или иного вида доступа к классам, модулям, сервисам и т.д. для ввода исходных данных и получения результатов с последующей их проверкой. Примером может служить модульное тестирование (unit testing), позволяющее "определить работают ли различные части исходного кода так как ожидается в различных условиях.". Другой пример - тестирование веб-сервисов путём вызова открыто доступных методов  этих сервисов.

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

Автоматизированное тестирование через графический интерфейс часто "легколомаемо" и чувствительно к изменениям в самом графическом интерфейсе.  Недостаточно хорошо спроектированный тест может потребовать полной переделки при казалось бы пустяковом изменении названия кнопки.

Каркасы.
В историческом разрезе множество вещей в технике проходит путь от хаоса к какой-либо системности. Разработка ПО идёт той же тропой - от хаоса первых попыток к более-менее логически и практически обусловленной системе. Каркасы (frameworks) широко применяются в разработке собственно ПО и имеет смысл следовать этому же подходу в автоматизации тестирования, так как по сути последняя есть разработка программного обеспечения особого сорта. Что такое "каркас"? Согласно педевикии: “...a software framework is an abstraction in which software providing generic functionality can be selectively changed by user code, thus providing application specific software. It is a collection of software libraries providing a defined application programming interface (API).”. Далее, "каркас автоматизированного тестирования это набор концепций, предположений и инструментов который обеспечивает поддержку автоматизированного тестирования.". Также, каркас в автоматизации позволяет ускорить и/или упростить разработку новых тестов и поддержание уже существующих в актуальном состоянии.

Каракас должен обеспечивать:
- механизм для организации и структурирования тестов: пред- и пост-условия, зависимости и прочее;
- механизм контроля тестируемого приложения или механизм доступа к этому приложению (запуск, останов и т.д.);
- механизм выполнения самих тестов;
- механизм проверки полученных результатов;
- механизм логирования/журналирования и генерации отчётов.

Известны несколько методологий автоматизации тестирования и построения каркаса:
 - Запись-и-Воспроизведение (Record & Playback) - НИКОГДА не используйте на реальных проектах;
 - Функциональная декомпозиция (или Разбиение на модули);
 - На основе данных (Data-driven);
 - На основе ключевых слов (Keyword-driven);
 - Объектный подход;
 - На основе моделей;
 - Смешанный подход.

Ссылки.
[1] http://www.automatedtestinginstitute.com/home/index.php?view=article&id=%2066&option=com_content&Itemid=1000
[2] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&catid=45:2nd-generation-frameworks&id=65:data-driven
[3] http://softwarequalitysource.com/AutomationTypes.html
[4] http://en.wikipedia.org/wiki/Model-based_testing
[5] http://www.slideshare.net/nashjain/test-automation-strategies-for-agile
[6] http://en.wikipedia.org
[7] http://code.google.com/p/selenium/wiki/PageObjects


Содержание.


2013-03-03

Cамотренинг по автоматизации. Что, почему, зачем, где, когда и как.

Содержание.

Что.
Автоматизация тестирования это "...использование ПО для управления выполнением тестов, сравнения ожидаемых и реальных результатов, создания предусловий для выполнения тестов, а также других действий связанных с контролем и отчётностью по тестированию.". На практике об автоматизации часто говорится в узком смысле - автоматизация ручных функциональных тестовых случаев, что обычно означает использование ГИП (графического интерфейса пользователя), т.е. автоматизированные тесты имитируют действия пользователя путём генерирования таких событий как движение "мышью", нажатия, щелчки, ввод с клавиатуры.  В широком смысле автоматизация тестирования включает такие вещи как например генерация ежедневных отчётов, рассылка их по электронной почте, наполнение БД тестовыми данными и т.д. .

Некоторые разновидности автоматизации:



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

Зачем.
Успешная автоматизация тестирования решает сразу несколько задач:
 - Уменьшение времени на тестирование (чаще всего речь идёт о регрессионном тестировании);
 - Делает тестирование более заметным и прозрачным (например можно легко получать замечательно оформленные отчёты по прогону тестов каждый день и таким образом постоянно "держать руку на пульсе" качества продукта);
 - Увеличение тестового покрытия (авто-тесты позволяют покрыть большее количество комбинаций за то же время и с возможностью одновременно отслеживать такие параметры как потребление памяти, процессорного времени, дискового пространства и пр.);
 - Тестировщики уделяют больше времени сложным сценариям и исследовательскому тестированию;
 - Исключение некоторых человеческих ошибок при прогоне тестов.

Где и когда.
Об автоматизации стоит задуматься когда:
 - процесс тестирования включает строго определённые последовательности часто повторяемых действий, которые выполняются шаг за шагом без особых изменений и при этом требуют относительно много времени;
 - у вас огромное количество сборок и версий для тестирования (например  планируется выпустить 64 версии в течении 10 лет);
 - необходимо протестировать/изучить поведение системы при определённых условиях(например при 100 000 активных пользовательских сессиях);
 - у вас нет ГИПа.

Автоматизация может принести нулевой результат когда:
 - процессы тестирования неопределенны и/или хаотичны;
 - бизнес-логика недостаточно определена или выверена;
 - ГИП нестабилен;
 - набор функций системы ещё не определён(разработка прототипа);
 - лица принимающие финансово-технические решения до конца не понимают структуру стоимости автоматизации и какие ресурсы для неё необходимы.

Как.
По определению, автоматизация тестирования производится с помощью ПО. Это могут быть внешние библиотеки, компоненты и инструменты или инструменты разработанные внутри проекта или фирмы. Говоря о непосредственно тестировании в рамках автоматизации, существует два больших класса: специализированные инструменты (такие как QTP, TestComplete, LoadRunner)  и коммерческие или открытокодовые библиотеки/компоненты(xUnit-ы, Selenium, JMeter). Каждый из классов имеет свои "за" и "против".

Специализированные инструменты:
 - в большинстве случаев крайне дороги;
 - требуют специального обучения;
 - разработанные тесты может быть трудно поддерживать и развивать из-за отсутствия у всех членов команды нужного опыта (например разработчикам может быть трудно быстро начать писать авто-тесты по причине незнакомого языка, среды и т.д.);
 - возможны трудности в обновлении/расширении функций таких инструментов (отдельные лицензии например).

 + обычно отличная тех. поддержка со стороны производителя;
 + обученным людям необязательно иметь навыки программирования.

Библиотеки/компоненты:
 - требуют навыков программирования;
 - документация часто плохая или отсутствует;

+ очень расширяемы - почти всегда можно дописать недостающую функциональность самостоятельно;
+ могут использоваться практически всеми членами проектной команды;
+ часто с открытым кодом и бесплатны.

 Ссылки:
[1] http://en.wikipedia.org/wiki/Automated_testing

[2] http://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

[3] http://openquality.ru/software-testing/automation.php

[4] http://automated-testing.info/


Содержание.

Заказчика надо держать в курсе...

 ... . И в ежовых рукавицах :).

Вводная. Самотренинг по автоматизации функционального тестирования.

Содержание:
1. Cамотренинг по автоматизации. Что, почему, зачем, где, когда и как.
2. Cамотренинг по автоматизации. Подходы, техники и каркасы.
3. Cамотренинг по автоматизации. Подходы: функциональная декомпозиция.
4. Cамотренинг по автоматизации. Подходы: данные правят(data-driven).
5. Cамотренинг по автоматизации. Подходы: ключесловный и поведенческий(keyword-driven, behaviour-driven).
6. Cамотренинг по автоматизации. Подходы: объектный.
7. Самотренинг по автоматизации. Подходы: Модельный и гибридный.
8. Практические заметки.
9. Типовая структура проекта.
10. Самотренинг по автоматизации. Локаторы элементов.
11.  Самотренинг по автоматизации. Введение в Луний.
12. Практические задания.

О чём и для чего?
 Число желающих что-нибудь заавтоматизировать в тестировании растёт, а с чего начать и куда копать чаще всего неясно. Огромное количество платных тренингов порождает проблему выбора и не даёт уверенности в результатах. Данный самотренинг это набор "выучись сам" - желающему предоставляются набор материалов для самостоятельного изучения, выполнения заданий и т.д. . Никаких разжёвывания и сверх-детальных объяснений, расчёт на инженерный подход, способность мыслить и самообучаться. Ожидается, что после выучивания инженер сможет участвовать в реальном проекте по автоматизации тестирования в качестве младшего специалиста.

 Самотренинг состоит из краткой теоретической части(конспекты), набора указаний для практики, а также простого веб-приложения для тестирования и зародыша проекта автоматизации на базе Selenium 2.0 WebDriver.

 Материалы(как текст, так и исходный код) предоставляются "как есть" и бесплатно для личного обучения. При цитировании или использовании в любых проектах по разработке ПО (открытых, коммерческих, некоммерческих и т.д.) - имейте совесть и ставьте ссылки на источник. Если есть желание попользоваться материалами как-то ещё или улучшить код - добро пожаловать в комментарии.


Предположения.
Изучающий - человек, желающий узнать что-то новое и готовый использовать данные материалы для этого.

Предполагается, что изучающий имеет/знает:
- 2-4 года опыта в ручном тестировании ПО;
- принципы и концепции тестирования;
- знания и опыт применения базовых техник тест-дизайна (классы эквивалентности, граничные значения и т.д.);
- начальные навыки в программировании. Желательно ООП.

Ссылки.
Исходники проекта автотестов +"варка" тестируемого приложения

[1] http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&id=1093&Itemid=76