Техніки, що базуються на специфікаціях.

Щотакетестування?

Тестування програмного забезпечення — це процес, що використовується для виміру якості розроблюваного програмного забезпечення. Зазвичай, поняття якості обмежується такими поняттями, як коректність, повнота, безпечність, але може містити більше технічних вимог Тестування — це процес технічного дослідження, який виконується на вимогу замовників, і призначений для вияву інформації про якість продукту відносно контексту, в якому він має використовуватись. До цього процесу входить виконання програми з метою знайдення помилок.

 

Техніки, що базуються на специфікаціях.

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

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

Альфа та бета тестуваня.

Перед тим, як випускається програмне забезпечення, як мінімум, воно повинне проходити стадії

• альфа (внутрішнє пробне використання) і

• бета (пробне використання із залученням відібраних зовнішніх користувачів) версій.

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

Таблиці прийняття рішень.

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

Такие таблицы представляют логические связи между условиями (могут рассматриваться в качестве “входов”) и действиями (могут рассматриваться как “выходы”). Набор тестов строится последовательным рассмотрением всех возможных кросс-связей в такой таблице.

5. Тесты на основе конечного автомата (Finite-state machine-based)

Общий контекст различных методов тестирования на основе конечных

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

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

Спецификация

• детерминирована;

• минимальна;

• полностью определена;

• сильно связна или имеет действие reset(R), достоверно приводящее из любого состояния в начальное.

От реализации требуется

• детерминизм;

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

• сильная связность или наличие reset;

• согласованность стимулов и реакций со спецификацией — входной и выходной алфавиты реализации те же;

• согласованность начального состояния — в начале работы реализация находится в начальном состоянии;

• ограниченность — число состояний в реализации не превосходит некоторого числа

N

 

6. Стратегія тестування – це схема, яка описує частину тестування циклу розробки програмного забезпечення. Він створений, щоб інформувати керівників проектів, тестерів і розробників про деякі ключові питання в процесі тестування. Це включає в себе тестування цілі методи тестування нових функцій, загальний час і ресурси необхідні для проекту, а також середовища тестування.

В ході випробувань стратегія описує як ризики продукту зацікавлених сторін пом'якшуються на рівні тестування,який тип тесті проводиться на рівні тестування та які вхідні та вихідні критерії застосовуються.

 

Дефект - неправильний крок, процес чи визначення даних в комп'ютерній програмі

¨ Логічні;

¨ Обчислень;

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

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

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

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

 

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

¨ Критичний;

¨ Серйозний;

¨ Значний;

¨ Незначний;

¨ Не дефект.

 

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

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

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

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

¨ Відкласти;

¨ Відхилити.

 

Тестування на основі формальних специфікацій.

 

Тестирование на основе формальной спецификации (Testing from formal specification)

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

 

Случайное тестирование (Random testing)

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

Тестування, орієнтоване на дефекти.

 

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

Предположениеошибок (Errorguessing)

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

Тестированиемутаций (Mutationtesting)

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

SWEBOK фокусируется на возможности, с помощьютестов, определятьотличиямежду мутантами и исходнымвариантомкода. Еслитакоеотличие установлено, мутанта “убивают”, а тест считаетсяуспешным. Обычно, данныйподходфокусируется на синтаксическихошибках, на практикеотслеживаемыхсовременнымисредамиразработки и, конечно, компиляторами.

Тестування мутацій.

Тестирование мутаций

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

Этот метод тестирования фокусируется на возможности, с помощью тестов, определять отличия между мутантами и исходным вариантом кода. Если такое отличие установлено, мутанта “убивают”, а тест считается успешным. Обычно, данный подход фокусируется на синтаксических ошибках, на практике отслеживаемых современными средами разработки и, конечно, компиляторами.

 

12. Оракул. Проблема оракула.

Оракул будь-який (людини або механізм) агент, який вирішує, чи програма вела себе правильно в даному тесті, і, відповідно, виносить рішення про “проходження” або “невдачу”. Існує багато різних видів оракулів, і автомитазація оракула може бути дуже проблематичною або дорогою.

Збої та відмови.

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

Тестування дозволяє виявити відмови, але це дефекти, які можуть і повинні бути видалені.

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

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

Тестирование производительности - это одна из сфер деятельности развивающейся в области информатики Инженерии производительности, которая стремится учитывать производительность на стадии моделирования и проектирования системы, перед началом основной стадии кодирования.

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

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

§ стресс (stress)

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

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

Стрес тестування.

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

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

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

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

Можно выделить два подхода к системному тестированию:

-на базе требований (requirements based)

Для каждого требования пишутся тестовые случаи (test cases), проверяющие выполнение данного требования.

-на базе случаев использования (use case based)

Альфа-тестирование и бета-тестирование являются подкатегориями системного тестирования.

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

 

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

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

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

 

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

