Введение в тестирование ПО

тестировщика ПО

порядке

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

ошибок (“Искусство тестирования программ”, Г. Майерс, 1979)
Процесс наблюдения за выполнением

1980

1987

1999

2004

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

не единичное действие

жизненного цикла

динамическим
Статическое тестирование: Тестирование компонента или системы на уровне спецификации или

ним рабочие продукты

дефектов
Предотвращение дефектов

Тестирование помогает уменьшить общий уровень риска в системе после

с чем сравнивается?
Объект тестирования (что сравнивается)
Базис тестирования (с

тестирования: Документ, на основании которого определяются требования к компоненту или

тестирования, могут быть разными:
отдельный модуль
компонент (несколько модулей)
подсистема

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

привести компонент или систему к невозможности выполнить требуемую функцию, например

чего-то, что она должна делать согласно техническим требованиям.
Программа делает что-то,

ошибку в архитектуре или коде программы, то эта программа будет

Ошибка (Error)

Дефект
(Defect)

Отказ
(Failure)

к неправильному результату .

Отказ: Отклонение компонента или системы от ожидаемого

Number – размер шахматной доски (3…10)
Cell Side – размер

диапазон обозначенный в требований 3-10

их источником являются технические требования (спецификация).

обходится в 100 раз дороже, чем на стадии формирования требований

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

его исправление

подтверждение того, что определенные требования были выполнены

ожиданиям и потребностям пользователей

правильный продукт?»

индивидуума…»

мин.

напрямую связаны с тестированием программных продуктов:
обеспечение качества (QA)
контроль качества (QC)

Зачастую

кода
Статический анализ кода
Внешняя оценка и аудит
В обеспечение качества

реактивные действия

реактивные и проактивные действия

тестирование – это лишь один из информационных сервисов.




рабочий

информация

это возможный способ оценки качества программного обеспечения в терминах найденных

качества, но вы не создаете качество и не можете лишить

Проекты бывают легкие и типовые, но большинство напоминают заснеженную горную

может показать, что дефекты присутствуют, но не может доказать, что

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

дефекты как можно раньше, активности по тестированию должны быть начаты

дефектов, обнаруженных при тестировании или повлекших за собой основное количество

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

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

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

и исправление дефектов не помогут, если созданная система не подходит

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

данные, относящиеся к функционированию компьютерной системы.

датами начала и окончания, предпринимаемый для достижения цели в соответствии

разработки (программного продукта), принятый в проекте, зависит от целей и

времени, начинающийся с момента появления концепции программного обеспечения и заканчивающийся

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

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

любой момент проекта
Даже если всё заканчивается хорошо, не знать этого

запланированных (сметных) пределах
Управляемость
Возможность внесения корректив по ходу проекта (изменяющиеся требования

ПО зависит от выбранной модели разработки.

из первых разработанных моделей. Она предполагает строгое последовательное (во времени)

остаются неизменными на протяжении всего проекта.
Четкое планирование: каждый этап и

в проект людям легче включиться в работу
Простая для понимания и

заказчик меняет требования.
Подходит только для тех проектов, где требования

и сроками поставки
Поскольку тестирование начинается только в конце проекта, оно,

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

проект
Когда тестировщики подключаются к работе на стадии формирования требований, тестирование

в которых система реализуется и тестируется итерационно, блоками

Формирование требований, проектирование,

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

адаптации процесса на основе уроков, извлеченных из предыдущих итераций
Более короткие

регрессионного тестирования
Каждое расширение системы требует регрессионного тестирования всех функций и

плана для обнаружения и устранения дефектов
Проявляется это в том,

внимания и уважения к тестированию
Эта проблема не имеет всеобщего

прототипа к прототипу, каждый из которых тестируется, затем перепроектируется и

с систематикой и контролем водопадной модели:
Данная модель включает в себя

из наиболее гибких моделей: изменения могут быть внесены позже в

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

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

модели мы пытаемся решить проблемы с неизвестными величинами путем повторяющего

соответствует этап тестирования;
каждый уровень тестирования имеет тестовые цели, характерные для

реальных ситуациях …


Модель в чистом виде используется редко
Как правило используется

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

к высокому:
Разработчики тестируют собственный код (низкий уровень независимости)
Независимые

код – не самая лучшая идея. Свежий взгляд необходим, т.к.

ошибки в своей работе. Это распространяется и на разработчиков программных

услуги по тестированию различным «заказчикам»:
Руководитель проекта (PM):
Руководитель проекта обязан быть

дефектах в его работе, причем, делая это быстро.
О тестировщика

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

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

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

удовлетворение является приоритетной задачей проекта и, конечно же, тестировщика

Уровень тестирования связан с областями ответственности в проекте.
Примерами уровней

с базисом тестирования (при наличии)
Критерии входа и выхода
Артефакты процесса тестирования,

по уровням делается для комплексных систем (системы систем) – системное

известно, как модульное тестирование

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

код.

отдельности все части работают.
Объекты тестирования
Компоненты
Программы
Модули БД
Базис тестирования
Требования к компонентам
Детальный

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

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

обнаружение дефектов
Программисты обнаруживают и мгновенно исправляют проблемы. Упрощенная отладка
Лучшее структурное

тестирование основано, в первую очередь, на написанном коде. Поэтому, если

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

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

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

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

и закрыты
Все тестовые сценарии исполнены; для каждого сценария есть результаты

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

проверки того, что она соответствует установленным требованиям

тестирование является разновидностью тестирования методом черного ящика, а, следовательно, не

требованиям (функциональным/нефункциональным)
Объекты тестирования
Система в целом
Базис тестирования
 Функциональная спецификация (FRS)
Спецификация

системного тестирования готово.
Спецификации продукта закончены и утверждены.
Сценарии системного тестирования отражены

(pairwise)
Тестирование состояний и переходов
Тестирование по сценариям использования
Измерения и метрики
Покрытие требований

и в систему управления дефектами
Инструментарий
Тестовые компараторы
Инструменты захвата/воспроизведения
Инструменты тестирования защищенности
Инструменты

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

является главной целью
Пользовательское приемочное тестирование проверяет готовность системы для использования;

знания о структуре кода:
черный ящик / серый ящик /

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

помощью автоматизированных средств анализа (статистический анализ) без исполнения кода.
Объекты тестирования:

разработки
уменьшение времени разработки
уменьшение времени и стоимости тестирования
сокращение

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

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

тестирование методом черного и белого ящика.
Например, продукт тестируется методом черного

анализе внутренней структуры компонента или системы.

Синонимы:
тестирование на основе структуры
структурное тестирование
тестирование

пользовательского интерфейса
Нефункциональное тестирование
Тестирование производительности, нагрузочное тестирование, стрессовое тестирование
Тестирование

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

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

является проверка целостности данных после различных транзакций (ввод/выбор/обновление). Как правило,

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

продукта с целью удостовериться в том, что он отвечает спецификациям

к функциональности, то есть надежность, эффективность, практичность, сопровождаемость и переносимость.

продукта


Тестирование производительности: в инженерии программного обеспечения тестирование, которое проводится с целью определения,

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

на граничных значениях рабочих нагрузок или за их пределами, или

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

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

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

продукт работы большинства тестировщиков.
Хорошими отчетами тестировщик зарабатывает себе хорошую репутацию.

недостатке в компоненте или системе, который может привести компонент или

изменений, а также поддержку их состояний. Часто имеет процессно-ориентированные возможности

Тренинг "SQA-024 Основы управление дефектами"

к различным стадиям, которые дефект проходит в инструменте управления дефектами

тестировщика, сообщившего о нем, или руководителем тестирования.
Если при рецензировании дефект

о нем закрывается. Работы по нему заканчиваются.
Любой статус помимо

использован при его поиске и упоминании о нем.
Краткое описание. Краткое

Отчет о дефекте 1/6

которое будут обращать внимание руководитель проекта и прочие руководители, и

дата
Имя тестировщика
Аппаратные и программные конфигурации
Входные данные
Шаги процедуры
Ожидаемые результаты
Фактические результаты
Попытки

воздействия конкретного дефекта на систему.
Приоритет. В какой мере дефект в

данных, бреши в защите
Операционная ошибка, неверный результат, потеря функциональности
Небольшие проблемы,

явный дефект
Должен быть устранен до релиза
Устранить, когда будет время
Желательно устранить,

вычислениях: Неправильный расчет по формуле/ неправильная бизнес валидация в коде
Ошибка данных: Некорректная

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

ошибки интерфейса, некорректная обработка переданных параметров, неправильное расположение полей и

Неявные/явные требования были пропущены/не отражены в документах на стадии сбора

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

к памяти, системный сбой
Ошибка тестового плана/сценария: Неполноценные/неверные/нечеткие/дублирующие или пропущенные тестовые

дефекты устраняются. Некоторые не устраняются вовсе, исправление же некоторых откладывается

дефект. Может, вам доводилось слышать фразу: «Это не дефект, а

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

2+2=5, 3+3=6, 4+4=9, 5+5=10 и 6+6=13. Напишите отчет о дефекте,

5 мин на размышления
10 мин на разбор

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

точно знают, как она работает, какие именно неисправности имеют существенное

знают области наибольшей важности для бизнеса и как они влияют

требований, проектирование и программирование) дает понимание того, как появляются ошибки,

анализировать спецификации, участвовать в анализе рисков, разрабатывать тестовые сценарии, а

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

James Bach and Bret Pettichord
“Foundations of Software Testing” by Dorothy