Рабочее место тестера проекта, основные функции тестера и набор инструментальных средств тестирования, методы тестирования, стадии тестирования, связь с разработчиком, архитектором и менеджером проекта

Тестирование как способ обеспечения качества

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

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

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

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

Конечной целью любого процесса тестирования является обеспечение такого емкого (совокупного) понятия как качество, с учетом всех или наиболее критичных для данного конкретного случая составляющих. С точки зрения ISO 9126, качество (программных средств) можно определить как совокупную характеристику исследуемого ПО, с учетом следующих составляющих:

• Надежность
• Сопровождаемость
• Удобство использования
• Эффективность
• Универсальность
• Функциональность

Более полный список атрибутов и критериев можно найти в самом стандарте ISO 9126 Международной организации по стандартизации. Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998 Standard for Software Test Documentation.

Миссии тестирования соответствует целям фазы:

1. Найти как можно больше дефектов.
2. Быстро определить существующие проблемы.
3. Определить воспринимаемые риски для качества.
4. Подтвердить соответствие стандарту.
5. Оценить соответствие спецификации.

Задачи тестирования:

1. Определение миссии тестирования.
2. Поверка подхода к тестированию.
3. Проверка стабильности выпуска.
4. Тестирование и оценка.
5. Достижение приемлемого результата миссии.
6. Совершенствование средств и методов тестирования.

Дополнительные задачи:

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

Уровни тестирования

Модульное тестирование (юнит-тестирование)

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

Преимущества:

• Поощрение изменений: юнит-тестирование позже позволяет программистам проводить рефакторинг, будучи уверенными, что модуль по-прежнему работает корректно (регрессионное тестирование). Это поощряет программистов к изменениям кода, поскольку достаточно легко проверить, что код работает и после изменений.
• Упрощение интеграции: юнит-тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию "снизу вверх": сначала тестируются отдельные части программы, затем программа в целом.
• Документирование кода: юнит-тесты можно рассматривать как "живой документ" для тестируемого класса. Клиенты, которые не знают, как использовать данный класс, могут использовать юнит-тест в качестве примера.
• Отделение интерфейса от реализации: поскольку некоторые классы могут использовать другие классы, тестирование отдельного класса часто распространяется на связанные с ним.

Интеграционное тестирование

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

Системное тестирование

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

Альфа-тестирование и бета-тестирование являются подкатегориями системного тестирования. "Альфа-" и "бета-тестирование" относятся к стадиям до выпуска продукта.

Альфа-тестирование

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

Бета-тестирование

В некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц, с тем чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей. Бета-тестирование в целом ограничено техникой черного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин "бета-тестирование" может указывать на состояние программы (ближе к выпуску чем "альфа"), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определенной степени.

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

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

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

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

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

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

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

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

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

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

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

Рабочие элементы и тестирование. Управление тестами

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

Для работы с тестами в Visual Studio Team Edition for Testers предусмотрено несколько средств:

• Test Manager – главный интерфейс тестировщика;
• Test View – средство просмотра тестов;
• Test Project – проект Visual Studio, используемый как контейнер для тестов;
• Test Results – окно, где отображаются результаты тестирования.

Остановимся более подробно на каждом.

Test List Editor – с помощью этого инструмента происходит создание, поиск, выполнение тестов и управление ими. Для того чтобы вывести указанное окно на экран, достаточно выбрать в меню Test команду Windows – Test List Editor. В его окне отображаются все предусмотренные системой тесты. Можно добавить дополнительные столбцы для отображения информации, которая вам необходима. Определяя пользовательские списки тестов, можно запускать тесты группами. При разделении тестов на категории можно руководствоваться любым разумным критерием, например, создать список, содержащий критичные модульные тесты, которые должны выполняться ежечасно в рамках процесса тестирования сборки. К сожалению, в окне Test List Editor недоступна информация о состоянии выполняющихся в данный момент тестов. Определить состояние теста можно в окне Test Results.

Test View – упрощенное средство просмотра имеющегося подмножества тестов. В окне Test View можно запускать, отлаживать, открывать и удалять отдельные тесты, а также добавлять новые. Чтобы вывести это окно на экран, нужно в меню Test выбрать команду Windows – Test View.

Test Project – тестировщикам не часто приходится иметь дело непосредственно с проектами тестирования, так как все тесты выполняются в рамках какого-либо проекта. Главным достоинством является то, что проекты и входящие в него тесты могут храниться в Visual Studio 2005 Team Foundation Version Control как и любые другие артефакты. Это означает, что не только на программный код, но и на тесты распространяются все преимущества использования системы управления версиями, такие как возможность учета изменений и их отката в случае необходимости. Это относится к тестам всех типов. Например, если кто-то внесет некорректное изменение в заданный в веб-тесте http -запрос, всегда можно определить, кто это сделал, и, пользуясь соответствующими средствами Team Foundation Version Control, вернуть тест в исходное состояние.

Test Results – средство просмотра результатов тестирования. При выполнении любого теста генерируются результаты, по которым тестировщик может определить, успешно ли пройден тест, нет ли в продукте дефектов и отвечает ли его качество определенным требованиям. В окне Test Results видно, какие тесты уже завершены, какие выполняются, а какие ждут своей очереди. Для каждого из завершенных тестов указано, успешно ли он пройден. Для теста, завершившегося неудачей, можно создать рабочий элемент "ошибка" назначить его разработчику. Разработчик либо сам запросит такие элементы, либо при правильной конфигурации получит уведомление об их появлении. Тогда он сможет запросить результаты теста, устранить ошибку и пометить рабочий элемент как отработанный, после чего создать новый рабочий элемент "задача" для тестировщика, чтобы тот провел повторное тестирование. Менеджеры также могут просматривать ошибки при помощи запросов или отчетов на портале проекта.