Функциональное тестирование

Функциональное тестирование программного обеспечения

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

В зависимости от степени доступа к коду системы можно выделить два типа функциональных испытаний:

⦁ тестирование black box (черный ящик) – проведение функционального тестирования без доступа к коду системы,
⦁ тестирование white box (белый ящик) – функциональное тестирование с доступом к коду системы.
Тестирование black box проводится без знания внутренних механизмов работы системы и опирается на внешние проявления ее работы. При этом тестировании проверяется поведение ПО при различных входных данных и внутреннем состоянии систем. В случае тестирования white box создаются тест-кейсы, основанные преимущественно на коде системы ПО. Также существует расширенный тип black-box тестирования, включающего в себя изучение кода, – так называемый grey box (серый ящик).

Ключевые преимущества

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

Основные этапы функционального тестирования

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

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

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

Направления функционального тестирования

Регрессионное тестирование — Тестирование функциональности продукта после исправления ошибок или реализации новых функциональных возможностей

Тестирование безопасности — Оценка уязвимости ПО к различным атакам и попыткам несанкционированного доступа к данным.

Системное тестирование — Проверка соответствия ПО требованиям, заявленным в спецификации

Тестирование мобильных приложений — Выявление дефектов в работе графического интерфейса

Тестирование установки — Тестирование процесса инсталляции/деинсталляции программного обеспечения

Конфигурационное тестирование — Проверка работы ПО на различных программных и аппаратных окружениях.

Интеграционное тестирование — Тестирование взаимодействий между компонентами системы и между несколькими системами.

Smoke-тестирование — Короткий цикл тестов для выявления правильной работы основных функций приложения.

Тестирование документации — Проверка документов на соответствие принятым стандартам, а также соответствие определенным характеристикам

Обеспечение тестового покрытия — Оценка плотности покрытия системы тестами

Тестирование удобства использования — Определение степени удобства использования, понятности и привлекательности разрабатываемого продукта

Каждый раз при внесении изменений в систему, либо дополнения ее новым функционалом, существует

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

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

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

⦁ При регулярном проведении регрессионного тестирования — значительное сокращение количества дефектов в системе к моменту релиза.
⦁ Исключение деградации качества системы при росте функциональности.
⦁ Уменьшение вероятности критических ошибок в опытно-промышленной эксплуатации.

Основные этапы

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

Многие современные ИТ-системы взаимодействуют с другими системами и модулями, поэтому крайне

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

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

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

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

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

Основные задачи

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

Способы проведения интеграционного тестирования подбираются в зависимости от интеграционных решений.

Этапы

⦁ Разработка тест-плана – руководства к действию для тестировщиков;
⦁ Формирование тестовых данных и создание тест-кейсов;
⦁ Реализация сценариев для запуска тест-кейсов;
⦁ Выполнение тест-кейсов и исправление ошибок;
⦁ Повторение цикла тестирования до успешной интеграции.

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

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

таких систем функционального тестирования оказывается недостаточно.

⦁ Тестирование безопасности снижает вероятность несанкционированного доступа к системе, краж информации и потерь данных;
⦁ Клиенты получают объективную оценку уровня защищенности систем.

⦁ Анализ архитектуры и построение модели угроз и рисков
⦁ Определение критериев защищенности
⦁ Поиск уязвимостей в исходном коде
⦁ Fuzz тестирование
⦁ Тестирование на проникновение
⦁ Тестирование, основанное на рисках
⦁ Проведение нагрузочного тестирования

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

Smoke-тестирование

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

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

⦁ Выявление критичных ошибок в первые несколько часов (минут) после установки
⦁ Снижение рисков вывода некачественного продукта;
⦁ Минимизация рисков при интеграции систем;
⦁ Сокращение затрат на исправление дефектов;
⦁ Ускорение проверки за счет автоматизации.

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

Системное тестирование предназначено для тестирования

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

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

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

