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

Рассуждать хочу долго и о ситах.

Си́то — устройство для разделения сыпучих масс по величине их составляющих (зёрен, круп, песка и т.п.).

Сперва послушаем историков:

Человеческие жертвоприношения из ряда тестировщиков до и после релиза были распространённым явлением у менеджеров проектов, живших на полуострове Юкатан до нашествия конкистадоров. Тестировщиков приносили в жертву через повешение, утопление, отравление, избивание, а также посредством захоронения заживо в груде документации по проекту.

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

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

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

Итак, утопление.

В начале ХХ века в центральной Америке было модно заниматься археологическими раскопками в «подземных» озерах. Для тех, кто в эти озера когда-то нырял, это довольно мрачное место. А для археолога ХХ века подобное озеро - кладезь информации. На дне, в многовековых наслоениях грязи, лежат никем не разворованные украшения, кости, черепа и прочие интересные археологические штучки.

Как все это добро достать?

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

А водолаз без движения уподобляется тем, кто уже никогда не выныривал из этого озера.

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

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

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

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

Сделаем музыкальную паузу.

Тестирование в Agile-way особенно сильно тем, что всё, что можно автоматизировать, автоматизируется до и во время разработки, а не отдельно от неё.

Каждое "сито" в девелопменте имеет свое имя.

1. Test Driven Development — сито мелкоячеистое.
2. Acceptance Test Driven Development — сито среднеячеистое.
3. Functional Testing — сито крупноячеистое.

Первые два сита — епархия программистов. Сам я существенно разбираюсь только в третьей теме.

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

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

Например, понятие сита — уже абстракция.

Абстрактность тут нужна потому, что большинству людей понятие TDD поначалу не «поддаётся», и неимоверно трудным оказывается процесс понимания всего этого. Но когда во все врубился и вгрыззся, становится странным, что до сих пор все это не использовал...

Unit testing

Внятный пример - LoveUT.

Цитата из статьи:

Тихо мурлыкая под нос, Анна продолжает кодировать свой класс.

Суть «разработки через тестирование» проста:

• Сначала программист пишет тест для проверки функциональности, которую собирается написать. Этот тест называется «unit-test», потому, что он проверяет только одну единицу функционала.
• Затем программист пишет функциональность.
• И постоянно проверяет ее посредством ранее написанного, специально для нее, теста.
• Как только функционал удовлетворяет требованиям этого теста, разработка функции считается завершенной. Переходим к следующей.
• Во время разработки других функций, которые связаны с уже существующей, программисту можно и следует запускать юнит-тесты чаще, чем его легкие всасывают в себя один литр воздуха. Если все «горит зеленым» — программист счастлив. Если красное — увы.

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

Особенности юнит-тестов:

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

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

Acceptance testing

Внятное описание на английском языке: wikipedia.org.

Акксептанс-тесты — второй шаг после юнит-тестов. Это уже существенный уровень абстрактности от кода.

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

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

Особенности акксептанс-тестов:

• Неподготовленный человек вполне может их читать и понимать, не видя код.
• Уровень абстракции в юнит-тестировании неимоверно большой. Тесты обрабатывают не определенный код, а определенные абстракции, которые должны быть воплощены в коде.
• Функция меняется как угодно. Акксептанс-тесты для нее не меняются.

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

Парадкос в том, что подобные проверки хоть и абстрактны, но изрядно привязаны к существующему коду. Ведь абстракции проверяются работающим кодом, не так ли?

Для сочувствующих agile development уточняем: акксептанс-тесты проверяют юзер-сториз. А юзер-сториз - вне кода, вне технологий. Получается, что у нас есть high level tests, которые запускаются нажатиями кнопок.

Пример, пример!

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

В примере проверялась такая юзер-стори:

«User want to perform money operation from my account to another one to pay/receive money to/from another User»

посредством следующего приемочного критерия:

«After money operation one of the accounts is increased and another is decreased by the same amount of money».

Критерии акксептанс-тестов задают (а в идеальном мире — пишут) заказчики софта, а не разработчики. Например, пресловутый заказчик просит* следующего:

• в базе должны существовать аккаунты разных юзеров.
• у каждого юзера на счету есть какие-то деньги.
• после нажатия кнопки «Сделать офигенно», со счета юзера №1 на счет юзера №2 должны передаваться какие-то суммы.

* имхо, неимоверно удачно выбранный глагол.

Как выглядит такой тест, написанный в wiki-разметке в фреймворке «FitNesse»

Как эта таблица выглядит в формате wiki:

Make sure that there are no accounts in the bank.

!|ensure|clean accounts|

Create two different accounts.

!|create account for user|Bob|with amount|5|

!|create account for user|John|with amount|7|

и тд

Как это выглядит после прогона теста:

Как и почему это работает — не уточним, чтобы не переходить в детали и не разрушать сказки и абстракции.

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

Предварительное резюме

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

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

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

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

Functional testing

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

Тут мы руками или головой проверяем, что будет, если мимо муравейника проедет танк, и кто победит, если муравьи нападут на танк. Ставлю сто баксов на муравьев...

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

Тут мы узнаем, что бывает, если муравьев в системе слишком много или слишком мало.

Это можно делать как всеми органами осязания, воззрения и осмысления, так и заранее документируя свои действия (тест-кейсы).

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

Окончательное резюме

Если

1. проект только начинается
2. разработка ведется в стиле on-going (неизвестны ни конечный результат, ни дата полного финала)
3. код пишется «с нуля»
4. заказчик умеет работать в agile-стиле
5. разработчики умеют работать в agile-стиле
6. инженеры «болеют» тестированием
7. все три сита постоянно применяются в процессе разработки

тогда

1. проект вполне может завершиться выпуском идеального продукта
2. все риски, которые влечет неполное тестирование, могут быть предупреждены и преодолены
3. скорость разработки возрастает в неимоверные разы
4. каждый гребёт свою кучу денег и убегает домой пить пиво и смотреть футбол с любимой женой.

Выводы: это ж совсем не то, что мне до сих пор понималось! :(

Еще не совсем ясно, как это будет касаться меня впредь. Подобные прогоны подобных тестов - это мир ХР. Это сила, но она касается именно момента "владения кодом":

1. овладел кодом,
2. сделал в нем изменение,
3. прогнал тесты,
4. увидел "зеленое" - с довольной рожей продолжил править код;
5. а если увидел "красное" - быстро поправил код, прогнал все заново, и с довольной рожей продолжил кодировать свои абстрактные абстракции в нечто более осязаемое, но тоже абстрактное.

Школа "функционального" тестирования гласит о следующем:

1. исследовал софтину,
2. прогнал тесты,
3. увидел "красное" - сообщил программисту. Что и как он будет дальше делать - он не скажет.

То есть, вообще другим воздухом дышим.

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

Или не дам.

ЗЫ Fitnesse (wiki-надстройка над Framework for Integrated Tests) - это вещь...

Бонус №1: рассуждения Алименкова на тему ATDD:

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

Команда становится более целостной без постоянного взаимодействия с тестировщиками...

Бонус №2: презентация Дмитрия Лобасева "Разработка через приемочное тестирование с FIT". Материалы с выступления на SQA2008".

]]> http://testitquickly.wordpress.com/2008/06/12/load-runner-vs-the-grinder-vs-apache-jmeter/ Thu, 12 Jun 2008 20:26:47 +0000 Алексей Лупан http://testitquickly.com/2008/06/12/load-runner-vs-the-grinder-vs-apache-jmeter/ Достаточно толковое сравнение между Load Runner vs The Grinder vs JMeter.

CONCLUSION

I selected The Grinder due to several make-or-break issues.

