Введение в тестирование по содержание
 Скачать 3.94 Mb.
|
Спиральная модель предназначена для крупных, дорогостоящих и сложных проектов (с высокими проектными рисками)Спиральная модельПреимуществаЛучший способ разработки систем с большим количеством неизвестных величин Одна из наиболее гибких моделей: изменения могут быть внесены позже в жизненном цикле Управление рисками – одна из встроенных функций данной модели, что делает ее более привлекательной по сравнению с другими моделями НедостаткиСтоимость продукта неизвестнаЧересчур трудный подход для проектов с четкими техническими требованиями к продукту В силу особенностей самой модели, конструкция системы будет неизменно меняться.Гибкость имеет первостепенное значение для решений, касающихся тестовых сценариев, тестовых данных, инструментов тестирования и тестового окружения на ранних этапах проекта. К примеру, если руководитель тестирования зациклен на каком-то одном способе генерации тестовых данных, а структура системного хранилища данных радикально меняется, скажем, от реляционной базы данных к XML файлам, потребуется значительная переработка тестовых артефактов, инструментов и подходов.Специфичная, экспериментальная манера тестирования на ранних этапах проекта.Тестирование ранних прототипов сводится к поиску неизвестного и тщательному тестированию сомнительных конструкций с целью обнаружить что-то, что не работает.Повышение уверенности в качестве продукта не является целью, как правило. Такое раннее тестирование, которое переходит к выполнению более типичных функций на финальных этапах, требует от руководителя тестирования менять планы и стратегии по мере развития проекта. Опять же, гибкость здесь – ключевой фактор. В силу того, что в спиральной модели мы пытаемся решить проблемы с неизвестными величинами путем повторяющего прототипирования, составление графиков не поддается прогнозированию. Оценка и планирование тестирования весьма затруднительны, особенно при наличии других активных проектов.Независимо от используемой модели..Есть несколько характеристик хорошего тестирования:каждому этапу разработки соответствует этап тестирования; каждый уровень тестирования имеет тестовые цели, характерные для данного уровня; анализ и проектирование тестов для данного уровня тестирования должны начинаться во время соответствующего этапа разработки; тестировщики должны начинать рецензирование документов, как только их черновые варианты становятся доступны. В жизни …В реальной жизни … В реальных проектах … В реальных ситуациях … Модель в чистом виде используется редко Как правило используется адаптация модели под контурные нужны, что и было задумано, например для RUP, Agile и некоторых других моделей разработки Команда тестированияКоманда тестированияТип мышления, требуемый для тестирования и рецензирования, отличается от типа мышления, требуемого для разработки. С правильной установкой разработчики сами могут тестировать собственный код, однако ответственность за это передается тестировщику, как правило, для того чтобы сфокусироваться именно на тестировании и получить ряд дополнительных преимуществ, таких как независимый взгляд обученных и профессиональных тестировщиков. Независимое тестирование может быть выполнено на любом уровне тестирования.Независимость тестирования: Разделение ответственностей, которое позволяет выполнять объективное тестирование.Уровни независимостиНиже описываются несколько уровней независимости, в порядке от низкого к высокому:Разработчики тестируют собственный код (низкий уровень независимости) Независимые тестировщики (например, из команды разработчиков) Независимая команда или группа тестирования из другой организационной группы или независимые тестировщики (например, специалисты по тестиро- ванию удобства использования и производительности) Независимые тестировщики, привлеченные на аутсорсинг или сторонние по отношению к организации. Важность независимости тестирования 1/2Причина 1 – Редактировать и править собственный код – не самая лучшая идея. Свежий взгляд необходим, т.к. проверяя свою работу, вы руководствуетесь теми же предположениями, что и при написании, а, значит, серьезные дефекты останутся незамеченными. Например, программа может содержать ошибки, обусловленные непониманием программиста поставленной задачи или технического задания. В этом случае, непонимание программиста, скорее всего, отразится и в самой программе. |