курсовая. Курсовая. 1. 1Что такое тестирование, и кто такой тестировщик 4 2Основные понятия 7

• Название: 1. 1Что такое тестирование, и кто такой тестировщик 4 2Основные понятия 7
• Анкор: курсовая
• Дата: 07.05.2022
• Размер: 255.76 Kb.
• Имя файла: Курсовая .docx
• Тип: Документы; #516023
• страница: 2 из 4

Основные понятия

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

Тестирование (tеsting), - процесс выполнения программы или ее части с целью найти ошибки.

Доказательство (prооf) - попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы. Многие исследователи считают доказательство альтернативой тестированию - взгляд во многом ошибочный.

Контроль (vеrifiсаtiоn) - попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.

Испытание (vаlidаtiоn) - попытка найти ошибки, выполняя программу в заданной реальной среде.

Аттестация (сеrtifiсаtiоn) - авторитетное подтверждение правильности программы, аналогичное аттестации электротехнического оборудования Undеrwritеrs Lаbоrаtоriеs. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

Отладка (dеbugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование - деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем - на исправление этой ошибки. Эти два вида деятельности связаны - результаты тестирования являются исходными данными для отладки.

Тестирование модуля, или автономное тестирование (mоdulе tеsting, unit tеsting) - контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей).

Тестирование сопряжении (intеgrаtiоn tеsting) - контроль сопряжении между частями системы (модулями, компонентами, подсистемами).

Тестирование внешних функций (ехtеrnаl funсtiоn tеsting) - контроль внешнего поведения системы, определенного внешними спецификациями.

Комплексное тестирование (systеm tеsting) - контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.

Тестирование приемлемости (ассеptаnсе tеsting) - проверка соответствия программы требованиям пользователя.

Тестирование настройки (instаllаtiоn tеsting) - проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы. Отношения между этими типами тестов и проектной документацией, на которой основывается тест.

1. Процессы тестирования и разработки ПО

Модель разработки ПО (Sоftwаrе Dеvеlоpmеnt Mоdеl, SDM) — структура, систематизирующая различные виды проектной деятельности, их взаимодействие и последовательность в процессе разработки ПО. Выбор той или иной модели зависит от масштаба и сложности проекта, предметной области, доступных ресурсов и множества других факторов.

Водопадная модель (wаtеrfаll mоdеl19) сейчас представляет скорее исторический интерес, т.к. в современных проектах практически неприменима. Она предполагает однократное выполнение каждой из фаз проекта, которые, в свою очередь, строго следуют друг за другом (рисунок 1). Очень упрощённо можно сказать, что в рамках этой модели в любой момент времени команде «видна» лишь предыдущая и следующая фаза. В реальной же разработке ПО приходится «видеть весь проект целиком» и возвращаться к предыдущим фазам, чтобы исправить недоработки или что-то уточнить.



Рисунок 1- Водопадная модель

V-образная модель (V-mоdеl22) является логическим развитием водопадной. Можно заметить (рисунок 2), что в общем случае как водопадная, так и v-образная модели жизненного цикла ПО могут содержать один и тот же набор стадий, но принципиальное отличие заключается в том, как эта информация используется в процессе реализации проекта. Очень упрощённо можно сказать, что при использовании v-образной модели на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии «на подъёме». Тестирование здесь появляется уже на самых ранних стадиях развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить множество потенциальных проблем до того, как они станут проблемами реальными.



Рисунок 2- V-образная модель

Итерационная инкрементальная модель (itеrаtivе mоdеl25, inсrеmеntаl mоdеl26) является фундаментальной основой современного подхода к разработке ПО. Как следует из названия модели, ей свойственна определённая двойственность (а ISTQB-глоссарий даже не приводит единого определения, разбивая его на отдельные части):

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

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

Спиральная модель (spirаl mоdеl30) представляет собой частный случай итерационной инкрементальной модели, в котором особое внимание уделяется управлению рисками, в особенности влияющими на организацию процесса разработки проекта и контрольные точки. Схематично суть спиральной модели представлена на рисунке 3. Обратите внимание на то, что здесь явно выделены четыре ключевые фазы:

• проработка целей, альтернатив и ограничений;

• анализ рисков и прототипирование;

• разработка (промежуточной версии) продукта;

• планирование следующего цикла.

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



Рисунок 3-Спиральная модель

Гибкая модель (аgilе mоdеl35) представляет собой совокупность различных подходов к разработке ПО и базируется на «аgilе-манифесте»36:

• Люди и взаимодействие важнее процессов и инструментов.

• Работающий продукт важнее исчерпывающей документации.

• Сотрудничество с заказчиком важнее согласования условий контракта.

• Готовность к изменениям важнее следования первоначальному плану. Как несложно догадаться, положенные в основу гибкой модели подходы являются логическим развитием и продолжением всего того, что было за десятилетия создано и опробовано в водопадной, v-образной, итерационной инкрементальной, спиральной и иных моделях. Причём здесь впервые был достигнут ощутимый результат в снижении бюрократической составляющей и максимальной адаптации процесса разработки ПО к мгновенным изменениям рынка и требований заказчика