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

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

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

Рисунок 1. Процесс тестирования дефектов

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

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

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

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

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

Рисунок 2. Тестирование методом черного ящика

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

Рисунок 3. Структурное тестирование

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

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

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

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

Метод тестирования ветвей основывается на графе потоков управления программы. Этот граф представляет собой скелетную модель всех ветвей программы. Граф потоков управления состоит из узлов, соответствующих ветвлениям решений, и дуг, показывающих поток управления. Если в программе нет операторов безусловного перехода, то создание графа - достаточно простой процесс. При построении графа потоков все последовательные операторы (операторы присвоения, вызова процедур и ввода-вывода) можно проигнорировать. Каждое ветвление операторов условного перехода (if-then-else или case) представлено отдельной ветвью, а циклы обозначаются стрелками, концы которых замкнуты на узле с условием цикла. На рисунке 4 показаны циклы и ветвления в графе потоков управления программы бинарного поиска .

Рисунок 4. Граф потоков управления бинарного поиска

Цель структурного тестирования - удостовериться, что каждая независимая ветвь программы выполняется хотя бы один раз. Независимая ветвь программы - это ветвь, которая проходит, по крайней мере, по одной новой дуге графа потоков. В терминах программы это означает ее выполнение при новых условиях. С помощью трассировки в графе потоков управления программы бинарного поиска можно выделить следующие независимые ветви :
1, 2, 3, 8, 9
1, 2, 3, 4, 6, 7, 2
1, 2, 3, 4, 5, 7, 2
1, 2, 3, 4, 6, 7, 2, 8, 9

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

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

С (G) = количество дуг – количество узлов + 2

Для программ, не содержащих операторов безусловного перехода, значение цикломатического числа всегда больше количества проверяемых условий. В составных условиях, содержащих более одного логического оператора, следует учитывать каждый логический оператор. Например, если в программе шесть операторов if и один цикл while, то цикломатическое число равно 8. Если одно условное выражение является составным выражением с двумя логическими операторами (объединенными операторами and или or), то цикломатическое число будет равно 10. Цикломатическое число программы бинарного поиска равно 4.

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

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

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

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

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

В примере на рисунке 5 последовательность тестов T1, Т2 и ТЗ сначала выполняется в системе, состоящей из модулей А и В (минимальная конфигурация системы). Если во время тестирования обнаружены дефекты, они исправляются. Затем в систему добавляется модуль С. Тесты T1, T2 и ТЗ повторяются, чтобы убедиться, что в новой системе нет никаких неожиданных взаимодействий между модулями А и В. Если в ходе тестирования появились какие-то проблемы, то, вероятно, они возникли во взаимодействиях с новым модулем С. Источник проблемы локализован, таким образом упрощается определение дефекта и его исправление. Затем система запускается с тестами Т4. На последнем шаге добавляется модуль D и система тестируется еще раз выполняемыми ранее тестами, а затем новыми тестами Т5 .

Рисунок 5. Тестирование сборки

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

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

На рисунке 6 показаны возможные инструментальные средства тестирования и отношения между ними.

1. Организатор тестов. Управляет выполнением тестов. Он отслеживает тестовые данные, ожидаемые результаты и тестируемые функции программы.
2. Генератор тестовых данных. Генерирует тестовые данные для тестируемой программы. Он может выбирать тестовые данные из базы данных или использовать специальные шаблоны для генерации случайных данных необходимого вида.
3. Оракул. Генерирует ожидаемые результаты тестов. В качестве оракулов могут выступать предыдущие версии программы или исследуемого объекта. При тестировании параллельно запускаются оракул и тестируемая программа и сравниваются результаты их выполнения.
4. Компаратор файлов. Сравнивает результаты тестирования с результатами предыдущего тестирования и составляет отчет об обнаруженных различиях. Компараторы особенно важны при сравнении различных версий программы. Различия в результатах указывают на возможные проблемы, существующие в новой версии системы.
5. Генератор отчетов. Формирует отчеты по результатам проведения тестов.
6. Динамический анализатор. Добавляет в программу код, который подсчитывает, сколько раз выполняется каждый оператор. После запуска теста создает исполняемый профиль, в котором показано, сколько раз в программе выполняется каждый оператор.
7. Имитатор. Существует несколько типов имитаторов. Целевые имитаторы моделируют машину, на которой будет выполняться программа. Имитатор пользовательского интерфейса - это программа, управляемая сценариями, которая моделирует взаимодействия с интерфейсом пользователя. Имитатор ввода/вывода генерирует последовательности повторяющихся транзакций .

