Результаты
Автоматические тесты для LSB Навигатора позволили к настоящему времени выявить около 30 ошибок, связанных с функциональностью. При этом общее число ошибок, занесенных в базу ошибок Навигатора за время его разработки — 250. Кроме того, автоматические тесты играют роль регрессионных и позволяют следить за тем, что генерируемые приложением страницы соответствуют стандарту XHTML; выполнение этой работы вручную нереалистично из-за сложности приложения и его базы данных. Разработка же анализатора скриптов и генератора тестов заняла 2 человеко-дня.
Характеристики генерируемых тестовых наборов по состоянию на декабрь 2007 года приведены в Таблице 1. Тесты делятся на две категории, в соответствии с режимом работы LSB Навигатора, для которого они предназначены. LSB Навигатор предоставляет два режима работы — режим пользователя (“Browse mode”) и режим администратора (“Administration mode”). При работе в режиме пользователя не допускается никаких изменений в базе данных (т.е. осуществляются только выборки данных при помощи оператора SELECT), в то время как в режиме администратора предоставляется практически полный контроль над базой данных. Скрипты, реализующие режим администратора, могут осуществлять гораздо больше различных запросов к базе данных и принимают на вход значительно большее число параметров. Ввиду этого тестирование работы в режиме администратора занимает больше времени, чем в случае режима пользователя.
| Режим работы | Количество тестов | Время генерации | Время тестирования | ||||
| Пользователь | 2912 | 15 с | 1ч. 30 мин. |
| |||
| Администратор | 28740 | 10 мин. | 6 ч. 15 мин. |
Таблица 1. Характеристики тестовых наборов для режимов пользователя и администратора LSB Навигатора.
Число тестов для режима администратора превосходит число тестов для режима пользователя в примерно 10 раз, а время их генерации — в 40. Это обусловлено тем, что при генерации тестов для режима администратора анализатор кода использует существенно больше системных ресурсов, что, в частности, приводит к активному использованию swap-раздела. В то же время затраты на выполнение тестов для этого режима отличаются не столь сильно; этот факт объясняется тем, что любой запрос, выполняемый в режиме администратора, затрагивает только одну таблицу базы данных (более того, существенная часть запросов обращается только к одной записи таблицы). В режиме же пользователя выполняется много сложных агрегатных запросов, выбирающих данные сразу из нескольких таблиц (например, при сборе различных статистических данных).
Большую часть времени (порядка 80%) занимает проверка получаемых страниц на соответствие спецификации XHTML. Соответственно, отключение этой проверки позволяет за то же время сгенерировать и выполнить большее количество тестов (например, перебирая больше различных комбинаций параметров). Более того, время анализа результатов тестирования сильно зависит от числа выявляемых при такой проверке ошибок (что обусловлено особенностями используемого для проверки инструмента) — так, наличие ошибок, проявляющихся в 250 тестах для режима пользователя (8% от общего количества) привело к увеличению времени их выполнения до 8 часов.
Что касается непосредственно ошибок, выявляемых тестами, то их можно разделить на следующие категории.
Вывод имен классов, типов и шаблонов без преобразования угловых скобок, знака ‘&’ и других специальных символов (на страницах, содержащих декларации функций и классов C++), которые могут быть интерпретируемых Web-браузером как часть разметки страницы, а не как данные. Такие ошибки выявляются в процессе проверки страницы на соответствие спецификации XHTML.
Ошибки, связанные с экранированием символов в строках, используемых в запросах к базам данных. Отсутствие экранирования приводит к некорректности запроса SQL и получению ошибки при работе с СУБД. Обнаружение таких ошибок чрезвычайно важно, т.к. их наличие в приложении делает потенциально возможным использование SQL-инъекций — способа взлома сайтов и программ, работающих с базами данных, основанного на внедрении в запрос произвольного SQL-кода [16].
Ошибки, связанные с некорректной обработкой переданных параметров. При определенных значениях параметров на их основе может быть создан некорректный SQL-запрос, что приведет к ошибке взаимодействия с СУБД.
Обращение к ассоциативному массиву по некорректному ключу. Такие ошибки выявляются на основе анализа лог-файлов HTTP-сервера. Как правило, они являются следствием некорректного задания имен полей, выбираемых в запросе к базе данных, либо банальных опечаток.
Измерение покрытия кода показало, что в процессе тестирования покрывается 60% строк кода скриптов (как уже упоминалось ранее, всего скрипты содержат около 17000 строк кода). Для сравнения — если просто обратиться к каждому скрипту без передачи ему каких-либо параметров, то покрытие составит 15%. Для измерения покрытия используется свободный инструмент PHPCoverage компании Spike Source [17]. Стоит отметить, что анализ покрытия кода также помогает выявлять недостижимый код, удаление которого приводит к увеличению покрытия.
Несмотря на достаточно высокое значение тестового покрытия, в процессе ручного тестирования встречаются ошибки, которые потенциально могли быть выявлены и автоматическими тестами (как правило, это ошибки работы с базой данных, либо ошибки формирования страницы, приводящие к нарушению спецификации XHTML). Такие ошибки проявляются на специфических значениях параметров при определенном их сочетании; они не выявляются автоматически, поскольку в процессе генерации тестов перебираются не все сочетания значений параметров. Как уже отмечалось ранее, генератор тестов обладает некоторыми средствами настройки стратегий перебора параметров, эти средства осуществляют достаточно грубую настройку. В результате при задании достаточно жестких ограничений на комбинации параметров тесты пропускают некоторые ошибки, а даже незначительное ослабление этих ограничений приводит к слишком большому количеству тестов, выполнение которых может длиться больше недели. Поэтому возможность более тонкой настройки генератора является одним из приоритетных направлений развития в ближайшем будущем; также возможно, что уменьшению числа тестов без потери качества может помочь более глубокий анализ зависимостей между параметрами.
Тем не менее, в автоматических тестах предусмотрена возможность использования запросов, созданных человеком, наряду со сгенерированными тестовыми запросами. Все запросы, которые привели к ошибкам, но при этом не попали в список сгенерированных, добавляются в «ручной» список. Таким образом, можно гарантировать, что если по каким-то причинам ошибка появится снова, то она будет выявлена автоматически.