⦁ Определение подхода к составлению тестовых сценариев
⦁ Создание плана и методики испытаний
⦁ Подготовка тестовых данных
⦁ Проведение тестирования
⦁ Выявление некорректного использования ресурсов

⦁ Тестовый план
⦁ Разработка тестов
⦁ Подготовка тестовых данных
⦁ Тестовые прогоны – автоматизированные и обычные
⦁ Составление отчета
⦁ Регрессионое тестирование после исправления ошибок

Тестирование документации

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

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

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

Тестирование документации включает тестирование нескольких уровней документации:

⦁ Бизнес-требования
⦁ Функциональные требования
⦁ Техническое задание
⦁ Руководства пользователей

Обеспечение тестового покрытия

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

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

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

Тестирование установки

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

Тестирование установки позволяет избежать таких проблем при установке ПО в промышленную среду, как:
⦁ Невозможность установить ПО
⦁ Потеря данных после установки новой версии
⦁ Невозможность откатиться до предыдущей версии

В результате экономия денег и времени, существенное облегчение работы администраторов.
Основные задачи

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

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

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

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

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

В рамках данной задачи оценивается:

⦁ Сколько шагов нужно сделать для выполнения задачи?
⦁ Сколько времени требуется на выполнение задачи?
⦁ Сколько ошибок делает пользователь-новичок при выполнении задачи?
⦁ Какое впечатление осталось у пользователя от работы с программой?
⦁ Эмоции пользователя во время выполнения задачи.

Конфигурационное тестирование

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

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

Основные этапы конфигурационного тестирования

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

Функциональное тестирование

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

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

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

При функциональном тестировании различают следующие методы формирования тестовых наборов:

— эквивалентное разбиение;

— анализ граничных значений;

— анализ причинно-следственных связей;

— предположение об ошибке.

Эквивалентное разбиение. Метод эквивалентного разбиения заключается в следующем.

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

Разработку тестов методом эквивалентного разбиения осуществляют в два этапа: на первом выделяют классы эквивалентности, а на втором — формируют тесты.

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

— если некоторый параметр х может принимать значения в интервале , то выделяют один правильный класс 1 ≤ х ≤ 999 и два неправильных: х < 1 и х>999;

— если входное условие определяет диапазон значений порядкового типа, например, «в автомобиле могут ехать от одного до шести человек», то определяется один правильный класс эквивалентности и два неправильных: ни одного и более шести человек;

— если входное условие описывает множество входных значений и есть основания полагать, что каждое значение программист трактует особо, например, «типы графических файлов: bmp, jpeg, vsd», то определяют правильный класс эквивалентности для каждого значения и один неправильный класс, например, txt;

— если входное условие описывает ситуацию «должно быть», например, «первым символом идентификатора должна быть буква», то определяется один правильный класс эквивалентности (первый символ — буква) и один неправильный (первый символ — не буква);

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

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

Ограничение на значение параметра Правильные классы эквивалентности Неправильные классы эквивалентности

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

Анализ граничных значений.Граничные значения — это значения на границах классов эквивалентности входных значений или около них. Анализ показывает, что в этих местах резко увеличивается возможность обнаружения ошибок. Например, если в программе анализа вида треугольника было записано А+В≥С вместо А+В>С, то задание граничных значений приведет к ошибке: линия будет отнесена к одному из видов треугольника.

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

— если входное условие описывает область значений, то следует построить тесты для границ области и тесты с неправильными входными данными для ситуаций незначительного выхода за границы области, например, если описана область , то должны быть сгенерированы тесты: -1.0, + 1.0,-1.001 и+1.001;

— если входное условие удовлетворяет дискретному ряду значений, то следует построить тесты для минимального и максимального значений и тесты, содержащие значения большие и меньшие этих двух значений, например, если входной файл может содержать от 1 до 255 записей, то следует проверить О, 1, 255 и 256 записей;

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

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

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

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

