Ветвления

Делать мелкие исправления в проекте можно путём непосредственной правки рабочей копии и последующей фиксацией изменений прямо в главной ветви (стволе) на сервере. Однако при выполнении сколько-нибудь значительных по объёму работ такой порядок становится неудобным: отсутствие фиксации промежуточных изменений на сервере не позволяет работать над чем-либо в групповом режиме, кроме того, повышается риск потери изменений при локальных авариях и теряется возможность анализа и возврата к предыдущим вариантам кода в пределах данной работы. Поэтому для таких изменений обычной практикой является создание ветвей (branch), то есть «отпочковывания» от ствола в какой-то версии нового варианта проекта или его части, разработка в котором ведётся параллельно с изменениями в основной версии. Ветвь создаётся специальной командой. Рабочая копия ветви может быть создана заново обычным образом (командой извлечения рабочей копии, с указанием адреса или идентификатора ветви), либо путём переключения имеющейся рабочей копии на заданную ветвь.

Чаще всего, когда работа, для которой создана ветвь, выполнена, ветвь реинтегрируется в ствол (основную ветвь). Это может делаться командой слияния (обычно merge), либо путём создания патча (patch), содержащего внесённые в ходе разработки ветви изменения и применения этого патча к текущей основной версии проекта.

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

1. Любые рабочие, тестовые или демонстрационные версии проекта собираются только из репозитория системы. «Персональные» сборки, включающие ещё не зафиксированные изменения, могут делать только разработчики для целей промежуточного тестирования. Таким образом, гарантируется, что репозиторий содержит всё необходимое для создания рабочей версии проекта.

2. Текущая версия главной ветви всегда корректна. Не допускается фиксация в главной ветви неполных или не прошедших хотя бы предварительное тестирования изменений. В любой момент сборка проекта, проведённая из текущей версии, должна быть успешной.

3. Любое значимое изменение должно оформляться как отдельная ветвь. Промежуточные результаты работы разработчика фиксируются в эту ветвь. После завершения работы над изменением ветвь объединяется со стволом. Исключения допускаются только для мелких изменений, работа над которыми ведётся одним разработчиком в течение не более чем одного рабочего дня.

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

31. Тестирование. Основные определения. Виды.

Тестирование программы — выполнение этой программы с целью обнаружения факта наличия в программе ошибки.

Отладка программы — определение места ошибки и внесение изменений в программу.

Цель тестирования — обнаружение ошибок в программе, а не доказательство её правильности.

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

Хорошим считается тест, который имеет высокую вероятность обнаружения ещё не выявленной ошибки.

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

Критерии разумности:

1. Программа должна быть правильной синтаксически.

2. Программа должна правильно решать поставленную перед ней задачу: при вводе в неё корректных данных она должна выдавать правильный результат. Правильность результата оговоривается с заказчиком.

3. Программа не должна делать ничего лишнего.

4. Результат должен быть получен за разумное время при разумных затратах других ресурсов.

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

Принципы тестирования:

1. Психологический — необходимо исходить из того, что ошибки в программе есть.

2. Тест представляет собой совокупность исходных данных и результатов. Результаты фиксируются до выполнения тестов.

3. Тестовые данные должны быть достаточно просты для проверки.

4. Тесты готовятся заранее, до выхода на машину. Это касается как исходных данных, так и ожидаемых результатов.

5. Первые тесты разрабатываются после получения задания на разработку, до написания кода. Кроме этого, ранняя разработка тестов помогает правильно понять поставленную задачу, вовремя её уточнить, выявить тонкие места.

6. Перед началом тестирования следует сформулировать цели, которые должны быть достигнуты в ходе тестирования.

Пример цели — полнота набора теста.

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

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

8. Тесты должны быть одинаково тщательны как для правильных, так и для неправильных входных данных.

9. Необходимо проверить 2 момента:

• Программа делает то, что должна делать.

• Программа не делает того, чего делать не должна.

10) Результаты теста необходимо изучать досконально и изучать полностью (изучай меня полностью ^_^)

11) Недопустимо ради упрощения тестирования изменять программу.

12) После внесения исправлений необходимо повторно протестировать программу. Вероятность внесения новой ошибки при исправлении старой — 20-50%.

13) Ошибки «кучкуются» - чем больше ошибок обнаружено в модуле и исправлено, тем больше вероятность, что там есть ещё.

14) Окончательное тестирование желательно проводить не автору программы, а другому человеку.

Самый очевидный способ проверки программы — перебрать все возможные варианты входных данных и проверить правильность полученных результатов. Но в большинстве случаев это невозможно.

Данный способ (исчерпывающее тестирование) применяется крайне редко и для любой нетривиальной программы невозможен.

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

все варианты делятся на подмножества, причём варианты попавшие в одно подмножество считаются равнозначными.

Проверив один из вариантов подмножества, мы проверили все остальные варианты подмножества.

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

Классификация — деление множества объектов на подмножества.

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

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

После выбора критерия полноты тестирования необходимо проанализировать каждый тест с 2-х точек зрения:

1. удачен ли данных тест и насколько он хорош.

2. Нужны ли дополнительные тесты.