Рисунок 6. Инструментальные средства тестирования

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

Для создания полного комплекса инструментального средства тестирования, как правило, требуется много сил и времени. Весь набор инструментальных средств, показанных на рис. 6, используется только при тестировании больших систем. Для таких систем полная стоимость тестирования может достигать 50% от всей стоимости разработки системы. Вот почему выгодно инвестировать разработку высококачественных и производительных CASE-средств тестирования .

Тестирование

Тестирование (англ. test - испытание, проверка) - эксперементальный метод психродиагностики, применяемый в эмпирических социологических исследованиях, а также метод измерения и оценки различных психологических качеств и состояний индивида.

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

Основоположники тестирования - Ф.Гальтон, Ч.Спирман, Дж.Каттел, А.Бине, Т.Симон. Сам термин "умственный тест" придумал Кеттел в 1890 г. Начало развития современной тестологии массового применения тестов на практике связано с именем французского врача Бине, разработавшего в соавторстве с Симоном метрическую шкалу умственного развития, известную под названием "тест Бине-Симона".

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

Тесты предъявляют требования:

Строгая формализация всех этапов тестирования,

Стандартизация заданий и условий их выполнения,

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

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

Каждый тест, соответствующий критериям надежности, кроме набора заданий включает в себя следующие компоненты:

1) стандартная инструкция для испытуемого о цели и правилах выполнения заданий,

2) ключ шкалирования - соотнесение пунктов заданий со шкалами измеряемых качеств, указывающее, какой пункт заданий к какой шкале относится,

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

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

Для преодоления основного недостатка большинства тестов применяются различные приемы:

1) увеличение базовой выборки с целью повышения ее репрезентативности по большему числу параметров,

2) введение поправочных коэффициетнов с учетом характеристик выборки,

3)введение в практику тестирования невербального способа предъявления материала.

Тест состоит из двух частей:

а) стимулирующего материала (задача, инструкция или вопрос)

б) указаний относительно регистрации или интнграции полученых ответов.

Типичная для тестов стандартизация ситуации обеспечивает им в отличие от "свободного" наблюдения поведения большуюю объективность результатов.

Тесты классифицируются по разным признакам.

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

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

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

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

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

Разработка теста состоит из четырех этапов.

На первомэтапе развивается исходная концепция с формулировкой основных пунктов испытания или основных вопросов, носящих предварительный характер;

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

На третьем этапе тест проверяется повторно на той же самой популяции;

На четвертом - калибруется по отношению к возрасту, уровню образования и другим признакам популяции.

На всех этапах разработки теста необходимо учитывать:

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

б) связанную с этим валидизацию метода, т.е. опpеделение того, насколько он измеpяет тpебуемое свойство;

в) величину выбоpки из популяции, на котоpой должна пpоводиться оценка метода;

г) стимулиpующий матеpиал (таблички, изобpажения, игpушки, фильмы);

д) влияние исследователя в пpоцессе инстpуктиpования, постановки задач, pазъяснений, ответов на вопpосы;

е) условия ситуации;

ж) такие фоpмы поведения испытуеого, котоpые свидетельствуют об измеpяемом свойстве;

з) шкалиpование pелевантных фоpм поведения;

и) сведение pезультатов по отдельным измеpяемым пунктам в общие значения (напpимеp, суммиpование ответов типа "Да");

к) фоpмулиpовку pезультатов в ноpмиpованной шкале оценок.

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

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

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

Использованная литература:

1.Соц.справочник,Киев,1990.

2.Соц.словарь,Минск,1991.

3.Фонд времени и мероприятия в соц.сфере,М:Наука,1989.

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

Ручное тестирование (manual testing) - часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно проводится тестировщиками или обычными пользователи путем моделирования возможных сценариев действия пользователя.

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

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

Пример фрагмента процедуры

1. Подать на вход три разных целых числа;
2. Запустить тестовое исполнение;
3. Проверить, соответствует ли полученный результат таблице [ссылка на документ1] с учетом поправок [ссылка на документ2];
4. Убедиться в понятности и корректности выдаваемой сопроводительной информации.

