Автоматизированные решения: повышение эффективности тестирования программного обеспечения

---

Аннотация

Стремительные инновации и жесткая конкуренция, царящие сегодня в мире ИТ, заставляют компании разрабатывать программное обеспечение высочайшего качества с минимальными затратами и в установленные сроки. Это требование возлагает большую ответственность на область тестирования и валидации программного обеспечения. Тестирование программного обеспечения на точность и функциональность обычно является последним рубежом в процессе разработки программного обеспечения (SDLC) перед выпуском нового или модифицированного программного обеспечения конечному пользователю. Проверка того, что программное обеспечение работает в соответствии со спецификациями проекта, требует много времени, труда и средств, а затраты могут составлять 50–75% от общих расходов на разработку. Когда проект отстает от графика, часто в этом виновато тестирование. Существует очевидная потребность в решениях для тестирования, которые сократят необходимое время для обеспечения качества и точности программного обеспечения. В данной статье рассматриваются несколько доступных методов повышения эффективности тестирования и валидации программного обеспечения посредством автоматизации.

Ключевые слова

Программное обеспечение, тестирование, автоматизация, решение, интеграция

---

Введение

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

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

Тестирование и валидация программного обеспечения снижают уровень неопределенности относительно качества вновь разрабатываемого или модифицируемого программного обеспечения. Исследования показали, что профессиональные программисты в среднем имеют шесть дефектов на 1000 строк кода [17]. Тестирование программного обеспечения проводится для подтверждения качества программного обеспечения путем выявления и устранения дефектов в поведении программы, демонстрации наличия всех функций, определенных в спецификациях, и оценки эксплуатационной надежности программного обеспечения перед выпуском конечному пользователю. Тестирование не обеспечивает качество, а скорее помогает выявить недостатки в качестве.

Чтобы сократить время и усилия, необходимые для завершения этапа тестирования, компании все чаще используют автоматизированные методы тестирования. Недавнее исследование, проведенное Microsoft, показало, что для ручного обнаружения и исправления дефектов программного обеспечения требуется около 12 часов программирования [17]. При таком темпе полная отладка программы из 350 000 строк кода может занять более 24 000 часов или 11,4 года, что обойдется в миллионы долларов [17]. Результаты данного исследования иллюстрируют необходимость применения методов эффективного и действенного тестирования программного обеспечения. Автоматизация не только ускоряет процесс тестирования, но и увеличивает объем тестового покрытия, которое можно выполнить за ограниченное время, что приводит к повышению качества программного обеспечения.

Данная статья организована следующим образом. В разделе 2 описывается процесс тестирования программного обеспечения. В разделе 3 обсуждается автоматизация тестирования программного обеспечения и её применение при генерации тестов, модульном тестировании, выполнении и использовании интегрированной среды тестирования. Раздел 4 завершает данную статью.

Тестирование

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

Для успешного тестирования требуется хороший план тестирования, который фокусируется на тестировании новой функциональности в выделенной тестовой среде. Регрессионное тестирование также необходимо, чтобы гарантировать, что новые функции не оказали негативного влияния на ранее существовавший код [19]. План тестирования должен включать как положительные, так и отрицательные сценарии, чтобы продемонстрировать, что программное обеспечение приемлемо реагирует на хорошие или плохие данные. Хорошо спланированный тест пытается доказать, что программное обеспечение работает так, как указано в спецификациях, гарантируя при этом, что программное обеспечение не вызовет проблем при формальной загрузке для использования. Ответственность команды тестирования выходит за рамки попыток «сломать» программное обеспечение. Фактически команда тестирования действует как защитник, заботящийся о благополучии как конечных пользователей программного обеспечения, так и самой компании-разработчика программного обеспечения [7].

Хотя тестирование является очень важным аспектом жизненного цикла разработки системы (SDLC), это также очень дорогой компонент, затраты на который могут составлять 50%–75% от общих затрат на разработку программного обеспечения [7]. Подготовка к тщательному тестированию требований программного обеспечения очень трудоемка и занимает много времени. Тестовые случаи и ожидаемые результаты готовятся для проверки производительности, функциональности и надежности программного обеспечения. Выполнение теста в контролируемой тестовой среде предоставляет данные о фактической производительности программного обеспечения. Эти данные сравниваются с заранее определенными ожидаемыми результатами для проверки программного обеспечения. Разработчики вносят необходимые изменения в код для исправления дефектов, выявленных в процессе тестирования, и программное обеспечение снова тестируется перед выпуском конечного продукта. В идеале тестирование должно продолжаться до тех пор, пока затраты на поиск и исправление дефектов ниже потенциальной стоимости сбоя программного обеспечения после выпуска конечному пользователю [17].

