Q какие компоненты надо тестировать.

Отказ (Failure). Прекращение способности функционального узла к выполнению предопределенной функции. Отказ должен определяться системой, иметь возможность исправления или замены on-line без воздействия на функциональность системы как до, так и после восстановления (замены).

Классификация и характеристики отказов:

1. По типу отказы подразделяются на:
• отказы функционирования (выполнение основных функций объектом прекращается)
• отказы параметрические (некоторые параметры объекта изменяются в недопустимых пределах)
2. По своей природе отказы могут быть:
• случайные, обусловленные непредусмотренными перегрузками, дефектами материала, ошибками персонала или сбоями системы управления и т. п.;
• систематические, обусловленные закономерными и неизбежными явлениями

 

1. Тестування продуктивності.

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

В тестировании производительности различают следующие направления:

нагрузочное (load)

стресс (stress)

тестирование стабильности (endurance or soak or stability)

конфигурационное (configuration)

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

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

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

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

 

 

1. Стрес-тести

Стресс-тестирование (англ. Stress Testing) — один из видов тестирования ПО, которое оценивает надежность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс-тестирование особенно необходимо для "критически важного" ПО, однако также используется и для остального ПО. Обычно стресс-тестирование лучше обнаруживает устойчивость, доступность и обработку исключений системой под большой нагрузкой, чем то, что считается корректным поведением в нормальных условиях.В общем случае методология стресс-тестирования основана на снятии и анализе показателей производительности приложения при нагрузках, значительно превышающих ожидаемые на стадии сопровождения и несёт в себе цель определить выносливость или устойчивость приложения на случай всплеска активности по его использованию.Необходимость стресс-тестирования диктуется следующими факторами:Большая часть всех систем разрабатываются с допущением о функционировании в нормальном режиме и даже в случае, когда допускается возможность увеличения нагрузки, реальные объёмы её увеличения не принимаются во внимание.Основные направления применения стресс-тестирования:1. Общее исследование поведения системы при пиковых нагрузках.

2. Исследование обработки ошибок и исключительных ситуаций системой при пиковых нагрузках.3. Исследование узких мест системы или отдельных компонент при диспропорциональных нагрузках.4. Тестирование ёмкости системы

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

1. Системне тестування.

1.Системне тестування охоплює повністю всю систему.2.Більшість функціональних збоїв ідентифіковано ще на рівні модульних та інтеграційних тестів.3.Системне тестування фокусується на нефункціональних вимогах - безпеки, продуктивності, точності, надійності.4.На цьому рівні також тестуються інтерфейси до зовнішніх додатків, апаратного забезпечення, операційному середовищі і т.д.

5.Види:1.Функціональне тестування – показати, що система веде себе згідно з очікуваннями користувачів (відповідність вимог)2.Тестування продуктивності – перевірка, щоб система забезпечувала заданий рівень продуктивності при обробці запитів. Виявляються “вузькі” місця в системі.3.Нагрузочне (стресове) тестування – оцінка продуктивності та стійкості системи у випадках максимальних навантажень

4.Тестування конфігурації – перевірка роботи системи на різному апаратному забезпеченні з різними програмними засобами

5.Тестування зручності використання

¨ Види (продовження):

¨ Тестування безпеки – перевіряється недоступність захищених даних та можливість несанкціонованого доступу

¨ Тестування надійності та відновлення після збоїв – імітуються збої, та перевіряється відновлюваність системи та даних

¨ Тестування зручності використання – перевіряється в першу чергу інтерфейс

1. Методології покращення якості.

 

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

• методология реинжиниринга;

• методология бенчмаркинга;

• методология «Шесть сигм»;

• методология (методы, подходы) Гэнити Тагути;

• методология самооценки;

• методология решения проблем.

 

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

 

Вимірювання результатів тестування

¨ Оцінювання продукту здійснюється за допомогою метрик:

¤ Підрахунку дефектів;

¤ Тенденції дефектів;

¤ Надійності;

¤ Процесу тестування;

¤ Покриття;

¤ Структурного покриття;

¤ Функціонального покриття;

¤ Динаміки виявлення дефектів.

 

 

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

 

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

 

 

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

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

Тесты, базирующиеся на блок-схеме (Control-flow-based criteria)

Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов.

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

Тесты на основе потоков данных (Data-flow-based criteria)

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

Ссылочные модели для тестирования, ориентированного на код (Reference models for code-based testing – flowgraph, call graph)

Является не столько техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов (например, sequence-диаграммы, определенной в нотации UML и построенной на основе анализа кода).

1. Відстеження та видалення дефектів.

 

