К основному контенту

С чего начинать изучение тестирования? Конечно же с методов!

На рисунке 1 представлена классификация тестирования. В этом блоге речь пойдет о методах тестирования или по другому – по доступу к коду и архитектуре приложения. 
                                             Рисунок 1. Классификация тестирования.
            Метод черного ящика – без доступа к коду.
Чтобы разобраться, приведу простой пример. Любой пользователь работает с тем или иным приложением каждый день. Сам того не зная, он тестирует это приложение. Тестирование проводится методом черного ящика, так как пользователь видит только интерфейсную часть с необходимым функционалом. Разница только в том, что пользователь уже работает с протестированным и отлаженным приложением, а тестировщик проверяет приложение до попадания его в руки пользователя.
Метод белого ящика (иначе еще говорят «стеклянного») – с доступом к коду.
Чтобы тестировать данным методом, у сотрудника должны быть знания для понимания увиденного. Чаще всего таким методом (должны J) тестируют разработчики, когда пишут код приложения. Но также этим методом приложение проверяют тестировщики, например, написав модульный тест.
Тестирование данным методом имеет такие преимущества, как:
- направленность тестирования;
- покрытие кода;
- управление потоком;
- отслеживание целостности данных;
- внутренние граничные точки;
- тестирование, определяемое выбранным алгоритмом.
Метод серого ящика - комбинация методов белого ящика и чёрного ящика, состоящая в том, что к части кода и архитектуры у тестировщика доступ есть, а к части — нет.
Приведем яркий пример. Допустим, мы тестируем функциональность страницы "регистрация":
• заполняем все поля (имя, адрес, е-мейл и т.д.) и
• нажимаем кнопку "Зарегистрироваться".
Следующая страница — подтверждение регистрации. Увидев сообщение или страницу с подтверждением регистрации, это не означает, что регистрация была успешной. Во время окончания регистрации должна появиться запись в базе данных. Тестировщику необходимо проверить как методом черного ящика (страница регистрации), так и методом белого ящика (запись в БД).
Методы белого и чёрного ящика не являются конкурирующими или взаимоисключающими, напротив, они гармонично дополняют друг друга, компенсируя таким образом имеющиеся недостатки.


Комментарии

Популярные сообщения из этого блога

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н

Тест план и тестовая модель - что это?

Test Plan (тест план)  — это документ или совокупность документов, расписывающих всю тестовую активность (цели, подходы, ресурсы и график запланированных тестовых активностей)  в пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:   1) Test plan identifier (идентификатор);   2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования);   3) Features to be tested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. 4) Features not to be tested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключе

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из * Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия – заключительные ша