Записки безумного тэстера

QAлификация :)

Mon, 17 Nov 2008 12:03:07 GMT

Собсна вот и родилось что то, будем развивать!

Адрес: qa.co.kg
Авторский коллектив: Роман Кононов (собсна я он и есть) и Самат Жукешов (блог «QA о разном»).

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

Для авторов, это своего рода записная книжка/блог/форум и даже своего рода мини портал, который объединяет людей близких к обеспечению качества программного обеспечения, здесь ведут обсуждения, публикуют заметки, вопросы и решения проблем связанных с общим понятием Software Quality Assurance - как тестирования программного обеспечения так и обеспечения качества процесса разработки, управления, сопровождения и деплоя. Главное - это обмен опытом.

via http://www.it4business.ru/blogs/1639/

PS Всем спасибо за участие,содействие и пеар (надеюсь и продолжите это все делать)

Визуальный интерфейс для SVN

Mon, 17 Nov 2008 11:10:50 GMT

Нашел интересный проект, посвященный созданию визуального интерфейса для распространенной системы контроля версий - SVN. Сам проект называется SVN Monitor

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

В общем интерфейс получился достаточно наглядный и юзабельный :)

А нужно ли автоматизировать тест?

Mon, 03 Nov 2008 09:30:11 GMT

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

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

Twist + Frankenstein или попытка впихнуть невпихуемое

Fri, 31 Oct 2008 10:44:41 GMT

Итак снова продукт от Thoughtworks о котором я недавно писал. Прошлый раз я описывал написание selenium (браузерных) тестов в продукте Twist, в этот раз попробуем проверить другую заявленную возможность - написание тестов на фреймворке Frankenstein .

Фреймворк франкенштейн ориентирован на тестирование java - swing приложений, сами тестовые скрипты пишуться ручками на понятном DSL подобном языке.

Для начала пробуем создать простейший тест для java-gui приложения.

При создании проекта выбираем тип Frankenstein

Указываем Main-Class (можно глянуть в манифесте) и дополнительные параметры (без параметров запустить не получилось, он отправляет приложению какую то свою кашу)

Далее идем в свойства проекта и добавляем ВСЕ необходимы для запуска приложения либы (в том числе и само приложение)

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

В итоге получается следующий код

Собсна процесс записи очень простой и удобный, за исключенией того, что пишет Твист с ошибками, на которые сам потом и ругается (не комплируется!) объекты франкенштейн определяет очень нестабильно, попадает по объектам нечасто (JTree так и не увидел).

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

В мемориз

Thu, 30 Oct 2008 08:12:06 GMT

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

По содержанию довольно актуальные и интересные темы в частности:

Turning Software Testing into the Backbone of your Quality Assurance System
Requirements-Based Testing - Ambiguity Reviews
Surveying Test Strategies:A Guide to Smart Selection and Blending
Finally Usability Testing?
Requirements and test management:More safety in vehicles through traceable testing

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

В общем маст хев, подписался на рассылку, была бы еще возможность доставить в наши пенаты за разумные деньги.

Кстати может кто подскажет еще онлайн периодику по теме тестирования?

Обновился TestabilityExplorer

Tue, 28 Oct 2008 09:53:22 GMT

Давно не следил за обновлениями данной тулзы, как оказалось обновился до версии 1,2,0 из изменений собсна более информативные отчеты - если раньше отображался только общее количество очков тестабельности, то сейчас можно развернуть более подробную статистику например так

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

К интеграционке также прикручивается методом ant task-а, из анализируемых языков пока таже java, будем ждать развития.

P.S

На официальном сайте можно посмотреть занимательную статистику отражающую результаты проверки на тестируемость различных популярных проектов (AspectJ,JRuby)

Twist или танцы вокруг DSL

Thu, 16 Oct 2008 11:44:39 GMT

Не так давно состоялся бета релиз тулзы для функционального совместного тестирования - Twist. Компания,что выпустила данный продукт уже не раз отмечалась весьма интересными проектами в области тестирования и управления, взять хотя бы Mingle ишшу трекер или CruiseControl - сервер интеграции с которого все начиналось.

Итак Твист (собсна название началось от девиза - пусть вся команда танцует твист) позиционируется как платформа для совместной разработки,поддержки и запуска тестов. Слить данный продукт можно с сайта производителя тамже после регистрации можно получить ключик к триальной 60-ти дневке.

Начнем с интерфейса, он полностью экклиспсовский, собственно это далеко не первый платный продукт основанный на этой платформе (вспомнить хотя бы Zend Studio), интерфейс до боли знакомы и поэтому простой в понимании и обращении выглядит основное окно примерно так

Классическая экклипсовская навигация, редактор кода с автодополнением и подсветкой, полная поддержка java ну и прочие вкусности взрослой IDE.

Попробуем написать простейший тест. Для начала создаем проект,создаем новый пустой сценарий и пытаемся что то сделать, вот тут самое интересное, пока я физически не полез в справку и усиленно ее не почитал, трудно было догадаться что нужно в определенном месте жмакать ctrl+1, выглядит процесс написания DSL примерно так

Здесь показан процесс создания фикстуры (или простейшего тест плана), далее заполняем тест план конкретными действиями

