Home

Автор: Дмитрий Юшкевич

В основу этой методики лег тот факт, что все развитые промышленные СУБД имеют то или иное средство профилирования своих процедур. Его основное предназначение — оценка производительности написанного кода (функции, процедуры и т.д.). Но есть и приятная второстепенная особенность: обычно это средство (в Oracle — пакет dbms_ profiler) имеет возможность получать статистику по номерам выполненных строк кода.

Этой статьей я бы хотел несколько сгладить уклон в сторону «black box testing», который явно просматривается как в статьях, так и на страницах форума. Все знают о существовании 2-х основных методологий тестирования — «черного» и «белого» ящика («серый ящик», как производную от этих двух методологий, оставляю за границей данного обсуждения). Не буду писать о пользе тестирования «белого ящика» и о том, что в рамках тестирования «белого ящика» используется гораздо больше технологий, чем просто оценки покрытия (и не только операторов). Однако замечу, что традиции тестирования таковы, что «белая» проверка считается, в основном, делом самих разработчиков ПО — т.е. программистов. Но жизнь зачастую взваливает заботу о «белом ящике» все-таки на плечи тестировщиков.

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

В силу производственной необходимости, меня интересовало покрытие операторов кода, написанного на pl\ sql (для Oracle). Ни о каких существующих «Oracle-ориентированных» средствах я не слышал. Поэтому пришлось разрабатывать определенную методику.

В основу этой методики лег тот факт, что все развитые промышленные СУБД имеют то или иное средство профилирования своих процедур. Его основное предназначение — оценка производительности написанного кода (функции, процедуры и т.д.). Но есть и приятная второстепенная особенность: обычно это средство (в Oracle — пакет dbms_ profiler) имеет возможность получать статистику по номерам выполненных строк кода. Именно эту особенность я и использовал для проверки своих приложений, не имеющих визуальной части, а состоящих только из серверного pl\sql-ного кода. В качестве примеров таких приложений можно привести приложения-загрузчики файлов в БД (обработчики строк), серверные процессы расчета абонентской платы, тарификации, биллинга, широко использующиеся в биллинговых системах.

Для оценки покрытия при помодульном тестировании приложений (Unit Test) я использовал сам профайлер — пакет dbms_ profiler — и три его служебные таблицы: PLSQL_ PROFILER_ RUNS, PLSQL_ PROFILER_ UNITS, PLSQL_ PROFILER_ DATA.

В общих словах, методика выглядит следующим образом:

1. Перед использованием методики удаляю (delete) информацию об исследуемых пакетах, которая может находиться в таблицах профайлера.
2. Включаю профайлер.
3. Выбираю одну из процедур\функций тестируемого пакета и запускаю ее на выполнение.
4. После завершения выполнения процедуры\функции оцениваю уровень охвата кода, выполнив запрос к служебным таблицам профайлера. Приблизительный вид запроса таков:

selectdistinct d.line# from PLSQL_PROFILER_DATA pd, PLSQL_PROFILER_UNITS pu where pd.runid = pu.runid and pd.unit_number = pu.unit_number and pu.unit_type = 'PACKAGE BODY' and pu.unit_name = SQL_NAME,

где SQL _ NAME — имя тестируемого пакета.

Соотношение числа хотя бы раз выполнившихся строк (значение поля PLSQL_PROFILER_DATA. total_ occur != 0) к их общему числу дает текущий коэффициент охвата. Назовем его Result. Если полученное значение больше или равно назначенного коэффициента (например, 0.9), то на этом оценку покрытия завершаю. Интересно отметить, что первичный проход по основной функциональности модуля у меня еще ни разу не показывал коэффициента, больше чем 0.4.

1. Если полученное в Result значение меньше заданного коэффициента охвата, то необходимо понять, какие строки пакета не исполнялись еще не разу с самого начала тестирования пакета. Для этого выбираю из служебных таблиц все номера строк с total_ occur = 0.
2. Анализ текста этих строк приводит меня к условиям, исполнение которых обеспечит вход программы в не пройденные ранее строки. При этом уделяю первоочередное внимание тем строкам, которые перечислены в списке с большей «кучностью». Т.е. если список выглядит следующим образом: «34,35,67,68,69,122,167,168,170, 171,173, 278,280,281», то первоначально стараюсь понять, отчего не было ни одного прохода в области строк «167,168,170,171,173».
3. На основании выводов, сделанных в предыдущем пункте или повторяю тот же тест с новыми условиями, или, если возможности этого теста исчерпаны, перехожу к новому тесту на базе новой процедуры\функции пакета. Тесты проводятся до тех пор, пока не получаю Result >= требуемого коэффициента покрытия.

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

Уверен, что «white box testing» может существенно снизить стоимость исправления ошибки и повысить конечное качество проверяемого продукта.