frei_by

0. Забудте про denwer

1. Установить php
2. Установить pear
3. Через pear вытянуть phpunit с сайта Бергмана
3.1 Через pear вытянуть Selenium testcase с сайта Бергмана
4. Скачать архив с jar селениумом и запустить сервер.
5. скопировать в блокнот селениумовский Hello world и запустить через командную строку как файл php <ваш файл>.

я обычно в такой последовательности делаю.

Я думаю многие сталкивались с классической задачей "протестировать форму регистрации" логин + email + проль.

В данном случае инетерес предаставляет именно поле email.
Какие для такого теста можно придумать тестовые данные? есть собачка, нет собачки, есть точка для доменной зоны (.com) нет точки...

Сегодня нашёл в интернете интересную статью о том как программисты мерялись валидаторами email. Набор тестовых данных впечатлил.
http://www.dominicsayers.com/isemail/ - статья
http://www.dominicsa...ail/results.php - результаты.
(http://code.google.com/p/isemail/) - исходники.

Особо инетресны случаи, когда email вроде...
first.last@[IPv6:::12.34.56.78] - корректный email ))
first.(")middle.last(")@iana.org - корректный email ))
test@example - снова, согласно RFC, корректный email ))

Ещё одна фича RC - &nbsp

Например, есть у вас текст "Продвижение товаров в классификаторе " который, как следовало ожидать, выглядит как "Продвижение товаров в классификаторе&nbsp;"
Полсе того как в голове проносятся всякие мысли про то что за такие нажатия на пробел в конце строки нужно линейкой по пальцам давать, нужно всё-таки как-то проверить эту строку на наличие.

http://stackoverflow...ext-containing-
например, в IDE это будет выглядеть так:

highlight
//*[text()='Продвижение товаров в классификаторе${nbsp}']

а в RC

$flag = false;
$flag = $this->isElementPresent('//*[text()=\'Продвижение товаров в классификаторе${nbsp}\']');
if ($flag !== true)
{$this->fail('3. Sucsessfuly login but fail to navigate to module...');}

такой трюк не проходит...

помогает если на клавиатуре с зажатым alt набрать 0160, привет от dos-а.

...или использование большого шаманского костяного бубна:

$this->isElementPresent('//*[text()=\'Продвижение товаров в классификаторе'.utf8_encode(chr(160)).'\']');

кто-нибудь сталкивался?

Как насчет стратегии тестирования? Вроде как не упомянута.

Вот давеча написал тестовый план (дизайнеры вместе с жаба-скриптчиками переделалаи корзину в магазине и поставили задание проверить корректность работы ++ "краш тест") :

2. План тестирования, [TP]

Введение.
Данный документ представляет из себя план тестирования модуля, осуществляющего функции стандартной корзины в системе магазинов. План предназначен для организации тестирования модуля после выполненных в модуле доработок. В рамках данного плана предполагается выполнить ограниченное функциональное тестирование работы корзины. Тестирование производится с точки зрения конечного пользователя (клиентский уровень). Разработанные тесты могут быть использованы для приёмочного тестирования.

Тестируемая система.
Тестируемая система представляет из себя магазин расположенный по адресу http://***/ доступный через сеть Интернет с сервера ***. Требования к системе описаны в SRS. У модуля можно выделить 4 режима работы, указанных в п.1.3. Режимы отличаются количеством шагов, которые покупателю необходимо выполнить для оформления заказа.

Тестируемые аспекты
В рамках данного плана предполагается выполнить (для каждого из вариантов режима работы соотв.):
1. Корректное функционирование системы: последовательность шагов, возможность вернутся по шагам, корректные данные заказа для каждого шага независимо от того, проходит ли покупатель шаги последовательно от первого до последнего, либо переходит с одного шага вперёд либо назад.
2. корректность расчёта величин для всех возможных валют,
3. корректность сопоставления доставка – способ оплаты – доступные валюты для данного способа
4. Валидация вёрстки, кроссброузерность: IE6 + Mozila FF 3.6. + Opera 10.62
5. Цитата из задания «by <тим лидер дизайнеров> - и просто краш-тест» - в рамках краш теста намеренное искажение данных с целью сформировать ошибочный заказ.

Не тестируемые аспекты
Настройки специфических электронных видов расчёта для корзины, как-то WebMoney и т.п.
Безопасность корзины в плане похищения конфиденциальных данных покупателя (номер паспорта, адрес и т.п.), способ передачи данных для сторонних платёжных систем.
Подмодуль «сообщения в корзине», подмодуль «получение заказов» - и общая корректность работы корзины со стороны продавца.
Нефункциональное тестирование, в том числе нагрузочное тестирование, тестирование производительности, тестирование удобства использования (usability)

Подход к тестированию
Уровень тестирования системное, с точки зрения конечного покупателя. Основная часть функционального тестирования будет выполнена вручную. «краш-тест» будет выполнен с использованием Jmeter путём искусственного создания запросов к системе. Метрики для ручного тестирования – покрытие путей модели, описанных в TDS. Метрики для автоматизированного краш теста – покрытие путей модели описанных для раздела автоматического краш-теста TDS.

Критерий успешности системы – система передаётся в эксплуатацию, когда разработан полный комплект тестов и все тесты для ручного тестирования выполняются без ошибок. Некритические ошибки найденный во время краш-теста могут быть перенесены как доработки.

Критерий прекращения тестирования – система передаётся на доработку, если хотя-бы один из разработанных тестов обнаруживает ошибку. После исправления ошибки система вновь передаётся на тестирование.

Поставка.
В результате выполнения данного плана должны появится:
Документ [TDS]
Комплект тестов, оформленный в виде [TSC]. Будут созданы два комплекта тестов – для ручного тестирования и для автоматизированного «краш-теста».

Требования к окружению.
Никаких.
(цитата из лога аськи)
<тим лидер програмистов>14:36
нагрузка не предсказуема
<тим лидер програмистов>14:37
то есть, может быть на 15 минуте быть, потом 15минуте 14 секунде, пропасть

Более крупного стратегического планирования пока что не произвожу... Задания приходят максимум на передаланный модуль. Новых проектов = новых больших войн пока что не планируется, поэтому пока что ограничиваюсь локальными операциями.

Первое время это напоминало партизанскую оборонительную войну - ставится задание - я вообще первое время никаких документов не оформлял, а сразу писал баги в трекер на задание. Баги правят - задание приходит ко мне. Я пишу новые - отправляю назад. Их исправляют - возвращают ко мне. Обычно после двух трёх перебросок кое-как закрывали задание, но при этом треть багов переносились как доработки на потом...

Сейчас - когда приходит новое задание, пробую начинать оформлять на него план тестирования.
Что-нибудь посоветуете?