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

МДК.01.02 ПОДДЕРЖКА И ТЕСТИРОВАНИЕ ПРОГРАММНЫХ МОДУЛЕЙ

Тема 1.

ЦЕЛИ И ЗАДАЧИ ТЕСТИРОВАНИЯ ПО

Несколько определений

Дефект (баг, глюк; defect, bug) – любое несоответствие фактического и ожидаемого результата (согласно требованиям или здравому смыслу).

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

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

Билд (build) – промежуточная версия программного средства (финальный бил часто называют релизом (release)).

Жизненный цикл ПО

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

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

Жизненный цикл ПО: затраты

Аналитики отмечают, что распределение затрат по стадиям жизненного цикла ПО примерно таково:

• Анализ требований 3%
• Спецификация 3%
• Проектирование 5%
• Кодирование 7%
• Тестирование 15%
• Промышленное производство и сопровождение 67%

Продукты, подвергаемые тестированию

Тестировать можно (и нужно!):

• Программы при их непосредственном запуске и исполнении (software).
• Код программ без запуска и исполнения (code).
• Прототип программного продукта (product prototype).
• Проектную документацию (project documentation):

• Требования к программному продукту (product requirements). Функциональные спецификации к программному продукту (functional specifications). Архитектуру (architecture) и дизайн (design). План проекта (project plan) и тестовый план (test plan). Тестовые случаи сценарии (test cases, ).
• Требования к программному продукту (product requirements).
• Функциональные спецификации к программному продукту (functional specifications).
• Архитектуру (architecture) и дизайн (design).
• План проекта (project plan) и тестовый план (test plan).
• Тестовые случаи сценарии (test cases, ).
• Сопроводительную документацию (и документацию для пользователей): Интерактивную помощь (on-line help). Руководства по установке (Installation guide) и использованию программного продукта (user manual).
• Интерактивную помощь (on-line help).
• Руководства по установке (Installation guide) и использованию программного продукта (user manual).

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

ЧТО ТАКОЕ ТЕСТИРОВАНИЕ?

• Сэм Канер - «Тестирование – это поиск ошибок».
• Ли Копланд - «Тестирование – это сведение к минимуму риска пропуска ошибки».
• Крупнейший институт инженеров IEEE утверждает, что «Тестирование – это проверка продукта на соответствие требованиям».
• В некоторых источниках даже можно найти утверждения, что «Тестирование – это процесс, направленный на демонстрацию корректности продукта».

ЧТО ТАКОЕ ТЕСТИРОВАНИЕ?

Цель тестирования – помочь сделать качественный продукт и в намеченные сроки.

Исходя из цели, можно сказать, что Тестирование По – это процесс определения качества программного продукта.

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

ПРОЦЕСС ТЕСТИРОВАНИЯ

Test Design

• Анализ Документации
• Подробное описание тестов и оборудования

Тест кейсы

• План Тестирования
• Выбор стратегии

Тест-план

Test Planning

Test Execution

• Выполнение тестов
• Поддержка, редактирование тестов
• Обнаружение и документирование ошибок

Отчеты об ошибках

Журналы испытаний

• Анализ результатов

Финальный отчет

Analysis & Reporting

КАЧЕСТВО ПО

Качественный – значит соответствующий ожиданиям того, кому этот продукт предназначается.

Для этого нужны требования к продукту.

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

КАЧЕСТВО ПО

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

Некоторые рассуждения о качестве:

• Если заказчик доволен продуктом – продукт качественный.
• Если продукт соответствует требованиям – продукт качественный.
• У качественного продукта всегда есть какие-то преимущества и нет серьёзных недостатков.

КАЧЕСТВО ПО

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

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

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

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

ХАРАКТЕРИСТИКИ КАЧЕСТВА ПО

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

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

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

ХАРАКТЕРИСТИКИ КАЧЕСТВА ПО