В этой процедуре тестировщик использует дополнительные документы и собственное понимание того, какую сопроводительную информацию считать “понятной и корректной”. Успех от использования процедурного подхода достигается в случае однозначного понимания тестировщиком всех пунктов процедуры. Например, в п.1 приведенной процедуры не уточняется, из какого диапазона должны быть заданы три целых числа, и не описывается дополнительно, какие числа считаются “разными”.

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

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

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

Сравнение ручного и автоматизированного подхода к тестированию

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

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

Инспекции и сквозные просмотры

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

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

Инспекционное заседание разбивается на две части:

1. Программиста просят рассказать о логике работы программы. Во время беседы возникают вопросы, преследующие цель обнаружения ошибки. Практика показала, что даже только чтение своей программы слушателям представляется эффективным методом обнаружения ошибок и многие ошибки находит сам программист, а не другие члены группы.
2. Программа анализируется по списку вопросов для выявления исторически сложившихся общих ошибок программирования. Ее участники должны сосредоточить свое внимание на нахождении ошибок, а не на их корректировке. Корректировка ошибок выполняется программистом после инспекционного заседания. Список ошибок анализируется и они распределяются по категориям, что позволяет совершенствовать его с целью повышения эффективности будущих инспекций. Можно вести учет типов ошибок, на основании которого следует проводить дополнительную стажировку программиста в слабых областях. Процесс инспектирования в дополнение к своему основному назначению, выполняет еще ряд полезных функций. Результаты инспекции позволяют программисту увидеть сделанные им ошибки и способствуют его обучению на собственных ошибках, он обычно получает возможность оценить свой стиль программирования и выбор алгоритмов и методов тестирования. Остальные участники приобретают опыт, рассматривая ошибки и стиль программирования других программистов. Инспекция является способом раннего выявления наиболее склонных к ошибкам частей программы, позволяющим сконцентрировать внимание на этих частях в процессе выполнения тестирования.

Сквозной просмотр, представляет собой набор процедур и способов обнаружения ошибок, осуществляемых группой лиц, просматривающих текст программы. Метод имеет много общего с процессом инспектирования, но их процедуры несколько отличаются и в нем используются другие методы обнаружения ошибок. Сквозной просмотр проводится как непрерывное заседание, группа состоит из 3–5 человек. Процедура отличается от процедуры инспекционного заседания тем, что участники «выполняют роль компьютера». Комиссии предлагают небольшое число написанных на бумаге тестов, представляющих собой наборы входных данных и ожидаемых выходных данных для программы или модуля. Тестовые данные подвергаются обработке в соответствии с логикой программы, состояние программы и значения переменных отслеживается на бумаге или доске.Тесты сами по себе не играют критической роли, а служат средством для первоначального понимания программы и основой для вопросов программисту о логике проектирования и принятых допущениях.

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

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

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

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

Тестирование ПО — попытка определить, выполняет ли программа то, что от неё ожидают. Как правило, никакое тестирование не может дать абсолютной гарантии работоспособности программы в будущем.

Для наглядности: почти все производители коммерческого ПО исправляют ошибки в своих продуктах.

Например: Корпорация Microsoft выпускает пакеты обновлений («Service Pack»), для своих операционных систем. Разработчики игр регулярно выпускают «патчи» для своих продуктов. Большинство разработчиков ПО после устранения ошибок выпускают обновлённую (новую) версию своей программы.

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

Существует несколько признаков по которым принято производить классификацию видов тестирования. Обычно выделяют следующие признаки:

По объекту тестирования:

• Функциональное тестирование (functional testing)
• Нагрузочное тестирование
  • Тестирование производительности (perfomance/stress testing)
  • Тестирование стабильности (stability/load testing)
• Тестирование удобства использования (usability testing)
• Тестирование интерфейса пользователя (UI testing)
• Тестирование безопасности (security testing)
• Тестирование локализации (localization testing)
• Тестирование совместимости (compatibility testing)

По знанию системы:

• Тестирование чёрного ящика (black box)
• Тестирование белого ящика (white box)
• Тестирование серого ящика (gray box)

По степени автоматизированности:

• Ручное тестирование (manual testing)
• Автоматизированное тестирование (automated testing)
• Полуавтоматизированное тестирование (semiautomated testing)

По степени изолированности компонентов:

• Компонентное (модульное) тестирование (component/unit testing)
• Интеграционное тестирование (integration testing)
• Системное тестирование (system/end-to-end testing)

По времени проведения тестирования:

