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

Тестирование? Зачем?

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

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

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

О классификации тестов

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

Сначала о временных характеристиках тестирования. Естественно, до того, как что-то написано, и проект, и спецификации проверяются специалистами, но это тестированием в полном смысле слова назвать достаточно сложно. Настоящее тестирование начинается, когда есть уже хоть какой-никакой код. Сначала идёт альфа-тестирование, когда тестируются вновь написанные возможности. Также к альфа-тестированию относится и регрессионное тестирование, когда тестируют уже исправленный код, в котором могли появиться какие-то новые ошибки. Когда разные компоненты проекта "склеены" в одно целое и самые очевидные баги уже истреблены, начинается бета-тестирование. "Беты", в основном, уже доступны широкой публике. Выпуская бету, разработчики получают возможность тестировать программу "в полевых условиях". При этом пользователям говорят, что ошибок всё-таки может быть ещё достаточно много, и разработчик не несёт никакой ответственности за сохранность данных и прочие мелочи жизни, почему-то важные для пользователя. Самое забавное, что разработчик в большинстве случаев и так ни за что не отвечает благодаря пресловутому принципу "AS IS", избавляющему его от мучений совести и судебных издержек как результата использования созданной им программы. Но на бете тестирование, на самом деле, не кончается. Для достаточно сложных и крупных систем есть ещё этап пострелизного тестирования, которое продвинутые софтверные вендоры называют консалтингом. Нередко с компании, купившей такую систему, даже берут деньги за такой "консалтинг", заключающийся, по большому счёту, именно в устранении багов, появившихся при интеграции системы.

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

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

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

Статический анализ

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

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

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

Всё ли тестировать?

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

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

Резюме

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

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by