Исполнение тестирования и ремонт багов
Так как о тестировании мы будем говорить все остальные томные вечера, то сейчас будем лаконичны, как спартанцы.
После того как проинтегрирован код, тестировщики проводят тест приемки (smoke test, sanity test или confidence test), в процессе которого проверяются основные функциональности.
Пример
Если мы не можем погнуться (log into) в наш эккаунт (account) на www.main.testshop.rs, то о каком дальнейшем тестировании можно говорить.
Если тест приемки не пройден, то программисты и релиз-инженеры совместно работают над поиском причины. Если проблема была в коде, то код ремонтируется, интегрируется и над ним снова производится тест приемки. И так по кругу, пока тест приемки не будет пройден.
Если же тест приемки пройден, то код замораживается и тестировщики начинают тестирование новых компонентов(new feature testing), т.е. исполнение своих тест-кейсов, написанных по спекам данного релиза (более подробно о значении термина feature поговорим в беседе о системе трэкинга багов).
После того как новые функциональности протестированы, наступает очередь исполнения "старых" тест-кейсов. Этот процесс называется регрессивным тестированием(regression testing), ко-
Цикл разработки ПО
105
торое проводится для того, чтобы удостовериться, что компоненты ПО, которые работали раньше, все еще работают.
Баги заносятся в систему трэкинга багов(Bug Tracking System, далее — СТБ,о ней у нас будет отдельный разговор), программисты их ремонтируют, и затем тестировщики проверяют, насколько качественным был ремонт.
|
|
|
Допустим, мы все, что хотели и как смогли, протестировали. Программисты залатали дыры в коде, что мы тоже протестировали, и у нас есть версия нашего проекта, готовая для релиза. Эту версию мы мурыжим еще пару деньков, проводя тест сдачи (Acceptance or Certification Test), и включаем зеленый свет релиз-инженерам, чтобы они передали плод наших терзаний кликам (от англ. click) пользователей.
Релиз
Release (англ.) — "выпуск, освобождение".
Пример
Герой романа Стивена Кинга — ботаник, чудик и домосед — подвергается постоянным унижениям от одноклассников, домочадцев и случайных прохожих. В один день он вдруг говорит себе "Хватит" и начинает колоть, резать и душить подлых обидчиков, а также в превентивных целях и всех остальных. Этот выпуск пара и есть "релиз" в его обыденном понимании.
До этого мы употребляли слово "релиз" в значении "основной релиз" (так будем поступать и дальше), но у нас есть и его "родственники".
Вот полная классификация "релизообразных":
1. Релиз (он же основной релиз) (major release) — стадия в цикле разработки ПО, идущая за стадией тестирование и ремонт багов, т.е. передача пользователям кода новой версии нашего ПО. Как правило, обозначается целыми числами, например 7.0.
|
|
|
2. Дополнительный релиз (minor release) — ситуация, когда после основного релиза планово выпускается новая функциональность или изменяется/удаляется старая. Дополнительный релиз не связан в багами. Как правило, обозначается десятыми, например 7.1.
106
Тестирование Дот Ком. Часть 1
3. Заплаточный релиз (patch release), когда после обнаружения и ремонта бага выпускается исправленный код. Как правило, обозначается сотыми, например 7.11.
О чем говорит версия 12.46 нашего www.testshop.rs? А говорит она о трех вещах:
1) о том, что последний основной релиз является двенадцатым по счету;
2) о четырех дополнительных релизах, выпущенных ПОСЛЕ двенадцатого релиза;
3) о шести заплаточных релизах, выпущенных ПОСЛЕ двенадцатого релиза.
Кстати, о номерах релизов. Некоторые компании в желании пооригинальничать дают основным релизам не номера, а названия. Ну, например, имя поп-группы или отдельного исполнителя.
Звонит программисту дружок:
—Здорово, старик. Слушай, Ленка подружку приводит, так что бери шампанское и подъезжай к семи.
—Не, я пас. Я тут с "Бритни Спирс" завис. -О!..
|
|
|
Неудобство такого подхода заключается в том, что непонятно, какой релиз был раньше — "Пол Маккартни" или "Джон Леннон", и в идиотизме произнесения названий дополнительных или заплаточных релизов: звонит контрагент со своей проблемой, а ему говорят: "Да усе будет в порядке. Мы заутра патч номер 7 кДорз присобачим".
Идем дальше.
Любой из трех релизов для пользователя означает, что наш www.testshop.rs как-то изменился.
Возможные изменения:
1. Новые функциональности (основной и дополнительный релизы);
2. Изменение/удаление старых функциональностей (основной и дополнительный релизы);
3. Починка багов, пропущенных в одном из релизов любого типа (заплаточный релиз).
Организация упаковки кода в виртуальный мешок и его передача пользователю осуществляются релиз-инженерами.
Давайте представим, что ЗАО "Тест-шоп", предназначенное, кстати, для продажи книг, только начинает работу.
Цикл разработки ПО 107
Унас есть
• два программиста (Дима и Митя) и
• хозяин-барин (месье Кукушкин Илья Харитонович),
а также
• два компьютера с "Виндоуз" для программистов (здесь и далее я не буду давать версий не нашего ПО),
|
|
|
• клевый лэптоп Харитоныча (ОС значения не имеет) и
• машина с Линуксом (далее называемая тест-машина) для разработки и тестирования ПО.
Проект начинается:
1. Регистрируется домен www.testshop.rs.
2. У интернет-провайдера и по совместительству хостинг-провайдера покупается доступ в Интернет и арендуется сервер, чтобы весь мир мог зайти на огонек, увидеть и оценить.
3. Программистские компьютеры, лэптоп СЕО и тест-машина объединяются в локальную сеть с выходом в Интернет.
4. Программисты начинают работать над проектом.
Мы уже говорили о том, что классическая архитектура веб-проекта — это
• веб-сервер;
• сервер с приложением;
• база данных.
Так вот, так как мы — интернет-компания молодая, то у нас все будет по-простому: на тест-машине будут все три компонента.
Архитектура www.testshop.rs
1. Веб-сервер Apache ("апачи", имя которого идет не от названия американского племени индейцев, издревле промышлявших подработками на интернет-проектах, а от patchy (залатанный), как память о неимоверном количестве заплаток, на него приклеенных, в результате чего он приобрел белизну и пушистость).
В директориях Apache мы храним:
• файлы, содержащие HTML-код с инкорпорированным
JavaScript-кодом. JavaScript-код, вставляется в HTML.-файлы и может служить, например, для проверки е-мейла при регистрации на наличие двух @. Достоинство использования JavaScript-кода, заключается в том, что проверка осуществ-
108 Тестирование Дот Ком. Часть 1
ляется на компьютере пользователя в отличие от варианта, когда мы посылаем непроверенную форму с регистрацией на сервер с приложением, нагружая этот сервер;
• файлы-картинки(images).
2. Приложение на Python иC++. Наше приложение состоит из:
• файлов с Python-скриптами,которые можно использовать, например, для "перевода" регистрационной формы, отправленной пользователем, на язык, понятный базе данных, и для создания новой строки в таблице для новых пользователей;
• файлов сC++ кодом.Например, нам нужно вставить новое значение в определенной колонке определенной таблицы базы данных для всех пользователей, зарегистрированных у нас более 1 года. Для этой цели мы можем написать программу на C++.
Кстати, C++ файлы — это единственные файлы в нашем проекте, которые мы компилируем перед использованием: каждый из наших C++ файлов — это простой текстовый файл с кодом, написанным на C++, и, чтобы он стал исполняемым, его нужно скормить C++ компайлеру, который проверит код на наличие багов синтаксиса и, если все О'к, переведет язык, понятный человеку (C++), на язык, понятный тест-машине (нули и единицы).
3. База данных MySQL ("майсиквел"). Здесь мы будем хранить
данные
• о пользователях (например, день регистрации в системе, е-мейл, имя, фамилию и пароль);
• о транзакциях пользователя (например, когда и что купил);
• о наименованиях книг и их наличии.
Идем дальше.
Начинаются первые неудобства и проблемы, связанные с отсутствием релиз-инженерных знаний:
1. При каждом сохранении файла в той же директории нужно давать ему новое имя, чтобы не удалить старый вариант редакции.
2. При сохранении файла после редактирования нельзя прокомментировать, что было изменено.
3. Самое главное: постоянно присутствует риск, что один из программистов удалит свою работу или работу коллеги.
Цикл разработки ПО 109
Пример
а. После спецификации, пробормоченнои Харитонычем за рюмочкой
чая, программисты начинают писать код.
б. Частью кода является файл registration.py, который лежит в ди
ректории /usr/local/apache/cgi-bin/ и был написан Димой два дня
назад.
в. Дима копирует этот файл в свою директорию /home/dima и начи
нает его редактировать.
г. Одновременно с ним без всякого злого умысла этот же файл копи
рует и сохраняет в своей директории (/home/mitya) Митя и тоже на
чинает его редактировать.
д. Дима, дописав и протестировав registration.ру, переносит (move)
его обратно в /usr/local/apache/cgi-bin/.
е. Вслед за ним туда же переносит свою версию registration.ру и Митя,
в результате чего:
• в /usr/local/apache/cgi-bin/ лежит Митина редакция;
• Дима рвет на себе волосы, так как не сохранил у себя ни копии первоначального файла, ни файла с новым кодом;
• Митя рвет на себе волосы, так как в процессе разработки у него была работающая версия, но он ее не сохранил, а, решив, что другой алгоритм будет лучше, написал другую версию, которую, толком не протестировав, перенес в /usr/local/apache/cgi-bin/.
• первый релиз откладывается, так как Митина версия registration.ру абсолютно "не пашет".
осле разбора полетов принимается решение об установке CVS. VS устанавливается на тест-машину и это дает следующее:
Файлы хранятся в репозитарии (repository),
ОТКУДА
их можно взять для редактирования (checkout) и КУДА
их можно положить после редактирования (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 часа.
С точки зрения конфигурации системы плэйграунд каждого из программистов находится на той же тест-машине.
Дело в том, что на одном веб-сервере могут находиться сразу несколько веб-сайтов. В нашем случае:
• 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, мы подсоединяемся к этой машине и настраиваем
а) провайдерский Линукс (например, создаем директории,
редактируем разрешения и т.д.);
б) провайдерский Apache (например, вносим изменения в
файл конфигурации и т.д.);
в) провайдерскую MySQL (например, определяем максималь
ное количество соединений и т.д.).
Цикл разработки ПО
113
2. Подготовка релиз-скрипта(release script) — программы, которая автоматизирует процесс релиза на машину для пользователей.
3. Исполнение релиз-скрипта:
а) релиз-скрипт запускает билд-скрипт, чтобы на тест-маши
не создался новый билд;
б) релиз-скрипт берет файлы этого нового билда и по прото
колу FTP ("эф-ти-пи" — File Transfer Protocol) пересылает
их в машину для пользователей;
в) релиз-скрипт:
• копирует из CVS на машину для пользователя скрипты для базы данных (DB-scripts) и
• запускает эти скрипты.
Скрипты для базы данных создают или модифицируют схему базы данных.Так как у нас первый релиз, то схема базы данных только создается, а именно создаются три таблицы:
• user_info (для данных о пользователях);
• user_transaction (для данных о транзакциях пользователя);
• book_vault (для данных о наименованиях книг и их наличии).
Кстати, нужно различать
• схему базы данных (database, или просто DB, schema) и
• сами данные.
Схема базы данных — это совокупность виртуальных контейнеров (над БД работают программисты и администраторы БД).
Данные — это начинка этих виртуальных контейнеров, которую своими действиями на www.testshop.rs, например регистрацией, создают/изменяют пользователи (user_info и user_transaction) или другие лица (например, Харитоныч, который через специальную программу, написанную Митей, может добавить новые названия книг и их количество в book_vault).
Небольшое отступление
По мере развития проекта машина для пользователей превратится в десятки связанных между собой веб-серверов, серверов с приложением и серверов с базами данных, образующих production pool, т.е. совокупность компьютеров, обслуживающих наших пользователей. Но это будет потом. А пока...
Welcome to www.testshop.rs!!! Наш первый релиз состоялся!!!
Книги продаются, к проекту примкнули кореша Харитоныча, в результате чего появились деньги, чтобы нанять новых людей и вообще начать активно расширяться.
114
Тестирование Дот Ком. Часть 1
Над проектом уже работают 2 продюсера, 7 программистов и 1 тестировщик. Долго ли, коротко ли, а уже и второй релиз (версия 2.0) состоялся.
На следующий день после выпуска версии 2.0 лавина жалоб от пользователей дает основания полагать, что версия 2.0 www.testshop.rs так же насыщена багами, как версия-2004 Государственной думы единороссами.
Компания превращается в форпост по борьбе с последствиями релиза версии 2.0:
• месье Кукушкинносится между столами программистов и тестировщика, давая ценные указания и оперируя словарным запасом, приобретенным на раннем (колымском) этапе своей карьеры;
• программисты,которые не чинят баги версии 2.0, не могут сохранить файлы для версии 3.0 в CVS, так как в CVS решением руководства можно сохранять только код с отремонтированными багами для релиза 2.0;
• программисты,которые чинят баги, естественно, не могут работать над версией 3.0;
• тестировщикпроверяет отремонтированный код для версии 2.0 вместо подготовки к тестированию версии 3.0;
• продюсерыотвечают на е-мейлы разгневанных пользователей, которые, несмотря на биографии менее яркие, чем биография Харитоныча, тем не менее с легкостью оперируют тем же словарным запасом.
Кстати, справедливости ради стоит отметить, что по идее к версии 1.0 вернуться можно, но это займет время и чревато ошибками, так как основной объем работы будет делаться вручную. Понадобится:
• найти версии файлов в CVS на день первого релиза*,
• изменить и протестировать билд- и релиз-скрипты,
• запустить релиз-скрипты и проверить, насколько правильно они сработали.
• Если в первом релизе у нас были десятки файлов, то с течением времени
их будут сотни!!!
В таком бедламе проходит двое безвылазных суток, и наконец баги придушены, билд протестирован на тест-машине и срочно организуется патч-релиз 2.01 на машину для пользователей.
После разбора полетов Митей, как одним из старожилов компании, вносится предложение о создании бранчей (branch — ветвь)
Цикл разработки ПО
115
в CVS. Предложение принимается единогласно (тем более что отвечать в случае провала будет инициатор), и Митя рассказывает, в чем суть этого подхода.
РАССКАЗ МИТИ
'В общем так, други. Допустим, у нас есть ребенок и его фотографии нужно раз в месяц по е-мейлу посылать теще. Если присылается фотография ребенка в недовольном состоянии, то теща приезжает и устраивает дома такой шухер, как будто она попользовалась нашей версией 2.0. Соответственно нужно сохранить фотографию ребенка, когда он улыбается, и если новая фотография теще не нравится, то нужно просто послать ей старую фотографию с улыбкой и сказать, что ошибка вышла".
Харитоныч:
— Да вот я помню... (далее следует 30-минутный рассказ о его тещах с постепенным переходом к обобщениям и, наконец, декларативному изложению отношения ко всему прекрасному полу). Да-а-а, вот так-то. Что ты там говорил про версию 2.0?
ПРОДОЛЖЕНИЕ МИТИНОГО РАССКАЗА
«Да, вот. Как я и говорил о хорошем и улыбающемся билде. Вот мини-история нашего проекта со стороны релиз-инженера:
В один прекрасный день мы начали работать над кодом ПО, и по мере написания этого кода стали добавлять в CVS новые файлы ,и изменять файлы, уже существующие в ней. В определенный момент мы сказали "Стоп" и назвали совокупность файлов в CVS "версия 1.0". Затем мы продолжили работу над кодом и снова стали добавлять в CVS новые файлы и изменять файлы, существующие в ней. В определенный момент мы снова сказали "Стоп" и назвали совокупность файлов в CVS "версия 2.0". Основной проблемой, которую мы взрастили, стала мешанина, начавшаяся в тот момент, когда мы не разделили файлы версии 1.0 и версии 2.0.
Идем дальше.
Представьте себе дерево, т.е.
ствол, и
ветви, растущие из ствола.
116
Тестирование Дот Ком. Часть 1
Вот как мы должны были поступить с самого начала:
• файлы, созданные вплоть до момента релиза версии 1.0, были основой, т.е. виртуальным стволом (trunk), нашего ПО;
• из этого ствола мы могли создать виртуальную ветвь (или бранч, от англ. branch) под названием "версия 1.0", которая включала бы все файлы версии 1.0 в редакциях (версиях) на момент, когда мы сказали "Стоп " для версии 1.0. Мы говорим "Стоп" после того, как код написани готов для интеграции и тестирования;
• таким образом, у нас появились бы ствол и одна ветвь;
• программисты, пишущие код для версии 2.0, должны были модифицировать код ствола (нарисунке — пунктиром);
• и когда код версии 2.0 был бы дописан, мы создали бы еще одну ветвь и назвали ее "версия 2.0 ";
• таким образом, у нас был бы ствол, из которого сначала рос бы бранч версии 1.0 и затем бранч версии 2.0;
• начиная работать над кодом релиза версии 3.0, мы снова работаем со стволом (на рисунке — пунктиром);
• и т.д.
Цикл разработки ПО
117
Таким образом, код каждой версии живет в CVS в виде отдельного бранча или ствола.
Кстати, есть множество нюансов, например слияние бранча и ствола, и ситуации, когда бранч сам становится стволом с ветвями и прочее, но я не буду вас этим загружать. Сейчас мне нуж-<:но, чтобы вы поняли главное.
Теперь вернемся к нашим баранам. Что сделано — то сделано. Сейчас в CVS y нас есть
• весь код версии 1.0;
• весь код версии 2.0;
• часть кода версии 3.0.
Пусть все это содержимое CVS будет нашим стволом. Я берусь найти совокупность файлов с редакциями, которые были у нас на момент релиза 2.0, и обратным числом создать из них бранч 2.0, чтобы в случае фиаско с версией 3.0 мы могли быстро вернуться к коду версии 2.0 и вообще начали хорошую традицию создания бранчей».
Выслушав Митю и мысленно поаплодировав ему, разберемся, что даст реализация Митиного предложения:
Во-первых,мы всегда сможем вернуться к предыдущей версии, если новая версия окажется некачественной.
Во-вторых,программисты
• смогут работать одновременно над различными версиями, например ремонтировать баги для 2.0 (бранч 2.0) и писать код для 3.0 (ствол) и
• результаты их работынад каждой из версий будут в CVS отделены друг от друга.
Вэтом случае www.main.testshop.rs будет веб-сайтом с кодом для 3.0 и вообще площадкой для билдов каждого нового релиза, а, скажем, www.old.testshop.rs будет веб-сайтом с кодом для 2.0 и вообще площадкой с кодом каждого предыдущего релиза.
В-третьих,мы сможем руководить состоянием бранчей.
У бранча есть три состояния:
1) открытый,т.е. в нем можно сохранять файлы;
2) условно открытый,в нем можно сохранять файлы, НО при определенном условии, например, программист дол-
118 Тестирование Дот Ком. Часть 1
жен написать номер реального бага в комментарии при сохранении файла; 3) закрытый.В этом случае файл может быть сохранен в соответствии с процедурой о неотложном ремонте багов (о процедуре через минуту).
Кстати, когда мы говорили о замораживании спеков, используя CVS, нужно понимать, что бранчи, в которых сохраняются спеки, не имеют никакой связи с бранчами, в которых сохраняется код. Как правило, это даже две CVS, установленные на двух разных машинах, но если даже используется одна и та же CVS на одной и той же машине, то бранчи для спеков и бранчи для кода — это как два сына одной женщины (т.е. CVS), один из которых мочит одноклассников в сортирах, а другой в это время читает Артура Шопенгауэра.
Кстати, часто возникает ситуация, когда программист сохранил код в бранче для патч-релиза и забыл сохранить исправленный код в стволе, т.е. в коде, из которого будет сделан бранч для следующего релиза. Таким образом, может получиться ситуация, когда баг, патч для которого уже был выпущен на машину для пользователей в предыдущем релизе, вновь появляется в следующем релизе. Чтобы избежать таких казусов, тестировщики придерживаются железного правила: на каждый баг, для которого был произведен патч-релиз, должен быть написан тест-кейс приоритета 1. Этот тест-кейс добавляется к группе тест-кейсов для регрессивного тестирования соответствующей функциональности.
Совместим наш цикл разработки ПО с открытостью бранчей.
1. Во время стадии кодирование, например, для версии 3.0 бранч с версией 3.0 является открытым.
2. Во время стадии тестирование и ремонт багов бранч является условно закрытым — никакой код не может сохраняться в таком бранче, за исключением кода с починкой для конкретного бага, при сохранении кода в CVS программист обязануказать номер открытого бага в СТБ, иначе CVS не разрешит checkin. Именно такой статус у бранча после заморозки кода и передачи кода тестировщикам.
3. После того как произошел релиз на машину для пользователей и в этом релизе найден баг, у нас есть два варианта:
а) если баг некритический (например, отсутствует проверка
е-мейла пользователя на два "@"), то его можно отре
монтировать в следующем релизе, т.е. мы фиксируем код
только в стволе;
б) если баг критический (например, невозможно совершить
покупку), то нужно отремонтировать его и выпустить патч-
Цикл разработки ПО
119
релиз как можно быстрее. Для такого срочного ремонта нужен формальный документ: процедура о неотложном ремонте багов(Emergency Bug Fix Procedure).
Кстати, не хочу вас путать, но есть одна важная для понимания вещь: иногда нужно незамедлительно изменить код приложения на машине для пользователей, и это изменение не связано с багами. В таком случае тоже заносится запись в СТБ, но с типом "Feature Request" — запрос о новой функциональности (подробнее об этом в разговоре о СТБ), и релиз такого кода регулируется этой же процедурой.
Примером, в котором нужен быстрый, не связанный с багами релиз, может послужить ситуация, когда у нас есть решение суда (например, о нарушении патента), которое обязывает срочно изменить код.
Релиз такого кода также называется патч-релизом.
Вопрос:В чем отличие такого патч-релиза от дополнительного релиза?
Ответ:В том, что дополнительный релиз — это плановый релиз, когда было заранее решено, что такие-то функциональности увидят свет, но включены они будут не в основной, а в дополнительный релиз.
Процедура о неотложном ремонте баговдолжна содержать:
• приоритет багов, которые подлежат НРБ. Например, это могут быть только П1 баги;
• список лиц, имеющих право инициировать процесс НРБ;
• последовательность действий между лицами, участвующими в НРБ, например:
1) программист, извещенный о проблеме, фиксирует баг;
2) исправление кода заверяется одним из его коллег через рассмотрение кода (code review);
3) релиз-инженер делает билд для регрессивного тестирования;
4) тестировщик производит тестирование;
5) релиз-инженер делает патч-релиз на машину для пользователей;
• коммуникацию между лицами, участвующими в НРБ. На
пример, в начале и конце каждого из этапов ответственное
лицо отвечает всем на последний е-мейл этой цепочки.
Причем в начале этапа посылается е-мейл типа "Начал де
лать билд для регрессивного тестирования. Примерный
120
Тестирование Дот Ком. Часть 1
срок до завершения операции — 30 минут". В конце этапа посылается е-мейл типа "Билд для регрессивного тестирования завершен. Тестировщики. Ау!".
Во многих компаниях для быстрого и эффективного исправления проблем после основного релиза по примеру полицейских создаются SWAT-команды (Special Weapons and Tactics teams — подразделения оперативного реагирования), по минимуму состоящие из продюсера, программиста, релиз-инженера и тестировщика. Допустим, у нас есть четыре такие команды. Для каждой их них устанавливается расписание на каждый день (по шесть часов каждая) на 10 дней после релиза, так чтобы по звонку в любое время дня и ночи головорезы соответствующего подразделения были готовы сорваться, приехать в офис и сидеть до посинения, пока патч-релиз не вылетит на машину для пользователей.
Дата добавления: 2018-05-02; просмотров: 1714; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!