|
|
Роман Савин - тест dot com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
Пример
Допустим, что на интранете у нас есть два внутренних тестировочных
веб-сайта, недоступных для пользователей:
• 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, cppsyntax_error.cpp:5: unterminated string or character constantsyntaxerror.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 Тестирование Дот Ком. Часть 18.9. //get first number10. 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.rs1. Веб-сервер 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. |
|
|
Скачать 5.26 Mb.