как видно каждый шаг, описанный понятным русским языком мы можем либо записать в рекордере, либо отредактировать ручками в виде java кода.

пишем код ручками:

Или записываем в браузере

В общем все очень просто и понятно.

Далее каждый тест принадлежит определенному контексту

Он необходим для того, чтобы задавать первоначальные условия запуска теста, например иньекция тестовых данных в базу или выставление определенных переменных или логин под определенным пользователем (аналог Before и After в JUnit)

Также каждый тест можно помечать определенными тегами

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

Запуск тестов тоже очень удобный и производиться нажатием кнопки Execute на тесте, либо запуском всех тестов в проекте.

В общем в итоге у меня получился следующий простенький тест

и следующий код (код полностью автогенерированный!)

Как видно все очень просто и понятно (если не считать того, что нужно усиленно покурить мануал), штука я бы сказал очень удобная и вплане организации совместной работы и вплане записывания/отладки тестов (селениуму многих вещей очень не хватает) и если сравнивать с аналогами (FITnesse,AOST) серьезная и расчитанная именно на использование (хотя и платная). Из минусов (помимо сложностей с логикой) хотелось бы заметить, что не нашел как же это все прикручивается к интеграционной машине (поддержка анта в релизе заявлена) ну и скажем так отчетность не порадовала (стандартная полосочка ну сколько прошло/упало). В общем для беты вполне серьезный продукт и думаю в дальнейшем можно будет активно использовать.

Оценка покрытия кода (Code Coverage)

Thu, 09 Oct 2008 12:14:29 GMT

На днях читая блоги наткнулся на непонятное определени - оценка покрытия согласно С1, как оказалось это один из видов оценки покрытия кода, спросив у гугла наткнулся на достаточно подробное описание видов покрытия, как оказалось их гораздо больше 3, что я описывал ранее. Итак виды покрыти кода.
1)Собсна то самое(Statement) C1 - линейное покрытие кода, считается каждый выполненный оператор (строчка кода или блок).Данный вид покрытия самый простой и не требует изменения исходного кода.
2)Оценка покрытия кода с учетом условных операторов(Decision - С2) - в каждом условном операторе (if,while,switch...) проверяется вызывался ли условный оператор со значением условия true и false, данный способ оценки более адекватный, но не учитывает тот случай если условие содержит несколько выражений - например if(sample||sample2), при этом вариант sample2 не проверяется/вызывается (если это функция).
3)Оценка покрытия кода с учетом всех условий(Condition) - проверяется покрытие кода на предмет того вызывается ли условный оператор со всеми возможными значениями проверяемых переменных. Данный способ более адекватен чем предыдущий и позволяет получить объективную оценку покрытия
4)Оценка покрытия с учетом путей выполнения(Path Coverage) - в данном случае считаются все пути, которые выполняются в процессе работы (путь - уникальная последовательность выполнения операторов, с учетом условных операторов)
5)Оценка покрытия с учетом вызовов функций(Function Coverage) - учитываются только уникальные вызовы функций - скажем так очень не объективная оценка покрытия (также ее называют BullsEye coverage)
6)Оценка покрытия с учетом выполнения циклов (Loop Coverage)- данная метрика оценивает выполнялись ли циклы имеющиеся в коде один или более раз или не выполнялись.
7)Оценка покрытия с учетом одновременного выполнения (Race Coverage)- показывает выполняется ли какой либо код одновременно - помогает выявить возможные проблемы в частности Race condition
8)Оценка покрытия с учетом операторов сравнения - выявляет встречаются ли в операторах сравнения (>,<) непредусмотренные значения (например 1>1).
9)Оценка покрытия с учетом выполнения таблицы конечных автоматов - определяет выполнились ли все возможные ветки в таблицы конечного автомата...

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

Обновление Marathon...

Mon, 06 Oct 2008 08:46:58 GMT