· Open/Closed Bugs

Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)

 

· Reopened/ClosedBugs

Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)

· Rejected/OpenedBugs

Метрика показывает отношение количества отклоненных багов к открытым

· BugsbySeverity

Количество багов по серьезности

· BugsbyPriority

Количество багов по приоритету

 

 

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

1. Начинать выполнение тестов с самых важных

a. Проверка правильности работы основных сценариев

b. Выполнение регрессионного тестирования (закрытие исправленных дефектов)

c. Прогон эффективных тестов (например, тестов частей программы, изменявшихся в последней сборке)

2. Лабораторные испытания

a. Подготовить тестовые данные и стенды

3. Помнить что до 80% ошибок будут переоткрыты после исправления

4. Не забывать обновлять сценарии тестирования. Добавлять тесты для новой функциональности, оптимизировать старые тесты.

5. Если остается время после выполнения формального тестирования, заняться исследовательским (неформальным/интуитивным) тестированием.

 

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

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

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

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

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

¨ Виконати кожен предикат

в модулі, для того щоб

оцінити його істинність чи хибність.

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

На заміну аналізаторам коду та генераторам тестових даних для структурного та функціонального тестування, лише працюючих на деяких апаратних та програмних платформах, приходять кросплатформені інструменти підтримки різних методів тестування.

Класифікація

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

c. Надійності;

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

e. Покриття;

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

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

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

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

В статичній фазі код досліджується по

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

Код перевіряється, застосовуючи методи широко відомі як:

¨ Перевірка – покроковий груповий перегляд робочого продукту, де з кожним кроком перевіряються наперед визначені критерії

¨ Покрокове керівництво – це перегляд де автор очолює команду під час пробного або вдаваного виконання продукту з наперед визначеними сценаріями.

Кроки процесу перегляду коду

Спеціалізоване тестування.

Спеціалізоване тестування - цей термін використовується для позначення тестування програмного забезпечення, при якому саме тестування проводиться без планування і документації. Спеціалізоване тестування є неформальним методом тестування. Як такий, цей метод був підданий критиці, оскільки він не структурований і, отже, дефекти, виявлені за допомогою цього методу може бути важче відтворити (оскільки не існує жодних баг-репортів). Тим не менш, сильною стороною спеціального тестування є те, що критичні дефекти можуть бути виявлені дуже швидко. Фактично, таке тестування здійснюється з доллю імпровізації: тестер намагається знайти помилки за допомогою інших засобів, які, здається йому доречними.

40. Критерії завершення тестування.

Об'єктивні критерії завершення тестування ґрунтуються на кількісних вимірах. Існуючі підходи до формування кількісних критеріїв можна розділити на чотири категорії:

· критерії, базовані на метриках покриття;

· критерії, базовані на серйозності дефектів;

· критерії, базовані на оцінках інтенсивності відмов та надійності;

· критерії оптимізації вартості, часу тестування та надійності.

У першому підході критерії встановлюються визначенням допустимих граничних значень метрик покриття (вимог, функцій, коду). Згідно з метриками покриття ці критерії підрозділяють на структурні та функціональні. Тестування припиняють при досягненні встановлених граничних значень. Ці критерії є індикатором повноти виконаного тестування, але не враховують час, витрачений на тестування.

Критерії другої категорії базуються на розподілі виявлених дефектів за ступенем серйозності та встановленні граничних значень кількості усунутих дефектів з урахуванням їхньої серйозності. Згідно з цим підходом тестування припиняють, якщо усунені всі найбільш серйозні дефекти і визначена кількість дефектів інших типів серйозності. Ці критерії відбивають не сам процес тестування (виявлення дефектів), а процес усунення дефектів розробником. Вони не враховують час, витрачений на тестування та усунення дефектів.

В критеріях третьої категорії, базованих на оцінках інтенсивності відмов та надійності, тестування продовжують до тих пір, поки не будуть досягнуті встановлені граничні значення метрик надійності (інтенсивність відмов, середній час функціонування без відмови, або ймовірність безвідмовної роботи). Ці критерії не враховують наслідки відмов для користувача, а лише їх ймовірність [30].

 

 

Планування тестування.

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

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

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

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

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

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

 

Критерії вибору тестів.

Критерии выбора тестов

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

Проведення тестування.

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

¨ Виконати кожен предикат

в модулі, для того щоб

оцінити його істинність чи хибність.

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

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

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

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

 

Порівняльне тестування.

Сравнительное тестирование (Back-to-back testing). Единичный набор тестов, позволяющих сравнить две версии системы.

порівняльне тестування- Якщо стисло, то це випробування аналогічної продукції різних виробників, мета якого — надати споживачу необхідну інформацію про товари й послуги на ринку. Володіючи такою інформацією, споживач не лише реалізує своє право на одержання незалежної, достовірної й компетентної інформації про якість продукції, але й отримує можливість використати своє право на вибір, який здійснює усвідомлено й раціонально на ґрунті наданої йому інформації.

 