¨ 1) Виявлення дефектів не застосовуючи жодних прийомів

¨ 2) Використання різних контрольних списків для гарантії покриття важливих частин документів

¤ Контрольні списки по робочим продуктам – перевірка основних функцій, структур даних, визначень даних компонентів

¤ Контрольні списки по властивостям – перевірка стилів коду, відповідність стандартам, зв'язаності та залежностей модулів

¨ 3) Сценарії використання системи застосовуються для управління пошуком дефектів, що об'єднує декілька компонентів ПЗ

 

1. Типи дефектів та їх класифікація.

Аспекти класифікацій дефектів:

¨ Симптом;

¨ Серйозність;

¨ Пріоритет усунення;

¨ Стадія розробки та джерело;

¨ Тип.

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

¨ Аварійне завершення програми;

¨ Несподівана поведінка програми;

¨ “ Зависання ” програми;

¨ Проблема вводу:

¤ Коректні дані не вводяться;

¤ Неправильні дані вводяться;

¤ Опис даних відсутній / невірний;

¤ Параметри не повні / відсутні;

¨ Проблема виводу:

¤ Невірний формат;

¤ Невірні результати / дані;

¤ Неповний / відсутній вивід;

¤ Граматика / синтаксис;

¨ Незадовільна продуктивність;

¨ Відчуття загального відказу продукту;

¨ Повідомлення про помилку системи.

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

¨ Критичний;

¨ Серйозний;

¨ Значний;

¨ Незначний;

¨ Не дефект.

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

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

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

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

¨ Відкласти;

¨ Відхилити.

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

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

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

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

¨ Логічні;Обчислень;Інтерфейсу;

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

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

1. Дослідне тестування.

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

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

 

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

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

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

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

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

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

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

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

 

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

Цей рівень тестування дозволяє перевірити функціонування окремо взятого елемента системи. Немає чітко визначеного означення модуля. Прикладами широко використовуваних означень є: клас, функція, процедура чи метод. Найбільш повно даний вид тестів описаний у стандарті IEEE 1008-87 "Standard for Software Unit Testing", що задають інтегровану концепцію систематичного і документованого підходу до модульного тестування.

Причини для модульного тестування в автономній манері:

1.Знайдена помилка асоціюється з визначеного модулю і так її легше виправити

2.Під час тестування бажано перевіряти чи приносить виконання певного модуля бажані результати. В ідеалі виконання всіх можливих (або максимально можлива кількість) випадків повинне бути розглянуто підчас тестування. Це вимагає обережно обирати вхідні дані для кожного виконання.

Як потрібно тестувати програму

1.Виконати кожну стрічку коду. За відсутності такого спостереження, сюрпризи можуть дуже дорого коштувати.

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

3.Важливим є виконання модулем своїх функцій та забезпечення відсутності в них відомих помилок.

Попередньо проведене модульне тестування не дає гарантій що програма буде працювати вірно в цілому. Але це не означає що його не потрібно проводити. Немає сенсу інтегрувати помилкові модулі через такі причини:

1.Багато з наступних тестів будуть марною тратою ресурсів

2.Пошук корінних причин невдач у інтегрованої системи є більш ресурсномістким.

 

1. Тестування зручності використання (usability).

Тестирование удобства пользования - это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.

Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

*производительность, эффективность (efficiency) - сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.? (меньше - лучше)

*правильность (accuracy) - сколько ошибок сделал пользователь во время работы с приложением? (меньше - лучше)

*активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее чем у нового пользователя)

*эмоциональная реакция (emotionalresponse) – как пользователь себя чувствует после завершения задачи - растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция - лучше)

 

1. Звіти по помилках.

 

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

Короткое описание проблемы; название тестируемого проекта; компонент приложения, где была найдена ошибка; номер версии тестируемого ПО; серьезность бага; приоритет бага; автор баг-репорта; спецификация системы на которой был найден баг; шаги воспроизведения; результат выполнения перечисленных выше шагов; результат, который ожидался

 

 

1. Метрики дефектів.

 

- Плотность дефектов (500 = Число дефектов / Размер юода)

- Плотность дефектов после поставки (РООО = Число дефектов

после поставки / Размер кода)

- Доля отклоненных дефектов (ВПК = Число отклоиеииых

дефектов / Число дефектов)

- «Убойность» тестов (ОР = Число дефектов / Число тестов)

- Эффективность тестирования (ТЕ = Число дефектов / Трудозатраты тестирования)

- Доля покрытия требований (КСК = Число требований,

покрытых тестами / Число требований)

- Плотность покрытия требований (КСО = Число тестов / Число

требований)

