3.5.3.Виды тестирования

2.2.1 Приёмочное тестирование проверяет поведение системы на предмет удовлетворения требований заказчика.

2.2.2 Установочное тестирование проводится с целью проверки процедуры инсталляции системы в целевом окружении.

2.2.3 Альфа- и бета-тестирование проводится перед выпуском версий. Альфа - внутреннее пробное использование и бета - пробное использование с привлечением отобранных внешних пользователей версий.

2.2.4 Функциональные тесты/тесты соответствия – проверка соответствия системы предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик.

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

2.2.6 Регрессионное тестирование - повторное выборочное тестирование системы или компонент для проверки того, что сделанные модификации не приводят к непредусмотренным эффектам..

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

2.2.8 Нагрузочное тестирование - выполнение программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик и далее, с отслеживанием поведения на всем протяжении повышения загрузки системы.

2.2.9 Сравнительное тестирование - набор тестов, позволяющих сравнить две версии системы.

2.2.10 Восстановительные тесты – проверка возможностей рестарта системы в случае непредусмотренной катастрофы, влияющей на функционирование операционной среды, в которой выполняется система.

2.2.11 Конфигурационное тестирование. В случаях, если программное обеспечение создается для использования различными пользователями (в терминах “ролей”), данный вид тестирования направлен на проверку поведения и

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

2.2.12 Тестирование удобства и простоты использования. Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не только функциональную составляющую – саму систему, но и ее документацию; насколько эффективно пользователь может выполнять задачи, автоматизация которых осуществляется с использованием данной системы; наконец, насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от ошибок пользователя.

3.5.4.Метрики

Измерения программ - это часть планирования, управления программными проектами и разработки тестов. Данные измерения могут базироваться на размере программ (например, в терминах количества строк кода или функциональных точек) или их структуре (например, с точки зрения оценки ее сложности в тех или иных архитектурных терминах). Структурные измерения могут также включать частоту обращений одних модулей программы к другим.

3.6.Сопровождение программного обеспечения

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

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

Сопровождение программного обеспечения в SWEBOK определяется как вся совокупность деятельности, необходимой для обеспечения эффективной (с точки зрения затрат) поддержки программных систем. Эти работы выполняются как перед вводом системы в эксплуатацию, так и после этого. Предварительные работы включают планирование деятельности по сопровождению системы, а также организацию перехода к ее полнофункциональному использованию. Если новая система должна заменить старую систему, предназначенную для решения тех же задач, просто на новом уровне эффективности, стоимости использования, новых функциональных возможностей, в этом случае важно обеспечить плавный переход со старой системы на новую, максимально естественный для пользователей. С этим связано не только планирование, например, переноса информации, хранимой в соответствующих базах данных, но и обучение пользователей, подготовка, настройка и проверка “боевой” конфигурации, определение последовательности операций, организация и обучение службы поддержки (help-desk) и т.п.

Сопровождение поддерживает функционирование программного продукта на протяжении всего операционного жизненного цикла, то есть периода его эксплуатации. В процессе сопровождения фиксируются и отслеживаются запросы на модификацию (также называемые “запросами на изменения” – change requests, в частности, в контексте конфигурационного управления), оценивается влияние предлагаемых изменений, модифицируется код и другие активы (артефакты) продукта, проводится необходимое тестирование и, наконец, выпускается обновленная версия продукта. Кроме того, проводится обучение пользователей и обеспечивается их ежедневная поддержка при работе с текущей версией продукта.

В общем случае, работы по сопровождению должны проводиться для решения следующих задач:

• устранение сбоев

• улучшение дизайна

• реализация расширений <функциональных возможностей>

• создание интерфейсов взаимодействия с другими (внешними) системами

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

• миграции унаследованного (legacy) программного обеспечения

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

Деятельность персонала сопровождения включает четыре ключевых аспекта:

• поддержка контроля (управляемости) программного обеспечения в течение всего цикла эксплуатации;

• поддержка модификаций программных систем;

• совершенствование существующих функций;

• предотвращение падения производительности программной системы до неприемлемого уровня.

Работы по сопровождению потребляют если не большую (как отмечает SWEBOK), то значительную часть финансовых ресурсов жизненного цикла программного обеспечения. Общее понимание сопровождения подразумевает лишь устранение сбоев. Однако, исследования и опросы на протяжении многих лет показывают, что более 80% усилий по сопровождению связаны не столько устранением сбоев, сколько с другими работами, не связанными с исправлением дефектов. Многие менеджеры по сопровождению объединяют в отчетности вопросы расширения функциональности и исправления ошибок в поддерживаемых программных системах. Такое смешение качественно различных работ приводит к неправильному представлению о реальной, на самом деле, не столь высокой стоимости сопровождения в части устранения дефектов. Понимание различных категорий работ в рамках деятельности по сопровождению помогает понять структуру реальных затрат. Кроме того, понимание факторов, влияющих на возможности сопровождения системы, помогают не только сохранять необходимый уровень затрат, но и снижать их.