Системное тестирование выполняется через внешние интерфейсы программного обеспечения и тесно связано с тестированием интерфейсов, которое проводят с помощью имитации действий пользователей над элементами этого интерфейса. Частным случаем этого вида тестирования является тестирование графического интерфейса пользователя (GUI) и интерфейса Web-приложений. Если интеграционное и модульное тестирование чаще проводят, воздействуя на компоненты системы с помощью предоставляемого ими программного интерфейса (API), то на системном уровне не обойтись без интерфейса пользователя, хотя тестирование через API также возможно.
Регрессивное тестирование - это методика испытаний, при которой тесты, произведенные ранее, повторно выполняются на новой версии целевого объекта. Цель такого тестирования - обеспечить, чтоб качество целевого объекта не ухудшалось при добавлении к этому объекту новых функций. Регрессивное тестирование необходимо для максимально раннего выявления дефектов. Как правило, такое тестирование выполняется в каждой итерации и заключается в повторном запуске тестов, выполненных на предыдущих итерациях.
Основные принципы дизайна классов в объектно-ориентированном программировании (SOLID) (предложены Робертом Мартином): 1) Single Responsibility Principle (принцип единственной обязанности): не должно быть более одной причины для изменения класса; 2) Open/Closed Principle - принцип открытия/закрытия: объекты проектирования (классы, функции, модули) должны быть открыты для расширения, но закрыты для модификации; открыт для расширения - поведение может быть расширено путём добавления новых объектов, реализующих новые аспекты поведения; закрыт для модификации - в результате расширения поведения исходный или двоичный код объекта не может быть изменён; 3) Liskov Substituion Principle (принцип замещения Лисков): функции, которые используют ссылки на базовые классы, должны иметь возможность использовать объекты произвольных классов, не зная об этом; 4) Interface Segregation Principle (принцип разделения интерфейса): клиент не должен вынужденно зависеть от элементов интерфейса, которые он не использует (зависимость между классами должна быть ограничена как можно более узким интерфейсом; 5) Dependency Invertion Principle (принцип обращения зависимостей: модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций, а абстракции не должны зависеть от деталей, при этом детали должны зависеть от абстракций.
Модернизация программного обеспечения
Динамика развития программ
Под динамикой развития программ понимают исследование изменений в программной системе. Результатом этих исследований стало множество законов Лемана, касающихся модернизации систем: 1) непрерывность модернизации: для программ, эксплутируемых в реальных условиях, модернизация - это необходимость, иначе их полезность снижается; 2) растущая сложность: согласно развитию, программы становятся всё более сложными, для упрощения или сохранения их структуры необходимы дополнительные затраты; 3) эволюция больших систем: процесс развития систем - саморегулирующийся. Такие характеристики системы, как размер, время между выпусками очередных версий и количество регистрируемых ошибок для каждой версии остаются практически неизменными; 4) организационная стабильность: жизненный цикл системы относительно стабилен, независимо от средств, которые выделены или не выделены на её развитие; 5) стабильность количества изменений: за весь жизненный цикл системы количество изменений в каждой версии остаётся примерно одинаковым.
Сопровождение программного обеспечения
Сопровождение - это обычный процесс изменения системы после её поставки заказчику, сопровождение не связано со значительными изменениями архитектуры системы, изменение существующих компонентов системы или добавление новых. Выделяют три вида сопровождения системы: 1) сопровождение с целью исправления ошибок: ошибки программирования легко одолеть, если же возникают ошибки проектирования, они требуют корректировки и перепрограммирования некоторых компонентов; 2) сопровождение с целью адаптации программного обеспечения к специфическим условиям эксплуатации; это может понадобиться при изменении составляющих рабочего окружения системы (программных средств, операционной системы); 3) сопровождение с целью изменения функциональных возможностей системы; возникает в результате организационных или деловых изменений.
Ключевые факторы, определяющие стоимость разработки и сопровождения: 1) стабильность команды разработчиков; 2) ответственность в соответствии с контрактом; 3) квалификация специалистов; 4) возраст и структура программы.
Показатели для оценки удобства сопровождения после ввода системы в эксплуатацию: 1) количество запросов на корректировку системы: рост количества сообщений о сбоях в системе означает увеличения количества ошибок, которые подлежат исправлению при сопровождении; это говорит об ухудшении удобства сопровождения; 2) среднее время, затраченное на анализ причин системных сбоев и отказов: этот показатель пропорционален количеству системных компонентов, в которых нужно внести изменения; если этот показатель растёт, то система требует многочисленных изменений; 3) среднее время, необходимое для реализации изменений: учитывается не время анализа системы для выявления причин сбоев, а время реализации изменений, их документирование, которое зависит от сложности программного кода; увеличение этого показателя означает сложность сопровождения; 4) количество незавершённых запросов на изменение: с ростом количества таких запросов сопровождение системы становится труднее. Таким образом, для определения стоимости сопровождения используется дополнительная информация о запросах на изменение и прогнозирование по удобству сопровождения. Причины перехода к новой архитектуре системы: 1) стоимость аппаратных средств; 2) совершенствование интерфейса пользователя; 3) распределённый доступ к системам.