В свежей версии Марафона (http://www.marathontesting.com/Home.html) наконец пофиксали понты с кликом по меню. Проблема заключалась в том, что в жава приложении написанным при помощи Spring Rich Client на гуи морде меню появлялось не сразу а после прошествии определенного времени, а собсна марафон не мог определить момент подгрузки меню и постоянно падал с NPE при попытке клика по неподгруженному меню, решали подобное через sleep(), но периодически,даже при больших задержках падало.В релизе 1,2,1,1 данный баг уже пофиксан. Наконец можем писать нормальные,стабильные автотесты. Всем индусам авторам марафона - большой рахмет

Tellurium,AOST и много других страшных DSL надстроек...

Fri, 03 Oct 2008 09:59:09 GMT

Давно хотел написать о различных надстройках что появились для селениума. В принципе селениум и сам по себе достаточно удобен для написания автотестов для веба, но вот некоторым неймётся уменьшить уровень вхождения для написания автотестов (чем проще писать, тем больше смогут это делать). В итоге получается очень много различных "химер" на базе селениума - например Selenium+Fitnesse или фреймворк для автотестов о котором я хочу рассказать - Tellurium (раньше назывался AOST).
Так вот АОСТ (так и подмывает назвать его моющим средством, из небезизвестной рекламы) позвоялет писать автотесты для веба практически нормальным английским функциональным языком примерно в слудующем виде:

openUrl "http://code.google.com/p/aost/"
click "menu.project_home"
waitForPageToLoad 30000
click "menu.downloads"
waitForPageToLoad 30000
click "menu.wiki"
waitForPageToLoad 30000
click "menu.issues"
waitForPageToLoad 30000

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

ui.Container(uid: "google_start_page", clocator: [tag: "td"], group: "true"){
    InputBox(uid: "searchbox", clocator: [title: "Google Search"])
    SubmitButton(uid: "googlesearch", clocator: [name: "btnG", value: "Google Search"])
    SubmitButton(uid: "Imfeelinglucky", clocator: [value: "I'm Feeling Lucky"])
}

и далее идет сам скрипт, который собсна позволяет использовать данные определения для совершения процесса тестирования.

Написан Теллуриум на новомодном груви с использованием жава, в комплект уже включены библиотеки для работы с JUnit и TestNG тестами а также сам селениум сервер. Собсна писать можно точно такие же тесты в формате JUnit или TestNG а также просто оформлять тесты в виде отдельных файлов и скармливать их батнику (прежде нужно сбилдить проект) который собсна запускает селениум сервер и выполняет скармливаемый тест (очень кстати удобно и быстро). Хвала разработчикам они подумали и о способах идентификации элементов управления, вместе с теллуриумом поставляется плагин для файрфокса, который позволяет определить идентификатор элемента сразу в формате теллуриума
ставиться правда плагин вручную и при помощи длительного изучения ридми. В общем после недолгих экспериментов получился следующий код

код в принципе очень прост,понятен и линеен, практически идеальный тест, запускается очень просто, путем вызова из командной строки бат файла "rundsl.bat " в качестве параметра к которому отправляется имя дсл файла. Выполняется весь скрипт очень быстро (Теллуриум предусматривает ожидание прогрузки страниц, где это необходимо), единственно результаты будут доступны только в виде ReturnCode консольного приложения, но ничто не мешает запускать тесты JUnit с прикрученным теллуриумом. Кстати при написании скрипта можно использовать все мощностя языка груви (условные операторы,циклы и т.д.).

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

Скриншотер

Fri, 26 Sep 2008 10:59:34 GMT

Здравствуйте, давно не писал, в основном потому что тупо нет времени, накопилась куча тем, о которых хотелось бы рассказать (клятвенно обещаю, в первую очередь себе, сконвертировать это все в электронный формат). Итак сегодня маленькая но очень удобная программуленька. Один из самых необходимых для тестера инструментов (конечно после рук) является небольшая софтинка для снятия скриншотов. До этого момента пользовался большим и неудобным снагитом девятой версии, большая многофункциональная софтина, которая просит денег и недюжинных способностей для изучения и использования всего его функционала. Недавно в обзорах бесплатного программного софта наткнулся на мелкую китайскую софтинку которая обладает сходным функционалом.
Программка называется PicPic слить можно по адресу - http://picpick.wiziple.net/ прелагаются 2 версии на китайском и английском, весит в районе 800 кб, что только умиляет после многомегабайтного снагита.
По функционалу есть все необходимые функции в частности
-Скриншот окна,экрана,региона,веб страницы
-Возможность измерения размеров объектов линейкой,измерение углов
-Редактирование снятых скриншотов
-Определение цвета под курсором

Интегрируется и ставиться софтинка очень быстро (ставить и не нужно) в автозагрузку добавляется автоматом, все хоткеи настраиваются очень быстро и удобно

В общем от снагита отказался в пользу этой удобной,простой и легкой мелочи. Ведь вся работа облегчается такими мелочами (totalCommander,Miranda,firefox,thunderbird)

Жизненное

Wed, 03 Sep 2008 09:31:46 GMT

Конечно запись совсем даже и рядом не относиться к работе или направлена на решение чьей либо проблемы, но блог все таки является дневником в первую очередь.
Итак с этого дня являюсь преподавателем кафедры ПОКС свово универа в котором собсна и пишу кандидатскую, данный шаг обусловлен совсем даже не попыткой "поднять бабла" или "уговорили на кафедре" а необходимостью отвести определенное количество часов для кандидатского минимума. Держитесь студенты...
ЗЫ не "развожусь"

Факты о багах

Mon, 25 Aug 2008 06:52:37 GMT

80% ошибок "зарыты" в 20% процентах кода
Высокая цикломатическая сложность является маркером бажных мест
Даже если код покрыт тестами на 100% , примерно 35% ошибок появляется из-за отсутствующей логики,
еще 40% ошибок возникает при уникальном сочетании входных данных
остальные являются рапространенными ошибками программистов
Чем дольше баг не фикситься, тем дороже стоит его пофиксить

Тестирование в условиях гибкой разработки.

Fri, 22 Aug 2008 06:27:58 GMT

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

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

Тестирование основанное на оценке рисков - в принципе данный подход существует и в той же водопадной модели, но в условиях быстро меняющегося функционала данный подход особенно важен. Во первых давит ограничение времени итерации, как такового отдельного времени на тестирование практически нет и нужно успеть до конца запланированной итерации (буфер конечно закладывается, но дядька Мерфи берет свое).Также обычно меняется только строго определенный и часто физически независимый функционал, поэтому тестирование только изменений вполне обоснованно. Также узкие/важные места может определять заказчик.
Тесное взаимодействие команды тестировщиков и команды разработчиков - в принципе один из основных принципов гибких методологий это постоянная коммуникация, для тестеров это очень важно, так как часто знание функционала разделено между описанием функционала, разработчиком и заказчиком и очень важно поддерживать коммуникация со всеми.Кстати на счет оптимального соотношения часто рекомендуют минимум 1 тестировщика на 3 программистов.
Использование сервера интеграции - при гибкой разработке, при частых изменениях функционала, при частых коммитах очень важно чтобы тутже проводилась хотя бы базовое регрессионное тестирование,прогонялись юнит тесты, собирались наименее емкие(по времени) метрики.Причем время отклика интеграционной машины на коммит не должно превышать 10 минут (максимально время до переключения человека на другую проблему)
Наличие тестового фреймворка и набора тулзов - для гибкого тестирования очень важно проводить тестирование быстро и без лишних затрат, очень часто затраты как раз таки появляются при рутинной и повторяющейся работе - очистка базы, занесение шаблонных значений, создание нового автотеста, прикручивание автотеста к интеграционной машине - данная рутина должна быть автоматизированна по максимуму, для обеспечение быстрого определения качества новой версии разрабатываемого ПО
Ретроспектива - очень важно после окончания итерации оглянуться назад и определить какие процессы заняли слишком много времения, какие не принесли ожидаемых результатов и каким образом это все лучше реализовать в следующей итерации.
Планирование процесса исправления найденных багов - в ходе частого изменения функционала продукта очень часто отлавливаются различного рода баги, очень важно вовремя определять приоритет багов и планировать процесс их исправления, например баги с высоким приоритетом исправляются в этой итерации с отодвиганием конечных сроков, баги с более низким приоритетом исправляются в следующей итерации.
Общедоступность метрик проекта - метрики проекта должны размещаться в общедоступном месте (как общественный монитор, вебсервер,либо какие либо индикаторы или красные лампочки) и отображать актуальную информацию не только о метриках кода (их собирает сервер интеграции) но и всяческие диаграммы состояния проекта (burn-down,Gantt).Данная практика в первую очередь необходима всей команде, для понимания текущего состояния дел в проекте и соответствующей реакции,также метрики позволяют определять различного рода риски.
Парное тестирование - данная практика является экспериментальной и возможно мое понимание немного отличается.Парное тестирование - это тестирование в паре с разработчиком - при этом у тестировщика появляется знание о продукте и методах его использования,более опытным тестером - при это тестировщик получает опыт новых для него методик тестирования или инструментов или заказчиком - при этом тестировщик расширяет свое видение продукта как конечный пользователь.

В общем тестирование в условиях гибкой разработки очень интересное и главное активное занятие, постоянно кто то что то меняет, коммитит, формирует требования, и это необходимо проверять, находить проблемы, решать их постоянно общаясь со всеми участниками проекта и получать удовольствие :)

