Связанные с изменениями виды тестирования

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

• Дымовое тестирование (Smoke Testing)

• Регрессионное тестирование (Regression Testing)

• Тестирование сборки (Build Verification Test)

• Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

17. Тестирование и управление изменениями: документирование, прослеживаемость и управление изменениями

Включается в системную документацию и состоит из тест-плана и документацию по прецеденту. При использовании кейс-средств возможно одновременное включение в репозиторий требований прецедентов и последующая генерация документации на их основе.

Управление изменениями заключается в работе с запросами на изменение, созданных по результатам выявленных дефектов, либо запросов на усовершенствования. Управление самими прецедентами и управление изменениями программного кода, как правило, реализовано в кейс-средствах.

Прослеживаемость тесно связана с тестированием и управлением изменениями, и должна обеспечивать связь между требованиями.

18. Управление изменениями кода: проблема и решения

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

Дополнительные применения:

1. возможность командной работы с одним и теми же файлами,

2. возможность синхронизации между разными рабочими местами,

3. возможность возврата к любому зафиксированному состоянию.

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

При одновременном изменении система контроля версиями может сама разрешить конфликты (объединить или слить изменения), либо предлагают средства их решения. Процесс слияния осуществляется в следующей последовательности:

1. получение самой актуальной версии,

2. слияние изменений,

3. при попытке сохранения на сервере, проверяется, что слияние было произведено с последней версией.

Некоторые системы позволяют блокировать файл в хранилище.

Дополнительные возможности систем управления версиями:

1. создание точек ветвления с общей историей изменения до точки ветвления, и с разными после неё,

2. дают возможность кто и что изменить,

3. ведут журнал изменений,

4. ведут контроль доступа.

19. Управление изменениями кода: типичный порядок работы с системой

1. Начало работы с проектом.

2. «Ежедневная» работа:

a) обновление рабочей копии,

b) внесение изменений,

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

3. Ветвление (слияние выполняется на клиенте, создание патча).

4. Конфликты и их разрешения (на этапах фиксации изменений, обновлений или слияния ветвей). Решения конфликтов бывают:

a) базовыми,

b) локальными,

c) серверными.

5. Блокировки.

6. Версии проекта или теги.

Базовые принципы работы над проектом с использованием ВЦС:

1) «Персональные» сборки не фиксируются в общем репозитории.

2) Текущая версия главной ветки всегда корректна.

3) Все изменения вносятся в рабочую ветку.

4) Выделенная тегом версия никогда не изменяется.

5) Демонстрационные и тестовые версии собираются только из репозитория системы.