Отправляет email-рассылки с помощью сервиса Sendsay

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

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "О карьере и профессиональном развитии IT-специалистов" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Июнь 2006   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Автор
Вячеслав Панкратов

Статистика

3.119 подписчиков
+11 за неделю
←   Все выпуски   →

Один из способов оценки покрытия операторов при тестировании pl\sql кодов (Дмитрий Юшкевич)


 
SOFTWARE-TESTING.RU
Информационный канал
 
  • Тестирование и качество информационных систем
  • Сообщество специалистов отрасли
  • Публикации и обсуждения материалов
  • Журнал "Тестирование и Качество"
Новости :: Пресс-релизы :: Библиотека :: Литература :: Инструменты :: Форумы :: Работа :: О проекте

Рассылка:
Тестирование программного обеспечения
Рассылки Subscribe.Ru
Работа для тестировщиков и QA. Вакансии ведущих компаний.
Тестирование и качество
Записки тестировщика
Автоматизированное тестирование
Тестирование программного обеспечения
Тестирование информационной безопасности
Последние обсуждения форума тестировщиков
:: Спонсоры проекта Software-Testing.Ru
:: Сервисы  
VIP ВАКАНСИИ ОБУЧЕНИЕ

Вакансии ведущих компаний!

Обучение для тестировщиков и QA!
  • Тренинги и семинары
  • Курсы по инструментам и технологиям
Профессиональные центры:
По поводу сотрудничества с проектом Sofwtare-Testing.Ru обратитесь к нашему консультанту
:: Публикации из раздела "Тестирование"

Один из способов оценки покрытия операторов при тестировании pl\sql кодов

Автор: Дмитрий Юшкевич (<Петер-Сервис>)

Этой статьей я бы хотел несколько сгладить уклон в сторону "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" может существенно снизить стоимость исправления ошибки и повысить конечное качество проверяемого продукта.

Автор: Дмитрий Юшкевич (<Петер-Сервис>)
:: Рекомендуем
Быстрое тестирование

Agile Software Development with SCRUM

Ken Schwaber, Mike Beedle

Кен Швабер на своих тренингах предлагал вводить практику наказания "рублем", когда каждый опоздавший на проектный митинг платит по доллару или евро, собранные деньги впоследствии он отдавал бездомным на улице.
Купить в ОЗОНЕ
© 2003-2006 www.software-testing.ru
В избранное