Экскурс в тестирование План icon

Экскурс в тестирование План


Смотрите также:
Объявляет
«Тестирование прошёл(ла)»...
План работы на урок: 1 Исторический экскурс...
Тематический план по дисциплине «Деловой иностранный язык»...
Актуальность программы экскурс в историю...
Тематический план дисциплины 9 Учебно методические материалы 11...
Контрольное тестирование. I. Тестирование на входящий рейтинг....
Фгу «Федеральный центр тестирования» в 2008 году проводит централизованное тестирование в полном...
План: Начало научного исследования психологических особенностей различных народностей...
Тестирование mpeg layer 3 (MP3) кодеров Предисловие...
Возможно ли тестирование программы на всех возможных путях угп...
Образовательные ресурсы Интернета. К уроку по обществознанию....



Лекция 11 14 ноября 2001.

Тестирование и формальные спецификации




Виды использования спецификаций:

  • Определение требований и эскизное проектирование

  • Детальное проектирование

  • Пост-спецификации

  • Реверс-инженеринг (обратная разработка, восстановление спецификаций)

  • Документация пользователя

  • Документация разработчика

  • Документация службы сопровождения

  • Поддержка тестирования

Можно сформулировать общую задачу-минимум и задачу-максимум.

Задача-минимум - поддержка согласованности всех видов документации (включая спецификации), реализационных представлений и тестов.

Задача-максимум – генерация одних артефактов на основе других.

Замечание. Каждый вид использования, предъявляет собственные требования к спецификациям. В частности. Разные виды и стили специфирования в разной степени подходят для генерации тестов.

^ Вопрос для размышления:

Каков должен быть габор артефактов, чтобы из них можно было сгенерировать все остальные?

Знаю сам

Уточняю

Узнал












Экскурс в тестирование


План

  • Почему тесты из спецификаций?

  • Цели тестирования

  • Основные подходы.Терминология

  • Извлечение тестов из спецификаций

Почему тесты из спецификаций?


Почему для автоматического тестирования недостаточно тестов, полученных из исходных текстов:

  • нет информации о способе проверки правильности результата

  • нет информации о том, что является полным набором функций системы


Цели тестирования


Цель тестирования - выявить наличие ошибок/несогласованностей.

Сравнение с другими формулировками:

  • найти ошибки (локализация - задача диагностики)

  • добиться отсутствия ошибок (отладка)

Терминология


Верификация и валидация

Верификация: проверка соответствия процесса разработки (включая его промежуточные и конечные фазы) требованиям к данному процессу.

Валидация: проверка того, что результат разработки ведет себя в соответствии с требованиями/ожиданиями пользователя/заказчика.

Тестирование – оценка качества ПО методом экспериментальной проверки – путем исполнения тестов.


Подходы к тестированию


Note. Дать английские термины.


“Черный ящик” и “белый ящик”.

Функциональное и структурное тестирование. Доменное тестирование.

Сценарное тестирование.

Стрессовое тестирование – тестирование при котором система подвергается нереально тяжелой нагрузке, сложным входным данным при неадекватном количестве ресурсов с целью сломать ее.

Модульное, интеграционное и системное тестирование.

Тестирование производительности, временных характеристик.


Разновидности объектов тестирования


Программные интерфейсы (Application Program Interfaces – API),

Телекоммуникационные протоколы

Системы реального времени

Пользовательские (графические) интерфейсы (GUI)

СУБД (database management system - DBMS)

Базы данных

Компиляторы


Виды тестирования


Разработка и использование тестов при отладке (это не собственно отладке, а только часть этой работы).

Собственно тестирование, проверка программы после того, как разработчик передал ее в службу проверки качества, сопровождения и т.п.

Приемные испытания (acceptance testing). Обычно это близко к системному тестированию, но такие тесты разрабатываются либо заказчиком, либо при его активном участии, что сказывается на методах, целях и, соответственно, на содержании.

Регрессионное тестирование (Regression testing). Тестирование, которое производится при внесении очередного изменения в программу, в частности, при выпуске нового релиза.

