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

3.1. Извлечение имен параметров и их значений

Как уже было отмечено ранее, при работе с Web-приложением пользователь непосредственно взаимодействует с посредником в виде Web-браузера. Браузер, в свою очередь, взаимодействует с Web-сервером, на котором работает приложение, по протоколу HTTP (конечно, возможно использование других посредников и других протоколов, однако они применяются достаточно редко, и здесь мы их рассматривать не будем). Для передачи данных Web-браузера серверу протоколом HTTP [11] предусмотрено несколько методов передачи параметров, из которых в большинстве Web-приложений используются два — GET и POST. Параметры GET — это параметры, передаваемые непосредственно в адресной строке Web-браузера. Параметры POST передаются вместе с пакетами данных (и используются, как правило, либо для передачи больших объемов данных, поскольку не имеют ограничений на размер, либо чтобы не загромождать адресную строку браузера).

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

Каждый скриптовый язык, рассчитанный на применение в Web-приложениях, предоставляет программистам удобные и унифицированные способы доступа к параметрам запроса. Так, в языке PHP доступ к параметрам, переданным скрипту методами POST и GET, обычно осуществляется через ассоциативные массивы $_POST и $_GET соответственно (или с помощью их устаревших аналогов, $HTTP_POST_VARS и $HTTP_GET_VARS), либо с использованием массива $_REQUEST, который в дополнение к таким переменным содержит пользовательские данные, передаваемые Web-браузером — так называемые cookie. Ключами в этих массивах являются имена параметров; в ответ на обращение по ключу возвращается значение соответствующего параметра. Аналогичный подход с использованием ассоциативных массивов применяется в Perl.

Таким образом, в случае PHP для определения имен параметров, воспринимаемых скриптом, достаточно выделить из текста скрипта использования массивов $_REQUEST, $_POST и $_GET, и проанализировать, по каким ключам производится выборка из этих массивов. В простейшем и самом распространенном случае ключ, по которому производится выбор элемента — это и есть имя параметра. Процесс извлечения таких имен из исходного кода легко автоматизируется. Не стоит при этом забывать, что скрипт может подключать другие файлы; анализ кода подключаемых файлов также может быть востребован.

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

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

Для решения этой задачи необходимо выявить, где в вычислениях условий операторов ветвления используются параметры запроса, а также какие значения являются операндами в операциях сравнения, где один из операндов — параметр запроса. Сложность решения такой задачи также зависит от структуры исходного кода приложения. Для языка PHP можно сказать, что, как и в случае поиска имен параметров, поиск значений проще всего автоматизировать, если при вычислении условий операторов ветвления производится непосредственное обращение к массивам $_REQUEST, $_POST или $_GET, а сравнение производится с константными выражениями.

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

• обращение к массивам $_REQUEST, $_POST и $_GET производится непосредственно по именам параметров;

• если в вычислении условия для оператора ветвления используется значение, полученное в запросе, то обращение к этому значению производится непосредственно через обращение к массивам $_REQUEST, $_POST и $_GET;

• если в операции сравнения один из операндов — параметр запроса, то второй — константа.

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

3.2. Зависимости параметров

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

Можно выделить два основных вида зависимостей между параметрами:

• значения параметров {a1, a2, ... an} используются, только если в запросе присутствуют параметры {b1, b2, ... bm};

• значения параметров {a1, a2, ... an} используются, только если в запросе присутствуют параметры {b1, b2, ... bm} и их значения лежат в интервалах {v1, v2, ... vm} соответственно;

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

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

4. Вынесение вердикта о правильности работы приложения

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

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

4.1. Ошибки взаимодействия с внешними системами

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

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

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

4.2. Соответствие спецификации XHTML

Web-приложение создает страницы в формате HTML либо XHTML [1]. Стандарт XHTML является более строгим; соответствие страниц этому стандарту облегчает работу Web-браузеров по их отображению и уменьшает время их загрузки. Соответствие спецификации XHTML позволяет избежать ошибок, связанных со структурной разметкой страницы (отсутствие необходимых тегов, использование атрибутов, которые могут поддерживаться не всеми браузерами и т.п.). Стандарт предъявляет строгие требования только к структуре документа, не затрагивая его содержимое; однако, как показывает практика, несоответствие сгенерированной страницы спецификации XHTML часто является следствием некорректной обработки данных, а не ошибкой форматирования страницы (при условии, что шаблоны разметки, используемые для формирования страницы, соответствуют стандарту XHTML).

Например, рассмотрим приложение, которое выводит текстовые данные, внутри которых могут содержаться угловые скобки — '<' и '>' (например, декларации шаблонов C++). Если угловые скобки печатать в документ HTML «как есть», то браузер будет воспринимать текст между двумя парными скобками как тег, и отображать его не будет. Однако поскольку такого «тега», скорее всего, не существует (не предусмотрено спецификацией XHTML), то при проверке на соответствие документа XHTML будет выявлена ошибка.

Для проверки соответствия документа спецификации XHTML существуют свободно доступные инструменты, например, Offline HTMLHelp.com Validator [13].

4.3. Анализ лог-файлов Web-сервера

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

$select = 'SELECT Aid, Aname FROM Application';
$res = Query($select);
while( $row = mysql_fetch_array($res) ) {
       print 'Application '.$row['Aname'].' '.$row['Aversion'];
}

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

Notice:  Undefined index: Aversion

При этом будет указан файл и номер строки, где произошло обращение по некорректному ключу.

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