По времени проведения тестирования



ДО передачи пользователю — альфа-тестирование (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 минут своего времени, а веб-сайт потерял меня как пользователя, так как "ложечки нашлись, а осадок остался". Все из-за неверного сообщения об ошибке.


Дата добавления: 2018-05-02; просмотров: 401; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!