Размещено на http://www.allbest.ru/

Оглавление

Введение

Глава 1. Теоретические аспекты процесса тестирования

1.1 Определение понятия тестирования ПО

1.2 Классификация видов тестирования

1.3 Методологии тестирования

1.4 Процесс тестирования

1.4.1 Разработка тест-кейсов

1.4.2 Выполнение тест-кейсов

1.4.3 Анализ результатов тестирования

Глава 2. Описание и анализ процесса автоматизированного тестирования

2.1 Описание процесса тестирования

2.2 Критерии эффективности процесса тестирования

Глава 3. Автоматизация процесса тестирования

3.1 Описание компании

3.2 Расчёт экономической целесообразности введения автоматизированного тестирования

3.3 Внедрение автоматизированных тестов

Вывод

Список литературы

Приложение



Введение

Основной пик интереса к тестированию программного обеспечения пришелся на девяностые года в США. Быстрое развитие систем автоматизированной разработки программного обеспечения и сетевых технологий привело к увеличению производства на рынке программного обеспечения. Усиление конкуренции между производителями программного обеспечения требовало повышенного внимания к качеству продукции. Поскольку ассортимент продукции сильно расширился, а цены стали доступнее, потребители начали обращать большее внимание на качество программного обеспечения. В настоящее время практически все области жизни подвержены компьютеризации. Мало того, что компьютеры, используются в повседневной жизни для обычных целей, они также необходимы, когда речь идет о гораздо более значимых сферах, таких как медицина, транспорт, строительство, безопасность и многие другие. Таким образом, вопрос о качестве программного обеспечения становится особенно важным, поскольку это не только вопрос комфорта, но и безопасности.

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

Вскоре после этого тестирование программного обеспечения стало неотъемлемой частью производства программного обеспечения. Тестирование необходимо для того, чтобы понять, работает ли программа, как ожидается и соответствует ли она предъявляемым к ней требованиям. Своевременное выявление и исправление ошибок и недоработок имеет огромное значение в процессе разработки программного продукта, поскольку это уменьшает риски и при этом происходит снижение затрат на разработку программного обеспечения. Благодаря тестированию, компании способны поддерживать качество своих продуктов на очень высоком уровне. Часто процесс тестирования ПО может быть автоматизирован, что в некоторых случаях может положительно отразится на скорости и качестве тестирования, это позволяет ещё больше снизить издержки компании и повысить качество продукта.

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

Целью данного исследования является анализ эффективности использования автоматизированного тестирования. Для достижения поставленной цели были определены следующие задачи:

· Выявление теоретических основ тестирования, классификация и описание его видов.

· Анализ и описание процесса тестирования, выявление критериев корректно построенного процесса.

· Определение критериев эффективности процесса тестирования.

· Расчёт экономической целесообразности введения автоматизированного тестирования.

· Внедрение автоматизированного тестирования.

Для достижения поставленных задач были выбраны такие теоретические методы исследования как анализ, для решения задач, связанных с анализом и описанием понятия и процесса тестирования, и классификация, для описания видов тестирования. Для выполнения практической части исследования использовались такие эмпирические методы, как беседа, для сбора данных, необходимых для расчета экономической целесообразности введения автоматизированного тестирования в компании, и эксперимент, позволяющий на практике определить эффективность внедрения автоматизированного тестирования.

Для данного исследования была использована литература описывающая различные направления тестирования. Для решения теоретических задач, таких как анализ процессов тестирования и его видов, использовались фундаментальные, классические для области тестирования книги, такие как «Ключевые процессы тестирования» автора Рекс Блэк, «Software Testing» автора Ron Patton. Для решения задач, связанных с автоматизированным тестированием, использовалась литература более узкой направленности, такая как «Автоматизация процессов тестирования» Винниченко И. В. При изучении экономических аспектов автоматизированного тестирования и расчетах использовалась следующие книги и статьи: Александр Хрущев «Эффективность использования автоматических тестов в ИТ-проектах», Максим Черняк «Оценка эффективности автоматизации тестирования» и «Автоматизированное тестирование программного обеспечения» авторов Элфрид Дастин, Джефф Рэшка, Джон Пол.

Структура работы обусловлена целью и задачами исследования. Работа состоит из введения, трех глав и заключения.

В введении отражена актуальность работы, определена степень научной проработанности темы, описаны цель, задачи и методы исследования, дана характеристика основных источников информации.

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

Заключение состоит из итогов исследования и окончательных выводов по рассматриваемой теме, сформированных в процессе данного исследования.

В приложении предоставлен полный исходный код решения по автоматизации тестов.



Глава 1. Теоретические аспекты процесса тестирования

