Тестирование программного обеспечения –

 это проверка ошибок,

 проверка соответствия ПО требованиям и здравому смыслу,
 оценка работоспособности ПО,
 Способ контролировать качество ПО.

Причины ошибок в ПО –

 человеческий фактор,
 проблемы в описании требований к ПО,
 недостаток времени,
 недостаточно продуманная архитектура приложения,
 недостаточное знание бизнеса,
 нехватка профессиональных навыков и опыта,
 изменения « в последнюю минуту».

История тестирования ПО. 9 сентября 1945 года оформлен 1ый баг. Первые программные
системы разрабатывались в рамках программ научных исследований или программ для нужд
министерства обороны. Тестирование таких продуктов проводилось строго формализовано с
записью всех тестовых процедур, тестовых данных, полученных результатов. Тестирование
выделялось в отдельный процесс, который начинался после завершения кодирования, но при
этом, как правило, выполняется тем же персоналом.

1960-х много внимания уделялось исчерпывающему тестированию, которое должно проводиться

с использованием всех путей в коде или вех возможных входных данных.

Однако это невозможно

1. Количество возможных водных данных очень велико

2. Существует множество путей

3. Сложно найти проблемы в архитектуре и спецификациях

Итог исчерпывающее тестирование было отклонено и признано теоретически невозможным.

В начале 1970-х годов тестирование ПО обозначалось как «процесс, направленный на

демонстрацию корректности продукта» или как «деятельность по подтверждению правильности
работы ПО»

Впоследствии этот метод тестирования был признан неэффективен.

Во второй половине 1970-х тестирование представлялось как выполнение программы с

намерениями найти ошибки, а не доказать, что она работает

Успешный тест – это тест, который обнаруживают ранее неизвестные проблемы.

1980-е годы тестирование расширялось понятием, как предупреждение дефектов.

Стали высказывать мысли, что необходимо методология тестирования, в частности, что

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

В ходе тестирования надо проверить не только собранную программу, но и требования , код,

архитектуру , сами тесты.
В начале 1990-х годов в понятие «тестирование» стали включать планирование, проектирование,
создание, поддержку и выполнение тестов и тестовых окружений, и это означало переход от
тестирования к обеспечению качества.

Начинают появляться различные программные инструменты для поддержки процесса

тестирования более продвинутые среды для автоматизации с возможностью создания скриптов и
генерации отчетов, системы управления тестами, ПО для проведения нагрузочного тестирования.

Тестирование / Обеспечения качества

Активности, которые помогают обеспечить качество:

 Тестирование требований
 Юнит- тесты
 Код-ревью
 Ранняя интеграция

Тестирование требование – выполняется самими тестировщиками.

Стандарты качества

Качество системы

Это степень удовлетворения системой заявленных и подразумеваемых потребностей различных

заинтересованных сторон, которая позволяет, таким образом, оценить достоинства.

Эти заявленные и подразумеваемые потребности представлены в международных стандартах

серии SQuaRE посредством моделей качества, которые предоставляют качество продукта в виде
разбивки на классы характеристик, которое в отдельных случаях далее разделяются на под
характеристики.

Модели качества

 Модель качества при использовании

 Модель качества продукта
 Модель качества данных ISO/IEC 25012-2008

Модель качества при использовании

 Эффективность(результативность) – это точность и полнота, с которой пользователи

достигают поставленных целей.
 Производительность – связь точности и полноты достижения пользователей целей с