Составные качества. Юзабилити

Fri, 15 Aug 2008 06:48:22 GMT

Здравствуйте.
Юзабилити - качественный атрибут отражающий то насколько просто\удобно\быстро можно использовать интерфейс предоставляемый конечному усреднённому пользователю.Итак получилось довольно непонятное определение, попробуем попроще

, разложим это самое "просто\удобно быстро" на составляющие, обозначающие что же на самом деле значит "простой интерфейс".
Наверное в первую очередь "простой" интерфейс - означает понятный, некий интерфейс основанный на уже виденных ранее вещах, своего рода интуитивно понятный, т.е увидев его пользователь должен с первых минут должен понять что нажимать,куда вводить и что он получит в итоге, причем не обязательно такой интерфейс должен основываться на стереотипах, достаточно чтобы он воспринимался интуитивно (что то вроде лестницы).
Следующий момент - простой интерфейс не должен быть перегружен лишними деталями, компонентами, он должен ориентироваться на конкретную цель, причем ориентироваться с максимальной эффективностью для скорости работы пользователя, т.е если это интерфейс веб-магазина там не должно быть функций биржи или панели запуска космического корабля.Далее - простой интерфейс должен легко запоминаться, либо основываясь на стереотипах, либо быть очень простым, либо предоставлять свой специфически-удобный метод работы с ним.
Далее интерфейс должен позволять легко и удобно откатывать/исправлять ошибки, чтобы не было мучительно больно потерять кучу текста удаленного по ошибке.
Ну и одно из самых важных - интерфейс должен быть приятным, нравиться пользователю и приносить своего рода удовольствие от работы с ним (как в той рекламе - "и в салоне так пахнет кожей, что все телки будут твои").
Итак состаные юзабилити:

Понятность
Эффективность
Запоминаемость
"Откатываемость"
"Красота"

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

Полный бизнец....

Fri, 08 Aug 2008 11:09:56 GMT

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

