Файл: Тестирование Вебприложений.pdf

-перечень функциональности в соответствии с пунктами требований, запланированный для тестирования на данном цикле, и реальные данные по нему
-количество выполненных тестов – запланированное и реально исполненное
-время, затраченное на тестирование каждой функции, и общее время тестирования.
-количество найденных дефектов.
-количество повторно открытых дефектов.
-отклонения от запланированной последовательности действий, если таковые имели место.
-выводы о необходимых корректировках в системе тестов, которые должны быть сделаны до следующего тестового цикла
Оценка качества тестов
Тестовые метрики
Набор тестовых метрик, который помогает определить эффективность тестирования и текущее состояние продукта:
-покрытие функциональных требований.
-покрытие кода продукта (для модульного уровня тестирования).
-покрытие множества сценариев.
-количество или плотность найденных дефектов. Текущее количество дефектов сравнивается со средним для данного типа продуктов с целью установить, находится ли оно в пределах допустимого статистического отклонения.
-соотношение количества найденных дефектов с количеством тестов на данную функцию продукта. Сильное расхождение этих двух величин говорит либо о неэффективности тестов (когда большое количество тестов находит мало дефектов), либо о плохом качестве данного участка кода (когда найдено большое количество дефектов на не очень большом количестве тестов)
-количество найденных дефектов, соотнесенное по времени, или скорость поиска дефектов. Если производная такой функции близка к нулю, то продукт обладает качеством, достаточным для окончания тестирования и поставки заказчику.
Оценка качества тестов
Обзоры тестов и стратегии:
Тестовый код и стратегия тестирования, зафиксированные в виде документов, улучшаются, если подвергаются коллективному обсуждению.
Такие обсуждения называются обзорами и для них должна существовать процедура проведения и оценки их результатов. Обзоры наряду с тестированием образуют набор методов борьбы с ошибками с целью повышения качества ПО.
Цели обзора тестовой стратегии:
-установить достаточность проверок, обеспечиваемых тестированием.

-проанализировать оптимальность покрытия или адекватность распределения количества планируемых тестов по функциональности продукта
-проанализировать оптимальность подхода к разработке кода, генерации кода, автоматизации тестирования.
Цели обзора тестового кода:
-установить соответствие тестового набора тестовой стратегии.
-проверить правильность кодирования тестов.
-оценить достигнутую степень качества кода, исходя из требований по стандартам, простоте поддержки, наличию комментариев и т.п.
-если необходимо, проанализировать оптимальность тестового кода с целью удовлетворения требований к быстродействию и объему.

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) направлена на доказательство того, что все используемые в модели данные, в том числе входные, обладают удовлетворительной точностью и не противоречат исследуемой системе, а значения параметров точно определены и корректно используются.
Эти проверки связаны с проблемным анализом, т.е. анализом и интерпретацией полученных в результате эксперимента данных. Проблемный
анализ — это формулировка статистически значимых выводов на основе данных, полученных в результате эксперимента на имитационной модели.
Проверяется правильность интерпретации полученных с помощью модели данных, оценивается насколько могут быть справедливы статистические выводы, полученные в результате имитационного эксперимента. С этой целью проводят исследование
свойств
имитационной
модели: оценивается точность,
устойчивость,
чувствительность
результатов моделирования. Эти проверки связаны с выходами модели, сама имитационная модель рассматривается как черный ящик.
Таким образом, на этапе испытания и исследования разработанной имитационной модели организуется комплексное тестирование модели

(testing) - планируемый итеративный процесс, направленный главным
образом на поддержку процедур верификации и валидации
имитационных моделей и данных.
Некоторые полезные процедуры тестирования рассмотрим ниже. Более широкое изложение методов тестирования имитационных моделей можно найти в специальной литературе [20, 33, 56].
6.2 Проверка адекватности модели
При моделировании исследователя прежде всего интересует, насколько хорошо модель представляет моделируемую систему (объект моделирования).
Модель, поведение которой слишком отличается от поведения моделируемой системы, практически бесполезна.

