Текст книги "tестирование dot com"

Автор книги: Роман Савин

сообщить о нарушении

Текущая страница: 6 (всего у книги 17 страниц)

программистах), тем добросовестнее они будут работать, тем

меньше будут получать втыков от жен – любительниц Louis

Vuitton и тем больше будут радеть за свое место и качество кода,

включая разработку дополнительных (от себя) юнит-тестов.

В общем нужно сделать так, чтобы профессионал не думал о

том, как свести концы с концами, а работал, зная, что его

труд будет достойно оценен, и видел, что компания заботится

о нем.

9. НАЛИЧИЕ ПОНЯТИЙ «КАЧЕСТВО» И "СЧАСТЬЕ

ПОЛЬЗОВАТЕЛЯ" КАК ОСНОВНЫХ СОСТАВЛЯЮЩИХ

КОРПОРАТИВНОЙ ФИЛОСОФИИ

Менеджмент должен сделать так, чтобы персонал понимал, что

"качество" и "счастье пользователя" – это не фикция, а путь к

финансовому успеху компании и соответственно лучшей жизни

каждого, кто работает над проектом. Если менеджеры по-

смеиваются над мерами по улучшению качества и отпускают

шутки о пользователях (даже в курилке!), то это тлетворно

действует на всех сотрудников компании и в конечном счете

негативно скажется на пользователях, а следовательно, по

принципу бумеранга и на самой компании, включая

«юмористов».

Пользователи знают, уважают их или нет, уже после одного

сообщения об ошибке, одного е-мейла от компании или од-

ного звонка в службу поддержки, и если философия компа-

нии – это «тупые юзеры», то, поверьте, она проявится, на

радость конкурентам, во многих вещах.

Теперь поговорим о трех основных занятиях программиста:

1. Написание кода для данного релиза происходит во время

стадии "Кодирование".

2. Интеграция кода для данного релиза происходит по за-

вершении стадии "Кодирование".

3. Ремонт багов для данного релиза происходит во время

стадии "Кодирование" следующего витка цикла разработ-

ки ПО (соответственно в пункте 1 программист ремонти-

ровал баги для предыдущего релиза).

Цикл разработки ПО

97

Техническая версия

1. НАПИСАНИЕ КОДА

Один программист написал: parent_value = 1. Другой програм-

мист написал: child_value = parent_valu + 3.

2. ИНТЕГРАЦИЯ КОДА

а. Пытаемся два куска кода соединить в один:

parent_value = 1,

child_value = parent_valu + 3.

б. Код не компилируется (компайлер выдает ошибку о неоп

ределенной переменной), так как второй программист на

писал parent valu вместо parent value.

в. Код второго программиста фиксируется:

child_value —parent_value + 3.

г. Пытаемся два куска кода соединить в один:

parent_value = 1,

child_value = parent_value + 3.

д. Код компилируется, но первый программист выполняет

юнит-тест, по которому parent_yalue должно быть равно 7.

е. Код первого программиста фиксируется:

parent_value – 1.

ж. Пытаемся два куска кода соединить в один:

parent_value = 7,

child_value = parent_value + 3.

з. Вроде все в порядке, передаем тестировщикам – пусть

они тра... маются.

3. РЕМОНТ БАГОВ

Согласно спецификации должно быть:

child_value – parent_yalue x 3.

Тестировщик рапортует баг, и на основании этого бага програм-

мист меняет код.

98

Тестирование Дот Ком. Часть 1

Лирическая версия

1. НАПИСАНИЕ КОДА

О написании кода мы уже говорили. Один момент:

Качество работы программиста не должно оцениваться по коли-

честву багов, которые он взрастил, так как помимо таких субъек-

тивных вещей, как профессионализм и добросовестность, на на-

личие багов влияет множество других объективных факторов, о

которых мы упоминали (нехватка времени, плохие спеки и т.д.).

2. ИНТЕГРАЦИЯ КОДА

Вариант 1. Неблагодарный

После того как код написан на игровой площадке каждого из

программистов, происходит интеграция кода, когда тысячи строк

кода разных авторов компилируются на одном компьютере, на-