Функціональне тестування.

Функціональне тестування – показати, що система веде себе згідно з очікуваннями користувачів (відповідність вимог)

Функциональные требования включают:

• Функциональная пригодность
• Точность
• Способность к взаимодействию
• Соответствие стандартам и правилам
• Защищённость

 

 

Тестування Web-застосувань.

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

 

3 рівні тестування Web-застосування.

 

· модульное тестирование;

· интеграционное тестирование;

· системное тестирование;

Проблеми оракула.

Ø Оракул будь-який (людини або механізм) агент, який вирішує, чи програма вела себе правильно в даному тесті, і, відповідно, виносить рішення про “проходження” або “невдачу”. Існує багато різних видів оракулів, і автомитазація оракула може бути дуже проблематичною або дорогою.

Тестування інсталяцій.

¨ З назви випливає, що дані тести проводяться з метою перевірки процедури інсталяції системи в цільовому оточенні.

(інфа з лекції)

Метод білої скриньки.

¨ Знання про програмний компонент/структуру

¤ Контрольний список виразів чи компонентів

¤ Тестування шляхів у коді (потік управління)

¤ Тестування залежності по даним (потоки даних)

¨ Застосування

¤ Тестування на ранніх стадіях

¤ Подвійна роль програміста – тестувальника

¨ Критерій зупинки

¤ В основному задачі покриття

¤ Інколи інші задачі по якості та надійності

 

Метод чорної скриньки.

¨ Поведінка на вході/виході

Ø Контрольний список із специфікації

Ø Тестування очікуваної поведінки

Ø Кінцеві автомати

¨ Застосування

Ø Застосовують на пізніх стадіях розробки

Ø Підходить як для верифікації так і валідації

Ø Сумісна з ОО програмуванням та повторним використанням

¨ Критерій зупинки

Ø Традиційний – на основі покриття

Ø На основі використання

 

Цілі тестування.

 

Цілі (види) тестування

 

Тестування проводиться для того, щоб

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

Перевірити створений продукт на відповідність вимогам і специфікаціям

Виявити можливі приховані дефекти ПО

· Приймальне тестування (Прийом / кваліфікаційних випробувань). Перевіряє поведінку системи на предмет задоволення вимог замовника.

· Установочное тестування (установка тестування). З назви випливає, що дані тести проводяться з метою перевірки процедури інсталяції системи в цільовому оточенні.

· Альфа-і бета-тестування (Альфа-і бета-тестування). Перед тим, як виробляється, програмне забезпечення, як мінімум, воно має проходити стадії альфа (внутрішнє пробне використання) і бета (пробне використання з залученням відібраних зовнішніх користувачів) версій.

· Функціональні тести / тести відповідності (тестування відповідності / Функціональне тестування / Коректність тестування). Ці тести можуть називатися по-різному, проте, їх суть проста - перевірка відповідності системи, що пред'являються до неї вимогам, описаним на рівні специфікації поведінкових характеристик.

· регресійне тестування

· тестування продуктивності

· Навантажувальне тестування

 

Метод сірої скриньки.

При тестуванні сірого ящика розробник тесту має доступ до вихідного коду, але при безпосередньому виконанні тестів доступ до коду, як правило, не потрібно.

Воно знаходиться в прикордонному стані між білим і чорним ящиком, тому його і називають сірим. Поєднання відбувається таким чином: зовні на продукт дивимося як на чорний ящик, але вибір тестів засновуємо на знанні внутрішнього устрою програми, знанні її коду. Цей метод часто використовується для тестування на веб-додатків.

 

Сіра скринька (змішане тестування)

Ø Більшість тестів середнього рівня.

Ø Приклад: процедури у модулях.

Ø Індивідуальні процедури як чорні скриньки

Ø Зв'язки між процедурами – біла скринька на рівні модуля

Регресійне тестування.

Якщо система успішно проходила тести до внесення модифікацій, вона повинна їх проходить і після внесення таких.

Основна проблема регресійного тестування
полягає в пошуку компромісу між наявними ресурсами та необхідністю проведення таких тестів у міру внесення кожної зміни.

Завдання полягає в тому, щоб визначити критерії "масштабів" змін, з досягненням яких необхідно проводити регресійні тести.

 

Інтеграційне тестування.

Інтеграційне тестування – тестування архітектури

Даний рівень тестування є процесом перевірки взаємодії між програмними компонентами / модулями.

Класичні стратегії інтеграційного тестування - "зверху-вниз" та "знизу-вгору“, “монолітне”.

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

1. "зверху-вниз" - Відбувається поступова інтеграція модулів