Данная глава посвящена решению таких задач, как выявление теоретических основ тестирования, классификация и описание видов тестирования, анализ и описание процесса тестирования, выявление критериев корректно построенного процесса.

Решение данных задач необходимо для того, чтобы лучше понимать процессы тестирования, различать виды тестирования и применять знания при оценке целесообразности внедрения автоматизированного тестирования в компании.

1.1 Определение понятия тестирования ПО

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

Тестирование - это одна из техник контроля качества, которая включает в себя такие процессы, как проектирование тестов, выполнение тестирования и анализ полученных результатов.

Общая схема тестирования (рисунок 1):

Рисунок 1. Общая схема тестирования.



На входе тестировщик получает программу, которую необходимо тестировать и требования. Наблюдая за программой в определенных условиях, на выходе тестировщик получает информацию о соответствии или несоответствии программы требованиям. Данная информация используется для исправления ошибок в существующем продукте, любо для изменения требований к еще только разрабатываемому продукту [1].

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

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

Таким образом, в процессе тестирования тестировщик выполняет две основные задачи.

Первой задачей является управление выполнением программы, а также создание искусственных ситуаций, в которых и происходит проверка поведения программы.

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

Если рассматривать задачи современного тестирования, то можно прийти к заключению, что они заключаются не только в обнаружении ошибок в программах, но и в выявлении причин, по которым они возникают. Такой подход к процессу тестирования позволяет разработчикам выполнять свою работу с максимальной эффективностью, устраняя обнаруженные ошибки быстро и своевременно.



1.2 Классификация видов тестирования

тестирование программный обеспечение автоматизированный

При тестировании программного продукта применяется огромное количество различных видов тестов. Наиболее широкую и подробную классификацию предложил автор книги «Тестирование Дот Ком» Роман Савин. Он объединил виды тестирования по таким признакам, как объект, субъект тестирования, уровень, позитивность тестирования, и степень автоматизации тестирования. Классификация была дополнена на основании таких источников, как книга Сэма Канера, «Тестирование программного обеспечения» и интернет-ресурс, посвященный тестированию, «Про Тестинг - Тестирование Программного Обеспечения».

По объекту тестирования

· Функциональное тестирование. Функциональное тестирование на сегодняшний день является одним из наиболее часто применяемых видов тестирования. Задача такого тестирования - это установить на сколько соответствует разработанное программное обеспечение (ПО) требованиям заказчика с точки зрения функционала. Иначе говоря, проведение функциональных тестов позволяет проверить способность информационной системы решать задачи пользователей.

· Нефункциональное тестирование. Позволяет проверить соответствие свойств программного обеспечения с поставленными нефункциональными требованиями. Таким образом, нефункциональное тестирование - это тестирование всех свойств программы, не относящихся к функциональности системы. Такими свойствами могут быть предъявленные характеристики с точки зрения таких параметров как:

- Надежность (способность системы реагировать на непредвиденные ситуации).

- Производительность (способность системы работать под большими нагрузками).

- Удобство (исследование удобства работы пользователя с приложением).

- Масштабируемость (возможность масштабировать приложение как вертикально, так и горизонтально).

- Безопасность (исследование возможности нарушения работы приложения и кражи пользовательских данных злоумышленниками).

- Портируемость (возможность перенести приложение на определенный набор платформ)

И много других качеств.

· Тестирование пользовательского интерфейса. Это тестирование корректности отображения элементов пользовательского интерфейса на различных устройствах, правильности реагирования их на совершение пользователем различных действий насколько и оценка того, насколько ожидаемо ведет себя программа в целом. Такое тестирование дает возможность оценить, насколько эффективно пользователь сможет работать с приложением и насколько внешний вид приложения соответствует утвержденным документам, созданными дизайнерами. При проведении тестирования пользовательского интерфейса основной задачей тестировщика является выявление визуальных и структурных недостатков в графическом интерфейсе приложения, проверке возможности и удобства навигации в приложении и корректность обработки приложением ввода данных с клавиатуры, мыши и других устройств ввода. Тестирование пользовательского интерфейса необходимо для того, чтобы убедиться в том, что интерфейс соответствует утвержденным требованиям и стандартам, и гарантировать возможность работы пользователя с графическим интерфейсом приложения.

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

