22. Ручной контроль как метод тест-ия.* *

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

Основными методами ручного контроля явл:

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

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

- участникам группы заранее выдают листинг прог-ы и спецификацию на нее;

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

- участники заседания мысленно выполняют каждый тест в соответствии с логикой прог-ы, при этом состояние прог-ы (значения переменных) отслеживается на бумаге или доске;

- при необходимости прог-исту задают вопросы о логике проектирования и принятых допущениях.)

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

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

20. Ф-ональное и стр-ное тест-ие прог-: цели, отличия стратегий, рекомендации по применению.*

29. Стр-ное прог-ирование. Определение подхода, цель и принципы.*

23. Методы стр-ного тест-ия. Общий недостаток методов.* //белый ящик

24. Методы ф-онального тест-ия. Области применения.* //черный ящик

25. Основные положения метода эквивалентного разбиения.*

1.Назовите цель разбиения исх-х д-х прог- на классы эквивалентности. Приведите пример выделения классов эквивалентности для какой-либо задачи * *

20. Ф-ональное и стр-ное тест-ие прог-: цели, отличия стратегий, рекомендации по применению.*

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

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

Стр-ный подход базируется на том, что известна стр-а тест-ого прог-ного обеспечения, в том числе его алгоритмы («стеклянный ящик»). В этом случае тесты строят так, чтобы проверить правильность реализации зад-ой логики в коде прог-ы.

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

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

Ф-ональный подход основывается на том, что стр-а прог-ного обеспечения не известна («черный ящик»). В этом случае тесты строят, опираясь на ф-ональные спецификации. этот подход наз-этот также подходом, управляемым д-ыми, так как при его использовании тесты строят на базе различных способов ДЕКи множ-ва д-х. Наборы тестов, полученные в соответствии с методами этих подходов, обычно объединяют, обеспечивая всестороннее тест-ие прог-ного обеспечения.

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

При проектировании ф-ональных тестов, надлежит выполнить следующие рекомендации

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

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

29. Стр-ное прог-ирование. Определение подхода, цель и принципы.*

Структу́рное программи́рование — парадигма программирования, в основе которой лежит представление программы в виде иерархической структуры блоков.

Цель стр-ного прог-ирования – разработка прог-ы, к-й присуща определенная стр-а, основанная на применении принципов стр-ного прог-ирования Перечислим эти принципы:

1Каждый прог-ный МОД (блок, ф-я, процедура) должен иметь только один вход и один выход. позволяет максимально упростить стыковку МОД в прог-е.

2В прог-ах рекомендуется применять 4 типа конструкций:

а) послед-ость (МОД, операторов)