лекция_позиция_2_ПиТПМ. Лекция 2 Пит пм. Тестирование программного обеспечения цели и задачи тестирования по что такое тестирование Сэм Канер Тестирование это поиск ошибок
 Скачать 33.2 Kb.
|
|
Лекция 2_ПиТ ПМ. Тестирование программного обеспечения ЦЕЛИ И ЗАДАЧИ ТЕСТИРОВАНИЯ ПО ЧТО ТАКОЕ ТЕСТИРОВАНИЕ? • Сэм Канер - «Тестирование – это поиск ошибок». • Ли Копланд - «Тестирование – это сведение к минимуму риска пропуска ошибки». • Крупнейший институт инженеров IEEE утверждает, что «Тестирование – это проверка продукта на соответствие требованиям». • В некоторых источниках даже можно найти утверждения, что «Тестирование – это процесс, направленный на демонстрацию корректности продукта». • Тестирование программного обеспечения — процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта. 1. Целью тестирования является обнаружение ошибок в тестируемом объекте, а не доказательство их отсутствия. 2. Тестировщики не отвечают за качество. Они помогают тем, кто за него отвечает. 3. Тестирование даёт тем большую экономическую отдачу, чем на более ранних стадиях работы над проектом оно выявило дефект. 4. Тестирование имеет смысл прекращать тогда, когда устранены все критические и 85% и более некритических дефектов программы, т.к. дальнейшее тестирование, как правило, является неоправданной статьёй расходов. 4. Несколько определений: Дефект (баг, глюк; defect, bug) – любое несоответствие фактического и ожидаемого результата (согласно требованиям или здравому смыслу). Тест-кейс (test case) – набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства. Тест-план (test plan) – часть проектной документации, описывающая и регламентирующая процесс тестирования. Билд (build) – промежуточная версия программного средства (финальный бил часто называют релизом (release)). Основные виды ошибок: Логическая ошибка - наиболее серьезная из всех ошибок. Когда написанная программа на любом языке компилирует и работает правильно, но выдает неправильный вывод, недостаток заключается в логике основного программирования. Это ошибка, которая была унаследована от недостатка в базовом алгоритме. Синтаксические (в записи конструкций языка программирования) и семантические (связанные с неправильным содержанием действий и использованием недопустимых значений величин) ошибки устраняются на этапе компиляции. Ошибка компиляции исправляются на стадии разработки. Ошибки среды выполнения могут возникнуть в результате нехватки ресурсов носителя. можно исправить, вернувшись к стадии кодирования. Арифметическая ошибка - ведущая к бесконечному результату, логическая ошибка, которая может быть исправлена только путем изменения алгоритма. Ошибки ресурса - переполнение буфера, использование неинициализированной переменной, нарушение прав доступа и переполнение стека. Ошибка взаимодействия несоответствие программного обеспечения с аппаратным интерфейсом или интерфейсом прикладного программирования. В случае веб-приложений, ошибка интерфейса может быть результатом неправильного использования веб-протокола. ПРОЦЕСС ТЕСТИРОВАНИЯ План Тестирования Выбор стратегии Тест-план Анализ результатов Финальный отчет Анализ Документации Подробное описание тестов и оборудования Тест кейсы Выполнение тестов Поддержка, редактирование тестов Обнаружение и документирование ошибок Отчеты об ошибках Журналы испытаний План Тестирования (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. Тест дизайн (Test Design) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования. Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. Баг/Дефект Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата. Каждый тест определяет: - свой набор исходных данных и условий для запуска программы; - набор ожидаемых результатов работы программы. КАЧЕСТВО ПО Для того, чтобы понять, что продукт соответствует требованиям пользователя и/или заказчика, применяют верификацию и валидацию. Верификация отвечает на вопрос: «Соответствует ли продукт требованиям?», а валидация: «Можно ли использовать продукт для определенных целей?» Верификация – это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы. Валидация – это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. КЛАССИФИКАЦИЯ ТЕСТИРОВАНИЯ ПО Статическое тестирование (static testing) - это процесс анализа самой разработки программного обеспечения, иными словами – это тестирование без запуска программы (проверка кода, требований, функциональной спецификации, архитектуры, дизайна и т.д.) Примерами ошибок, которые потенциально можно выявить с помощью автоматического статического тестирования, могут быть: • утечки ресурсов (утечки памяти, не освобождаемые файловые дескрипторы и т.д.) • возможность переполнения буфера (buffer overflows) • ситуации частичной (неполной) обработки ошибок Динамическое тестирование (dynamic testing) — это тестовая деятельность, предусматривающая эксплуатацию (запуск) программного продукта. • Оно делится на несколько подтипов: тестирование белого ящика, тестирование черного ящика, а иногда выделяют и тестирование серого ящика. • Эта классификация уже относится к методам тестирования, т.е. как именно тестируют программу. Сравнение методов • Достоинство статических методов состоит в сравнительно небольшом количестве необходимых ресурсов. Однако их реализация может содержать непредсказуемый процент брака (нереализуемых путей). Кроме того, в этих системах переход от покрывающего множества путей к полной системе тестов пользователь должен осуществить вручную (трудоемко). • Динамические методы требуют значительно больших ресурсов как при разработке, так и при эксплуатации, однако увеличение затрат происходит, в основном, за счет разработки и эксплуатации аппарата определения реализуемости пути (символический интерпретатор, решатель неравенств). Достоинство этих методов заключается в том, что их продукция имеет некоторый качественный уровень - реализуемость путей. Методы реализуемых путей дают самый лучший результат. МЕТОДЫ ТЕСТИРОВАНИЯ Метод белого ящика (white-box testing, glass-box testing) – тестирование, при котором тестировщик имеет доступ к коду. Его еще называют тестированием стеклянного ящика или тестированием прозрачного ящика. Тесты основаны на знании кода приложения и его внутренних механизмов. Метод белого ящика часто используется на стадии, когда приложение ещё не собрано воедино, но необходимо проверить каждый из его компонентов, модулей, процедур и подпрограмм. Метод чёрного ящика (black-box testing) заключается в том, что тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь. Тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе на основе применения пользовательского интерфейса для ввода входных и получения выходных данных. Цель данного метода – проверить работу всех функций приложения на соответствие функциональным требованиям. Метод серого ящика (gray box testing) – совокупность подходов из методов белого и чёрного ящика. Этот метод, как правило, используется при тестировании веб-приложений, когда тестировщик знает принципы функционирования технологий, на которых построено приложение, но может не видеть кода самого приложения. Метод белого ящика • Модель программы в виде "белого ящика" предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. • Структурная информация понятна и доступна разработчикам подсистем и модулей приложения, поэтому данный вид тестирования часто используется на этапах модульного и интеграционного тестирования (Unit testing, Integration testing). • Структурные критерии тестирования базируются на основных элементах управляющего графа программы - операторах, ветвях и путях. Метод черного ящика Функциональное тестирование (functional testing) – процесс проверки программного обеспечения, сконцентрированный на анализе соответствия ПО требованиям и спецификациям. Функциональное тестирование ещё называют поведенческим или тестированием на поведенческом уровне. Цели функционального тестирования: Обнаружить дефекты в программном продукте. Определить степень соответствия программного продукта требованиям и ожиданиям заказчика. Принять решение о возможности передачи продукта заказчику. Для обнаружения всех ошибок в программе, используя управление по данным, необходимо выполнить исчерпывающее тестирование, т. е. тестирование на всех возможных наборах данных. Для тех же программ, где исполнение команды зависит от предшествующих ей событий, необходимо проверить и все возможные последовательности. Очевидно, что проведение исчерпывающего тестирования для подавляющего большинства случаев невозможно. Поэтому обычно выполняют «разумное» или «приемлемое» тестирование, которое ограничивается прогонами программы на небольшом подмножестве всех возможных входных данных. Этот вариант не дает гарантии отсутствия отклонений от спецификаций. Правильно выбранный тест должен уменьшать, причем более чем на единицу, число других тестов, которые должны быть разработаны для обеспечения требуемого качества программного обеспечения. При функциональном тестировании различают следующие методы формирования тестовых наборов: • эквивалентное разбиение; • анализ граничных значений; • анализ причинно-следственных связей; • предположение об ошибке Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок: 1) некорректных или отсутствующих функций; 2) ошибок интерфейса; 3) ошибок во внешних структурах данных или в доступе к внешней базе данных; 4) ошибок характеристик (необходимая емкость памяти и т. д.); 5) ошибок инициализации и завершения. ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ Тестирование производительности (performance testing) – проверяет способность программы выполнять заданное количество операций в заданный промежуток времени: • Нагрузочное тестирование (load testing) – проверяет способность приложения работать при запланированной нагрузке. • Стресс-тестирование (stress testing) – обычно используется для понимания пределов пропускной способности приложения. Этот тип тестирования проводится для определения надёжности системы во время экстремальных или диспропорциональных нагрузок и отвечает на вопросы о достаточной производительности системы в случае, если текущая нагрузка сильно превысит ожидаемый максимум. • Тестирование стабильности (stability/endurance/soak testing) –проводится с целью убедиться в том, что приложение выдерживает ожидаемую нагрузку в течение длительного времени. • Конфигурационное тестирование – ещё один из видов традиционного тестирования производительности. В этом случае вместо того, чтобы тестировать производительность системы с точки зрения подаваемой нагрузки, тестируется эффект влияния на производительность изменений в конфигурации. Конфигурационное тестирование может быть совмещено с нагрузочным, стресс или тестированием стабильности. Тестирование удобства использования (usability testing) – проверка того, насколько пользователю удобно и приятно работать с приложением. Юзабилити-тестирование охватывает пять аспектов тестирования, обучаемость, эффективность, удовлетворенность, запоминаемость, и ошибки. Тестирование безопасности (security 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) – в данном случае тестировщик пытается поставить себя на место пользователя или просто решает «Как можно сломать программу?». При таком тестировании план тестировщик держит в голове или делает для себя пометки. Психологические аспекты тестирования Хороший тестировщик должен обладать следующими психологическими качествами: • Повышенной ответственностью. • Хорошими коммуникативными навыками. • Способностью ясно, быстро, чётко выражать свои мысли. • Исполнительностью. • Терпением, усидчивостью, внимательностью к деталям, наблюдательностью. • Гибким мышлением, хорошей способностью к обучению. • Хорошим абстрактным и аналитическим мышлением. • Способностью ставить нестандартные эксперименты. • Высокими техническими навыками. • Склонностью к исследовательской деятельности. |