не выявилось, время отклика в пределах нормы, тесты откатались нормально, загрузка сервака средняя. Как оказалась проблемы были в коде, в евоной оптимизации под конкретный браузер, собсна о проблемах говорить не мне, решать тоже не мне, я всего лишь опишу как выявили. Погуглив на тему тестирования производительности нашел кучу софтин и сервисов, которые собсна все это и делают - оценивают производительность. Софтины совершенно различные начиная с плагинов для файрфокса(firebu,YSlow) и заканчивая вышеупомянутыми jmeter и ab. Но у применяемых мной была одна большая проблема, они всего лишь эмулировали поведение браузеров а не были им. Одна из этих софтин и оказалась искомым решением - Fiddler. Данный инструмент является расширенным прокси сервером, который берет на себя трансляцию пакетов с поддержкой фильтрации и и отчетности буквально по каждому запросу/ответу. Итак подробней - начать работать очень просто, буквально настраиваем в любом браузере работу через прокси (порт по умолчанию 8888) и наблюдаем в главном окне фиддлера собсна всю обменку выглядит примерно так...

соответственно результат,протокол,запрос,время запроса и дополнительные не менее важные параметры, также присутствует базовый функционал по построению диаграм и простой визуализации, вот например так отображается соотношение контента на тестируемом сайте

а вот собсна и неутешительная статистика

Request Count:     243
Bytes Sent:     124,490
Bytes Received: 702,387 

ACTUAL PERFORMANCE
--------------
Requests started at:    14:24:57:5156
Responses completed at:    16:44:40:7812
Total Sequence time:    02:19:43.2656250
DNS Lookup time:    45,797ms
TCP/IP Connect time:    14,002ms 

RESPONSE CODES
--------------
HTTP/404:     1
HTTP/304:     8
HTTP/301:     1
HTTP/200:     233 

RESPONSE BYTES (by Content-Type)
--------------
        text/x-component:    350,102
                text/css:    13,701
               image/gif:    32,839
                ~headers:    64,872
              image/jpeg:    19,641
               text/html:    109,562
application/x-javascript:    111,670

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

Примерно так выглядит диаграмма запросов

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

Testability...

Thu, 24 Jul 2008 13:18:11 GMT

Здравствуйте.

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

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

Итак начнем с требований к продукту - требования в первую очередь должны быть последовательными, реальными, недвусмысленными, правильными, логичными, полными, понятными также требования необходимо разделять по ролям и по функционалу на независимые use case (на основе которых будут писаться test case).
Определение архитектуры,дизайна и выбор технологий - на этой стадии очень много подводных камней начиная с выбора технологий - технологии должны быть тестируемы средствами автоматизированного тестирования, технологии должны быть просты в установке, деплое, поддержке, удобстве использования, достаточно распространены(что в принципе гарантирует избавление от вышеперечисленных проблем). Дизайн и архитектура должны выбираться с учетом удобства/быстроты/простоты установки,настройки,работы с конечным продуктом (билдить в течении часа 6 варок в приложении с функционалом движка сайта, затем деплойить их еще минут 20, чтобы проверить 1 тикет - ну извините), в общем нужно еще и о конечных пользователях (причем еще и об админах,тестерах,деплойерах). Также все модули/приложения/части проекта должны каким либо образом покрываться тестами, т.е должна быть возможность их протестировать (использование моков,стабов,эмуляторов и т.д.)
Написание кода - в данном случае оценивать тестопригодность кода нужно с позиций "white box", модульного и интеграционного тестирования, т.е начиная от надлежащего оформления кода (code conventions) и заканчивая общими правилами (в том числе и паттернами) написания хорошего кода, кстати я уже писал о средствах автоматической оценки тестопригодности кода.

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

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

Несерьезно об ошибках

Tue, 22 Jul 2008 11:59:52 GMT

Здравствуйте.

Наверное многие уже читали и в блогах и на википедии о различных "необычных" ошибках в частности о гейзенбаге,борбаге и т.д. попробую и я внести свою лепту в классификацию таких ошибок

Итак начнем с наиболее часто встречаемого Гейзенбага(heisenbug) - данный тип ошибок назван в честь принципа неопределенности Гейзенберга, который гласит, что процесс наблюдения объекта влияет на свойства объекта.В программах это чаще всего выражается в том, что в процессе отладки приложения сам дебаггер влияет на скорость и выполнение приложения, а соответственно может повлиять на проявление ошибки. Также такой тип ошибок часто проявлялся в unmanaged языках в случае неинициализации переменных(например c ) в таком случае содержимое переменных приложения после запуска невозможно предугадать.

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

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

Шрединбаг(Schroedinbugs) - данный баг назван по имени эксперимента Шредингера (кот Шредингера, что ни жив ни мертв),основные признаки в том что программа перестает работать в тот момент, когда кто то найдет баг,читая сырцы или вызовет баг в программе своими действиями. Встречается достаточно часто, например вот сейчас в файрфоксе у меня не работает даунлоад бар, после того как я в настройках профиля удалил настройку пути до закачанных файлов, теперь даунлоад бар просто не отображается а при попытке выбора другой папки падает эксепшн.

Стотл(Stotle) - данный тип багов назван в честь греческого философа Аристотеля, характеризуется этот баг тем, что в результате некорректного ввода данных в программу мы получаем некорректный выход, т.е приложение не проверяет входные данные на адекватность а пользователи бывают разные.