Различают модели существующих и проектируемых систем.
Если реальная система (или ее прототип) существует, дело обстоит достаточно просто. Поэтому для моделей существующих систем исследователь должен выполнить проверку адекватности имитационной модели объекту моделирования, т.е. проверить соответствие между поведением реальной системы и поведением модели.
На реальную систему воздействуют переменные G*, которые можно измерять, но нельзя управлять, параметры Х*, которые исследователь может изменять в ходе натурных экспериментов. На выходе системы возможно измерение выходных характеристикY*.
При этом существует некоторая неизвестная исследователю зависимость между ними Y*=f*(Х*, G*).
Имитационную модель можно рассматривать как преобразователь входных переменных в выходные. В любой имитационной модели различают составляющие: компоненты, переменные, параметры, функциональные зависимости, ограничения, целевые функции. Модель системы определяется как совокупность компонент, объединенных для выполнения заданной функции Y = f(Х, G).Здесь Y, Х, G - векторы соответственно результата действия модели системы выходных переменных, параметров моделирования,
входных переменных модели. Параметры модели Х исследователь выбирает произвольно, G -принимают только те значения, которые характерны для данных объекта моделирования.
Очевидный подход в оценке адекватности состоит в сравнении выходов
модели и реальной системы при одинаковых (если возможно) значениях
входов. И те, и другие данные (данные, полученные на выходе имитационной модели и данные, полученные в результате эксперимента с реальной системой) — статистические. Поэтому применяют методы статистической
теории оценивания и проверки гипотез.
Используя соответствующий статистический критерий для двух выборок, мы можем проверить статистические гипотезы (Н
0
) о том, что выборки выходов системы и модели являются выборками из различных совокупностей или (Н
1
), что они "практически" принадлежат одной совокупности.
Могут быть рекомендованы два основных подхода к оценке адекватности:
1 способ: по средним значениям откликов модели и системы.
2 способ: по дисперсиям отклонений откликов модели от среднего
значения откликов систем.
А если не существует реальной системы (что характерно для задач проектирования, прогнозирования)? Проверку адекватности выполнить в этом случае не удается, поскольку нет реального объекта. Для целей исследования модели иногда проводят специальные испытания (например, так поступают при военных исследованиях). Это позволяет убедиться в точности модели, полезности ее на практике, несмотря на сложность и дороговизну проводимых испытаний.

Могут использоваться и другие подходы к проведению валидации имитационной модели [56], кроме статистических сравнений между откликами реальной системы и модели. В отдельных случаях полезна валидация внешнего представления, когда проверяется насколько модель выглядит адекватной с точки зрения специалистов, которые с ней будут работать, так называемый тест Тьюринга (установление экспертами различий между поведением модели и реальной системы). В процессе валидации требуется постоянный контакт с заказчиком модели, дискуссии с экспертами по системе. Рекомендуется также проводить эмпирическое тестирование допущений модели, в ходе которого может осуществляться графическое представление данных, проверка гипотез о распределениях, анализ чувствительности и др. Важным инструментом валидации имитационной модели является графическое представление промежуточных результатов и выходных данных, а также анимация процесса моделирования.
Наиболее эффективными являются такие представления данных, как гистограммы, временные графики отдельных переменных за весь период моделирования, графики взаимозависимости, круговые и линейчатые диаграммы. Методика применения статистических технологий зависит от доступности данных по реальной системе.
Верификация имитационной модели
Верификация модели — есть доказательство утверждений соответствия алгоритма ее функционирования замыслу моделирования и своему назначению. На этапе верификации устанавливается верность логической
структуры модели, реализуется комплексная отладка с использованием средств трассировки, ручной имитации, в ходе которой проверяется правильность реализации моделирующего алгоритма.
Комплексные процедуры верификации включают неформальные и формальные исследования программы-имитатора. Неформальные процедуры могут состоять из серии проверок следующего типа: проверка преобразования информации от входа к выходу; трассировка модели на реальном потоке данных (при заданных G и X):
X изменяется по всему диапазону значений контролируется Y; o можно посмотреть, не будет ли модель давать абсурдные ответы, если ее параметры будут принимать предельные значения; o
"проверка на ожидаемость", когда в модели заменяют стохастические элементы на детерминированные и др.
Полезным при решении указанных задач могут быть также следующие приёмы [56]: обязательное масштабирование временных параметров в зависимости от выбранного шага моделирования (валидация данных); валидация по наступлению "событий" в модели и сравнение (если возможно) с реальной системой; тестирование модели для критических значении и при наступлении редких событий;