• Эффективность – это отношение уровня услуг, предоставляемых ПП к объему используемых вычислительных ресурсов. Объем используемых вычислительных ресурсов количественно определяется затратами машинного времени и оперативной памяти на выполнение заданных функций.
• Сопровождаемость – это такие характеристики ПП, которые позволяют минимизировать усилия по внесению изменений при обнаружении ошибок в ПП и при его модификации. Не последнюю роль в повышении сопровождаемости играют комментарии к тексту программы!
• Мобильность – это способность ПП быть перенесенным из одной вычислительной среды (окружения) в другую, в частности, с одной ЭВМ на другую (применяют термин “перенос с одной платформы на другую”).

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

КРИТЕРИИ КАЧЕСТВА

Ниже приведены лишь некоторые примеры того, как могут формулироваться критерии качества.

• Покрытие требований тестами – не менее 80%.

• Закрыто 100% известных критических дефектов, 90% дефектов средней критичности, 50% остальных дефектов.

• Общий показатель прохождения тестов – не менее некоторого значения: X = (Passed/Executed)*100%

КРИТЕРИИ КАЧЕСТВА

Боб Мартин на конференции “Agile 2008” предложил прекрасную метрику качества кода: “What the f… / per minute”. Для проведения исследования нужен лишь секундомер, эксперт и калькулятор.

КЛАССИФИКАЦИЯ ТЕСТИРОВАНИЯ ПО

Статическое тестирование (static testing) - это процесс анализа самой разработки программного обеспечения, иными словами – это тестирование без запуска программы (проверка кода, требований, функциональной спецификации, архитектуры, дизайна и т.д.)

Динамическое тестирование (dynamic testing) - это тестовая деятельность, предусматривающая эксплуатацию (запуск) программного продукта.

• Оно делится на несколько подтипов: тестирование белого ящика, тестирование черного ящика, а иногда выделяют и тестирование серого ящика.
• Эта классификация уже относится к методам тестирования , т.е. как именн о тестируют программу.

МЕТОДЫ ТЕСТИРОВАНИЯ

Метод белого ящика (white-box testing, glass-box testing) – тестирование, при котором тестировщик имеет доступ к коду . Его еще называют тестированием стеклянного ящика или тестированием прозрачного ящика ..

Тесты основаны на знании кода приложения и его внутренних механизмов.

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

МЕТОДЫ ТЕСТИРОВАНИЯ

Метод чёрного ящика (black-box testing) заключается в том, что тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь.

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

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

Как вы думаете, каковы основные преимущества метода белого ящика? А чёрного ящика?

МЕТОДЫ ТЕСТИРОВАНИЯ

Метод серого ящика (gray box testing) – совокупность подходов из методов белого и чёрного ящика.

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

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ

• Функциональное тестирование
• Тестирование производительности

• Нагрузочное тестирование Стресс-тестирование Тестирование стабильности
• Нагрузочное тестирование
• Стресс-тестирование
• Тестирование стабильности
• Конфигурационное тестирование
• Юзабилити-тестирование
• Тестирование безопасности
• Тестирование локализации
• Тестирование совместимости
• Конфигурационное тестирование
• Инсталляционное тестирование
• Тестирование документации

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ

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

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

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

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ

Тестирование производительности (performance testing) – проверяет способность программы выполнять заданное количество операций в заданный промежуток времени:

• Нагрузочное тестирование (load testing) – проверяет способность приложения работать при запланированной нагрузке.
• Стресс-тестирование (stress testing) – обычно используется для понимания пределов пропускной способности приложения. Этот тип тестирования проводится для определения надёжности системы во время экстремальных или диспропорциональных нагрузок и отвечает на вопросы о достаточной производительности системы в случае, если текущая нагрузка сильно превысит ожидаемый максимум.
• Тестирование стабильности (stability/endurance/soak testing) –проводится с целью убедиться в том, что приложение выдерживает ожидаемую нагрузку в течение длительного времени.
• Конфигурационное тестирование – ещё один из видов традиционного тестирования производительности. В этом случае вместо того, чтобы тестировать производительность системы с точки зрения подаваемой нагрузки, тестируется эффект влияния на производительность изменений в конфигурации. Конфигурационное тестирование может быть совмещено с нагрузочным, стресс или тестированием стабильности.

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ

