- •Организация процесса тестирования программного обеспечения: спиральное представление процесса тестирования
- •Организация процесса тестирования программного обеспечения: характеристика шагов процесса тестирования.
- •Организация процесса тестирования программного обеспечения: критерии принятие решения об окончании тестирования.
- •Организация процесса тестирования программного обеспечения: тестирование элементов.
- •Организация процесса тестирования программного обеспечения: тестирование элементов/ тестирование путей.
- •Организация процесса тестирования программного обеспечения: тестирование элементов.
- •Организация процесса тестирования программного обеспечения: тестирование элементов.
- •Организация процесса тестирования программного обеспечения: тестирование интеграции.
- •Организация процесса тестирования программного обеспечения: нисходящее тестирование интеграции.
- •Организация процесса тестирования программного обеспечения: нисходящее тестирование интеграции.
- •Организация процесса тестирования программного обеспечения: восходящее тестирование интеграции.
- •Организация процесса тестирования программного обеспечения: сравнение восходящего и нисходящего тестирования интеграции.
- •Организация процесса тестирования программного обеспечения: сравнение восходящего и нисходящего тестирования интеграции.
- •Организация процесса тестирования программного обеспечения: тестирование правильности.
- •Организация процесса тестирования программного обеспечения: конфигурация ПО.
- •Организация процесса тестирования программного обеспечения:
- •Организация процесса тестирования программного обеспечения: отладка
- •Пример цикла тестирования ПО:
- •Артефакты тестирования:
- •Стандарты, регулирующие качество ПО:
- •Обеспечение качества ПО:
- •Обеспечение качества ПО:
- •Верификация и валидация ПО (V&V):
- •Стандарты, регулирующие проведение и планирование V&V
- •Верификация и валидация ПО (V&V):
Организация процесса тестирования программного обеспечения: восходящее тестирование интеграции.
Сборка и тестирование системы начинаются с модулей-атомов, располагаемых на нижних уровнях иерархии. Модули подключаются движением снизу вверх. Подчиненные модули всегда доступны, и нет необходимости в заглушках.
Шаги методики восходящей интеграции:
1.Модули нижнего уровня объединяются в кластеры (группы, блоки), выполняющие определенную программную подфункцию.
2.Для координации вводов-выводов тестового варианта пишется драйвер, управляющий тестированием кластеров.
3.Тестируется кластер.
4.Драйверы удаляются, а кластеры объединяются в структуру движением вверх.
Организация процесса тестирования программного обеспечения: сравнение восходящего и нисходящего тестирования интеграции.
Нисходящее тестирование:
1)основной недостаток— необходимость заглушек и связанные с ними трудности тестирования;
2)основное достоинство — возможность раннего тестирования главных управляющих функций.
Восходящее тестирование:
1)основной недостаток — система не существует как объект до тех пор, пока не будет добавлен последний модуль;
2)основное достоинство — упрощается разработка тестовых вариантов, отсутствуют заглушки.
Возможен комбинированный подход. В нем для верхних уровней иерархии применяют нисходящую стратегию, а для нижних уровней — восходящую стратегию тестирования
Организация процесса тестирования программного обеспечения: сравнение восходящего и нисходящего тестирования интеграции.
При проведении тестирования интеграции очень важно выявить критические модули. Признаки критического модуля:
1)реализует несколько требований к программной системе;
2)имеет высокий уровень управления (находится достаточно высоко в программной структуре);
3)имеет высокую сложность или склонность к ошибкам (как индикатор может использоваться цикломатическая сложность — ее верхний разумный предел составляет 10);
4)имеет определенные требования к производительности обработки.
Критические модули должны тестироваться как можно раньше. Кроме того, к ним должно применяться регрессионное тестирование (повторение уже выполненных тестов в полном или частичном объеме).
Организация процесса тестирования программного обеспечения: тестирование правильности.
Последний шаг программного тестирования — тестирование правильности.
Цель — подтвердить, что функции, описанные в спецификации требований к ПС, соответствуют ожиданиям заказчика.
Подтверждение правильности ПС выполняется с помощью тестов «черного ящика», демонстрирующих соответствие требованиям. При обнаружении отклонений от спецификации
Важным элементом подтверждения правильности является проверка конфигурации ПС. Конфигурацией ПС называют совокупность всех элементов информации, вырабатываемых в процессе конструирования ПС. требований создается список недостатков.
Организация процесса тестирования программного обеспечения: конфигурация ПО.
Минимальная конфигурация ПС включает следующие базовые элементы:
1)системную спецификация;
2)план программного проекта;
3)спецификацию требований к ПС; работающий или бумажный макет;
4)предварительное руководство пользователя;
5)спецификация проектирования;
6)листинги исходных текстов программ;
7)план и методику тестирования; тестовые варианты и полученные результаты;
8)руководства по работе и инсталляции;
9)ехе-код выполняемой программы;
10)описание базы данных;
11)руководство пользователя по настройке;
12)документы сопровождения; отчеты о проблемах ПС; запросы сопровождения; отчеты о конструкторских изменениях;
13)стандарты и методики конструирования ПС.
Проверка конфигурации гарантирует, что все элементы конфигурации ПС правильно разработаны, учтены и достаточно детализированы для поддержки этапа сопровождения в жизненном цикле ПС.
Организация процесса тестирования программного обеспечения:
Другие виды тестирования:
•Системное тестирование
•Тестирование восстановления
•Тестирование безопасности
•Стрессовое тестирование
•Тестирование производительности Следствием успешного тестирования является отладка. Если в процессе
тестирования выявлена ошибка - в процессе отладки она будет выявлена и устранена.
Организация процесса тестирования программного обеспечения: отладка
Различают две группы методов отладки:
1. Аналитические методы базируются на анализе выходных данных для тестовых прогонов.
Основное преимущество аналитических методов отладки состоит в том, что исходная программа остается без изменений.
2. Экспериментальные методы базируются на использовании вспомогательных средств отладки (отладочные печати, трассировки), позволяющих уточнить характер поведения программы при тех или иных исходных данных. Преимущество экспериментальных методов отладки состоит в том, что основная рутинная работа по анализу процесса вычислений перекладывается на компьютер. Многие трансляторы имеют встроенные средства отладки для получения информации о ходе выполнения программы.
Недостаток экспериментальных методов отладки — в программу вносятся изменения, при исключении которых могут появиться ошибки. Впрочем, некоторые системы программирования создают специальный отладочный экземпляр программы, а в основной экземпляр не вмешиваются.
Общая стратегия отладки — обратное прохождение от замеченного симптома ошибки к исходной аномалии (месту в программе, где ошибка совершена).
В простейшем случае место проявления симптома и ошибочный фрагмент совпадают. Но чаще всего они далеко отстоят друг от друга.
Пример цикла тестирования ПО:
Приведем пример стандартного цикла тестирования для каскадной модели ЖЦ ПО. Каждая организация может адаптировать данную обобщенную схему для себя.
Анализ требований. Тестирование должно проводится на этапе работы с требованиями. В ходе разработки тестировщики совместно с программистами определяют какие элементы проекта подлежат тестированию, и определяют параметры такого тестирования.
Планирование тестирования. Определяются те виды работ, которые необходимо планировать. Разрабатываются стратегия и план тестирования, test bed.
Разработка тестов. Процедуры и сценарии тестирования, варианты тестирования или тестовые случаи, наборы данных, тестовые скрипты.
Выполнение тестирования. Специалисты проводят все виды тестов согласно плану и документируют результаты.
Отчет о тестировании. По окончании тестирования рассчитываются оценки и готовится итоговый отчет.
Анализ результатов тестирования. Или анализ дефектов. После его окончания разработчики согласовывают с заказчиком меры по выявленным ошибкам.
Повторное тестирование. Единожды выявленный программистами баг, проверяется тестировщиками.
Регрессионное тестирование проводится Чтобы убедиться в работоспособности программы, после каждый модификации.
Окончание этапа тестирования. После того, как достигнут результат, соответствующий заданным критериям, вся артефакты тестирования приводятся в порядок и становятся статистикой для будущих проектов.
Артефакты тестирования:
•План тестирования.
Документ описывающий кто, что, когда и как будет тестироваться
Документ описывающий все необходимые для проверки приложения тесты.
•Тестовый сценарий (тест) — это описание начальных условий, входных данных, действий пользователя и ожидаемого результата.
•Наборы тестовых сценариев - Это тестовые сценарии сгруппированные по некоему признаку (например тестируемой функциональности). Наиболее часто выделяемыми наборами являются: Набор тестовых сценариев для Smoke-test и План приёмо-сдаточных испытаний.
•Набор тестовых сценариев для Smoke-test — задает перечень тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test — убедиться в том, что ключевые функции программы работают, не вникая в подробности.
•План приёмо-сдаточных испытаний - задает перечень тестовых сценариев, после положительного прохождения которых заказчик подписывает акт приемо-передачи (сдачи-приемки).
Стандарты, регулирующие качество ПО:
Общие принципы обеспечения качества процессов производства во всех отраслях экономики регулируются набором стандартов ISO 9000. Наиболее важные для разработки ПО стандарты в его составе следующие:
ISO 9000:2000 Quality management systems — Fundamentals and vocabulary. Системы управления качеством — Основы и словарь. (Аналог — ГОСТ Р-2001).
ISO 9001:2000 Quality management systems — Requirements. Models for quality assurance in design, development, production, installation, and servicing. Модели для обеспечения качества при проектировании, разработке, коммерциализации, установке и обслуживании. Определяет общие правила обеспечения качества результатов во всех процессах жизненного цикла. (Аналог — ГОСТ Р-2001).
ISO 9004:2000 Quality management systems — Guidelines for performance improvements.
Системы управления качеством. Руководство по улучшению деятельности. (Аналог — ГОСТ Р-2001).
ISO/IEC 90003:2004 Software engineering — Guidelines for the application of ISO 9001:2000 to computer software.
Руководящие положения по применению стандарта ISO 9001 при разработке, поставке и обслуживании программного обеспечения.
Этот стандарт конкретизирует положения ISO 9001 для разработки программных систем, с упором на обеспечение качества при процессе проектирования. Он также определяет некоторый набор техник и процедур, которые рекомендуется применять для контроля и обеспечения качества разрабатываемых программ.
Стандарт ISO 9126 предлагает использовать для описания внутреннего и внешнего качества ПО многоуровневую модель. На верхнем уровне выделено 6 основных характеристик качества ПО. Каждая характеристика описывается при помощи нескольких входящих в нее атрибутов. Для каждого атрибута определяется набор метрик, позволяющих его оценить.
