Прагматически от программного продукта ожидается надежность, т.е. что программное обеспечение функционирует желаемым образом при заданных условиях. Способ функционирования и условия работы необходимо задавать на начальных этапах разработки продукта, а также уточнять в ходе всего цикл разработки. На практике невозможно протестировать все возможные комбинации входных параметров и сравнивать выход программы с ожидаемым результатом. Следовательно, очень важно выбрать эффективный набор тестовых данных в сочетании с типом тестирования. На настоящий момент используются также и автоматизированные тесты. Все тесты, например, как тесты эксплуатационной пригодности, нельзя автоматизировать.
Сущностью тестирования являются проверочные действия, которые демонстрируют выполнение всех представленных требований к программному обеспечению. При тестировании также надо удостовериться, что все представленные для исправления дефекты могут быть исправлены, и исправления, в свою очередь, не станут основой новых ошибок.
Поскольку качество программного продукта во многом зависит от типа проводимых испытаний, необходимо их тщательно выбирать и согласовывать с заказчиком продукта. Часть тестирования делает программист, часть тестирования проводят тестировщики, и напоследок, привлекают клиентов-заказчиков. Дальше приводится краткий обзор различных видов тестирования.
- В случае модульного тестирования тестируют конкретные программные модули –
одну подсистему из всей системы. Тестирование проводит в общем случае разработчик, занимающийся реализацией модуля. Модуль должен быть протестирован прежде, чем его проинтегрируют в остальную систему. Тестируя модуль, необходимо следить, чтобы он отвечал при анализе поставленным требованиям. Целью тестирования модуля является все же нахождение ошибок, а не установление соответствия требованиям пользователя. Например, работают ли корректно добавленные в модуль функции и возвращают ли правильные ответы. Модули тестируют на основе данных: верных, неполных и ошибочных. Обычно производится так называемое тестированием типа «белый ящик», то есть тестировщик знает внутреннее строение и логику работы тестируемого программного обеспечения.
- В случае интеграционного тестирования тестируют совместную работу между модулями – проверяют, работают ли объединенные друг с другом модули, и не генерируют ли самостоятельно работающие без ошибок модули совместные ошибки. В качестве тестировщика обычно используют независимого тестировщика, то есть тестировщика, который сам не разрабатывал проверяемые модули. Примером интеграционного теста является еженощная компиляция, чтобы проконтролировать поведение разрабатываемого продукта.
- В случае системного тестирования тестируют работу системы как единое целое. При тестировании системы методом «черного ящика» рассматривают части системы, непосредственно доступные пользователю (пользовательский интерфейс), без углубления в код (отсюда и наименование «черный ящик»). Тестовые случаи составляет тестировщик (в основном на основе пользовательских историй), который проводит также тесты. Тестировщиком может быть как заказчик, так и быть со стороны исполнителя. Этот тип тестирования также называют функциональным тестированием.
- Регрессионное тестирование – это тестирование любых типов программного обеспечения, которое используют после введенных изменений кода / системы. Например, при добавлении новой функциональности, изменении конфигурации, обновлении. Цель регрессионного тестирования – убедиться, что изменения и исправления ошибок не порождают в системе новые ошибки. Тестируют измененные модули (модульное тестирование), связанные с ними модули и функциональность всей системы (функциональное тестирование). Основным методом является повторный запуск уже используемых тестов с тем, чтобы убедиться, что система работает, старые ошибки не повторяются, и не возникают новые. В случае регрессионного тестирования полезно автоматизировать работу для уменьшения общей рабочей нагрузки.
- Тестирование производительности и нагрузочные тесты предназначены для проверки соответствия данной системы техническим требованиям. Тестирование производительности можно проводить несколькими способами – путем измерения производительности каждого компонента, либо экспериментируя с большой совокупностью тестовых данных при обычном использовании системы. Цель тестов производительности – распознать критические места, где может возникнуть перегрузка и потратить время на оптимизацию этих мест.
Если обычно тестовые данные продумываются тщательно и исходные данные выбираются исходя из задач, то в случае такого тестирования можно тестировать также с помощью случайной, сгенерированной компьютером большой совокупности данных.
- Цель проверки достоверности (валидация) – подтвердить, что выход работы программного обеспечения в обработанном виде годится для заданного использования. «Делаем ли мы корректную программную систему?»
- Цель верификации – подтвердить, что каждый выход процесса или проекта отвечает специфицированным требованиям. «Делаем ли мы программное обеспечение правильно?»
- Юзабилити-тесты (удобство использования) оценивают удобство использования системы с точки зрения пользователя: цель юзабилити-тестирования – выявление ошибок и мест, которые можно было бы улучшить, для этого наблюдают за использованием продукта пользователями. Конечно, к юзабилити-тестированию не относится то, когда пользователю показывают прототип / изображение (скриншот) будущего продукта и спрашивают, понятно ли. При тестировании человек должен выполнять конкретные задания, и, таким образом, выясняются плохо понимаемые места в программной системе или также на веб-странице. Для юзабилити-тестирования подходят так называемые «люди с улицы», те, которые видят систему впервые. Но также и эксперты, которые смогут, исходя из своего опыта и пользуясь теорией, найти слабые места в удобстве использования.
- Приемочный тест, или тест акцептования – тест, проводимый заказчиком для оценивания и принятия продукта. Тестовые случаи при приемочном тестировании описывают общими словами критерии передачи и приемки проекта, тестовые случаи, о которых заказчик и исполнитель договариваются до реализации проекта, должны быть конкретными и измеримыми;
- Исследование (проверка) кода – в отличие от рассмотренных выше типов тестов, в случае исследования кода код не выполняется, однако инспектируется тестировщиком. Исследование кода предполагает наличие опросных листов, на основе которых оценивают код и ищут в нем ошибки, что в тестах при обычных условиях не делают. Исследователи кода должны быть очень компетентными, например, в части используемого языка. Что ищут? Например, неинициализированные переменные, неподобающе выбранные типы данных переменных, выход переменных или индекса массива за разрешенный предел, порядок действий, совместимость различных типов переменных и т.п.
Следует комбинировать вышеупомянутые техники. Имеется целое множество тестируемых свойств, следует учитывать то, что на этапе установления требований к продукту для соответствующего свойства требования уже установлены и установлены так, чтобы позволить контролировать, то есть измерить, соответствие продукта. Перечислим ниже наиболее важные требования к характеристикам программного обеспечения:
- функциональность – атрибут продукта, выражающий его соответствие поставленным задачам, это значит, что программное обеспечение может делать то, в чем нуждается клиент;
- защищенность – свойство продукта ограничивать доступ неавторизованным лицам к бизнес-логике / данным;
- отказоустойчивость – атрибут продукта, выражающий способность обеспечить определенную работоспособность и в случае возникновения ошибочного состояния функционального уровня или неправильного использования интерфейса;
- самовосстанавливаемость – атрибут продукта, выражающий способность восстанавливать нормальный режим работы и работоспособность после возникновения ошибочного состояния;
- восстанавливаемость – атрибут продукта, выражающий сложность и необходимый объем работ, и время, необходимое для восстановления основной функциональности системы в случае аварийной ситуации;
- эффективность, производительность – атрибут продукта, выражающий время реагирования и затрачиваемое на обработку данных под нагрузкой;
- применяемость
- понятность – атрибут продукта, выражающий необходимый объем времени, в течение которого пользователи поймут логическую концепцию и применимость;
- обучаемость – атрибут продукта, выражающий необходимый объем времени, в течение которого пользователи смогут научиться использовать систему (например, ввод / вывод данных и т.д.);
- простота использования – атрибут продукта, выражающий гибкость системы и сложность изменения системы конечными пользователями, чтобы сделать систему удобной для себя;
- привлекательность – атрибут продукта, выражающий удовлетворение конечных пользователей от услуг, представления и поведения, предлагаемых продуктом;
- стабильность – атрибут продукта, выражающий величину риска возникновения неожиданного поведения, последующего за внесением изменений продукта;
- повторная используемость – атрибут продукта, выражающий возможность повторного использования компонентов продукта в других программных проектах
- мобильность – атрибут продукта, выражающий затраты времени и рабочие затраты при внедрении продукта в другие среды, платформы.
Различные типы тестов и соответствие этапов разработки иллюстрирует нижеприведенный рисунок. Непрерывные стрелки указывают шаги процесса разработки программного продукта во временном порядке, пунктирные линии указывают на связи между типами тестов и этапами разработки: например, модульный тест контролирует соответствие готового модуля спецификации, которая рождается на шаге детального проектирования;
системный тест соответствует шагу установления требований к программному обеспечению и отвечает на вопрос о том, соответствует ли целиком готовая система установленным требованиям. Приемочный тест отвечает на вопрос, удовлетворяет ли программный продукт потребностям клиента, или созрел ли продукт для внедрения и / или продажи.
Рисунок 1-7. V-модель тестирования программных продуктов. Модель частично вдохновлена водопадной моделью
Найденные в ходе тестирования ошибки следует документировать. Документирование, безусловно, не означает оформление бумажных документов, наоборот, используют специальные CASE-средства, например, Mantis и Bugzilla, которые также помогают в передаче отчетов об ошибках программистам.
Дополнительно к тестированию с качеством продукта связаны и исследования. Исследования – это деятельность, которая обычно осуществляется в виде групповой работы. В ходе исследования обсуждается и оценивается статус проекта программного обеспечения, риски, делаются решения по управлению ресурсами и из сферы требований-решений продукта. Решения должны протоколироваться с указанием лиц, ответственных за своевременное внедрение решений.
Специальнымитипами исследований являются:
- технические совещания, в котором участвуют архитекторы, аналитики, проектировщики продукта, клиенты. Анализируют и делают решения, затрагивающие структуру продукта;
- исследования кода;
- аудиты, которые обычно проводятся независимо представителями внешних организаций. Оценивают, среди прочего, соответствие продукта и / или процесса разработки требованиям, стандартам, формальным процедурам, договорам и т.д. Самая известная в мире ИТ-аудиторов организация – ISACA (http://www.isaca.org), сертифицированные ее аудиторы носят титул CISA (Certified Information System Auditor – сертифицированный аудитор информационных систем).