- доля повторно открытых дефектов (КОК = Число повторно

открытых дефектов / Число дефектов)

- И много-много других

 

° Lifetime - распределение дефектов по их продолжительности жизни в проекте

° Detection time - распределение дефектов по времени их обнаружения

в жизненном цикле проекта, релиза или программного продукта.

° Submitted vs Resolved - временное распределение количества

дефектов со статусом Submitted и со статусом Resolved

° Resolved vs Validated - временное распределение количества

дефектов со статусом Resolved и со статусом Validated

° Reopened - временное распределение количества дефектов со

статусом Reopened

° Zero-defects data - прогноз даты, к которой идентифицированные при системном тестировании дефекты будут закрыты.

 

1. Тестування графічного інтерфейсу користувача.

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

Тестирование на соответствие стандартам графических интерфейсов;

Тестирование с различными разрешениями экрана;

Тестирование в ограниченных условиях, например, в условиях нехватки памяти;

Совместимость с различными Интернет-браузерами;

Тестирование локализованных версий: точность перевода, проверка длины названий элементов интерфейса и т.д.;

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

1. Метрики динаміки знаходження дефектів.

Метрики якості процесів

• Вимірювання частоти дефектів під час тестування – чим більше дефектів виявлено під час тестування, тим більше їх буде при використанні

• Вимірювання динаміки виявлення дефектів на протязі часу

• Вимірювання дефектів по фазах життєвого циклу

Ефективність видалення дефектів (DRE)

 

 

1. Розробка, керована тестуванням (Test-driven development).

Разработка через тестирование (test-driven development, TDD) — техникаразработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест и под конец проводится рефакторинг нового кода к соответствующим стандартам. Разработка через тестирование требует от разработчика создания автоматизированных модульных тестов, определяющих требования к коду непосредственно перед написанием самого кода. Тест содержит проверки условий, которые могут либо выполняться, либо нет. Когда они выполняются, говорят, что тест пройден. Прохождение теста подтверждает поведение, предполагаемое программистом. Разработчики часто пользуются библиотеками для тестирования (testing frameworks) для создания и автоматизации запуска наборов тестов. На практике модульные тесты покрывают критические и нетривиальные участки кода. Это может быть код, который подвержен частым изменениям, код, от работы которого зависит работоспособность большого количества другого кода, или код с большим количеством зависимостей. Среда разработки должна быстро реагировать на небольшие модификации кода. Архитектура программы должна базироваться на использовании множества сильно связанных компонентов, которые слабо сцеплены друг с другом, благодаря чему тестирование кода упрощается.

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

Разумеется, к тестам применяются те же требования стандартов кодирования, что и к основному коду.

1. Виконання тестів.

q Планування тестування:

Ø Цільове налаштування на основі перспектив та очікувань клієнтів по якості

Ø Загальна стратегія на онові характеристик продукту/оточення

q Підготовка тестування:

Ø Підготовка тестових випадків та наборів– зазвичай на основі формальних моделей

Ø Підготовка процедури випробувань

 

¨ Головні кроки виконання тесту:

Ø Виділення часу на тест (та ресурси)

Ø Застосування тесту

Ø Виявлення відмов систем (та збір інфомаціі для подальших дій)

q Ключ до виконання: Обробка обох нормальних та ненормальних випадків

q Oracle Проблема тестування

q Аналіз результатів тестування:

q Перевірка результату (як частина виконання)

q Подальший аналіз результатів – аналіз на дефекти/надійність і т.д.

q Інші аналізи: кількість дефектів та інші метрики

1. Модель процесу тестування.

 

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

• Контрольная задача – набор тестовых данных, условий выполнения тестов и ожидаемых результатов.
• Методика испытаний – документ, содержащий указания по настройке и выполнению контрольных задач, а также по оценке получаемых результатов.
• Сценарий тестирования – это упрощенное описание теста, включая исходные данные, условия и последовательности выполнения действий и ожидаемые результаты.
• Тестовый скрипт является программой, выполняемой при автоматическом тестировании с помощью инструментальных средств тестирования.
• Описание взаимодействия тестов представляет собой диаграмму последовательностей или коопераций, отражающую упорядоченный во времени поток сообщений между компонентами тестов и объектом тестирования.

 

 

1. Управління тестуванням.

 

Главные принципы

Целью менеджмента качества(SQM) является управление качеством программного обеспечения и процесса его развития.

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

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

 

Весь процесс управления качеством можно разбить на 3 уровня:

1. Обеспечение качества программного продукта

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

Наличие базы лучших практик достижения качества

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

2. План достижения качества

Для каждого разрабатываемого проекта должен быть написан план по достижению качества, который необходим, чтобы регулировать применение тех средств, которые описаны выше

3. Контроль качества ПО

Обучение персонала созданию четко формализованных инженерных документов с использованием стандартных шаблонов

Обучение персонала тому, как проводить стандартные процессы управления качеством

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

 

 

1. Інструменти тестування.

¨ Класифікація інструментів тестування

¨ Інструменти керування тестуванням

¤ Менеджери конфігурацій та проекту

¨ Інструменти, підтримуючі аналіз вимог та проекту

¤ Аналізатори планів, вимог та проектів

¤ Розробники прототипів/емулятори системи

¤ Інструменти тестування вимог

¤ Планувальники тестів

¨ Класифікація інструментів тестування

¨ Інструменти підтримки тестування на етапі реалізації та супроводу

¤ Статичні аналізатори вихідного коду

¤ Інструменти підготовки тестів

¤ Інструменти виконання тестів

¤ Оцінювачі тестів

¨ Інструменти керування тестуванням

Менеджери конфігурації - відстежують і контролюють внесення змін до ПС на протязі її розробки та супроводу і підтримують цілісність розроблених і поставляються версій ПС.

Менеджери проекту - підтримують функції планування та відстеження на етапах розробки та супроводу системи (оцінювання термінів, ресурсів, побудова мережевих графіків і ін.)

¨ Інструменти, підтримуючі аналіз вимог та проекту

¨ Аналізатори планів, вимог і проектів - оцінюють специфікації на повноту, несуперечність і відповідність встановленим стандартам для специфікацій.

¨ Будівники прототипів/емулятори системи - об'єднують дії з тестування з діями з аналізу та проектування і дозволяють швидко промоделювати вимоги та проектні рішення.

¨ Інструменти, підтримуючі аналіз вимог та проекту

¨ Інструменти трасування вимог - дозволяють встановити зв'язки вимог до проекту, кодом і тестами.

¨ Планувальники тестів - підтримують процес планування тестування на всіх його рівнях.

¨ Статичні аналізатори вихідного коду

¨ Аудитори - аналізують код на відповідність стандартам кодування та встановленим правилам.

¨ Вимірювачі складності - обчислюють метрики коду для визначення атрибутів складності шляхом оцінювання таких характеристик коду, як потік управління, операнди / оператори, дані, структура системи.

¨ Інструменти генерації перехресних посилань - забезпечують посилання між різними сутностями (змінними).

¨ Вимірювачі розміру - обчислюють число рядків вихідного коду (SLOC).

¨ Інструменти підготовки тестів

¨ Екстрактори даних - будують тести, витягуючи інформацію з існуючих баз даних або тестових наборів.

¨ Генератори тестів за специфікацією вимог - будують тести за вимогами, написаним на формальному мові специфікації.

¨ Генератори тестових даних (за різними методами) - генерують вхідні дані для тестування відповідно до методу, реалізованим в інструменті.

¨ Планувальники тестів - підтримують розробку та ведення планів тестування.

¨ Інструменти виконання тестів

¨ Динамічні аналізатори покриття - оцінюють покриття коду тестами по відношенню до операторів, шляхам або модулів.

¨ Інструменти захоплення / програвання - автоматично записують дії тестувальника при виконанні програми у вигляді автоматичної тестової процедури і потім відтворюють ці дії.

¨ Відладчики - безпосередньо підтримують автономне тестування, хоча їх призначення - пошук і усунення помилок (налагодження).

¨ Емулятори - можуть застосовуватися замість відсутніх компонентів системи.

¨ Інструменти виконання тестів

¨ Аналізатори мережі - призначені для аналізу трафіку мережі.

¨ Аналізатори продуктивності - відстежують тимчасові характеристики системи або її компонентів.

¨ Аналізатори помилок періоду виконання - відстежують роботу програми на наявність помилок, пов'язаних із захопленням-звільненням пам'яті, нульовими покажчиками і т.п.

¨ Інструменти управління виконанням тестів - автоматизують різні функції налаштування та виконання тестів, очищення системи після виконання тестів.

¨ Оцінювачі тестів

¨ Компаратори - порівнюють результати тестування і виявляють відхилення. Інструменти захоплення / програвання зазвичай мають у своєму складі такі компоненти.

¨ Конвертори та аналізатори даних - конвертують дані в зручний для інтерпретації формат і виконують різні види статистичного аналізу цих даних.

¨ Трасувальник дефектів / змін - зберігають інформацію про дефекти і генерують звіти. Зазвичай входять до складу систем управління конфігурацією і інструментів управління тестуванням.

 

 

1. Метрики покриття.