• Альфа тестирование (alpha testing)
  • Тестирование при приёмке (smoke testing)
  • Тестирование новых функциональностей (new feature testing)
  • Регрессионное тестирование (regression testing)
  • Тестирование при сдаче (acceptance testing)
• Бета тестирование (beta testing)

По признаку позитивности сценариев:

• Позитивное тестирование (positive testing)
• Негативное тестирование (negative testing)

По степени подготовленности к тестированию:

• Тестирование по документации (formal testing)
• Эд Хок (интуитивное) тестирование (ad hoc testing)

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

• Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.
• Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.
• Системное тестирование — тестируется интегрированная система на её соответствие требованиям.
  • Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.
  • Бета-тестирование — в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц, с тем чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.

Часто для свободного/открытого ПО стадия Альфа-тестирования характеризует функциональное наполнение кода, а Бета тестирования — стадию исправления ошибок. При этом как правило на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.

Тестирование «белого ящика» и «чёрного ящика»

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

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

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

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

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

Статическое и динамическое тестирование

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

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

Также к статическому тестированию относят тестирование требований, спецификаций, документации.

Регрессионное тестирование

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

Тестовые скрипты

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

Покрытие кода

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

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

Как правило, инструменты и библиотеки, используемые для получения покрытия кода, требуют значительных затрат производительности и/или памяти, недопустимых при нормальном функционировании ПО. Поэтому они могут использоваться только в лабораторных условиях.

Разработка через тестирование (test-driven development)

