Лекция
Привет, Вы узнаете о том , что такое автоматизированное функциональное тестирование, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое автоматизированное функциональное тестирование, functional automation testing, automation testing, пирамида тестирования , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..
Автоматизированное тестирование программного обеспечения — часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно использует программные средства для выполнения тестов и проверки результатов выполнения, что помогает сократить время тестирования и упростить его процесс.
Автоматизированное тестирование ПО (Automation Testing)
- это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования.
автоматизированное функциональное тестирование ПО (Functional Automation Testing)
- это процесс верификации функциональных требований и особенностей тестируемого приложения, по средствам инструментов для автоматизированного тестирования. (см. Функциональное тестирование)
Предлагаем вашему внимаю следующие темы, дающие ответы на самые распространенные вопросы, возникающие в процессе внедрения автоматизированного тестирования:
Также рекомендуем почитать статьи специалистов по автоматизированному тестированию:
С автоматизацией тестирования, как и со многими дугими узконаправленными IT - дисциплинами, связано много неверных представлений. Для того, чтобы избежать неэффективного применения автоматизации, следует обходить ее недостатки и максимально использовать преимущества. Далее мы перечислим и дадим небольшое описание для основных нюансов автоматизации и дадим ответ на основной вопрос данной статьи – когда автоматизацию всетаки стоит применять.
Для того чтобы принять решение о целесообразности автоматизации приложения нужно ответить на вопрос «перевешивают ли в нашем случае преимущества?» - хотя бы для некоторой функциональности нашего приложения. Если вы не можете найти таких частей, либо недостатки в вашем случае неприемлемы – от автоматизации стоит воздержаться.
При принятии решения стоит помнить, что альтернатива – это ручное тестирование, у которого есть свои недостатки.
В поиске эффективных мест для автоматизации вам может помочь глава "Что необходимо автоматизировать".
Спрашивая: «Что автоматизировать?», необходимо сначала ответить на вопрос: «Целесообразна лиавтоматизация тестирования в условиях проекта». Если ответ «ДА», то необходимо, исходя из требований к объекту тестирования, создать план, по которому будут разрабатыватьсяавтоматизированные тесты. Создавая подобный документ, вы должны четко представлять, "что автоматизировать?", "как автоматизировать?" и "чем автоматизировать?". Не будем вдаваться в подробности, как и чем тестировать ту или иную функцию, просто перечислим места, где, на наш взгляд,нужно применять автоматизацию:
А также, многое другое, в зависимости от требований к тестируемой системе и возможностей выбранного инструмента для тестирования.
Для более эффективного использования автоматизации тестирования лучше разработать отдельные тест кейсы проверяющие:
Пример: создание, удаление, просмотр и изменение данных о пользователе.
Пример: пользователь заходит на почтовый сайт, листает письма, просматривает новые, пишет и отправляет письмо, выходит с сайта. Об этом говорит сайт https://intellect.icu . Это так называемый end-to-end сценарий, который проверяет совокупность действий. Мы предлагаем вам использовать именно такие сценарии, так как они позволяют вернуть систему в состояние, максимально близкое к исходному, а значит – минимально влияющее на другие тесты.
Пример: система создает некоторый xml файл, структуру которого необходимо проверить.
Это и есть та функциональность, от автоматизации тестирования которой, можно получить наибольшую отдачу.
Рис. 1 . Пирамиды идеального и неидеального автоматизированного тестирования
Если мы обнаружим, что модульные или приемочные испытания слишком сложны и дорогостоящи, чтобы писать их и поддерживать, то, скорее всего, у нас слишком связанная архитектура, когда четких границ между модулями не существует (или, возможно, никогда не существовало). В этом случае нам необходимо создать менее связанную систему. Ее модули можно тестировать независимо, без среды интеграции. Тогда можно сделать так, чтобы приемочные испытания даже самых сложных приложений выполнялись в течение нескольких минут.
В данном разделе рассмотрим аспекты, влияющие на выбор инструмента автоматизации тестирования.
Во первых, вы должны обратить внимание насколько хорошо инструмент для автоматизации распознает элементы управления в вашем приложении. В случае когда элементы не распознаются стоит поискать плагин, либо соответствующий модуль. Если такового нет – от инструмента лучше отказаться. Чем больше элементов может распознать инструмент – тем больше времени вы сэкономите на написании и поддержке скриптов!
Во-вторых, нужно обратить внимание на то сколько времени требуется на поддержку скриптовнаписанных с помощью выбранного инструмента. Для этого запишите простой скрипт который выбирает пункт меню, а потом представьте, что изменился пункт меню который необходимо выбрать. Если для восстановления работоспособности сценария вам придется перезаписать скрипт целиком, то инструмент не оптимален, так как реальные сценарии гораздо сложнее. Лучше всего тот инструмент, который позволяет вам вынести название кнопки в переменную в начале скрипта и быстро заменить ее значение. В идеале – описать меню как класс.
И последний момент на который нужно обратить внимание – насколько удобен инструмент для написания новых скриптов. Сколько требуется на это времени, насколько можно структурировать код (поддержка ООП), насколько код читаем, насколько удобна среда разработки для рефакторинга (переработки кода) и т.п.
Лучше всего для принятия правильного решения об автоматизации отвечать на вопросы «Зачем? Что? Как?» именно в таком порядке. Это поможет избежать впустую потраченных времени нервов и финансов. С другой стороны вы сможете получить надежность, скорость и качество!!!
Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них по итогам 2007 года:
Использование этих инструментов помогает тестировщикам автоматизировать следующие задачи:
Однако автоматические тесты не могут полностью заменить ручное тестирование. Автоматизация всех испытаний — очень дорогой процесс, и потому автоматическое тестирование является лишь дополнением ручного тестирования. Наилучший вариант использования автоматических тестов — регрессионное тестирование.
Выбор инструмента зачастую зависит от объекта тестирования и требований к тестовым сценариям, т.к. инструменты тестирования не могут поддерживать абсолютно все технологии, используемые при разработке приложений. То есть, выбор инструмента сводится к банальному методу проб и ошибок. В итоге, нередко мы выбираем несколько инструментов для тестирования функций приложения. Например, GUI мы проверяем по средствам Mercury WinRunner, бэкенд процессы - используя "java based test tools" или другие инструменты. Основные аспекты выбора инструмента автоматизации тестирования рассмотрены в разделе "Как автоматизировать?".
Рассмотрим инструменты для автоматизированного функционального тестирования от разных производителей:
| Компания | Инструмент |
| Hewlett-Packard (Mercury Interactive) | QuickTest Professional, WinRunner |
| IBM Rational | Rational Robot, Rational Functional Tester |
| Borland (Segue) | SilkTest |
| AutomatedQA Corp | TestComplete |
| Microsoft | Microsoft VS 2005 |
| SeleniumHQ | Selenium |
Отдельным пунктом также хочется выделить Java библиотеки для автоматизированного тестирования (java based test tools and libraries):
| Инструмент | Описание |
| Selenium | Selenium is a set of different software tools each with a different approach to supporting test automation of web applications across many platforms. |
| Watij | Watij (pronounced wattage) stands for Web Application Testing in Java. Watij is a pure Java API created to allow for the automation of web applications. Based on the simplicity of Watir and enhanced by the power of Java, Watij automates functional testing of web applications through a real browser. Currently Watij supports automating Internet Explorer on Windows only. Future plans are in place to support others like Mozilla. |
| HtmlUnit | HtmlUnit is a "browser for Java programs". It models HTML documents and provides an API that allows you to invoke pages, fill out forms, click links, etc... just like you do in your "normal" browser. It has fairly good JavaScript support (which is constantly improving) and is able to work even with quite complex AJAX libraries, simulating either Firefox or Internet Explorer depending on the configuration you want to use. It is typically used for testing purposes or to retrieve information from web sites. HtmlUnit is not a generic unit testing framework. It is specifically a way to simulate a browser for testing purposes and is intended to be used within another testing framework such as JUnit or TestNG |
| HttpUnit | Written in Java, HttpUnit emulates the relevant portions of browser behavior, including form submission, JavaScript, basic http authentication, cookies and automatic page redirection, and allows Java test code to examine returned pages either as text, an XML DOM, or containers of forms, tables, and links. When combined with a framework such as JUnit, it is fairly easy to write tests that very quickly verify the functioning of a web site. |
| Jamaleon | Jameleon is an automated testing framework that can be easily used by technical and non-technical users alike. One of the main concepts behind Jameleon is to create a group of keywords or tags that represent different screens of an application. All of the logic required to automate each particular screen can be defined in Java and mapped to these keywords. The keywords can then be organized with different data sets to form test scripts without requiring an in-depth knowledge of how the application works. The test scripts are then used to automate testing and to generate manual test case documentation. |
| Junit | JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. |
| Abbot | Abbot is a simple framework for unit and functional testing of Java GUIs. Facilitates generating user actions and examining component state. Supports recording and playback on any Java application. |
| Marathon | With Marathon you capture user interactions on the applications and also insert assertions to verify that correct processing is taking place. The generated raw script can be re-factored to modules for efficient reuse and maintainability. Replay the scripts either manually or integrate Marathon into your build process for automatic execution of the test suites. |
Так же существует огромное количество фреймворков и инструментов, ориентированных не только на Java, но и на другие языки программирования, такие как: ruby, php, C#, javascript, python, perl и т.д. Их обзор мы проведем в ближайшее время.
Условно, тестируемое приложение можно разбить на 3 уровня:
Для обеспечения лучшего качества продукта, рекомендуется автоматизировать все 3 уровня. Рассмотрим более детально стратегию автоматизации тестирования на основе трехуровневой модели:
Под автоматизированными тестами на этом уровне понимаются Компонентные или Модульные тесты написанные разработчиками. Тестировщикам никто не запрещает писать такие тесты, которые будут проверять код, конечно же, если их квалификация позволяет это. Наличие подобных тестов на ранних стадиях проекта, а также постоянное их пополнение новыми тестами, проверяющими «баг фиксы», убережет проект от многих серьезных проблем.
Как правило не всю бизнес логику приложения можно протестировать через GUI слой. Это может быть особенностью реализации, которая прячет бизнес логику от пользователей. Именно по этой причине по договоренности с разработчиками, для команды тестирования может быть реализован доступ напрямую к функциональному слою, дающий возможность тестировать непосредственно бизнес логику приложения, минуя пользовательский интерфейс.
На данном уровне есть возможность тестировать не только интерфейс пользователя, но также и функциональность, выполняя операции вызывающую бизнес логику приложения. С нашей точки зрения, такого рода сквозные тесты дают больший эффект нежели просто тестирование функционального слоя, так как мы тестируем функциональность, эмулируя действия конечного пользователя, через графический интерфейс.
Для удобства наложения автоматизированных тестов, на уже имеющиеся тест кейсы, структура тест скриптов должна быть аналогична структуре тестового случая - Precondition, Steps & Post Condition.
Получаем правило, что каждый тест скрипт должен иметь:
Перечислим основные функции скрипта:
Рекомендуется также создать общую библиотеку по обработке ошибок и исключительных ситуаций. Например:
В итоге, воспользовавшись вышеописанными рекомендациями, у вас будет реализована общаяархитектура тест скриптов и сценариев. А рассмотрев статьи по использованию PageObject pattern в разделе "Статьи и практические советы по автоматизации тестирования ", вы сможете реализовать собственный фреймворк для автоматизации тестирования через GUI .
Чтобы автоматизация тестирования дала нужные плоды, а именно сократила время на тестирование ПО, предлагается следующее:
Написание и подход к автоматизации тестирования зависит от процесса разработки приложения. Взяв за основу RUP (Rational Unified Process), описанный на страницах блога"ПроТестинг", могу предложить следующую процедуру, разбитую на фазы:
Более подробный обзор использования RUP при разработке программного обеспечения можно прочитать в следующем документе: RUP bestpractices
Выводы из данной статьи про автоматизированное функциональное тестирование указывают на необходимость использования современных методов для оптимизации любых систем. Надеюсь, что теперь ты понял что такое автоматизированное функциональное тестирование, functional automation testing, automation testing, пирамида тестирования и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Качество и тестирование программного обеспечения. Quality Assurance.
Термины: Качество и тестирование программного обеспечения. Quality Assurance.