However, each tool has unique strengths and weaknesses. Which tool is ultimately best for you depends on a number of things.

Both of the open source projects have merits, but neither one is ideal. My approach will be to work with the Grinder development team to resolve the most serious offenders.

Вчера лег спать в полпятого утра. Ночь ушла на возню с JAVA, без настройки которой Grinder не работает. Добился внятного сообщения о том, что "Failed to load Main-Class manifest attribute" из файла, в котором эти самые атрибуты должны читаться, а почему так - не понятно.

Отложил.

Не готов я учить JAVA только для того, чтобы запустить "для рассмотрения" Grinder.

Придётся теребить ближайшего разработчика.

Public Sub Add_Connector()

Set vsoShape = Application.ActiveWindow.Selection.Item(1)
vsoShape.AddRow visSectionConnectionPts, 7, visCnnctX
vsoShape.CellsSRC(visSectionConnectionPts, 7, visCnnctY).FormulaU = "Height*0"
vsoShape.CellsSRC(visSectionConnectionPts, 7, visCnnctX).FormulaU = "Width*0.5"

vsoShape.AddRow visSectionConnectionPts, 8, visCnnctX
vsoShape.CellsSRC(visSectionConnectionPts, 8, visCnnctY).FormulaU = "Height*1"
vsoShape.CellsSRC(visSectionConnectionPts, 8, visCnnctX).FormulaU = "Width*0.5"

End Sub

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

- Используешь OpenOffice Calc для перевода юз-кейсов на язык тест-кейсов, и мечтаешь автоматизировать это?

- Но как это сделать, ведь это невозможно!

- Теперь это возможно с новым макросом, который поможет любому, кто использует OpenOffice Calc для перевода юз-кейсов на язык тест-кейсов, и мечтает автоматизировать это!

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

В итоге на листе Calc появляется уже готовое нечто:

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

Макрос предрасположен в первом комментарии. Лицензия фрибээсдэшная. Ю ар фри ту бээсдэ тхиз код аз ю уищ.

Мы знаем, как вставить макрос в Calc.

Мы знаем, как назначить макросу сочетание клавиш.

Все это знают.

Если делать так, то за два часа до завершения у нас уже будут КАКИЕ-ТО результаты тестирования. А все вопросы будут заданы тимлидеру ВСЕ СРАЗУ. Он отметит все то, что не особо важное, и ответит на все, что важно.

Недостаток тут может быть только в human resource - если в четыре часа будет недоступен тот, кто может прояснить темные места скрипта. Но это редкий форс-мажор.

Еще на собственном опыте разодыбл жизненно важную информацию для всех уверенных в том, что на установку платформы и всех прибамбасов нужно тратить не более часа: "чистая" Windows Vista ставится в течение 1 часа 40 минут на 512 Мб (или в течение 1 часа 20 минут на 1 Гб).

Еще 30-40 минут уходит на конфигурацию системы (доменные политики, установка прав пользователя). Почему так долго? А спросите разработчиков Vista, почему процедура Log on и Log off в доменном имени занимает не менее шести-семи минут? А почему сохранение измененных настроек домена занимает не менее шести-семи минут? Итого 2 часа 10 минут из восьмичасового рабочего дня (исполнение скриптов, разумеется, рассчитано на восемь часов, а не на шесть). Теперь начинаем ставить все офисы и программы, которые нужно тестировать. Если на их установку уходит менее часа - поздравления.

Вчера в процессе установки Vista "встала" криво, и не разрешала устанавливать какой бы то ни было Office или Non-Office. О своей "кривости" Vista ничего не сообщила, и через 3 часа 20 минут было принято решение установить нужную платформу на другом компьютере. Кто же знал, что для Vista такой долгий процесс установки - норма...

Закуска: Приснилось забавное восклицание: Дурак! Это не описание бага! Это requirements!

Скачать (6,5 мб)

Удивительно эффективно.
Главное - не включать в список пустые ячейки.