22
программного обеспечения. С одной стороны существует множество
разнообразных видов тестирования, с другой стороны можно отметить, что
отрасль тестирования программного обеспечения довольно молода, и
вероятнее всего типизация видов тестирования будет меняться и
дополняться.
1.3 Процесс тестирования
Тестирование программного обеспечения представляет собой процесс
сверки реального поведения ПО и ожидаемого. Процесс осуществляется в
искусственно созданных условиях – такого рода ситуации называются
тестами. Тесты разрабатываются на основе документации представленной
заказчиком. Тесты группируются в тестовые наборы (test suite). После
выполнения теста или тест набора собираются отчеты, и происходит анализ
поступивших данных. После анализа полученных данных становится ясно,
есть ли в программном обеспечении дефекты или нет.
Рисунок 2 – Процесс тестирования
23
1.3.1 Разработка тест-кейсов
Тест-кейс (тестовый ситуация, test case) – это минимальный элемент
тестирования (одна проверка), представляет собой совокупность шагов,
инструкций, которые требуются для реализации проверки какой-либо
тестируемой функции. [29]
Под тест-кейсом подразумевается структура вида:
Action > Expected Result > Test Result
Таблица 4 – Структура тест кейса
Action
Expected result
Test result
(passed/failed/blocked)
Open page “Login”
Login page is opened
Passed
Тест-кейсы позволяют проводить тестирование «черным ящиком», без
полного ознакомления с документацией по программному продукту. Если
тест-кейс написан грамотно, то он должен легко поддерживаться при
дальнейшей разработке программного обеспечения, что позволяет экономить
время тестировщиков. Вариант с подробными тест-кейсами позволяет
повысить качество тестирования, в ущерб вариативности тестирования, и
увеличивает время и трудозатраты на поддержку тестового набора.
Структура тестовой ситуации включает в себя [10]:
• уникальный идентификатор - используется для удобной
организации - хранения и навигации по тестам.
• название - краткое описание сути тестовой ситуации.
• предусловия - условия, которые должны быть выполнены,
прежде чем начнется выполнение тест-кейса. Как пример,
24
тестирование формы регистрации: чтобы пользователь смог
зарегистрироваться у него обязательно должна быть электронная
почта. В данном случае, наличие электронной почты является
предусловием, для начала тестирования формы регистрации.
• шаги - поэтапное описание действий, которые должны произойти
в тест-кейсе.
• ожидаемый результат - результат, который мы ожидаем увидеть
после выполнения тест-кейса.
Также к тест-кейсу предъявляются определенные требования.
- тест-кейс можно считать хорошим, если он может обеспечить
высокую вероятность обнаружения ошибки. Невозможно достигнуть полного
отсутствия ошибок в программе, исходя из этого, процесс тестирования
следует направить на выявление прежде не обнаруженных дефектов.
- каждый шаг в тест-кейсе должен содержать в себе всю необходимую
информация для прохождения теста, но следует избегать излишней
детализации при написании тест-кейса.
- следует придерживаться самодостаточности тестов. При написании
тестов желательно исключить ситуации излишних зависимостей между тест-
кейсами. [1] Следует понять, что чем больше тестов входит в цепочку
взаимосвязанных тестов, тем сложнее будет происходить дальнейшая
поддержка таких тестов. Независимость теста по времени и порядку
исполнения позволит избежать ситуации, когда были внесены изменения в
один из начальных тестов, и последующие тесты теряют свой контекст.
- ожидаемый результат следует прописывать в тест-кейс сразу же при
создании теста. Если ожидаемый результат не был определен заранее, то
25
впоследствии тестировщик может посчитать неверный результат за
ожидаемый.
- негативное тестирование не менее важное, чем позитивное.
Негативное тестирование проверяет нестандартные ситуации для
программного обеспечения. Следует помнить, что большое количество
дефектов, связано именно с непредусмотренными программой действиями
пользователей.
- мониторинг побочной активности программы. Возможна ситуация,
когда тест-кейс завершился согласно ожидаемому результату и тест можно
считать положительным, но тестировщик упустил, что в момент
прохождения теста были пиковые нагрузки на систему или какие либо другие
дефекты не связанные непосредственно с тестовой ситуацией.
Таблица 5 – Пример тест-кейса
№
Название
тест-кейса
Шаги
Ожидаемый результат
1.
Проверка
валидного
значения
времени.
1.Ввести в поле «Введите
время» значение «16:15»,
2.Нажать на кнопку
«Показать»,
3.Посмотреть на циферблат
аналоговых часов.
Коротка стрелка
показывает на цифру 4,
Длинная стрелка
показывает на цифру 3.
2.
Проверка
значения
времени с
недостающей
1.Ввести в поле «Введите
время» значение «6:5»,
2.Нажать на кнопку
«Показать»,
Автокорректировка
формата времени
(подстановка
недостающих нулей),
26
цифрой в
минутах и
часах.
3.Посмотреть на циферблат
аналоговых часов.
Коротка стрелка
показывает на цифру 6,
Длинная стрелка
показывает на цифру 1.
1.3.2 Выполнение тест-кейсов
Тестирование программного обеспечения желательно проводить
специалистом, который не был непосредственно задействован в написании
кода. В таком случае качество процесса тестирования значительно
повышается, тестирование становится более эффективным и точным.
Сам процесс тестирование по своей природе является деструктивным.
В это кроется различия в психологическом подходе к созданному продукту.
Программисту при создании программного обеспечения, приходиться
настраиваться на конструктивный процесс. Также, следует помнить, что за
время работы с кодом у программиста может появиться «привыкание» к
коду, и он будет считать ожидаемым, фактически, не верный результат
работы ПО. Тестировщик изначально настроен более деструктивно, по
отношению к программному обеспечению. С таким подходом тестировщику
изначально проще находить дефекты в программном обеспечении.
И хотя многие программисты вполне успешно самостоятельно
справляются с задачей тестирования программного обеспечения, следует
заметить, что выполнение тестирования другим специалистом даст больший
эффект и будет проходить более плодотворно. Именно по этой причине
создаются отдельные группы тестировщиков.
Одной из главных проблем при проведении тестирования является
принятие решение о достаточности тестирования. Это происходит потому,
27
что относительно большинства программных продуктов фактически
невозможно провести исчерпывающее тестирование. Одной из причин
сложности данного процесса является большое количество входящих
данных. Наступает момент, когда техническая сторона процесса вступает в
конфронтацию с экономической частью и руководству проекта, приходиться
решать проблему: какое количество тестов даст оптимальный вариант
качества, при оптимальных затратах.
Довольно часто возникает ситуация, когда созданные тесты были
малоэффективны, так как их способность обнаружения дефектов была
крайне мала. В то же время, отличные тесты, обнаруживающие дефекты с
высокой вероятностью, оставались без должного внимания тестировщиков.
Из вышесказанного следует, что принимая решение о времени и
количестве проводимых тестов с продуктом, следует принимать во внимание
уровни риска, как технического характера, так и бизнес риски, для
программного продукта и для всего проекта. Также следует принимать во
внимание то, что проект обычно имеет ограничения по бюджету и времени.
1.3.3 Анализ результатов тестирования
Несмотря на разнообразие видов и типов тестирования, процессы
тестирования достаточно схожи. Разработкой и анализом тестов должен
заниматься тестировщик. За реализацию тестов так же несет ответственность
тестировщик, выполнение тест-кейсов может производиться вручную или в
автоматическом режиме.
По результату выполнения тест-кейсов, им присваивается статус
положительный, отрицательный или блокирован. Если тест-кейс получил
отрицательный статус или статус блокирован, то тестировщик может
28
провести дополнительную работу для выявления причины некорректного
поведения программного обеспечения.
При использовании методологии черного ящика, анализ результатов
теста сводится к выявлению общих закономерностей, ведущих к появлению
ошибки. Однако когда используется методологии белого или серого ящика,
тестировщик может провести более глубокий анализ причин возникновения
дефекта. В зависимости от доступных тестировщику данных (база данных,
исходный код программы, логов и т.п.), он способен с некоторой точностью
определить источник некорректного поведения программы.
После того, как максимально точно выявлена причина нежелательного
поведения, тестировщик должен описать её вместе со способом
воспроизведения ошибки для дальнейшей передачи этой информации
разработчикам. Когда источник ошибки точно определен и хорошо описан,
разработчикам гораздо проще исправить эту ошибку.
В данном параграфе были рассмотрены основные этапы процесса
тестирования программного обеспечения, определены такие понятия, как
тест-план и тест-кейс.
ВЫВОДЫ по главе 1. Информация в данной главе позволяет нам
сделать вывод, что в связи с бурным ростом отрасли информационных
технологий, с такой же скоростью будет расти важность процессов
тестирования ПО. Также стоит принять во внимание многообразие видов и
методов тестирования, что будет постоянно увеличивать финансовую
нагрузку на бизнес. Возникшая проблема подтверждает актуальность
исследования процесса автоматизации регрессионного исследования и
требует более пристально рассмотреть предмет исследования.
29
ГЛАВА 2. АНАЛИЗ И ОПИСАНИЕ ПРОЦЕССА
АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
2.1 Описание процесса автоматизации тестирования
Автоматизированное тестирование программного обеспечения — часть
процесса тестирования на этапе контроля качества в процессе разработки
программного обеспечения. Оно использует программные средства для
выполнения тестов и проверки результатов выполнения, что помогает
сократить время тестирования и упростить его процесс. [34] Автоматизация
тестирования это не просто выполнение автоматических тестов, это
написание и использование всевозможных скриптов для анализа результатов,
подготовки тестовых данных, парсинга документов и т.п., фактически,
автоматизация всех рутинных и повторяющихся задач для облегчения
процесса тестирования.
Рисунок 3 – Цели автоматизации тестирования
30
Автоматизированное тестирование решает тот же тип задач, что и
ручное тестирование. Автоматизированное тестирование производится при
помощи специализированного программного обеспечения и с
использованием разнообразных вспомогательных инструментов. Результатом
автоматизации тестирования становиться повышение качества тестирования
при ускорении самого процесса тестирования. [24]
Как бы привлекательно не выглядела, для бизнеса, идея переложить
тестирование на программное обеспечение, уже в самом начале, при
внедрении автоматизации начинают возникать определенные проблемы [6]:
• отношение программистов – многие программисты отказываются
понимать, зачем нужны авто-тесты, если уже есть тестировщики.
• внедрение автоматизации процесс долги и дорогостоящий.
• внедрению автоматизации предшествует долги и кропотливый
процесс сбора данных о тестах и анализе средств, стратегий и
прочего.
• «legacy code» (устаревший код) – скорость развития
информационных технологий приводит к тому, что программный
код написанный несколько лет назад считается, фактически,
устаревшим. Возможны ситуации, когда современно ПО
откажется взаимодействовать с устаревшим кодом. Подобного
рода проблемы делают процесс внедрения автоматизации
тестирования проблематичным.
• отлаженный процесс тестирования тоже может стать проблемой
для автоматизации. Когда тестировщики привыкают делать свою
работу одинаково из релиза в релиз, возникают ситуации, что
31
сама тестовая команда будет противиться внедрению процесса
автоматизации тестирования.
Внедрение авто-тестов всегда должно начинаться с организации
процесса ручного тестирования, таких как, грамотная документация,
написанная для такого тестирования. Мы приходим к тому, что для того,
чтобы начать внедрение процесса автоматизации, нужно знать конкретно,
что и как должно быть реализовано в программном продукте. Обычно
каждый авто-тест основывается на каком-либо тест-кейсе используемом для
ручного тестирования у которого присутствует повышенная детализация.
При старте внедрения авто-тестирования, нам следует определить, что
именно нужно автоматизировать, необходимо корректно оценить
целесообразность автоматизации процесса тестирования в условиях
конкретного проекта. Если оценка показывает, что автоматизация
целесообразна, то следующим шагом будет, разработка тест-плана, согласно
требованиям применяемым к объекту тестирования. При разработке тест-
плана, тестировщику следует четко понимать, что нужно автоматизировать и
как именно это следует реализовать. Автоматизация тестирования, в
большинстве случаев, дает возможность существенно ускорить и удешевить
процесс тестирования, но следует помнить, что существует ряд условий, при
наличии которых процесс автоматизации становиться особенно эффективен:
• Рутинные, однообразные операции, такие как заполнение каких-
либо форм, с большим количеством полей.
• Валидационные сообщения, проверка появления сообщений об
ошибках или неверном поведении пользователя или программы.
• Критическая функциональность которая используется довольно
часто, и мало подвергается изменениям.