Анализ причинно-следственных связей.Анализ причинно-следственных связей позволяет системно выбирать высокорезультативные тесты. Метод использует алгебру логики и оперирует понятиями «причина» и «следствие». Причиной в данном случае называют отдельное входное условие или класс эквивалентности. Следствием — выходное условие или преобразование системы. Идея метода заключается в отнесении всех следствий к причинам, т. е. в уточнении причинно-следственных связей. Данный метод дает полезный побочный эффект, позволяя обнаруживать неполноту и неоднозначность исходных спецификаций.

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

Далее на основе анализа семантического (смыслового) содержания спецификации строят таблицу истинности, в которой каждой возможной комбинации причин ставится в соответствие следствие. При этом целесообразно истину обозначать «I», ложь — «О», а для обозначения безразличных состояний условий применять обозначение «X», которое предполагает произвольное значение условия (0 или 1). Таблицу сопровождают примечаниями, задающими ограничения и описывающими комбинации причин и/или следствий.которые являются невозможными из-за синтаксических или внешних ограничений. При необходимости аналогично строится таблица истинности для класса эквивалентности.

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

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

Предположение об ошибке.Часто программист с большим опытом находит ошибки, «не применяя никаких методов». На самом деле он подсознательно использует метод «предположение об ошибке».

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

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

В основе программы лежит решение системы линейных уравнений:
Ах+By=С,

Dx+Еу=F.

По методу эквивалентных разбиений формируем для каждого коэффициента один правильный класс эквивалентности (коэффициент — вещественное число) и один неправильный (коэффициент — не вещественное число). Откуда генерируем 7 тестов:

1) все коэффициенты — вещественные числа (1 тест);

2-7) поочередно каждый из коэффициентов — не вещественное число (6 тестов).

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

8) результат — единственное решение
(δ ≠ 0)

9) результат — множество решений
(δ=0 и =0 =0);

10) результат — отсутствие решений
(δ=0но≠0);

и с результатами на границе:

11) δ=0.01

12) δ=-0.01

13) δ=0=0

14) δ=0=

По методу а н а л и з а п р и ч и н н о – с л е д с т в е н н ы х с в я з е й определяем множество условий:

а) для определения типа прямой:

а = 0

b = 0 — для определения типа и существования первой прямой;

с = 0

d = 0

e = 0 — для определения типа и существования второй прямой;

f = 0

б) для определения точки пересечения:

=δ=0

Выделяем три группы причинно-следственных связей (определение типа и существования первой линии, определение типа и существования второй линии, определение точки пересечения) и строим таблицы истинности для определения типа первой прямой (табл. 9.1) и для определения результата (табл. 9.2). В обеих таблицах X означает неопределенное значение. Для второй прямой таблица истинности будет выглядеть аналогично табл. 9.1.

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

Таблица 9.1

А = 0 B = 0 C = 0 Результат
X прямая общего положения
прямая, параллельная оси ОХ
ось ОХ
прямая, параллельная оси ОУ
ось ОУ
X множество точек плоскости

Таблица 9.2

δ=0 Единственное решение Множество решений Решения нет
X X
X
X

В результате к уже имеющимся тестам добавляются:

15-21) проверки всех случаев расположения обеих прямых — 6 тестов по первой прямой совмещают с 6-ю тестами по второй прямой так, чтобы варианты не совпадали (6 тестов); 22) проверка несовпадения условия = 0 или(в зависимости от того, какой тест был выбран по методу граничных условий) — тест также можно совместить с предыдущими 6-ю тестами.
По методу предположения об ошибке добавим тест:
23) все коэффициенты — нули.
Всего получили 23 теста по всем четырем методам. Для каждого теста перед применением необходимо указать ожидаемый результат. Если попробовать вложить независимые проверки, то, возможно, число тестов можно еще сократить.

Тестирование на этапе создания программного продукта

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

