Процесс тестирования, Разработка тест-кейсов - Тестирование программного обеспечения

Тестирование представляет собой процесс проверки того, насколько программное обеспечение соответствует требованиям, заявленным заказчиком. Он осуществляется в специальных, искусственно создаваемых ситуациях посредством наблюдения за работой программного обеспечения. Такого рода искусственно построенные ситуации называют тестовыми или просто тестами.

Разработка тестов происходит на основе проверяемых требований и критерия полноты тестирования. Разработанные тесты формируются в тест-кейс (набор тестов) и выполняются на ПО, которое нужно протестировать. После прогона всех тестов анализируется результат, в результате чего можно выявить ошибки в программе.

Процесс тестирования схематично показан на рисунке 2.

процесс тестирования

Рисунок 2. Процесс тестирования.

Разработка тест-кейсов

Тест-кейс (тестовый случай) - это минимальный элемент тестирования (одна проверка), содержащий в себе описание конкретных действий, условий и параметров, которые направленны на проверку какой-либо функциональности. Набор тест-кейсов называется тестовым набором (test suite).

Тест-кейсы позволяют тестировщикам провести проверку продукта без полного ознакомления с документацией. При условии, что созданный тест-кейс удобен в поддержке, то, написанный один раз, он позволит сэкономить большое количество времени и усилий тестировщиков. Подробные тест-кейсы также способны существенно снизить вариативность выполнения тестов различными тестировщиками, что повышает качество тестирования.

Атрибуты тест-кейса.

Тест-кейс должен включать в себя:

    - Уникальный идентификатор тест-кейса. Этот идентификатор необходим для удобства организации и навигации по тестовым наборам. - Название. В названии должна отражаться основная идея тест-кейса, цель данной проверки. - Предусловия. Список шагов, не имеющих прямого отношения к проверяемому функционалу, которые необходимо выполнить до начала теста. Например, для тест-кейса "Заказ товара" предусловием может быть шаг "авторизоваться на сайте", если на данном сайте заказать товар может только авторизованный пользователь. - Шаги. Описание последовательности действий, которая должна привести к ожидаемому результату. - Ожидаемый результат. Поведение системы, предусмотренное требованиями. Один тест-кейс проверяет одну конкретную функцию, поэтому ожидаемый результат может быть только один. - Статус кейса. Проставляется в соответствии с тем, соответствует ли фактический результат ожидаемому. Тест-кейс может иметь один из трех статусов:
      - Положительный, если фактический результат совпадает с ожидаемым результатом. - Отрицательный, если фактический результат не совпадает с ожидаемым результатом. Если статус кейса отрицательный-найдена ошибка. - Выполнение теста блокировано, если после одного из шагов продолжение теста невозможно. В этом случае так же, найдена ошибка.
    - История редактирования. Дает возможность узнать, кем и когда был изменен тест-кейс. Это удобно, поскольку позволяет более эффективно редактировать тест-кейсы.

