Современные информационные технологии/ 2.
Вычислительная техника и программирование
Магистрант Коваленко Л.В.
Карагандинский Государственный Технический Университет, Казахстан
Автоматизированное тестирование при разработке ПО
Тестирование
- один из важнейших этапов проверки качества разработанного ПО.
Так
сложилось, что ответ на вопрос о качестве ПО в большинстве случаев дает только
его эксплуатация -- как говорится, "жизнь покажет". Вместе с тем
заказчик вправе требовать от разработчика гарантий. Обилие неудачных попыток
получить заказное ПО высокого качества вызывает у заказчиков законные вопросы:
а возможно ли в принципе создавать качественное ПО? как этого добиться? что
должен требовать заказчик, чтобы получить качественное ПО? как должен работать
сам заказчик?
Для оценки
качества ПО всегда применяется целый комплекс мер, среди которых тестирование
ПО на предмет обнаружения ошибок - один из важнейших этапов.
Для его
проведения тестирования необходимы объект тестирования - в данном случае ПО - и
эталон, с которым этот объект сравнивается. ПО - это сложный объект, который
меняется по составу и проверяемым свойствам на разных стадиях разработки. Важно
понимать, что если разработчик и заказчик не сформулировали требования к ПО еще
до начала его разработки, то, во-первых, заказчик вряд ли получит именно то,
что хотел, и, во-вторых, ПО, которое он все-таки получит нельзя будет
проверить, поскольку объект есть, а эталона нет.
Иначе
говоря, тестирование ПО проводится на соответствие заранее определенным
требованиям (по функциональности, производительности, безопасности и пр.).
Поскольку объект тестирования сложный, необходим системный подход к
тестированию, его организации и проведению.
Итак, первый
вывод: надо четко определять требования к ПО в самом начале разработки, но не
"требования вообще" типа "ПО должно работать", а
требования, которые можно проверить. При этом требования к ПО подразделяются на
функциональные (какие функции и с каким качеством должно реализовывать ПО) и
нефункциональные (ограничения на время решения задачи, скорость доступа к
данным, требования к занимаемым ресурсам и т. п.). У заказчика и разработчика
должна быть возможность сравнить текущее функционирование системы с ее
эталонным (ожидаемым) поведением. При этом рекомендуется использовать итеративный
подход, так как раннее тестирование критичных областей значительно снижает риск
неудачи и стоимость исправлений для всего проекта разработки ПО.
Обсуждение технического задания,
технического проекта, архитектуры системы с заказчиком - это тоже часть
процесса обнаружения ошибок и уточнения эталона. Одно из главных правил для
разработчика -- надо очень плотно работать с заказчиком, тогда обе стороны
будут лучше понимать, что происходит при создании ПО в каждый конкретный момент
и как быстрее находить совместные решения.
Принято
разделять тестирование по уровням задач и объектов на разных стадиях и этапах
разработки ПО:
·
тестирование частей ПО (модулей,
компонентов) с целью проверки правильности реализации алгоритмов - выполняется
разработчиками;
·
функциональное тестирование подсистем и ПО
в целом с целью проверки степени выполнения функциональных требований к ПО -
рекомендуется проводить отдельной группой тестировщиков, не подчиненной
руководителю разработки;
·
нагрузочное тестирование (в том числе
стрессовое) для выявления характеристик функционирования ПО при изменении
нагрузки (интенсивности обращений к нему, наполнения базы данных и т. п.) - для
выполнения этой работы требуются высококвалифицированные тестировщики и
дорогостоящие средства автоматизации экспериментов.
Когда
понятно, что и зачем нужно тестировать, и есть план действий, самое время
задуматься о том, как это сделать эффективнее, быстрее и более качественно.
Современное ПО - это сложный объект, и вручную с ним справляться трудно и
дорого. К тому же при "ручном" тестировании результаты каждого
выполнения тестов пропадают, и их трудно повторить. Для того чтобы увеличить
объем проверок и повысить качество тестирования, обеспечить возможность
повторного использования тестов при внесении изменений в ПО применяют средства
автоматизации тестирования. К их числу относятся средства автоматизации
функционального и нагрузочного тестирования клиент-серверных и Web-приложений:
Rational TestStudio, Mercury LoadRunner, Segue SilkPerformer и др.
Тестированием
надо заниматься не только постоянно, но и систематично. Если не забывать, что
это процесс обнаружения ошибок, то стоит потребовать от разработчика, чтобы он
периодически силами специально созданных групп проводил так называемые
"review", или "структурные просмотры" проектных материалов
и аудит исходных кодов программ. Заказчик вправе договориться с разработчиком о
предъявлении подобных материалов или о не очень глубоком контроле хода такого
процесса. Он заинтересован в том, чтобы в организации разработчика были
поставлены процессы. В этом случае заказчик может быть уверен, что качество
разрабатываемого ПО контролируется и обеспечивается в ходе разработки.
Хотя
тестирование - процесс достаточно творческий, его можно и нужно планировать.
Это значит, что на каждом этапе работ должны быть выбраны критерий качества и
критерий завершения тестирования. Первый нужен для того, чтобы тестировщик или
группа тестировщиков понимали, что и на соответствие чему они проверяют. То
есть, каковы объект и эталон и какие свойства объекта проверяются. Второй
критерий помогает принять решение в случае, когда исчерпываются ресурсы,
отведенные на тестирование, он отвечает на вопрос, при каких условиях
тестирование может быть завершено.
План при
тестировании действительно нужен. Ведь для проверки сложного объекта можно и нужно
применять разные стратегии, позволяющие добиваться максимального результата при
существующих ограничениях на ресурсы тестирования. Например, если проверить
наиболее вероятные пути в программе, можно быть уверенным, что уж на них-то ПО
будет работать верно. Кроме того, план тестирования позволяет заранее
определить, что нужно подготовить для проведения тестирования. Скажем, многие
разработчики ПО начинают готовиться к нагрузочным экспериментам только тогда,
когда наступило время их проведения.
План тестирования
определяется международным стандартом IEEE 829-1983. В нем должны быть
предусмотрены как минимум три раздела содержащие, следующие описания:
·
что будет тестироваться (тестовые
требования, тестовые варианты);
·
какими методами и насколько подробно будет
тестироваться система;
·
план-график работ и требуемые ресурсы
(персонал, техника).
Дополнительно
описываются критерии удачного/неудачного завершения тестов, критерии окончания
тестирования, риски, непредвиденные ситуации, приводятся ссылки на соответствующие
разделы в основных документах проекта - план управления требованиями, план
конфигурационного управления и т. п.
Литература:
2. Агапов А. С.,
Зенин С. В., Михайловский Н. Э., Мкртумян А. А. Оценка и аттестация зрелости
процессов создания и сопровождения программных средств и информационных систем
(ISO/IEC TR 15504-CMM), Пер. с англ. Москва, "Книга и бизнес",
2001.
3. Rational Unified Process, Rational Software Corp.,
1987-2002.