CITKIT.ru
3 терабайта свободного софта!
Logo    
IT-рынок Новости мира IT Океан(!) софта на CITKIT.ru Форумы Поступления в библиотеку Учебный центр Курилка
CitForum    CITForum на CD Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

16.05.2005

Google
WWW CITForum.ru

Новости мира IT:

  • 11.05 - Intel создает свою группу по Open Source
  • 11.05 - Банк контролирует использование USB устройств при помощи DeviceLock
  • 11.05 - Microsoft устранила опасную дыру в Windows
  • 11.05 - "Корпорация ОСС" создает антимонопольный альянс операторов IP-телефонии
  • 11.05 - В Mac OS X найдены множественные уязвимости
  • 11.05 - "Билайн" запускает услугу "Мобильная почта"
  • 11.05 - Две критические уязвимости в браузере Firefox 1.0.3
  • 11.05 - IBM покупает начинающую Open Source-компанию Gluecode
  • 11.05 - Microsoft готова к битве с Open Source за школы
  • 11.05 - Sun завершит "открытие" Solaris в ближайшие 45 дней
  • 11.05 - Создатели браузера Firefox выпускают юбилейные монеты в честь 50 миллионов скачанных копий
  • 11.05 - Вышла пятая версия мобильной ОС от Microsoft
  • 11.05 - Поисковые движки умнеют быстрее, чем люди
  • 11.05 - Фишеры постоянно совершенствуются
  • 11.05 - Специалисты прогнозируют появление аналога Google Adsense от "Яндекс"
  • 06.05 - ICANN озаботилась проблемой торговых марок
  • 06.05 - Google патентует сортировку новостей
  • 06.05 - Intel готовит двуядерные процессоры второго поколения
  • 06.05 - Schoolforge-UK и OSC продвигают Open Source в школы
  • 06.05 - Новая версия рекламной программы подстрекает пользователей купить ПО для своего лечения
  • 06.05 - Microsoft продает ряд своих закрытых разработок
  • 06.05 - Google Labs анонсировал ускоритель интернета
  • 06.05 - Microsoft подвешивает пиратам "морковку"
  • 06.05 - В США входят в обиход "интеллектуальные" тележки для супермаркетов
  • 06.05 - Microsoft работает над аналогом PDF
  • 05.05 - Yahoo video search теперь доступен массам
  • 05.05 - Алмазы помогут бороться с хакерами
  • 05.05 - Интернет-охоту хотят запретить
  • 05.05 - Microsoft привлекает блоггеров для теста Longhorn
  • 05.05 - Основатель Red Hat предложил Стиву Джобсу помощь в решении проблемы с торговой маркой
  • 05.05 - Компьютерная система оргкомитета Кубка мира по футболу 2006 года пострадала от червя Sober
  • 04.05 - Cisco Systems представила многофункциональный продукт Adaptive Security Appliance 5500
  • 04.05 - Администрация Евросоюза поддержала идею всеевропейской интернет-библиотеки
  • 04.05 - Компьютерный вирус дарит билеты на чемпионат мира по футболу
  • 04.05 - Лаборатория Касперского: Обзор вирусной активности - апрель 2005
  • 04.05 - Microsoft хочет отсудить у россиянина два домена
  • 04.05 - Сделка между Lenovo и IBM завершена
  • 04.05 - Эпидемия червя Sober.p зафиксирована в Западной Европе
  • 04.05 - Panda Software публикует отчет о вирусной активности за апрель
  • 03.05 - Институт SANS обновил список наиболее опасных уязвимостей

    Архив новостей >>>


  • 2003 г

    Автоматизированное тестирование при разработке ПО

    Виктор Ематин, Борис Позин (rational@sibintek.ru), www.sibintek.ru
    Статья опубликована в журнале "Сетевой журнал" №3.2002 www.setevoi.ru

    Аннотация

    Статья рассматривает один из самых важных этапов при разработке сложных программных систем – этап тестирования. Современные средства разработки позволяют быстро построить "каркас" приложения, но насколько это качественно? В статье описываются основные задачи тестирования, виды тестов и критерии тестирования. Приводятся рекомендации по построению процесса тестирования.

    Тестирование - один из важнейших этапов проверки качества разработанного ПО.

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

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

    1. С чего же начинается тестирование? Для его проведения необходимы объект тестирования - в данном случае ПО - и эталон, с которым этот объект сравнивается. ПО -это сложный объект, который меняется по составу и проверяемым свойствам на разных стадиях разработки. Важно понимать, что если разработчик и заказчик не сформулировали требования к ПО еще до начала его разработки, то, во-первых, заказчик вряд ли получит именно то, что хотел, и, во-вторых, ПО, которое он все-таки получит нельзя будет проверить, поскольку объект есть, а эталона нет.

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

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

    2. Неопытный заказчик всегда настроен на то, чтобы дать задание, а потом посмотреть конечный результат. Это самый верный способ получить некачественное ПО. Но низкое качество невыгодно обеим сторонам. Заказчику потому что заказанное им ПО нельзя использовать к тому моменту, когда оно уже нужно, и он теряет время и деньги, поскольку ПО должно работать на его бизнес, а оно не работает (т. е. не приносит денег), да еще и отбирает дополнительные ресурсы на доработку. Разработчику потому, что он теряет авторитет, дорабатывает ПО за свой счет (теряет деньги) и не может быстро переключиться на другого заказчика (теряет заказы). Гораздо эффективнее поэтапно осуществлять контроль над ходом отработки ПО. Именно такой подход приносит наибольший эффект и при разумной позиции заказчика будет наверняка положительно воспринят разработчиком. Для успешного проведения тестирования чрезвычайно важно тщательно спланировать эти работы. Рекомендуется использовать шаблоны документов, в том числе плана тестирования, разработанный в соответствии с требованиями международного стандарта IEEE 829-1983 Standard for Software Test Documentation.

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

    3. И все же, что значит "поэтапное тестирование"? Заметим сразу, что многие заказчики не думают о том, что тестирование стоит денег и вообще затрат ресурсов и что за качество надо платить. Однако, осознав это, заказчик всегда должен понимать, за что именно он платит и как увидеть результаты.

    Принято разделять тестирование по уровням задач и объектов на разных стадиях и этапах разработки ПО (см. таблицу):

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

    Этапы тестирования

     Вид тестирования

     Стадия, этап

     Объект

     Критерий

     Структурное, надежности

     Разработка

     Компоненты

     Покрытие ветвлений, функции

     Сборочное

     Разработка

     Подсистемы

     Функциональность, степень проверки компонентов

     Функциональное

     Разработка

     Система в целом

     Соответствие функциональным требованиям ТЗ

     Регрессионное

     Разработка, сопровождение

     Система в целом

     Проверка качества внесения изменений

     Нагрузочное

     Разработка, сопровождение

     Система в целом

     Оценка статистических характеристик системы, соответствие ТЗ, ТТХ, подбор конфигурации оборудования

      Стрессовое

     Разработка, сопровождение

     Система в целом

     Корректность работы системы при предельных нагрузках

    Когда понятно, что и зачем нужно тестировать, и есть план действий, самое время задуматься о том, как это сделать эффективнее, быстрее и более качественно. Современное ПО -- это сложный объект, и вручную с ним справляться трудно и дорого. К тому же при "ручном" тестировании результаты каждого выполнения тестов пропадают, и их трудно повторить. Для того чтобы увеличить объем проверок и повысить качество тестирования, обеспечить возможность повторного использования тестов при внесении изменений в ПО применяют средства автоматизации тестирования. К их числу относятся средства автоматизации функционального и нагрузочного тестирования клиент-серверных и Web-приложений: Rational TestStudio, Mercury LoadRunner, Segue SilkPerformer, а также менее популярные продукты фирм Compuware, CA, Empirix, RadView Software и др.

    Тестированием надо заниматься не только постоянно, но и систематично. Если не забывать, что это процесс обнаружения ошибок, то стоит потребовать от разработчика, чтобы он периодически силами специально созданных групп проводил так называемые "review", или "структурные просмотры" проектных материалов и аудит исходных кодов программ. Заказчик вправе договориться с разработчиком о предъявлении подобных материалов или о не очень глубоком контроле хода такого процесса. Он заинтересован в том, чтобы в организации разработчика были поставлены процессы. В этом случае заказчик может быть уверен, что качество разрабатываемого ПО контролируется и обеспечивается в ходе разработки. Именно на это направлены известная модель технологической зрелости СММ (Capability Maturity Model, www.sei.cmu.edu/cmmi/orgdocs/conops.html) и стандарт ISO 15504.

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

    Ну а что же между испытаниями, когда ПО еще только создается? И на этом этапе очень важно, чтобы деятельность по тестированию велась планомерно. Хотя тестирование - процесс достаточно творческий, его можно и нужно планировать. Это значит, что на каждом этапе работ должны быть выбраны критерий качества и критерий завершения тестирования. Первый нужен для того, чтобы тестировщик или группа тестировщиков понимали, что и на соответствие чему они проверяют. То есть, каковы объект и эталон и какие свойства объекта проверяются. Второй критерий помогает принять решение в случае, когда исчерпываются ресурсы, отведенные на тестирование, он отвечает на вопрос, при каких условиях тестирование может быть завершено.

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

    План тестирования определяется международным стандартом IEEE 829-1983. В нем должны быть предусмотрены как минимум три раздела содержащие, следующие описания:

    • что будет тестироваться (тестовые требования, тестовые варианты);
    • какими методами и насколько подробно будет тестироваться система;
    • план-график работ и требуемые ресурсы (персонал, техника).

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

    Как подготовиться к тестированию, что именно нужно для его проведения? Как мы уже выяснили, необходимы проверяемые требования, затем каждое из них связывается с одним или несколькими тестовыми требованиями. Далее логический набор тестовых требований группируется в тестовые сценарии, проверка которых позволит дать односложный ответ на вопрос, корректно ли осуществляется ввод, правильно ли работает та или иная бизнес-функция в системе. Этот результат понятен не только специалистам, но и конечному пользователю. Основные объекты автоматизации тестирования - системы, реализующие работу клиентской части. Ключевой особенностью тестирования клиент-серверных систем является возможность проверки корректности функционирования и удовлетворительного быстродействия системы через работу клиентской части. Таким образом, тщательно и всесторонне проверив эти возможности, мы получаем гарантию работоспособности системы для конечного пользователя. Еще один важный аспект организации работ -- хранение созданных тестов. Мы рекомендуем относиться к тестам так же, как и к исходному коду, т. е. нужно использовать версионные хранилища для возможности восстановления тестов предыдущих версий системы (MS SourceSafe, Rational ClearCase,...). Это пригодится на этапе сопровождения ПО и даст возможность повторного использования готовых тестов на нескольких версиях системы. Аналогично нужно относиться и к тестовым данным, создавая архивы, копии и версии содержимого БД.

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

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

    • биллинговые системы;
    • системы массового обслуживания клиентов;
    • CRM-решения;
    • ввод в действие новых ERP-систем для оценки качества их работы в условиях сети и инфраструктуры заказчика в целом;
    • тестирование ПО при его сопровождении и развитии, поставке новых версий и релизов;
    • выбор серверов, на которых работает ПО, и т. п.

    Рекомендуемая литература

    1. Агапов А. С., Зенин С. В., Михайловский Н. Э., Мкртумян А. А. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504-CMM), Пер. с англ. Москва, "Книга и бизнес", 2001.

    2. Мартин Фаулер. Новые методологии программирования. www.maxkir.com/sd/newmethRUS.html.

    3. Rational Unified Process, Rational Software Corp., 1987-2002.

    Copyright © ЗАО "Издательский дом мировой периодики", 2000-2002
    Тел.: (095) 258-55-68

    Сведения об авторах:

    Все авторы работают в дирекции по консалтингу и методологии создания программного обеспечения информационных систем компании ООО ИК СИБИНТЕК, г. Москва.

    Позин Борис Аронович – директор по консалтингу и методологии,
    Ематин Виктор Владимирович – начальник отдела тестирования ПС.

    rational@sibintek.ru
    www.sibintek.ru

    Другие статьи авторов:

    "Автоматизированное создание документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational"


     


    ХАЙВЕЙ - лучший российский хостинг-провайдер: хостинг, регистрация доменов, услуга Ваша@почта, поддержка 24 часа


    NetPromoter - единственный российский профессиональный комплекс программ и сервисов для раскрутки сайта и интернет-статистики


    STSS - известный поставщик надежных серверных решений различного назначения на платформе Intel (Xeon) и AMD.


    5-55: the ITIL company. Практический опыт и теоретические знания на лучших семинарах по ITIL и процессам ITSM.


    Подписка на новости IT-портала CITForum.ru
    (библиотека, ftp-архив CITKIT.ru)

    Новые поступления в on-line библиотеку:

    28 апреля

  • Выбор первого дистрибутива Linux: Пособие для начинающих
  • Обфускация и защита программных продуктов
  • Анализ и оптимизация циклов с помощью производящих функций
  • Стратегии объектно-реляционного отображения: систематизация и анализ на основе паттернов

    26 апреля

  • Business Intelligence обещает значительный рост в 2005 году
  • Десять основных тенденций 2005 года в области Business Intelligence и Хранилищ данных
  • Управление эффективностью бизнеса и предсказуемость
  • Увеличение эффективности бизнеса: пять ошибок управления, которых следует избегать
  • Потребность в организационных данных: модель комплексного управления эффективностью бизнеса
  • Технология Хранилищ данных для государственных учреждений
  • Оцените, насколько совершенно ваше Хранилище данных

    21 апреля

  • Исполнение моделей при помощи виртуальной машины
  • Параллельные алгоритмы компьютерной алгебры
  • От стандарта до стандарта (о стандартизации оптических разъемов)
  • За штурвалом IP-станции

    Продолжение дискуссии читателей:

  • Линукс и пользователи, или что мне не нравится в Linux
  • Еще один взгляд на альтернативные ОС (и софт для них)
  • О некомпетентности пользователя Windows
  • Переписка Долгачева В.С. и Монахова В.В.

    19 апреля

  • Межпротокольный шлюз NAT-PT с функциями DNS-ALG и FTP-ALG для обеспечения взаимодействия между сетями IPv4 и IPv6
  • Рефакторинг архитектуры программного обеспечения: выделение слоев
  • Комбинаторика слов и построение тестовых последовательностей
  • Функциональное тестирование Web-приложений на основе технологии UniTesK

    14 апреля

  • Как организовать двойную парольную защиту данных в Oracle
  • Деревянный интерфейс

    Продолжение дискуссии читателей:

  • Microsoft против мира
  • Впечатления от прочитанного

    12 апреля

  • Крупные проблемы и текущие задачи исследований в области баз данных
  • Глава 2 из книги Т.Кайта "Oracle для профессионалов"Архитектура

    Дискуссия читателей о Linux и Windows:

  • Деньги правят миром, и у кого их больше, тот и прав!
  • О злокозненности некомпетентных пользователей, или почему я не люблю ограниченных пользователей Windows

    7 апреля

  • О доблести Билла Гейтса, или почему Windows лучше, чем LINUX или Mac OS
  • Витая пара - все ли так просто?!
  • Выбираем сервер печати
  • Один слой хорошо, а два - лучше (о пишущих DVD-приводах)

    5 апреля

  • Использование Caché SQL Gateway
  • Глава 19 из книги Т.Кайта "Oracle для профессионалов"Хранимые процедуры на языке Java
  • Что такое PostgreSQL?
  • Обновлен PostgreSQL FAQ

    31 марта

  • Использование Веб-сервисов в Caché
  • Защита на уровне строк (Oracle)
  • Секции в реальном мире

    29 марта

  • Разработка успешных приложений для Oracle - первая глава из книги Тома Кайта "Oracle для профессионалов"
  • Web-сервисы: растущие опасения (мнение аналитиков IDC)
  • Технология OLAP - мощная альтернатива электронным таблицам
  • Какой модной стала подготовка отчетности

    24 марта

  • Многоверсионность данных и управление параллельными транзакциями
  • Исключение из правил. Опыт разработки и внедрения финансовой корпоративной системы
  • Обнаружение компрометаций ядра Linux с помощью gdb
  • Корпоративная сервисная шина - "бюджетный" подход к решению задач интеграции
  • Сервис-ориентированная архитектура
  • Бизнес-процессы и XML

    22 марта

  • Доступно. И точка! (обзор точек беспроводного доступа)
  • Коммутаторы Fast/Gigabit Ethernet для "большой" сети
  • Push to Talk: нажми на кнопку и ...говори
  • Сети нового поколения и технология softswitch

    17 марта

  • Часто задаваемые вопросы о proxy (proxy FAQ)
  • Самонастраивающаяся база данных: управляемые приложения и настройка SQL
  • Еще раз о волоконных трассах
  • Настраиваем русский Unicode в FreeBSD-5.3.

    10 марта

  • Еще не сказанное о волоконной оптике
  • Wi-Fi на службе оператора
  • Пора менять платформу?
    (о сокетах LGA775 и PGA478)

    Oracle:

  • Детальный аудит для практических целей
  • Шифруем свои ресурсы данных

    3 марта

  • Требования к проекту. Классификация - первый шаг к пониманию
  • Gtk vs. Qt: драки не будет
  • Управление бизнесом "по максимуму": BPM для финансовых учреждений
  • Реализация решения по управлению эффективностью бизнеса
  • Новые SerialATA-винчестеры
  • Карман для сервера

    1 марта

  • Выбрать корпус - нет ничего проще?
  • Создание виртуальной сети с удаленной загрузкой узлов
  • Текущее состояние и перспективы развития рынка интеграционных технологий
  • Интеграция корпоративной информации: новое направление
  • Архитектурные подходы к консолидации

    24 февраля

  • Каждому проекту своя методология
  • Императив интеграции
  • Безопасность IP-телефонии - полевые зарисовки
  • О злокозненности Билла Гейтса, или почему я не люблю Windows

    22 февраля

  • Oracle10: шифруем данные
  • В версии Oracle10 "виртуальные частные базы данных" данных стали избирательнее
  • Каждому (пользователю) свое (данное в таблице)
    Часть 1
    Часть 2
  • Ускоряем интернет
  • Сетевая аутентификация на практике
  • В фокусе Microsoft Virtual Server 2005

    17 февраля

    Открыт новый раздел
    Все об Open Source

    Все новости >>>



  • IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы - pr@citforum.ru, тел. +7 095 4119920 Пресс-релизы - manager@citforum.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...