Требования к тест-кейсу

    - Для измерения покрытия требований, требования к продукту должны быть проанализированы и впоследствии разбиты на пункты. Если тест-кейсы покрывают все требования, то может быть дан положительный или отрицательный ответ о реализации данного требования в продукте. - Тест является хорошим в случае, когда он может обеспечить высокую вероятность обнаружения ошибки. Показать, что в программе полностью отсутствуют ошибки невозможно, поэтому процесс тестирования должен быть направлен на выявление прежде не найденных ошибок. - Четкие, однозначные формулировки шагов. Описание шагов для прохождения тест-кейса должно содержать всю необходимую информацию, но при этом тест-кейс не должен быть слишком детализирован. Например, если тест-кейс содержит такие шаги, как авторизация, в описании необходимо указывать логин и пароль, но не нужно указывать в каком углу экрана находится окно авторизации. - Отсутствие зависимостей тест-кейсов. Если тесты связанны между собой, становится проблематичным изменение, дополнение или удаление конкретного тест-кейса, появляется необходимость изменять связанные с ним тесты. Более того, взаимосвязанные тесты обладают конкретный сценарием от перехода одного теста к другому. Это приведет к тому что не все сценарии перехода от одного теста к другому будут протестированы и появляется вероятность пропустить баг. - Ожидаемый результат необходимо прогнозировать заранее и прописывать его в тест-кейсе. Если ожидаемый результат не определить заранее, может возникнуть ситуация, когда тестировщик видит то, что он хочет увидеть. При заранее определенном результате тестировщику необходимо только сравнить ожидаемый результат с фактическим. - Необходимо уделять внимание не только тестам, которые проверяют правильные данные, но и тем тестам, которые проверяют работу программы при неправильных, непредусмотренных данных. Большое количество ошибок связано именно с теми действиями пользователя, которые не предусмотрены программой. - Также необходимо проверять, не делает ли программа то, чего не должна. Нужно производить проверку на нежелательные побочные эффекты.

В таблице 1 приведен пример тест-кейса, отвечающего вышеописанным требованиям.

Таблица 1. Пример тест-кейса.

Тест PGU-1: ВСВ. Избранные услуги

Описание теста: цель, сценарий и исходное состояние программы:

Проверка работы функциональности "Избранные услуги"

#:

Шаги:

Ожидаемая реакция:

Execution Status:

1

Авторизоваться на портале.

Авторизация прошла успешно.

Пройден

2

Перейти в версию для слабовидящих, кликнув на соответствующую иконку в левом верхнем углу.

Открылась главная страница портала в версии для слабовидящих.

Пройден

3

Перейти в каталог услуг, открыть любую карточку услуги.

Карточка услуги открыта успешно.

Пройден

4

Нажимаем "Добавить услугу" внизу страницы.

Попап "Услуга успешно добавлена в избранные. Вы можете перейти к ней из Личного кабинета".

Пройден

5

Повторяем шаги 3-4 несколько раз.

Шаги выполнены успешно, результаты соответствуют ожидаемым.

Пройден

6

Переходим в Личный кабинет.

По умолчанию открывается раздел "Мои услуги". Отображается пронумерованный список добавленных услуг в порядке их добавления.

Пройден

7

Проверяем переход на карточку услуги из списка избранных услуг.

Переход происходи корректно.

Пройден

8

Переходим обратно в ЛК. Отмечаем галочкой любую услугу.

Появилась кнопка "Удалить" внизу страницы.

Пройден

9

Нажимаем кнопку "Удалить"

Попап "Услуга успешно удалена из избранных.". Услуга пропала из списка избранных услуг.

Пройден

10

Поочередно удаляем остальные услуги.

Удаление прошло корректно.

Пройден

Execution type:

Вручную

Estimated exec. duration (min):

10.00

Приоритет:

Medium

Execution Details

Версия (сборка)

3.0.111 /2.10.31

Тестировщик

\n Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script

Execution Result:

Пройден

Execution Mode:

Вручную

Данный тест-кейс содержит следующие обязательные атрибуты:

    - Уникальный идентификатор тест-кейса: PGU-1 - Название: ВСВ. Избранные услуги - Предусловия: в данном тест-кейсе предусловием является авторизация на портале. Непосредственно к тесту авторизация не относится (авторизацию на портале проверяет отдельный тест-кейс), но без авторизации данная проверка невозможна. - Шаги. - Ожидаемый результат. - Статус кейса. - История редактирования: в тест-кейсе указана информация о том, кто проходил тест, в какое время и в рамках какой сборки.

Данный тест-кейс отвечает требованиям, изложенным выше. Шаги сформулированы однозначно, содержат необходимую, но не лишнюю информацию, ожидаемый результат четкий и однозначный.

Похожие статьи




Процесс тестирования, Разработка тест-кейсов - Тестирование программного обеспечения

Предыдущая | Следующая