Ошибка Фазы луны (Phase of the moon bug)- этот баг чаще всего связан с каким либо параметром, который оказывается связан с временным явлением или завязан на какие либо другие циклически возникающие факторы. История возникновения данного бага уходит корнями в программу, которая апроксимировала фазы луны и выводила их даты в файл, причем длина строки была ограничена 80 символами и очень редко эта длина превышалась и соответственно другая программа, что считывала эти данные из файла падала, отсюда и пошло - бага Фазы луны. Кстати на этом же типе бага в далекие 80 обжегся CERN - они запускали ускоритель частиц,который долго не хотел работать нормально, оказалась причина была как раз в фазах луны, что своим притяжением изменяла геометрию 27километрового ускоряющего кольца, эта история также называется Местью Ньютона.Также сюда можно отнести проблему Y2K

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

Призрак в коде(Ghost in the code) - данный тип бага практически невозможно обнаружить, он живет в приложении годы после рилиза и проявляется только при определенных событиях и при определенных входных данных, поиск такого бага называется "охота на призрака"

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

Всем удачи и поменьше вам трудных багов!

Testability

Mon, 21 Jul 2008 13:02:43 GMT

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

приложение(требования,описания,исходный код). Оценка тестируемости любого вида достаточно сложный процесс и оценить объективно,всесторонне очень трудно. Например чтобы оценить тестируемость требования к продукту необходимо составить на основе данных требований адекватные use case, на основе которых уже реализовывать test case. На днях наткнулся на интересный инструмент, некую попытку определить тестируемость, увы не заказчика и не разработчика, а всего лишь кода и всего лишь для модульного вида тестирования. Иструмент называется testability-explorer, работает по принципу анализа java байт кода и определения в нем классов наиболее непригодных для написания модульных тестов. Основными критериями служат оценка цикломатической сложности каждого метода, но вычисляется она не обычным способом а к сложности метода добавляется также сложность коструктора класса (ибо нестатический метод без инстанционирования мы не вызовем) и сложность вызываемых в данном методе других методов и классов, также вычисляется количество статических ссылок на сторонние объекты (без использования инъекции зависимостей) и получается итоговое число которое определяет тестируемость класса. В принципе инструмент достаточно простой для использования, очень легко прикручивается к анту и позволяет генерировать простые и понятные графики, но для практического применения разве что пригоден начинающим разработчикам (ткнуть носом в пахнущий код) или для изучения(цикломатическая сложность,инъекция зависимостей- зачем оно все нужно и где это применять), также иногда интересно посмотреть на устаревший код(боже какой же кал мы писали...)
Отчет выглядит примерно следующим образом( диаграмки кстати генерятся при помощи гугл апи в онлайн)

Google _ingletone Detector

Wed, 09 Jul 2008 10:31:02 GMT

Всем доброго времени суток.

Паттерн Singleton или Одиночка очень часто ипользуется

.Введите содержимое врезки, у данного шаблона существует достаточно много плюсов например: контролирование количества экземпляров класса, уменьшение количества имен,также его применение позволяет контроллировать глобальные переменные. Из минусов можно упомянуть то что применение данного шаблона повышает связанность, нарушает принцип SRP, увеличивает сложность тестируемости кода. Это не значит что его не следует использовать, тут главное не увлекаться. Итак третьего дня нашел интересный инструмент от гугла, который позволяет находить в коде этих самых одиночек, причем не просто Singletone но и также Fingletone-ны,Hingletone-ны,Mingletone-ны.И так в чем же разница между этими зверьми.

Singleton

public class Singleton {
  private static Singleton instance;

  public static Singleton getInstance() {
    if (instance == null) {
      instance = new Singleton();
    }
    return instance;
  }
}

Mingleton

public class Mingleton {
  public static Foo getFoo() {
    return Foo.getDefault(); 
    // or return new Foo();
  }
}

Hingleton

public class Hingleton {
  private static Foo instance;

  public static Foo getInstance() {
    if (instance == null) {
      instance = new Foo();
    }
    return instance;
  }
}

Fingleton

public class Fingleton {
  public static Foo instance;
}

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

Инструмент работает следующим образом указываем ей путь к классу или jar файлу и дополнительные параметры (если нужны), на выходе инструмент генерирует статистику по по _ingletone-нам и Graphml файл.

C:\>java -jar gsd.jar C:\src\hibernate\libs\spring.jar C:\sample.graphml -S

Classes drawn: 70 of 1601
Singletons:    0     Singleton users:    0
Hingletons:    0     Hingleton users:    0
Mingletons:   18     Mingleton users:   27
Fingletons:   15     Fingleton users:   21

Graphml файл проще сконвертировать при помощи этого(у меня не вышло по причини отсутствия Linux) или открыть этим (качать придеться минимум 12 мб и долго тыкать интерфейс, а также сложно прикрутить к интеграционке)получается примерно следующая картинка

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

Отпуск...

Fri, 13 Jun 2008 11:18:05 GMT

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

Мультибраузерные тесты

Tue, 10 Jun 2008 07:29:20 GMT

Уже не раз писал о создании тестов на селениуме, их оптимизации и различного рода хаков. После написания теста на селениуме возникает вопрос - а почему бы его не запустить на другом браузере отличном от того на котором записывал (firefox обычно или руками), запустить, посмотреть несложно,достаточно поменять лишь строку инициализации селениума в скрипте

selenium = new DefaultSelenium("localhost", SeleniumServer.getDefaultPort(), "*chrome", url);

