Тестовая деятельность

Лекция 5

Распространение программных систем достигло такой стадии, когда экономики впадаютв большую зависимость от успешной разработки и доставки ПО. Отчетливообозначена потребность разработки ПО за меньшие промежутки времени. Это обстоятельство предъявляет повышенные требования к разработчикам и тестировщикам ПО не только в плане ускоренного производства ПО, но и в плане обеспечения должного уровня качества. Основные требования:

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

•Необходимо обеспечивать достаточно высокое качество тестирования, которое бы гарантировало, что дефекты, приводящие к разрушительным последствиям, не попадут на компьютеры конечных пользователей.

              Основные определения в области тестирования ПО

Дефект (баг, глюк- bug, defect) - любое несоответствие фак5тического и ожидаемого результата (согласно требованиям или здравому смыслу). Это ошибка программиста, дизайнера или ещё кого, кто принимает участие в разработке ПО,

Дефект может возникнуть

• на стадии формулирования требований,

• на стадии проектирования,

• на стадии кодирования,

• из-за некорректной конфигурации,

• из-за некорректных данных,

• и т.д.

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

 

 

Failure ( сбой, причём не обязательно аппаратный) в работе компонента, программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (а defect caused the failure) и существуют такие, которые не приводят. (Сбой — это нарушение нормального функционирования отдельной программы, устройства или компьютера в целом. Внешне это выглядит как появление различных сообщений.)

 

Error — ошибка пользователя, то есть он пытается использовать программу иным способом. Пример — вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).

 

Багтрекер (Bugtracker) – система учета и отслеживания ошибок, которая позволяет создавать, хранить, просматривать и модифицировать информацию о багах.

 

Жизненный цикл бага (Bug workflow) – последовательность этапов, которые проходит баг на своём пути с момента его создания до окончательного закрытия.

 

Отчет о дефекте (Bug report) – документ, описывающий найденный дефект, а также действия, необходимые для его воспроизведения.

 

Приоритет (Priority) – это порядок в котором дефекты должны быть исправлены. Чем выше стоит приоритет, тем скорее нужно исправить дефект, выставляется менеджером, тимлидом или заказчиком. Выделяют 3 уровня приоритета.

1. Высокий (High). Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.

2. Средний (Medium). Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.

3. Низкий (Low). Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Серьезность дефекта (Severity) – это степень негативного влияния дефекта на продукт. Эту оценку выставляет тестировщик, принимающий участие в тестировании компонента или системы. Выделяют следующие серьезности:

1. Блокирующая (Blocker). Блокирующая ошибка, приводящая приложение в нерабочее состояние. Решение проблемы необходимо для дальнейшего функционирования системы.

2. Критическая (Critical). Критическая ошибка (например, неправильно работающая бизнес логика, "дыры" в системе безопасности) - проблема, приводящая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.

3. Значительная (Major). Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.

4. Незначительная (Minor). Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.

5. Тривиальная (Trivial). Тривиальная ошибка, не касающаяся бизнес логики приложения, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

 

Тест-кейс (test case) - набор входных данных, условий, ожидаемых результатов. Этот набор разрабатывается для проверки некоторого свойства ПО или поведения ПО.

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

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

Что будете тестировать?

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

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

https://habrahabr.ru/post/279535/

 

Билд, релиз (build, realese)  - промежуточная и конечная версии ПО.

Ожидаемый результат (Expected result) – поведение компонента или системы при установленных условиях, которое определено спецификацией или другими источниками.

Фактический результат (Actual result) – наблюдаемое или генерируемое поведение компонента или системы во время тестирования.

В обязанность тестировщика входит поиск вероятных ошибок и сбоев в функционировании объекта тестирования (продукта, программы, и т.д.). Тестировщик моделирует различные ситуации, которые могут возникнуть в процессе использования предмета тестирования, чтобы разработчики смогли исправить обнаруженные ошибки.

 

Тестовая деятельность

Проверка без запуска ПО на машине (проверка за столом- desk checks), называется статическим тестированием (static testing). Статическое тестирование является одним из наиболее эффективных средств выявления дефектов на ранних стадиях разработки, благодаря чему достигается существенная экономия времени и затрат на разработку. Статическое тестирование по существу есть все, что можно сделать для выявления дефектов без прогона программного кода. Этим средством, однако, на практике зачастую пренебрегают.

 

Деятельность, предусматривающая эксплуатацию ПО называется динамическим тестированием (dynamic testing). Динамическое тестирование является центральным звеном процесса тестирования ПО. Динамическое тестирование выполняется не только силами тестовой группы; тестовая группа должна быть частью коллектива разработчиков и совместно с ними принимать участие в проверке взаимодействия и функционирования компонентов системы.

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

Перед специалистами по тестированию и разработчиками поставлены противоположные цели. Цель разработчика - создать код без дефектов, который соответствует назначению программного продукта и отвечает требованиям заказчика. Дефект ПО остается необнаруженным, пока не произойдет отказ системы. На стадии системных испытаний цель тестировщика – вызвать сбой ПО, обнаружить и задокументировать связанные с ним дефекты, а затем удалить их из системы. В идеальном случае долговечность дефекта ограничена моментом, когда он обнаруживается средствами статического или динамического тестирования и успешно устраняется. Хороший результатом для разработчика – успешное прохождение теста, успешный результат для тестировщика – отказ программы на том же самом тесте. В конечном итоге разработчик и тестировщик стремятся к единой цели -получить качественное ПО, которое хорошо работает и удовлетворяет требованиям заказчика.

Две базовых функции тестирования – верификация(verification) и аттестация (validation - валидация).

Верификация обеспечивает соответствие результатов конкретной фазы процесса разработки требованиям данной и предшествующей стадий (правильная работа ПО).

Валидация – гарантия того, что ПО удовлетворяет системным требованиям, т.е. дает гарантию того, что построен требуемый продукт.