 Автор: Александр Симаков
Оригинальная публикация
Тестирование web-приложений является неотъемлемой частью процесса их разработки. Существуют различные уровни тестирования, вот некоторые из них:
- модульное тестирование;
- интеграционное тестирование;
- системное тестирование;
- приемочное тестирование.
В рамках модульного тестирования проверяются минимально возможные компоненты, например, отдельные классы или функции. Интеграционное тестирование предназначено для проверки связи между компонентами. Задачей системного тестирования является проверка как функциональных, так и не функциональных требований к системе в целом. Приемочное тестирование проверяет поведение системы на предмет удовлетворения требований заказчика.
В этой статье рассказывается о высокоуровневой методике тестирования web-приложений которую можно использовать как для приемочного так и для системного тестирования. Ключевую роль при этом играет Ruby-библиотека Watir (Web Application Testing In Ruby). Библиотека Watir позволяет запрограммировать действия браузера Internet Explorer на языке Ruby. Таким образом можно автоматизировать значительную часть ручной работы тестеров по заполнению форм, переходу по ссылкам, проверке User-Stories т.д.
Авторы: Сардарян Рубен, Новичков Александр
Материал предоставлен компанией CMconsult
Данная статья посвящена достаточно интересному направлению в индустрии разработки и тестирования программного обеспечения, а именно экстремальному программированию. Про общие идеологические принципы ХР писалось много и очень много, поэтому мы сразу решили не описывать то, что и так уже есть — основу ХР. Данная статья — это практика использования.
Статья состоит из двух частей:
- Практика использования;
- Экстремальное программирование в IBM Rational Unified Process.
Автор: Дмитрий Юшкевич
В основу этой методики лег тот факт, что все развитые промышленные СУБД имеют то или иное средство профилирования своих процедур. Его основное предназначение — оценка производительности написанного кода (функции, процедуры и т.д.). Но есть и приятная второстепенная особенность: обычно это средство (в Oracle — пакет dbms_ profiler) имеет возможность получать статистику по номерам выполненных строк кода.
Автор: Сергей Мартыненко
Статья написана в стиле «Давайте начнем». На простом примере рассматривается модульное тестирование в среде VisualStudio 2005 Team Suite.
Исходная задача: Требуется создать библиотеку для вычисления факториалов.
Для работы нам понадобится VisualStudio 2005 Team Suite. VisualStudio 2005 Express Edition или VisualStudio 2005 Professional не поддерживает модульное тестирование.
Автор: Ларри Квесада, специалист по Rational, IBM
Источник публикации
Excel-плагин для TestManager — это набор макросов, включенных в Microsoft Excel, который расширяет функциональность IBM Rational TestManager. Практики в области тестирования могут использовать плагин вместе с TestManager на всем продолжении цикла тестирования для облегчения разработки набора тестовых данных, его импорта в TestManager, а также передачи отчётов. Менеджеры по обеспечению качества могут использовать плагин для получения доступа к статусу тестовой программы, не запуская её саму. В конце концов, как только отчёты созданы в Excel, можно использовать любую функцию Excel, например, копирование и вставку из книги Excel в документ Word, создание графиков и диаграмм, сводных таблиц, функций, создание версий для печати и т.д.
Автор: Scott Sehlhorst
Оригинал: Test Smarter, Not Harder
Перевод: Дмитрий Дудников по заказу Software-Testing.Ru
Эта статья о комбинаторных методах построения тестов первоначально была написана для developer.* в марте 2006 года. Недавняя статья на Dailytech обращает внимание на одно очень интересное исследование о новых методах генерации многомерных комбинаций (четверок и более), выполненное Лабораторией информационных технологий Национального института стандартов и технологий США (NIST, the National Institute of Standards and Technology). Данная переработанная и дополненная версия статьи учитывает эти результаты.
Введение
В первой части исследуется проблема обеспечения хорошего покрытия тестами входных данных сложного программного обеспечения. Во второй части обсуждаются подходы к решению этой проблемы (включая выявленные в исследовании NIST). В третьей части анализируются подходы к улучшению «лучшего» решения, описанного во второй части.
Мы поговорим о способах снижения цены, которую приходится платить за обеспечение высокого качества тестирования. Более конкретно, мы обсудим техники, удешевляющие создание и поддержку набора регрессионных тестов.
Мы начнем с обсуждения проблемы, а затем обсудим подходы к построению тестов, дающие все большую эффективность по более низкой цене. Надеемся, что вам понравится статья и будем рады услышать от вас отзывы и дополнения.
 Автор: Андрей Козлов