· Тестирование защищенности. Позволяет выявить главные уязвимости программного обеспечения по отношению к различным атакам со стороны злоумышленников. Компьютерные системы довольно часто подвергаются кибер атакам с целью нарушения работоспособности информационной системы либо кражи конфиденциальных данных. Тестирование безопасности дает возможность проанализировать реальную реакцию и действенность защитных механизмов, использованных в системе, при попытке проникновения. В процессе тестирования безопасности тестировщик пытается выполнять те же действия, которые выполнял бы настоящий взломщик. При попытке тестировщиком взломать систему могут использоваться любые средства: атаки системы при помощи специальных утилит; попытки узнать логины и пароли с помощью внешних средств; DDOS атаки; целенаправленная генерация ошибок для обнаружения возможности проникновения в систему в процессе её восстановления; использование известных незакрытых уязвимостей системы.

· Инсталляционное тестирование. Под этим термином подразумевают тестирование корректности установки (инсталляции) определенного программного продукта. Такое тестирование обычно происходит в искусственно созданных средах с целью выявить степень готовности программного обеспечения к эксплуатации. Основные причины проведения таких тестов связаны с необходимостью проверить корректность поведения программного продукта при автоматизированном развертывании либо обновлении. Обеспечение правильной и стабильной установки программного обеспечения является очень важным фактором при создании программного продукта, поскольку позволяет пользователям быстрее и с меньшими усилиями начать использовать продукт, при этом обеспечивая одинаково корректное поведение этого продукта во всех протестированных программных средах.

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

· Тестирование надежности и восстановления после сбоев (стрессовое тестирование). Такой вид тестирования довольно часто проводится для программного обеспечения, работающего с ценными пользовательскими данными, бесперебойность работы и скорость восстановления после сбоев которого критичны для пользователя. Тестирование на отказ и восстановление осуществляет проверку способности программы быстро и успешно восстанавливаться после отказа оборудования, перебоев сети или критических ошибок в самом программном обеспечении. Это дает возможность оценить возможные последствия отказа и время, необходимое для последующего восстановления системы. На основе полученных в ходе тестирования данных может быть оценена надежность системы в целом, и, при условии неудовлетворительных показателей, соответствующие меры, направленные на улучшение систем восстановления, могут быть приняты

· Тестирование локализации. Тестирование локализации дает возможность выяснить насколько хорошо приспособлен продукт для населения определенных стран и насколько он соответствует ее культурным особенностям. Обычно, рассматриваются культурный и языковой нюансы, а именно перевод пользовательского интерфейса, сопутствующей документации и файлов на определенный язык, также тестируется правильность форматов валют, чисел, времени и телефонных номеров.

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

· Тестирование стабильности. Тестирование стабильности проверяет работоспособность приложения при длительном использовании на средних нагрузках. В зависимости от типа приложения, формируются определенные требования к длительности его бесперебойной работы. Тестирование стабильности стремится выявить такие недочеты приложения как утечки памяти, наличие ярко выраженных скачков нагрузки и прочие факторы, способные помешать работе приложения в течение длительного периода времени.

· Объемное тестирование. Задачей объемного тестирования поставлено выявление реакции приложения и оценка возможных ухудшений в работе ПО при значительном увеличении количества данных в базе данных приложения. Обычно в такое тестирование входит:

- Замер времени выполнения операций, связанных с получением или изменением данных БД при определенной интенсивности запросов.

- Выявление зависимости увеличения времени операций от объема данных в БД.

- Определение максимального количества пользователей, которые имеют возможность одновременно работать с приложением без заметных задержек со стороны БД.

• Тестирование масштабируемости. Это вид тестирования программного обеспечения, предназначенный для проверки способности продукта к увеличению (иногда к уменьшению) масштабов определенных нефункциональных возможностей. Некоторые виды приложений должны легко масштабироваться и, при этом, разумеется, оставаться работоспособными и выдерживать определенную пользовательскую нагрузку [2].

Тестирование, связанное с изменениями

· Санити является одним из видов тестирования, целью которого служит доказательство работоспособности конкретной функции или модуля в соответствии с техническими требованиями, заявленными заказчиком. Санитарное тестирование довольно часто используется при проверке какой-то части программы или приложения при внесении в нее определенных изменений со стороны факторов окружающей среды. Данный вид тестирования обычно выполняется в ручном режиме.

· Дымовое тестирование представляет собой короткий цикл тестов, целью которых является подтверждение факта запуска и выполнения функций устанавливаемого приложения после того как новый или редактируемый код прошел сборку. По завершении тестирования наиболее важных сегментов приложения предоставляется объективная информация о присутствии или отсутствии дефектов в работе тестируемых сегментов. По результатам дымового тестирования принимается решение об отправке приложения на доработку или о необходимости его последующего полного тестирования.

· Регрессионное тестирование - тестирование, направленное на обнаружение ошибок в уже протестированных участках. Регрессионное тестирование проверяет продукт на ошибки, которые могли появиться в результате добавления нового участка программы или исправления других ошибок. Цель данного вида тестирования - убедиться, что обновление сборки или исправление ошибок не повлекло за собой возникновения новых багов [3].

