Текст книги "tестирование dot com"
Автор книги: Роман Савин
Жанры:
Интернет
,сообщить о нарушении
Текущая страница: 9 (всего у книги 17 страниц)
ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ (functional testing)
Уже говорили и еще будем много говорить.
ТЕСТИРОВАНИЕ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ
(UI (читается как «ю-ай») testing)
Это тестирование, при котором проверяются элементы интерфей-
са пользователя. Мы рассмотрим все основные элементы веб-
интерфейса при разговоре о системе трэкинга багов.
Важно понимать разницу между
тестированием интерфейса пользователя и
тестированием с помощью интерфейса пользователя.
Пример первого
Проверяем максимальное количество символов, которые можно напе-
чатать в поле «Имя» на странице «Регистрация», т.е. проверяем, отве-
чает ли конкретный элемент интерфейса, называющийся "одностроч-
ное текстовое поле" (textbox), требованию спецификации, которая ука-
зывает на максимальное количество символов, которое в этом поле
можно напечатать.
Пример второго
Тестируем бэк-энд и с помощью интерфейса создаем транзакцию по-
купки, т.е. мы использовали интерфейс пользователя как инструмент
для создания транзакции.
ТЕСТИРОВАНИЕ ЛОКАЛИЗАЦИИ
(localization testing)
Многогранная вещь, подразумевающая проверку множества ас-
пектов, связанных с адаптацией сайта для пользователей из
других стран. Например, тестирование локализации для поль-
зователей из Японии может заключаться в проверке того, не вы-
даст ли система ошибку, если этот пользователь на сайте зна-
комств введет рассказ о себе символами Kanji, а не английским
шрифтом.
ТЕСТИРОВАНИЕ СКОРОСТИ И НАДЕЖНОСТИ
(load/stress/performance testing)
Это проверка поведения веб-сайта (или его отдельных частей)
при одновременном наплыве множества пользователей.
Классификация видов тестирования
153
У каждого, кто пользуется Интернетом, есть опыт ожидания,
когда, например, кликаешь на линк и следующая страница
медленно высасывает из тебя душу, загружаясь ну оче-е-е-е-нь
долго.
Плохой перформанс (скорость работы) – это основная беда
российских интернет-проектов.
Менеджмент, который экономит на подобном тестировании, в
итоге, как правило, глубоко сожалеет об этом, так как современ-
ный интернет-пользователь – это существо ранимое и нервное,
если сайт работает медленно, с перебоями или не работает со-
всем, так как не справляется с наплывом посетителей, то совре-
менный интернет-пользователь идет куда? Правильно, на сайт
конкурента, тем более что физически никуда идти или ехать не
надо, а надо лишь набрать "даблюдаблюдаблю точка адрес кон-
курента точка ком ".
Тестирование скорости и надежности – это отдельная техниче-
ская дисциплина, за хорошее знание которой получают очень
большие деньги в иностранной валюте.
Как правило, целью такого тестирования является обнаружение
слабого места (bottleneck) в системе. Под системой подразумева-
ются все компоненты веб-сайта, включая код, базу данных, "же-
лезо" и т.д.
В моей практике был случай, когда из-за того, что один из за-
просов к базе данных был составлен громоздко (с точки зрения
обработки этого запроса системой), одна интернет-компания
потеряла много пользователей, так как в течение нескольких
дней сайт то работал, то не работал, и никто не мог понять,
what the heck is going on ("что за фигня "), пока один из програм-
мистов не встрепенулся и не исправил код. Прошу заметить,
что функционально старый код работал прекрасно, но с точки
зрения перформанса он никуда не годился.
Скорость и надежность веб-сайта профессионально проверяется
специальным ПО, которое легко может стоить под 100 тыс. долл.
(например, Silk Performer от Segue или Load Runner от Mercury Interactive).
Упомянутое ПО служит:
с одной стороны, для генерации наплыва пользователей,
154
Тестирование Дот Ком. Часть 2
с другой – для измерения скорости, с какой веб-сайт в сред-
нем отвечает каждому из "наплывших" и с третьей – для
последующего анализа полученных данных.
ТЕСТИРОВАНИЕ БЕЗОПАСНОСТИ (security testing)
Одна из знакомых моего друга несколько лет назад наотрез от-
казывалась пользоваться Интернетом. На вопрос "почему? " она
неизменно отвечала, что боится хукеров, чем неизменно вызывала
у окружающих смех до икоты, так как на самом деле она имела
в виду хакеров (hacker – в современном значении киберпреступ-
ник, hooker – девушка легкого поведения).
Шутки шутками, а киберпреступность (cyber crime) – это целая
криминальная индустрия, доходы ежегодно измеряются милли-
ардами долларов, которые соответственно теряют корпорации и
честные каптруженики.
Тестирование безопасности – это множество вещей, суть кото-
рых заключается в том, чтобы усложнить условия для кражи —
кражи данных, денег и информации.
Например, в одной из систем интернет-платежей есть специальный
отдел, который профессионально занимается взламыванием... своего
же веб-сайта и получает премии за каждую найденную ошибку в сис-
теме обеспечения безопасности.
ТЕСТИРОВАНИЕ ОПЫТА ПОЛЬЗОВАТЕЛЯ
(usability testing)
Призвано объективно оценить опыт пользователя (user experience),
который будет работать с разрабатываемым интерфейсом.
Каждый из нас иногда ломает голову над тем, как исполнить же-
лаемое на том или ином сайте. Поясню.
Допустим, вы идете на сайт сети пиццерий и хотите найти
пиццерию, ближайшую к вашему дому. Если интерфейс сделан с
заботой об опыте пользователя (user friendly interface), то мы
быстро найдем вверху (header) и/или внизу (footer) страницы
хорошо заметный линк «restaurant locator» либо «store locator»
(месторасположение ресторана).
Вопрос: почему такой линк должен быть вверху или внизу стра-
ницы и называться именно так?
Классификация видов тестирования
155
Ответ: да потому, что это своего рода конвенция, и пользователь,
ищущий ближайшую к дому пиццерию, ожидает увидеть линк в
этих местах и с таким названием.
При юзабилити-тестировании также проверяется интуитивность
интерфейса. Я видел некоторые "гениальные" интерфейсы, кото-
рые словно были созданы с целью не допустить достижения
страницы, на которой можно оплатить товар.
Еще одним примером ужасного юзабилити является ставшее
популярным размещение, скажем, на новостных сайтах больших
мигающих баннеров справа от текста, после минуты чтения
новостей на таком сайте создается впечатление, что побывал
на угарной дискотеке.
Юзабилити-тестирование часто проводится путем привлечения
группы потенциальных пользователей с целью собрать впечатле-
ния от работы с системой.
В добрые доткомовские времена, на рубеже тысячелетий пред-
ставители интернет-компаний запросто ловили на улицах Сан-
Франциско праздношатающихся разгшъдяев и платили им 50 долл.
за час работы со свежеиспеченным веб-сайтом. Those were the
Ways, my friend... Those were the days... (непереводимо).
Зачастую опыт пользователя тестируется самими продюсерами
во время написания спека и создания макетов. Есть также про-
фессиональные юзабилити-инженеры.
ТЕСТИРОВАНИЕ СОВМЕСТИМОСТИ
(compatibility testing)
Это проверка того, как наш веб-сайт взаимодействует с
• "железом" (например, модемами) и
• ПО (браузерами/операционными системами) наших поль-
зователей.
Пример
МНОГО лет назад, когда Netscape Navigator все еще использовался, а
Виндоуз была еще в 98 версии, мы нашли такой баг:
"Краткое описание:
"Проблема совместимости: Win'98 перезагружается при входе в
систему с Netscape Navigator версии Х.Х"
156
Тестирование Дот Ком. Часть 2
Описание и шаги для воспроизведения проблемы:
1. Открой www.main.testshop.rs с помощью Netscape Navigator вер-
сии Х.Х, установленной на Win'98 (можно использовать машину
из тест-лаборатории).
2. Введи «[email protected]» в поле «Имя пользователя»
и «121212» в поле «Пароль».
3. Нажми на кнопку «Вход».
Баг: Win'98 начинает перезагружаться.
Ожидаемый результат: вход в систему.
Комментарий:
баг воспроизводится только при таком сочетании браузера и ОС".
Из примера почерпнем по крайней мере три вещи:
• при тестировании было найдено такое сочетание браузе-
ра/операционной системы, при котором существовал фа-
тальный баг, из-за которого пользователь не только не
смог бы войти в www.main.testshop.rs, но и терял бы всю
свою несохраненную работу;
• проблемы, связанные с совместимостью между веб-сайтом
и браузером/ОС, реальны и могут вести к серьезным багам;
• можно (и нужно) создать тест-лабораторию с наиболее по-
пулярными сочетаниями браузер/ОС, установленными на
компьютерах наших пользователей.
Как найти эти популярные сочетания? Очень просто – покопайтесь
в Интернете и поищите статистику о пользовании браузеров и ОС.
Что дальше? Дальше включаем компы с популярными ОС, запус-
каем на них популярные браузеры и исполняем наши тест-кейсы.
Тестирование с разными браузерами называется кросс-браузер-
тестированием (cross-browser testing).
Тестирование с разными ОС называется кросс-платформ-тести-
рованием (cross-platform testing).
Примером тестирования совместимости вашего сайта и «железа» явля-
ется ситуация, когда полноценное пользование вашим сайтом возможно
только при наличии видеокарты определенного типа, например поддер-
живающей технологию DirectX версии Х.Х. Здесь мы можем, например,
протестировать, каков будет опыт пользователя, если у того на машине
установлена устаревшая и неподдерживаемая видеокарта (кстати, такое
тестирование будет называться негативным, но об этом позднее).
За исключением тех случаев, когда тест-кейсы специально созда-
ны для тестирования совместимости, я не рекомендую указывать
Классификация видов тестирования
157
в них детали, например, по типу и версии браузера, так как типы
и особенно версии меняются. Как мы помним, излишняя детали-
зация приводит к трате времени на поддержание тест-кейсов.
3. По субъекту тестирования
• альфа-тестировщик (alpha tester);
• бета-тестировщик (beta tester).
АЛЬФА-ТЕСТИРОВЩИК (alpha tester)
Это сотрудники компании, которые профессионально или непро-
фессионально проводят тестирование: тестировщики, програм-
мисты, продюсеры, бухгалтеры, сисадмины, секретарши. В стар-
тапах накануне релиза нередко все работники, включая Харито-
ныча, сидят по 16 часов кряду, пытаясь найти непойманные баги.
БЕТА-ТЕСТИРОВЩИК (beta tester)
Это нередко баловень судьбы, который не является сотрудником
компании и которому посчастливилось пользоваться новой сис-
темой до того, как она станет доступна всем остальным. За бета-
тестирование иногда даже платят деньги (вспомните пример с 50
долл. в час за юзабилити-тестирование).
4. По времени проведения тестирования
ДО передачи пользователю – альфа-тестирование (alpha
testing):
• тест приемки (smoke test, sanity test или confidence test);
• тестирования новых функциональностей (new feature
testing);
• регрессивное тестирование (regression testing);
• тест сдачи (acceptance или certification test),
ПОСЛЕ передачи пользователю – бета-тестирование (beta
testing)
О "До передачи пользователю – альфа-тестирование (alpha test-
ing)" мы еще поговорим.
О "После передачи пользователю – бета-тестирование (beta test-
ing)" уже говорили.
158
Тестирование Дот Ком. Часть 2
5. По критерию
«позитивности» сценариев
• позитивное тестирование (positive testing);
• негативное тестирование (negative testing).
Начнем со второго.
Пример
Допустим, что имя файла с банковскими транзакциями должно иметь
определенный формат:
bofa_< YYYYMMDD>_ach. txt,
где YYYY – это год в полном формате (2005), ММ – это месяц в полном
формате (01 – январь), DD – это день в полном формате (01 – первое
число месяца).
Этот файл служит в качестве ввода для программы process transactions,
которая ежедневно в 23:00
автоматически «забирает» его из директории /tmp/input_files/,
анализирует (parse) его и
вставляет данные из него в базу данных.
Предположим, что из-за ошибки кода, генерирующего файл, имя фай-
ла от 18 января 2004 г. будет не
• bofa_20040t18_ach.txt (processtransactions ожидает именно и
буквально это имя), а
• bofa_2004118_ach.txt.
Какая реакция должна быть у программы process_transactions, если
она не может найти файл?
Ответ на этот вопрос может быть найден в спеке, где, например, может
быть указано, что в ситуации, когда файл не найден, process_ transac-
tions посылает соответствующему дистрибутивному списку е-мейл:
• с предметом (e-mail subject) "Ошибка: файл ввода для proc-
ess transactions отсутствует" и
• содержанием (e-mail body) "Файл bofa_20040118_ach.txt
отсутствует в директории /tmp/input_files/".
Если спек не предусматривает возможности возникновения такой си-
туации, то мы как тестировщики должны ее предусмотреть и создать
тест-кейс с соответствующим сценарием.
Итак, сценарий, проверяющий ситуацию, связанную с
• потенциальной ошибкой (error) пользователя и/или
• потенциальным дефектом (failure) в системе,
называется негативным.
Классификация видов тестирования
159
Пример ошибки пользователя
ВВОД недействительных данных в поле «Имя» на странице регистрации.
Пример дефекта в системе
Вышеуказанный пример о неправильной генерации имени файла.
Создание и исполнение тест-кейсов с негативными сценариями
называется НЕГАТИВНЫМ тестированием.
Далее.
Позитивные сценарии – это сценарии, предполагающие нор-
мальное, «правильное»
• использование и/или
• работу системы.
Первый пример позитивного сценария
Ввод действительных данных в поле «Имя» на странице регистрации.
Второй пример позитивного сценария
Проверка работы системы, когда имя файла имеет правильный фор-
мат: bofa_20040l 18_ach.txt.
Создание и исполнение тест-кейсов с позитивными сценариями
называется ПОЗИТИВНЫМ тестированием.
Несколько мыслей вдогонку:
а. Как правило, негативное тестирование находит больше
багов.
б. Как правило, негативное тестирование – вещь более слож
ная, творческая и трудоемкая, так как спеки описывают,
как должно работать, когда "усе в порядке", а не как долж
но работать в ситуациях с ошибками или сбоями.
в. Если есть позитивные и негативные тесты как часть тест-
комплекта, то позитивные тесты исполняются в первую
очередь. Логика:
В большинстве случаев целью создания функционачьности
является возможность реализации именно позитивных
сценариев, т.е. работоспособность позитивных сценариев
более приоритетна, чем работоспособность негативных
сценариев.
г. Существуют спеки, полностью посвященные тому, как долж
на себя вести система при ошибках/дефектах. Следователь
но, все тестирование такого спека будет негативным.
160
Тестирование Дот Ком. Часть 2
д. Два полезных термина:
• обращение с ошибкой/дефектом (error handling /failure
handling) – это то, как система реагирует на ошиб-
ку/дефект;
• сообщение об ошибке (error message) – это информа-
ция (как правило, текстовая), которая выдается пользо-
вателю в случае ошибки/сбоя.
Маленький примерчик вдогонку
Правильность сообщений об ошибке является намного более серьез-
ной вещью, чем может показаться, при рассуждениях об этом в теории.
Например, сегодня я попытался купить по Интернету новую книгу Хару-
ки Мураками:
• добавил книгу в корзину на одном из сайтов,
• вбил номер кредитки в соответствующие поля веб-страницы и
• нажал кнопку «Купить».
Мне выдается сообщение об ошибке: так, мол, и так, проверьте, пожа-
луйста, номер своей кредитной карты, дорогой пользователь. Я про-
веряю – все в порядке: и номер карты, и срок действия. Нажимаю
«Купить» еще раз – го же сообщение об ошибке. Пробую вбить инфор-
мацию по другой карте – то же самое. Начиная с этого момента,
успешное осуществление акции покупки новой книги Харуки Мура-
ками стало для меня делом принципа. Звоню в службу поддержки, и
мне говорят
– А вы, кстати, поставили галочку в чек-бокс (check box), что
согласны
с нашим соглашением?
-Нет.
– А вы поставьте и попробуйте нажать на кнопку «Купить».
– Ставлю, пробую, работает.
– Ну вот и славненько. Чем-нибудь еще можем быть полезны?
– Ничем. Thank you.
В итоге я потерял 15 минут своего времени, а веб-сайт потерял меня
как пользователя, так как «ложечки нашлись, а осадок остался». Все
из-за неверного сообщения об ошибке.
6. По степени изолированности
тестируемых компонентов
• компонентное тестирование (component testing);
• интеграционное тестирование (integration testing);
• системное (или энд-ту-энд) тестирование (system or
end-to-end testing).
Сначала краткие и емкие определения, а затем иллюстрации.
Классификация видов тестирования
161
Компонентное тестирование (component testing) – это тестиро-
вание на уровне логического компонента. И это тестирование
самого логического компонента.
Интеграционное тестирование (integration testing) – это тести-
рование на уровне двух или больше компонентов. И это тестиро-
вание взаимодействия этих двух или больше компонентов.
Системное (или энд-ту-энд) тестирование (system or end-to-end
testing) – это проверка всей системы от начала до конца.
Теперь иллюстрации кратких и емких определений.
Допустим, программисту поставлена задача написать код, который
бы находил полные имена и е-мейлы пользователей, потра-
тивших больше 1000 долл. в нашем онлайн-магазине с момента
регистрации. Таким пользователям должен быть отправлен е-мейл
с подарочным сертификатом, использование которого до 17 но-
ября включительно предоставит 5%-ю скидку на любую разовую
покупку.
Кстати, для добротного тестирования данной функциональности нужно
написать гораздо больше тест-кейсов, чем я приведу, но сейчас наша
задача – это понять
суть каждого из трех рассматриваемых видов тестирования и
разницу между ними.
КОМПОНЕНТНОЕ ТЕСТИРОВАНИЕ
Для начала выделим три компонента, которые мы протестиро-
вали бы:
1. Создание файла с полными именами, е-мейлами и номера-
ми сертификатов.
2. Рассылка пользователям е-мейлов.
3. Правильное предоставление скидки вышеуказанным поль-
зователям.
Проверяем.
Компонент 1
Проверяем, что создается файл нужного формата
• с полными именами и е-мейлами пользователей, потратив-
ших > 1000 долл., и
• номером сертификата для каждого из этих пользователей.
162
Тестирование Дот Ком. Часть 2
Это позитивное тестирование.
Мы также должны проверить, не затесались ли в наш файл
пользователи, потратившие < 1000 долл.
Это негативное тестирование, связанное с потенциальным дефек-
том в коде, отвечающем за выбор правильных пользователей.
Компонент 2
Допустим, код первого компонента, который должен был создать
для нас файл, не работает. Мы не отчаиваемся, а просто вручную,
не ропща на судьбу, создаем файл установленного формата с взя-
тыми с потолка
• е-мейлами,
• полными именами пользователей и
• номерами подарочных сертификатов.
Этот файл мы "скармливаем" программе рассылки е-мейлов и
проверяем, что правильные е-мейлы доходят до пользователей из
файла(позитивное тестирование).
Компонент 3
Как мы помним, компонент 1 не работает. Что делать?
Сертификат – это как некий код, например «UYTU764587657».
который нужно ввести во время оплаты, и если сертификат дей-
ствительный, то итоговая сумма к оплате уменьшается.
В данном случае можно попросить программиста, чтобы тот по-
мог сгенерировать легитимные номера сертификатов. Когда но-
мера сертификатов имеются в наличии, можно, например, прове-
рить, работает ли подарочный сертификат только один раз (пози-
тивное тестирование) или его можно использовать для двух или
более транзакций (негативное тестирование, воспроизводящее
ошибку пользователя, использующего сертификат более одного
раза). Также нужно будет проверить размер скидки (5%) (пози-
тивное тестирование) и действительность сертификата:
до 17 ноября (позитивное тестирование), 17
ноября (позитивное тестирование) и
после 17 ноября (негативное тестирование, воспроизводящее
ошибку пользователя, использующего просроченный сер-
тификат).
Классификация видов тестирования
163
Кстати, в случаях когда тестирование связано со сроками (например,
сроком истечения сертификата), мы, естественно, не ждем до 17 но-
ября, а просто меняем системное время тест-машины на нужное время
или меняем значение времени в базе данных. Естественно, что такие
изменения вы должны предварительно согласовать с коллегами, кото-
рые работают на той же тест-машине или с той же базой данных.
Важный момент: хотя по спеку все три компонента и взаимосвя-
заны, из-за проблем в коде у нас получилось компонентное тес-
тирование в чистом виде. Другими словами, мы тестировали са-
ми компоненты, а не связь между ними.
Тестирование связи между компонентами называется интегра-
ционным тестированием.
ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ
У нас есть три связи между компонентами:
а) между 1-м и 2-м компонентами;
б) между 2-м и 3-м компонентами;
в) между 1-м и 3-м компонентами.
Подробности:
а. Компонент 1 генерирует файл со списком
• е-мейлов и полных имен подходящих пользователей и
• номерами сертификатов.
Этот список используется компонентом 2, который ответ-
ствен за рассылку е-мейлов.
б. Компонент 2 доставляет пользователю в качестве е-мейла
информацию о подарочном сертификате. Пользователь
может использовать сертификат (компонент 3), только ес
ли он знает правильный номер своего сертификата.
в. Компонент 1 генерирует код сертификата, который ис
пользуется компонентом 3.
Итак, в нашем случае при интеграционном тестировании у нас
есть для проверки 3 связи. Приведем примеры соответствующих
тестов на интеграцию.
а. Здесь можно проверить, совместим ли формат файла, соз-
данного компонентом 1, с программой рассылки компонента 2.
Например, последняя принимает следующий формат файла:
полное имя пользователя, е-мейл, номер сертификата.
164
Тестирование Дот Ком. Часть 2
Значения отделены друг от друга запятой (comma-delimited). Ин-
формация о каждом новом пользователе – на новой строчке.
Сам файл – простой текстовый файл, который можно открыть
программой Notepad.
Образец файла:
Ferdinando Magellano, [email protected], QWERT98362
James Cook, [email protected], ASDFG54209 Иван
Крузенштерн, [email protected], LKJHG61123
Допустим, программист ошибочно заложил в коде, что значения
файла разделяются не запятой (форматом, принимаемым про-
граммой рассылки), а точкой с запятой:
Ferdinando Magellano; [email protected]; QWERT98362
James Cook; [email protected]; ASDFG54209 Иван
Крузенштерн; [email protected]; LKJHG61123
Когда мы проводим интеграционный тест, мы обнаруживаем, что
программа рассылки не принимает файл неподходящего формата,
и соответственно никакие е-мейлы до пользователей не дойдут,
если этот баг не будет устранен.
б. В данном случае у нас может быть ситуация, когда файл
имеет верный номер сертификата, но из-за бага в программе рас
сылки пользователь получает е-мейл с "неправильным" номером
сертификата.
Это может произойти из-за того, что программа рассылки
может быть ошибочно сконфигурирована, чтобы "брать"
только 9 первых символов из третьей колонки (колонки с номе-
рами сертификатов), т.е. QWERT98362 будет преподнесена поль-
зователю в укороченном виде (truncated): QWERT9836.
Интеграционный тест по использованию номера сертификата,
полученного по е-мейлу, может выявить этот баг.
в. Здесь может быть ситуация, когда номер сертификата, сгене
рированный компонентом 1, не принимается компонентом 3.
Пример такой ситуации
Компонент 1 сохранил номер сертификата в базе данных в зашифро-
ванном виде, т.е. в целях безопасности использовался алгоритм, кото-
рый превратил «LKJHG61123», например, в «*&»(*&86%(987$!$#". Из-за
бага в компоненте 3 последний не дешифровал номер сертификата,
Классификация видов тестирования
165
ВЗЯТЫЙ из БД, а просто попытался сравнить эту абракадабру из БД и
номер сертификата, введенный пользователем, что привело к тому,
что номера не сошлись и легитимная скидка не была предоставлена.
Должен ли был быть номер сертификата зашифрован или нет, для
нас сейчас значения не имеет. Значение имеет тот факт, что баг
был обнаружен во время интеграционного тестирования.
СИСТЕМНОЕ ТЕСТИРОВАНИЕ
Это тестирование системы (функциональности) от начала до
конца (end-to-end), т.е. каждый сценарий будет затрагивать всю
цепочку: компонент 1 – > компонент 2 —> компонент 3.
Я рекомендую ставить простой тест-кейс с системным тестом
в самое начало тест-комплекта. Так можно сразу увидеть, если
что-то явно не в порядке. Это своего рода тест приемки непосред-
ственно для вещи, тестируемой данным тест-комплектом.
Хорошая идея вдогонку
Е-мейл состоит из следующих частей:
е-мейла алиаса;
собаки;
домена почтового сервера;
точки;
глобального домена.
В вашем рабочем е-мейле алиасом будет, как правило, ваши имя (или
инициал) и фамилия: rsavin.
Собака остается собакой, хотя по-аглицки она называется «at» (читает-
ся как «эт»):
@ Доменом почтового сервера будет домен
компании:
testshop
Точка остается точкой, хотя по-аглицки она называется «dot» (читается
как «дот»):
.
Глобальный домен – это зона домена компании, например «com» или «ги»:
rs,
т.е. получаем: [email protected]
При тестировании интернет-проектов приходится создавать много сче-
тов пользователей. Загвоздка в том, что е-мейл пользователя, который
очень часто является его именем, может быть использован только один
раз, т.е. мой рабочий е-мейл [email protected] может быть использо-
ван для создания только одного счета.
166
Тестирование Дот Ком. Часть 2
ЧТО делать? Открывать бесчисленные счета на хотмейлах и яху? Ответ
неверный.
Самая хорошая идея: поговорите с администратором почтового сер-
вера вашей компании, чтобы он модифицировал настройки сервера
так, чтобы к вам приходили все е-мейлы следующего формата:
rsavin+sometext@testshop. rs,
т. е. после моего алиаса стоит знак плюс и между знаком плюс и соба-
кой находятся любые легитимные знаки.
Например, для тестирования компонента 1 я регистрируюсь с е-мейлом:
Таким образом, вы можете создавать тысячи эккаунтов пользователей
своего сайта, не регистрируя тысяч новых е-мейл-эккаунтов.
Рекомендую. Очень удобно.
7. По степени автоматизированное™
тестирования
• ручное тестирование (manual testing);
• автоматизированное тестирование (automated testing);
• смешанное / полуавтоматизированное тестирование
(semi automated testing).
О каждом из трех "друзей" будет еще сказано очень много и в
подробностях. Пока же давайте поговорим концептуально.
РУЧНОЕ ТЕСТИРОВАНИЕ
Это исполнение тест-кейсов без помощи каких-либо программ,
автоматизирующих вашу работу. Например, для того чтобы
создать эккаунт нового пользователя, мы идем на наш
www.main.testshop.rs, открываем страницу регистрации, запол-
няем формы и т.д.
АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ
Это отдельная дисциплина искусства тестирования. Значительная
часть эффективности работы отдела тестирования зависит от
того, какие задачи отданы для автоматизации и как эта автома-
тизация была осуществлена. Автоматизация может как принести
огромное облегчение всем тестировщикам, так и завалить работу
всего отдела и отложить релиз, премию, отпуск и другие сладкие
вещи.
Классификация видов тестирования
167
Оговорка
Термин «тул» (tool (англ.) – инструмент) используется для обозначения
компьютерной программы, как правило, вспомогательного свойства.
Автоматизировать можно сотни вещей. Вот наиболее часто
встречающиеся виды автоматизации:
а. Тулы для помощи в черноящичном и сероящичном тес-
тировании.
Например,
• тул, который автоматически создает для нас эккаунт поль-
зователя;
• тул, совершающий запросы к базе данных и генерирующий
файлы формата, утвержденного системой VISA, используя
извлеченные данные;
• тул, генерирующий транзакции покупки в нашем магазине,
и т.д. и т.п.
Вариантам нет конца и края. Такие тулы пишутся программиста-
ми компании или самими тестировщиками.
Пример тула, создающего эккаунты пользователя
Если набрать в браузере www.main.testshop.rs/tools/register.py (это
все, естественно, гипотетически, так как такого сайта в природе не су-
ществует), то мы увидим не 10 обязательных полей, которые нужно за-
полнить, а одно текстовое поле и кнопку «создать тест-эккаунт». Вы
просто вводите уникальный е-мейл нового пользователя, например
[email protected], и нажимаете на кнопку. Тул делает за
вас все остальное. Пароль для всех эккаунтов будет, например «898989».
Хорошая идея:
используется автоматизация для создания новых эккаунтов или
нет, очень удобно, когда в компании существует конвенция для
одного пароля при создании тест-эккаунтов, например «898989».
Дело в том, что иногда нет времени/возможности создать эккаунт
с определенными транзакциями, настройками и т.д., и если такой
эккаунт уже существует, то, зная пароль, вы сможете им воспользо-
ваться.
При этом помните о деловой этике, и если этот эккаунт создан не вами,
то по возможности вежливо спросите у «хозяина» эккаунта разрешение.
б. Программы для регрессивного тестирования
Это специальное ПО, созданное для буквального воспроизведе-
ния действий тестировщика.
168
Тестирование Дот Ком. Часть 2
Пример
Согласно тест-кейсу вы должны
• войти в систему,
• выбрать товар,
• положить его в корзину,
• заплатить и
• удостовериться, что баланс на кредитной карте уменьшился на
сумму покупки.
Чтобы исполнить этот тест-кейс, вы должны запустить браузер, ввести
имя пользователя и пароль, нажать на кнопку «Вход»... и, в конце кон-
цов, сравнить фактический и ожидаемый результаты.
Теперь представьте себе, что некая программа делает те же самые
действия, что и вы, т.е. сама запускает браузер, печатает, где положе-
но, имя пользователя и пароль, нажимает на кнопку «Вход»... и, в конце
концов, сравнивает ожидаемый и фактический результат и сообщает
вам о нем (через сообщение на экране, запись в файле, е-мейл и т.д.).
Такое ПО, как правило, поддерживает режим "Запись / Воспроиз-
ведение", т.е. когда мы нажимаем на кнопку "Запись" и начинаем
кликать мышками и клацать клавишами клавиатуры, ПО записы-
вает наши действия и, когда мы закончили, генерирует код. Этот
код мы можем запустить с этим же ПО, и оно воспроизведет все
наши клики и клацы, т.е. буквально будет водить курсором мыш-
ки, набирать текст и т.д.
Такое ПО, как правило, имеет собственный язык программиро-
вания, т.е. можно не записывать свои действия, а непосредст-
венно написать код, что и делается теми, кто профессионально
работает с таким ПО.
Наиболее популярная и мощная программа для автоматизации
регрессивного тестирования веб-проектов – это Silk Test, выпус-
каемый компанией Segue.
У нас будет отдельная беседа о хороших и плохих вещах, связан-
ных с автоматизацией регрессивного тестирования.
