Файл: Федеральное государственное автономное образовательное учреждение высшего образования казанский (приволжский) федеральный университет высшая школа информационных технологий и информационных систем.docx

Как становится ясно из названия фазы, выполнение тестов – это процесс запуска всех или определенных Тестовых случаев и оценка результатов выполнение. Это происходит, когда стадия разработки кода почти завершена. Выходными данными здесь являются отчеты об ошибках, журналы (логи), статус тестов, общие отчеты по тестированию (рис. 11) [4]¹⁸.

Рис. 11. - Выходные данные фазы выполнения тестов

На разных уровнях тесты выполняют разные участники команды. На модульном уровне обычно тесты выполнятся разработчиками, на интеграционном – и разработчиками, и инженерами по тестированию, на уровне системы – тест-инженеры и конечные пользователи, на приемочном уровне – конечные пользователи, но тестировщики также могут быть вовлечены.

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

При выполнении тестов всегда обнаруживаются тестовые сценарии, которые не были учтены ранее. Важно, чтобы эти сценарии были добавлены в общее хранилище Тестовых случаев для дальнейшего использования. В процессе выполнения тестов делаются записи в хронологическом журнале тестирования, чтобы отразить все детали, которые произошли во время тестирования [9]¹⁹. Журнал помогает в воспроизведении действий.

Как только Тест-кейс обнаруживает дефект, создается отчет об ошибке для диагностики проблемы и ее исправления. Обычно эти отчеты автоматизируются с помощью систем отслеживания ошибок. Самые важные составляющие отчета:

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

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

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

Обзор тестирования

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

Исправление разработчиком ошибки вносит коррективы в область выполнения теста. Например, распространенной практикой является такая: тестировщики не выполняют тесты, связанные с ошибкой пока она не будет исправлена. После исправления они выполняют все связанные Тест-кейсы, чтобы убедиться, что исправление не повлияло на другой функционал. Эта практика помогает сохранять время и сокращать трудозатраты.

Обзор тестирования использует результаты тестирования предыдущих сборок. Это помогает определить, на каких областях стоит сфокусироваться. Кроме того, это корректирует график, расстановку ресурсов, планирование последующих выпусков продукта [4]²⁰.

Что касается общего процесса тестирования, то могут быть приведены различные оценки: анализ надежности, анализ покрытия, анализ всех дефектов. Анализ надежности отражает, выполняет ли продукт ранее поставленные задачи. Если да, то его можно выпускать реальным пользователям, соответственно можно выбирать дату релиза. Если нет, то нужно рассчитать необходимые ресурсы и время для достижения этих целей. Анализ покрытия может использоваться как альтернатива критерию для остановки тестирования. Общий анализ дефектов приведет к определению областей,

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

Критерии для начала и окончания тестирования и требования для этапов планирования тестирования и тест-дизайна

После описания жизненного цикла тестирования программного обеспечения стоит поговорить о критериях начала и окончания тестирования и требованиях для этапов планирования тестирования и тест-дизайна. Это необходимо для проведения дальнейшего исследования.

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

Рис. 12. - Разработка тест-плана

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

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

Тест-план для каждого уровня должен опираться на информацию, специфичную для данного конкретного уровня, например, риски и допущения, требования к персоналу, график, тестовая стратегия и необходимые навыки. Порядок написания и выполнения тестовых планов таков: план написанный первым будет выполняться последним, то есть план для приемочного тестирования будет задействован в последнюю очередь. Причиной тому служит то, что требования для его выполнения становятся известными в первую очередь. К примеру, снова возьмем уровень тестирования системы. Начало работы с планом обычно назначается, когда закончена фаза разработки требований и команда работает над документами этапа проектирования тестирования [4]²¹. Согласно [3]²², входные требования для уровня тестирования системы – это документация концепции, требования к интерфейсу, пользовательская документация.

Если существует общий тест-план, то план для системного уровня стремится добавить в Общий план элементы, специфичные для тест-плана уровня системы. IEEE рекомендует ссылаться на следующие документы:

спецификация требований;
спецификация дизайна;
руководство пользователя;
руководство по эксплуатации.

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

Рис. 13. - Разработка тест-плана уровня системы

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

В некоторых организациях используется так называемый чек-лист для проверки проведения всех необходимых мероприятий по подготовке к тестированию (Таблица 2 см. Приложение 2).

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