Cтатическое и динамическое тестирование
Статическое тестирование отличается от динамического тем, что производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода (code review) или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к статическому тестирвоанию относится тестирования спецификации и прочей документации.
В отличии от статического, динамическое тестирование производится путем запуска продукта и проверки его функционала.
Исследовательское / ad-hoc тестирование Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом. Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования.
Тестовая документация бывает двух видов: внешняя и внутренняя.
Внешняя документация:
Замечание – короткая записка, комментарий о небольшой неточности в реализации продукта.
Баг-репорт – описание выявленного случая несоответствия производимого продукта требованиям, к нему выдвигаемым – ошибки или ее проявления (идея, описание исходного состояния системы для выполнения кейса, шаги, ОР, ФР, входные данные, которые использовались во время воспроизведения кейса, критичность/приоритет, скрин, версию, сборку, ресурс и другие данные об окружении).
Запрос на изменение (улучшение) – описание неявных/некритичных косвенных требований, которые не были учтены при планировании/реализации продукта, но несоблюдение, которых может вызвать неприятие у конечного потребителя. И пути/рекомендации по модификации продукта для соответствия им.
Отчет о тестировании (тест репорт) – документ, предоставляющий сведения о соответствии/ несоответствии продукта требованиям.
Внутренняя документация:
Тест-план (план тестирования) – формализованное и укрупненное описание одной сессии тестирования по одному или нескольким направлениям проверок. Т.е. перечень направлений проверок, которые должны быть проведены в рамках сессии тестирования (и, сообразных этим направлениям, требований). Основная цель документа – описать границы сессии тестирования, стабилизировать показательность данной сессии.
Тестовый сценарий – последовательность действий над продуктом, которые связаны единым ограниченным бизнес-процессом использования, и сообразных им проверок корректности поведения продукта в ходе этих действий.
Тестовый комплект – некоторый набор формализованных тестовых случаев объединенных между собой по общему логическому признаку.
Чек-лист (лист проверок) – перечень формализованных тестовых случаев в виде удобном для проведения проверок. Тестовые случаи в чек-листе не должны быть зависимыми друг от друга. Цель – обеспечить стабильность покрытия требований проверками необходимыми и достаточными для заключения о соответствии им продукта. Особенностью является то, что чек-листы компонуются теми тестовыми случаями, которые показательны для определенного требования.
Тестовый случай (тест-кейс) – формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным.
Жизненным циклом программного обеспечения (SLC) является период времени, начинающийся с момента появления концепции ПО и заканчивающийся тогда, когда использование ПО более невозможно.
Критерии входа (entry criteria) - основные условия, которые должны быть выполнены до того, как Вы и Ваша команда могут начать тестирование.
все дефекты, которые относятся к ранним стадиям (проектирования) закрыты и проверены;
код проверенный с помощью осуществления «Unit» тестов;
основные функциональные возможности ПО готовы для тестирования;
имеется документация, которая определяет требования;
все тестировщики ознакомлены с архитектурой ПО;
все тестировщики ознакомлены с целями проекта;
готова среда тестирования;
доступные для использования билды;
утверждены план тестирования и/или тестовые случаи.
Критерии выхода (exit criteria) - Проще говоря, как критерии входа определяют начало тестирования, так и критерии выхода определяют его окончание и ПО готово к следующему этапу жизненного цикла (внедрение и т.д.).
все заранее предопределенные области ПО как «рисковые» протестированы и такой статус понижен/удален;
все ошибки тщательно задокументированы и доведены менеджменту/акционерам/заказчикам;
все тесты с высоким приоритетом пройдены и соответственно помечены как «Pass»;
все требования документации SRS (Спецификация требований ПО);
STR утверждено собственником проекта;
протестирована архитектура ПО;
ни одна серьезная или критическая ошибки не остаются открытыми;
90-95% всех тестов сделано.
Приведите несколько инструментов, которые могут использоваться для автоматизации тестирования.
внутренние инструменты автоматизации;
серия программных продуктов Selenium;
MS VS;
JUnit;
Test Complete;
LoadRunner;
Testing Аnywhere;
WinRunner.
Процедура тестирования (Test Procedure) - документ, описывающий последовательность действий при выполнении теста. Также известен как ручной сценарий тестирования.
Покрытие кода (code coverage) — это метод анализа, определяющий, какие части ПО были проверены (покрыты) набором тестов, а какие нет, например, покрытие операторов, покрытие альтернатив или покрытие условий.
Инспекция кода (code inspection) или просмотр кода (code review) — это систематическая проверка исходного кода программы с целью обнаружения и исправления ошибок, которые остались незамеченными в начальной фазе разработки.
Код завершен = его реализация завершена
Отладка (debugging) — это процесс поиска, анализа, и устранения причин отказов и ошибок в ПО.
Критичность (severity) — это важность воздействия конкретного дефекта на разработку или функционирование компонента или системы.
Реляционная БД – (relation) – связь, зависимость
SQL – язык структурированных запросов