В предыдущем посте про JMeter я описывал создание примитивного нагрузочного теста. При разработке более сложных сценариев не обойтись без отладки. К сожалению, в JMeter эта техника не совсем очевидна. Ниже на несложном примере покажу несколько приемов отладки тест-плана. Заодно продемонстрирую использование таких элементов, как HTTP Request Defaults, Regular Expression Extractor, If Controller и некоторых других.



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

Disclaimer

Читая книгу по автоматизированному тестированию нашел довольно интересное описание некоторых путей, которые используются для автоматизации процесса. Так как книга написана на английском языке, представляю свой вольный перевод одной части. При прочтении книги очень часто вспоминал свой путь к автоматизации. В данной статье рассматривается то, что нельзя автоматизировать ни в коем случае.

 

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

Почему бы не избежать этих неприятностей, прогнав нагрузочный тест?

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

Под катом рассказываю, как с нуля организовать незамысловатый нагрузочный тест сайта при помощи Apache JMeter.

«Младших тестировщиков производительности» не бывает. Зато бывают люди, которые начинают заниматься тестированием производительности. (с) Скотт Барбер (aka The Perf Guy)

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

18 февраля начнется новый онлайн-тренинг, продолжительностью 6 занятий «Тестирование производительности», автор и ведущий Алексей Баранцев.

Продолжение перевода серии заметок Джеймса Виттейкера под названием «The Future of Testing». Эта серия в оригинале была опубликована в конце 2008 года, и в ней Джеймс сделал ряд предсказаний относительно того, как будет выглядеть работа тестировщиков в будущем, лет через 10-20. Его прогнозы во многом основаны на тех идеях, которые развивались и продолжают развиваться в компании Microsoft, где Джеймс работал в то время.

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

1. «Тестсорсинг»
2. Виртуализация
3. Информация
4. Перемещение тестирования к началу
5. Визуализация
6. Культура тестирования
7. Тестировщики в роли дизайнеров
8. Тестирование после релиза

Совместными усилиями участников Клуба тестировщиков мы сделали перевод серии заметок Джеймса Виттейкера под названием «The Future of Testing». Эта серия в оригинале была опубликована в конце 2008 года, и в ней Джеймс сделал ряд предсказаний относительно того, как будет выглядеть работа тестировщиков в будущем, лет через 10-20. Его прогнозы во многом основаны на тех идеях, которые развивались и продолжают развиваться в компании Microsoft, где Джеймс работал в то время.

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

1. «Тестсорсинг»
2. Виртуализация
3. Информация
4. Перемещение тестирования к началу
5. Визуализация
6. Культура тестирования
7. Тестировщики в роли дизайнеров
8. Тестирование после релиза

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

Итак, перед вами – будущее тестирования.

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

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

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

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

В статье описаны принципы работы движка для тестирования спецификаций и приведены примеры использования. Сам движок прилагается к статье. Можно его считать небольшой библиотекой для интеграционного тестирования.

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

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

Однако начну несколько издалека — с рассказа про огненные сморчки.

Из институтского курса по технологиям программирования я вынес следующую классификацию видов тестирования (критерий — степень изолированности кода). Тестирование бывает:

• Блочное (Unit testing) — тестирование одного модуля в изоляции.
• Интеграционное (Integration Testing) — тестирование группы взаимодействующих модулей.
• Системное (System Testing) — тестирование системы в целом.

Классификация хорошая и понятная. Однако на практике выясняется, что у каждого вида тестирования есть свои особенности. И если их не учитывать, тестирование станивится обременительным и им не занимаются в должной мере. Здесь я собрал подходы к реальному применению различных видов тестирования. А поскольку я пишу на .NET, ссылки будут на соответствующие библиотеки.

В заметке «Можно ли делить на 0,01 ?» на сайте тестировщиков я написал, что при тестировании нужно проверять согласованность валидаторов входных данных с логикой обработки этих данных приложением. Но из комментариев к этой заметке я понял, что для понимания того, как надо тестировать валидацию данных, надо понимать, как она должна работать, что можно считать правильным, а что нет. Поэтому я написал об этом отдельную статью. В ней рассматривается три вопроса: 1) зачем вообще нужна валидация данных, и 2) где и когда может выполняться валидация данных, 3) какие бывают разновидности проверок. Ну и конечно продемонстрировано, как всё это выглядит на живых примерах. А может быть мои рассуждения окажутся интересны не только тестировщикам, но и разработчикам.

 

Совсем недавно в ходе разработки одного проекта передо мной встала задача поиска удобного средства для написания юнит-тестов на C++. К каким результатам привело моё исследование подробнее в этой статье.

По случаю дня тестировщика, а также в преддверии шестой конференции специалистов по тестированию и обеспечению качества а также конференции Test Labs в Киеве, публикую полный список имеющихся в наличии материалов выступлений предыдущей пятой конференции, которая состоялась 23-24 апреля 2009 г. в Санкт-Петербурге.

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

QuickTest Professional – популярный инструмент для автоматизации функционального тестирования. В немалой степени его популярность обусловлена наличием в нем рекордера пользовательской активности, который позволяет записать действия пользователя и преобразовать их в скрипт.
Объекты, с которыми взаимодействует пользователь, автоматически идентифицируются QTP и сохраняются в специальное хранилище – репозиторий. При сохранении в репозиторий, QTP автоматически сохраняет идентификационные свойства объекта, но делает это не всегда правильно. Например, если на веб-странице присутствуют несколько таблиц (даже если у каждой из них есть свой ID), QTP идентифицирует их по порядковым номерам. Такой способ идентификации объектов вызывает проблемы при проигрывании автотестов. Более того, многие объекты вообще не попадают в репозиторий при записи. Это вызвано многими причинами, наиболее частыми из которых является сложная верстка или верстка с применением DIV-ов. Однако, существует способ обращаться к объектам тестируемого приложения на этапе выполнения скрипта, минуя обращение к репозиторию.
Этот способ называется Descriptive Programming (DP).

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

Этот перевод является продолжением серии статей про тестирование:

• Настройка IDE для автоматического запуска тестов
• Категории программных тестов

На очереди практические советы по построению тестопригодного кода и примеры применения изложенных знаний на реальных проектах.
P. S. Отдельное спасибо taxigy за корректуру русского перевода.


Я думаю, что баги можно разделить на три базовые категории:

1. Логические. Логические баги наиболее популярны и часто встречающиеся. Это ваши if'ы, циклы и другая подобная логика в коде. (Мысли: это работает неверно).
2. Баги взаимодействия. Баг взаимодействия — когда два разных объекта неправильно взаимодействуют между собой. Например, выход одного объекта является не тем, что ожидает следующий объект в цепочке. (Мысли: данные к месту назначения пришли испорченными).
3. Баги отображения. Баг отображения — когда вывод (обычно некоторый пользовательский интерфейс, UI) отображается некорректно. Ключевой момент — в том, что это человек определяет, что есть правильно, а что — нет. (Мысли: это «выглядит» неправильно)