По уровню тестирования

· Модульное тестирование (Unit тесты). Заключается в проверке каждого отдельного модуля (самобытного элемента системы) путем запуска автоматизированных тестов в искусственной среде. Реализации таких тестов часто используют различные заглушки и драйверы для имитации работы реальной системы. Модульное автоматизированное тестирование - это самая первая возможность запустить и проверить исходный код. Создание Unit тестов для всех модулей системы позволяет очень быстро выявлять ошибки в коде, которые могут появиться в ходе разработки.

· Интеграционное тестирование. Это тестирование отдельных модулей системы на предмет корректного взаимодействия. Основная цель интеграционного тестирования - найти дефекты и выявить некорректное поведение, связанное с ошибками в интерпретации или реализации взаимодействия между модулями.

· Системное тестирование. Это тестирование программы в целом, такое тестирование проверяет соответствие программы заявленным требованиям.

· Приемочное тестирование. Это комплексное тестирование, определяющее фактический уровень готовности системы к эксплуатации конечными пользователями. Тестирование проводится на основании набора тестовых сценариев, покрывающих основные бизнес-операции системы [2].

По исполнению кода

· Статическое тестирование. Это выявление артефактов, появляющихся в процессе разработки программного продукта путем анализа исходных файлов, таких как документация или программный код. Такое тестирование проводится без непосредственного запуска кода, качество исходных файлов и их соответствие требованиям оцениваются вручную, либо с использованием вспомогательных инструментов. Статическое тестирование должно проводиться до динамического тестирования, таким образом, ошибки, обнаруженные на этапе статического тестирования, обойдутся дешевле. С точки зрения исходного кода, статическое тестирование выражается в ревизии кода. Обычно ревизия кода отдельных файлов производится после каждого изменения этих файлов программистом, сама же ревизия может проводиться как другим программистом, так и ведущим разработчиком, либо отдельным работником, занимающимся ревизией кода. Использование статического тестирования дает возможность поддерживать качество программного обеспечения на всех стадиях разработки и уменьшает время разработки продукта.

· Динамическое тестирование. В отличии от статического тестирования, такой вид тестирования предполагает запуск исходного кода приложения. Таким образом, динамическое тестирование содержит в себе множество других типов тестирования, которые уже были описаны выше. Динамическое тестирование позволяет выявить ошибки в поведении программы с помощью анализа результатов ее выполнения. Получается, что почти все существующие типы тестирования соответствуют классу динамического тестирования [1].

По субъекту тестирования

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

· Бета-тестирование. Тестирование продукта, по-прежнему находящегося в стадии разработки. При бета-тестировании этот продукт предоставляется для некоторого количества пользователей, для того чтобы изучить и сообщить о возникающих проблемах, с которыми сталкиваются пользователи. Такое тестирование необходимо чтобы найти ошибки, которые разработчики могли пропустить. Обычно бета-тестирование проводится в две фазы: закрытый бета-тест и открытое бета-тестирование. Закрытый бета-тест - это тестирование на строго ограниченном кругу избранных пользователей. Такими пользователями могут выступать знакомые разработчиков, либо их коллеги, не связанные напрямую с разработкой тестируемого продукта. Открытое бета-тестирование заключается в создании и размещении в открытом доступе публичной бета-версии. В данном случае любой пользователь может выступать бета-тестером. Обратная связь от таких бета-тестеров осуществляется с помощью отзывов на сайте и встроенных в программу систем аналитики и логирования пользовательских действий, эти системы необходимы для анализа поведения пользователей и обнаружения трудностей и ошибок, с которыми они сталкиваются [2].

По позитивности сценария

· Позитивное тестирование. Тесты с позитивным сценарием проверяют способность программы выполнять заложенный в нее функционал. Как правило, для такого тестирования разрабатываются тестовые сценарии, при выполнении которых, в нормальных для ПО условиях работы, не должно возникать никаких сложностей.

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

По степени автоматизации

· Ручное тестирование. Ручное тестирование проводится без использования дополнительных программных средств, оно позволяет проверить программу или сайт с помощью имитации действий пользователя. В этой модели тестировщик выступает в качестве пользователя, следуя определенным сценариям, параллельно анализируя вывод программы и ее поведение в целом.

· Автоматизированное тестирование. Такое тестирование позволяет за счет использования дополнительного программного обеспечения для автоматизации тестов значительно ускорить процесс тестирования. Такое дополнительное ПО позволяет контролировать и управлять выполнением тестов и сравнивать ожидаемый и фактический результаты работы программы. Более подробно будет рассмотрено позже [2].