езжают друг на друга, спотыкаются, огрызаются и дарят релиз-

инженерам, производящим интеграцию, сомнения в принципи-

альном наличии вселенской гармонии.

Пример

Собрали четырех отличных художников, причем каждый должен выпол-

нить заказ на куске прозрачной пленки 50x50 см:

• задание первому: нарисовать удрученного, стоящего на коленях

молодого человека;

• задание второму: нарисовать милостиво склонившегося старика;

• задание третьему: нарисовать фон, вызывающий сострадание;

• задание четвертому: нарисовать группу печальных людей.

"В общем, парни, генеральная идея... эта... типа как у этого... О! У Рем-

браНа: возвращение загулявшего сына".

Неудивительно, что мы прочувствуем всю боль релиз-инженеров, ко-

гда соединим четыре рисунка вместе и увидим

• удрученного великана, стоящего на коленях над

• стариком,

• гладящим промокшую болонку

• в окружении заспанных курсантов-суворовцев.

Остается только редактировать картинки каждого из художников и гру-

стить, что их не совмещали по мере написания, используя...

Вариант 2. Благодарный

Чтобы избежать проблем, когда в один момент происходит мас-

сированная интеграция кодов разных авторов, как в Варианте 1,

программисты производят интеграцию постоянно по мере напи-

Цикл разработки ПО

99

сания нового кода (т.е. стадия 1 и стадия 2 цикла разработки кода

сливаются в одну стадию), что дает возможность выявить несты-

ковки между кодами разных авторов на раннем этапе.

3. РЕМОНТ БАГОВ...

происходит во время стадии "Тестирование и ремонт багов", по-

сле того как код для данного релиза был заморожен и програм-

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

Необходимость в замораживании кода вызвана тем, что продукт

(в данном случае код) должен быть в каком-то устойчивом виде,

чтобы его проверили.

Пример

Представьте следующую ситуацию:

1. Программист закончил работу над функциональностью А;

2. Тестировщик проверил, что функциональность А работает, и дал

добро на релиз;

3. За час до релиза программист вносит маленькое изменение в код,

которое в теории ничего не ломает...

а на практике приводит к тому, что функциональность В, связанная с А,

абсолютно перестает работать, т.е. получилось так, что тестировщик

попросту потерял время (а значит, и деньги компании), тестируя не

финальную версию продукта.

Из сказанного вытекают две принципиально важные для тести-

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

• код заморожен (обычно релиз-инженеры посылают соот-

ветствующий е-мейл);

• версия продукта на внутреннем сайте, на котором вы будете

производить тестирование, является именно той версией,

которую вам нужно протестировать.

Пример

Допустим, что на интранете у нас есть два внутренних тестировочных

веб-сайта, недоступных для пользователей:

• www.everest.testshop.rs и

• www.elbrus.testshop.rs

Допустим также, что сайт

• www.everest.testshop.rs(по-простомуназываемый «Эверест») является

версией 1.0 и содержит функциональность А версии 1.0, а

• www.elbrus.testshop.rs(по-простомуназываемый «Эльбрус») является

версией 2.0 и содержит функциональность А версии 2.0.

100

Тестирование Дот Ком. Часть 1

Так вот в окне веб-браузера функциональность А может выглядеть аб-

солютно одинаково и на Эвересте, и на Эльбрусе, но ее бэк-энд будет

существенно различаться на этих двух сайтах.

Допустим, тестировщик собирается проверить функциональность А

версии 2.0, но ошибочно использует для тестирования Эверест (с вер-

сией 1.0), вследствие чего он не только впустую тратит время, но

и рискует дать добро на релиз непротестированного кода функцио-

нальности А версии 2.0.

Подобные ошибки возникают, как правило, по небрежности или

незнанию тестировщика и из-за "нелогичных" названий внутрен-

них веб-сайтов.

Пути предотвращения ситуации, когда тестировщик тестирует не

ту версию ПО:

1. Узнайте у релиз-инженера, как определить версию кода, и

используйте сие знание перед началом исполнения тести-

рования;

2. Посоветуйте, чтобы внутренние веб-сайты имели логич-

