Тестирование поддержки (Maintenance testing)
Сопровождение (maintenance): Модификация программного продукта после его поставки с целью исправления дефектов, улучшения производительности или других характеристик или для адаптации продукта к изменившемуся окружению. (IEEE 1219)
Сопровождаемость (maintainability): Легкость изменения программного продукта для исправления дефектов, для соответствия новым требованиям, с целью облегчения последующего сопровождения или для адаптации к изменившемуся окружению. (ISO 9126)
Тестирование сопровождаемости (maintainability testing): Тип тестирования, проводимого для оценки степени эффективности и продуктивности возможных изменений элемента тестирования. (ГОСТ 56920)
Maintenance является последней стадией SDLC. По мнению многих экспертов, по мере того, как изменения после релиза вносятся в существующее приложение, каждое изменение может рассматриваться как начало нового цикла SDLC, но точнее будет сказать, что проект в это время находится в жизненном цикле обслуживания программного обеспечения (SMLC - Software Maintenance Life Cycle). Многие проекты проводят большую часть своего времени именно в SMLC после релиза, а не в SDLC перед ним.
Maintenance testing (тестирование поддержки/обслуживания/эксплуатации/сопровождения) - это модификация программного продукта после его выпуска с целью исправления дефектов, улучшения производительности или других характеристик или для адаптации продукта к изменившемуся окружению. (IEEE 1219). После того, как программное обеспечение или приложение задеплоены, оно начинает эксплуатироваться годами и даже десятилетиями. В это время система и ее операционная среда часто исправляются, изменяются или расширяются. Пользователю могут потребоваться некоторые добавленные или новые функции в текущем программном обеспечении, которые требуют внесения изменений в текущее программное обеспечение, и эти изменения должны быть протестированы. Конечным пользователям может потребоваться миграция программного обеспечения на другую самую последнюю аппаратную платформу или изменение среды, например версии ОС, варианта базы данных и т. д., что требует тестирования всего приложения на новых платформах и в новой среде. После того, как продукт релизится, он время от времени требует некоторого обслуживания в целях профилактики сбоев.
Основные активности (principal activities):
Динамическое обслуживание (Dynamic maintenance)
Корректирующее обслуживание (Corrective maintenance)
Адаптивное обслуживание (Adaptive maintenance)
Задача выполнения Maintenance testing становится более эффективной, когда программное обеспечение имеет хорошую характеристику обслуживаемости (maintainability).
Reliability, maintainability в ISO 9126 определяется как «легкость, с которой программный продукт может быть изменен для исправления дефектов, модифицирован для соответствия новым требованиям, модифицирован для облегчения будущего обслуживания или адаптирован к изменившейся среде».
Maintainability состоит из:
Анализируемость: это относится к усилиям, требуемым (обычно разработчиками) для диагностики дефектов или выявления частей программной системы, требующих изменений;
Изменяемость: это касается усилий, необходимых для фактического исправления дефектов или внесения улучшений;
Стабильность: вероятность возникновения непредвиденных побочных эффектов в результате внесения изменений в программное обеспечение. Это то, что мы имеем в виду, когда иногда говорим, что программное обеспечение хрупкое (brittle);
Тестируемость: описывает усилия, необходимые для тестирования измененного программного обеспечения. Это один из основных атрибутов качества программного обеспечения, который напрямую влияет на нашу работу;
Причины плохой Maintainability:
Усилия, необходимые для исправления дефектов и внесения изменений, могут быть больше, чем планировалось
Если размер группы поддержки (maintenance team), выполняющей эти задачи, будет фиксированным (обычная ситуация), это также приведет к увеличению временных затрат
Время, затрачиваемое на задачи обслуживания, превышает фиксированные окна обслуживания (maintenance windows)
Это может отрицательно сказаться на производстве (например, сотрудники, прибывающие на работу, обнаруживают, что сервер приложений недоступен из-за проскальзывания окна планового ночного обслуживания)
Поддержка (Maintainers) могут быть вынуждены сокращать сроки, чтобы не выходить за рамки согласованных периодов обслуживания. Им может потребоваться сделать предположения относительно реализации необходимых изменений (возможно, из-за плохой документации)
Если применяются Соглашения об уровне обслуживания, могут налагаться штрафы
Долгосрочное накопление плохой поддерживаемости в результате кумулятивного эффекта плохой практики разработки программного обеспечения
Уровень надежности постепенно снижается
Увеличивается количество функциональных дефектов, вносимых изменениями (регрессии)
На исправление дефектов уходит больше времени
На персонал поддержки оказывается все большее давление, что может даже привести к дальнейшему ухудшению ситуации
Виды Maintenance testing:
Подтверждающее тестирование (Confirmation Maintenance Testing): тестирование измененной функциональности. Вы должны тщательно протестировать все модификации (небольшие или большие), внесенные в программное обеспечение, и убедиться, что нет проблем с функциональностью и простоев. Тестовая среда должна быть копией реальной среды вместе с тестовыми данными;
Регрессионное тестирование (Regression Maintenance Testing): тестирование существующей функциональности на предмет регрессии. Это делается после фазы подтверждающего тестирования. Вы должны протестировать всю систему, чтобы убедиться, что измененная функциональность (работы по обслуживанию) не должна влиять на функциональность существующего программного обеспечения;
Для поддерживающего релиза (maintenance release) может потребоваться поддерживающее тестирование на нескольких уровнях тестирования с использованием различных типов тестов в зависимости от его объема. Объем технического обслуживания зависит от:
Степень риска изменения, например, степень, в которой измененная область программного обеспечения общается с другими компонентами или системами;
Размер существующей системы;
Размер изменения;
Триггеры для Maintenance. Существует несколько причин, по которым проводится обслуживание программного обеспечения, а значит, и тестирование обслуживания, как для запланированных, так и для незапланированных изменений. Мы можем классифицировать триггеры для обслуживания следующим образом:
Модификации, такие как запланированные улучшения (например, на основе выпуска), корректирующие и срочные изменения, изменения операционной среды (например, плановые обновления операционной системы или базы данных), обновления программного обеспечения COTS и исправления для дефектов и уязвимостей;
Миграция, например, с одной платформы на другую, которая может потребовать операционных тестов новой среды, а также измененного программного обеспечения, или тестов преобразования данных, когда данные из другого приложения будут перенесены в поддерживаемую систему;
Вывод из эксплуатации, например, когда срок поддержки приложения подходит к концу. Когда приложение или система выводятся из эксплуатации, это может потребовать тестирования миграции или архивирования данных, если требуются длительные периоды хранения данных;
Также может потребоваться тестирование процедур восстановления / извлечения после архивирования в течение длительного периода хранения;
Регрессионное тестирование может потребоваться, чтобы убедиться, что все функциональные возможности, которые остаются в эксплуатации, по-прежнему работают;
Например, для систем Интернета вещей (IoT) тестирование обслуживания может быть инициировано введением в общую систему совершенно новых или модифицированных вещей, таких как аппаратные устройства и программные услуги. При тестировании обслуживания таких систем особое внимание уделяется интеграционному тестированию на разных уровнях (например, уровень сети, уровень приложений) и аспектам безопасности, в частности, тем, которые относятся к персональным данным.
Impact Analysis для Maintenance. Анализ воздействия оценивает изменения, которые были внесены в поддерживающую версию, чтобы определить предполагаемые последствия, а также ожидаемые и возможные побочные эффекты (side effects) изменения, а также определить области в системе, на которые это изменение повлияет. Анализ влияния также может помочь определить влияние изменения на существующие тесты. Побочные эффекты и затронутые области в системе необходимо протестировать на предмет регрессии, возможно, после обновления любых существующих тестов, затронутых изменением. Анализ воздействия может быть проведен до внесения изменения, чтобы помочь решить, следует ли вносить изменение, исходя из возможных последствий в других областях системы.
Источники:
Доп. материал:
Last updated
Was this helpful?