1.3 Методологии тестирования

Существуют различные методологии динамического тестирования ПО. В зависимости от наличия у тестировщика доступа к исходному коду программы, выделяют следующие методы тестирования:

· Метод черного ящика

· Метод белого ящика

· Метод серого ящика

Метод черного ящика.

Впервые термин «черный ящик» упоминается психиатром У. Р. Эшби в книге "Введение в кибернетику" в 1959 г. Он писал, что метод черного ящика позволяет изучать поведение системы абстрагируясь от ее внутреннего устройства.

В области тестирования метод черного ящика - это техника тестирования, которая основана на работе с внешними интерфейсами программного обеспечения, без знания внутреннего устройства системы [4].

Данный метод назван “Черным ящиком”, поскольку в этом методе тестируемое программное обеспечение для тестировщика выглядит как черный ящик, внутри которого происходят некоторые процессы, однако тестировщику о них принципиально ничего не известно. Данная техника позволяет обнаружить ошибки в следующих категориях:

· Ошибки интерфейса.

· Недостающие или неправильно реализованные функции.

· Недостаточная производительность или ошибки поведения системы.

· Некорректные структуры данных или плохая организация доступа к внешним базам данных.

Таким образом, поскольку тестировщик не имеет никакого представления о внутреннем устройстве и структуре системы, ему необходимо сконцентрироваться на том, что делает программа, а не на том, как она это делает.

Метод белого ящика.

Как можно догадаться из названия, этот метод тестирования противоположен методу черного ящика. Данный метод тестирования основан на анализе внутренней структуры системы [4].

То есть в данном случае тестировщику известны все аспекты реализации тестируемого программного обеспечения. Этот метод позволяет протестировать не только корректность реакции программы на определенный ввод (как в случае с черным ящиком), но и правильную работу отдельных модулей и функций, основываясь на знании кода, который будет обрабатывать этот ввод. Знание особенностей реализации тестируемой программы - обязательное требование к тестировщику для успешного применения этой техники. Тестирование методом белого ящика позволяет углубиться во внутренне устройство ПО, за пределы его внешних интерфейсов.

Метод серого ящика.

Этот метод тестирования системы предполагает комбинацию подходов Белого и Черного ящиков. Таким образом, тестировщику лишь частично известно внутреннее устройство программы. Например, предполагается, наличие доступа к внутренней структуре программного обеспечения для разработки максимально эффективных тест-кейсов, в то время как само тестирование будет проводится методом черного ящика. Или тестировщики могут во всем следовать методу черного ящика, однако для того что бы убедиться в корректной работе отдельных алгоритмов могут смотреть информацию в логах или анализировать записи программы в базе данных.

1.4 Процесс тестирования

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

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

Процесс тестирования схематично показан на рисунке 2.

Рисунок 2. Процесс тестирования.

1.4.1 Разработка тест-кейсов

Тест-кейс (тестовый случай) - это минимальный элемент тестирования (одна проверка), содержащий в себе описание конкретных действий, условий и параметров, которые направленны на проверку какой-либо функциональности. Набор тест-кейсов называется тестовым набором (test suite).

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

Атрибуты тест-кейса.

Тест-кейс должен включать в себя:

· Уникальный идентификатор тест-кейса. Этот идентификатор необходим для удобства организации и навигации по тестовым наборам.

· Название. В названии должна отражаться основная идея тест-кейса, цель данной проверки.

· Предусловия. Список шагов, не имеющих прямого отношения к проверяемому функционалу, которые необходимо выполнить до начала теста. Например, для тест-кейса «Заказ товара» предусловием может быть шаг «авторизоваться на сайте», если на данном сайте заказать товар может только авторизованный пользователь.

· Шаги. Описание последовательности действий, которая должна привести к ожидаемому результату.

· Ожидаемый результат. Поведение системы, предусмотренное требованиями. Один тест-кейс проверяет одну конкретную функцию, поэтому ожидаемый результат может быть только один.

· Статус кейса. Проставляется в соответствии с тем, соответствует ли фактический результат ожидаемому. Тест-кейс может иметь один из трех статусов:

• Положительный, если фактический результат совпадает с ожидаемым результатом.

• Отрицательный, если фактический результат не совпадает с ожидаемым результатом. Если статус кейса отрицательный-найдена ошибка.

• Выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка.

· История редактирования. Дает возможность узнать, кем и когда был изменен тест-кейс. Это удобно, поскольку позволяет более эффективно редактировать тест-кейсы.

Требования к тест-кейсу

