Открыть Электронные книги
Категории
Открыть Аудиокниги
Категории
Открыть Журналы
Категории
Открыть Документы
Категории
Очень упрощённо можно сказать, что при использовании v-образной модели на каждой
стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей
стадии «на подъёме». Тестирование здесь появляется уже на са-мых ранних стадиях
развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить
множество потенциальных проблем до того, как они станут проблемами реальными.
Автор модели Barry Boehm в своих публикациях31, 32 подробно раскрывает эти вопросы и
приводит множество рассуждений и рекомендаций о том, как применять спиральную
модель с максимальным эффектом.
Тем не менее можно утверждать, что всё больше и больше проектов начи- нают
использовать гибкую модель разработки.
Вкратце можно выразить суть моделей разработки ПО таблицей 2.1.a.
Таблица 2.1.a — Преимущества Недостатки Тестирование
Сравнение
моделей
разработки ПО
Модель
Водопадная
У каждой стадии Полная неспособ- С середины про-
есть чёткий прове- ность адаптировать екта.
ряемый результат. проект к измене-
В каждый момент ниям в требова-
времени команда ниях.
выполняет один вид Крайне позднее
работы. со- здание работаю-
Хорошо работает щего продукта.
для небольших за-
дач.
V-образная
У каждой стадии Недостаточная На переходах
есть чёткий прове- гиб- кость и между стадиями.
ряемый результат. адаптируе- мость.
Внимание тестиро- Отсутствует
ванию уделяется с раннее
первой же стадии. прототипирование.
Хорошо работает Сложность устра-
для проектов со нения проблем,
стабильными тре- пропущенных на
бованиями. ранних стадиях
развития проекта.
Итерационная
инкре-ментальная Достаточно Недостаточная В
раннее гиб-кость внутри определённые
прототипировани итера-ций. моменты
е. Сложность итераций.
Простота устра-нения Повторное
управле-ния проблем, тестиро-вание
итерациями. пропущенных на (после дора-
Декомпозиция ранних стадиях ботки) уже прове-
про-екта на развития ренного ранее.
управляе-мые проекта.
итерации.
Спиральная
Глубокий анализ рисков. Высокие накладные
Подходит для круп-ных расходы.
проектов. Сложность приме-нения
Достаточно раннее для неболь-ших проектов.
прототипирование. Высокая зависи-мость
успеха от ка-чества анализа
рисков.
Гибкая
Максимальное во- Сложность реали- В определённые
влечение заказ-чика. зации для больших моменты итераций и
Много работы с проектов. в любой необхо-
требованиями. Сложность постро- димый момент.
Тесная интеграция ения стабильных
тестирования и процессов.
разработки.
Минимизация доку-
ментации.
ID
В это поле записывается номер кейса или номер вместе с какой-то аббревиатурой к
примему «PD_Sync_123»служит для их уникальной идентификации среди других кейсов.
Summary
Здесь описывают шаги, для того чтобы воспроизвести баг. Степы рекомендуют
максимально сокращать, то есть найти кратчайший путь для воспроизведения бага и
описать в степах, и очень важно чтобы они оставались максимально понятными для
разработчиков.
Expected Result
В этом поле описываем ожидаемый результат после хождения по шагам или возможно
после конкретных шагов, что бывает реже.
Pass/Fail
Поле служит для проставления статуса каждому тест кейсу. Если ожидаемый результат
совпадает с реальным, то проставляем pass, в противном случае ставим fail. Возможно еще
несколько статусов в зависимости от процессов и правил в IT компании
Комплексное тестирование (Сборочное тестирование, integration testing или interface testing).
На данном уровне тестируются объединенные элементы (компоненты или подсистемы) общей
системы, чаще всего некоторая взаимодействующая между собой группа элементов.
Системное тестирование (system testing).После того, как система собрана из составляющих
компонентов, она должна быть протестирована на соответствие системным. На данном уровне
тестируется приложение или система (одно или более приложений) целиком.
Для каждого уровня тестирования могут использоваться различные виды тестирования, для
каждого из которых, в свою очередь, могут использоваться различные типы тестовых испытаний.
Дымовое тестирование (проверка на дым, Smoke testing). Первый прогон программы (после
написания или после внесения существенных изменений). Как правило, используется для
определения, готова ли программа для проведения более обширного тестирования. Основная
цель такого тестирования - выявление проблем «лежащих на поверхности» – тестируется чаще
всего основная бизнес логика программы.
Нагрузочное тестирование (Load testing). цель этого тестирования – оценить способность
системы правильно функционировать при некотором превышении планируемых нагрузок при
реальной эксплуатации (система имеет некоторый «запас прочности»).
По степени автоматизации:
o Ручное тестирование — тест-кейсы выполняет человек.
o Автоматизированное тестирование — тест-кейсы частично или полно-стью
выполняет специальное инструментальное средство.
Внешняя документация:
Внутренняя документация: