Вимірювання, пов’язані з тестуванням.

Базових метрик для вимірювання результатів тестування корисними є такі метрики:

метрики оцінювання набору тестів відповідно до обраного критерію покриття, як от метрики покриття тестових вимог, коду чи функцій;

метрики тенденцій дефектів (знайдених, усунутих, по серйозності, пріоритету тощо).

Крім того, для ефективного керування процесом тестування важливими метриками є час і вартість тестування.

Щодо практичного використання метрик для керування процесом тестування існує декілька проблем, а саме:

збирання початкових даних для обчислення метрик;

інтерпретація результатів розрахунку та ступінь довіри до них;

яким чином використовувати метрики для керуванням тестуванням на кожному рівні;

вибір мінімальної множини метрик, прийнятних в контексті певного процесу тестування.

Метрики для включення в процес тестування повинні вибиратися таким чином, щоб слугувати об'єктивними індикаторами стану виконання процесу тестування і поточного стану ПС.

Випадкове тестування.

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

 

Техніки орієнтовані на код.

Техники, ориентированные на код (Code-based techniques)

3.3.1 Тесты, базирующиеся на блок-схеме (Control-flow-based criteria)
Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов.

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

3.3.2 Тесты на основе потоков данных (Data-flow-based criteria)
В данных тестах отслеживается полный жизненный цикл величин (переменных) – с момента рождения (определения), на всем протяжении использования, вплоть до уничтожения (неопределенности). В реальной практике используются нестрогое тестирование такого вида, ориентированное, например, только на проверку задания начальных значений всех переменных или всех вхождений переменных в код, с точки зрения их использования.

3.3.3 Ссылочные модели для тестирования, ориентированного на код (Reference models for code-based testing – flowgraph, call graph)
Является не столько техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов (например, sequence-диаграммы, определенной в нотации UML и построенной на основе анализа кода).

 

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

¨ Цілі системи відслідковування проблем:

¤ Відслідковування стану тестування та усунення дефектів;

¤ Організація взаємодії між співробітниками та рішення спірних питань відносно класифікації і пріоритетів усунення дефектів;

¤ Визначення причин дефектів та виявлення “ вузьких місць ” у процесах розробки тестування.

22. Класифікація дефектів за серйозністю:

¨ Критичний;

¨ Серйозний;

¨ Значний;

¨ Незначний;

¨ Не дефект.

Класифікація дефектів за пріоритетом усунення:

¨ У першу чергу;

¨ Звернути увагу;

¨ У порядку черги;

¨ Відкласти;

¨ Відхилити.

Класифікація дефектів за стадіями розробки та джерелам:

¨ Класифікація дефектів за стадіями розробки співвідносить їх зі стадіями розробки, на яких вони були внесені.

¨ Класифікація дефектів за джерелами співвідносить дефекти з робочими продуктами стадій розробки, використання яких призвело до появи дефектів у коді ПО.

Класифікація дефектів за типом дефекту:

¨ Логічні;

¨ Обчислень;

¨ Інтерфейсу;

¨ Обробки даних;

¨ Вводу даних;

¨ Обробки помилок та ін.

 

 

23. Исследовательское тестирование – систематический способ проверить продукт без предопределенного набора тестов. Существует множество эвристик, которые могут быть применены к проведению исследовательского тестирования. Эти эвристики включают в себя использование ролей, характеристики, переменный анализ, область поиска и тестирование различных состояний. Для того, чтобы выполнить исследовательское тестирование таким образом, необходимо выбрать роль и работать через функциональные возможности системы, пытаясь достичь определённых целей. Лимит сессий исследовательского тестирования – не более двух часов.

 

Тестуванняконфігурації.

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

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

· Проект по профилированию работы системы

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

· Проект по миграции системы с одной платформы на другую

Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.

Перед началом проведения конфигурационного тестирования рекомендуется:

· создавать матрицу покрытия (матрица покрытия - это таблица, в которую заносят все возможные конфигурации),

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

· шаг за шагом, в соответствии с расставленными приоритетами, проверяют каждую конфигурацию.

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

 

 

Модульнетестування.

Модульное тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно модульное тестирование проводится вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks - каркасы) для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило исправляются в коде без формального их описания в системе менеджмента багов (BugTrackingSystem).

Один из наиболее эффективных подходов к модульному тестированию - это подготовка автоматизированных тестов до начала основного кодирования (разработки) программного обеспечения. Это называется разработка от тестирования (test-drivendevelopment) или подход тестирования вначале (testfirstapproach). При этом подходе создаются и интегрируются небольшие куски кода, напротив которых запускаются тесты, написанные до начала кодирования. Разработка ведется до тех пор пока все тесты не будут успешными.