· Для измерения покрытия требований, требования к продукту должны быть проанализированы и впоследствии разбиты на пункты. Если тест-кейсы покрывают все требования, то может быть дан положительный или отрицательный ответ о реализации данного требования в продукте.

· Тест является хорошим в случае, когда он может обеспечить высокую вероятность обнаружения ошибки. Показать, что в программе полностью отсутствуют ошибки невозможно, поэтому процесс тестирования должен быть направлен на выявление прежде не найденных ошибок.

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

· Отсутствие зависимостей тест-кейсов. Если тесты связанны между собой, становится проблематичным изменение, дополнение или удаление конкретного тест-кейса, появляется необходимость изменять связанные с ним тесты. Более того, взаимосвязанные тесты обладают конкретный сценарием от перехода одного теста к другому. Это приведет к тому что не все сценарии перехода от одного теста к другому будут протестированы и появляется вероятность пропустить баг.

· Ожидаемый результат необходимо прогнозировать заранее и прописывать его в тест-кейсе. Если ожидаемый результат не определить заранее, может возникнуть ситуация, когда тестировщик видит то, что он хочет увидеть. При заранее определенном результате тестировщику необходимо только сравнить ожидаемый результат с фактическим.

· Необходимо уделять внимание не только тестам, которые проверяют правильные данные, но и тем тестам, которые проверяют работу программы при неправильных, непредусмотренных данных. Большое количество ошибок связано именно с теми действиями пользователя, которые не предусмотрены программой.

· Также необходимо проверять, не делает ли программа то, чего не должна. Нужно производить проверку на нежелательные побочные эффекты.

В таблице 1 приведен пример тест-кейса, отвечающего вышеописанным требованиям.

Таблица 1. Пример тест-кейса.

Тест PGU-1: ВСВ. Избранные услуги
Описание теста: цель, сценарий и исходное состояние программы: Проверка работы функциональности "Избранные услуги"
#:	Шаги:	Ожидаемая реакция:	Execution Status:
1	Авторизоваться на портале.	Авторизация прошла успешно.	Пройден
2	Перейти в версию для слабовидящих, кликнув на соответствующую иконку в левом верхнем углу.	Открылась главная страница портала в версии для слабовидящих.	Пройден
3	Перейти в каталог услуг, открыть любую карточку услуги.	Карточка услуги открыта успешно.	Пройден
4	Нажимаем "Добавить услугу" внизу страницы.	Попап "Услуга успешно добавлена в избранные. Вы можете перейти к ней из Личного кабинета".	Пройден
5	Повторяем шаги 3-4 несколько раз.	Шаги выполнены успешно, результаты соответствуют ожидаемым.	Пройден
6	Переходим в Личный кабинет.	По умолчанию открывается раздел "Мои услуги". Отображается пронумерованный список добавленных услуг в порядке их добавления.	Пройден
7	Проверяем переход на карточку услуги из списка избранных услуг.	Переход происходи корректно.	Пройден
8	Переходим обратно в ЛК. Отмечаем галочкой любую услугу.	Появилась кнопка "Удалить" внизу страницы.	Пройден
9	Нажимаем кнопку "Удалить"	Попап "Услуга успешно удалена из избранных.". Услуга пропала из списка избранных услуг.	Пройден
10	Поочерёдно удаляем остальные услуги.	Удаление прошло корректно.	Пройден
Execution type:	Вручную
Estimated exec. duration (min):	10.00
Приоритет:	Medium
Execution Details
Версия (сборка)	3.0.111/2.10.31
Тестировщик	elizaveta.cherkasova@rtlabs.ru
Execution Result:	Пройден
Execution Mode:	Вручную

Данный тест-кейс содержит следующие обязательные атрибуты:

· Уникальный идентификатор тест-кейса: PGU-1

· Название: ВСВ. Избранные услуги

· Предусловия: в данном тест-кейсе предусловием является авторизация на портале. Непосредственно к тесту авторизация не относится (авторизацию на портале проверяет отдельный тест-кейс), но без авторизации данная проверка невозможна.

· Шаги.

· Ожидаемый результат.

· Статус кейса.

· История редактирования: в тест-кейсе указана информация о том, кто проходил тест, в какое время и в рамках какой сборки.

Данный тест-кейс отвечает требованиям, изложенным выше. Шаги сформулированы однозначно, содержат необходимую, но не лишнюю информацию, ожидаемый результат четкий и однозначный.



1.4.2 Выполнение тест-кейсов

