Экономическая эффективность внедрения технологии автоматизированного тестирования

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РЕСПУБЛИКИ БЕЛАРУСЬ

УО «БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ»

Кафедра прикладной математики и экономической кибернетики

Специальность «Экономическая кибернетика»

ДИПЛОМНАЯ РАБОТА

на тему: Экономическая эффективность внедрения технологии автоматизированного тестирования



Реферат

Дипломная работа: 60 с., 23 рис., 5 табл., 30 источников, 1 прил.

ТЕСТИРОВАНИЕ, ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ, АВТОМАТИЗАЦИЯ, СТАНДАРТЫ КАЧЕСТВА, ИНФОРМАЦИОННЫЕ СИСТЕМЫ, ДЕФЕКТ, КАЧЕСТВО, УПРАВЛЕНИЕ ТЕСТИРОВАНИЕМ, ПРОЕКТ, ФРЕЙМВОРК, ЭФФЕКТИВНОСТЬ

Объект исследования - эффективность внедрения технологии автоматизированного тестирования.

Предмет исследования - методы, модели и инструменты анализа и оценки экономической эффективности автоматизированного тестирования.

Цель работы: обоснование экономической эффективности внедрения автоматизированного тестирования программного обеспечения на примере проекта компании.

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

Методы исследования: анализа и синтеза, обобщения и аналогии, экономико-математическое моделирование.

Исследования и разработки: проведено исследование теоретических основ процесса тестирования программного обеспечения, направлений и автоматизированного тестирования, обоснована экономическая эффективность его применения.

Экономическая значимость: разработка специальной библиотеки тестов является экономически целесообразным как для заказчика, так и для разработчика.

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



Abstract

Diploma thesis: 60 pages, 23 figures, 5 tables, 30 sources, 1 appendix

TESTING, SOFTWARE, AUTOMATION, STANDARTS OF QUALITY, INFORMATION SYSTEMS, DEFECT, QUALITY, TESTING MAINTENANCE, FRAMEWORK, EFFICIENCY

Object of research - efficiency of test automation technology implementation.

Subject of research - methods, models and tools for analysis and estimation of economic efficiency of test automation.

Objective of the work: to prove economic efficiency of the implementation of test automation on the example of the company's project.

Relevance: in recent years, Automated Testing has gained popularity in Software development thanks to the convenience. However, implementation and support of automated tests is a very resource-intensive, respectively, expensive procedure. Justification of economic efficiency of Test Automation implementation is an actual task.

Methods: analysis and synthesis, aggregation and analogy, economic-mathematical modeling.

Research and development: research of theoretical bases of software testing process, the directions and the automated testing was conducted, economic efficiency of its implementation was proved.

Economic significance: development of special library of tests is economically expedient both for the customer, and for the developer.

The author confirms that contained settlement and analytical material correctly and objectively reflects the state of the process under investigation, and all borrowed from literature and other sources theoretical and methodological terms and concepts are accompanied by references to their authors.



Введение

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

Целями данной дипломной работы соответственно стал анализ эффективности внедрения технологии автоматизированного тестирования в процесс разработки программного продукта.

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

В данной работе представлена информация об организации процесса тестирования с применением технологии автоматизированного тестирования. Был выбран инструмент для автоматизации, т.е. тот коммерческий продукт, который будет использоваться для создания тестов. В качестве такого средства был выбран программный продукт Smartbear TestComplete, в котором будут храниться автоматизированные тесты, и которое будет формировать отчёты о результатах запусков тестов. Тестовые данные будут храниться в виде текстовых файлов с расширением.xml. Для контроля над изменениями в коде тестов и тестовых данных будет использоваться система контроля версий, Team Foundation Server TFS, являющаяся одним из модулей интегрированной среды разработки Visual Studio.

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

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

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

Процесс разработки программного обеспечения рассматривался в рамках предприятия.



1. Основы автоматизации тестирования коммерческих программных продуктов

1.1 Теоретические основы тестирования программных продуктов

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

