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

Статическое или динамическое? Позитивное или негативное? Давайте разбираться.

В предыдущем блоге "С чего начинать тестирование? Конечно же с методов!" была представлена классификация тестирования. В данном блоге рассмотрим "По запуску кода на исполнение" и "По принципу работы с приложением".
         Начнем с "По запуску кода на исполнение". У данного класса два вида тестирования: статическое и динамическое.
Статическое тестирование —  это процесс, который обычно ассоциируют с анализом программного обеспечения, используется для верификации практически любого артефакта разработки:
- программный код,
- требований,
- системных спецификаций,
- функциональных спецификаций,
- документов проектирования
- архитектуры программных систем и их компонентов.
При статическом тестировании не запускается программный код. Такое тестирование позволяет выявить ошибки на ранних стадиях разработки. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств.
Динамическое тестирование — это процесс тестирования обратный статическому. Он не может осуществляться без запуска программного кода приложения. Этапы динамического тестирования:
- запуск системы или подсистемы;
- вызов необходимых функциональных элементов или модулей;
- сравнение через графический интерфейс пользователя реального поведения системы с ожидаемым.
         У класса "По принципу работы с приложением" тоже два вида: позитивное и негативное.
Цель негативного теста — убедиться, что система правильно реагирует на неправильное действие. Надо помнить, что негативное тестирование не менее важно, чем позитивное. Пользователи - люди, а не роботы, а значит нужно помнить про человеческий фактор - ошибаться.
Цель позитивного теста проверить, что приложение правильно выполнило вызываемую функцию с корректными данными. Все сценарии использования нашей системы выполнимы и приводят к ожидаемому результату, а не к ошибкам.
Сначала, конечно, проверяют позитивные сценарии, иначе как работать с системой, которая не выполняет основной функционал. Но после позитивного необходимо и негативные тесты провести, чтобы не вышло так, что пользователь ошибся в действиях или данных, и рухнула вся система =)

Комментарии

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

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

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (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 (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут по...

Что нужно знать о рисках

Риски используются для определения того, где начинать тестирование и каким аспектам уделить большее внимание. Риск (risk): Фактор, который может привести к негативным последствиям в будущем, обычно выражается через вероятность и влияние. ( ISTQB ) Анализ рисков (risk analysis): Процесс оценки идентифицированных рисков для вычисления их вероятности и влияния. ( ISTQB ) Контроль рисков (risk control): Процесс, в результате которого выносятся решения и принимаются защитные меры для уменьшения рисков до определенного уровня или поддержанию рисков в оговренных рамках. ( ISTQB ) Определение рисков представляет собой  процесс идентификации  рисков с использованием таких методик как мозговой штурм, контрольные списки и история отказов. Процесс оценки определенного ри...