Одной из особенностей процесса тестирования является необходимость проведения тестирования программы специалистом, который не является ее автором. Категорически неприемлемо тестирование продукта программистом, создавшим его. Это правило должно быть применимо ко всем, без исключения, формам тестирования, например, как к тестированию целой системы, так и к тестированию отдельных модулей, а также внешних функций. Несомненно, при проведении процесса тестирования не автором программы, он становится более точным и эффективным.

Если рассматривать суть процесса тестирования, то становится очевидным, что это процесс деструктивный. С этой его особенностью и связывают представление о тестировании как о сложной работе. Исключительно трудной эта работа представляется для программиста, создавшего продукт, так как проектирование, разработка и написание программы является процессом конструктивным, в отличие от тестирования, в процессе которого специалисту необходим настрой на деструктивный образ мышления. Исходя из этой особенности тестирования, приступать к тщательному и беспристрастному выявлению ошибок сразу же по завершению создания программы представляется трудновыполнимым для ее автора.

Например, содержащиеся в модуле дефекты, которые являются следствием ошибок перевода (такие как, к примеру, неверная интерпретация спецификации), с высокой долей вероятности будут присутствовать и в тестах, так как оба процесса будут выполняться одним и тем же специалистом. Также могут обнаружиться в тестах и ошибки, сделанные при понимании и сопряжении других модулей.

Однако, не следует делать однозначный вывод, что тестирование программы специалистом ее создавшим невозможно. Большое количество программистов справляются с этой задачей вполне успешно. Но, исходя из вышесказанного, можно прийти к заключению, что выполнение тестирования другим специалистом, не являющимся ее автором, гораздо эффективнее и плодотворнее. Поэтому и создаются группы тестировщиков, специально для проведения процесса тестирования с наиболее оптимальными результатами.

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

Существует довольно много примеров, когда написанные тесты были малоэффективны, так как их способность обнаружения новых ошибок была крайне низкой. В то же время, хорошие тесты, обнаруживающие ошибки с высокой точностью, могли остаться без внимания специалистов.

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

1.4.3 Анализ результатов тестирования

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

По результатам выполнения каждого теста, ему присваивается статус (положительный, отрицательный, блокирован). Если тест получает отрицательный статус, то в зависимости от методологии тестирования тестировщик может проводить дополнительную работу для выявления конкретной ошибки, которая была причиной некорректного поведения программы [4].

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

После того, как максимально точно выявлена причина нежелательного поведения, тестировщик должен описать её вместе со способом воспроизведения ошибки для дальнейшей передачи этой информации разработчикам. Когда источник ошибки точно определен и хорошо описан, разработчикам гораздо проще исправить эту ошибку.



Глава 2. Описание и анализ процесса автоматизированного тестирования

Данная глава посвящена описанию автоматизированного тестирования, его типам, выявлению достоинств и недостатков в автоматизации тестирования.

Более того в этой главе определены критерии эффективности процесса тестирования, описаны формулы для расчёт экономической целесообразности введения автоматизированного тестирования.

2.1 Описание процесса тестирования

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

Автоматизация процесса тестирования программного обеспечения делает возможным повышение качества тестирования и ускоряет процесс его проведения.

Автоматизация тестирования начинается с построения процесса ручного тестирования, а именно, с документации, написанной для такого тестирования. Таким образом, для того, чтобы начать процесс автоматизации тестирования, нужно точно знать, что и как должно быть реализовано. Обычно каждый автоматизированный тест базируется на тест-кейсе для ручного тестирования с повышенным уровнем детализации.

Выбор тестов для автоматизации.

Для того, чтобы определить, что именно нужно автоматизировать, необходимо сначала оценить целесообразность автоматизации тестирования в условиях проекта. Если автоматизация целесообразна, то, принимая во внимание требования к объекту тестирования, необходимо разработать план, согласно которому автоматизированные тесты будут создаваться. При разработке подобного документа, необходимо четко понимать, что нужно автоматизировать и как именно это реализовать. Автоматизация тестирования обычно позволяет ускорить и удешевить процесс тестирования, однако существуют условия, в которых автоматизация особенно эффективна:

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

· Рутинные операции, например проверка форм, в которых необходимо заполнять большое количество полей.

· Труднодоступные места в системе, такие как запись в базу данных, бекэнд процессы, логирование.

· Валидационные сообщения (проверка появления валидации при некорректном заполнении поля)

· Проверка корректного поиска данных

· Проверки, требующие точных математических расчетов

· Длинные end-to-end сценарии

И многое другое, в зависимости от инструментов тестирования и требований к системе.

Можно выделить три основных вида автоматического тестирования: модульное тестирование (unit test), тестирование API и GUI тесты.

· Модульное тестирование является самым низким уровнем автоматизированного тестирования. Поиск ошибок осуществляется на уровне функций, методов, процедур. Данные тесты обычно пишутся разработчиками.