например на InternetExplorer

selenium = new DefaultSelenium("localhost", SeleniumServer.getDefaultPort(), "*iexplorer", url);

или на оперу,сафари,

конкверор, также основанные на вышеперечисленных(например Avant или GreenBrowser) и даже нестандартные (обязательна поддержка javaScript). Например запустить тесты под Netscape можно заменив идентификатор браузера в параметрах на следующий

*custom c:\Program Files\Netscape\Netscape\Netscp.exe

только необходимо помнить, что в используемом браузере должен быть установлен, в качестве прокси, адрес селениум сервера.

Это все конечно удобно и просто - поменял строку запуска и уже тесты запускаются в другом браузере, но остается еще несколько проблем

Чтобы провести тестирование в n браузерах нужно поменять строку запуска n раз и запустить это все вручную

Необходимо наблюдать за процессом тестирования с целью выявления проблем несовместимости теста с браузером и проблем верстки приложения или несовместимости приложения и браузера

Проведение мультибраузерных тестов на одной машине займет очень много времени и ресурсов.

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

<junit haltonfailure="yes" haltonerror="yes" printsummary="yes" maxmemory="512m">
	 <sysproperty key="SELENIUM_SERVER_HOST" value="localhost"/>
	 <sysproperty key="SELENIUM_SERVER_PORT" value="4444"/>
	 <sysproperty key="SELENIUM_BROWSER_STARTCOMMAND" value="*chrome"/>
	<classpath refid="WebTestsclasspath"/>
	<formatter type="brief" usefile="false"/>
	<formatter type="xml"/>
	<batchtest todir="output/test-result">
		<fileset dir="output" includes="**/Test.class"/>
	</batchtest>
</junit>

как видно из скрипта помимо стандартной процедуры запуска JUnit добавились команды для передачи в тестируемый скрипт параметров - sysproperty, скрипт теста изменился следующим образом

 selenium = new DefaultSelenium(System.getProperty(SELENIUM_SERVER_HOST),
        Integer.parseInt(System.getProperty(SELENIUM_SERVER_PORT)),
        System.getProperty(SELENIUM_BROWSER_STARTCOMMAND),
        url);

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

Для решения второй проблемы можно использовать возможности языка Java и интеграционного сервера, итак для базовой сверки отображения верстки в браузере мы,создав класс наследник, перегрузим базовые методы селениума, такие как Click и Type и Open

    public void click(String locator) {
        super.click(locator);
        ScreenShot();
    }

    public void open(String url) {
        super.open(url);
        ScreenShot();
    }

    public void type(String locator, String value) {
        super.type(locator, value);
        ScreenShot();
    }
    
    private void ScreenShot()
     {
	java.text.SimpleDateFormat formatter = new java.text.SimpleDateFormat("yyyy-mm-dd-hh-mm");
	java.util.Date date = new java.util.Date();
	String dd = formatter.format(date);
 	selenium.captureScreenshot(dd + ".png");
     }

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

Третью проблему мы можем разрешить при помощи одного из проектов создателей селениума - Selenium Grid, который позволяет распределенно запускать тесты на различного рода платформах и различных браузерах, при этом процедура запуска нисколько не меняется. Принцип работы с SeleniumGrid следующий - запускается хаб, рапределяющий нагрузку между распределенными серверами, затем запускаются седениум сервера с настройками браузеров, в которых может тестировать данный сервер, подключение клиента осуществляется к хабу, который уже перенаправляет на свободный/подходящий селениум сервер (причем названия браузеров мы можем менять - например FirefoxOnLinux, в скрипте инициализации селениума нужно в качестве браузера указать то же самое).Также при запуске тестов на SeleniumGrid необходимо выставлять у junit параметр forked=true а forkmode=pertest, но это только при условии не связанности тестов! В противном случае возможны race condition. Этот параметр позволяет запускать различные тесты параллельно на нескольких машинах одновременно, что позволяет разгрузить интеграционную машину и ускорить проведение тестов.

В качестве минусов мультибраузерных тестов хочу заметить что не все тесты будут проходить на различных браузерах (например загрузка файлов) но это больше не ограничение селениума а ограничения безопасности по выполнению java script.

Удачного тестирования веб приложений!

Зрелость процесса...

Wed, 04 Jun 2008 11:24:40 GMT

Не так давно начал читать прагматичное тестирование, автор довольно интересно выделил фазы зрелости процесса тестирования и сознания тестера...

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

в данный момент по моему видению переползаем с 3 пункта на 4, правда работы и тренингов ой как много предстоит...

Оценка времени написания тестов

Wed, 21 May 2008 11:36:05 GMT

Очень часто при планировании разработки возникает вопрос - сколько нужно времени, чтобы протестировать тот или иной функционал, немного погуглив нашел несколько способов оценки времени тестирования

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

2 - Экспертная оценка - оценка производиться сторонним экспертом с учетом его опыта (сколько времени ему потребовалось на решение подобных задач) и учетом опыта и профессионализма людей которые будут проводить тестирование

3 - Параметрическая оценка - данный метод больше отонситься к такой метрике как Velocity из терминов XP, использование примерно такое же - например у нас имеется определенный опыт по оценке задач, замеряя среднее значение отношения затраченного времени к запланированному, затем мы проводим планирование и умножаем на полученный параметр.

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

