This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Управление тестированием Интервью с Ильей Альшанетским FAQ: Как помочь в развитии PHP?
издается с февраля 2004 года, www.phpinside.ru
PHP Inside №14
Содержание В фокусе Исправление ошибок: в нужное время и в нужном месте. Часть I............................................3 Исправление ошибок: в нужное время и в нужном месте. Часть II ........................................10 Функциональное тестирование при помощи Selenium.............................................................16 Люди Интервью с Ильей Альшанетским..............................................................................................37 FAQ: Как принять участие в развитие PHP?..............................................................................41 Идеи Библиотека dbtree для работы с деревьями Nested Sets............................................................48 Введение в разработку веб-приложений с Ajax........................................................................ 59 Множественное наследование в ОО модели PHP..................................................................... 64
От редактора В первом осеннем выпуске PHP Inside мы затронем много различных тем. Темой номера "В Фокусе" является "Управление тестированием" и в рамках темы представлена статья об управлении ошибками, а так же, Сергей Юдин расскажет об инструменте тестирования веб-приложений "Selenium". Еще одним интересным моментом этого номера стало интервью с Ильей Альшанетским - активным разработчиком PHP и некоторых проектов, таких как FUDforum и eGroupware. В интервью он поведал нам о своем опыте работы релиз-менеджером PHP и рассказал о "кухне" выпусков новых релизов этого языка. Так же мы не смогли пройти мимо материалов, посвященных интересным и полезным технологиям и алгоритмам: Ajax и Nested Sets. Для сторонников Nested Sets мы публикуем пример работы с классом dbtree, написанный автором самого класса - Кузьмой Феськовым. Dbtree получает признание за рубежом (Мануель Лемос, ведущий проекта phpclasses.org сыграл в этом не последнюю роль) и теперь пришло время познакомить и наших соотечественников (тех кто еще не успел) с этим действительно мощным инструментом управления иерархическими структурами в PHP. И в завершении, Денис Баженов в статье "Множественное наследование в ОО модели PHP" рассказал о своих идеях реализации множественного наследования.
Команда номера
Авторы и переводчики Кузьма Феськов Андрей Олищук Сергей Юдин Денис Баженов Антон Довгаль Алексей Борзов Александр Войцеховский Григорий Федоринов
Редакционная коллегия Александр Смирнов Александр Войцеховский Андрей Олищук [nw] Антон Чаплыгин Елена Тесля
Выпуск номера Андрей Олищук [nw] Денис Зенькович Антон Чаплыгин Андрей Махнач Денис Бесков-Доронин
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть I
В фокусе Исправление ошибок: в нужное время и в нужном месте. Часть I Автор: Scott Berkun Перевод: Андрей Олищук Управление ошибками – это целая наука, азы которой преподает Скотт Беркун, автор книги по управлению проектами В работе с ошибками есть одно золотое правило: исправлять ошибки нужно в том порядке, который вероятнее всего приближает к успеху. Звучит банально, не правда ли? Неправда. Могу поспорить, что свыше половины «глючных» и ненадёжных программ, которые вам приходилось использовать, были такими не потому, что разработчикам не хватило времени сделать их лучше. Просто они исправляли не те ошибки. Желание исправить «нужные» ошибки и знание того, каким образом это сделать, -две разные вещи. При попытке продуманного подхода к работе с ошибками возникает две основные трудности: первая - необходимо знать, как принять правильное решение по поводу исправления той или иной ошибки, вторая - создание и поддержание рабочего процесса, который обеспечивал бы реализацию этих решений даже в условиях "дедлайна". Опытные лидеры и команды знают, что усталость непременно накапливается к концу проекта, этапа или итерации. Им наверняка придётся меньше спать, больше работать и в жутких количествах поглощать кафеиносодержащие продукты. Думая загодя, умные лидеры вводят в действие простые правила и создают неприкосновенные запасы ресурсов на ранних стадиях, и когда становится очень трудно, у таких лидеров всегда находятся резервы для принятия правильных решений. Это эссе, состоящее из двух частей, является своеобразным учебником для использования таких правил и неприкосновенных запасов. Даже больше — я поделюсь с вами идеями, на основании которых вы сможете создавать свои собственные правила. Мои рекомендации состоят из четырех уровней — от отрывочных советов по оказанию "первой помощи" (Уровень 1) до крупномасштабного планирования (Уровень 4). Но перед тем как начать, рассмотрим список неправильных подходов, которых следует избегать при принятии решений о правке ошибок. 3
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть I
Вот десять худших способов принятия решений: 1. Править только те ошибки, которые раздражают вашего директора; 2.
Править все ошибки (никогда не успеете);
3. Не править ошибок вовсе (зато успеете сдать систему уже сегодня!); 4. Править только те ошибки, которые раздражают жену/дочь/хомяка вашего босса; 5. Требовать согласования каждого решения самым надоедливым и недалёким человеком в вашей организации (возможно, пересекается с подходом №1); 6. Начать править случайно выбранную ошибку и, остановившись на полпути, перейти к другой. По завершению повторить; 7. Бояться ошибок. Не править их и свалить все на когонибудь другого; 8. Расставить ошибки в алфавитном порядке и править их от А до Я, исключая гласные. При соответствующем подходе к именованию ошибок этот подход может превратиться в №3; 9. Создать сложную избирательную систему представителей, выбираемых двумя третями большинства для написания проекта регламента по формированию трёх двусторонних комитетов, наделённых полномочиями по модерированию будущих дисскуссий на тему стратегического управления ошибками; 10. Тратить все имеющееся время на споры о том, похож ли ваш текущий подход на что либо из только что приведённого списка. Будем надеятся, что вы не сталкивались с описанным выше подходами на практике. Теперь, когда вы предупреждены, будет легче избежать неправильных решений в будущем. Как только ваш менеджер предложит нечто подобное, то пожалуйста встаньте, тихо повернитесь и бегите изо всех сил.
1. Первая помощь В лучших веб-мастерских и программистских цехах процесс управления исправления ошибок очень напоминает медицинскую очередность оказания помощи. Кто-нибудь берёт на себя основную роль по просмотру всех поступающих ошибок и раскладыванию их на три или четыре кучи. Это называется сортировкой, разбором ошибок или управлением дефектами. Как и в случае с любыми другими вещами, которые у вас возможно есть, например CD-дисками, книгами, долгами, подружками, — с ошибками лучше всего справляться, объединяя их в высокоуровневые группы. Таким образом становится легче понять ситуацию, обсудить ее с другими и найти подходящего квалифицированного "врача".
4
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть I
Это универсальное правило — гораздо проще работать с тремя-четырьмя группами, чем с сотнями или тысячами отдельных вещей. Поэтому, если ошибки ставят весь проект вверх дном, то первым делом необходимо отказаться от всех действий, сесть и начать сортировку по степеням важности. Тест: если вы не помните, когда в последний раз занимались разборкой ошибок, то остановитесь и немедленно приступите к разбору. Вы не можете просто взмахнуть волшебной палочкой над базой ошибок, чтобы они самостоятельно упорядочились. Здесь нужен смельчак (вроде вас), который не побоится грязной работы, засучит рукава и отсортирует их. Можете мне поверить — иначе не получится. Если вы достаточно дисциплинированы, то сможете проводить разборку регулярно, ежедневно в течение всего хода проекта, не позволяя ситуации ни на минуту выйти из-под контроля. Как вариант - вы можете попытаться мотивировать своих программистов систематически разбирать собственные ошибки. Это здорово, но какой бы подход не применялся, дело должно быть сделано. Прежде чем вы пропустите эти строки со словами «Я знаю о сортировке, но не делаю её по такой-то и такой-то причине», учтите, что сортировка необходима для оздоровления в процессе оказания первой помощи в любом из смыслов — медицинском или техническом. Нет смысла лепить лейкопластырь на коленку больного, если у него из спины торчит полдюжины отравленных стрел. Без сортировки вы не будете точно знать, на что потратить энергию команды наилучшим образом. В отличие от пациента, исступленными жестами привлекающего ваше внимание к своей спине с незваными стрелами, ваша база кода не скажет, где у нее болит больше всего. Вам нужно определить это самостоятельно. Усилия по сортировке важности ошибок имеют еще и несколько полезных последствий. Разбираясь с ошибками, лидер вынуждает всех улучшать своё видение проекта вцелом. Он обнаруживает множество дублирующихся ошибок, уже исправленные ошибки, нехватку данных (которые нужно отправить на уточнение тестерам), ошибки, которыми можно пренебречь, и даже нечто нелепое, вроде жалобы на то, что веб-сайт не предсказывает номера выигрышных лотерейных билетов. Практика показывает, что после первой сортировки количество ошибок обычно уменьшается на 30 процентов, что, конечно же, здорово прибавляет настроения. Однако вам не удастся так легко добиться цели без выполнения всей работы.
Очень простая сортировка Если говорить о принципах классификации ошибок, то существует бесчисленное множество способов организовать сортировку ошибок. Каждый IT-ветеран имеет свое собственное мнение на этот счет. Как всегда, здесь нет единственно правильного решения. Используйте простые подходы и в следующий раз совершенствуйте их, основываясь на полученном опыте.
5
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть I
Согласно простейшей схеме, все ошибки можно разделить на три группы: “необходимо исправить”, “надо бы исправить”, “не нужно исправлять”. Перебирая ошибки, относите их к одной из этих категорий. При этом чем больше ошибок будет отнесено в «надо бы исправить» и «не нужно исправлять», тем более эффективной будет сортировка, поскольку эти группы представляют собой чёткие решения. Чего вам точно не нужно - так это чтобы 99 процентов ваших ошибок попадало в «необходимо исправить». Такой подход к сортировке называется «трусливым». Если все ошибки нужно исправить, то это равносильно тому, что они равнозначны, но это бессмысленно. Иными словами, вы просто сбежали от решения проблемы. Запомните золотое правило: чтобы добиться успеха, расставьте ошибки в порядке их приоритета. Если приоритет у всех ошибок один, значит, нет порядка и, следовательно, нет успеха. Сортируя ошибки, стремитесь к тому, чтобы 50 процентов попало в «необходимо исправить», а все остальное в «надо бы исправить» и «не нужно править». Затем остановитесь и серьезно взгляните на ошибки. Оцените оставшиеся ресурсы (время и людей) и решите, что наиболее важно для проекта (заказчиков и бизнеса). В конце проекта нет задачи важнее, чем активное и упреждающее управление ошибками и обработка проблемных ситуаций. Стремитесь к 50 процентам «необходимо исправить» и жмите, пока есть силы. И только когда дальнейшее сжимание станет действительно невозможным, знайте: вы провели настоящую сортировку. Врачи первой помощи не выбрасывают белый флаг и не просят таймаутов, когда им приходится выбирать, кого из пострадавших спасать в первую очередь. Если они могут делать ТАКОЙ выбор ради человеческих жизней, то уж вы точно справитесь с расстановкой приоритетов для ошибок. Не прячьтесь за невежеством «трусливой сортировки» — будьте тверды, упрямы и ведите свою команду вперед!
Правила очень простой сортировки Вот основные правила для трех групп ошибок: 1. Если ошибку «должны исправить», то это означает, что она важнее любой ошибки из группы «надо бы исправить» и «не будем править»; 2. Если ошибку «надо бы исправить», значит, она менее важна, чем любая из группы «должны исправить», и более важна, чем из группы «не будем править». 3. Если ошибку «не будем править», значит, она менее важна, чем любая другая ошибка в категории «надо бы исправить». Несомненно, все решения по поводу правки ошибок являются относительными. Здесь нет абсолютов. Определение степени важности включает много факторов, и отнести ошибку к той или иной группе может быть очень сложно.
6
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть I
Сообразительные команды создают четко определенные маркеры (критерии), которые помогают выработать правильное решение (мы вернемся к этим критериям во второй части). Не переживайте, что у вас будет много спорных моментов. Я гарантирую, что вызывать споры о правильности размещения будет минимальное количество ошибок в каждой группе. Сфокусируйте коллектив на позитивном, на тех ошибках, с важностью которых все согласны. Если наберется 50 таких ошибок, то пройдет несколько рабочих дней или недель до тех пор, пока возникнет необходимость вернуться к дебатам по поводу оставшихся. Группа ошибок «должны исправить» — вот над чем нужно работать программистам. Они ничего не должны трогать в «надо бы исправить», за исключением тех случаев, когда они помогают с сортировкой. Смысл прост: не трогай того, что может понадобиться, до тех пор, пока это не понадобится на самом деле. Другими словами — не беспокойся о десерте, если еще не ясно, что будет на обед. Всегда будет возникать соблазн прихватить ошибок для исправления из группы «надо бы исправить». Никоим образом нельзя отступаться от принятых ранее решений, даже если среди отодвинутых на второй план есть ошибки, которые раздражают всю команду, портят любимый функционал или просто очень интересны для исправления. Приоритеты должны стать самой главной вещью для проекта и заказчика. Приверженность команды целям проекта, а не другим желаниям — это и есть разница между качественными и низкопробными проектами.
Когда сортировать Зачастую бывает достаточно еженедельных сортировок. В понедельник утром, когда ваша команда немного отдохнула, сортируйте ошибки и получайте план наилучшего использования вашей команды на всю предстоящую неделю. Ошибки из группы «должны исправить» должны преподноситься команде с умом — вне зависимости от того, выбирают ли программисты работу самостоятельно или у них есть очерченные области задач. Если группа «должны исправить» слишком велика, то разделите ее на две подгруппы «сделать на этой неделе» и «сделать до конца проекта». В зависимости от поступления новых ошибок и внесений изменений заказчиками и менеджерами вам может понадобиться большая частота проведения сессий сортировки.
Уровень 2. Более детальная сортировка За исключением тех случаев, когда вы правите ошибки по мере их поступления (хорошая, но на удивление редко применяемая стратегия), обычно все решения касательно ошибок принимаются уже в самом конце, когда наиболее велико давление сроков. Следовательно, вам необходимо иметь сведения по каждой ошибке в достаточном количестве, чтобы принять правильное решение быстро. Если вы тратите половину своего времени на то, чтобы воспроизвести ошибку или даже просто понять ее суть, значит, вы уже теряете даром драгоценное время.
7
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть I
Качественные описания ошибок и ситуаций, при которых они возникали, могли быть сделаны еще несколько дней или недель раньше. Все, что вам для этого нужно, — большая база ошибок, которая переливается всеми цветами радуги, хорошо организованный кабинет, а не населенный крысами и привидениями паутинчатый чердак. Программисты могут входить в него, говорить, чего им не хватает, и возвращаться к работе. База ошибок требует постоянного сопровождения и усердия со стороны тех, кто открывает ошибки. Чем выше качество информации в базе ошибок, тем меньше времени и сил вы потратите на сортировку, и тем больше ваша команда проведет времени в реальной правке ошибок. Внимание: качественное описание ошибки (или отсутствие такового) могут быть первым критерием для сортировки ошибок по их важности. Чтобы улучшить качество информации об ошибке, прежде всего необходимо детализировать группы, на которые эти ошибки делятся. Помимо групп (Должны/Надо бы/Не будем), нужно ввести еще два понятия: «Приоритет» и «Серьезность». Смысл приоритетов прост: вместо «Должны сделать» назовите это «Приоритет 1», вместо «Надо бы сделать» — «Приоритет 2», и вместо «Не будем делать» — «Приоритет 3». Некоторые команды идут еще дальше и добавляют приоритет 4. Таким образом, Приоритетом 3 становится «вероятно, не будем делать», а Приоритетом 4 — «Не будем делать, пока не остынет преисподняя, потом снова не запылает и опять не остынет». Я не встречал успешных команд, у которых градация приоритетов имела бы более четырех уровней. Создание 15 различных приоритетов — это совершенно лишняя затея. «Серьезность» определяет, насколько серьезной будет ошибка для заказчика, если она случится. Отделение серьезности от приоритетности исправления дает лучшее видение ошибки, так как появляется возможность разделить последствия выполнения ошибки от возможности ее появления. К примеру, перед вами может быть ошибка, которая приводит к взрыву монитора пользователя (Серьезность 1), но возникает она только после тройного клика на пункт меню при напевании австралийского национального гимна на немецком языке, что маловероятно (Приоритет 3). Чтобы это заработало, кто-то должен сесть и определить разницу между уровнями серьезности 1, 2 и 3. Хорошо, если при этом будут приводиться примеры реальных ошибок, чтобы люди могли выбрать правильный уровень. После этого, как только будет открываться новая ошибка, степень серьезности будет заполняться надлежащим образом. Кому-то, вероятно, вам, придется добавить степени серьезности и к старым ошибкам.
8
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть I
Вот пример системы определения серьезности. Рекомендую вашей команде собраться вместе и оценить следующее: • Уровень серьезности 1. Потеря данных. Заказчик теряет данные или серьезно повреждает их. Восстановление данных может быть невозможно или требуется переустановка приложения (или нажатие кнопки «обновить» в браузере»); • Уровень серьезности 2. Часть функционала не работает или работает с большими проблемами. Большая часть возможностей не работает или работает не так, как ожидалось, поэтому рабочие задачи нельзя решить или приходится искать обходные пути; • Уровень серьезности 3. Раздражение. Второстепенные функции работают не так, как ожидалось. Обходные пути существуют, но их сложно найти или они раздражают и разочаровывают. Используя эти два критерия (приоритет и серьезность), вы можете отсортировать оставшиеся ошибки более мудро. Вместо того, чтобы работать просто с тремя большими группами ошибок, вы можете задать дополнительные уточняющие вопросы и отсортировать ошибки внутри каждой группы в зависимости от того, насколько они серьезны. Это один из быстрых способов расставить ошибки по местам внутри группы с одинаковым приоритетом. Третий важный критерий, который нужно учитывать при работе с ошибками, — это часть проекта, на которую ошибки воздействуют. Чем больше ваша команда, тем важнее учитывать этот критерий. Необходимо понять, какая часть проекта страдает от ошибки: возможность печати или поисковый механизм? Разбейте весь проект на четыре-пять частей и учитывайте их в базе ошибок. Это даст вам новый взгляд на проект — вы сможете определять, какие части проекта наиболее «сырые» или какие части наиболее важны для вас и ваших заказчиков. Если каждый программист отвечает за конкретную часть проекта, то такой подход позволит распределять ошибки для правки. Существует большое количество других критериев для сортировки ошибок. Наиболее часто встречаются такие, как качественное описание ошибки и способов ее воспроизведения, версия ПО, в которой ошибка была найдена, по уникальному ID и по человеку, ее обнаружившему. Каждый проект уникален и информация, которая вам может понадобиться, — тоже уникальна.
9
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть II Автор: Scott Berkun Перевод: Андрей Олищук Вторая часть статьи об управлении ошибками В предыдущей части, когда мы обсуждали ошибки в программном обеспечении, мы говорили о самых основах тактики: сортировке и расстановке приоритетов. В части 2 продвинемся еще дальше. Теперь ставки растут - требуется больше вложений, но и повышаются размеры полученных прибылей.
Уровень 3. Критерии выхода Как вы определяете, что завершили работу над чем либо? Легко определить когда кончаются шоколадные печенья или лазанья - их просто не остается на тарелке. Но более сложные вещи, такие как программное обеспечение, не так прозрачны (и не так вкусны). Вы должны заранее запланировать те критерии, по которым вы определите, что работа завершена. Если вы не сделаете этого, то потратите дополнительные часы на споры о том, все ли сделано, и на лишний кодинг. Если у вас достаточно трезвого ума, и вы заранее определите критерии выхода, то ваша команда израсходует время на достижение цели, а не на споры. Критерием выхода может являться любое утверждение об окончании разработки, которое будет истинным до того, как разработка программы будет завершена. Простейшим примером критерия выхода является время. Вы определяете точное время и дату завершения проекта не обращая внимания на оставшиеся ошибки или невыполненные задачи. Этот критерий наиболее прост для достижения, но он не имеет никакого отношения к качеству программного продукта. Вы уложитесь в сроки поставки вне зависимости от того, реализовано у вас 10 или 90 процентов функционала. Но если смотреть с точки зрения качества, то дата выпуска продукта - это всего лишь произвольная точка времени. Другой очевидный, но плохой критерий - мнение. К примеру, вице-президент вашей фирмы может решить, что программа готова, когда ему покажется, что она готова. 10
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть II
Даже если у вас золотой вице-президент, это все равно плохой фактор. Если он случайно попадет под автобус, то ваш проект последует за ним. Вам нужно нечто зафиксированное на бумаге, чтобы ускорить взаимодействие. Если все будет хранится в чьей-то голове, то за ней выстроится длинная очередь из ожидающих. Настоящие критерии выхода базируются прежде всего на измерениях качества. Какое количество дефектов, какого типа приемлемо для программы? Если вы читали первую часть, то должны быть знакомы с терминами "Приоритет" и "Серьезность" - простейшими способами классификации ошибок. Но что, если вы не определили, какие задачи должны иметь приоритет над другими? Должны ли быть исправлены все ошибки с приоритетом №1, или должны быть исправлены все ошибки с приоритетом №1, но только для какой -то конкретной части проекта? Если этого не знаете вы, то не знает и ваша команда, и вы обречены на споры по поводу каждой ошибки. Определение критериев выхода - это одно из проявлений лидерства. Для этого необходима постоянная забота о проекте, что сможет произвести эффект катализатора для всей организации. Ключевой вопрос таков: как много ошибок, какого типа, в каких частях проекта допустимы? Вот несколько наводящих вопросов, которые могут помочь: • Чем вы были заняты в последнее время? Вам необходимо выпустить несколько релизов. Их количество случайно, но это даст вам точку отсчета. Вы можете увеличивать или понижать качество относительно чего-либо, и это позволит вам выразить то, что вы имеете ввиду. Если вы никогда ранее не делали этого, то поставьте перед собой цели. Решите, какие действия вам необходимо проделать, чтобы выпустить версию 2.0. Периодически вы сможете определять качество в сравнении с предыдущими версиями и направлять работу в нужном русле. • Какие части проекта наиболее важны? Составьте упорядоченный список частей проекта/функциональных возможностей. Те элементы, которые наиболее важны для заказчика, должны иметь больший вес. Вы можете определить одни критерии выхода для функций А, Б и В и другие - для Г, Д и Е. Используйте основные ресурсы для наиболее используемых функций. • Какие тесты (тест-кейсы) вы используете? Критерии выхода не должны основываться на количестве ошибок. Если вы используете тест-кейсы для каждой функции своего ПО, то вы можете установить критерий выхода в процентном соотношении пройденных тестов. Если вы до сих пор не использовали тестов, то пришло время начать делать это (http://en.wikipedia.org/wiki/Test_case). Они могут инкапсулировать много различных критериев в один, зачастую автоматизированный, тест. Если вы будете их делать, то тесты помогут вам определить не только критерии выхода, но и просто помогут в завершении конкретной работы. Каждый чек-ин (занесение части кода в общую базу) может выполняться по прохождению теста. Это поможет определять проблемы до того, как они превратятся в большое бедствие.
11
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть II
• Какие параметры производительности должны быть достигнуты? Определены ли параметры производительности, к достижению которых вы стремитесь? Время загрузки, сохранения, закачки? Сфокусируйтесь на параметрах, которые очевидны для ваших заказчиков, - в таком случае вы будете править ошибки, имеющие значение именно для заказчика. Проблемы с производительностью - одни из самых неприятных для заказчика. В придачу ко всему, они имеют тенденцию быть сложными для правки (подсказка: пытайтесь определить их на ранних стадиях). Если вы не имеете понятия о том, какие показатели производительности должны быть у вашей прграммы, последуйте данному ранее совету - выстройте цепочку релизов и делайте лучше, чем в прошлый раз. Любой критерий выхода, который вы определите, должен иметь достаточную спецификацию. Каждая функциональная возможность или дизайн должны включать раздел с описанием, по которому разработчики смогут определить, завершена работа или нет. Запишите, какие тесты должны быть пройдены, какие параметры производительности должны быть достигнуты, каким критериям юзабилити программа должна соответствовать, или какие типы ошибок должны быть поправлены. Если вы не можете этого определить, значит, вы недостаточно осмыслили функционал, над которым работаете и который нужен заказчику. Чтобы критерии выхода оставались простыми, вам может понадобиться две совокупности: ряд нумерованных релизов и дополнительных критериев, специфичных для функционала. С таким подходом вам останется определить критерии выхода, большие или меньшие показателей из предыдущих релизов. Совет для лентяев: вся работа по определению параметров того или иного релиза может быть возложена на одного ответственного человека. Помните: вы всегда можете корректировать критерии выхода в течение проекта. Им не обязательно быть одинаковыми от начала и до конца проекта. Но помните, фиксируя их, вы даете команде инструмент для определения качества ее работы. Хорошо, когда критерии выхода периодически улучшаются (но не просто изменяются). Это может происходить после дополнительных переговоров с заказчиком и командой. Даже если аргументы возникают в процессе обсуждения этих изменений, люди будут спорить о влиянии на качество с точки зрения проекта (и заказчика), что более эффективно, чем обсуждение уровней ошибок.
Уровень 4. Раннее планирование Теперь вы готовы сделать серьезный шаг к правке ошибок. Если первых три уровня пройдены, то пришло время перейти от тактики к вопросам стратегии. Чтобы преодолеть посредственность, вам необходимо найти пути для траты вашего времени не на простые проблемы, а на продвинутые задачи. Работая с низкоуровневой тактикой, вы будете только подпирать проект и предотвращать переход проблем из разряда простых в серьезные. Конечно, если что-то из вышесказанного принесет свои плоды в работе вашей команды, то заработанное великим трудом время уйдет на раздумья о том, как пройдут следующие несколько дней, недель или месяцев.
12
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть II
Вам необходимо взглянуть на более фундаментальные вещи, которые вы можете улучшить для повышения качества вашего программного обеспечения. Простейший вид раннего планирования - взглянуть на предыдущий проект (или последнюю неделю текущего проекта). Спросите себя и других, что было сделано не так и продолжает вас преследовать в текущем проекте? Это плохие привычки, неэффективные инструменты или простое взаимонепонимание? Составьте список сфер для улучшения и разместите их в грубом порядке по принципу срочности или значимости. Решения проблем могут заключаться в покупке лучших систем управления ошибками, постановке конкретных задач по сортировке ошибок, обучении членов команды или улучшении способов управления ошибками. Возможно, хорошим решением будет назначение определенного человека для переговоров с заказчиком по поводу ошибок. Другой вариант: вы можете составить анкету для заказчика, которая поможет ему лучшим образом составлять отчеты об ошибках, что повысит качество описания ошибок, вводимых в систему. Подходящий способ обеспечить все это состоит в выделении человека для выполнения им задач по контролю качества. Если таковой человек в вашей команде уже есть, обеспечьте его большими возможностями (http://www.macdevcenter.com/pub/a/mac/2005/07/08/dev_team.html). Другой подход - сфокусироваться на раннем определении проектов. Если у вас есть возможность, наймите проектировщика или инженера по юзабилити, чтобы они помогли вам правильно организовать проект с самого начала. Они помогут вам определить наиболее важные направления и избавят вашу команду от траты времени на разработку второстепенных функций. Если вы вырабатываете список частей проекта для улучшения, не забудьте ранжировать их. Расставьте их в порядке наибольшей значимости для вас и проекта, а затем начните решение первой задачи из этого списка. Не первых пяти или десяти, а именно самой первой. До тех пор, пока вы и каждый член вашей команды не будут способны добиться позитивных изменений, вы должны добиваться этих изменений. Помогите всем объединиться вокруг улучшения ситуации, позвольте каждому высказывать свои предложения и участвовать в их реализации. И не забывайте о критериях выхода, иначе как вы узнаете, что какой-либо процесс уже улучшен?
Исключения и примечания Существует несколько исключительных ситуаций, когда необходимо пренебречь советами, данными в этом эссе. Простая рекомендация: иногда программист может быстро превратить большую ошибку в ошибку малой важности. В такой ситуации нужно править ошибки вне порядка их приоритета. Позвольте программистам иногда действовать по их усмотрению. Соглашательство порой может быть полезным.
13
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть II
• Мораль: правка ненавистных или очевидных ошибок, вне зависимости от их приоритета, может позволить программисту почувствовать гордость и повысить моральный дух. Это допустимо, если вы знаете, ради чего идете на это. Если такие вещи проделываются часто, то смените критерии для расстановки приоритетов 1, 2 и 3. Если вам приходится обходить правило, смените это правило. • Убедитесь, что программисты не путают свое время с рабочим временем. Низкоприоритетные ошибки и те ошибки, которые интересны лично им, они могут править только в свободное время. При этом убедитесь, что им известно, будут ли им начислены бонусы за работу над проектом в нерабочее время. • Качество: исправление ошибок схоже с любой другой работой - чем больше времени вы на это тратите, тем выше качество исправлений. При этом возьмите за правило, что время, затраченное на исправление, должно соответствовать весу ошибок. Вы ведь не будете навешивать пластмассовую дверь на золотые петли без веской причины?
Часто задаваемые вопросы • Кто должен быть вовлечен в сортировку ошибок (Уровень 1)? Тот, кто громче всех кричит. Не важно, разработчик ли это, тестер или менеджер проекта. Если один человек может взять на себя сортировку и фильтрацию базы ошибок, то не стоит поручать эту работу троим. Если у вас есть представитель заказчика, попросите его плотно поучаствовать в этом процессе (но будьте готовы переводить ошибки в его термины). Все специалисты, технические писатели, юзабилити-инженеры, маркетинг должны быть приглашены, но наилучший способ сэкономить время каждого из них - это договориться с ними о телефонных консультациях, когда их помощь будет нужна. Дайте им знать, какая из ошибок требует их внимания, и они подскажут вам, насколько серьезна данная ошибка. • Что мне делать, если я не могу добиться согласия босса на определение критерия выхода (окончания проекта)? Изучайте гипноз. Ну, хорошо, возьмите этот критерий для работы над пилотным проектом. Обратитесь к людям, которые уже участвовали в таких проектах и попробуйте выработать критерии вместе с ними. Затем, когда проект, по вашему мнению, подойдет к концу, совместно с боссом рассмотрите, насколько ваши критерии выхода приемлемы в данной ситуации. Если они приемлемы, босс все равно скажет нет. Если не приемлемы, то что вы еще ожидали от босса? Повторяйте эту процедуру, пока вы не найдете что-либо, позволяющее вам закончить проект. • Приведите пример самого неудачного случая в вашей практике управления ошибками. Что ж, это история одного менеджера по контролю качества, который сформулировал критерии выхода за два дня до срока окончания проекта.
14
PHP Inside №14
Исправление ошибок: в нужное время и в нужном месте. Часть II
Он был счастлив своему прогрессу, но когда я взглянул на то, что он записал, я не был удивлен, что он просто задокументировал текущий билд. Вы можете догадаться о качестве этого релиза. Правда, это была не совсем ошибка менеджера. Вице-президент оставил критерии выхода только у себя в памяти и не сообщил о них менеджеру. • Почему управление ошибками не преподается как часть информатики в университетах? Возможно, их учебные планы сами полны ошибок? Если быть честным, то здесь достаточно и меньшего времени, чем учеба в университете. Я полагаю, что исправление ошибок - это узкая прикладная дисциплина, которая с академической точки зрения больше является прикладной, нежели относится к теории вычислительной техники. В большинстве училищ (в американской системе образования - trade scool, прим. переводчика), где учебный процесс сфокусирован на конкретных прикладных науках, можно встретить факультативные занятия по контролю качества и искусству отладки.
Полезные ссылки Тестирование программного обеспечения. Это огромная тема. Начать можно отсюда: http://en.wikipedia.org/wiki/Software_testing Безболезненный учет ошибок: замечательное эссе от Джоеля о простом учете ошибок. http://www.joelonsoftware.com/articles/fog0000000029.html Примеры сортировки ошибок. Здесь есть примеры различной организации сортировки ошибок. Ссылки разнообразны: • Bugzilla: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html • OSAF: http://wiki.osafoundation.org/bin/view/Journal/KatieParlante20040726 • Gnome: http://developer.gnome.org/projects/bugsquad/triage/faq.html • Microsoft video of a triage session: http://channel9.msdn.com/ShowPost.aspx?PostID=26948#26948 • Software quality assurance FAQ: http://www.softwareqatest.com/qatfaq1.html
Функциональное тестирование при помощи Selenium
15
PHP Inside №14
Функциональное тестирование при помощи Selenium
Функциональное тестирование при помощи Selenium Автор: Сергей Юдин Любое качественное веб-приложение нуждается в тестировании. Selenium — инструмент для тестирования веб-приложений Любое приложение нужно тестировать. Как говорил очень уважаемый программист: «программы, которые не протестированы, не работают». Мы пишем код и тестируем его, мы создаем страницы и смотрим, как они отображаются в браузере, мы создаем формы и проверяем, правильно ли работают на них все компоненты.
Что такое функциональное тестирование Чаще всего мы проводим тестирование наших приложений на соответствие требованиям заказчика (даже если в роли заказчика выступаем мы сами). Такое тестирование называется приемочным или функциональным. Например, у нас есть электронный магазин. Его функциональное тестирование будет заключаться в проверке работы каталога товаров, навигации по разделам, выбор товаров, формирование корзины, оформление заказа, просмотр состояния заказа, получение подтверждения о принятии заказа к обработке по почте и т.д. Грубо говоря, мы проверяем работоспособность приложения, а также правильность его работы. Зачастую функциональное тестирование проводится вручную, обычно для этого выделяют специального человека или несколько, которые обходят сайт раз за разом и сверяют поведение системы с тем, что прописано в техническом задании. На такое ручное тестирование уходит очень много времени, да и качество этого тестирования далеко не идеальное: человек может что-либо забыть, полениться сделать, пропустить что-то. Один из самых больших недостатков такого ручного тестирования, что моменты обнаружения ошибки в поведении системы и локализации этой ошибки очень удалены друг от друга. Иногда проходит неделя или даже больше времени, прежде чем ошибка выявляется, и на поиск ее причины и исправление уходит много времени. Мы не можем проводить ручное тестирование сколь угодно часто, так как это требует больших затрат. Мне могут возразить, что у них в компании есть люди, которые занимаются ручным функциональным тестирование весь день. 16
PHP Inside №14
Функциональное тестирование при помощи Selenium
Что ж, вы можете гарантировать, что один и тот же сайт можно обходить целиком 5-10 раз в день, проверять его до мельчайших деталей? Если ответ да, то мне просто жаль ваш отдел QA. Для того чтобы проводит такое тестирование быстро, часто и главное эффективно, существуют средства для автоматизации функционального тестирования. Далее мы будем вести речь только об автоматизированном функциональном тестировании, мы покажем, как и при помощи чего можно автоматизировать этот нелегкий и скучный труд.
Автоматизированное функциональное тестирование Автоматизированным функциональным тестированием называют такое тестирование системы (в нашем случае это будет webсайт), когда тестирование ведется в полностью автоматическом режиме, без непосредственного участия человека, без знания деталей реализации этой системы на соответствие требованиям заказчика. Функциональное тестирование поэтому называют также тестированием “черного ящика”. Автоматизированные функциональные тесты в идеале не должны знать ничего про архитектуру системы, из каких компонентов она состоит, на каком языке программирования реализована и т.д. Это не позволит менять архитектуру, язык приложения, базу данных, но гарантирует, что мы сможем всегда быстро проверить, что система все еще работоспособна.
Автоматизированные функциональные тесты в идеале не должны знать ничего про архитектуру системы, из каких компонентов она состоит, на каком языке программирования реализована
Тестирование должно проводится так, как если бы реальный пользователь работал с системой. Приемочные тесты можно использовать для любых приложений (размера и качества реализации). Их написание не требует много времени и серьезных навыков. Приемочные тесты можно писать как до реализации тестируемой системы, так и после. Функциональные тесты бывают очень полезны при рефакторинге legacy-систем (ранее написанных), если они не были до этого покрыты модульными тестами. В этом случае мы еще до рефакторинга производим создание набора функциональных тестов, чтобы у нас имелась возможность быстро проверить целостность системы и ее функциональности после внесения изменений. Функциональное тестирование для web-сайтов подразумевает эмуляцию работы пользователя с браузером, а именно: открытие страниц, переход по ссылкам, заполнение и отправка форм, проверка значений полей форм, наличие определенного текста на страницах, получение почты, отправка файлов и т.д. При этом все действия по осуществлению манипуляции браузером должны производить сами тесты, в автоматическом режиме, без участия человека.
При помощи чего производится функциональное тестирование. В настоящий момент в среде разработчиков ни один продукт не используется как стандарт для функционального тестирования web-приложений. Существует 2 типа продуктов для функционального тестирования:
17
PHP Inside №14
Функциональное тестирование при помощи Selenium
•
Продукты, эмулирующие поведение браузера, написанные на языке высокого уровня, обычно на том же языке, что и приложение (но не обязательно). В качестве примеров можно привести httpUnit, JWebUnit, WebTester из SimpleTest и другие.
•
Продукты реализованные на JavaScript и реализующие проверки непосредственно средствами браузера. В качестве примеров можно привести Watir и Selenium.
Эмуляторы хорошо себя зарекомендовали и стали достаточно популярны. В первую очередь из-за того, что они появились раньше программ второго типа, кроме этого эмуляторы могут использовать код, который написан для приложения, правильно и оптимально создавать фикстуры (формировать среду для правильной работы тестов), немаловажен и такой показатель как высокая скорость исполнения. Но эмуляторы браузеров не могут на 100% справиться с одной задачей – они не могут выполнять JavaScript код, который используется на страницах сайтов. Это накладывает ограничения или на процесс тестирования, или на процесс создания сайтов. То есть невозможно проверить работу сайта, как если бы это делал реальный пользователь, так как эмуляция работы браузера – вовсе не эквивалентна реальной работе браузера. Из-за этого автоматизированное тестирование приходится дополнять тестированием ручным. Этого недостатка лишены продукты для функционального тестирования второго типа. Они контролируют работу браузера, выполняют команды и делают проверки при помощи JavaScript-кода, что практически гарантирует 100% адекватность автоматизированного тестирования ручному. К сожалению, до недавнего времени у разработчиков не было возможности пользоваться хорошим, удобным, а главное бесплатным продуктом второго типа. Но теперь есть Selenium!
Selenium – краткое описание Selenium как проект был начат относительно недавно (в июне 2004 года, стал открытым в декабре 2004 года) и ведется под патронажем компании ThoughtWorks. Кстати в этой компании работает Мартин Фаулер, а это о многом говорит. Selenium выпускается под лиценцией Apache License, Version 2.0. Selenium доступен по этому адресу: http://selenium.thoughtworks.com/ По этому находится JIRA для Selenium (аналог Trac): http://jira.public.thoughtworks.org/browse/SEL Что собой представляет Selenium? Это объектно-ориентированное JavaScript приложение, которое может анализировать файлы определенной структуры для того, чтобы находить в них команды для манипуляции браузером и команды для выполнения определенных проверок.
18
PHP Inside №14
Функциональное тестирование при помощи Selenium
В поставке Selenium входит документация, которая может помочь быстро разобраться в использовании этой системы для функционального тестирования. Для того чтобы попробовать Selenium в работе, его необходимо скачать, разархивировать, положить в папку, доступную для web-сервера и набрать в строке браузера приблизительно такой путь: http:/localhost/selenium/TestRunner.htm. Никаких дополнительных настроек не требуется. Вот так должно выглядеть окно вашего браузера после запуска Selenium-а:
Рабочее окно Selenium поделено на несколько областей. Снизу находится рабочая область браузера. Здесь будут отображаться страницы тестируемого сайта. В левом верхнем углу находится список тестовых случаев (TestCase-ов), которые могут быть выполнены для текущего приложения. Это список тестовых случаев называется TestSuite. В центральной верхней части находится содержимое текущего TestCase-а, в правой верхней части – управляющие кнопки для запуска тестов, а также статистика выполнения тестов. Для запуска тестов нажмите кнопку AllTests и Selenium начнет проверку самого себя при помощи набора тестов, который поставляется вместе с ним. Selenium может выполнять тесты в трех скоростных режимах: run, walk и step. Run выполняет тесты с максимальной скоростью. Walk делает паузу в 0.5 сек (по-умолчанию) на каждой команде, что может быть очень удобно при визуальной проверке правильности работы сайта. Step – вы самостоятельно приказываете Selenium-у выполнить следующую команду.
19
PHP Inside №14
Функциональное тестирование при помощи Selenium
Содержимое TestCase-а TestCase-ы Selenium – это обычные html-страницы с одной таблицей, содержащей команды. Каждая строка таблицы содержит 3 колонки. Первая из них является действием или проверкой (action и assertion/check), вторая – именем элемента (target), к которому применяется команда, и третья – значением (value). Вот пример файла TestCase-а Selenium-а, назовем его Test Login: <meta content="text/html; charset=win-1251" http-equiv="content-type"> Test Login
Test Login
open
/login
type
login
vasa
type
password
super_admin
clickAndWait
login_button
verifyLocation
/
verifyTextPresent
Wellcome, Vasa Pupkin
Разберем по порядку, что же делает Selenium, выполняя данный TestCase. Стоит сразу указать, что Selenium пропускает первую строку таблицы. Здесь вы можете поместить краткое описание, что же будет осуществляться в данном тесте.
20
PHP Inside №14
Функциональное тестирование при помощи Selenium
Мы покажем ниже, как можно вставлять комментарии в тестовый код другими способами. Итак,
open
/login
Выполняет действие open. Selenium дает команду браузеру перейти на указанную страницу - /login. Колонка для значения здесь не используется. Допустим в результате выполнения у нас открылась страница, содержащая форму авторизации:
Теперь Selenium при помощи действий type заполнит поля формы определенными значениями. Вы визуально увидите, что поля получили соответствующие значения.
type
login
vasa
type
password
super_admin
После этого действием clickAndWait Selenium нажмет кнопку для отправки формы и будет дожидаться ответа.
clickAndWait
login_button
После этого при помощи проверки verifyLocation Selenium проверит текущее положение браузера. После аутентификации мы должны оказаться на главной странице сайта
verifyLocation
/
И, наконец, после успешной аутентификации на должны увидеть приглашение на главной странице.
21
PHP Inside №14
Функциональное тестирование при помощи Selenium
Selenium проверяет наличие соответствующего текста на странице при помощи проверки verityTextPresent
verifyTextPresent
Wellcome, Vasa Pupkin
Чуть ниже мы разберем, какие команды и проверки есть в Selenium, как указывать определенные элементы на странице, а также как расширить набор доступных команд и проверок.
Организация тестов Как уже было указано, TestCase-ы организованы в список, который называется TestSuite. TestSuite также является обыкновенной html страницей, приблизительно такого содержания: <meta content="text/html; charset=win-1251" http-equiv="content-type"> Test Suite
Теперь объясним чуть поподробнее то, как организуются тесты и как они хранятся на диске. В базовой поставке все файлы TestCase-ов и TestSuite-ов являются обычными текстовыми html файлами и лежат в папке /selenium/tests. При запуске Selenium пытается найти файл TestSuite.html в этой папке и загружает список тестов из TestSuite в левое верхнее окно. При щелчке на одну из ссылок файла TestSuite.html в окно текущего TestCase-а загружается содержимого соответствующего файла с командами. Вот в принципе и все. Для расширения набора тестов какоголибо приложения мы должны создать соответствующий TestCase html файл и поместить на него ссылку в TestSuite.html. Это, правда, самый простейший вариант использования Selenium-а, однако большинство разработчиков он устроит. Отметим здесь же, что хотя Selenium воспринимает TestCaseы только в виде html страниц, это вовсе не значит, что сами TestCase-ы должны быть html файлами. Они могут генериться при помощи PHP, JSP, CGI, в общем, при помощи любой технологии, которая вам может показаться удобной.
22
PHP Inside №14
Функциональное тестирование при помощи Selenium
Однако нельзя не согласиться, что Selenium – это одна из самых простых на сегодняшний момент систем, чтобы начать функциональное тестирование своих web-приложений.
Инсталляция Selenium для тестирования сайтов Существует 2 способа инсталляции Selenium: •
Отдельный web-сервер, который тестирует другие сайты.
•
Инсталляция Selenium-а по тому же адресу, что и тестируемый сайт.
Мы не будем рассматривать первый случай, так как здесь возникают некоторые проблемы с так называемыми cross-site scripting limitations, то есть отказ браузера исполнять код, если он требует модификации содержимого страницы, пришедшей с другого хоста. Вы можете самостоятельно поискать решение этих проблем, благо в списке рассылки Selenium-а такие вопросы время от времени появляются. Самым простым способ установки Selenium является распаковка его в папку проекта, удаление родных тестов, подчистка TestSuite.html – вот и все. Но данный метод связан с копированием файлов Selenium в каждый проект, кому это может понравиться? Ниже мы покажем, как можно легко и быстро настроить Selenium на использование одной инсталляции несколькими проектами. Итак, допустим, мы разархивировали selenium в папку / var/external/selenium/. При помощи Selenium мы желаем протестировать 2 проекта: / var/dev/project1/ и /var/dev/project2/. Что нам нужно сделать, что того, чтобы использовать одну инсталляцию на работы с обоими проектами. При запуске Selenium-а мы указывали в пути файл TestRunner.html в папке /var/external/selenium/. Посмотрим на его содержимое: <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type" /> Selenium Functional Test Runner <script language="JavaScript" type="text/javascript" patched.js"> <script language="JavaScript" type="text/javascript" browserbot.js"> <script language="JavaScript" type="text/javascript" api.js"> <script language="JavaScript" type="text/javascript" commandhandlers.js"> <script language="JavaScript" type="text/javascript" executionloop.js"> <script language="JavaScript" type="text/javascript" fitrunner.js"> <script language="JavaScript" type="text/javascript" logging.js"> <script language="JavaScript" type="text/javascript" src="htmlutils.js"> <script language="JavaScript" type="text/javascript"