· Тестирование API осуществляет проверку взаимодействия нескольких модулей между собой, или проверяет взаимодействие со сторонними сервисами.

· GUI тесты - тестирование через графический пользовательский интерфейс. С помощью имитации действий пользователя проверяются такие аспекты, как надлежащее функционирование кнопок и полей, правильное появление диагностических сообщений об ошибках и корректная работа приложения в целом. Написанием GUI тестов чаще всего занимаются тестировщики.

Сегодня существует множество средств, позволяющих автоматизировать тестирование программного продукта. Однако автоматизация тестирования не всегда востребована, ведь в конечном итоге может оказаться что разработка и сопровождение систем автоматизированного тестирования обойдется компании дороже, чем труд ручных тестировщиков.

При анализе целесообразности создания систем автоматизированного тестирования важно оценить:

· насколько сложно эту работу выполнять “руками”

· как часто будут выполняться эти тесты

· необходимо ли увеличивать скорость выполнения тестов

· если тесты нужно автоматизировать, то нужно ли это делать со всеми тестами, или достаточно автоматизировать лишь некоторые из них.

Основные задачи, которые решаются внедрением автоматизированного тестирования - это снижение времени, нужного для тестирования и повышение качества тестирования.

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

Следовательно, можно выделить основные плюсы и минусы автоматизированного тестирования.

Преимущества:

· Сокращение времени, затрачиваемого на исполнение тестов (относительно с ручного тестирования)

· Возможность проводить тесты, которые невозможно реализовать без использования программных средств автоматизации.

· Экспертиза становится более независимой, поскольку исключается человеческий фактор.

Недостатки:

· Автоматизация тестирования может потребовать очень значительных трудозатрат

· Требуется персонал с гораздо более высокой квалификацией

· Более сложный анализ результатов

· Повышение трудозатрат на актуализацию автотестов при изменениях в системе

· Риск появления ошибок в самом автотесте

· Не все тесты возможно автоматизировать

2.2 Критерии эффективности процесса тестирования

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

· Время, необходимое для разработки тестов

· Время, которое занимает один цикл тестирования

· Квалификация персонала, необходимая для разработки и проведения тестов

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

Автоматизируя процесс тестирования, мы, разумеется, меняем процесс тестирования, а вместе с ним поменяется и оптимальная комбинация перечисленных выше параметров. Например, можно ожидать, что увеличится время, необходимое для разработки тестов и повысятся требования к квалификации персонала, при этом сильно понизится, время, занимаемое одним циклом тестирования. Учитывая, что комбинация параметров стала новой, вероятно поменяется и качество тестирования вместе с его стоимостью. Для того чтобы была возможность дать численный эквивалент эффективности процесса тестирования, предлагается зафиксировать параметр качества на определенном уровне. Тогда численной оценкой эффективности определенного способа тестирования будет являться величина инвестиций, необходимая для того, чтобы он обеспечивал некий определенный уровень качества.

Оценка целесообразности автоматизации тестирования производится с помощью подсчета затрат на ручное и автоматизированное тестирование и их сравнение [5], [6]. Точно посчитать финансовую целесообразность автоматизации тестов обычно невозможно, поскольку она зависит от параметров, которые в процессе разработки продукта могут быть лишь примерно понятно (например, планируемая длина жизненного цикла системы или точный список тестов, подлежащих автоматизации).

Для расчёта инвестиций, необходимых для внедрения и эксплуатации автоматизированных тестов за выделенный период (Ip), используется следующая формула:



I0 - Оценка стартовых инвестиции, которые состоят из затрат на лицензии необходимого программного обеспечения для разработки автотестов, стоимости дополнительных аппаратных средств и.т.п.

C0 - Оценка стоимости разработки и отладки библиотеки автоматических тестов, которая рассчитывается как произведение среднего времени, нужного для написания одного автоматизированного теста одним разработчиком тестов (в часах), умноженное на цену его рабочего часа и на общее количество тестов, которые предстоит автоматизировать.

k - Это количество планируемых прогонов тестов (циклов тестирования) за всё оставшееся время жизненного цикла продукта.

Ce - Оценка стоимости одного прогона всех автоматизированных тестов, которая рассчитывается как время, необходимое для подготовки к выполнению тестирования, сложенное с средним временем выполнения одного теста одним тестировщиком, умножено на цену рабочего часа и на общее количество тестов. В нашем случае эта переменная принята за 0, поскольку подготовка к циклу тестирования не требуется, а само тестирование не требует дополнительного контроля со стороны работника и происходит полностью автономно.