Покры́тие ко́да — мера, используемая при тестировании программного обеспечения. Она показывает процент, насколько исходный код программы был протестирован.

Существует несколько различных способов измерения покрытия, основные из них:

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

Для программ с особыми требованиями к безопасности часто требуется продемонстрировать, что тестами достигается 100 % покрытие для одного из критериев. Некоторые из приведённых критериев покрытия связаны между собой; например, покрытие путей включает в себя и покрытие условий и покрытие операторов.

 

 

1. Статистичне тестування.

 

— Статистическое тестирование (statistics-driven testing); проводится выборочно, чтобы проверить, как долго или насколько хорошо может выполняться программа.

 

1. Класифікація інструментів тестування.

¨ Класифікація інструментів тестування

¨ Інструменти керування тестуванням

¤ Менеджери конфігурацій та проекту

¨ Інструменти, підтримуючі аналіз вимог та проекту

¤ Аналізатори планів, вимог та проектів

¤ Розробники прототипів/емулятори системи

¤ Інструменти тестування вимог

¤ Планувальники тестів

¨ Класифікація інструментів тестування

¨ Інструменти підтримки тестування на етапі реалізації та супроводу

¤ Статичні аналізатори вихідного коду

¤ Інструменти підготовки тестів

¤ Інструменти виконання тестів

¤ Оцінювачі тестів

¨ Інструменти керування тестуванням

Менеджери конфігурації - відстежують і контролюють внесення змін до ПС на протязі її розробки та супроводу і підтримують цілісність розроблених і поставляються версій ПС.

Менеджери проекту - підтримують функції планування та відстеження на етапах розробки та супроводу системи (оцінювання термінів, ресурсів, побудова мережевих графіків і ін.)

¨ Інструменти, підтримуючі аналіз вимог та проекту

¨ Аналізатори планів, вимог і проектів - оцінюють специфікації на повноту, несуперечність і відповідність встановленим стандартам для специфікацій.

¨ Будівники прототипів/емулятори системи - об'єднують дії з тестування з діями з аналізу та проектування і дозволяють швидко промоделювати вимоги та проектні рішення.

¨ Інструменти, підтримуючі аналіз вимог та проекту

¨ Інструменти трасування вимог - дозволяють встановити зв'язки вимог до проекту, кодом і тестами.

¨ Планувальники тестів - підтримують процес планування тестування на всіх його рівнях.

¨ Статичні аналізатори вихідного коду

¨ Аудитори - аналізують код на відповідність стандартам кодування та встановленим правилам.

¨ Вимірювачі складності - обчислюють метрики коду для визначення атрибутів складності шляхом оцінювання таких характеристик коду, як потік управління, операнди / оператори, дані, структура системи.

¨ Інструменти генерації перехресних посилань - забезпечують посилання між різними сутностями (змінними).

¨ Вимірювачі розміру - обчислюють число рядків вихідного коду (SLOC).

¨ Інструменти підготовки тестів

¨ Екстрактори даних - будують тести, витягуючи інформацію з існуючих баз даних або тестових наборів.

¨ Генератори тестів за специфікацією вимог - будують тести за вимогами, написаним на формальному мові специфікації.

¨ Генератори тестових даних (за різними методами) - генерують вхідні дані для тестування відповідно до методу, реалізованим в інструменті.

¨ Планувальники тестів - підтримують розробку та ведення планів тестування.

¨ Інструменти виконання тестів

¨ Динамічні аналізатори покриття - оцінюють покриття коду тестами по відношенню до операторів, шляхам або модулів.

¨ Інструменти захоплення / програвання - автоматично записують дії тестувальника при виконанні програми у вигляді автоматичної тестової процедури і потім відтворюють ці дії.

¨ Відладчики - безпосередньо підтримують автономне тестування, хоча їх призначення - пошук і усунення помилок (налагодження).

¨ Емулятори - можуть застосовуватися замість відсутніх компонентів системи.

¨ Інструменти виконання тестів

¨ Аналізатори мережі - призначені для аналізу трафіку мережі.

¨ Аналізатори продуктивності - відстежують тимчасові характеристики системи або її компонентів.

¨ Аналізатори помилок періоду виконання - відстежують роботу програми на наявність помилок, пов'язаних із захопленням-звільненням пам'яті, нульовими покажчиками і т.п.

¨ Інструменти управління виконанням тестів - автоматизують різні функції налаштування та виконання тестів, очищення системи після виконання тестів.

¨ Оцінювачі тестів

¨ Компаратори - порівнюють результати тестування і виявляють відхилення. Інструменти захоплення / програвання зазвичай мають у своєму складі такі компоненти.