Особенности тестирования различных приложений. Лекция Особенности тестирования различных приложений. Автоматиз. Тестирование Вебприложений
 Скачать 0.61 Mb.
|
|
: 1)Тестирование основной функциональности, когда тестированию подвергается собственно система, являющаяся основным выпускаемым продуктом 2)Тестирование инсталляции включает тестирование сценариев первичной инсталляции системы, сценариев повторной инсталляции (поверх уже существующей копии), тестирование деинсталляции, тестирование инсталляции в условиях наличия ошибок в инсталлируемом пакете, в окружении или в сценарии и т.п. 3)Тестирование пользовательской документации включает проверку полноты и понятности описания правил и особенностей использования продукта, наличие описания всех сценариев и функциональности, синтаксис и грамматику языка, работоспособность примеров и т.п. Типы тестирования по способу выбора входных данных: 1)Функциональное тестирование, при котором проверяется: -покрытие функциональных требований. -покрытие сценариев использования. 2)стрессовое тестирование, при котором проверяются экстремальные режимы использования продукта. 3)Тестирование граничных значений. 4)Тестирование производительности. 5)Тестирование на соответствие стандартам. 6)Тестирование совместимости с другими программно-аппаратными комплексами. 7)Тестирование работы с окружением. 8)Тестирование работы на конкретной платформе На практике используются и комбинируются различные типы тестов для обеспечения заданного качества продукта. Подходы к разработке тестов -подходы, основанные на выборе тестовых данных (тестирование спецификаций, тестирование сценариев) -и подходы, основанные на реализации тестового кода (ручная разработка тестов, генерация тестов) Тестирование спецификации При разработке тестов, основанных на функциональной спецификации продукт требования к продукту являются основным источником, определяющим, какие тест будут разработаны. Для каждого требования пишется один или более тестов, которые в совокупности должны проверить выполнение данного требования в продукте. Тестирование сценариев осуществляется следующим образом: -определяется модель использования, включающая операционное окружение продукта и "актеров". Актером может быть пользователь, другой продукт, аппаратная часть и др. -разрабатываются сценарии использования продукта, которые могут быть строго определенным, параметризованным или разрешать некоторую степень неопределенности. -разрабатывается набор тестов, покрывающих заданные сценарии, с учетом степени неопределенности, заложенной в сценарии, и, при этом, каждый тест покрывает один сценарий, несколько сценариев, или, наоборот, часть сценария. Ручная разработка тестов Наиболее распространенным способом разработки тестов является создание тестового кода вручную. Это наиболее гибкий способ разработки тестов, однако характерная для него производительность труда инженеров- тестировщиков в создании тестового кода не намного выше скорости создания кода продукта, а объемы тестового кода на практике зачастую превышают объем кода продукта в 5 и более раз. Генерация тестов Учитывая существенные трудозатраты на ручную разработку тестов целесообразно использование автоматизированных способов получения тестового кода, таких как использование специальных тестовых языков (скриптов) игенерации тестов. В настоящее время некоторые языки спецификаций, используемые для описания алгоритмов тестирования, могут быть использованы идля генерации тестового кода, одним из примеров является язык MSC. Использование подхода генерации тестового кода позволяет значительно поднять производительность тестирования, а также преобразовать формализацию (кодировку) сценариев в достаточно интеллектуальную деятельность. Выполнение тестов: -подход ручного тестирования -подход автоматического исполнения (прогон) тестов. Ручное тестирование Ручное тестирование заключается в выполнении задокументированной процедуры, где описана методика выполнения тестов, задающая порядок тестов и для каждого теста - список значений параметров, который подается на вход, и список результатов, ожидаемых на выходе. Поскольку процедура предназначена для выполнения человеком, в ее описании для краткости могут использоваться некоторые значения по умолчанию, ориентированные на здравый смысл, или ссылки на информацию, хранящуюся в другом документе. Пример фрагмента процедуры ручного тестирования: 1)Подать на вход три разных целых числа. 2)Запустить тестовое исполнение. 3)Проверить, соответствует ли полученный результат таблице [ссылка на документ1] с учетом поправок [ссылка на документ2]. 4)Убедиться в понятности и корректности выдаваемой сопроводительной информации. Автоматизированное тестирование Автоматизация рассмотренного ранее примера приводит к созданию скрипта, задающего тестируемому продукту три конкретных числа и перенаправляющего вывод продукта в файл с целью его анализа, а также содержащего конкретное значение желаемого результата, с которым сверяется получаемое при прогоне теста значение. Пример фрагмента скрипта автоматизированного тестирования: 1)Выдать на консоль имя или номер теста и время его начала. 2)Вызвать продукт с фиксированными параметрами. 3)Перенаправить вывод продукта в файл. 4)Проверить равенство возвращенного продуктом значения ожидаемому (эталонному) результату, зафиксированному в тесте. 5)Проверить вывод продукта, сохраненный в файле (п.3), на равенство заранее приготовленному эталону. 6)Выдать на консоль результаты теста в виде вердикта PASS/FAIL и в случае FAIL - краткого пояснения, какая именно проверка не прошла. 7)Выдать на консоль время окончания теста. Сравнение ручного и автоматизированного подхода Ручное Автоматизированное Задание Гибкость в задании данных. Позволяет Входные значения строго входных использовать разные значения на разных циклах заданы значений прогона тестов, расширяя покрытие Проверка результата Гибкая, позволяет тестировщику оценивать Строгая. Нечетко нечетко сформулированные критерии сформулированные критерии могут быть проверены только путем сравнения с эталоном Повторяемость Низкая. Человеческий фактор и нечеткое Высокая определение данных приводят к неповторяемости тестирования Надежность Низкая. Длительные тестовые циклы приводят к Высокая, не зависит от длины снижению внимания тестировщика тестового цикла Чувствительность Зависит от детальности описания процедуры. Высокая. Незначительные к незначительным Обычно тестировщик в состоянии выполнить изменения в интерфейсе часто изменениям в тест, если внешний вид продукта и текст ведут к коррекции эталонов продукте сообщений несколько изменились Скорость выполнения Низкая Высокая тестового набора Возможность Отсутствует. Низкая скорость выполнения Поддерживается генерации тестов обычно не позволяет исполнить сгенерированный набор тестов Документирование тестовых процедур Тестовые процедуры - это формальный документ, содержащий описание необходимых шагов для выполнения тестового набора. Вслучае описания ручных тестов тестовые процедуры должны содержать полное описание всех шагов и проверок, позволяющих протестировать продукт ивынести вердикт PASS/FAIL. Вслучае описания автоматизированных тестов тестовые процедуры должны содержать достаточную информацию для запуска тестов и анализа результатов. Описание тестов разрабатывается для облегчения анализа и поддержки тестового набора, может быть реализовано в произвольной форме, но при этом должно выполнять следующие задачи: -анализировать степень покрытия продукта тестами на основании описания тестового набора. -для любой функции тестируемого продукта найти тесты, в которых функция используется. -для любого теста определить все функции и их сочетания, которые данный тест использует (затрагивает) -вывить структуру и взаимосвязи тестовых файлов -выявить принцип построения системы автоматизации тестирования Документирование дефекта Каждый дефект, обнаруженный в процессе тестирования, должен быть задокументирован и отслежен. При обнаружении нового дефекта его заносят в базу дефектов. Для этого лучше всего использовать специализированные базы, поддерживающие хранение и отслеживание дефектов, например, вида DDTS. При занесении нового дефекта рекомендуется указывать: -наименование подсистемы, в которой обнаружен дефект. -версия продукта (номер build ), на котором дефект был найден. -описание дефекта. -описание процедуры (шагов, необходимых для воспроизведения дефекта). -номер теста, на котором дефект был обнаружен. -уровень дефекта, то есть степень его серьезности с точки зрения критериев качества продукта или заказчика. Тестовый отчет Тестовый отчет обновляется после каждого цикла тестирования и должен содержать следующую информацию для каждого цикла: -перечень функциональности в соответствии с пунктами требований, запланированный для тестирования на данном цикле, и реальные данные по нему -количество выполненных тестов – запланированное и реально исполненное -время, затраченное на тестирование каждой функции, и общее время тестирования. -количество найденных дефектов. -количество повторно открытых дефектов. -отклонения от запланированной последовательности действий, если таковые имели место. -выводы о необходимых корректировках в системе тестов, которые должны быть сделаны до следующего тестового цикла Оценка качества тестов Тестовые метрики Набор тестовых метрик, который помогает определить эффективность тестирования и текущее состояние продукта: -покрытие функциональных требований. -покрытие кода продукта (для модульного уровня тестирования). -покрытие множества сценариев. -количество или плотность найденных дефектов. Текущее количество дефектов сравнивается со средним для данного типа продуктов с целью установить, находится ли оно в пределах допустимого статистического отклонения. -соотношение количества найденных дефектов с количеством тестов на данную функцию продукта. Сильное расхождение этих двух величин говорит либо о неэффективности тестов (когда большое количество тестов находит мало дефектов), либо о плохом качестве данного участка кода (когда найдено большое количество дефектов на не очень большом количестве тестов) -количество найденных дефектов, соотнесенное по времени, или скорость поиска дефектов. Если производная такой функции близка к нулю, то продукт обладает качеством, достаточным для окончания тестирования и поставки заказчику. Оценка качества тестов Обзоры тестов и стратегии: Тестовый код и стратегия тестирования, зафиксированные в виде документов, улучшаются, если подвергаются коллективному обсуждению. Такие обсуждения называются обзорами и для них должна существовать процедура проведения и оценки их результатов. Обзоры наряду с тестированием образуют набор методов борьбы с ошибками с целью повышения качества ПО. Цели обзора тестовой стратегии: -установить достаточность проверок, обеспечиваемых тестированием. -проанализировать оптимальность покрытия или адекватность распределения количества планируемых тестов по функциональности продукта -проанализировать оптимальность подхода к разработке кода, генерации кода, автоматизации тестирования. Цели обзора тестового кода: -установить соответствие тестового набора тестовой стратегии. -проверить правильность кодирования тестов. -оценить достигнутую степень качества кода, исходя из требований по стандартам, простоте поддержки, наличию комментариев и т.п. -если необходимо, проанализировать оптимальность тестового кода с целью удовлетворения требований к быстродействию и объему. LINT(1) НАЗВАНИЕ lint - верификатор C-программ СИНТАКСИС lint [-a] [-b] [-h] [-u] [-v] [-x] [-l библ] [-n] [-p] [-c] [-o библ] файл ... ОПИСАНИЕ Команда lint пытается обнаружить в заданных файлах, содержащих C- программы, конструкции, которые, возможно, являются ошибочными, немобильными или излишними. Более строго, чем при компиляции, выполняется проверка соответствия типов. Среди обнаруживаемых дефектов - недостижимые операторы; циклы, в которые входят не с начала; описанные, но не используемые автоматические переменные; логические выражения с константными значениями. Кроме того, проверяется использование функций и обнаруживаются функции, возвращающие значения в одних местах, но не возвращающие в других; функции, вызываемые с различным числом аргументов или с аргументами разных типов; функции, значения которых не используются, и функции, значения которых не возвращаются, но используются. Файлы-аргументы, имена которых оканчиваются на .c, считаются исходными C-файлами. Аргументы, имена которых оканчиваются на .ln, считаются результатом предыдущих вызовов lint с использованием опций -c или -o. Файлы .ln аналогичны об ектным (.o) файлам, которые создаются командой , если в качестве входных файлов заданы .c файлы. Файлы с другими расширениями игнорируются с выдачей предупреждения. Программа lint обрабатывает все .c, .ln и llib-lбибл.ln (заданные указанием -l библ) файлы в том порядке, в котором они перечислены в командной строке. По умолчанию lint подсоединяет к концу списка файлов свою стандартную библиотеку C-программ llib-lc.ln. Однако, если используется опция -p, вместо стандартной подсоединяется мобильная C-библиотека программы lint llib- port.ln. Если опция -c не указана, второй проход lint проверяет этот список файлов на взаимную совместимость. В случае задания опции -c файлы .ln и llib-lбибл.ln игнорируются. Можно указывать произвольное число опций и задавать их в командной строке в любом порядке вперемежку с именами файлов. Следующие опции используются для того, чтобы подавить выдачу некоторых сообщений. -a -b -h -u -v -x Не выдавать сообщения о присваиваниях long-значений переменным, не специфицированным как long. Не выдавать сообщения о недостижимых операторах break. [Программы, сгенерированные при помощи или обычно содержат большое число таких операторов.] Не применять набор эвристических тестов, предназначенных для того, чтобы попытаться "поймать" ошибки, улучшить стиль и сделать программу компактнее. Не выдавать сообщения о функциях и внешних переменных, используемых, но не определенных или определенных, но не используемых. (Эта опция полезна, когда при обращении к lint задается подмножество файлов, составляющих одну большую программу.) Не выдавать сообщения о неиспользуемых параметрах функций. Не сообщать о внешних переменных, которые нигде не используются. Потомство Многие из проверок, которые выполнял lint , теперь, учитывая достижения в генерации собственного кода , встроены в компиляторы (иногда с включенной опцией, например -Wall для GCC ). Эти компиляторы действительно должны для оптимизации исполняемого файла выполнять статический анализ гораздо более продвинутый, чем их предок UNIX. Несколько lint -проверок теперь не нужны, так как стандартизация разных языков программирования значительно уменьшила проблемы с переносимостью. Использование современных платформ разработки и контекстных текстовых редакторов с синтаксическим анализатором и автоматическим отступом также позволяет создавать более безопасный и приятный для чтения исходный код с самого начала. С появлением и распространением C++ были предприняты попытки адаптировать lint к особенностям этого нового языка; но его изолированное положение обрекло его: теперь на рынке можно найти целый ряд чрезвычайно сложных инструментов для статического анализа исходного кода. Тем не менее, lint остается популярным для общих проектов благодаря своему небольшому размеру, стабильности (отсутствие несвоевременных изменений версии), возможностям настройки и чрезвычайной переносимости. Благодаря lint исходные файлы от разных разработчиков могут быть согласованы для соблюдения определенных формальных правил единства, необходимых для автоматического обновления программного обеспечения и его документации. Верификация модели Это проверка на соответствие поведения модели замыслу исследователя и моделирования. Т.е. процедуры верификации проводят, чтобы убедиться, что модель ведет себя так, как было задумано. Для этого реализуют формальные и неформальные исследования имитационной модели. Верификация имитационной модели предполагает доказательство возможности использования создаваемой программной модели в качестве машинного аналога концептуальной модели на основе обеспечения максимального сходства с последней. Цель процедуры верификации — определить уровень, на котором это сходство может быть успешно достигнуто. Валидация и верификация имитационной модели связаны с обоснованием внутренней структуры модели, в ходе этих процедур проводятся испытания внутренней структуры и принятых гипотез, исследуется внутренняя состоятельность модели. Валидация данных Валидация данных (data validity) направлена на доказательство того, что все используемые в модели данные, в том числе входные, обладают удовлетворительной точностью и не противоречат исследуемой системе, а значения параметров точно определены и корректно используются. Эти проверки связаны с проблемным анализом, т.е. анализом и интерпретацией полученных в результате эксперимента данных. Проблемный анализ — это формулировка статистически значимых выводов на основе данных, полученных в результате эксперимента на имитационной модели. Проверяется правильность интерпретации полученных с помощью модели данных, оценивается насколько могут быть справедливы статистические выводы, полученные в результате имитационного эксперимента. С этой целью проводят исследование свойств имитационной модели: оценивается точность, устойчивость, чувствительность результатов моделирования. Эти проверки связаны с выходами модели, сама имитационная модель рассматривается как черный ящик. Таким образом, на этапе испытания и исследования разработанной имитационной модели организуется комплексное тестирование модели |