Тестирование часто рассматривается как деятельность, которая не может быть выполнена до тех пор, пока программное обеспечение не будет фундаментально завершено. В действительности, тестирование должно происходить на протяжении всего процесса разработки. Затраты на исправление дефектов быстро растут на протяжении всего цикла разработки. Существует четыре уровня разработки, на которых должно проводиться тестирование. Эти виды деятельности включают в себя модульное, системное, интеграционное и приемочное тестирование [15]. Модульное тестирование изолирует индивидуально завершенные программные модули от остального программного обеспечения и использует подготовленные входные данные для получения результатов, которые можно сравнить с результатами, предсказанными спецификациями. Программист обычно выполняет модульное тестирование. Системное тестирование включает в себя проверку интерфейсов и взаимозависимостей различных подсистем по отдельности, а затем их объединение для тестирования системы в целом, чтобы определить, правильно ли выполняется заданная функциональность [17]. Интеграционное тестирование объединяет все системные компоненты, аппаратное и программное обеспечение, а также взаимодействие с человеком, чтобы гарантировать удовлетворение системных требований в реальных или моделируемых средах. Это этап, на котором происходит большая часть тестирования программного обеспечения для валидации. Валидация программного обеспечения определяется в Глоссарии стандартов IEEE по программной инженерии как процесс оценки системы или компонента в конце процесса разработки для определения их соответствия заданным требованиям [2]. После прохождения валидации программное обеспечение переходит к приёмочному тестированию, проводимому конечными пользователями. Приёмочное тестирование является заключительным этапом тестирования и обычно проводится с использованием бета-версии программного обеспечения.

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

Выпуск некачественного программного обеспечения имеет долгосрочные последствия, которые трудно и дорого обратить вспять. Затраты, связанные с исправлением дефектов программного обеспечения после выпуска, могут быть в 100 раз больше, чем затраты на предотвращение появления того же дефекта [17]. Сопровождение программного обеспечения, которое включает в себя модификацию программного обеспечения после поставки, требует значительной доли организационных ресурсов с расходами до 50%–80% всего ИТ-бюджета корпорации [11]. Также существует риск потери удовлетворенности клиентов, которую трудно восстановить после ее потери. В некоторых отраслях дефектное программное обеспечение может вызвать необратимые проблемы. За последние 15 лет дефекты программного обеспечения сорвали запуск европейского спутника, задержали открытие чрезвычайно дорогого аэропорта в Денвере на год, разрушили миссию НАСА на Марс, погибли четыре морских пехотинца в результате крушения вертолета и остановили системы скорой помощи в Лондоне, что привело к тридцати смертельным случаям [21].

Автоматизация

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

Автоматизированные инструменты — это программные продукты, способные выполнять другое программное обеспечение с помощью тестовых сценариев. Эти инструменты способны выполнять задачи гораздо быстрее, чем люди, без вероятности ошибок, которая присутствует при ручном тестировании. Большее количество тестовых случаев может быть выполнено за меньшее время, увеличивая объем тестирования и покрытие кода. При обнаружении потенциального дефекта тестовый сценарий можно повторить с точно такими же входными данными и последовательностью, чего нельзя гарантировать при ручном тестировании [15]. Повторное использование тестовых сценариев экономит время и помогает обеспечить стабильность программного обеспечения. Время не является фактором при автоматизации и обычно не требует большого вмешательства человека. Используя автоматизацию, тестирование можно проводить 24 часа в сутки, семь дней в неделю. При полном использовании этого потенциала типичный цикл тестирования можно сократить более чем на 75% [15].

Для успешного внедрения автоматизации к ней необходимо подходить так же, как и к другим проектам по разработке программного обеспечения. Инструменты автоматизации хороши ровно настолько, насколько хорош процесс, используемый для их внедрения. Для получения каких-либо преимуществ необходимы первоначальные инвестиции в планирование, обучение и разработку [18]. Цели, задачи и стратегии тестирования должны быть определены до выбора инструмента автоматизации. После согласования методологии тестирования инструменты должны быть оценены на совместимость с типом запланированного тестирования, вычислительной платформой, тестовой средой и функциями продукта. Тестовая система также должна быть оценена на предмет возможности одновременного запуска программного обеспечения и инструмента автоматизации. Процедуры внедрения должны быть документированы, а пользователи должны быть вовлечены в процесс на протяжении всего процесса. Необходимо определить роли и обязанности и установить реалистичные ожидания. Автоматизированное тестирование редко работает идеально с первого раза. Рекомендуется иметь план действий на случай, если автоматизация не даст необходимых результатов.

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

Автоматизированная генерация тестов на основе спецификаций