израсходованными ресурсами
 Удовлетворенность (полноценность (пригодность, полезность), доверие, удовольствие,
комфорт (физический комфорт))
 Свобода от риска (смягчение отрицательных последствий:
o Экономического риска;
o Риска здоровья и безопасности;
o Экологического риска.

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

 Функциональная пригодность – это степень в которой продукт обеспечивает выполнение

функций в соответствии с заявленными требованиями. Делиться:
 Функциональная полнота- степень покрытия функций всех определенных задач и
целей пользователей
 Функциональная корректность (приложение делает то, что должно делать)
 Функциональная целесообразность – степень функционального упрощения
выполнения зада пользователя
 Уровень производительности – это степень производительности ПО относительно суммы
использованных ресурсов.
 Временные характеристики
 Использование ресурсов
 Потенциальные возможности- это степень соответствия требованиями предельных
значений параметров продукта.
 Совместимость:
 Сосуществование – степень, в которой ПО может сосуществовать с другим ПО на
одном девайсе, сервере или системе.
 Интероперабельность – это степень в которой две и более системы способны
обмениваться информацией (использовать информацию друг друга)
 Удобство использования:
 Определимость пригодности;
 Изучаемость;
 Управляемость;
 Защищенность от ошибки пользователя;
 Эстетика пользовательского интерфейса;
 Доступность. – возможность использования системы для достижения
определенной цели в указанном контексте использования, широким кругом
людей с самыми разными возможностями.
 Надежность
 завершенность (зрелость)
 готовность(доступность) – можно оценить, как долю общего времени, в
течении которого приложение находится в работоспособном состоянии
 отказоустойчивость
 восстанавливаемость – способность продукта восстановить данные или самого
себя после того, как произошел сбой.
 Защищённость
 конфиденциальность – обеспечение доступа и ограничение доступа к
определенным ресурсам приложения в соответствии с ролью
пользователя.
 целостность – степень предотвращения системой не санкционированного
доступа или модификации данных.
 неподдельность – степень в которой может быть доказан факт события
или действия таким образом, что этот факт не может быть опровергнут.
 отслеживаемость – степень до которой действие объекта могут быть
прослежены однозначно.
 подлинность – степень достоверности того, что объект или ресурс равны
требуемому объекту или ресурсу.
  Сопровождаемость
 модульность – деление программы на модули
 возможность многократного использования
 анализируемость – на сколько быстро можно проанализировать и
понять где ошибка
 модифицируемость – связано с исправлением ошибок.
 тестируемость
 Переносимость
 адаптируемость
 устанавливаемость
 взаимозаменяемость – способность продукта заменить другой
конкретный программный продукт для достижения тех же целей в
тех же условиях.

Терминология

DEV ENVIRONMENT – среда для разработчиков где они отслеживают, проверяют, есть ли
изменения (новые изменения видны сразу и они намного чаще чем в QA (отличие от QA)

QA ENVIRONMENT – среда где тестировщики проверяют качество приложения

STAGING ENVIRONMENT – среда, где имитируется работа приложения, как на production

environment

PRODUCTION ENVIRONMENT - среда, где работают конечные пользователи приложения

VERIFICATION – процесс тестирования приложения на соответствие предъявленным требованиям

которые осуществляются на протяжении всей разработки приложения.

VALIDATION – проверка приложения на соответствие бизнес-целям проводиться, как правило

перед релизом.
 Процесс разработки ПО

Процесс разработки -Структура, согласно которой построено создание нового ПО.

Жизненный цикл ПО – период времени, который начинается с момента принятия решения о

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

Составляющая процесса

 Требования
 Архитектура
 Дизайн
 Имплементация
 Тестирование
 Релиз

Модели разработки ПО

Структура, систематизирующая различные виды проектной деятельности, их взаимодействие

и последовательность в процессе разработки ПО

 Каскадная модель ( НЕ МОЖЕМ ВЕРНУТЬСЯ К ПРЕВЕДУЩЕЙ ФАЗЕ)

 Требования
 Архитектура
 Дизайн
 Имплементация
 Тестирование
 Релиз) В современной ко всему добавляется тестирование. (подходит медицинское,
военное ПО, крупные проекты, распределенная команда) (Не подходит часто меняются
требования , небольшие проекты ,небольшая команда)
 V-модель
 Требования
 Архитектура
 Дизайн
 Имплементация
 Модульное тестирование
 Верификация
 Валидация

 Итеративная модель
Требование – дизайн –имплементация – тестирование – релиз (и так по кругу)
Подходит для небольших проектов, небольших команд, команда в одной локации.
Не подходит распределенная команда, медицинское, военное ПО ( делим большой
объем на маленькие кусочки ) ( всегда есть возможность в последнюю минуту сделать
изменения)
 Инкрементальная модель
 Спиральная модель
AGILE
Философия разработки ПО.
AGILE МАНИФЕСТ :
Люди и взаимодействие важнее процессов и инструментов
Работающие продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласованной

SCRUM и XP
Мери и Том Поппендик Береживое производство ПО
Кен АУЭР, РОЙ Миллер экстрим программиование