Лекция3

Методы тестирования

Белый ящик

Полностью покрыты все :

… строки кода программы

… ветви в коде программы

… пути в коде программы

Черный ящик

Полностью покрыты все:

… входные данные

… комбинации входных данных

… последовательности комбинаций

входных данных

Black Box

= specification-based testing: Testing, either functional or

non-functional, without reference to the

internal structure of the component or system.

White Box

=clear-box testing= structural testing: Testing based on

an analysis of the internal structure of the component or

system

Test Types (Виды тестирования)

Functional testing

Non- Functional testing

Structural testing

Testing related to changes

Functional testing

Функциональное тестирование (Functional

testing)

Тестирование безопасности (Security and

Access Control Testing)

Тестирование взаимодействия (Interoperability

Testing)

Non - Functional testing

Нагрузочное тестирование (Performance and LoadTesting)

Стрессовое тестирование (Stress Testing)

Тестирование стабильности или надежности(Stability / Reliability Testing)

Объемное тестирование (Volume Testing)

Тестирование установки (Installation testing)

Тестирование удобства пользования (UsabilityTesting)

Тестирование на отказ и восстановление (Failoverand Recovery Testing)

Конфигурационное тестирование (ConfigurationTesting)

Testing related to changes

Дымовое тестирование (Smoke Testing)

Регрессионное тестирование (Regression Testing)

Тестирование сборки (Build Verification Test)

Санитарное тестирование или проверка

согласованности/исправности (Sanity Testing)

Source: http://www.protesting.ru/testing/testtypes.html

Документы, создаваемые в ходе

жизненного цикла проекта.

Документация,

Которую тестировщик использует:

Требования,

Инструкции,

ТЗ

Спецификации

User story

Архитектра

Зачем нужно создавать документы? Для кого они создаются?

Документация, которая создается для проведения тестирования:

Тест планы

Чек листы

Тест кейзы , test suit

Traceability_matrix

Bugreport

Test result report

Тест-требования :

основной документ для

тестировщика, который

определяет

функциональность системы

с точки зрения того, что

должно быть проверено,

чтобы удостовериться в ее

корректном

функционировании, а также

- на основании

какого внешнего

эффекта можно убедиться,

что проверяемая функция

реализована правильно.

http://www.intuit.ru/studies/courses/1040/209/lecture/5396?page=2#sect3)

Какие бывают требования?

Уровни требований:

Бизнес требования

Функциональные

Нефункциональные

User story- бизнес требования.- высказанные от имени

конечных пользователей, из которых понятно, что должен

делать пользователь в системе для реализации своих нужд:

Как, <роль/персона юзера>, я <что-то хочу получить>,

чтобы <с такой-то целью> .

Пример:

Как пользователь, я могу хранить свои фото в системе,

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

Пример про цветок самолет

И функциональные и не функциональные требования должны обладать свойствами:

Корректность

Недвусмысленность (однозначность)

Полнота

Непротиворечивость (совместимость или согласованность)

Упорядоченность (ранжированность по важности и стабильности)

Проверяемость ( верифицируемость)

осуществимость

Модифицируемость

Трассируемость (прослеживаемость)

Понятность(ясность)

Test Plan План тестирования

стратегия тестирования (test strategy): Высокоуровневое описание уровней тестирования, которые должны быть выполнены, и тестирования, входящего в эти уровни, для организации или программы из одного или более проектов.

test plan: Документ, описывающий цели, подходы, ресурсы и график запланированных тестовых активностей. Он определяет объекты тестирования, свойства для тестирования, задания, ответственных за задания, степень независимости каждого тестировщика, тестовое окружение, метод проектирования тестов, определяет используемые критерии входа и критерии выхода и причины их выбора, а также любые риски, требующие планирования на случай чрезвычайных обстоятельств.

http://www.intuit.ru/studies/courses/1040/209/lecture/5396?page=2

Из чего состоит план тестирования

ЧТО надо тестировать

Что будем тестировать: карта функциональности (feature map)

Разделение функциональности на части: по внешнему виду, по бизнес

ценности, рискованности для тестирования.

КАК будем тестировать? - тест стратегия , виды тестирования.

ГДЕ -необходимые для тестирования оборудование и программные

средства

КОГДА -последовательность проведения работ:

- подготовка (Test Preparation),

- тестирование (Testing),

- анализ результатов (Test Result Analisys)

Критерии начала тестирования:

готовность тестовой платформы (тестового стенда)

законченность разработки требуемого функционала

наличие всей необходимой документации

Критерии окончания тестирования:

результаты тестирования удовлетворяют критериям качества продукта:

требования к количеству открытых багов выполнены

выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)

выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)

Ответственности и риски и пути их решения

..далее:

Source: Посмотреть на стандарты: http://www.protesting.ru/testing/plan.htmlПримеры планов: http://software-testing.ru/library/testing/general-testing/91

http://blog.shumoos.com/archives/267http://iqa.com.ua/documentation/testplan

Посмотреть ISTQB раздел 5.2

Подготовка наборов тестовой документации (Test Case) и

чеклистов (check-list)

Test Case- Минимальная единица тестирования, которая описывает

совокупность шагов, конкретных условий и параметров, которые необходимы

для проверки тестир. Функциональности

Зачем нужен тестовый сценарий?

•Проверить конкретную область, характеристику и т.д. функционала с требуемой

степенью детализации.

В качестве бонусов:

•Можно получить полезную документацию и использовать как оракул.

•Обучение новичков.

Подготовка наборов тестовой документации (Test

Case) и чеклистов (check-list)

Чек-лист (check list) — это документ, описывающий что должно быть

протестировано. При этом чек-лист может быть абсолютно разного

уровня детализации. На сколько детальным будет чек-лист зависит от

требований к отчетности, уровня знания продукта сотрудниками и

сложности продукта. [Testopedia]

Как правило, чек-лист содержит только действия (шаги), без

ожидаемого результата. Чек-лист менее формализован чем тестовый

сценарий. Его уместно использовать тогда, когда тестовые сценарии

будут избыточны. Также чек-лист ассоциируются с гибкими подходами в

тестировании.

Зачем нужен чек-лист?

•Не забыть что-то протестировать.

•Помогает осуществлять контроль за тестированием.

Что такое Test suit и Test run

Тестовый набор (Test Suite) - это комбинация тест скриптов, для

проверки определенной части программного обеспечения,

объединенной общей функциональностью или целями, преследуемыми

запуском данного набора.

Тесты для запуска (Test Run) - это комбинация тест скриптов или

тестовых наборов для последующего совместного запуска

(последовательного или параллельного, в зависимости от

преследуемых целей и возможностей инструмента для

автоматизированного тестирования).

Test rail, testlink, excel , bugtracker. Ort.testrail.net

Смотрим примеры чек листов и

практикуемся

Сборник чек и чит-листов для помощи в тестировании : http://www.ukrqa.org.ua/index.php/knowledge-base-

practice/category/%D1%87%D0%B5%D0%BA-%D1%87%D0%B8%D1%82-

%D0%BB%D0%B8%D1%81%D1%82%D1%8B-qa-patterns

!Checklists.xls

Создание чеклистов для ListBoxer:

Делим ListBoxer по функционалу:

Инсталляция

Сортировка

Фильтрация

Работа с файлами

Ввод данных

Test rail, testlink, excel , bugtracker. Ort.testrail.net