(англ. test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (англ. test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования.

Ни один программист не считает работу над некоторым фрагментом кода завершенной, не проверив перед этим его работоспособность. Однако, если вы тестируете свой код, это не означает, что у вас есть тесты.

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

Методика разработки через тестирование(Test-Driven Development, TDD) позволяет получить ответы на вопросы об организации автоматических тестов и выработке определенных навыков тестирования.

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

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

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

Разработчику приятнее писать такой код.

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

Пишем новый код только тогда, когда автоматический код не сработал.

Удаляем дублирование.

Два столь простых правила на самом деле генерируют сложное индивидуальное и групповое поведение со множеством технических последствий:

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

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

Наша среда разработки должна быстро реагировать на небольшие модификации кода.

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

Два упомянутых правила TDD определяют порядок этапов программирования:

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

Зеленый - заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.

Рефакторинг - удалите из написанного вами кода любое дублирование.

Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными.

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

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

Терминология, связанная с модульными тестами

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

• Модульные тесты - Unit Tests, Programming Tests, Developer Tests - тесты, проверяющие функциональность отдельных классов, компонентов, модулей приложения. Эти тесты не видны конечному заказчику или доменному эксперту. Обычно их начинают писать после оформления функциональных тестов.

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

• Моки, Мок-объекты (MockObjects) - автоматически генерируемые заглушки, которые могу выступат в роли реальных объектов. Поведением моков можно управлять непосредственно в тесте. Моки могут выполнять дополнительные проверки, что тестируемый код их использовал, как ожидалось.

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

• Тест - TestCase - набор тестовых методов, предназначенных для тестирования одного класса (в среде xUnit). Обычно TestCase состоит из методов, чье имя начинается с приставки test. Каждый такой метод тестирует какой-либо один момент тестируемого класса. В приемочном тестировании TestCase - это набор команд, которые тестируют одну значимую для заказчика функциональность.

• Фикстура - Fixture - состояние среды тестирования, которое требуется для успешного выполнения тестового метода. Это может быть набор каких-либо объектов, состояние базы данных, наличие определенных файлов и т.д. Фикстура создается в методе setUp() перед каждым вызовом метода вида testSomething теста (TestCase) и удаляется в tearDown() после окончания выполнения тестового метода.

• Проверка - Assert - метод класса TestCase, который предназначен для сверки реального состояния тестируемого кода с ожидаемым.

Терминология, связанная с наборами тестов

• Набор тестов - TestSuite - набор тестов, предназначенный для тестирования какой-либо укрупненной сущности программной системы. В SimpleTest есть понятие TestGroup, которые практически эквивалентно понятию TestSuite. Иногда TestSuite употребляют в значении «все тесты, которые есть для приложения».

Терминология, связанная с приемочными тестами

• Приемочные (функциональные) тесты - Customer tests, Acceptance tests - тесты, проверяющие функциональность приложения на соответствие требованиям заказчика. Приемочные тесты не должны ничего знать о деталях реализации приложения. Приемочные тесты заменяют ТЗ при использовании методики экстремального программирования (XP).

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

Андрей Колесов

Вряд ли имеет смысл говорить о важности тестирования в общем процессе разработки ПО, ведь давно известно, что реализация каждого этапа жизненного цикла приложений является необходимым условием для появления качественного программного продукта. Но, сказав слова о равенстве всех видов работ, нужно признать: в течение всей истории разработки ПО - а она насчитывает более 50 лет - тестирование выступало в роли падчерицы, которой достается самая трудоемкая, рутинная и непрестижная работа * . Далеко за примерами ходить не нужно: авторские права разработчиков закреплены законодательством, их имена можно при желании легко узнать. А что нам известно о тех, кто тестирует приложения, и это при том, что именно на их долю приходится в среднем около трети затрат по созданию ПО?

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

Нужно отметить парадоксальную ситуацию: при обилии методической литературы и курсов по проектированию и кодированию ПО наблюдается практически полное отсутствие материалов по тестированию и отладке! Как сказал известный американский автор книг по разработке ПО Джон Роббинс: "Даже если у вас есть специальное образование, бьюсь об заклад, что вы никогда не сталкивались со специальным курсом, посвященным отладке" (см. PC Week/RE, № 9/2004, с. 61).

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

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

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

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

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

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

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

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

1. Объем тестирования очень велик. Дело в том, что именно в случае внутрифирменных разработок очень часто вносятся изменения (многие слушатели семинара говорили о непрерывном потоке корректировок по запросам подразделений-заказчиков). А ведь, как известно, классическое правило разработки ПО гласит: изменение одной строки кода требует повторного проведения полного цикла тестирования.
2. Как это ни цинично звучит, но разработчики очень часто не заинтересованы в снижении количества ошибок в ПО, передаваемом в эксплуатацию. Руководство компаний оценивает работу ИТ-отдела в первую очередь по его умению уложиться в бюджет (время и деньги), а проблемы эксплуатации программ его волнуют значительно меньше. Поэтому получается, что увеличение объемов тестирования повышает издержки ИТ-подразделения без выделения соответствующих ресурсов со стороны начальства ** .
3. Проведение качественного тестирования требует наличия специалистов и инструментов соответствующего профиля. А из п. 2 следует, что ИТ-подразделениям держать собственные группы тестировщиков просто невыгодно.

Общие вопросы тестирования

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

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

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

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

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

Тестирование - процесс также итерационный. После обнаружения и исправления каждой ошибки обязательно следует повторение тестов, чтобы убедиться в работоспособности программы. Более того, для идентификации причины обнаруженной проблемы может потребоваться проведение специального дополнительного тестирования. При этом нужно всегда помнить о фундаментальном выводе, сделанном профессором Эдсжером Дейкстрой в 1972 г: "Тестирование программ может служить доказательством наличия ошибок, но никогда не докажет их отсутствие!".

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

Функциональное и нагрузочное тестирование. Работы первого вида можно отнести к традиционным - проверка ПО на соответствие требованиям по функционалу *** . В последние годы заметно возросла актуальность относительно новых задач, таких, например, как анализ совместимости разрабатываемого продукта с различными программными и аппаратными платформами, приложениями и пр. Второй тип обычно связывают с задачами оценки производительности и масштабирования, но на самом деле он затрагивает гораздо более широкий круг проблем; выявление узких мест в коде программы, обнаружение "утечек" ресурсов и т. д.

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

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

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

Решение проблемы - центры тестирования

Как уже было сказано, ведущую роль в вопросах тестирования играют методология и организационная составляющая. Что же касается инструментария, то его роль в этом процессе вторична и выбор того или иного продукта для автоматизации задач тестирования определяется уже в зависимости от целей и специфики проекта, существующих предпочтений заказчика, бюджета. На рынке сейчас представлен целый спектр средств автоматизированного тестирования, в котором лидируют IBM Rational, Mercury, Segue, Compuware.

В рамках семинара специалистами компании "Аплана" рассматривались возможности автоматизированного тестирования на примере средств тестирования IBM Rational, которые в настоящее время получили значительное распространение среди российских разработчиков (см. врезку "Методология и инструментарий IBM Rational"). Обсуждались также различные сценарии их применения при создании ПО корпоративного уровня. Среди конкретных программных продуктов особое внимание было уделено наиболее популярной сегодня системе IBM Rational Robot.

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

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

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

• выполнение полного комплекса работ по тестированию ПО или отдельных его этапов на стенде Центра или на площадке заказчика;
• консалтинг и обучение заказчиков по вопросам организации процессов тестирования внутри организации;
• аудит тестирования, проводимого сторонними компаниями;
• аутсорсинг технических и программных ресурсов для проведения тестирования.

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

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

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

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

Методология и инструментарий IBM Rational

Общая методология разработки ПО Rational Unified Process выделяет довольно большой набор видов тестирования (см. рисунок). Их можно с известной долей условности разделить следующим образом: Функциональное тестирование (Function testing) тестирование целостности данных (Data integrity testing); тестирование на разных платформах (Configuration testing); тестирование отказоустойчивости (Failover & recovery testing); тестирование доступа (Security testing); инсталляционное тестирование (Installation testing); тестирование пользовательского интерфейса (User interface testing) Нагрузочное тестирование (Load testing) профилирование производительности (Performance profiling); тестирование цикла работы (Business cycle testing); тестирование при большой пользовательской нагрузке (Stress testing); тестирование на больших объемах данных (Volume testing). Для решения этих задач предлагаются следующие основные инструменты: IBM Rational TestManager - управление тестированием; IBM Rational PurifyPlus (Purify, PureCoverage, Quantify) - анализ работы системы в режиме RunTime; IBM Rational Robot - функциональное и нагрузочное тестирование; IBM Rational TestFactory - автоматизация создания тестов; IBM Rational XDE Tester - функциональное тестирование Java и web-приложений. Из сопоставления двух этих списков видно, что каждый продукт покрывает несколько типов тестирования. Вот краткая характеристика этих инструментов. IBM Rational TestManager необходим на всех этапах тестирования, предоставляет в распоряжение команды общие средства планирования, проектирования, исполнения и анализа тестов с использованием единой панели управления. Данный продукт имеет собственное хранилище данных, что обеспечивает более качественное управление версиями. Любой инструмент тестирования ПО, обладающий собственным API, не сложно интегрировать в единую систему, при этом может поддерживаться большинство исполняющих платформ тестирования. IBM Rational PurifyPlus включает три инструмента, предназначенных для анализа в режиме реального времени приложений и компонентов, разработанных с помощью Visual C/C++, C#, VB, VB .NET, Java, Java .NET. Purify обеспечивает автоматическое выявление ошибок, связанных с памятью, при этом выделяются источник и расположение ошибки. Если доступен исходный код, то его можно исправить непосредственно из Purify. Запатентованная технология Object Code Insertion позволяет выявлять ошибки доступа к памяти не только в исходном коде, но и в двоичных программных компонентах (DLL, объекты COM/DCOM, ODBC). PureCoverage - средство автоматического определения непротестированного кода. Quantify выполняет оценку производительности, определяя узкие места приложений и компонентов, как с исходным кодом, так и без него. Встроенные средства анализа данных помогают проводить сравнение результатов тестовых прогонов для различных вариантов кода. IBM Rational Robot - средство создания, изменения и выполнения автоматизированных тестов Интернет-приложений, ERP-систем и клиент-серверных решений. С его помощью обеспечивается объектно-уровневая поддержка при создании приложений на различных средствах разработки. Сценарии функциональных тестов генерируются в среде SQABasic, синтаксически совместимой с VB; встроенный редактор позволяет расширить сценарии тестов необходимыми процедурами и логическими условиями. Предусмотрена возможность создания специализированных тестов для различных типов программных объектов. Для формирования скриптов используется собственный Си-подобный язык. IBM Rational TestFactory - инструмент автоматической генерации скриптов тестирования посредством всестороннего анализа запущенного приложения для выявления дефектов надежности. Поскольку в программах имеется огромное число путей выполнения, проблема заключается в том, чтобы создать тесты, которые проверяют полный функционал приложения за минимальное число шагов. IBM Rational XDE Tester - специализированный инструмент для тестирования Java-приложений (J2EE, J2SE, SWT, AWT/JFC) и Web-приложений (HTML, DHTML, XML, JavaScript, апплеты Java). Текстовые сценарии пишутся на Java, технология ScriptAssure обеспечивает проверку достоверности динамических данных. Среда тестирования реализована в оболочке Eclipse, при этом имеется возможность встраивания инструмента в WebSphere Studio и Rational XDE Developer.