Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Автоматизированное тестирование

No description
by

Alexander Timochko

on 31 January 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Автоматизированное тестирование

Автоматизированное тестирование
Что это?
Автоматизированное тестирование программного обеспечения (Software
Automation Testing)
это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования.
Автоматизатор
Специалист по автоматизированному тестированию программного обеспечения (Software Automation Tester) - это технический специалист (тестировщик или разработчик программного обеспечения), обеспечивающий создание, отладку и поддержку работоспособного состояния тест скриптов, автоматизированного тестирования.
Преимущества и недостатки автоматизации тестирования
+
Повторяемость
– все написанные тесты всегда будут выполняться однообразно, то есть исключен «человеческий фактор». Тестировщик не пропустит тест по неосторожности и ничего не напутает в результатах.
Быстрое выполнение
– автоматизированному скрипту не нужно сверяться с инструкциями и документациями, это сильно экономит время выполнения.
Меньшие затраты на поддержку
– когда автоматические скрипты уже написаны, на их поддержку и анализ результатов требуется, как правило, меньшее время чем на проведение того же объема тестирования вручную.
Отчеты
– автоматически рассылаемые и сохраняемые отчеты о результатах тестирования.
Выполнение без вмешательства
– во время выполнения тестов инженер-тестировщик может заниматься другими полезными делами, или тесты могут выполняться в нерабочее время (этот метод предпочтительнее, так как нагрузка на локальные сети ночью снижена).
Зачем нужно автоматизировать?
Инициализация
Инициализация (от англ. initialization, инициирование) — создание, активация, подготовка к работе, определение параметров. Приведение программы и тестов в состояние готовности к использованию (в нашем случае к проведени тестирования).
Тулза?
Инструмент для автоматизированного тестирования (Automation Test Tool) - это программное обеспечение, посредством которого специалист по автоматизированному тестированию осуществляет создание, отладку, выполнение и анализ результатов прогона тест скриптов.
Скрипт?
Тест Скрипт (Test Script) - это набор инструкций, для автоматической проверки определенной части программного обеспечения.
Сьют?
Тестовый набор (Test Suite) - это комбинация тест скриптов, для проверки определенной части программного обеспечения, объединенной общей функциональностью или целями, преследуемыми запуском данного набора.
Запуск?
Тесты для запуска (Test Run) - это комбинация тест скриптов или тестовых наборов
последующего совместного запуска (последовательного или параллельного, в зависимости от преследуемых целей и возможностей инструмента для автоматизированного тестирования).
Автоматизированное Функциональное Тестирование
Автоматизированное функциональное тестирование ПО (Functional Automation Testing) - это процесс верификации функциональных требований и особенностей тестируемого приложения, по средствам инструментов для автоматизированного тестирования.
Для проведения автоматизации существует множество причин:
Ручное тестирование требует длительного времени.
Ручной процесс подвержен ошибкам.
Автоматизация освобождает людей для выполнения лучшей работы.
Автоматизированные регрессивные тесты предоставляют “страховочную сетку”.
Автоматизированные тесты обеспечивают ранний и частый отклик.
Тесты обеспечивают документацию.
Автоматизация может обеспечить хороший возврат инвестиций
Ручное тестирование требует длительного времени
Ручное тестирование просто отнимает очень много времени. По мере роста приложения время на полное его тестирование также возрастает. Если не предусмотрено никакой автоматизации, то регрессивные тесты придется выполнять вручную. Выполнение регрессивных тестов вручную отнимает все больше и больше времени
Ручной процесс подвержен ошибкам
Повторяющееся ручное тестирование, особенно по написанным сценариям, очень быстро надоедает. Это прямой путь к ошибкам и пропуску даже простейших дефектов. Люди, выполняющие ручное тестирование, пропускают шаги, а то и целые тесты. Если перед командой стоят жесткие сроки, возникает соблазн “срезать углы”, в результате чего серьезные проблемы остаются незамеченными. Поскольку ручное тестирование проходит медленно, вы вполне можете заниматься им и в последнюю ночь перед завершением итерации. Сколько ошибок мы сможем отловить в
таких условиях?
Автоматизация освобождает людей
для выполнения лучшей работы
Автоматизация тестирования означает, что вы сможете уделить еще больше внимания испытанию потен циально слабых частей системы. Поскольку вы не тратите время на выполнение утомительных ручных сценариев, ваша энергия сохраняется для более сложной и творческой работы, обдумывания различных сценариев и изучения работы приложения
Автоматизированные регрессивные тесты
предоставляют “страховочную сетку
Знание о том, что код имеет хорошее покрытие автоматизированными регрессивными тестами, дает замечательное чувство уверенности. Конечно, любые изменения могут дать неожиданный эффект, но мы узнаем об этом в течение каких-то минут, если речь
идет об уровне модулей, либо часов, если это касается более высокого уровня функциональности
Команды, которые обеспечили себе хорошее покрытие кода автоматизированнымирегрессивными тестами, могут без страха вносить изменени
Автоматизированные тесты обеспечивают
ранний и частый отклик
После того, как автоматизированный тест некоторой части функциональности прошел успешно, он и будет проходить успешно до тех пор, пока эта функциональность не будет намеренно изменена. Запуск комплекта автоматизированных тестов при каждой фиксации нового кода в системе управления версиями помогает гарантировать быстрый перехват регрессивных ошибок. Быстрый отклик означает, что изменение остается свежим в сознании некоторого программиста, и потому он может быстро устранить неисправность, чем в том случае, когда она обнаруживается намного позже. Быстрое выявление ошибок означает, что их дешевле исправлять
Тесты это замечательная документация
Когда автоматизированы тесты, иллюстрирующие примеры желаемого поведения, они становятся “живой” документацией, описывающей работу системы. Иметь написанную документацию о работе каждого фрагмента функциональности, конечно, замечательно, но никто не сможет спорить с исполняемым тестом, который наглядно показывает зеленым и красным цветом, как работает код при заданном наборе входных данных
Возврат инвестиций и окупаемость
Важный компонент окупаемости тестирования заключается в способе исправления дефектов. Команды, полагающиеся на ручные тесты, часто находят ошибки по истечении значительного времени после написания кода, содержащего эти ошибки, и это в свою очередь делает поцесс исправления ошибок более трудоемким а следовательно дорогим. В случае с автоматизацией, время потраченное на подготовку автотестов в кратчайшие сроки окупится с лихвой
-
Повторяемость
– все написанные тесты всегда будут выполняться однообразно. Это одновременно является и недостатком, так как тестировщик, выполняя тест вручную, может обратить внимание на некоторые детали и, проведя несколько дополнительных операций, найти дефект. Скрипт этого сделать не может.
Затраты на поддержку
– несмотря на то, что в случае автоматизированных тестов они меньше, чем затраты на ручное тестирование того же функционала – они все же есть. Чем чаще изменяется приложение, тем они выше.
Большие затраты на разработку
– разработка автоматизированных тестов это сложный процесс, так как фактически идет разработка приложения, которое тестирует другое приложение. В сложных автоматизированных тестах также есть фреймворки, утилиты, библиотеки и прочее. Естественно, все это нужно тестировать и отлаживать, а это требует времени.
Стоимость инструмента для автоматизации
– в случае если используется лицензионное ПО, его стоимость может быть достаточно высока. Свободно распространяемые инструменты как правило отличаются более скромным функционалом и меньшим удобством работы.
Пропуск мелких ошибок
- автоматический скрипт может пропускать мелкие ошибки на проверку которых он не запрограммирован. Это могут быть неточности в позиционировании окон, ошибки в надписях, которые не проверяются, ошибки функционала с которым не осуществляется взаимодействие во время выполнения скрипта.
Что нужно автоматизировать?
Спрашивая: «Что автоматизировать?», необходимо сначала ответить на вопрос: «Целесообразна ли автоматизация тестирования в условиях проекта». Если ответ «ДА», то необходимо, исходя из требований к объекту тестирования, создать план, по которому будут разрабатываться автоматизированные тесты. План должен отвечать на вопросы:
"что автоматизировать?"
"как автоматизировать?"
"чем автоматизировать?"
Например:
Труднодоступные места в системе (бэкенд процессы, логирование файлов, запись в БД)
Часто используемая функциональность, риски от ошибок в которой достаточно высоки. Автоматизировав проверку критической функциональности, можно гарантировать быстрое нахождение ошибок, а значит и быстрое их решение.
Рутинные операции, такие как переборы данных (формы с большим количеством вводимых полей. Автоматизировать заполнение полей различными данными и их проверку после сохранения)
Валидационные сообщения (Автоматизировать заполнение полей не корректными данными и проверку на появление той или иной валидации)
Длинные end-to-end сценарии
Проверка данных, требующих точных математических расчетов
Проверка правильности поиска данных
Для более эффективного использования автоматизации тестирования лучше разработать отдельные тест кейсы проверяющие:
Базовые операции создания/чтения/изменения/удаления сущностей (так называемые CRUD операции - Create / Read / Update / Delete).
Типовые сценарии использования приложения, либо отдельные действия
Интерфейсы, работы с файлами и другие моменты, неудобные для тестирования вручную
Как автоматизировать?
Во первых, вы должны обратить внимание насколько хорошо инструмент для автоматизации распознает элементы управления в вашем приложении.
Во-вторых, нужно обратить внимание на то сколько времени требуется на поддержку скриптов написанных с помощью выбранного инструмента.
И последний момент на который нужно обратить внимание – насколько удобен инструмент для написания новых скриптов. Сколько требуется на это времени, насколько можно структурировать код (поддержка ООП), насколько код читаем, насколько удобна среда разработки для рефакторинга (переработки кода) и т.п.
Три уровня автоматизации тестирования
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 & Post Condition.
Соответственно каждый тест скрипт должен иметь:
Precondition
Steps (Test)
Post Condition
Precondition
Инициализация приложения (например, открытие главной страницы, вход под тестовым пользователем, переход в необходимую часть приложения и подведение системы к состоянию пригодному для тестирования)
Steps
Непосредственное проведение теста
Занесение данных о результате теста, с обязательным сохранением причин провала и шагов, по которым проходил тест
Post Condition
Удаление, созданных в процессе выполнения скрипта, ненужных тестовых данных
Корректное завершение работы приложения
Резюмируя:
Автоматизация необходима для создания “страховочной сетки”, получения существенного отклика, сведения к минимуму уровня технического долга и помощи в разработке
Страх, недостаток знаний, отрицательный прошлый опыт внедрения автоматизации, быстро изменяющийся код, унаследованный код — все это распространенные барьеры на пути автоматизации
Автоматизация регрессивных тестов и утомительной ручной работы освобождает команду для решения более важных задач, таких как исследовательское тестирование
Без автоматизации регрессивных тестов объем ручного регрессивного тестирования будет продолжать расти в объеме и в конечном итоге может просто игнорироваться
Пример:
Надо проверить код осуществляющий покупку товара
Необходимо протестировать вызов этой функции с различными параметрами. Для случая itemID==0 и ItemID<>0
Пример:

Необходимо залогиниться не используя интерфейс:
Full transcript