ные имена. Например, версия кода, переданного пользова-

телю, всегда должна быть на внутреннем сайте по адресу

www.old.testshop.rs, а версия для следующего релиза – на

www.main.testshop.rs;

3. Попросите релиз-инженеров, чтобы те создали на интра-

нете динамически обновляемую страничку с информацией

о

• версии и

• подверсии, т.е. билде (об этом позже),

каждого внутреннего тестировочного веб-сайта.

В завершение кодирования поговорим еще о паре вещей.

Хотя и спеки, а иногда даже и сами идеи для спеков – ребятки

не без греха, большинство багов зачинается именно при написа-

нии кода. При кодировании появляется присущий только этой

стадии и одновременно самый простой в нахождении вид бага —

синтаксический баг (syntax bug).

Прелесть синтаксических багов заключается в том, что они, явля-

ясь ошибками в языке программирования, находятся компай-

лером (например, в случае с C++) автоматически. Последний

выдает на экран сообщение об ошибке и принципиально не соз-

Цикл разработки ПО

101

дает исполняемый файл, пока проблема не будет зафиксирована

(в скриптовых языках, таких, как Python, исполняемым файлом

является сам файл с кодом и синтаксические баги находит интер-

претатор языка).

Пример

Вот первая программка любого изучающего C++:

1. #include 2.

3. voidmain()

4. {

5. cout<< "Hello, World!<< endl;

6. }

Текст этой программки находится в файле syntax_error.cpp. По-

пробуем ее скомпилировать:

~> C++ syntax error, cpp

syntax_error.cpp:5: unterminated string or character constant

syntaxerror.cpp: 5: possible real start of unterminated constant

Последние две строчки – это текст об ошибке, выданный ком-

пайлером из-за того, что мы не закрыли кавычки в строке 5 после

World! Никакого исполняемого файла создано не было. Если мы

исправим эту ошибку, то файл без проблем скомпилируется.

Тестировщики обязаны устройству Вселенной за то, что есть ло-

гические баги (logical bugs). Эти баги, как следует из их назва-

ния, – это ошибки в логике кода, т.е. код компилируется без син-

таксических ошибок, но фактический результат исполнения этого

кода не соответствует ожидаемому результату.

Пример

Спецификация:

"7.2. Пользователь должен ввести два целых числа от 1 до 12,

после чего программа выведет на экран их среднее арифмети-

ческое".

Код:

1. #include 2.

3. voidmain()

4. {

5. int first number = 0;

6. int secondjnumber = 0;

7. float average = 0.0;

102

Тестирование Дот Ком. Часть 1

8.

9. //get first number

10. cout« „Enter first number:“;

11. cin » first_n umber;

12.

13.

14. //get second number

15. cout« „Enter second number:“;

16. cin » second number; 17.

18. //calculate average

19. average = firstjiumber+second_number/2.0; 20.

21. //output result

22. cout« "Average = "« average « endl; 23.

24. }

Тестирование:

Enter first number: 9 Enter

second number: 2 Average

=10

Согласно спецификации результатом исполнения программы

должно быть среднее арифметическое двух чисел, т.е. в нашем

случае 5,5 (ожидаемый результат). Фактический же результат

оказался равен 10.

5,5 не равно 10, соответственно у нас есть логический баг.

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

(были пропущены скобки):

19. average = (first_number+second_number)/2.0.

Кстати, в приведенном пункте спека есть баг, так как непонятно, какое

максимально допустимое целое число: 11 или 12? Программист, увидев

этот баг, должен был сделать уточнение у продюсера и обязать того

исправить спек. Если максимальное число = 12, то точная формулировка

должна быть следующей: "7.2. Пользователь должен ввести два целых

числа от 1 до 12 включительно, после чего программа выведет на экран

их среднее арифметическое".

Кстати, программист заложил в коде еще один логический баг, так как

согласно спеку код должен принять только действительный ввод, кото-

рым являются целые числа 1 – 1 1 (или 1 – 12).

Кстати, спек имеет еще один баг: не сказано, как должна отреагировать

программа, если пользователь введет недействительный ввод, например