Тестирование - техническая операция, которая заключается в определении одной или нескольких характеристик данного продукта, процесса или услуги по соответствующей процедуре. [3]

Тестированию подвергаются следующие основные элементы:

- программы при их запуске и исполнении;

- программный код (без запуска и исполнения);

- прототип программного продукта;

- проектная документация;

- требования к программному продукту;

- функциональные спецификации к программному продукту;

- архитектура и дизайн;

- план проекта и тестовый план;

- тестовые сценарии;

- сопроводительная документация (и документация для пользователей);

- интерактивная помощь;

- руководство по установке и использованию программного продукта.

Условно, в зависимости от целей, тестирование разделяется на следующие группы:

- функциональное;

- нефункциональное;

- тестирование, связанное с изменениями.

Функциональное тестирование - процесс проверки программного обеспечения, сконцентрированный на анализе соответствия требованиям и спецификациям. Целями такого тестирования является обнаружить ошибки в программном продукте.

Существуют следующие уровни функционального тестирования:

- приёмочный тест - самый первый и быстрый уровень, если тесты этого уровня не проходят, тестирование прекращается;

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

- расширенный тест - полная проверка приложения на соответствие всем требованиям.

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

- все виды тестирования производительности:

- нагрузочное тестирование;

- стрессовое тестирование;

- тестирование стабильности или надежности;

- тестирование установки;

- тестирование удобства пользования;

- тестирование на отказ и восстановление;

- конфигурационное тестирование.

Тестирование производительности означает определение масштабируемости приложения под нагрузкой, т.е. анализ поведения приложение при изменениях нагрузок:

- измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций;

- определение количества пользователей, одновременно работающих с приложением;

- определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций);

- исследование производительности на высоких, предельных, стрессовых нагрузках.

Нагрузочное тестирование имитирует работу определенного количества бизнес пользователей, на каком-либо общем, разделяемом ими, ресурсе.

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

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

Тестирование установки направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения. [1]

Тестирование удобства пользования - это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [2]

Тестирование на отказ и восстановление - проверка того, насколько продукт способен противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).

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

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

- дымовое тестирование (smoke testing);

- регрессионное тестирование (regression testing);

- тестирование сборки;

- санитарное тестирование, проверка исправности (sanity testing). [1]

Дымовое тестирование (приёмочное) - выполнение небольшого по объёму тестового набора, для подтверждения работоспособности приложения после сборки кода. Проверяются наиболее важные модули приложения и от результатов проведения такого тестирования, зависит, будет ли дальше проверяться приложение или оно будет направлена разработчикам на повторное исправление.

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

Существует следующие основные типы регрессионного тестирования:

- регрессия ошибок - проверка того, что исправленная ошибка на самом деле не исправлена;

- регрессия старых ошибок - проверка того, что последнее изменение кода программы или данных привело к возникновению старых ошибок, т.е. старые ошибки стали снова воспроизводиться;

- регрессия побочного эффекта - проверка того, что последнее изменение кода программы или данных привело к неработоспособности других частей разрабатываемого приложения;

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

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

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

- компонентное или модульное тестирование;

- интеграционное тестирование;

- системное тестирование.

Компонентное тестирование - тестирование отдельного модуля программного средства (под модулем может пониматься отдельный класс, метод и т.д.)

Интеграционное тестирование - проверка того, как отдельные компоненты, проверенные на предыдущем уровне, взаимодействуют друг с другом.

Системное тестирование - полная проверка приложения: проверяются как функциональные, так и нефункциональные требования.

Также выделяются следующие направления тестирования:

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

- динамическое тестирование - такое тестирование подразумевает эксплуатацию (запуск) программного продукта. [1]

Существует разделение тестирования по степени автоматизации:

- ручное тестирование;

- автоматизированное.

Ручное тестирование направлено на поиск ошибок в системе, используя составленный план тестирования, специалист по тестированию проверяет систему вручную, как если бы он был пользователем.

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

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

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

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

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

Преимущества автоматизации тестирования:

- повторяемость - все написанные тесты всегда будут выполняться однообразно, т. е. исключен «человеческий фактор»;

