Home

Автор: Статья написана членами коллектива ООО «Системы программной верификации» или в соавторстве с ними.

Оригинальная публикация

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

Автор: Статья написана членами коллектива ООО «Системы программной верификации» или в соавторстве с ними.

Оригинальная публикация

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

Гейзенбаг (англ. Heisenbug) - термин, используемый в программировании для описания программной ошибки, которая исчезает или меняет свои свойства при попытке её обнаружения [2]. Данное название является игрой слов и происходит от физического термина «Принцип неопределённости Гейзенберга», который на бытовом уровне понимается как изменение наблюдаемого объекта в результате самого факта наблюдения, происходящее в квантовой механике. В русской терминологии более часто используется термин «плавающая ошибка». Примером могут являться ошибки, которые проявляются в окончательном варианте программы (“релизе”), однако не видны в режиме отладки, или ошибки синхронизации в многопоточном приложении.

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

Автор: Джон Смарт (John Smart)

Оригинальная публикация: Background Unit Testing: New evolutions in unit testing and IDE integration

Об авторе: Джон Смарт -- ведущий консультант компании Wakaleo Consulting, специализирующейся в области Enterprise Java, Web Development и Open Source technologies. В настоящее время он проживает в Веллингтоне, Новая Зеландия. Джон широко известен в Java-сообществе благодаря многочисленным публикациям, кроме того, он является автором Java Power Tools.

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

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

Автор: Александр Симаков

Оригинальная публикация

Тестирование web-приложений является неотъемлемой частью процесса их разработки. Существуют различные уровни тестирования, вот некоторые из них:

• модульное тестирование;
• интеграционное тестирование;
• системное тестирование;
• приемочное тестирование.

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

В этой статье рассказывается о высокоуровневой методике тестирования web-приложений которую можно использовать как для приемочного так и для системного тестирования. Ключевую роль при этом играет Ruby-библиотека Watir (Web Application Testing In Ruby). Библиотека Watir позволяет запрограммировать действия браузера Internet Explorer на языке Ruby. Таким образом можно автоматизировать значительную часть ручной работы тестеров по заполнению форм, переходу по ссылкам, проверке User-Stories т.д.

Авторы: Сардарян Рубен, Новичков Александр
Материал предоставлен компанией CMconsult

Данная статья посвящена достаточно интересному направлению в индустрии разработки и тестирования программного обеспечения, а именно экстремальному программированию. Про общие идеологические принципы ХР писалось много и очень много, поэтому мы сразу решили не описывать то, что и так уже есть — основу ХР. Данная статья — это практика использования.

 Статья состоит из двух частей:

• Практика использования;
• Экстремальное программирование в IBM Rational Unified Process.

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

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

Перевод: Алексей Лемешко

Источник: Steve McConnell, Construx Software Builders, P.O. Box 6922, Bellevue, WA 98008.
E-mail: Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript — WWW: http://www.construx.com/stevemcc/

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

Автор: Сергей Мартыненко

Статья написана в стиле «Давайте начнем». На простом примере рассматривается модульное тестирование в среде VisualStudio 2005 Team Suite.

Исходная задача: Требуется создать библиотеку для вычисления факториалов.

Для работы нам понадобится VisualStudio 2005 Team Suite. VisualStudio 2005 Express Edition или VisualStudio 2005 Professional не поддерживает модульное тестирование.

Автор: Сергей Мартыненко

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