15. Цели и задачи тестирования?

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

16. В чем отличие тестирования от отладки?

Отладка программы — это специальный этап в разработке программы, состоящий в выявлении и устранении программных ошибок, факт существования которых уже установлен.

Тестирование позволяет выявить эти ошибки.

17. Что такое Верификация (verification) и что такое Валидация (validation)?

Верификация — подтверждение на основе представления объективных свидетельств того, что установленные требования были выполнены.

Валидация — подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены.

18. Какие стратегии\подходы тестирования Вы знаете? Перечислите их.

Подходы

• Black Box (нет доступа к исходному коду, тестирование с точки зрения конечного пользователя)

• White Box (есть доступ к исходному коду, позволяет проверить внутреннюю структуру программы, анализ приложения на уровне кода)

• Grey Box (есть доступ к части кода, смешанная методика)

19. Какие уровни тестирования Вы знаете? Перечислите их.

Уровни

• Модульное (Unit-testing) - тестирование независимых элементов кода

• Интеграционное (Integration-testing) – тестирование интерфейсов между протестированными модулями

• Системное (System-testing)

• Приемочное (Acceptance-testing) - тестирование на стороне заказчика

20. Какие виды тестирования Вы знаете? Перечислите их.

Виды

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

• Тестирование производительности (performance testing)

• Нагрузочное тестирование (load testing)

• Стресс-тестирование (stress testing)

• Тестирование безопасности

• Localization testing

• Platform testing

• Installation testing

• Regression testing

21. Перечислите основные этапы процесса тестирования.

• Planning (планирование – определение целей, стратегии, подготовка тестового окружения, расстановка приоритетов)

• Test-case design & creation (разработка тест-кейсов)

• Test-case execution (выполнение тест-кейсов в соответствии с приоритетами)

• Test-case review (просмотр кейсов другим тестером, внесение предложений)

• Bug verification (инициализация ошибок)

• Reporting & Metrics (оценка, метрики – проектные, процессные, product-метрики)

22. Что такое требование к ПО?

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

23. Какие бывают типы требований?

• Бизнес-требования —Содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью.

• Пользовательские требования —Описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

• Функциональные требования — определяют что должен реализовать продукт. Описывается в системной спецификации. Определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».  Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

• Нефункциональные требования – описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся: * легкость и простота использования * легкость перемещения * целостность * эффективность и устойчивость к сбоям * внешние взаимодействия между системой и внешним миром * ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

24. Что такое Test Case?

Test Case - это специальная, искусственно созданная ситуация, выбранная определённым образом, и описание того, какие наблюдения за работой программы нужно сделать для проверки её соответствия некоторому требованию

25. Что должно быть в описании тест-кейса (приведите пример)?

• Preconditions (предусловия) - список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния

• Actions, Steps (шаги) – список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о соответствии поставленным требованиям

• Expected Result (ожидаемый результат) – результат, который должен получиться после выполнения тест-кейса в соответствии с требованиями

26. Что такое Test Matrix (Тестовая матрица)?

Тестовая матрица – это матрица, в которой хранятся test cases со всеми необходимыми параметрами для их описания:

• ID

• Description

• Pre-Conditions

• Entry Point

• Actions

• Expected Result

• Requirement ID

• Priority

27. Что является источником\основанием для создания тест-кейсов?

Требования (Requirements)

28. Какие техники создания тест-кейсов Вы знаете? Перечислите и опишите основную идею каждой из них.

• Разбиение на классы эквивалентности

1. Выделяются правильные и неправильные классы эквивалентности;

2. Тестируется правильный класс для каждого корректного значения;

3. Тестируется одно некорректное значение за раз.

• Анализ граничных значений – проверяются значения на границе, а также значения больше граничного на единицу и меньше граничного на единицу; одно значение внутри интервала.

• Таблицы решений

1. Определяется список возможных условий и действий;

2. Определяются комбинации условий и действий;

3. Создается тест-кейс для каждого правила (столбца).

• Метод функциональных диаграмм

1. Осуществляется декомпозиция функциональных требований;

2. Выписываются причины, каждой из них присваивается уникальный номер;

3. Выписываются последствия, каждому из них также присваивается уникальный номер;

4. По спецификации составляется граф «причина-последствие»;

5. Строится таблица решений;

6. Записывается тест-кейс для каждого столбца.

29. Что такое «ошибка» (дефект, «баг»)?

Баг –дефект в программе. Это общий термин, используемый для описания ошибки, недостатка, сбоя или проблемы в программе или системе, которые приводят к неправильному или неожиданному результату, либо приводят к непредусмотренному поведению.

30. Какая информация обязательно должна быть в отчете об ошибке, чтобы ее можно было воспроизвести?

• Bug ID – номер ошибки

• Status – состояние ошибки

• Title – краткое описание

• Description – содержит информацию о шагах, ожидаемом и полученном результатах, версии билда, тестовом окружении

• Severity – может указывать тестировщик

• Priority – насколько ошибка критична для end-user’а

• Date – дата обнаружения

• Author – тестировщик, нашедший ошибку

• Test-case ID – номер тест-кейса в матрице

• Requirement ID – номер требования

• Responsible Person – девелопер, ответственный за исправление