- быстрое выполнение - автоматизированному скрипту не нужно сверяться с инструкциями и документациями, и вследствие этого снижаются временные затраты на выполнение теста;

- меньшие затраты на поддержку - когда автоматические скрипты уже написаны, на их поддержку и анализ результатов требуется, как правило, меньшее время чем на проведение того же объема тестирования вручную;

- отчеты - автоматически рассылаемые и сохраняемые отчеты о результатах тестирования;

- выполнение без вмешательства - во время выполнения тестов сотрудник может выполнять другую работу либо выполнение тестов происходит в нерабочее время, что является предпочтительным, поскольку в этот промежуток времени снижена нагрузка на локальные сети;

Недостатки автоматизации тестирования:

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

- затраты на поддержку - если в приложение часто вносятся изменения, то соответственно понадобятся частые изменения в тестовых скриптах, что может увеличивать затраты на содержание автоматических тестов;

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

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

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

Существуют следующая функциональность, от автоматизации тестирования которой, можно получить наибольшую отдачу:

- труднодоступные места в системе (бэкенд процессы, логирование файлов, запись в БД);

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

- рутинные операции, такие как переборы данных, заполнение формы с большим количеством вводимых полей;

- проверочные сообщения (автоматизировать заполнение полей не корректными данными и проверку на появление той или иной валидации);

- длинные end-to-end сценарии;

- проверка данных, требующих точных математических расчетов;

- проверка правильности поиска данных.

А также, другая функциональность, в зависимости от требований к тестируемой системе и возможностей выбранного инструмента для тестирования.

Существуют, однако, те области, где следует применять ручное тестирование, поскольку автоматизации здесь нецелесообразна, это:

- анализ документации и спецификаций на наличие разнообразных ошибок и недоработок;

- анализ исходного кода на наличие логических ошибок;

- разработка тестов;

- создание алгоритмов формирования тестовых данных;

- первый запуск тестов;

- экспертная оценка результатов выполнения тестов;

- написание отчётов об ошибках;

- отладка и обновление тестов;

- документирование процесса тестирования;

- выбор тестов, которые необходимо выполнить;

Для более эффективного использования автоматизации тестирования разрабатываются отдельные тестовые случаи проверяющие:

- базовые операции создания, чтения, изменения, удаления сущностей;

- типовые сценарии использования приложения, либо отдельные действия. Это так называемый end-to-end сценарий, который проверяет совокупность действий, такие сценарии позволяют вернуть систему в состояние, максимально близкое к исходному, и, следовательно - минимально влияющее на другие тесты;

- интерфейсы, работы с файлами и другие моменты, неудобные для тестирования вручную.

На выбор инструмента автоматизации тестирования влияют следующие аспекты:

- следует обратить внимание, насколько хорошо инструмент для автоматизации распознает элементы управления в разрабатываемом приложении. В случае, когда элементы не распознаются - следует заняться поиском дополнения(плагина), либо соответствующего модуля. Если такового нет - от инструмента лучше отказаться. Чем больше элементов может распознать инструмент - тем большую экономию времени возможно получить при написании и поддержке скриптов;

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

- удобство инструмента для написания новых скриптов. Это подразумевает временные затраты, а также возможность структурирования кода (поддержка объектно-ориентированного программирования), отладки и изменения.

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

Таблица 1.1 - Инструменты для автоматизации

Компания	Инструмент
Hewlett-Packard (Mercury Interactive)	Quick Test Professional, WinRunner
IBM Rational	Rational Robot, Rational Functional Tester
Borland (Segue)	SilkTest
Automated QACorp	TestComplete
Microsoft	Microsoft VS 2015
OpenQA	Selenium
Бесплатные библиотеки	HtmlUnit, HttpUnit, Watij, Selenium, Junit

Примечание - Источник: [5].

Существует три уровня автоматизации тестирования.

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

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

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

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

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

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

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

Таблица 1.2 - Действующие государственные стандарты и их международные аналоги