Тестирование удобства использования (usability testing) – проверка того, насколько пользователю удобно и приятно работать с приложением.

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ

Тестирование безопасности (security testing)

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

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

• Первичное тестирование безопасности.
• Полное тестирование приложения.
• Полное тестирование приложения и сервера.

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ

Тестирование интернационализации (internationalisation testing) – проверка готовности продукта к переводу на различные языки.

Тестирование локализации (localisation testing) – проверка качества перевода продукта на конкретный язык.

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ

Тестирование совместимости (compatibility testing) – проверка того, как приложение взаимодействует с другими приложениями и операционной системой. В случае веб-ориентированных приложений особое внимание уделяется совместимости с различными браузерами.

Инсталляционное тестирование (installation testing) – проверка всего того, что связано с инсталляцией продукта в систему и удалением продукта из системы.

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

ПО СТЕПЕНИ АВТОМАТИЗАЦИИ:

• Ручное тестирование (manual testing) – тестирование без применения различных средств автоматизации.
• Автоматизированное тестирование (automated testing) – тестирование с применением различных средств автоматизации.

ПО СТЕПЕНИ ИЗОЛИРОВАННОСТИ КОМПОНЕНТОВ:

Компонентное (модульное) тестирование (component/unit testing) – тестирование отдельного модуля программного средства (под модулем может пониматься в т.ч. отдельный класс, метод и т.д.)

Интеграционное тестирование (integration testing) – проверка того, как отдельные компоненты, проверенные на предыдущем уровне, взаимодействуют друг с другом.

Системное тестирование (system/end-to-end testing) – полная проверка приложения: проверяются как функциональные, так и нефункциональные требования.

ПО ВРЕМЕНИ ПРОВЕДЕНИЯ ТЕСТИРОВАНИЯ:

Альфа-тестирование (alpha testing) – имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком.

Тестирование при приёмке (smoke testing)

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

Регрессионное тестирование (regression testing) - проверка того, что внесённые в приложение изменения не привели к потере работоспособности того, что ранее работало, и/или привели к работоспособности того, что ранее не работало.

Тестирование при сдаче (acceptance testing)

Бета-тестирование (beta testing) – интенсивное использование почти готовой версии продукта (как правило, программного или аппаратного обеспечения) с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (Релизом) продукта на рынок, к массовому потребителю. Кроме того, открытие бета-тестирования может использоваться как стратегия: продвижение продукта на рынок, т.к. реклама, а также получение предварительных отзывов.

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

ПО ПРИЗНАКУ ПОЗИТИВНОСТИ СЦЕНАРИЕВ:

• Позитивное тестирование (positive testing) – проверка того, как приложение работает в заведомо “тепличных условиях” (корректные данные, условия работы и т.п.)
• Негативное тестирование (negative testing) – проверка того, как приложение реагирует на различные “неприятности” (пропала сеть, повреждён файл, введены некорректные данные и т.п.)

Ожидаемый результат (expected result) – такое поведение программного средства, которое мы ожидаем в ответ на наши действия.

ПО СТЕПЕНИ ПОДГОТОВЛЕННОСТИ К ТЕСТИРОВАНИЮ:

• Тестирование по документации (formal testing) – тестирование по заданному плану, по разработанным чек-листам и тест-кейсам.
• Тестирование ad hoc или интуитивное тестирование (ad hoc testing) – в данном случае тестировщик пытается поставить себя на место пользователя или просто решает «Как можно сломать программу?». При таком тестировании план тестировщик держит в голове или делает для себя пометки.

ВЫВОДЫ

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

2. Наша основная задача – проверять корректность работы программ и сообщать руководителю проекта "что работает, а что – нет".