0, 13, "А", "#" или пустое место...

Цикл разработки ПО

103

Две последние вещи в разговоре о стадии кодирования.

Первая вещь

Как мы помним, на этой стадии тестировщики пишут тест-кейсы.

Так вот тест-комплекты необходимо, как и спеки, хранить в CVS

и публиковать линки к ним на интранете для предоставления

возможности свободного ознакомления с ними любому заинтере-

сованному лицу внутри компании. Главные преимущества хране-

ния тест-кейсов в CVS:

• отсутствие возможности случайного удаления файла;

• присутствие возможности возвратиться к предыдущим вер-

сиям файла;

• файл хранится на сервере, и каждый, кому нужно (и кто

имеет право), может взять его для исполнения тестирова-

ния, изменения и удаления существующих или включения

дополнительных тест-кейсов.

Вторая вещь

Хорошая идея для компании в целом и для интересов самого

тестировщика – это провести рассмотрение тест-кейсов (Test-

case Review), когда за несколько дней до начала тестирования со-

бираются

• продюсер, написавший спек,

• программист, написавший по спеку код и

• тестировщик, написавший по спеку тест-кейсы.

Тестировщик раздает присутствующим распечатки этих тест-кей-

сов и подробно рассказывает, как он будет проверять функцио-

нальности, описанные в спеке.

Полезность рассмотрения тест-кейсов заключается в том, что

во многих случаях продюсеры и программисты дают новые

идеи для тестирования и/или корректируют допущенные не-

точности.

Политический момент

Если участники митинга

• не предложили внести в тест-кейсы ничего нового либо

• предложили и вы внесли,

то это формально означает, что они одобрили то, как будет протести-

рован код. А так как все протестировать невозможно и всегда есть веро-

ятность, что мы не проверим какой-либо багосодержащий сценарий,

104

Тестирование Дот Ком. Часть 1

то даже в случае пропущенного бага все будут знать, что вы сделали

все возможное для качественной подготовки к тестированию, т.е. соз-

дали тест-кейсы и получили одобрение их эффективности.

Кстати, после рассмотрения тест-кейсов пошлите е-мейл всем

присутствовавшим на совещании. Перечислите в этом е-мейле все

модификации к тест-кейсам, о которых вы договорились на совеща-

нии. Таким образом, с одной стороны, вы составите памятку для са-

мого себя, а с другой – дадите себе возможность удостовериться (пу-

тем получения ответов на е-мейл), что вы учли все предложенные вам

вещи по модификации тест-кейсов и учли эти вещи правильно. Отсут-

ствие ответа на подобный е-мейл – это знак согласия.

Во многих крупных интернет-компаниях рассмотрение тест-кей-

сов – это обязательная процедура перед переходом к стадии...

Исполнение тестирования и ремонт багов

Так как о тестировании мы будем говорить все остальные томные

вечера, то сейчас будем лаконичны, как спартанцы.

После того как проинтегрирован код, тестировщики проводят

тест приемки (smoke test, sanity test или confidence test), в процессе

которого проверяются основные функциональности.

Пример

Если мы не можем погнуться (log into) в наш эккаунт (account) на

www.main.testshop.rs, то о каком дальнейшем тестировании можно

говорить.

Если тест приемки не пройден, то программисты и релиз-инже-

неры совместно работают над поиском причины. Если проблема

была в коде, то код ремонтируется, интегрируется и над ним сно-

ва производится тест приемки. И так по кругу, пока тест приемки

не будет пройден.

Если же тест приемки пройден, то код замораживается и тести-

ровщики начинают тестирование новых компонентов (new fea-

ture testing), т.е. исполнение своих тест-кейсов, написанных по

спекам данного релиза (более подробно о значении термина fea-

ture поговорим в беседе о системе трэкинга багов).

После того как новые функциональности протестированы, насту-

пает очередь исполнения "старых" тест-кейсов. Этот процесс на-

зывается регрессивным тестированием (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/.

• первый релиз откладывается, так как Митина версия registra-

tion.ру абсолютно «не пашет».

осле разбора полетов принимается решение об установке 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