Действующий стандарт Республики Беларусь	Обозначение международного стандарта	Статус международного стандарта
1	2	3
СТБ ИСО/МЭК 12119-2003 Информационные технологии. Пакеты программ. Требования к качеству и тестирование	ISO/IEC 12119:1994	Отменен в связи с заменой на ISO/IEC 25051:2006. Опубликован проект ISO/IEC CD 25051:2012
СТБ ИСО/МЭК 9126-2003 Информационные технологии. Оценка программной продукции. Характеристики качества и руководства по их применению	ISO/IEC 9126:1991	Отменен с заменой на ISO/IEC 9126-1:2001, который уже тоже отменен. Дополнительно разработаны и сейчас пересматриваются: ISO/IEC TR 9126-2:2003; ISO/IEC TR 9126-3:2003; ISO/IEC TR 9126-4:2004
СТБ ИСО/МЭК ТО 9294-2003 Информационные технологии. Руководство по управлению документированием программного обеспечения	ISO/IEC 9294:1990	Отменен в связи с заменой на ISO/IEC TR 9294:2005, который перерабатывается в ISO/IEC/IEEE 26511:2011
СТБ ИСО/МЭК 12207-2003 Информационные технологии. Процессы жизненного цикла программных средств	ISO/IEC 12207:1995	Отменен в связи с заменой на ISO/IEC 12207:2008
СТБ ИСО/МЭК 14764-2003 Информационные технологии. Сопровождение программных средств	ISO/IEC 14764:1999	Отменен в связи с заменой на ISO/IEC 14764:2006

Примечание - Источник: [5].

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

Таблица 1.3 - Международная организация по стандартизации

Область применения	Обозначение
Менеджмент услуг	Серия ISO/IEC 20000
Управление жизненным циклом	ISO/IEC TR 24748 части 1-4
Качество программного продукта	Серия ISO/IEC 25000
Информационные технологии. Оценка процессов	ISO/IEC 15504 части 1-10
Тестирование программного продукта	ISO/IEC/IEEE DIS 29119 части 1-4

Примечание - Источник: [5].

Согласно стандарту СТБ ИСО/МЭК 12119-2003 процесс тестирования выглядит следующим образом.

Для начала процесса должны быть выполнены определённые условия:

- наличие компонентов продукта - для тестирования пакета программ должны иметься в наличии все его поставляемые компоненты, а также нормативные документы, указанные в описании продукта;

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

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

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

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

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

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

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

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

При тестировании должны быть использованы исходные данные и последовательности команд, которые в документации пользователя явно не рекомендуются или объявляются запрещенными.

Протоколы по каждому тесту должны содержать информацию, достаточную для повторения. Данная информация должна включать:

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

- все результаты, связанные с контрольными примерами, включая все ошибки, выявленные при выполнении теста;

- штат персонала, вовлеченного в тестирование.

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

- обозначение продукта;

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

- использованные документы (включая их обозначения);

- результаты тестирования описания продукта, документации пользователя, программ и данных;

- перечень несоответствий требованиям;

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

- дата окончания тестирования.

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

- все измененные части документов, функций и данных должны быть протестированы как новый продукт;

- все неизмененные части, на которые могут влиять измененные части или изменения в необходимой системе (в соответствии с опытной оценкой тестировщика), должны быть протестированы как новый продукт;

- все другие части должны быть, по крайней мере, выборочно протестированы. [3]

1.2 Методы многокритериальной оптимизации оценки экономической эффективности

Достаточно часто в реальных ситуациях качество эксплуатации исследуемого объекта или системы оценивается не единственным критерием или показателем качества (см. параметрическую оптимизацию уравнение 3-1), а совокупностью таких критериев, причем представляющих одинаково значимыми. [17] Такая постановка задачи приводит к задаче оптимизации с векторной целевой функцией , которая должна трактоваться неким определенным образом. Как правило, относительная значимость этих целей в общем неизвестна до тех пор, пока не будут определены все основные свойства системы и не будут полностью истолкованы все возможные взаимосвязи. [14]По мере того, как число возможных целей возрастает, то, очевидно, что эти взаимосвязи образуют сложную структуру и их становятся труднее идентифицировать.[27][28] В данном случае многое зависит от интуиции исследователя и его или ее умения точно выражать те или иные предпочтения в процессе оптимизации.[18] Таким образом, стратегия построения многокритериальной оптимизации состоит, прежде всего, в способности адекватно определить постановку задачи так, что бы эта задача допускала свое решение, а также выразить необходимые предпочтения в виде числовых зависимостей и сохранив при этом реальность поставленной задачи.[19][29]

