Автоматизация тестирования
Автоматизированное тестирование программного обеспечения (Software Automation Testing) - это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования. Специалист по автоматизированному тестированию программного обеспечения (Software Automation Tester) - это технический специалист (тестировщик или разработчик программного обеспечения), обеспечивающий создание, отладку и поддержку работоспособного состояния тест скриптов, тестовых наборов и инструментов для автоматизированного тестирования. Инструмент для автоматизированного тестирования (Automation Test Tool) - это программное обеспечение, по средствам которого специалист по автоматизированному тестированию осуществляет создание, отладку, выполнение и анализ результатов прогона тест скриптов.
Процесс внедрении автоматизации тестирования: § внедрение невозможно при отсутствии процесса тестирования — те, § § кто будут заниматься автотестами должны понимать принципы и подходы в тестировании, а это достаточно большой пласт знаний, которым разработчики обладают в единичных случаях; при внедрении автотестирования надо учесть затраты и выгоды — при этом стоит помнить, что сюда надо включить время на выбор обучение сотрудников, ведение документации по тому, как происходит автотесы, как затраты и повышение квалификации сотрудников, уменьшение время на регрессию как выгода; правильно выбрать инструмент для автоматизации (об этом ниже); понять, что должно быть автоматизировано полностью, что лишь частично, а что вообще не стоит автоматизировать — цель покрыть все автотестами плохая, потому что не несет пользы продукту; определить правила как мы подходим к автоматизации — автоматизация это тоже написание кода, поэтому здесь надо соблюдать устоявшиеся инженерные практики.
Существует два основных подхода к автоматизации тестирования: 1. тестирование на уровне кода 2. GUI-тестирование. К первому типу относится, в частности, модульное тестирование. Ко второму - имитация действий пользователя с помощью специальных тестовых фреймворков. GUI-автоматизация развивалась в течение 4 поколений инструментов и техник:
• Утилиты записи и воспроизведения (capture/playback tools) записывают действия тестировщика во время ручного тестирования. • Сценарии (Scripting) — форма программирования на языках, специально разработанных для автоматизации тестирования ПО — смягчает многие проблемы capture/playback tools. • Data-driven testing — методология, которая используется в автоматизации тестирования. Особенностью является то, что тестовые скрипты выполняются и верифицируются на основе данных, которые хранятся в центральном хранилище данных или БД. Роль БД могут выполнять ODBCресурсы, csv или xls файлы и т. д. Data-driven testing — это объединение нескольких взаимодействующих тестовых скриптов и их источников данных в фреймворк, используемый в методологии. • Keyword-based автоматизация подразумевает разделение процесса создания кейсов на 2 этапа: этап планирования и этап реализации.
Экономическую целесообразность от автоматизации тестов не всегда можно просчитать заранее, потому что она зависит от ряда факторов: 1. Планируемого жизненного цикла системы; 2. Выбранного метода разработки системы; 3. Объектов автоматизации; 4. Методов автоматизации.
Существует 3 распространённых способа подсчёта эффективности внедрения автоматизации тестирования : 1. Прямой расчёт рентабельности инвестиций; 2. Расчёт рентабельность инвестиций с точки зрения эффективности использования ресурсов; 3. Расчёт рентабельность инвестиций с точки зрения минимизации рисков.
При расчёте затрат на автоматизацию тестирования, необходимо учитывать следующие факторы: 1. стоимость программного обеспечения для автоматизации тестирования; 2. затраты на обучение персонала или привлечение более квалифицированного персонала; 3. затраты на дополнительные аппаратные средства (в отдельных случаях); 4. стоимость разработки первоначальной библиотеки автоматических скриптов; 5. стоимость прогона библиотеки автоматических скриптов; 6. затраты на анализ результатов прогона автоматических тестов; 7. затраты на поддержание автоматизированных скриптов в актуальном состоянии.
где I 0 - стартовые инвестиции, которые высчитываются как сумма затрат на лицензию программного обеспечения для автоматизации тестирования, обучение персонала и стоимость дополнительных аппаратных средств; C 0 - стоимость разработки и отладки первоначальной библиотеки автоматических скриптов, которая высчитывается как произведение времени, требуемого на написание одного автоматизированного скрипта одним тестировщиком (в часах), умноженное на общее количество скриптов и на стоимость рабочего часа; k - количество планируемых циклов тестирования (то есть предполагаемое количество прогонов скриптов); Ce - стоимость однократного выполнения набора автоматизированных скриптов, которая вычисляется как среднее время, потраченное на подготовку к выполнению и непосредственно выполнение одного скрипта одним тестировщиком (в часах), умноженное на общее количество скриптов и на стоимость рабочего часа. Данная переменная может принимать 0 значение, например, когда подразумевается полностью автономное выполнение тестов, не требующее вмешательства человека ни на стадии подготовки к выполнению теста, ни во время исполнения теста;
Ca - стоимость анализа результатов одного прогона набора автоматизированных скриптов, которая вычисляется как предполагаемый процент неудачно проведённых тестов, умноженный на общее количество скриптов, среднее время, требуемое на анализ причин неудачного прогона одного скрипта одним тестировщиком (в часах), и на стоимость рабочего часа тестировщика; Cm - стоимость поддержания автоматизированных скриптов в актуальном состоянии, которая вычисляется как произведение ожидаемого коэффициента изменений скриптов для каждого цикла выполнения, времени, потраченного одним тестировщиком на изменение одного скрипта (в часах), общего количества скриптов и стоимости рабочего часа тестировщика. Данная переменная может принимать 0 значение, например, если в данной функциональной области не планируется никаких последующих изменений.
К преимуществам автоматизированного тестирования можно отнести: 1. Сокращение времени на исполнение тестов по сравнению с ручным тестированием; 2. Возможность проведения тестов, которые нельзя провести без использования средств автоматизации; 3. Повышение независимости экспертизы (исключается человеческий фактор); 4. Возможность проводить тестирование вне рабочих часов тестировщика. 5. Снижение стоимости итерации тестирования. 6. Увеличение скорости тестирования без ущерба для результата.
7. Повышение надежности систем за счет улучшения качества тестирования. 8. Обеспечение возможности многократного использования разработанных тестовых сценариев без увеличения стоимости тестирования. 9. Обеспечение прозрачности информации о качестве принимаемых изменений к программному обеспечению. 10. Усиление контроля процесса обеспечения качества. 11. Прозрачность и простота планирования времени для проведения тестирования программного обеспечения. 12. Автоматическое формирование отчётов о тестировании. 13. Рациональное использование рабочего времени команды тестирования: один тестировщик может параллельно осуществлять тестирование нескольких систем, автоматические тесты могут выполняться в нерабочее время (ночь, выходные). 14. Использование передовых технологий в сфере обеспечения качества. 15. Сокращение времени на проведение тестирования программного обеспечения. 16. Набор тестов ограничивается в первую очередь производительностью системы, а не доступным резервом времени тестировщиков. 17. Минимизация влияния человеческого фактора на процесс тестирования.
Недостатки внедрения автоматизации тестирования 1. Автоматизация тестирования зачастую требует значительных трудозатрат; 2. Требуется более квалифицированный персонал; 3. Сложный анализ результатов; 4. Любое изменение в работе системы может потребовать трудозатратных изменений в автоматических тестах; 5. Ошибка в реакции системы на один из тестов может привести к ошибочным результатам прогона последующих тестов; 6. Риск возникновения ошибок в самом автоматическом тесте; 7. В некоторых случаях, не все функциональные особенности системы можно покрыть автоматизированными тестами с помощью выбранного инструментария.
Что нужно автоматизировать? § Труднодоступные места в системе (бэкенд процессы, § § § логирование файлов, запись в БД) Часто используемая функциональность, риски от ошибок в которой достаточно высоки. Автоматизировав проверку критической функциональности, можно гарантировать быстрое нахождение ошибок, а значит и быстрое их решение. Рутинные операции, такие как переборы данных (формы с большим количеством вводимых полей. Автоматизировать заполнение полей различными данными и их проверку после сохранения) Валидационные сообщения (Автоматизировать заполнение полей не корректными данными и проверку на появление той или иной валидации) Длинные end-to-end сценарии Проверка данных, требующих точных математических расчетов Проверка правильности поиска данных
Для эффективного использования автоматизации тестирования лучше разработать отдельные тест кейсы проверяющие: § Базовые операции создания/чтения/изменения/удаления сущностей (так называемые CRUD операции - Create / Read / Update / Delete). Пример: создание, удаление, просмотр и изменение данных о пользователе. § Типовые сценарии использования приложения, либо отдельные действия. Пример: пользователь заходит на почтовый сайт, листает письма, просматривает новые, пишет и отправляет письмо, выходит с сайта. Это так называемый end-to-end сценарий, который проверяет совокупность действий. § Интерфейсы, работы с файлами и другие моменты, неудобные для тестирования вручную. Пример: система создает некоторый xml файл, структуру которого необходимо проверить. §.
Как автоматизировать? Рассмотрим аспекты, влияющие на выбор инструмента автоматизации тестирования. Во первых, вы должны обратить внимание насколько хорошо инструмент для автоматизации распознает элементы управления в вашем приложении. В случае когда элементы не распознаются стоит поискать плагин, либо соответствующий модуль. Во-вторых, нужно обратить внимание на то сколько времени требуется на поддержку скриптов написанных с помощью выбранного инструмента. Для этого запишите простой скрипт который выбирает пункт меню, а потом представьте, что изменился пункт меню который необходимо выбрать. Если для восстановления работоспособности сценария вам придется перезаписать скрипт целиком, то инструмент не оптимален, так как реальные сценарии гораздо сложнее. Насколько удобен инструмент для написания новых скриптов. Сколько требуется на это времени, насколько можно структурировать код (поддержка ООП), насколько код читаем, насколько удобна среда разработки для рефакторинга (переработки кода) и т. п.
Три уровня автоматизации тестирования § Unit Tests Layer § Functional Tests Layer (Non-UI) § GUI Tests Layer
Уровень модульного тестирования (Unit Test layer) Под автоматизированными тестами на этом уровне понимаются Компонентные или Модульные тесты написанные разработчиками. Тестировщикам никто не запрещает писать такие тесты, которые будут проверять код, конечно же, если их квалификация позволяет это. Наличие подобных тестов на ранних стадиях проекта, а также постоянное их пополнение новыми тестами, проверяющими «баг фиксы» , убережет проект от многих серьезных проблем. Уровень функционального тестирование (Functional Test Layer non-ui) Как правило не всю бизнес логику приложения можно протестировать через GUI слой. Это может быть особенностью реализации, которая прячет бизнес логику от пользователей. Именно по этой причине по договоренности с разработчиками, для команды тестирования может быть реализован доступ напрямую к функциональному слою, дающий возможность тестировать непосредственно бизнес логику приложения, минуя пользовательский интерфейс. Уровень тестирования через пользовательский интерфейс (GUI Test Layer) На данном уровне есть возможность тестировать не только интерфейс пользователя, но также и функциональность, выполняя операции вызывающую бизнес логику приложения. С нашей точки зрения, такого рода сквозные тесты дают больший эффект нежели просто тестирование функционального слоя, так как мы тестируем функциональность, эмулируя действия конечного пользователя, через графический интерфейс.
Архитектура Автоматических Тестов (Test Tools Architecture) Каждый тест скрипт должен иметь: § Precondition § Steps (Test) § Post Condition
§ Precondition § Инициализация приложения (например, открытие главной страницы, вход под тестовым пользователем, переход в необходимую часть приложения и подведение системы к состоянию пригодному для тестирования) § Инициализация тестовых данных § Steps § Непосредственное проведение теста § Занесение данных о результате теста, с обязательным сохранением причин провала и шагов, по которым проходил тест § Post Condition § Удаление, созданных в процессе выполнения скрипта, ненужных тестовых данных § Корректное завершение работы приложения
Стратегия использования автоматизированных тестов 1. Написанием тестов должны заниматься «специально обученные люди» специалисты по автоматизированному тестированию (Software Automation Testers). После написания, тесты передаются команде ручного тестирования, которая уже осуществляет их ежедневный запуск и анализ результатов. Тем самым автоматизированные тесты также проходят тестирование, и в результате увеличивается их надежность и жизнеспособность. 2. Написанные и отлаженные тесты также могут передаваться команде разработки, для отладки новых версий. 3. Команде разработки рекомендуется осуществлять ежедневную сборку, с прогоном всех написанных тестов на всех уровнях автоматизации тестирования. И только после того, как новая версия начинает удовлетворять критериям качества, осуществлять установку новой версии на QA платформу.
Типичный подход менеджеров Что тут делать? Все просто! • Записал сценарий • Проиграл сценарий на виртуальной машине • Если тест сломался, значит это баг • Cобрал баги
Оказалось все не просто • Получившийся код трудно поддерживать • Новый человек совершенно не понимает того, что написали до него • Код плохо читаем, не структурирован и плохо расширяется на другие среды • Много дублированного кода
Не увлекайтесь, иначе “вагоны” покатятся в разные стороны
Девять общих правил из жизни • Скрипты всегда более стабильны, чем UI тесты • В рамках одного теста - один язык • Общая база знаний и примеров – обязательна • Делайте “обертки” для методов, функций и т. д. • Привлекайте опытных коллег для Code. Review • Анализируйте сценарии, которые закодировал тестировщик • Один test case – один автотест • Вы тратите 50% времени на поддержку тестов? – Надо что-то менять! • Можете запустить 1000 тестов пять раз в день? Подумайте, а можете вы это все проанализировать? Каков выхлоп?
Автоматизация = программирование роботов
Обучение роботов 1. Повторяй за мной 2. Органы чувств - распознование - реакция 3. Интеллект -память -логика -самостоятельность
Язык , среда интерпретатор фреймворк Драйвер интерфейса библиотеки
Java, C#. . x. Unit(Java, . Net, C/C ++, Ruby, PHP) Test. NG(Java) MSVS Test Edition (. Net) Selenium RC (Java, . Net, Ruby, Python, PHP) Web. Driver(Java) Html. Unit(Java) Watir(Ruby) библиотеки Комплексные инструменты
Характеристики качества тестов § Сопровождаемость -удобно читать - удобно вносить изменения § Мобильность - тестирование в различных конфигурациях § Оптимизация - Сопровождаемость важнее § Надежность - Сопровождаемость важнее
Сопровождаемость § Повторное использование кода § Разделение аспектов § Шаблон проектирования § Понятные названия § Комментарии (и др. документация) § Рефакторинг тестов § Использование готовых библиотек
Инструменты R&P Почему бы и нет? -надо четко понимать когда остановиться Результатом – готовый код спагетти - спагетти надо готовить дальше
1. Выделяем инициализацию и завершение Виды тестовых конфигураций -общая -группы тестов -одного теста 2. Выделяем воздействия -обобщенные параметризированные стимулы -уровень бизнес-логики -названия понятные заказчику 3. Проверки
Сам тест
Инструменты автоматизации
Silk. Test Позволяет быстро и рентабельно автоматизировать функциональное тестирование приложений на нескольких ведущих платформах, включая несколько версий Windows, Linux и UNIX. С помощью Silk. Test пользователи могут проводить одновременное кросс-платформенное тестирование приложений в множестве различных сред, используя единый набор тестовых сценариев. Silk. Test 7. 6 устраняет необходимость платить за отдельные инструменты функционального тестирования для каждой поддерживаемой среды или многократно перезаписывать одинаковые сценарии для каждой платформы.
Quicktest Professional (Quick. Test Pro или QTP) Основной инструмент автоматизации функционального тестирования компании HP. Инструмент может автоматизировать функциональные и регрессионные тесты через записать действий пользователя при работе с тестируемым приложением, а потом исполнять записанные действия с целью проверки работоспособности ПО. Записанные действия сохраняются в виде скриптов. Скпирты могут быть отображенные в инструменте как VBScript (expert view) или же как визуальные последовательные шаги с действиями (keyword view). Каждый шаг может быть отредактирован и на него можно добавить точки проверки (checkpoint), которые сравнивают ожидаемый результат с полученным.
Основные функции проверка фукнциональности через точки проверки (checkpoints) обработка исключительных ситуаций (Exception handling) формирование данных в таблицы с последующим использованием подхода data-driven тестирование работа с сложными UI объектами расширяемость за счет дополнительных модулей oтчетность по результатам выполнения Достоинства распознавание объектов; точки проверки; поддержка скорость написания несложных тестов Недостатки цена поддержка одного языка программирования VBScript может использоваться только на OC Windows Поддерживаемые технологии: Web, Java, . Net, WPF, SAP, Oracle, Siebel, People. Soft, Delphi, Power Builder, Stingray 1, Terminal Emulator, Flex, Mainframe terminal emulator Поддерживаемые ОС: Microsoft Windows , Язык тестов: VBScript
Rational Functional Tester Инструмент для полноценного функционального и регрессионного тестирования. Инструмент предоставляет тестировщикам средства автоматизированного тестирования, позволяющие выполнять функциональное тестирование, регрессивное тестирование, тестирование пользовательского интерфейса и тестирование управляемое данными. § Интеграция с Jazz Eclipse Client Version 2. 0 – for Rational Team Concert and Rational Quality Manager Servers – предоставляет доступ к элементам потока операций, а также логическую или составную поддержку управления тестами (SCM test asset support). § Позволяет тестировщикам автоматизировать тестирование, устойчивое к частым изменениям пользовательского интерфейса приложений, благодаря технологии Script. Assure™. § Выполняет проверку динамических данных с использованием различных мастеров, точек проверки и шаблонов регулярных выражений.
Автоматизированный мастер для выполнения тестирования, управляемого данными, позволяет повысить полноту тестирования за счет многократного использования отдельных тестов с различными наборами тестовых данных. Позволяет тестировщикам выбрать язык сценариев для разработки и настройки тестов: Java в среде Eclipse или Microsoft Visual Basic. NET в среде Visual Studio. NET. Включает встроенную поддержку Web-, . Net-, Java-. Siebel-, SAPприложений и приложений эмуляции терминалов, таких как приложения 3270 (z. Series™) и 5250 (i. Series™), Power. Builder, AJAX, Adobe Flex, Dojo Toolkit и GEF. Можно также тестировать документы Adobe PDF, а также приложения z. Series, i. Series и p. Series. Поддерживает функциональное тестирование сред приложений Oracle ERP посредством поставляемых расширений. Поддерживаемые технологии: Java, . NET, Win 32, HTML, Terminal Application, Siebel-, SAPприложения, Power. Builder, AJAX, Adobe Flex, Dojo Toolkit и GEF Поддерживаемые ОС: Windows 2000, XP, Vista, 7, Linux (только воспроизведение) Язык тестов: Java, Visual Basic в среде Visual. Studio
: Java библиотеки Инструмент Описание Watij (произносится мощность) выступает как веб-приложение тестирования на Java. Watij является чистым Java API создан, специально для автоматизации веб-приложений. Исходя из простоты Watir и распространенности Java достаточно мощьный инструмент, Watij автоматизирует функциональное тестирование веб-приложений в реальном браузере. В настоящее время Watij поддерживает автоматизацию Internet Explorer только на Windows Html. Unit является "браузером для программ Java". Это модель HTML документа и обеспечивает API, который позволяет ссылаться на страницы, заполнять формы, нажимайте на ссылки, и т. д. . . так же, как вы делаете в «нормальном» браузере. Он имеет довольно хорошую поддержку Java. Script (который постоянно улучшается) и способен работать даже с довольно сложными AJAX библиотек, имитируя либо Firefox или Internet Explorer в зависимости от конфигурации, который необходимо использовать. Он обычно используется для тестирования или для получения информации с веб-сайтов. Http. Unit Написанная в Java, Http. Unit эмулирует соответствующие части поведения браузера, в том числе формы представления, Java. Script, базовой аутентификации HTTP. В сочетании с библиотеками такими как JUnit, довольно легко писать тесты, которые очень быстро проверят функционирование веб-сайта.
§ Selenium IDE: возможности применения без использования тяжеловесных решений § Cubic Test: Eclipse + GEF + Selenium = визуальное управление тестами § Selenium grid: распределенная среда для тестирования web приложений – это просто § Вкратце о: § Selenium on Rails: простой способ автоматизации тестирования Ro. R приложений § Bromine: новый проект интегрированной тестовой среды на базе Selenium
1. Selenium IDE § Plugin к Firefox. Позволяет: § § Записывать тесты непосредственно из Firefox Воспроизводить загруженный тест в Firefox через Selenium Test Runner Экспортировать записанный тест в один из поддерживаемых языков (java, ruby, php, c#, python…) § Достоинства § Прост в использовании, не требует много ресурсов, не требует специальной подготовки сотрудников. § Позволяет автоматизировать простые тестовые сценарии/операции § Недостатки § Не позволяет использовать логические условия, циклы и т. п. что ограничивает его применимость линейными тестами § Нет возможности запуска сьюитов, а не отдельных тестов § Нет возможности параллельного запуска (только в разных экземплярах Firefox)
Selenium IDE в действии
2. Cubic Test § Возможности: § § § Интегрируется в Eclipse IDE как отдельная Perspective. Имеет инструменты Record/Playback. Использует визуальное моделирование и управление тестами (на базе Graphical Test Editor, GEF, также интегрируемого в Eclipse). § Позволяет выносить общие сценарии в субтесты и подключать их по мере необходимости. § Позволяет объединять тесты в наборы (сьюиты), также используя визуальное представление. § Позволяет экспортировать графическое представление тестов в HTML Prototype или Watir (в том числе допускает написание собственных экспортеров). § Достоинства § Оригинальная и простая для понимания концепция визуального управления тестами, основанная на распространенных и доступных open source инструментах. § Прост в использовании и не требует специализированных навыков программирования на том или ином языке (java, ruby, c#. . . ). § Встроенные средства записи и воспроизведения. § Недостатки § Отсутствие возможности параллельного воспроизведения тестовых наборов. § Некорректная работа с кирилицей
Cubic Test в действии
3. Selenium grid § Возможности: § Быстрое и простое распараллеливание выполнения тестов. В основе данной возможности лежит фреймворк Test. NG (а не j. Unit как у «классических» seleniumтестов). § Возможность построения распределенной и масштабируемой среды для выполнения тестов. § Достоинства § Многократное уменьшение времени выполнения при большом количестве тестовых сценариев. § Возможность использования ранее написанных тестов (на java, ruby python…). § Простой способ построения распределенной среды для выполнения тестов. § Недостатки § Нет средств Record/Playback. § Нет поддержки selence test cases. § Требует более высокой квалификации от сотрудников. § Сыроват. Например: § Проблемы с кирилицей при воспроизведении. § Проблемы с запуском parallels tests.
Архитектура Selenium-grid
Selenium-grid в действии public class Test. Grid. Demo { @Before. Test(always. Run = true) @Parameters({"selenium. Host", "selenium. Port", "browser", "web. Site"}) protected void start. Session(String selenium. Host, int selenium. Port, String browser, String web. Site) throws Exception { start. Selenium. Session(selenium. Host, selenium. Port, browser, web. Site); } @After. Test(always. Run = true) protected void close. Session() throws Exception { close. Selenium. Session(); } @Test(enabled = true, groups = {"cp", "registration"}, description = "Grid test demo") @Parameters({"selenium. Host", "selenium. Port", "browser", "web. Site"}) public void Some. Test() throws Exception { session(). open("http: //domain. com"); } }
4. О чем еще стоит упомянуть? § Bromine. Интегрированная тестовая среда на базе Selenium. § Selenium предоставляет возможности § Создание тестов при помощи IDE § Предоставляет JS framework § Предоставляет Remote Control server § Предоставляет Core runner § Bromine, возможности: § Многофункциональный QA инструмент § Позволяет создавать проекты § Привязывать требования к проектам § Привязывать тесты к требованиям § Предоставляет простой способ управления и запуска тестов § Позволяет анализировать результаты запуска тестов § Позволяет создавать дефекты § Также имеется облегченная light версия только для запуска тестов и анализа результатов
Скачать презентацию Автоматизация тестирования Автоматизированное тестирование программного обеспечения Software
635dd1345aeff88fbd3788ed5416bf45.ppt