Программа курса “Введение в тестирование ПО”. Статическое тестирование

Содержание

Слайд 2

- Виды тестирования?

- Виды тестирования?

Слайд 3

3. Статическое тестирование Статическое тестирование

3. Статическое тестирование

Статическое тестирование

Слайд 4

Статическое тестирование Cтатическое тестирование заключается в изучении свойств программы, не выполняя

Статическое тестирование
Cтатическое тестирование заключается в изучении свойств программы, не выполняя ее код.
Оно

может быть использовано как для нахождения дефектов еще на этапах проектирования и моделирования, так и проверки исходного кода программы (code review) на предмет использованных конструкций, алгоритмов, отношений модулей и компонентов программы и т.п. Во время статического тестирования можно получить информацию о свойствах программы: ее безопасность, возможность поддержки, надежность и эффективность.
Слайд 5

Процесс ревью, использование инструментальных средств для статического анализа С помощью code

Процесс ревью, использование инструментальных средств для статического анализа
С помощью code review

на раннем этапе могут быть выявлены ошибки в коде продукта. Как правило code review производится самими разработчиками.
Code review - инженерная практика в терминах гибкой методологии разработки. Это анализ (инспекция) кода с целью выявить ошибки, недочеты, расхождения в стиле написания кода, в соответствии написанного кода и поставленной задачи.
Слайд 6

Процесс ревью, использование инструментальных средств для статического анализа К очевидным плюсам

Процесс ревью, использование инструментальных средств для статического анализа
К очевидным плюсам этой

практики можно отнести:
Улучшается качество кода
Находятся «глупые» ошибки (опечатки) в реализации
Повышается степень совместного владения кодом
Код приводится к единому стилю написания
Хорошо подходит для обучения «новичков», быстро набирается навык, происходит выравнивание опыта, обмен знаниями
Слайд 7

Процесс ревью, использование инструментальных средств для статического анализа Примерами ошибок, которые

Процесс ревью, использование инструментальных средств для статического анализа
Примерами ошибок, которые потенциально

можно выявить с помощью автоматического статического тестирования, могут быть:
утечки ресурсов (утечки памяти, неосвобождаемые файловые дескрипторы и т.д.)
возможность переполнения буфера (buffer overflows)
ситуации частичной (неполной) обработки ошибок
Слайд 8

Процесс ревью, использование инструментальных средств для статического анализа Конкретные примеры инструментальных

Процесс ревью, использование инструментальных средств для статического анализа
Конкретные примеры инструментальных средств

статического тестирования для Java: Checkstyle, FindBugs, PMD (Programming Mistake Detector), для Javascript: JSLint.
Слайд 9

4. Динамическое тестирование Динамическое тестирование

4. Динамическое тестирование

Динамическое тестирование

Слайд 10

Динамическое тестирование производится путем запуска продукта и проверки его функционала. Проверка

Динамическое тестирование производится путем запуска продукта и проверки его функционала. Проверка

осуществляется с помощью ручного или автоматического выполнения заранее подготовленного набора тестов. 
Динамическое тестирование помогает определить свойства программы по результатам ее выполнения – соответствие функциональным требованиям, работа в разных средах, разных версий, локализация, нагрузка, работа с входными и выходными данными, – типов динамического тестирования очень много. Поэтому, в большинстве случаев, говоря слово «тестирование» подразумевается именно динамическое.

- Динамическое тестирование

Слайд 11

Тест план (Test plan) Тест дизайн (Test design) Тестовый случай(Test case) - Процесс разработки тестов

Тест план (Test plan)
Тест дизайн (Test design)
Тестовый случай(Test case)

- Процесс разработки

тестов
Слайд 12

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

- Процесс разработки тестов

Тест план (Test Plan) - это документ, описывающий

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

- Процесс разработки тестов Хороший тест план должен как минимум отвечать

- Процесс разработки тестов

Хороший тест план должен как минимум отвечать на

следующие вопросы:
Что надо тестировать?
описание объекта тестирования: системы, приложения, оборудование
Что будете тестировать?
список функций и описание тестируемой системы и её компонент в отдельности
Как будете тестировать?
стратегия тестирования, а именно: виды тестирования и их применение по отношению к тестируемому объекту
Когда будете тестировать?
последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys ) в разрезе запланированных фаз разработки
Критерии начала тестирования:
готовность тестовой платформы (тестового стенда)
законченность разработки требуемого функционала
наличие всей необходимой документации
...
Критерии окончания тестирования:
результаты тестирования удовлетворяют критериям качества продукта
требования к количеству открытых багов выполнены
выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)
выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)
...
Слайд 14

- Процесс разработки тестов Тест дизайн – это этап процесса тестирования

- Процесс разработки тестов

Тест дизайн – это этап процесса тестирования ПО,

на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
План работы над тест дизайном
анализ имеющихся проектных артефактов: документация (спецификации, требования, планы), модели, исполняемый код и т.д.
написание спецификации по тест дизайну (Test Design Specification)
проектирование и создание тестовых случаев (Test Cases)
Слайд 15

Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных

Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных

условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Под тест кейсом понимается структура вида:
Action > Expected Result > Test Result

- Процесс разработки тестов

Слайд 16

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

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

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

- Процесс разработки тестов

Слайд 17

- Процесс разработки тестов Структура Тестовых Случаев (Test Case Structure) Каждый

- Процесс разработки тестов

Структура Тестовых Случаев (Test Case Structure)
Каждый тест кейс

должен иметь 3 части:
Слайд 18

- Процесс разработки тестов Вывод Для того чтобы команда тестирования работала

- Процесс разработки тестов

Вывод
Для того чтобы команда тестирования работала сплоченно и

не отвлекалась по вопросам оформления тест кейсов, у всех должен быть единый шаблон или подход к их написанию.