Автоматизированная генерация тестов на основе спецификаций — относительно новый процесс, используемый для автоматизации создания тестов. Этот метод генерирует тестовые случаи и ожидаемые результаты, используя формальные спецификации программного обеспечения. Тесты генерируются как многокомпонентные артефакты в многошаговом, многоуровневом процессе [1]. Многокомпонентность означает, что тестовый случай фактически состоит из нескольких компонентов: начальных входных значений, входных данных, необходимых для наблюдения эффекта тестового случая, и ожидаемых выходных данных. Многошаговый аспект означает, что тесты генерируются из функциональных спецификаций с помощью пошагового процесса уточнения. Это делается путем уточнения спецификаций в граф, который затем уточняется в тестовые спецификации и, наконец, в готовые к запуску тестовые сценарии. Многоуровневый аспект означает, что тесты генерируются для использования при тестировании программного обеспечения на нескольких уровнях.

Использование автоматизации на основе спецификаций для создания тестов имеет множество преимуществ. Этот метод разработки тестов очень эффективен и исключает человеческий фактор, освобождая ресурсы для планирования и других задач. Поскольку окончательные спецификации доступны до написания программного обеспечения, тесты можно создавать до того, как будет написана первая строка кода. Часто при создании тестов инженер-тестировщик обнаруживает несоответствия и неоднозначности в спецификациях [1]. Выявление проблем в спецификациях до написания кода сокращает количество изменений, необходимых на более поздних этапах разработки. Использование формальных спецификаций для разработки тестов гарантирует, что программное обеспечение тестируется именно так, как оно должно работать. Результаты выполнения этих тестов точно определяют, какой процент требований соответствует программному обеспечению.

Автоматизация во время модульного тестирования

Использование автоматизации во время модульного тестирования позволяет выявлять дефекты на ранних этапах разработки, что позволяет предотвратить превращение небольших ошибок, допущенных программистами, в потенциальные дефекты, способные повлиять на качество программного обеспечения. Модульное тестирование проводится на отдельных модулях кода до интеграции. Выявление и исправление ошибок на этом этапе разработки обходится гораздо дешевле, чем поиск ошибок после интеграции. До 80% ошибок кода можно обнаружить за один проход модульного тестирования. Более 95% ошибок можно обнаружить при использовании нескольких проходов [8]. Инструменты статического анализа используются во время модульного тестирования для анализа кода без его выполнения. Эти инструменты выявляют класс проблем и помечают их для исследования и исправления. Они отлично подходят для обнаружения мертвого кода, бесконечных циклов, элементов данных, которые хранятся, но никогда не используются, и элементов данных, которые используются до инициализации. Статические анализаторы также определяют, какие модули содержат повышенную сложность в коде и требуют дополнительного тестирования. Инструменты покрытия кода также могут использоваться во время модульного тестирования для оценки того, какая часть кода была протестирована набором тестов.

Автоматизация исполнения

Инструменты автоматизации выполнения обеспечивают централизованное выполнение и контроль тестирования, тем самым снижая количество ошибок, присущих человеку. Выполнение — сложная и трудоемкая операция, поскольку включает в себя настройку тестовой среды, выполнение теста, запись результатов, сообщение информации об ошибках и очистку среды после завершения теста [5]. Существует множество инструментов автоматизации выполнения, которые можно настроить под существующие процессы тестирования. Использование этих инструментов для управления процессом тестирования гарантирует его соответствие отраслевым стандартам, таким как ISO или ATLM [20]. Инструменты выполнения поддерживают планирование, управление и анализ работ по тестированию, а также позволяют ссылаться на планы тестирования и спецификации продукта для обеспечения прослеживаемости. Использование автоматизации выполнения значительно улучшает тестирование, предоставляя возможность планировать и запускать тесты без участия оператора, выполнять тесты в локальных и глобальных сетях, поддерживать многоплатформенное тестирование, синхронизацию многопотоковых тестов, а также интегрироваться с инструментами модульного тестирования. Дополнительные преимущества включают возможность отслеживать как автоматизированные, так и ручные тесты, возможность восстановления после ошибок теста и продолжения выполнения, запись результатов тестирования и сравнение их с ожидаемыми результатами, а также оценку общей успешности тестирования [20].

Интегрированная среда тестирования

Будущее автоматизированного тестирования программного обеспечения в крупных компаниях лежит в использовании интегрированной среды тестирования (ITE). ITE представляет собой единый интерфейс, предоставляющий согласованное, унифицированное представление тестовой информации посредством интеграции данных и средств управления с существующими инструментами, используемыми в организации [5]. Эта среда предоставляет группам тестирования по всей компании доступ ко всем тестовым данным и инструментам, как если бы они хранились в одном месте. Тестировщики имеют доступ к унифицированным тестовым данным и инструментам тестирования через графический пользовательский интерфейс (GUI). Существующие тестовые данные доступны для использования несколькими командами. ITE значительно повышает производительность благодаря преимуществам интеграции данных и средств управления, а также устранению избыточной работы, выполняемой группами тестирования.