Многокритериальная оптимизация представляет собой минимизацию некого вектора целей F(x), на которой могут быть наложены дополнительные ограничения или предельные значения:

Отметим, что поскольку F(x) является неким вектором, то любые компоненты F(x) являются конкурирующими и отсутствует некое единое решение поставленной задачи. [20] Взамен этого, для описания характеристик целей вводится концепция множества точек неулучшаемых решений (так называемая оптимальность по Парето). [26] Неухудшаемое решение есть такое решение, в котором улучшение в одной из целей приводит к некому ослаблению другой. [21] Для более точной формулировки данной концепции рассмотрим некую область допустимых решений в параметрическом пространстве , которое удовлетворяет всем принятым ограничениям, т.е. при ограничениях:



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

, где при условии .

В двумерном случае, как это представлено на рисунке 1.1, вектор характеристик F(x) отображает параметрическое пространство в пространство целевых функций. [23]

Рисунок 1.1 - Отображение параметрического пространства а пространство целевых функций

Примечание - Источник: [23].

Точка является неулучшаемым решением, если для некоторой окрестности нет некого такого, что и

Множество точек неулучшаемых решений лежит на кривой между точками С и D. Точки А и В представляют специфичические неулучшаемые точки. [24]



Рисунок 1.2 - Множество неулучшаемых решений

Примечание - Источник: [23].

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

Поскольку любая точка пространства , то есть пространства, в котором отсутствуют неухудшаемые точки, представляет точку, в которой любое улучшение может быть достигнуто во всех выбранных целях, то ясно, что такая точка не представляет никакой ценности.[25] Следовательно, многокритериальная оптимизация должна включать в себя определенную генерацию и выбор точек с неулучшаемыми решениями. [30]



2. Анализ системы тестирования программного обеспечения в ИООО «ЭПАМ Системз»

2.1 Характеристика и направления деятельности компании

«EPAM Systems» -- крупнейший поставщик услуг в области разработки программного обеспечения и решений на территории бывшего Советского Союза и в Центральной и Восточной Европе. Созданная в 1993 году, сегодня она имеет 17 представительств в 10 странах мира, в штате более 5000 высококвалифицированных специалистов, и компания продолжает стабильно расти. Компания EPAM Systems выполняет проекты более чем в 30 странах мира, в частности -- для всемирно известных заказчиков из списков Fortune 50/500 и государственных учреждений, в том числе и на территории СНГ.

Выполняя проекты для крупнейших корпораций, и сотрудничая с ведущими мировыми разработчиками программного обеспечения, «EPAM Systems» приобрела уникальный опыт в таких областях как:

- разработка по заказам крупнейших производителей программного обеспечения для систем корпоративного планирования (ERP), управления жизненным циклом изделий (PLM); корпоративных информационных порталов (EIP), систем управления отношениями с клиентами (CRM), серверов интеграции приложений (EAI), систем управления контентом (CMS), систем управления знаниями (KMS);

- разработка приложений, соответствующих требованиям новейших сервис-ориентированных архитектур (SOA -- service-oriented architecture);

- создание и развертывание электронных систем управления закупками и сбытом;

- построение порталов крупных предприятий и холдингов с развитыми средствами анализа данных и управления знаниями;

- интеграция приложений в распределенных системах (в том числе насчитывающих сотни производственных площадок, сотни унаследованных приложений и десятки ERP-систем), проектирование, консолидация и настройка корпоративных справочников и каталогов. [11]

EPAM с успехом внедрили свои решения в различных сферах деятельности, включая:

- финансы;

- страхование;

- государственное управление;

- СМИ, исследования и дистанционное образование;

- телекоммуникации и высокие технологии;

- производство, строительство и автомобилестроение;

- программное обеспечение;

- розничная торговля и потребительские товары;

- энергетика, нефтедобыча и металлургия;

- туризм и индустрия развлечений.

Рисунок 2.1 - Основные сведения об ИООО «ЭПАМ Системз»

Примечание - Источник: [8].



Компания выполняет тестирование программного обеспечения как в рамках отдельных проектов, так и на различных этапах жизненного цикла программного обеспечения: проектирования, разработки, внедрения, промышленной эксплуатации, сопровождения и поддержки 2 и 3 уровней. EPAM проверяет функциональность, производительность, безопасность и другие характеристики самых различных приложений: разработанных EPAM, другими ИТ-компаниями или ИТ-подразделением заказчика.

Рисунок 2.2 - Деятельность ИООО «ЭПАМ Системз»

Примечание - Источник: [8].

Для тестовых испытаний используются собственные стенды, облачные сервисы, виртуальные машины. Производственные процессы EPAM сертифицированы по стандарту информационной безопасности ISAE 3000 Type 2 (SAS70 Type II), а также соответствуют стандартам ISO 9001:2000 и CMMI level 4. Партнерство с IBM и другими технологическими лидерами помогает обеспечить необходимую тестовую среду для практически любых испытаний программного обеспечения: функционального, модульного, интеграционного тестирования; тестирования производительности, безопасности, баз данных, мобильных приложений.

В большинстве проектов по разработке и тестированию программного обеспечения EPAM применяет автоматизированное тестирование с использованием как коммерческих инструментов: SilkTest, QuickTestPro, WinRunner, TestComplete, RationalFunctionalTester, Rational XDE Tester, RationalRobot, - так и open-source-продуктов: Selenium, Watir, WatiN, HttpUnit, HtmlUnit, JUnit, NUnit, JaTeFW и т.п. Кроме этого, нами часто используется собственный инструментарий TAF (TestAutomationFramework), который позволяет одновременно тестировать несколько решений, построенных на различных технологиях.

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

Разработка программных продуктов - одна из основных специализаций EPAM с момента основания в 1993 году. За годы успешной реализации проектов для всемирно известных поставщиков программного обеспечения, среди которых Oracle, Microsoft, Novell и SAP, был приобретён уникальный опыт в области разработки программного обеспечения, проектирования целевой архитектуры и прототипирования ИТ-решений.

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

ЕПАМ осуществляет полный цикл разработки программного продукта - с нуля до момента его выхода на рынок, обеспечиваем его дальнейшую поддержку и версионность. Работа над проектом ведется согласно четко выстроенной методологии (Agile/Scrum, RUP, CI (Continuous Integration) и др.), которая может быть гибко адаптирована под процессы конкретного заказчика, включая организацию удаленной работы специалистов. Компания располагает также инструментами собственной разработки для управления проектами и персоналом в территориально распределенной среде.

Что касается управления разработкой программного обеспечения, то в зависимости от целей и задач проекта управление разработкой программного обеспечения в EPAM осуществляется по различным методикам:

- каскадная (водопадная; waterfall) модель;

- итеративная модель (методология RUP - Rational Unified Process);

- гибкая разработка (методология Agile - Scrum, Extreme Programming и др.);

- непрерывная интеграция (методология Continuous Integration);

- для обеспечения максимально эффективного управления процессом разработки программного обеспечения компанией разработано и используется группа собственных специализированных ИТ-решений;

- EPAM Project Management Center (PMC) - для управления и отслеживания хода проекта в распределенной среде;

- EPAM Utilization and Project Staffing Analyzer (UPSA) - для отбора специалистов по заданным критериям (знание определенных технологий, опыт участия в аналогичных проектах, местоположение и т.п.) и анализа проектного портфолио;

- EPAM Human Resource Management - Applicants Workbench -для эффективного управления персоналом. Система содержит базу данных всех кандидатов, обращавшихся в компанию, включая студентов, которые в данный момент обучаются в студенческих лабораториях ЕРАМ;