Для проведения функционального тестирования персоналом отдела технического контроля разрабатывается документ программа и методика испытаний функционала приложения (ПМИ). Документ ПМИ содержит перечень сценариев тестирования программного продукта (test cases) с подробным описанием шагов. Каждый шаг сценария тестирования характеризуется действиями пользователя (специалиста по тестированию) и ожидаемыми результатами – ответной реакции программы на эти действия. Программа и методика испытаний обязана имитировать эксплуатацию программного продукта в реальном режиме. Это означает, что сценарий тестирования должен быть построен на основе анализа операций, которые будут выполнять будущие пользователи системы, а не быть искусственно составленной последовательностью понятных только разработчику манипуляций. Функциональное тестирование может проводиться на различных уровнях тестирования, перечень которых зависит от сложности приложения:

  • Компонентное (модульное) тестирование. Тестирование отдельных компонентов программного продукта, сфокусированное на их специфике, назначении и функциональных особенностях.
  • Интеграционное тестирование. Данный вид тестирования проводится после компонентного тестирования и направлен на выявление дефектов взаимодействия различных подсистем на уровне потоков управления и обмена данными.

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


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

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

Нефункциональное тестирование

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

Тестирование производительности

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

Прочие виды нефункционального тестирования

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

Тестирование на этапе сопровождения программного продукта

Регрессионное тестирование

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

Предварительное тестирование новой версии программного продукта

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

Виды и структура процесса тестирования определяются сложностью самого объекта тестирования. То же самое с теми, кто тестирует программный продукт. Ими могут быть и сами программисты (предварительное тестирование), могут быть сотрудники отдела качества компании разработчика, а могут быть и привлеченные ресурсы. Например, если программа является серийным продуктом, то все ее основные испытания заканчиваются системным тестированием, а потом уже начинаются рекламные кампании и продажи. Если программный продукт – частный заказ, то после системного тестирования проводят еще и приемочное тестирование. И системное тестирование, и приемочное тестирование направлены на комплексное испытание системы (все виды предусмотренного для нее функционального и нефункционального тестирования), но проводятся на разных площадках и с участием разного персонала. Системное тестирование проводится на стороне разработчика, а приемочное на стороне заказчика и на его же аппаратном и системном программном обеспечении. Что касается процесса тестирования на этапе сопровождения, то он может длиться намного дольше, чем сам процесс создания программного решения и прерываться только выпуском абсолютно новой версии программного продукта, после чего все начинается заново…

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

Тем не менее, перед тем как автоматизировать тестирование любого приложения, необходимо сначала выполнить серию тестов вручную. Мануальное тестирование требует значительных усилий, но без него мы не сможем убедиться в том, возможна ли автоматизация в принципе. Один из фундаментальных принципов тестирования гласит: 100% автоматизация невозможна. Поэтому, ручное тестирование – необходимость.

Мифы о ручном тестировании:

– кто угодно может провести ручное тестирование

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

– автоматизированное тестирование мощнее ручного

Полная автоматизация невозможна. Необходимо использовать также и ручное тестирование.

– ручное тестирование – это просто

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

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

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

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

Существует несколько основных видов автоматизированного тестирования:

– автоматизация тестирования кода (Code-driven testing) – тестирование на уровне программных модулей, классов и библиотек (фактически, автоматические юнит-тесты);

– автоматизация тестирования графического пользовательского интерфейса (Graphical user interface testing) – специальная программа (фреймворк автоматизации тестирования) позволяет генерировать пользовательские события – нажатия клавиш, клики мышкой, и отслеживать реакцию программы на эти действия – соответствует ли она спецификации.

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

Для составления автоматизированных тестов, QA-специалист должен уметь программировать. Автоматические тесты – это полноценные программы, просто предназначенные для тестирования.

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

Сравнение ручного и автоматизированного тестирования

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

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

Вручную можно протестировать практически любое приложение, в то время как автоматизировать стоит только стабильные системы. Автоматизированное тестирование используется главным образом для регрессии. Кроме того, некоторые виды тестирования, например, ad-hoc или исследовательское тестирование могут быть выполнены только вручную.

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *