34 Основные принципы тестирования программ. Заповеди по тестированию, предложенные г. Майерсом. Методы тестирования, два подхода к тестированию.

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

Тестирование – процесс многократного повторения программы с целью обнаружения ошибок. Тестирование – составная часть отладки.

Заповеди, предложенные Майерсом, по тестированию ПС.

• Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу;

• Заповедь 2. Хорош тот\ тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы;

• Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных;

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

• Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование;

• Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Существуют следующие методы тестирования ПС:

1. Статическое тестирование – ручная проверка программы за столом.

2. Детерминированное тестирование – при различных комбинациях исходных данных.

3. Стохастическое – исходные данные выбираются произвольно, на выходе определяется качественное совпадение результатов или примерная оценка.

Имеется два подхода к тестированию:

1. Структурное тестирование – метод «белого ящика», тестируется логика программы, внутренняя структура программы.

2. Функциональное тестирование – метод «черного ящика»- тестируется спецификация, т.е. вход/выход без учета знаний о ее структуре.

Структурное тестирование

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

Тестируются блоки ветвлений, циклы и т.д.

Существует несколько типов структурного тестирования:

• покрытие операторов;

• покрытие решений;

• покрытие решений / условий;

• комбинаторное покрытие условий;

• тестирование циклов.

Функциональное тестирование

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

Существуют несколько видов функционального тестирования:

• эквивалентные классы;

• анализ граничных значений;

• тестирование на предельных нагрузках;

• тестирование на предельных объемах;

• тестирование защиты;

• эксплуатация системы самим разработчиком (если возможно);

• опытная эксплуатация.

35 Тестирование модулей: тестирование путей, структур управления, ветвлений, специальных значений (примеры).

1. Тестирование путей — самая подробная проверка — должны быть выялены всевозможные пути прохождения по модулю;

рисунок

2. Тестирование структуры управления;

При тестировании управляющих структур считается, что одного прохода по циклу достаточно.

3. Тестирование ветвлений — анализируются точки ветвления управляющего графа;

4. Тестирование специальных значений — деление на ноль, потеря значимости и так далее;

36 Автономная отладка ПС. Комплексная отладка ПС.

В нашей стране различаются два основных вида отладки (включая тестирование): автономную и комплексную отладку ПС.

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

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

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

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

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

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

Достоинства восходящего тестирования:

1. Простота подготовки тестов;

2. Возможность полной реализации плана тестирования модуля.

Недостатки восходящего тестирования:

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

2. Большой объем отладочного программирования;

3. Необходимость специального тестирования сопряжения модулей.

Достоинства нисходящего тестирования:

1. Большинство тестов готовится в форме, рассчитанной на пользователя;

2. Во многих случаях относительно небольшой объем отладочного программирования;

3. Отпадает необходимость тестирования сопряжения модулей.

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

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

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

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

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

Весьма важным при автономной отладке является тестирование сопряжения модулей.

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

Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага.

• Шаг 1. На основании спецификации отлаживаемого модуля подготовьте тесты для каждой возможности и каждой ситуации, для каждой границы областей допустимых значений всех входных данных, для каждой области изменения данных, для каждой области недопустимых значений всех входных данных и каждого недопустимого условия.

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

• Шаг 3. Проверьте текст модуля, чтобы убедиться, что для каждого цикла существуют тесты, обеспечивающие, по крайней мере, три следующие ситуации: тело цикла не выполняется ни разу, тело цикла выполняется один раз и тело цикла выполняется максимальное число раз. Добавьте недостающие тесты.

• Шаг 4. Проверьте текст модуля, чтобы убедиться, что существуют тесты, проверяющие чувствительность к отдельным особым значениям входных данных. Добавьте недостающие тесты.

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

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

Тестирование архитектуры ПС. Целью тестирования является поиск несоответствия между описанием архитектуры и совокупностью программ ПС. К моменту начала тестирования архитектуры ПС должна быть уже закончена автономная отладка каждой подсистемы.

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

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

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

Тестирование определения требований к ПС. Целью тестирования является выяснение, в какой мере ПС не соответствует предъявленному определению требований к нему. Особенность этого вида тестирования заключается в том, что его осуществляет организация-покупатель или организация-пользователь. Обычно производится с помощью контрольных задач - типовых задач, для которых известен результат решения.

37 Необходимость коллективной разработки ПО. Метод бригады главного программиста. Состав бригады. Обязанности главного программиста.

Если

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

2. Некоторые задачи очень объемные Прогнозируемые задачи можно закончить раньше если работать параллельно

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

Задача может потребовать коллективного решения.

Миллс «Бригада главного программирования»

Создается группа из 5 10 человек Бригада состоит и з главного програмера , помошника главного програмера , секретарь (библиотекарь) , программисты исполнители. Идея — работает как один программист высокой квалификации.

Главный програмер несет 100% ответственность за проектирование ПС. Распределяет работу, принимает решения. Отвечает за успех .Пишет важные процедуры и функции, определенные спецификацией для остальных модулей,ю объединяет результаты в единое целое. Руководство персоналом, соблюдение условий контракта, регулирование отношений с заказчиком .Решает когда и сколько программистов может понадобиться.