Тест-стратегия

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

1. Виды тестирования.

Интеграционное тестирование – этот вид тестирования проверяет взаимодействие компонентов, взаимодействие модулей, которые общаются между собой. Тестирование проводится с помощью нескольких Test Cases из общего набора, которые относятся к интеграции.

Конфигурационное тестирование – проверка работоспособности системы в различных конфигурациях программного и аппаратного обеспечения (оперативная память, процессор, видео-карта и т.п.). Для проведения такого вида тестирования нужно провести тестирование по всем Test Cases на одной конфигурации (например, браузер/ОС), записать и автоматически воспроизвести на других конфигурациях.

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

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

Объёмное тестирование – тестирование при большом количестве данных. Его цель – определить, при каких объёмах данных система перестаёт работать.

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

Модульное тестирование – проверка функционирования самого элементарного компонента системы. Обычно берется самый минимально возможный для тестирования компонент – одна функция программы.

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

Exploratory-тестирование – это тестирование методом свободного поиска, или тестирование без заранее спроектированных тестов, выполняемых в точном соответствии с планом.

Usability-тестирование – предназначено для тестирования удобства и простоты пользования программой. Проводится не по Test Cases, представляет собой оценку в целом. Обычно имеется ряд вопросов-критериев, на которые можно ориентироваться при оценке usability системы.

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

Регрессионное тестирование – повторное. С его помощью проверяют исправления в программе. Например, есть дефект. Его исправляют, после чего проводят регрессионный тест, т.е. проверяют, исправлена ли ошибка на самом деле или нет. Данный набор действий необходимо выполнять регулярно. Причина – если ошибка возникла, то она вполне может появляться еще не один раз. При выходе каждой новой версии программы, желательно проверять, какие ошибки были до этого, т.к. они могут появляться заново в дальнейшем.

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

Usability - и Exploratory - тестирование также проводится по итерациям, если есть уже макет, реализующий какую-либо функциональность продукта (для Exploratory), либо просто макет пользовательского интерфейса (для Usability). Оно также может проводиться регрессионно, по мере исправления обнаруженных ошибок, добавления новой функциональности либо внесения изменений заказчика. На завершающем этапе разработки проводится контрольное Usability- и Exploratory- тестирование системы в целом.

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

Unit-тестирование проводится на этапе разработки и только в случаях, где срабатывают критерии необходимости использования модульного тестирования (см. Лабораторную работу №6).

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

2. Конфигурация платформ, на которых проводится тестирование.

Указывается, какие были выбраны конфигурации и почему.

3. Инструменты, с помощью которых проводится тестирование.

Для проведения тестирования по тестовым случаям используется инструмент Microsoft Test Manager 2010 (рис 5.1).

Рис. 5.1. Microsoft Test Manager 2010.

Для проведения тестирования производительности используется среда разработки Microsoft Visual Studio 2010 (рис. 5.2).

Рис. 5.2. Инструмент для определения производительности Веб-приложений входящий в состав среды разработки Microsoft Visual Studio 2010 Ultimate.

4. Тестовые случаи (Test Cases).

Test Cases составляются по «требованиям» заказчика (User Stories) менеджером проекта в среде разработки Microsoft Visual Studio 2010 либо в Microsoft Test Manager 2010.

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

Пример тест-стратегии для программы «Алгоритм Rijndael»:

1. Виды тестирования.

В процессе тестирования будет проведено конфигурационное тестирование, usability-тестирование, exploratory-тестирование и приемочное тестирование.

2. Конфигурация платформ, на которых проводится тестирование.

Так как данный программный продукт является WinForms-приложением, то для конфигурационного тестирования достаточно протестировать систему на одной-трех наиболее распространенных операционных систем. Тестирование будет проводится на компьютере с операционной системой Windows ХР.

3. Инструменты, с помощью которых проводится тестирование.

Так как тест-планом и тест-стратегией предусмотрено тестирование по тестовым случаям будет использоваться инструмент Microsoft Test Manager 2010.

4. Тестовые случаи.

1. Запуск программы.

2. Шифрование данных.

3. Дешифрование данных.

4. Закрытие программы.