Найти тему

Тестирование ПО - основные понятия

Приветствую вас в первой части своего блога, посвященную введению в тестирование. Я решил начать его, помня о тех проблемах, с которыми столкнулся в начале, и постараюсь сделать максимально доступным для восприятия. Материал собирался и обрабатывался из разных источников, для более глубокого изучения могу порекомендовать краткую и содержательную книгу, которая была для меня наиболее полезной - Тестирование программного обеспечения. Базовый курс. Автор - Святослав Куликов.

Обратная связь приветствуется.

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

Тестирование ПО — процесс анализа программного продукта и его документации с целью выявить дефекты и тем самым повысить качество. Другими словами, мы сравниваем ожидаемое поведение тестируемого объекта с фактическим. Делается это на определенном наборе тестов (test suite). Тестирование - это лишь одна из техник контроля качества, куда также входят планирование работ, проектирование тестов, их выполнение, и анализ полученных результатов.

Качество ПО определяется как совокупность характеристик, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

В тестировании есть две фундаментальные идеи. Его можно рассматривать как процесс доказательства работоспособности программы в определенных условиях - позитивное тестирование, и наоборот доказательство его неработоспособности - негативное тестирование.

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

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

Чтобы лучше понять это, зададим несколько вопросов.

Что надо тестировать? - Опишем объект тестирования: систему, приложение, оборудование, документацию. Составляем список функций системы и её компонентов по отдельности.

Как будем тестировать? - Определяем подходящие виды тестирования (об этом в дальнейшем) и их применение по отношению к объекту тестирования.

Как понять, что можно начинать тестирование? Готовность тестовой платформы, законченность разработки требуемого функционала, наличие всей необходимой документации.

Какова последовательность действий в тестировании? - Подготовка к тестированию, тестирование, анализ результатов тестирования.

Тестирование окончено, если результаты тестирования удовлетворяют критериям качества продукта.

В тестовый план должно входить также описание окружения тестируемой системы - тестового стенда и его конфигурации.

Для повышения качества тест плана рекомендуется проводить его периодическое рецензирование со стороны участников проектной группы. Это можно сделать, просто договорившись между собой или же реализовать в виде "процедуры утверждения". Как пример, приведем список участников проектной группы, утверждение которых мы считаем необходимым: Ведущий тестировщик, Тест менеджер (менеджер по качеству), Руководитель разработки, Менеджер Проекта.

Воспользовавшись советами, вы можете составить качественный тест план.

В тест план должен входить непосредственно и сам

Тестовый сценарий (test case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. Из них состоит набор тестов (test suite) - это последовательность действий, по которой можно проверить, соответствует ли тестируемая функция установленным требованиям.

В тестовый сценарий должны входить следующие пункты:

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

Описание теста (Test Case Description) список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.

Постусловия (PostConditions) - список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state).

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

Структура отчета:

Короткое описание (Summary) - Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.

Проект (Project) - Название тестируемого проекта.

Компонент приложения (Component) - Название части или функции тестируемого продукта.

Номер версии (Version) - Версия на которой была найдена ошибка.

Серьезность (Severity) - Наиболее распространена пятиуровневая система градации серьезности дефекта: • S1 Блокирующий (Blocker) • S2 Критический (Critical) • S3 Значительный (Major) • S4 Незначительный (Minor) • S5 Тривиальный (Trivial).

Приоритет (Priority) - Приоритет дефекта: • P1 Высокий (High) • P2 Средний (Medium) • P3 Низкий (Low).

Статус (Status) - Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle).

Автор (Author) - Создатель баг репорта.

Назначен на (Assigned To) - Имя сотрудника, назначенного на решение проблемы

Окружение (Environment) - ОС / Сервис Пак и т.д. / Браузера + версия /… Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера и т.д.

Шаги воспроизведения (Steps to Reproduce) - Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.

Фактический Результат (Result) - Результат, полученный после прохождения шагов к воспроизведению.

Ожидаемый результат (Expected Result) - Ожидаемый правильный результат.

Дополненительно - Прикрепленный файл (Attachment) - Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы.

Думаю, для начала вам хватит (=

Дополнительные ресурсы для изучения:

http://www.protesting.ru/

https://habr.com/ru/post/279535/