Компонент интеграции данных управляет содержимым данных и ассоциациями. Этот компонент обеспечивает согласованный способ доступа и управления всеми данными, связанными с тестированием, в организации. Тестировщикам предоставляется единое представление тестовых данных независимо от того, где они хранятся. Эти данные включают в себя тестовые случаи, наборы тестов, записи о дефектах, информацию об истории тестирования и управление конфигурацией тестирования [5]. Тестировщики могут создавать, читать и обновлять тестовые данные. Прослеживаемость обеспечивается за счет автоматической регистрации любых изменений существующих тестовых данных в файле истории для дальнейшего использования. Данные, введенные в ITE, автоматически преобразуются в стандартный формат используемой архитектуры тестирования, и создаются ссылки на необходимые инструменты для выполнения данных [5].

Компонент интеграции данных состоит из трёх уровней: репозитории данных, доступ к ним со стороны сервера и абстракция данных [5]. Существующие тестовые данные хранятся в различных репозиториях, используемых разными группами тестирования. Репозитории связаны между собой и доступны через сервер. Каждому элементу тестовых данных назначается единый идентификатор ресурса (URI), который указывает на фактическое местоположение хранения данных [5]. Возможности абстракции данных используются для создания и управления тестовыми данными, а также для поддержания связей между ними.

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

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

Заключение

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

Ссылки

1. 1. Offutt, J. and S. Liu (1999). Generating Test Data from SOFL Specifications. The Journal of Systems and Software 49:1, 49–62.
2. 2. Institute of Electrical and Electronics Engineers. (1990). IEEE Standard computer dictionary: A compilation of IEEE standard computer glossaries. IEEE, New York.
3. 3. Loveland, S., G. Miller, R. Prewitt, M. Shannon (2002). Testing z/OS: The premier operating system for IBM’s zSeries server. IBM Systems Journal 41:1, 55.
4. 4. Farchi, E., A. Hartman, S.S. Pinter (2002). Using a model-based test generator to test for standard conformance. IBM Systems Journal 41:1, pp. 89.
5. 5. Williams, C., H. Sluiman, D Pincher, M Slavercu (2002). The STCL test tools architecture. IBM Systems Journal 41:1, pp. 74.
6. 6. Dustin, E., J. Rashka, J. Paul (1999). Introduction of an automated test to a project, Methods & Tools, pp. 11–15.
7. 7. B. Hailpern, P. Santhanam (2002). Software debugging, testing and verification, IBM Systems Journal 41:1, pp. 4–12.
8. 8. Rankin, C. (2002). The software testing automation framework, IBM Systems Journal 41:1, pp. 126.
9. 9. Binder, R.V., (1994). Design for testability in object oriented systems, Communications of the ACM 37:9, pp. 87–102.
10. 10. Amman, P., P. Black (1999). Abstracting formal specifications to generate software tests via model checking. National Institute of Scientific Standards.
11. 11. Banker, R.D., G. B. Davis, S. A. Slaughter, Software Development practices, software complexity and software maintenance performance: a field study, Management Science 44 (4) (1998) pp. 433–450.
12. 12. Harter, D. E., M. S. Krishnan, S. A. Slaughter (2000). Effects of Process Maturity on quality, cycle time and effort in software product development, Management Science 46:4, pp 451–466.
13. 13. Austin, R. D. (2001). The effects of time pressure on quality in software development: an agency model. Information Systems Research 12:2, pp 195–207.
14. 14. Buthcer, M., H. Munro, T. Kratchmer (2002). Improving Software via ODC: Three Case Studies. IBM Systems Journal 41:1, pp. 31.
15. 15. Fewster, M., D. Graham (1999). Software Test Automation: Effective Use of Test Execution Tools, ACM Press, New York, NY.
16. 16. Perry, W. (1986). How to Test Software Practices: A Step-By-Step Guide to Assuring They Do What You Want, John Wiley & Sons, New York, NY.
17. 17. Pham, H. (2000), Software Reliability, Springer, Singapore.
18. 18. Hayes, L. (1995). The Automated Testing Handbook, The Software Testing Institute, Dallas, TX.
19. 19. Kaner, C., J. Falk, H.Q. Nguyen (1999). Testing Computer Software, Wiley Computer Publishing, New York, NY.
20. 20. Dunstin, E. (2001). Automated Test Tool Evaluation Matrix, Quality Web Systems, Addison Wesley.
21. 21. Mann, C.C. (2002). Why is software so bad?, Technology Review, July/August.