Методы функциональных диаграмм

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

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

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

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

 Недостатки данного подхода.

1) По определению исчерпывающего тестирования невозможно провести.

2) Нет гарантии того, что программа соответствует своим спецификациям , т.е программа жестко следует спецификации.

3) В программе могут быть пропущены некоторые операторы и условия.

4) Исчерпывающее тестирование не может выявить ряд ошибок условного характера, т.е по абсолютной величине а-в<ε

|A| - |B| ≤ ε : A>0: B>0: |A-B|≤ ε

Особенности тестирования черного и белого ящика

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

 Стратегия белого ящика

Метод один поиск всех маршрутов , а критериев несколько.

Следующие критерии:

1) Критерии покрытия операторов

2) Критерии покрытия решений

3) Критерии покрытия условий

4) Критерии решений –условий

5) Критерии комбинаторного покрытия, т.е критерии белого ящика определяет покрытия логики программы.

 1)Критерии операторов- когда по операторам пройтись хоть раз

2) Критерии покрытия решений – более сильный метод, который также удовлетворяет критерию покрытия операторов ,согласно этому критерию, каждое направление перехода ,должно быть реализовано хотя бы 1 раз., т.е надо пройтись по переходам работы программы.

3) Критерии условий. Являются более сильными критериями, при котором выполняется требование « пройтись хотя бы однократно по результатам каждого условия». Иначе говоря, поскольку при данном критерии не всегда удается пройтись по всем операторам, то и указанное требование дополняется требованием, что в каждой точке программы хотя бы один раз было передано управление покрытия условий.

4)Это такой критерий, как и (3), только в тестах должны еще участвовать анализ решений.

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

Известны 3 метода предупреждения и выявления ошибок.

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

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

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

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

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

Для решения поставленной проблемы выбора, для решения процессов- разработано 2 подхода

1) Монолитное тестирование

2) Пошаговое тестирование(может быть как восходящим, так и нисходящим).

 Монолитное тестирование предусматривает проверку всей программы целиком(комплекс программ)

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

Анализ двух указанных подходов(преимущества и недостатки)

1) Монолитное тестирование более трудоемкий процесс сравнительно с пошаговым.

2)При пошаговом тестировании ошибки в межмодульных интерфейсах обнаруживаются раньше, т.е сборка программы идет практически с 0.

3) При пошаговом тестировании менее трудоемка отладка и поиск ошибок, т.е локализация ошибок и внешних изменений не влечет за собой переделку всего модуля.

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

5) Затраты машинного времени в большинстве случаев при монолитном тестировании как правило меньше , чем при пошаговом, т.к при монолитном тестировании выполняется отдельный модуль, который просто передает управление, тогда как в конце тестирование производится в полном объеме.

6) Монолитное тестирование создает хорошие предпосылки для распространения процессов тестирования.

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

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

2) Тестирование на предельных объектах

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

3) Тестирование на предельных нагрузках- проверка функциональности программного обеспечения в стрессовых ситуациях, т.е максимального объема информации в сжатые отрезки времени, например, в сетевом режиме вводится с нескольких мест информация в базу данных.

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

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

6) Тестирование производительности или эффективности программного обеспечения.

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

7) Тестирование требований к памяти, т.е необходимость проверить предельные объемы оперативной и внешней памяти ,в любой момент времени работы программного изделия.

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

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

9) Тестирование удобств установки программного обеспечения- оно проверяет установку достаточно сложного программного продукта, на конкретные условия эксплуатации.

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

11) Тестирование восстановления

Существует ряд программных систем:

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

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

13) Тестирование документации

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

14) Тестирование процедур: если программное обеспечение является некоторой частью подсистемы обработки данных большой системы, в которой имеются процедуры выполняемые человеком, то эти процедуры должны быть протестированы

Анализ: трудоемкость тестирования составляет от 20 до 60% от всего объема работ, причем львиная доля его составляет -выбор необходимой исходной информации для получения эталонных значений. Эта задача резко экспоненциально растет, когда речь идет о комплексном тестировании огромного объема маршрутов, когда необходимо протестировать предельные нагрузки на программное обеспечение. Нередкий случай ,когда ручная разработка тестов практически невозможна и специально создается и ……..позволяющая генерирование тестов.

 Методы отладки:

 Основная задача программиста состоит в том, чтобы его программа работала без ошибок, для этого существует 2 подхода

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

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

Лекция 16

Известны три источника ошибок в написании программы (с точки зрения анализа их распределения) – это алгоритмические ошибки или неверный выбор алгоритма решения задачи. Эти ошибки могут иметь наиболее серьезный характер впоследствии до полной переработки программы. К ним относятся: не учет или неполный учет данных, неправильное понимание структуры рассмотрения алгоритма, как неполного подмножества данных, данные, выходящие за пределы задач, не знание или неполное знание средств вычислительной техники, незнание команд ЭВМ, языковых средств, возможностей среды разработки.

Описки – уровень обидной ошибки, который определен в результате просмотра.

Основная задача программиста состоит в том, чтобы его программа работала без ошибок.