Тестирование программного
обеспечения
Тестирование программы
• Тестирование предназначено для того, чтобы показать, что
программа делает то, для чего она предназначена, и
обнаружить программные дефекты до того, как она будет
введена в эксплуатацию.
• Когда вы тестируете программное обеспечение, вы запускаете
программу, используя искусственные данные.
• Вы проверяете результаты тестового прогона на наличие
ошибок, аномалий или информации о нефункциональных
атрибутах программы.
• Может выявить наличие ошибок, а НЕ их отсутствие.
• Тестирование является частью более общего процесса проверки
и проверки, который также включает методы статической
проверки
Цели тестирования программ
• Продемонстрировать разработчику и заказчику, что ПО
соответствует его требованиям.
– Для пользовательского программного обеспечения это означает,
что для каждого требования в документе с требованиями должен
быть как минимум один тест.
– Для универсальных программных продуктов это означает, что
должны быть проведены тесты для всех системных функций, а
также их комбинаций, которые будут включены в выпуск продукта.
• Выявление ситуаций, в которых поведение программного
обеспечения является неправильным, нежелательным или не
соответствует его спецификации.
– Тестирование дефектов связано с устранением нежелательного
поведения системы, такого как системные сбои, нежелательное
взаимодействие с другими системами, неправильные вычисления
и повреждение данных.
Валидация и тестирование дефектов
Первая цель ведет к валидационному тестированию
– Вы ожидаете, что система будет работать корректно, используя
заданный набор тестовых примеров, которые отражают
ожидаемое использование системы.
Вторая цель приводит к тестированию дефектов
– Тестовые примеры предназначены для выявления дефектов.
Тестовые примеры при тестировании на дефекты могут быть
намеренно неясными и не обязательно отражать то, как обычно
используется система.
Цели тестирования
Валидационное тестирование
• Продемонстрировать разработчику и заказчику системы, что
программное обеспечение соответствует их требованиям
• Успешное тестирование показывает, что система работает
должным образом.
Проверка дефектов
• Обнаруживать сбои или дефекты в программном обеспечении,
когда его поведение является неправильным или не соответствует
его спецификации
• Успешный тест - это тест, который заставляет систему работать
неправильно и, таким образом, выявляет дефект в системе.
Модель ввода-вывода программ
Verification vs validation
Verification :
"Правильно ли мы
создаем продукт”.
• Программное
обеспечение должно
соответствовать его
спецификации.
Validation : "Создаем
ли мы правильный
продукт”.
Программное
обеспечение должно
делать то, что
действительно
требуется
пользователю.
V & V уверенность
Цель V & V - создать уверенность в том, что система
"соответствует назначению’.
Зависит от назначения системы, ожиданий пользователей и
маркетинговой среды:
• Назначение программного обеспечения
Уровень доверия зависит от того, насколько важно
программное обеспечение для организации.
• Ожидания пользователей
Пользователи могут иметь низкие ожидания от определенных
видов программного обеспечения.
• Маркетинговая среда
Вывод продукта на рынок на ранней стадии может оказаться
более важным, чем обнаружение дефектов в программе.
Inspections and testing
• Software inspections(Проверка программного
обеспечения)
Связана с анализом статического представления
системы для выявления проблем (статическая
проверка). Может быть дополнен инструментальным
анализом документов и кода.
• Software testing (Тестирование программного
обеспечения)
• Связан с проверкой и наблюдением за поведением
продукта (динамическая проверка). Система
выполняется с использованием тестовых данных, и
наблюдается ее рабочее поведение.
Инспекции и испытания
Инспекции программного
обеспечения
• Они предполагают, что люди изучают исходное
представление с целью обнаружения аномалий и
дефектов.
• Проверки не требуют запуска системы, поэтому могут
быть использованы до внедрения.
• Они могут быть применены к любому представлению
системы (требования, дизайн, данные конфигурации,
тестовые данные и т.д.). Было показано, что они являются
эффективным методом обнаружения программных
ошибок.
Инспекции и испытания
• Инспекции и тестирование являются
взаимодополняющими, а не противоположными
методами проверки.
• И то, и другое следует использовать во время процесса V
& V.
• Инспекции могут проверять соответствие спецификации,
но не соответствие реальным требованиям заказчика.
• Проверки не могут проверять нефункциональные
характеристики, такие как производительность, удобство
использования и т.д.
Модель процесса тестирования
программного обеспечения
Этапы тестирования
• Тестирование разработки, при котором
система тестируется во время разработки для
выявления ошибок
• Тестирование выпуска, при котором отдельная
команда тестирования тестирует полную
версию системы перед ее выпуском для
пользователей.
• Пользовательское тестирование, при котором
пользователи или потенциальные
пользователи системы тестируют систему в
своей собственной среде
Development testing
Тестирование разработки
Тестирование разработки
Тестирование разработки включает в себя все действия по
тестированию, которые выполняются командой, разрабатывающей
систему.
1. Модульное тестирование(Unit testing), при котором тестируются
отдельные программные модули или классы объектов. Модульное
тестирование должно быть сосредоточено на тестировании
функциональности объектов или методов.
2. Тестирование компонентов (Component testing), при котором
несколько отдельных блоков интегрируются для создания составных
компонентов. Тестирование компонентов должно быть
сосредоточено на тестировании интерфейсов компонентов.
3. Системное тестирование(System testing), при котором некоторые
или все компоненты системы интегрируются и система тестируется в
целом. Тестирование системы должно быть сосредоточено на
тестировании взаимодействия компонентов
1. Unit testing (модульное
тестирование)
Unit testing
Любая программа состоит из юнитов, или модулей, — отдельных
блоков и функций. Кнопка добавления товара в корзину, формула
калькулятора стоимости, скрипт для формирования карточки товара
— всё это отдельные модули.
• Модули взаимодействуют и обеспечивают работу программы или
приложения. Чтобы проверить, правильно ли написан модуль,
проводят юнит-тесты, или модульное тестирование, — проверку не
всего приложения, а одного модуля. Пример юнит-теста — проверка
функции подсчёта общей стоимости заказа.
• Модульное тестирование проводят сразу после написания кода.
Проверить работу кнопки в готовом приложении не получится, потому
что на неё уже влияют другие модули.
• Если пропустить этап юнит-тестирования, в следующий раз не
получится понять, что именно вызвало ошибку: какой-то из модулей
или неправильно настроенная интеграция между ними. Придётся
разбираться, тратить время и всё равно тестировать отдельные
юниты.
• Интеграционные тесты —
тестирование
взаимодействия нескольких
юнитов. Например, кнопки
«Купить товар» и корзины.
• Сквозные (end-to-end)
тесты — тестирование
работы большого количества
юнитов вместе. Это может
быть как всё приложение,
так и конкретный сценарий,
например поиск товара, его
помещение в корзину, заказ
и оплата.
Достоинства Юнит тестов
● Можно провести сразу после написания кода.
Программист пишет конкретный модуль и тут же его
тестирует — не нужно ждать готовности других модулей
или интеграций.
● Быстрее, чем другие тесты, так как охватывают только
небольшую функцию.
● За счёт лёгкости и скорости юнит-тесты самые дешёвые.
● Разные юниты можно тестировать одновременно.
● Легко автоматизировать, так как при таких тестах нет
имитации сценария пользователя — только проверка
реакции кода на те или иные действия и данные.
● Просто посчитать, какой процент кода покрыт тестами.
Unit testing
• Unit testing is the process of testing individual
components in isolation.
• It is a defect testing process.
• Units may be:
– Individual functions or methods within an object
– Object classes with several attributes and
methods
– Composite components with defined interfaces
used to access their functionality.
Object class testing
Полное тестовое покрытие
класса включает в себя:
• Тестирование всех операций,
связанных с объектом
• Установка и опрос всех атрибутов
объекта
• Использование объекта во всех
возможных состояниях.
Наследование усложняет
разработку тестов класса
объектов, поскольку
информация, подлежащая
тестированию, не локализована.
Интерфейс объекта метеостанции
Automated testing
•
По возможности модульное тестирование должно быть
автоматизировано, чтобы тесты запускались и проверялись без
ручного вмешательства.
•
При автоматическом модульном тестировании вы используете
платформу автоматизации тестирования (например, JUnit) для
написания и запуска тестов вашей программы.
•
Фреймворки модульного тестирования предоставляют
универсальные тестовые классы, которые вы расширяете для
создания конкретных тестовых примеров.
• Затем они могут запустить все тесты, которые вы внедрили, и
сообщить, часто через какой-либо графический интерфейс, об
успешном выполнении любого из тестов.
Automated test components
• Часть настройки, где вы инициализируете
систему с помощью тестового примера, а
именно входных данных и ожидаемых
выходных данных.
• Часть вызова, в которой вы вызываете объект
или метод, подлежащий тестированию.
• Часть утверждения, в которой вы сравниваете
результат вызова с ожидаемым результатом.
Если утверждение имеет значение true, то тест
прошел успешно, если false, то он завершился
неудачей.
Выбор примеров модульного
тестирования
Тестовые примеры должны показывать, что при использовании
должным образом компонент, который вы тестируете, делает
то, что от него требуется.
Если в компоненте есть дефекты, они должны быть выявлены с
помощью тестовых примеров.
Это приводит к 2 типам модульных тестовых примеров:
• Первый из них должен отражать нормальную работу
программы и показывать, что компонент работает должным
образом.
• Другой тип тестового примера должен основываться на опыте
тестирования тех случаев, когда возникают общие проблемы.
Он должен использовать ненормальные входные данные,
чтобы проверить, что они правильно обработаны и не приводят
к сбою компонента.
Partition testing
• Входные данные и выходные результаты
часто попадают в разные классы, где все
члены класса связаны между собой.
• Каждый из этих классов является разделом
эквивалентности или доменом, в котором
программа ведет себя эквивалентным
образом для каждого члена класса.
• Тестовые примеры должны быть выбраны
из каждого раздела.
Equivalence partitions
Разделение эквивалентности
Пример тестирования ПОИСК
•
•
•
•
•
•
•
Что надо узнать
По каким полям поиск должен работать / по
каким нет
Ищет по включению или полному
соответствию?
Регистрозависимый ли поиск?
Какая максимальная длина поисковой строки?
А если длина превышена, запрос обрезается?
Как работает поиск при пустом запросе?
И т.д.
Что надо проверить
• Поиск ищет по всем полям, указанным в ТЗ (по названию, по
брендам, по артикулу и т.д.)
• Поиск НЕ ищет по тем полям, которые НЕ указаны в ТЗ
( зачем тестировать то, что поиск не работает по полям, по
которым не должен? Не должен же искать, зачем проверять? )
• Учитывается ли контекст поиска — ищу я по всему сайту или
только разделу
• Регистронезависимость поиска — найдет ли «Samsung», если я
ввела «samsung»?
• Найдет ли 2 слова из разных полей?
• Ошибка в вводе (исправляются ли опечатки, ищет ли похожее)
• Пустое поле / только пробелы в поле