- EPAM Hardware Utilization Analyzer (EPAM HUA) - для эффективного использования технологических ресурсов компании;

- EPAM Scrum Tool - для поддержки полного цикла разработки программного обеспечения по Agile-методологии;

- другие внутренние системы.

Рассмотрим методологию Agile широко применяемую в компании.

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

Agile (и ее вариации - методологии Scrum, Extreme Programming и т.д.) подразумевает разработку программного обеспечения короткими циклами. Каждый этап - это уменьшенный вариант проекта: проводится планирование, анализ требований, проектирование, кодирование, тестирование и документирование. По окончании этапа заказчик получает работающую версию информационной системы, если требуется - пересматривает дальнейшие приоритеты проекта, и цикл разработки запускается снова. В итоге создается решение, которое на 100 процентов соответствует ожиданиям компании.

На практике методология Agile может использоваться в нескольких интерпретациях. В проектах для заказчиков EPAM наиболее часто применяет: Scrum, Extreme Programming, Lean Software Development (LSD), Dynamic Systems Development Method (DSDM), Open Unified Process (OpenUP), Agile Project Management (APM), Microsoft Solutions Framework для Agile (MSF) и др.

Преимущества Agile:

- быстрая и постоянная обратная связь команды разработчиков с заказчиком;

- гибкий график реализации функциональности;

- отсутствие затрат на составление и согласование подробной технической документации;

- акцент на эргономичность ИТ-системы;

- все процессы, функционирующие в EPAM, делятся на 4 группы;

- ProductRealization;

- MeasurementandAnalysis;

- ManagementResponsibility;

- AssetManagement.

Наибольший интерес представляют production-процессы (т.е. процессы из группы Product Realization):

- Project Management Process;

- Project and Product Quality Assurance;

- Configuration and Change Management Process;

- Software Development Process;

- Quality Control Process;

- Requirement Development and Management Process;

- Maintenance and Support Process;

- Risk Management.

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

Рисунок 2.3 - Production-процессы EPAM Systems

Примечание - Источник: [8].

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

Для того, чтобы разработка шла успешно, используются другие процессы:

- Project Management -- чтобы правильно запланировать работы и распределить задачи между сотрудниками, мониторить состояние проекта и контролировать его выполнение;

- Risk Management -- чтобы определить потенциальные проблемы и предупредить их или определить действия, которые помогут минимизировать негативные последствия этих проблем;

- Configuration and Change Management -- чтобы не запутаться, какие файлы и документы где хранятся, в каких системах, как выпускаются билды, чтобы иметь возможность отследить, какое изменение или требование в каком билде было реализовано, чтобы организовать эффективную совместную работу;

- Project and Product Quality Assurance -- чтобы проект был успешным и его цели были достигнуты (посредством, например, ревью требований перед их реализацией, обучения сотрудников или внедрение новой технологии, и т.п.);

- Requirement Development and Management -- как должны разрабатываться требования, как ими управлять;

- Software Development -- описывает непосредственно имплементацию продукта;

- Quality Control -- проверка качества поставляемого продукта или его частей посредством тестирования, оптимизации производительности и экспертной оценки;

- Maintenance and Support -- какие есть уровни сопровождения и поддержки и какие активности проводятся в рамках каждого из них.

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

Процессы остальных групп:

- к группе Measurement and Analysis относятся: Internal Audit, Measurement and Analysis, Formal Evaluation;

- к группе Management Responsibility относятся: Organizational Process Management;

- к группе Asset Management относятся: Human Resource Management, Organizational Training, Software Asset Management, Risk Management for IT Services, Change Management for IT Services.

