tестирование dot com
Шрифт:
Допустим, что время на создание нового билда равно 15 минутам.
Билд-скрипты создают новые билды каждые 3 часа в соответствии с
расписанием билдов (build schedule): в 12:00, 15:00, 18:00 и т.д. Прак-
тическую ценность здесь имеют две вещи:
1. Нет смысла тестировать веб-сайт с 12:00 до 12:15, с 15:00 до
15:15,
создания и одна часть файлов может принадлежать старому
билду, а другая — новому.
2. Если программист починил ваш баг и сделал checkln изменен-
ного кода в CVS, то вы сможете протестировать починку только
после следующего билда, т.е. если checkin файла в CVS произо-
шел в 16:00, то протестировать починку можно после билда, ко-
торый начнется в 18:00.
Соответственно иногда в целях экономии времени имеет смысл
попросить релиз-инженера, чтобы тот сделал внеочередной билд,
причем о последнем должны быть оповещены все остальные тести-
ровщики.
Итак, перед проверкой починки бага убедитесь не только в
том, что вы тестируете нужную версию, но и в том, что тести-
руете нужный билд. Номер билда, содержащего отремонтиро-
ванный код, включается программистом в запись о баге в СТБ
(подробнее об этом в разговоре о СТБ).
Кстати, номера билда для данной конкретной версии начинаются с
единицы для первого билда (который мы проверяем во время теста
приемки) и увеличиваются на единицу с каждым новым билдом.
Как узнать номер билда? Спросите об этом своего релиз-инже-
нера. В веб-проектах номер билда часто включается в HTML-KOJX
каждой страницы веб-сайта и может быть найден, если посмотреть
этот код, используя функциональность веб-браузера View source.
Итак, Дима написал билд-скрипт, добавил его в сгоп, и новый
билд у нас создается каждые 3 часа.
С точки зрения конфигурации системы плэйграунд каждого из
программистов находится на той же тест-машине.
Дело в том, что на одном веб-сервере могут находиться сразу не-
сколько веб-сайтов. В нашем случае:
• www.mitya.testshop.rs —
• www.dima.testshop.rs — это адрес Диминого плэйграунда, а
• www.main.testshop.rs — это веб-сайт, на который делается
каждый из билдов.
112
Тестирование Дот Ком. Часть 1
Следовательно, тестировщики будут использовать именно
www.main.testshop.rs для своего тестирования.
Соответствующие
• директория с ЯГЖ-файлами и картинками,
• директория с приложением (Python и C++ файлы) и
• база данных
слинкованы с каждым из сайтов, так что у нас есть три конфигу-
рации, независимые друг от друга.
Кстати, важный нюанс о плэйграундах, билдах и CVS. Основное правило
для checkin: сначала сделай быстрый юнит-тест и убедись, что твои
файлы компилируются по крайней мере на твоем плэйграунде,
и уже после этого делай их "публичными" через checkin в CVS.
Рациональное объяснение: билды строятся из кода, хранимого в
CVS. Если же код не компилируется, то билд будет сломан (build
is broken) и соответственно никакого тестирования не будет.
Мы касались этого правила, говоря об идее постоянной интегра-
ции кода.
Идем дальше.
Код написан, тестирование и ремонт багов закончены. Настало
время первого релиза www.testshop.rs!!!
Первый релиз происходит так:
1. Подготовка машины у хостинг-провайдера (production
server, просто production или live machine — машина для пользо-
вателей).
Когда говорили об аренде сервера хостинг-провайдера, то име-
лось в виду, что мы арендовали совершенно конкретный компью-
тер, который находится где-то у провайдера и имеет уникальное
(в общемировом масштабе) сетевое ID, которое называется IP
Address ("ай-пи адрес"). Используя этот IP Address, мы подсое-