5 - Реверсивный анализ - проводим планирование задачи с учетом разнообразных рисков, например при тестировании того или иного объекта имеется риск, что объект или средство тестирования будет вести себя нестабильно, чтобы избежать таких рисков закладываем дополнительный буфер времени для закрытия таких возможных брешей (в этом отношении мне больше понравился метод критической цепи вплане буферов и оценок)

Обычно на практике используем смешанный метод "оценки на глаз" и закладывание буфера с учетом рисков...

Метрики.Подробности

Wed, 21 May 2008 10:23:06 GMT

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

1) CCN (Cyclomatic Complexity Number)- цикломатическая сложность кода, данная метрика показывает количество возможных условных вариантов выполнения кода или количества различных путей выполнения(прохождения) метода.Формула вычисления сложности выглядит слудующим образом

CC = E - N + P, где E- число ребер графа, N число вершин а P - число связанных компонент

Для кода это число вычисляется так : при встрече каждого условного оператора(if,for,while,case...) прибавляется единица, также единица прибавляется для EntryPoint метода. Например сложность следующего кода равна 3

public int getValue(int param1) {
  int value = 0;
  if (param1 == 0)  {
    value = 4;
  } else {
    value = 0;
  }
  return value;      
}

цикломатическую сложность имеет смысл вычислять только для методов класса так как если например в классе более 30 методов а сложность каждого минимум равна единице, то соответственно суммарная сложность будет 30 и более, что очень много, в данном случае имеет смысл вычислять среднюю сложность класса или проекта а также сложность каждого метода в отдельности.Если говорить о значение, то желательно чтобы оно не превышало 7-10, но это все специфично для каждого проекта и очень сильно зависит от решаемой задачи.Средств для подсчета данной метрики очень много (начиная от взрослых IDE и заканчивая разнообразными мелкими разработками и даже встроенными в язык ).Основной смысл данной метрики это показать программисту ниболее сложные и труднопонимаемые методы классов, которые сложно протестировать, отследить в них ошибку и изменить.Пока писал пост нашел еще одну производную от цикломатической сложности - essential complexity, при ее подсчете используется упрощенные граф кода.

2) Duplicate lines of code - или CPD(copy paste detector) - дублицируемость кода или наличие в коде повторяемых кусков. Данная метрика нужна в первую очередь для улучшения дизайна,архитектуры приложения, так как наличие копипаста очень плохая практика предполагающая большой объем конечного кода, труднопонимаемость и сложность внесения изменений (изменения приходиться вносить во все места копипаста). Данная практика обычно разрешается применением наследования и полиморфизма. Наиболее рапространенное средство измерения этой метрики это Simian.

3)Afferent Coupling, Efferent Coupling, Instability - долго думал как перевести, наиболее близкие понятия оказались в биологии - центростремительная и центробежная связь, и стабильность. Смысл данных метрик заключается в анализе качества дизайна - определяется количество зависящих и зависимых объектов в определенном фокусе (классы или пакеты). Нестабильность определяется по следующей формуле: Instability = Efferent Coupling / (Efferent Coupling + Afferent Coupling) (0 - очень стабильный,1 -максимально нестабильный). Измеряются данные метрики следующими инструментами: Classycle,NDepend,Jdepend.

4)Code Coverage - покрытие кода разнообразными тестами, данная метрика определяет отношение между количеством вызванных тестом строк к общему количеству строк метода/класса/пакета. Также помимо просто построчного покрытия есть поблочное/веточное(branch) - которое учитывает блоки или ветки разделенными условными/циклическими операторами. Средств оценки данной метрик очень много, но все они работают примерно одинаково - сначала в исходный код (или промежуточный язык) добавляются (инструментятся,инжектяться,проксируются) специальные операторы логгирования далее прогоняются необходимые тесты и собирается статистика зафиксированная логгерами. Это один из видов метрик который меняет(в некоторых языках) исходный(промежуточный) код (ну есть еще Mutation testing :) ). Средства оценки - Cobertura,Emma,NCover,RCOV. Обычно данная метрика измеряется в процентах, максимальное значение естественно 100%, но это не означает что ошибок нет, это всего лишь значит, что весь исходный код вызывался из тестов (тесты кстати могут быть даже ручные).

5) Code audit - аудит и проверка кода, данная метрика определяет соответствие написания кода каким либо стандартам и правилам, чаще всего проверяется правильность именования, различные запахи кода (большие классы,методы, дублирование), сложность понимания, возможные ошибки и плохие практики (bad practices). Средства сильно зависят от языка и обычно заточены только под него и под определенные стандарты (обычно это все можно конфигурировать) например FoxCop, FindBugs, PMD, CheckStyle, некоторые из них уже устарели (в связи с устареванием стандартов) но некоторые продолжают быть актуальными использование их очень важно.

6) Statistics-Based Metrics - различные метрики основанные на текстовой статистике например - LOC(Line of Code),NOM(Number of Methods),Line per Method, Line per Class, Method per Class и многие другие ориентированные на статистику базовых кирпичиков языка. Данные метрики позволяют оценить плохие запахи кода (большой класс, большой метод), но практического применения у меня пока не получалось выделить.

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