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

Заключение

Хорошая среда разработки программного обеспечения предполагает адекватное кадровое обеспечение и соответствующее время на такую деятельность, как тестирование программного обеспечения, а также руководство персоналом, который им занимается. Однако условия работы некоторых тестеров никак нельзя назвать идеальными — зачастую необходимо изучить и протестировать новое приложение в нереальные сроки. Некоторые организации решают выпустить продукт к определенной дате и хотят, чтобы тестеры подтвердили пригодность продукта к использованию.
Успешное тестирование, — как и качество программного обеспечения, — зависит от многих других дисциплин разработки ПО, включая:
• конфигурационный менеджмент, чтобы иметь возможность следить, какая версия приложения в данный момент тестируется;
• соста ...

Оглавление
Введение 2
1. Тестирование в процессе разработки ПО 3
2. Организация управления тестированием и выявление основных проблем 16
Заключение 22
Список используемой литературы: 23

Введение

Важной составляющей качества программного обеспечения является процесс тестирования и проверки корректности его работы. Существующие на сегодняшний день методы тестирования программного обеспечения (ПО) не позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы, поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО. Задача тестирования и верификации программных систем занимают центральное положение в исследованиях по математической теории программирования. Это обусловлено, в первую очередь, высокой актуальностью создания теоретического фундамента для разработки надѐжного программного обеспечения. Современный этап развития индустрии программн ых систем характеризуется значительным усложнением процесса их разработки.
Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.
Управление тестированием представляет собой мероприятия по организации и управлению процессом и артефактами, необходимыми для проведения тестирования.
В технологиях производства программных продуктов тестированию отводится роль основного средства обеспечения и контроля качества продукта. Это проявляется в том, что процессы тестирования все глубже интегрируются в проектные методы, а управление тестированием становится важнейшей составляющей управления проектами.

