tестирование dot com

компанию.

Идем дальше.

В идеальном случае каждый программист имеет личную версию

сайта (или playground— игровую площадку), в которую входят:

• веб-сервер (web server);

• сервер с приложением (application server);

• база данных (database).

Коротко остановимся на каждом из этих компонентов.

Пример

1. Пользователь набирает в браузере: www.testshop.rs. Через Интернет

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

сыпятся:

• файл index.htm, содержащий HTML (Hyper Text Markup Language)-код с

инкорпорированным в нем JavaScript (читается как "джава-скрипт")-

кодом;

• файлы-картинки (images), на которые ссылается веб-страница

index.htm. Эти картинки пользователь должен увидеть в веб-брау-

зере на веб-странице index.htm.

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

в веб-браузере после набора URL веб-сайта (например, www.google.com),

называется homepage.

Кстати, коммуникация между веб-браузером и веб-сервером осуще-

ствляется путем обмена сообщениями, основанными на протоколе, т.е.

своде правил, называемом HTTP (Hyper Text Transfer Protocol). Потоки

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

Интернетом, являются HTTP-трафиком (HTTP traffic).

2. Пользователь кликаетлинк "Регистрация" (веб-сервер присылает в

ответ файл register.htm и слинкованные с ним картинки).

3. На странице register, htm пользователь вводит имя, е-мейл и прочие

данные и отправляет форму, нажав кнопку "Зарегистрироваться".

88

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

4. Через веб-сервер эта форма, т.е. запрос о регистрации, поступает

на сервер с приложением, которое

• обрабатывает этот запрос;

• запрашивает базу данных, есть ли уже эккаунт с таким е-мейлом;

• обрабатывает ответ от базы данных;

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

нии записи для нового пользователя;

• формирует ответ для пользователя;

• в виде веб-страницы с подтверждением регистрации или веб-стра-

ницы с ошибкой посылает пользователю ответ через веб-сервер.

Так вот, программисты разрабатывают код вышеупомянутого

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

тировщикам, в злорадном предвкушении потирающим ручонки и

знающим, что причинами возникновения багов в коде явля-

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

нету, так и другие объективные вещи:

а. Некачественные и/или изменяющиеся спецификации

Об этом мы уже говорили.

б. Личностные качества программиста

Такие, как халатность, невнимательность и лень.

в. Отсутствие опыта

Программист может просто не знать, как нужно сделать пра-

вильно.

г. Пренебрежение стандартами кодирования

О стандартах чуть позже.

д. Сложность системы

Современные интернет-проекты отличаются такой сложностью,

что мозг простого смертного порой просто не в состоянии про-

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

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

е. Баги в ПО третьих лиц, т.е. баги

• в операционных системах;

• в компайлерах (compiler — ПО для переведения (напри-

мер, C++) кода в машинный язык и создания исполняе-

мых файлов);

• в веб-серверах;

• в базах данных и др.

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

89

ж. Отсутствие юнит-тестирования,

х.е. тестирования кода самим программистом: "И вообще, почему

я должен искать баги в своем коде, когда есть тестировщики?"

(Поговорим о юнит-тестировании через минуту.)

з. Нереально короткие сроки для разработки

Об этом мы тоже скоро поговорим.

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

передачи кода тестировщикам (иллюстрации последуют не-

медленно) включают:

1. Наличие требований к содержанию спеков и следова-

ние правилам их изменения;

2. Возможность прямой, быстрой и эффективной комму-

никации между программистами и программистами и

продюсерами;

3. Инспекции кода;

4. Стандарты программирования;