Часто приходится видеть, как подчас даже опытные тестировщики спотыкаются на известных граблях – на составлении тест-планов. Хочу рассказать о модели ведения тест-планов, основанной на сценариях использования.
Про необходимость тест-планов писать не буду, скажу лишь, что тест-план – и это не преувеличение – является основным инструментом в работе тестировщика. Он может вестись на бумаге, в голове, в текстовом файле или в баг-трекере, но он должен быть. Хотя бы для того, чтобы сказать потом начальству, что было проверено, а что нет. На моей памяти тестирование не одного проекта было сорвано из-за отсутствия тест-планов или неудобства работы с ними.
Я предлагаю модель, которая помогает существенно снизить риски неадекватного планирования. Суть её сводится к выделению сценариев использования приложения и наполнению их конкретными данными.
Автор: Семенкин Максим
Оригинальная публикация
В последнее время пришлось довольно активно изучать вопрос функционального тестирования, поэтому довелось разобраться с инструментарием, который может быть пригоден для тестирования веб-приложений. Поскольку разработку ведем на Java, то и инструментарий подбирался соответствующий. Надеюсь, мой опыт будет полезен другим.
 Автор: Мартыненко Сергей
Оригинальная публикация: Часть 1, Часть 2.
Часть первая, рациональная
Эта часть статьи написана по мотивам доклада на первой конференции русскоязычного комьюнити тестировщиков 21 апреля 2007.
Под автоматизированным тестированием в этой статье понимается только и исключительно функциональное тестирование через GUI при помощи одного из инструментов: Rational Robot, QTP, TestComplete (священная корова, примерно соответствующая Oracle у DBA). Сделано это для того, чтобы не писать во всей статье оговорки.
Выбор регрессионных автоматических тестов
Для предотвращения «расползания» кода и раннего обнаружения ошибок широко применяется практика ежедневного тестирования в автоматическом режиме.
В мировой практике наиболее распространены следующие виды тестов:
 Автор: Евгений Россинский
Оригинальная публикация: http://blog.netstream.ru/2009/03/squis/
При разработке мы стараемся покрывать наш код не только матом, но и unit тестами. Однако все покрыть тестами не всегда получается. К тому же, остается GUI, для которого написание тестов довольно трудоемкая работа. При всех этих проблемах неизменным остается требование, что каждый следующий камит в репозиторий не должен портить уже существующий функционал.
В этой статье я хочу рассказать какой инструментарий мы используем для тестирования наших desktop приложений, написанных на Qt.
Пол года назад в ходе исследования инструментов для тестирования GUI в поле моего зрения попал продукт Squish компании froglogic. Из плюсов данного решения можно отметить следующие:
- тесная дружба Squish c классами Qt (в том числе и itemы в QGraphiscScene);
- кроссплатформенность;
- поддержка скриптовых языков (Javascript, Python);
- автоматизированная генерация текста теста;
- удобная система запуска тестов из консоли.
На другую чашу весов легла стоимость лицензии 93 000 руб. (это по августовскому курсу 2650 евро).
Поскольку из конкурентов подобных вкусностей за такие деньги никто не предлагал, а аналогичных бесплатных решений я не нашел, скрепя сердце я купил лицензию.
|