Характеристики качества ПО


Функциональность (функциональная полнота, правильность, точность)

Производительность, скорость, время отклика и др. временные характеристики.

Надежность, устойчивость к отказам, возможности самовосстановления.

Удобство сопровождения (удобство изучения, локализации проблем, исправления, развития).


Подзадачи тестирования


Генерация входных данных

Анализ результатов (output / outcome)

Генерация окружения: драйверов, заглушек.

Разработка инвариантного (common use) окружения run-time support, сетевые средства контроля и управления тестированием.

Накопление результатов тестирования, генерация отчетов

Оценка полноты

  • определение критериев заверешения тестирования/генерации тестов

  • селекция/фильтрация тестовых данных

  • оценка полноты тестового набора.

Регрессионное тестирование

  • сравнение результатов тестирования разных версий

  • конфигурирование тестовых наборов для разных целевых конфигураций

  • ре-генерация

  • связь артефактов/конфигурация тестовых наборов с историей изменений в проекте


Классы эквивалентности тестовых ситуаций


Введем термины:

  • тестовая ситуация – совокупность внешних и внутренних факторов, позволяющих различать условия выполнения программы;

Примеры внешних факторов

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

Примеры внутренних факторов

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

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

Примеры метрик для определения критериев тестового покрытия:

  • число выполненных операторов программы

  • число выполненных ветвей

  • число выполненных путей

  • число использованных data flow переходов

  • число использованных каналов передачи сообщений

  • число использованных разновидностей входных/выходных данных и др.

  • число проверенных состояний данных

  • число проверенных переходов между состояниями

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

В случае, когда критерии тестового покрытия определяются на основе спецификаций (некоторой модели поведения или структуры целевой системы), используется, так называемый, подход “model checking”. Суть подхода заключается в том, что тестовые наборы генерируются с целью покрыть в необходимой степени пути, ветви, условия и другие элементы модели. Вопрос о том, в каком соотношении находятся показатели тестового покрытия модели и целевой системы в общем случае не рассматривается. В «чистом» виде “model checking” предполагает аналитическую верификацию.

Общие подходы к тестированию конечного автомата


Определение (детерминированного) конечного автомата

type FA = S0 >< T

T = S >< I -m-> S >< O

Где S - множество состояний

T - множество переходов

I - множество входных воздействий

O - множество реакций

Задача достижения определенного состояния, определенного перехода.

Различающие/разрешающие тестовые последовательности.

Уровни критериев покрытия конечного автомата. Вложенные критерии.


Структура системы выполнения тестов


  • общие понятия – background

      • метрика для определения полноты тестового покрытия (для определения критериев тестового покрытия)

      • критерии тестового покрытия

      • тестовые ситуации

      • классы эквивалентности тестовых ситуаций

  • тестовый набор - test suite:

      • тестовая последовательность

      • тестовый драйвер

      • заглушка - stub

      • что есть «тестовый вариант - test case»?

  • инфраструктура

      • подсистема поддержки времени выполнения - run-time support - test bed

      • навигация

      • генерация отчетов

Потоки данных:


Input входные тестовые данные

Outcome выдача/выходные данные теста

Verdict вердикт

Trace трассировочная информация

Obtained coverage полученное тестовое покрытие


Стандартные схемы тестирования



Тестирующая система

тестовые агенты

Тестируемая система


Английские термины:

  • Тестирующая система – Test system, Test program

  • Тестируемая система – System Under Test (SUT) или Implementation Under Test (IUT)

  • Тестовый агент – Test agent

  • Совокупность программ, участвующих в тестировании – Test harness

  • Совокупность программных средств, которые используются для подготовки и пропуска тестов - Testware




Скачать 63.75 Kb.
оставить комментарий
Дата15.10.2011
Размер63.75 Kb.
ТипЛекция, Образовательные материалы
Добавить документ в свой блог или на сайт

Ваша оценка этого документа будет первой.
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Документы

Рейтинг@Mail.ru
наверх