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

Тестированием надо заниматься не только постоянно, но и систематично. Если не забывать, что это процесс обнаружения ошибок, то стоит потребовать от разработчика, чтобы он периодически силами специально созданных групп проводил так называемые "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.