По этой причине имеет смысл построить соответствующую модель жизненного цикла процесса тестирования. Пример каскадной модели жизненного цикла процесса тестирования приводится на рисунке 5. Отметим, что данная модель описывает динамическое тестирование, однако в ней не отражено статическое тестирование.Далее дано краткое описание действий, входов и выходов для каждой стадии каскадного процесса тестирования. Анализ требований На этапе анализа требований цели, которые преследует группа специалистов по тестированию и коллектив разработчиков, различаются в ряде аспектов. Обоим коллективам нужны четкие, недвусмысленные спецификации требований, которые служат входными данными для их работы. Разработчики желают получить полный набор требований, которыми можно воспользоваться для формулирования функциональных требований к системе и которые позволили бы проводить работы по проектированию и кодированию программного продукта. С другой стороны, тестовой группе нужен набор требований, который позволил бы им составить план проведения испытаний и выполнить системные и приемочные испытания.Очень полезным выходным документом стадии анализа требований, как для разработчиков, так и для тестовой группы, является матрица прослеживаемости требований. Матрица прослеживаемости требований (requirements traceability matrix) представляет собой документ, который отображает каждое требование на промежуточные результаты процесса разработки, такие как компоненты проекта, модули программного обеспечения и результаты тестирования. Она может быть представлена в виде электронной таблицы, таблицы текстового процессора, базы данных или Web-страницы.Планирование испытаний Под планированием испытаний понимается определение объемов испытаний, подходов, ресурсов и расписания выполнения намеченных действий. Для того чтобы тестирование было эффективным, необходимо потратить значительные средства и усилия па планирование, а также быть готовым пересматривать этот план в динамике, соответственно изменениям в требованиях, расчетах или программных кодах по мере выявления дефектов. Определение критериев входа и выхода для каждой стадии процесса тестированияОтображение тестов на требованияОпределение того, что подлежит тестированию, и подхода, который при этом будет использоватьсяПланирование основных этапов работОценка времени, необходимого для выполнения работ по тестированиюОценка персонала, необходимого для выполнения тестовых работ, по квалификации и степени занятостиОпределение тестовой системы (аппаратных и программных средств), необходимой для проведения тестированияОценка рисков, связанных с тестированием, и план по их уменьшениюРисунок 6 - Подготовительные этапы для этапов системных и приемочных испытаний, выполняемые на стадии планирования испытанийОчень важно, чтобы все требования подверглись тестированию, либо же, если требования выстроены по некоторой системе приоритетов, по крайней мере, должны быть проверены требования с максимальными приоритетами. Матрица прослеживаемости требований является полезным инструментальным средством на стадии планирования испытаний, поскольку она может использоваться при расчете объемов тестирования, необходимого для охвата важнейших требований. Промежуточные результаты или выходы, являющиеся результатами этих действий, могут быть включены в план проведения испытаний, который, как правило, состоит из одного или большего числа документов. Проектирование тестов, реализации и отладка Динамическое тестирование основано на выполнении заданного набора операций на конкретном модуле программного продукта и сравнении фактически полученных результатов с ожидаемыми. Если после прогона получен ожидаемый результат, считается, что модуль прошел тест. Если зафиксировано аномальное поведение, тест считается неудачным, однако он может оказаться успешным в смысле обнаружения дефекта. Заданный набор выполняемых операций образует тестовый случай. Следует подчеркнуть, что тестовые случаи должны быть спроектированы, закодированы и отлажены до того, как их можно будет использовать. Проектирование тестов состоит из двух компонентов: архитектуры тестов и подробных планов тестов. Архитектура тестов упорядочивает тесты по группам, таким как функциональные тесты, испытания для определения рабочих характеристик, проверка безопасности и т.д. Она также описывает структуру и соглашения по именованию хранилища тестов. Подробные планы тестов описывают назначение каждого теста, технические средства и данные, необходимые для выполнения теста, ожидаемые результаты каждого теста, а также указывают на требование, на подтверждение выполнения которого ориентируется данных тест. Между требованиями и планами тестов должно существовать, по меньшей мере, отношение один к одному. На основе планов тестов могут быть разработаны подробные методики проверки. Уровень детализации, необходимый для представления методики проверки в виде письменного документа, зависит от квалификации и уровня знаний персонала, выполняющего прогон тестов. Следует найти компромисс между временем, необходимым для написания подробной, последовательной методики, и временем, которое заинтересованное лицо тратит на обучение правильному выполнению тестов. Даже если тест должен быть автоматизирован, в общем случае затраты времени на заблаговременное подробное описание методики проверки оправдываются, поскольку перед специалистом по автоматизации ставится четкая и однозначная задача автоматизации теста. Как только методика тестирования будет описана, ее потребуется проверить на каком-либо модуле программного продукта. Поскольку, скорее всего, этот тест будет проверяться на "изобилующей ошибками" программе, особо внимательно следует анализировать случаи, когда тест не проходит, что позволит определить, где находится причина неудачи — в тестируемом коде или в самом тесте. Системное тестирование Набор завершенных, отлаженных тестов может использоваться и на следующей стадии каскадного процесса тестирования, т.е. на этапе системных испытаний. Системное тестирование проводится для удостоверения того, что программное обеспечение делает именно то, что от него ожидает пользователь. Существуют два основных типа системных испытаний: функциональная проверка и испытания для определения рабочих характеристик. Функциональная проверка (functional testing) не требует от тестировщика знаний принципов работы программного продукта, в то же время она требует знаний функциональных требований, предъявляемых к системе. Она использует набор тестов, которые определяют, выполняет ли система все то, что она должна делать с точки зрения пользователя. После того, как тестирование подтвердило адекватность базовой функциональности системы, задачей тестирования становится проверка, насколько хорошо система выполняет свои функции. В рамках испытаний для определения рабочих характеристик (performance testing) выполняются такие проверки, как тестирование в предельных режимах, нагрузочные испытания, контроль синхронизации и проверка восстанавливаемости. Испытания на надежность, на эксплуатационную готовность, проверка приспособленности к техническому обслуживанию также можно включить в число испытаний для определения рабочих характеристик. Помимо функциональной проверки и испытаний для определения рабочих характеристик, возможны различные дополнительные проверки, проведение которых может понадобиться на стадии системных испытаний. В их число могут входить проверка безопасности, установочная проверка, проверка на совместимость, проверка удобства и простоты использования, проверка возможностей наращивания. Приемочные испытания По завершении системного тестирования продукт может быть передан пользователю для проведения приемочных испытаний. Если пользователи принадлежат той же компании, что и разработчики, такое тестирование обычно называется альфа-тестированием (alpha testing). Если пользователями являются заказчики, готовые работать с программным продуктом еще до его официальной готовности, то такое тестирование называется бета-тестированием (beta testing). И альфа-, и бета-тестирование представляют собой соответствующие формы контрольных испытаний (pilot tests), в условиях которых система устанавливается на экспериментальной базе с целью выявления дефектов. Другой формой приемочных испытаний являются аттестационные испытания (benchmark test), когда заказчик выполняет заранее определенный набор тестовых случаев, имитирующих типовые условия, в которых система будет работать после ввода в эксплуатацию. Для аттестационных испытаний могут быть использованы тестовые случаи, которые разработаны и отлажены вашей тестирующей организацией и которые в то же время были проверены и одобрены заказчиком. По завершении контрольных и аттестационных испытаний заказчик должен уведомить вас, какие требования не удовлетворены, а какие должны быть изменены, чтобы можно было перейти к заключительным испытаниям. Заключительным типом приемочных испытаний является установочная проверка (installation test), по условиям которой завершенная версия программного продукта устанавливается на площадках заказчика с целью получить от него подтверждение, что программный продукт соответствует всем требованиям и заказчик согласен на его поставку. Сопровождение Сопровождение программного продукта часто ставит разработчиков и тестировщиков перед необходимостью решения определенных задач. Сопровождения для разработчика — это исправление дефектов, которые были обнаружены заказчиком во время эксплуатации программного продукта, а также расширение функциональных возможностей продукта, которое призвано удовлетворить возросшие требования заказчика. Что касается организации тестирования, то сопровождение означает проверку результатов исправления дефектов, тестирование расширенных функциональных возможностей и выполнение регрессионных тестов (regression tests) на новых версиях программного продукта. Цель всего этого заключается в получении подтверждения того, что ранее исправно работавшие функциональные средства не пострадали от внесения изменений в программный продукт. Организация управления тестированием и выявление основных проблемОсновная проблема состоит в разработке тестов, позволяющих судить о качестве программы. Требования качества отражены в стандарте качества, наиболее важные из них:- Корректность, т.е. соответствие системы предназначению;- Безопасность, отсутствие неавторизованной утечки информации;-Устойчивость системы в случае непредусмотренного поведения окружения и при работе с неправильными входными данными;- Эффективность использования ресурсов времени и памяти;- Оптимальность реализованных в системе алгоритмов.Как правило, анализ соответствия предъявленным требованиям проводится либо путем визуального анализа, либо методом тестирования. Если какое-либо из свойств системы может быть выражено формально, например, в виде математической формулы, то анализ этого свойства может быть проведѐн методами верификации. Тестирование программы заключается в анализе результатов на некоторых выборочных данных. Тестирование является в настоящее время основной формой контроля качества программ, и занимает большую часть разработки самой программы.