Сотрудничество с ведущими фирмами-разработчиками программного обеспечения, консалтинговыми компаниями и исследовательскими институтами помогает EPAM Systems поставлять своим клиентам решения мирового уровня. Среди наиболее известных партнёров EPAM Systems по решениям и технологиям следует упомянуть: SAP, Microsoft, IBM, Novell, BEA Systems, Oracle, SunMicrosystems, Knova, Retek, Datalex, Interwoven, LeverX, LogicLibrary; по консалтингу: CoreMatrixSystems, Datalex, EchoInternational, Консалтинговая компания IDS Scheer, IMG, MadisonConsultingGroup, SolutionzGroup, TІImpact; по исследованиям: Белорусский национальный технический университет, Белорусский государственный университет, Белорусский государственный университет информатики и радиоэлектроники, Белорусский государственный экономический университет, Гродненский государственный университет, Гомельский государственный университет, Национальная Академия Наук (Беларусь), Мэнхеймский университет (Германия).

14 февраля 2012 года компания EPAM Systems открыла совместную учебно-научную лабораторию по подготовке SAP-специалистов на базе БГЭУ. Благодаря появлению новой лаборатории, университет стал участником программы SAP University Alliances, которая призвана поддерживать вузы в подготовке высококвалифицированных специалистов. Технологии SAP изучают студенты факультета менеджмента на кафедрах экономической информатики и информационных технологий. Обучение, помимо лекционной части, включает также практические занятия: студенты могут подключаться к серверам Академического центра компетенций EPAM в Санкт-Петербурге.

EPAM Systems имеет большое количество офисов, размещённых в Восточной и Центральной Европе, а также в США. Следует также отметить, что главное представительство находится в Беларуси, в Минске, в Парке высоких технологий, а штаб-квартира в Лоренсвилле, штат Нью-Джерси.

Схема размещения офисов EPAM Systems показана на рисунке 2.4.

Рисунок 2.4 - Офисы EPAM Systems

Примечание - Источник: [8].



На рисунке 2.5 отображена организационная структура EPAM Systems.

За время работы EPAM Systems реализовано огромное количество проектов в странах СНГ и по всему миру. Понимание специфики функционирования бизнеса и окружающей среды, в том числе законодательной, а также размер и стабильность компании сделали EPAM лидером в разработке программного обеспечения в Центральной и Восточной Европе.

Рисунок 2.5 - Организационная структура EPAM Systems

Примечание - Источник: [8].

Стоит отметить, что за последние несколько лет наблюдается рост численности сотрудников EPAM Systems, одним из факторов является увеличение количества специалистов отрасли информационных технологий. Порядка 6,5 тыс. человек приходятся на минский офис компании. На рисунке 2.6 показан график изменения численного состава работников организации.

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

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

Рисунок 2.6 - Рост численности сотрудников EPAM Systems

Примечание - Источник: [8].

Основные финансовые итоги 4 квартала 2015 года следующие:

- выручка в 4 квартале 2015 года выросла до $260.3 миллиона[12], что на 10.3% выше аналогичного показателя предыдущего квартала и на 28.7% - показателя 4 квартала 2014 года. [1]

- в постоянной валюте выручка возросла на 34,3% по сравнению с 4 кварталом предыдущего года и на 11,7% по сравнению с предыдущим кварталом этого года;

- операционная прибыль, рассчитанная по GAAP, зафиксирована на уровне $31,8 миллиона, что на 32,3% выше результата 4 квартала 2014 года ($24 миллиона);

- операционная прибыль, рассчитанная не по GAAP, составила $46,8 миллиона, что на 29,6% больше, чем в 4 квартале 2014 года;

- квартальная разводненная прибыль на одну акцию (EPS) по GAAP составила $0.52 (для сравнения в 4 квартале 2014 года - $0.37);

- квартальная разводненная прибыль на одну акцию (EPS), рассчитанная не по GAAP, равна $0.78 (в аналогичном периоде 2014 года - $0.62).

Общие итоги 2015 года:

- выручка увеличилась на 25,2%, составив $914,1 миллиона, в конце 2014 года - $730,0;

- в постоянной валюте выручка по сравнению с концом предыдущего года возросла на 32,8%;

- операционная прибыль, рассчитанная по GAAP, зафиксирована на уровне $106,0 миллиона, что на 23% выше результата на конец 2014 года;

...