tестирование dot com
Шрифт:
КУДА
их можно положить после редактирования (checkin).
При этом
а) каждый раз, когда мы кладем файл в репозитарии,
• не нужно менять имени файла;
• мы можем комментировать, что было изменено в этом
файле;
• CVS автоматически присваивает файлу номер редакции
(версии), уникальный для этого файла;
• CVS связывает номер версии файла, комментарий к из-
менениям, имя
110
Тестирование Дот Ком. Часть 1
запись (при желании можно увидеть всю историческую
последовательность записей);
б) если Дима взял из репозитария файл, то Митя не может его
оттуда взять, пока Дима не положит его обратно.
Итак, поставив старую добрую и бесплатную CVS, мы имеем:
• все версии файла, каждая из которых кроме уникального
номера версии имеет еще и запись об изменениях;
• программистов, которые уже не могут случайно уничто-
жить код друг друга;
• возможность сравнить содержание файла в разных ре-
дакциях.
Теперь, когда наш код хранится в CVS, возникает другая задача —
как сделать так, чтобы этот код стал доступным на веб-сайте для
тестирования — www.main.testshop.rs? Для решения этой задачи
нужно, чтобы файлы из CVS были интегрированы и отправлены
по назначению в соответствующие директории тест-машины и
чтобы у нас было отражение содержимого CVS
• по состоянию на данный момент и
• для данного релиза.
Каждое такое отражение кода веб-сайта называется билдом (build).
Иными словами, билд — это версия версии ПО.
Билды делаются или вручную, или путем запуска билд-скриптов
(build script), т.е. программ, написанных релиз-инженерами для
автоматизации процесса. Как правило, билд-скрипты добавляются
в сгоп (это расписание запуска программ в Линукс-системах), с
тем чтобы создавать новые билды через определенные проме-
жутки времени.
Цель создания новых билдов заключается в том, чтобы изме-
ненный код (сохраненный в CVS) стал доступным для тестиров-
щиков:
а. После того как программист починил баг, найденный при
тестировании, он тестирует починку на своем плэйгра-
унде, после чего делает checkin отремонтированного кода
в CVS.
б. Отремонтированный код становится частью нового билда.
в. Новый билд замещает (replace) на тест-машине код преды
дущего билда.
Цикл разработки ПО
111
Пример
Допустим, что время на создание нового билда равно 15 минутам.
Билд-скрипты создают новые билды каждые 3 часа в соответствии с
расписанием билдов (build schedule): в 12:00, 15:00, 18:00 и т.д. Прак-
тическую ценность здесь имеют две вещи:
1. Нет смысла тестировать веб-сайт с 12:00 до 12:15, с 15:00 до
15:15, с 18:00 до 18:15 и т.д., так как билд находится в процессе
создания и одна часть файлов может принадлежать старому
билду, а другая — новому.
2. Если программист починил ваш баг и сделал checkln изменен-
ного кода в CVS, то вы сможете протестировать починку только
после следующего билда, т.е. если checkin файла в CVS произо-
шел в 16:00, то протестировать починку можно после билда, ко-
торый начнется в 18:00.
Соответственно иногда в целях экономии времени имеет смысл
попросить релиз-инженера, чтобы тот сделал внеочередной билд,
причем о последнем должны быть оповещены все остальные тести-
ровщики.
Итак, перед проверкой починки бага убедитесь не только в
том, что вы тестируете нужную версию, но и в том, что тести-
руете нужный билд. Номер билда, содержащего отремонтиро-
ванный код, включается программистом в запись о баге в СТБ
(подробнее об этом в разговоре о СТБ).
Кстати, номера билда для данной конкретной версии начинаются с
единицы для первого билда (который мы проверяем во время теста
приемки) и увеличиваются на единицу с каждым новым билдом.
Как узнать номер билда? Спросите об этом своего релиз-инже-
нера. В веб-проектах номер билда часто включается в HTML-KOJX
каждой страницы веб-сайта и может быть найден, если посмотреть
этот код, используя функциональность веб-браузера View source.
Итак, Дима написал билд-скрипт, добавил его в сгоп, и новый
билд у нас создается каждые 3 часа.
С точки зрения конфигурации системы плэйграунд каждого из