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

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

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

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

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

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

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

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

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

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

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

автоматов.

Рассматривается описание требований к поведению тестируемой системы,

представленное в виде конечного автомата, называемого спецификацией. Реальное

поведение тестируемой системы, со всеми имеющимися в ней ошибками, также может быть

полностью смоделировано конечным автоматом, называемым реализацией. Реализация

неизвестна, известно только, что это конечный автомат, удовлетворяющий ряду условий.

Задача состоит в построении как можно более компактного набора тестов — входных

последовательностей (и соответствующих им в спецификации выходных), — позволяющих

отличить реализацию от спецификации всякий раз, когда они не эквивалентны.

Соответственно, если поведение реализации на этом наборе тестов не будет отличаться от

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

На спецификацию и реализацию накладываются дополнительные ограничения.

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

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

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

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

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

состояния в начальное.

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

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

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

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

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

алфавиты реализации те же;

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

начальном состоянии;

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

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

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

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

¨ Логічні;

¨ Обчислень;

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

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

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

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

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

¨ Критичний;

¨ Серйозний;

¨ Значний;

¨ Незначний;

¨ Не дефект.

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

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

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

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

¨ Відкласти;

¨ Відхилити.

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

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

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

Наши рекомендации