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

Савин Роман

ми компоненты, а не связь между ними.

Тестирование связи между компонентами называется интегра-

ционным тестированием.

ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ

У нас есть три связи между компонентами:

а) между 1-м и 2-м компонентами;

б) между 2-м и 3-м компонентами;

в) между 1-м и 3-м компонентами.

Подробности:

а. Компонент 1 генерирует файл со списком

• е-мейлов и полных имен подходящих пользователей

и

• номерами сертификатов.

Этот список используется компонентом 2, который ответ-

ствен за рассылку е-мейлов.

б. Компонент 2 доставляет пользователю в качестве е-мейла

информацию о подарочном сертификате. Пользователь

может использовать сертификат (компонент 3), только ес

ли он знает правильный номер своего сертификата.

в. Компонент 1 генерирует код сертификата, который ис

пользуется компонентом 3.

Итак, в нашем случае при интеграционном тестировании у нас

есть для проверки 3 связи. Приведем примеры соответствующих

тестов на интеграцию.

а. Здесь можно проверить, совместим ли формат файла, соз-

данного компонентом 1, с программой рассылки компонента 2.

Например, последняя принимает следующий формат файла:

полное имя пользователя, е-мейл, номер сертификата.

164

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

Значения отделены друг от друга запятой (comma-delimited). Ин-

формация о каждом новом пользователе — на новой строчке.

Сам файл — простой текстовый файл, который можно открыть

программой Notepad.

Образец файла:

Ferdinando Magellano, [e-mail], QWERT98362

James Cook, [e-mail], ASDFG54209 Иван

Крузенштерн, [e-mail], LKJHG61123

Допустим, программист ошибочно заложил в коде, что значения

файла разделяются не запятой (форматом, принимаемым про-

граммой рассылки), а точкой с запятой:

Ferdinando Magellano; [e-mail]; QWERT98362

James Cook; [e-mail]; ASDFG54209 Иван

Крузенштерн; [e-mail]; LKJHG61123

Когда мы проводим интеграционный тест, мы обнаруживаем, что

программа рассылки не принимает файл неподходящего формата,

и соответственно никакие е-мейлы до пользователей не дойдут,

если этот баг не будет устранен.

б. В данном случае у нас может быть ситуация, когда файл

имеет верный номер сертификата, но из-за бага в программе рас

сылки пользователь получает е-мейл с "неправильным" номером

сертификата.

Это может произойти из-за того, что программа рассылки

может быть ошибочно сконфигурирована, чтобы "брать"

только 9 первых символов из третьей колонки (колонки с номе-

рами сертификатов), т.е. QWERT98362 будет преподнесена поль-

зователю в укороченном виде (truncated): QWERT9836.

Интеграционный тест по использованию номера сертификата,

полученного по е-мейлу, может выявить этот баг.

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

рированный компонентом 1, не принимается компонентом 3.

Пример такой ситуации

Компонент 1 сохранил номер сертификата в базе данных в зашифро-

ванном виде, т.е. в целях безопасности использовался алгоритм, кото-

рый превратил "LKJHG61123", например, в "*&"(*&86%(987$!$#". Из-за

бага в компоненте 3 последний не дешифровал номер сертификата,

Классификация видов тестирования

165

ВЗЯТЫЙ из БД, а просто попытался сравнить эту абракадабру из БД и

номер сертификата, введенный пользователем, что привело к тому,

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

Должен ли был быть номер сертификата зашифрован или нет, для

нас сейчас значения не имеет. Значение имеет тот факт, что баг

был обнаружен во время интеграционного тестирования.

СИСТЕМНОЕ ТЕСТИРОВАНИЕ

Это тестирование системы (функциональности) от начала до

конца (end-to-end), т.е. каждый сценарий будет затрагивать всю

цепочку: компонент 1 — > компонент 2 —> компонент 3.

Я рекомендую ставить простой тест-кейс с системным тестом

в самое начало тест-комплекта. Так можно сразу увидеть, если

что-то явно не в порядке. Это своего рода тест приемки непосред-

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

Хорошая идея вдогонку

Е-мейл состоит из следующих частей: