Современные информационные технологии/3 программное обеспечение

К.т.н. Салыкова О.С.

Костананайский государственный университет им. А Байтурсынова

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

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

1. С чего же начинается тестирование? Для его проведения необходимы объект тестирования - в данном случае ПО - и эталон, с которым этот объект сравнивается. ПО -это сложный объект, который меняется по составу и проверяемым свойствам на разных стадиях разработки. Важно понимать, что если разработчик и заказчик не сформулировали требования к ПО еще до начала его разработки, то, во-первых, заказчик вряд ли получит именно то, что хотел, и, во-вторых, ПО, которое он все-таки получит нельзя будет проверить, поскольку объект есть, а эталона нет.

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

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

2. Неопытный заказчик всегда настроен на то, чтобы дать задание, а потом посмотреть конечный результат. Это самый верный способ получить некачественное ПО. Но низкое качество невыгодно обеим сторонам. Заказчику потому что заказанное им ПО нельзя использовать к тому моменту, когда оно уже нужно, и он теряет время и деньги, поскольку ПО должно работать на его бизнес, а оно не работает (т. е. не приносит денег), да еще и отбирает дополнительные ресурсы на доработку. Разработчику потому, что он теряет авторитет, дорабатывает ПО за свой счет (теряет деньги) и не может быстро переключиться на другого заказчика (теряет заказы). Гораздо эффективнее поэтапно осуществлять контроль над ходом отработки ПО. Именно такой подход приносит наибольший эффект и при разумной позиции заказчика будет наверняка положительно воспринят разработчиком. Для успешного проведения тестирования чрезвычайно важно тщательно спланировать эти работы.

3. И все же, что значит "поэтапное тестирование"? Заметим сразу, что многие заказчики не думают о том, что тестирование стоит денег и вообще затрат ресурсов и что за качество надо платить. Однако, осознав это, заказчик всегда должен понимать, за что именно он платит и как увидеть результаты.

Принято разделять тестирование по уровням задач и объектов на разных стадиях и этапах разработки ПО (см. таблицу):

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

При "ручном" тестировании результаты каждого выполнения тестов пропадают, и их трудно повторить. Для того чтобы увеличить объем проверок и повысить качество тестирования, обеспечить возможность повторного использования тестов при внесении изменений в ПО применяют средства автоматизации тестирования. К их числу относятся средства автоматизации функционального и нагрузочного тестирования клиент-серверных и Web-приложений: Rational TestStudio, Mercury LoadRunner, Segue SilkPerformer, а также менее популярные продукты фирм Compuware, CA, Empirix, RadView Software и др.

Тестированием надо заниматься не только постоянно, но и систематично. Если не забывать, что это процесс обнаружения ошибок, то стоит потребовать от разработчика, чтобы он периодически силами специально созданных групп проводил так называемые "review", или "структурные просмотры" проектных материалов и аудит исходных кодов программ. Желательно, чтобы на этапах сборки, комплексной отладки и опытной эксплуатации разработчик фиксировал интенсивность обнаружения ошибок, -- тогда по характеру изменения этой интенсивности можно будет судить об изменении качества ПО и, например, о целесообразности его передачи в опытную или постоянную эксплуатацию. Наконец, необходимо проведение комплекса испытаний ПО на соответствие требованиям ТЗ или других нормативных документов, на возможность эффективно работать с ПО на основе использования программной документации, приемосдаточных и других видов испытаний, обеспечивающих заказчику уверенность в работоспособности созданного для него ПО.

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

План тестирования определяется международным стандартом IEEE 829-1983. В нем должны быть предусмотрены как минимум три раздела содержащие, следующие описания:

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

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

Таким образом, тщательно и всесторонне проверив эти возможности, мы получаем гарантию работоспособности системы для конечного пользователя. Еще один важный аспект организации работ - хранение созданных тестов. Мы рекомендуем относиться к тестам так же, как и к исходному коду, т. е. нужно использовать версионные хранилища для возможности восстановления тестов предыдущих версий системы (MS SourceSafe, Rational ClearCase,). Это пригодится на этапе сопровождения ПО и даст возможность повторного использования готовых тестов на нескольких версиях системы. Аналогично нужно относиться и к тестовым данным, создавая архивы, копии и версии содержимого БД.