Введение

ВВЕДЕНИЕ

Современных менеджеров и разработчиков программного обеспече­ния просят осуществлять подготовку своих продуктов в минимальные сроки с минимальными ресурсами. Более 90% разработчиков срывают даты поставки. Нарушение сроков носит регулярный характер для 67% разработчиков. Кроме того, в 91% случаев приходилось удалять в цикле разработки ключевую функциональность, чтобы уложиться в срок [1]. Сроки поставки продукта на рынок определяют выживание или смерть продукта — и, следовательно, выживание или смерть компании.

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

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

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

Так как ГОСТ 16504-81 "Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения" является устаревшим и не дает нужных сведений, мною было принято решение использовать международную систему стандартов Международного Института Инженеров по Электронике и Электротехнике (IEEE).

ЗАКЛЮЧЕНИЕ

В рамках данной ВКР:

1.  Проанализирована специфика тестируемой системы. Это, прежде всего, многоверсионность ПО, широкое использование GUI, разработка в Delphi 6, использование СУБД Oracle 9i.

2.  Выбраны виды тестирования, подлежащие автоматизации. Этими видами являются нагрузочное тестирование, которое невозможно при ручном тестировании, регрессионное тестирование, которое гораздо быстрее и эффективнее делается средствами автоматизации, сравнительное тестирование, очень актуальное для многоверсионного ПО, каким является "Аргус"

3.  Выбран инструмент автоматизированного тестирования. Инструментом является продукт компании Automated QA Test Complete 3.12.

4.  Создана модель системы тестирования.

5.  Разработана система тестов, соответствующая текущему этапу разработки системы "Аргус"

Система автоматизированного тестирования активно применяется при тестировании и разработке новых модулей системы "Аргус".

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

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

Литература

1. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация, Элфрид Дастин, издательство "ЛОРИ" 2003г

2. http://software-testing. ru/

3. http://www. ieee. org/