 |
Виды тестовых исследований
|
|
|
|
Область обеспечения качества ПО и тестирования, в частности, — очень обширна. В самом общем виде все тестовые исследования имеет смысл разделить на две большие группы.
К первой относятся функциональные тесты, т. е. имеющие отношение к рабочей функциональности программного обеспечения, заложенной в ТЗ. Одной из разновидностей функционального тестирования является приемочное тестирование, или приемосдаточные испытания. Функциональные тесты имеют первоочередное значение для обеспечения качества продукта, поэтому разработчики ПО уделяют им особое внимание. Как правило, отделы тестирования компаний проводят именно такие тесты, поэтому аутсорсинг функционального тестирования не является в настоящий момент самым популярным. Однако статистика показывает, что проведение дополнительного независимого тестирования позволяет уменьшить количество дефектов в 3—30 раз в зависимости от качества исходной системы.
Ко второй группе относятся тесты на все, что не входит в основную функциональность ПО: эргономичность, производительность, безопасность, надежность и т. д. Ни для кого не секрет, что на этапе разработки ТЗ многие аспекты работы программы упускаются из вида, подразумеваются неявно, или же требования меняются в процессе разработки, но не документируются. Причем чем больше программная система, тем больше таких упущений. Например, программа проектировалась для работы в локальной сети, а затем к ней добавили модуль доступа в Интернет. К первоначальной системе не предъявлялось высоких требований по безопасности и отказоустойчивости, но в результате расширения функциональности эти требования стали критически важными.
|
|
|
В результате наиболее популярной услугой при аутсорсинге тестирования является исследование производительности, надежности и нагрузочных характеристик ПО. Причина очевидна — это развитие клиент-серверных систем и Интернет-приложений. Системы, построенные в данной архитектуре, имеют несколько узких мест. Как правило, это серверы баз данных и приложений, а также средства коммуникаций. Клиент-серверные системы работают в многопользовательском режиме, поэтому вопросы надежности и нагрузочной способности для них приобретают особое значение. Стоимость сбоя серверной программы несоизмеримо выше стоимости сбоя клиентского приложения. Поэтому дополнительное проведение тестирования такой системы на надежность экономически оправдано.
С тестированием на надежность тесно связано тестирование на производительность. Обычно разработчики пытаются вложить в программу максимум возможностей, что не так уж и плохо, пока не возникает необходимость подключить к системе несколько сотен или тысяч пользователей. В этом случае программа может оказаться неработоспособной и потребуется как минимум оптимизация ее работы, а как максимум — перепроектирование системы в целом. Поэтому проведение тестов на производительность является архиважным как на этапе разработки требований и архитектуры системы, так и во время приемочных испытаний. Как правило, разработчики не обладают достаточной квалификацией и ресурсами для проведения полномасштабного нагрузочного тестирования, и в этом случае аутсорсинг тестирования является не только экономически более эффективным, но зачастую и единственно возможным способом проверки ПО.
Руководитель, собирающийся провести независимое тестирование программного продукта, должен осознавать, что наиболее успешных результатов можно достичь только при выполнении определенных условий. Качество проводимого тестирования напрямую зависит от того объема информации о продукте, который разработчик может передать тестовому агентству. Чем больше будет предоставлено информации, тем качественнее можно подготовить требования к тестированию, тем большее число дефектов удастся выявить. Понятно, что организации с хорошо налаженным процессом производства, соответствующим, например, ISO 9001, получат максимальную выгоду.
|
|
|
Однако к аутсорсингу тестирования часто прибегают именно те компании, где формализация требований к ПО либо отсутствует, либо требования документированы в очень общем виде. Следует помнить, что в этом случае от тестового агентства потребуются дополнительные усилия и время на знакомство с продуктом, поэтому планировать начало работы с тестерами нужно заблаговременно, не дожидаясь окончания кодирования последней функции в программе. По этой причине целесообразно выяснить, какую методику намерены использовать тестеры, какие требования будут предъявляться к функциональности продукта. Невнятный ответ на данный вопрос поставит под сомнение качество тестирования.
Еще одним важным моментом работы с тестовым агентством является установление процедуры взаимодействия и обмена информацией. Необходимо определить, каковы должны быть способы передачи информации, формат описания обнаруженных дефектов, способы импорта/экспорта данных между информационными системами учета ошибок и требований к ПО, обеспечение конфиденциальности и пр. Неменьшее значение имеет и процедура управления проведением тестирования, регулярная отчетность о выполнении работ.
Аутосорсинг на примере
Перед тем, как приступить к изучению аспектов тестирования, необходимо рассмотреть процедуру анализа качества программных систем, выполняемого сотрудниками компаний, специализирующихся на тестировании. В нашей стране среди таких компаний наиболее известна Amphora Quality Technologies [8], которая занимается корпоративными информационными системами, Internet-приложениями и сложными геоинформационными и мультимедийными приложениями.
Качество программного обеспечения является сложным комплексным показателем. Количественные показатели качества определяются с помощью введения метрик, связанных с функциональностью, надежностью, производительностью и многими другими характеристиками. Однако важнейшим из критериев качества является, естественно, соответствие функционала системы спецификациям проекта. Или, другими словами, соответствие системы заданным требованиям.
|
|
|
Определение качества программных систем подразумевает под собой анализ проектных материалов, требований и приоритетов, планирование и проведение тестовых исследований, а также оценку полученных результатов.
По окончании тестирования, результаты исследований обобщаются и оформляются в виде формального отчета. Это отчет содержит подробное описание проделанной работы и список обнаруженных проблем. Когда необходимо, проводится сравнительный анализ характеристик системы с ее предыдущими версиями или выбранными эталонами.
Анализ функциональности программных систем и оценка их соответствия требованиям проводится специалистами лаборатории тестирования функциональности. Анализ функциональности включает в себя выполнение следующих тестирований:
Тестирование функциональности (тестирование "черного ящика")- тестирование программного продукта на соответствие функциональным спецификациям. Эти тесты могут быть и достаточно простыми, например, для проверки основных функций, и очень сложными, состоящими из множества сценариев, проверяющих полученные данные на соответствие ожидаемым.
Анализ дефектов - локализация областей программных операций, которые потенциально могут снизить качество продукта.
Тестирование интерфейсов - автоматическое тестирование функциональности визуальных форм, проверка на соответствие корпоративным стандартам (если требуется).
Тестирование системных компонентов - тестирование функциональности каждого из компонентов в отдельности, которое включает в себя проверку DCOM, CORBA и Java RMI компонентов, а также всех других компонентов, предоставленных в исходном коде.
Тестирование на совместимость и портативность - проверка корректной работы программных продуктов на тех конфигурациях аппаратного и программного обеспечения, для работы на которых они были разработаны. В частности, AQT проводит тестирование на совместимость между приложениями в Windows 2000.
|
|
|
Тестирование способности к взаимодействию - исследования, направленные на определение возможностей системных процессов взаимодействовать с внешними компонентами. Например, со специфичным аппаратным обеспечением, драйверами различных устройств, программным обеспечением других компаний и т.д. Как правило, здесь речь идет о тестировании характеристик надежности и производительности межсистемных шлюзов, а также об определении эффективности архитектурных и технических решений.
По результатам тестирования может быть произведен анализ причин возникновения обнаруженных дефектов, а также статистический анализ количественных характеристик качества ПО. Использование метрик в совокупности с регрессионным тестированием (тестирование каждого релиза) позволяет определять динамику изменения качества ПО и делает процесс разработки ПО управляемым и прогнозируемым.
Производительность является одной из важнейших характеристик современных информационных систем. Крупные корпорации, работающие на рынке e-Business и on-line решений, разрабатывают системы, обрабатывающие тысячи транзакций за несколько секунд. Для этих систем расширяемость и устойчивость к пиковым нагрузкам являются необходимыми условиями для успеха.
Анализ качества программного обеспечения с точки зрения производительности включает в себя следующие тесты:
Cравнительное тестирование - тесты, использующие стандартные, рекомендованные нагрузки для измерения производительности системы и ее сравнения с рекомендованной производительностью системы (или измерениями);
Тестирование производительности - тесты, использующие постоянный объем нагрузки, но различные конфигурации системы и программного окружения, для определения приемлемости производительности тестируемой системы и ее настройки (или оптимизации). Измерению подлежит количество транзакций в минуту, число пользователей, размер используемой базы данных;
Нагрузочное тестирование - проверка и определение приемлемости действующих пределов системы при различных объемах нагрузки, при этом сама тестируемая система остается постоянной. Измеряются характеристики объема нагрузки и времени ответа;
Анализ распределения и балансировки нагрузки - если системы содержат распределенную архитектуру или балансировку нагрузок, проводятся специальные тесты, для проверки методов функций распределения и балансировки нагрузок;
|
|
|
Тестирование конфликтов - проверка возможности системы корректно обрабатывать многочисленные запросы пользователей к одному ресурсу (записи данных, память, и т.п.);
Тестирование объемов - проверка и анализ возможностей системы оперировать большими объемами данных. Проверяется как работа с большими объемами данных на входе\выходе системы, так и работа с внутренними данными системы;
Стрессовое тестирование - тесты направлены на проверку работы функций системы с некоррекными параметрами. Стрессовое состояние системы может включать экстремальные нагрузки, дефицит памяти, отсутствие сервисов или аппаратного обеспечения, сжатые общие ресурсы;
Тестирование на расширяемость - тесты для измерения и анализа скорости выполнения различных операций продукта на множестве конфигураций программного и аппаратного обеспечения и систем управления базами данных.
Тестирование надежности - проверка поведения системы при длительной непрерывной эксплуатации при условии высокой нагрузки системы;
Тестирование целостности - проверка выносливости системы (защита от падений), а также проверка соответствия языку, синтаксису и корректного использования ресурсов.
Тестирование безопасности - проверяет уровень безопасности баз данных и коммуникации, проводит общий анализ архитектуры и качества безопасности подсистем продукта;
Тестирование на уязвимость - проверки направлены на поиск потенциально слабых мест программного обеспечения, могущих привести к несанкционированному доступу к информации или к системным ошибкам.
Программное обеспечение промежуточного уровня, или Middleware, - одна из наиболее важных составляющих современных информационных систем и e-Business решений. Как правило, в рамках Middleware функционирует бизнес-логика и специализированные межкомпонентные шлюзы, обеспечивающие эффективную "стыковку" программных слоев между собой. Качество и производительность серверной системы промежуточного уровня в большой степени определяют соответствующие характеристики программного комплекса в целом.
Тестирование программного обеспечения промежуточного уровня включает функциональное тестирование, тестирование производительности, безопасности и тестирование возможности взаимодействия. Анализу подвергается сам сервер промежуточного уровня, компоненты приложений и коммуникационная подсистема.
Тестирование удобства использования - тестирование на оборудовании и в окружении программного обеспечения, аналогичного используемому заказчиком, с целью проверки способности системы корректно работать в окружении конечного пользователя. Кроме того, тестируется пользовательский интерфейс и оценивается удобство системы.
Тестирование установки, возможностей настройки и обновлений - определение насколько хорошо и легко продукт устанавливается и обновляется на множестве конфигураций программного и аппаратного обеспечения, при различных условиях (например, недостаточное количество свободного места на диске или перебои электропитания).
Анализ согласованности - проверка точности и полноты технических требований, установленных разработчиками к окружению программного обеспечения;
Тестирование корректности требований - общий анализ функциональности, производительности и надежности операций системы на различных аппаратных и программных платформах и в различных конфигурациях, определяемых техническими требованиями.
Наличие исходных кодов и технических спецификаций программного обеспечения расширяет возможности ряда тестовых и аналитических исследований, а также существенно повышает достоверность их результатов. В основном, это объясняется наличием полной информации об архитектуре и конкретном способе реализации тех или иных компонентов системы. Вместе с этим, существует ряд специализированных исследований, проведение которых в принципе невозможно при тестировании системы методом "черного ящика".
Компонентное тестирование - анализ качества отдельных компонентов или структурных частей системы путем комплексного тестирования их функциональности и интерфейсов в искусственно формируемой программной среде. Чаще всего, данное исследование включает в себя функциональное тестирование и тестирование производительности. В ряде случаев, компонентное тестирование может быть произведено в отсутствие исходных кодов.
Корреляционное тестирование - исследование, направленное на анализ взаимного влияния различных компонентов или слоев системы друг на друга. В процессе анализа ряд компонентов системы может быть заменен компонентами-заглушками либо подвергнут независимому тестированию. В ряде случаев для систем, построенных в компонентной архитектуре, корреляционное тестирование может быть проведено в отсутствие исходных кодов.
Шаблонное тестирование - сравнительный анализ характеристик качества отдельных компонентов или структурных частей системы (наиболее часто - характеристик производительности) с аналогичными характеристиками авторитетных шаблонов. Шаблоном, как правило, является простой компонент или программа, осуществляющая принципиально аналогичные функциональные действия реального компонента. Однако она построена в простой архитектуре и лишена бизнес-логики (за исключением основной), вычислений, функций ввода-вывода, неизбежно присутствующих в системе. Характеристики шаблона могут быть получены экспериментальным либо аналитическим путем.
Локализация ошибок и дефектов - исследование, направленное на поиск компонентов - источников проблем, обнаруженных в процессе тестирования программного обеспечения. Как правило, речь идет о функциональном тестировании и тестировании производительности. Однако, данное исследование в равной степени полезно и для анализа причин дефектов, выявленных в результате других исследований. В процессе исследования проводится анализ соответствия функциональности отдельных компонентов системы техническим спецификациям, а также отладка отдельных компонентов системы.
Статический анализ исходного кода - проверка семантического и синтаксического соответствия исходного кода программного обеспечения определенным правилам. В основном, данный вид исследований проводится для контроля соответствия исходных текстов системы корпоративным стандартам либо для выявления случаев использования "запрещенных" конструкций или функций ОС. Последнее необходимо для проведения отраслевых сертификаций программных систем либо реинжиниринга крупных программных комплексов.
Вслед за этим, перед разработчиками программного обеспечения встает задача локализации и устранения источников обнаруженных в ходе исследований проблем. Анализ причин обнаруженных дефектов и интерпретация полученных характеристик программного продукта с целью его оптимизации - не менее трудоемкий процесс, чем тестирование и обработка результатов. Необходимо провести исследования архитектуры и исходного кода системы, отладку отдельных компонентов программы, а также, возможно, дополнительные тестовые исследования. С наибольшей продуктивностью данный процесс может быть выполнен при участии специалистов, обнаруживших исследуемые проблемы.
Методология разработки программного обеспечения Rational Unified Process регламентирует итеративный подход к разработке программного обеспечения. Все этапы проекта, а именно - планирование, анализ, дизайн, разработка, тестирование и оценка результатов проделанной работы выполняются многократно, на каждой стадии работы над проектом. Фактически, для каждого шага проводится полный производственный цикл.
Данный подход обеспечивает высокую степень систематизации производства, повышает качество продукции и значительно снижает риски. Особую актуальность итеративный подход приобретает, когда речь идет об обеспечении качества программного обеспечения.
С одной стороны, однажды обнаруженные дефекты должны быть исправлены, и это должно быть подтверждено результатами соответствующих тестов в процессе контроля качества следующего релиза программного обеспечения. С другой стороны, качество каждого нового релиза должно быть подтверждено всесторонним тестированием его функциональности и других характеристик.
Таким образом, однажды сформированный набор тестов необходимо проводить от релиза к релизу, регулярно контролируя качество программного обеспечения. В процессе развития или модификации системы тестовый набор будет меняться. Однако перечень выполняемых тестов должен всегда обеспечивать всесторонний контроль качества текущей функциональности системы и проверку исправления дефектов, обнаруженных на всех предыдущих итерациях.
Данный итеративный процесс называется регрессионным тестированием.
Литература
1. Майерс Г. Искусство тестирования программ. М.: Финансы и статистика, 1982.
2. Weinberg G.M. The Psyhology of Computer Programming/ New York, Van Nostrand Reinhold, 1971.
3. Brian Marick. The craft of software testing. Prentice-Hall, 1995.
4. Макгрегор Д., Сайкс Д. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие.DiaSoft, 2002.
5. Агафонов В.Н. Спецификация программ: понятийные средства и их организация. Новосибирск: «Наука», 1990.
6. Тоценко В.Г., Александров А.В., Парамонов Н.Б. Корректность, устойчивость, точность программного обеспечения. Киев: «Наукова Думка», 1990.
7. Безбородов Ю.М. Индивидуальная отладка программ. М.: «Наука», 1982.
8. Непомнящий В.А., Рякин О.М. Прикладные методы верификации программ. М.: Радио и связь, 1988.
9. Сайт компании Amphora Quality Technologies (http://www.aqt.ru).
10. Брукс Ф. Мифический человеко-месяц, или как создаются программные системы. СПб.: Символ-Плюс, 2000.
11. Майерс Г. Надежность программного обеспечения. М.: Мир, 1980.
12. Липаев В.В. «Тестирование программ», М. Радио и связь, 1986.
13. J. McCarthy "Dynamics of Software Development", Microsoft Press, 1995.
14. Архангельский Б.В., Черняховский В.В. Поиск устойчивых ошибок в программах. М: Радио и связь, 1989.
Приложение I. Список вопросов поинспекциям исходного текста программ (по Г.Майерсу)
Данный список содержит наиболее часто задаваемые вопросы во время проведения инспекций кода и сквозных просмотров программ (по материалам Г.Майерса).
Обращение к данным.
1. Используются ли переменные с не установленными значениями?
2. Лежат ли индексы массивов вне заданных границ?
3. Есть ли вероятность появления нецелого индекса?
4. Есть ли выход за границы строк?
Вычисления.
1. Производятся ли вычисления значений неарифметических переменных?
2. Производятся ли вычисления с использованием данных разных видов?
3. Существуют ли вычисления над значениями переменных разной длины?
4. Не меньше ли длина результата, чем длина вычисляемого значения?
5. Возможно ли переполнение или потеря промежуточного результата при вычислении?
6. Есть ли вероятность деления на нуль?
7. Существуют ли неточности при обработке двоичных чисел?
8. Не выходит ли значение переменной за пределы установленного диапазона?
9. Понятен ли порядок проведения вычислений?
10. Правильно ли осуществляется деление целых чисел?
Описание данных.
1. Все ли переменные описаны?
2. Правильно ли инициализированы массивы и строки?
3. Правильно ли определены размер, тип и класс памяти?
4. Согласуется ли инициализация с классом памяти?
5. Нельзя ли обойтись без переменных со сходными именами?
Сравнение.
1. Сравниваются ли величины несовместимых типов?
2. Сравниваются ли величины различных типов?
3. Корректны ли булевские выражения?
4. Понятен ли порядок следования операторов?
5. Понятна ли процедура разбора компилятором булевых выражений?
Передача управления.
1. Будет ли завершен каждый цикл?
2. Будет ли завершена программа?
3. Существует ли какой-нибудь цикл, который не выполняется из-за невыполнения входных условий?
4. Корректны ли возможные погружения в цикл?
5. Есть ли ошибки отклонения числа итераций от нормы?
6. Соответствуют ли друг другу символы начала и окончания блока?
7. Существуют ли неявные решения?
8. Можно было бы обойтись без безусловной передачи управления (оператор goto)?
Интерфейс.
1. Равно ли число входных формальных параметров числу фактических аргументов?
2. Соответствуют ли атрибуты параметров и аргументов?
3. Правильно ли заданы число, атрибуты и порядок следования аргументов для стандартных (библиотечных) функций?
4. Существуют ли какие-нибудь обращения к параметрам, не связанным с текущей точкой входа?
5. Не изменяет ли функция аргументы, являющиеся только входными?
6. Согласуются ли определения глобальных переменных во всех использующих их модулях?
7. Передаются ли в качестве аргументов константы?
Ввод-вывод.
1. Правильно ли указаны атрибуты файлов?
2. Правильно ли осуществляется открытие файлов (потоков ввода/вывода)?
3. Соответствует ли формат спецификации операторам ввода/вывода?
4. Соответствует ли размер буфера размеру читаемых данных?
5. Открыты ли файлы перед их использованием?
6. Обнаруживаются ли признаки появления конца файла (EOF)?
7. Перехватываются ли ошибки ввода/вывода?
8. Правильно ли осуществляется позиционирование внутреннего указателя файла на нужную позицию записи/чтения?
Приложение II. Список вопросов поинспекциям исходного текста программ на С++ (по Б. Марику)
Данный список содержит наиболее часто задаваемые вопросы во время проведения инспекций кода и сквозных просмотров программ, написанных на языке С++ (по материалам Brian Marick).
Объявления
Константы
Корректны ли задаваемые параметры с инструкцией #ifdefs, например:
#ifdef PDP10
#define BYTESIZE 7 /* должно быть 6 */
#else
#define BYTESIZE 8
#endif
|
|
|
