Программа сложной структуры с использованием меню
о незавершения программы ;
5) доказательство тотальной (полной ) корректности
(то есть одновременное решение первой и третьей задач);
6) доказательство некорректности (решение второй или
четвертой задачи).
Методы доказательства частичной корректности программ как правило
опираются на аксиоматический подход к формализации семантики языков
программирования. В настоящее время известны аксиоматические семантики
Паскаля, подмножества ПЛ/1 и некоторых других языков.
Аксиоматическая семантика языка программирования представляет собой
совокупность аксиом и правил вывода. С помощью аксиом задается семантика
простых операторов языка (присваивания, ввода - вывода, вызова процедур).
С помощью правил вывода описывается семантика составных операторов или
управляющих структур (последовательности, условного выбора, циклов). Среди
этих правил вывода надо отметить правило вывода для операторов цикла так
как оно требует знания инварианта цикла (формулы, истинности которой не
изменяется при любом прохождении цикла).
Построение инварианта для оператора цикла по его тексту является
алгоритмически не разрешимой задачи, поэтому для описания семантики циклов
требуется своего рода ”подсказка” от разработчика программы.
Наиболее известным из методов доказательства частичной корректности
программ является метод индуктивных утверждений предложенный Флойдом и
усовершенствованный Хоаром. Метод состоит из трех этапов.
Первый этап - получение аннотированной программы. На этом этапе для
синтаксически правильной программы должны быть заданы утверждения на языке
логики предикатов первого порядка :
6
входной предикат ;
выходной предикат ;
по одному утверждению для каждого цикла (эти
утверждения задаются для входной точки цикла и должны характеризовать
семантику вычислений в цикле).
Доказательство неистинности условий корректности свидетельствует о
неправильности программы, или ее спецификации, или программы и
спецификации.
Несмотря на достаточную сложность процесса верификации программы и
на то, что даже успешно завершенная верификация не дает гарантий качества
программы ( т.к. ошибка может содержаться и в верификации ), применение
методов аналитического доказательства правильности очень полезно для
уточнения смысла разрабатываемой программы, а знание этих методов
благотворно сказывается на квалификации программиста.
Наконец, динамический контроль программы - это проверка
правильности программы при ее выполнении на компьютере, т.е. тестирование.
ЦЕЛИ , ПРИНЦИПЫ И ЭТАПЫ ТЕСТИРОВАНИЯ .
Каждому программисту известно, сколько времени и сил уходит на
отладку и тестирование программ. На этот этап приходится около 50% общей
стоимости разработки программного обеспечения.
Но не каждый из разработчиков программных средств может верно
определить цель тестирования. Нередко можно услышать, что тестирование -
это процесс выполнения программы с целью обнаружения в ней ошибок. Но эта
цель недостижима : ни какое самое тщательное тестирование не дает
гарантии, что программа не содержит ошибок.
Другое определение тестирования ( у Г. Майерса ) тестирование -
это процесс выполнения программы с целью обнаружения в ней ошибок. Такое
определение цели стимулирует поиск ошибок в программах. Отсюда также ясно,
что “удачным” тестом является такой, на котором выполнение программы
завершилось с ошибкой. Напротив, “неудачным можно назвать тест, не
позволивший выявить ошибку в программе.
Определение Г. Майерса указывает на объективную трудность
тестирования : это деструктивный ( т.е. обратный созидательному ) процесс.
Поскольку программирование - процесс конструктивный, ясно, что большинству
разработчиков программных средств сложно “переключиться” при тестировании
созданной ими продукции.
7
У Майерса сформулированы также основные принципы организации
тестирования :
1) необходимой частью каждого теста должно являться
описание ожидаемых результатов работы программы, чтобы можно было быстро
выяснить наличие или отсутствие ошибки в ней ;
2) следует по возможности избегать тестирования
программы ее автором, т.к. кроме уже указанной объективной сложности
тестирования для программистов здесь присутствует и тот фактор, что
обнаружение недостатков в своей деятельности противоречит человеческой
психологии ( однако отладка программы эффективнее всего выполняется именно
автором программы ) ;
3) по тем же соображениям организация -
разработчик программного обеспечения не должна “единолично ” его
тестировать ( должны существовать организации, специализирующиеся на
тестировании программных средств ) ;
4) должны являться правилом доскональное изучение
результатов каждого теста, чтобы не пропустить малозаметную на
поверхностный взгляд ошибку в программе ;
5) необходимо тщательно подбирать тест не
только для правильных ( предусмотренных ) входных данных, но и для
неправильных (непредусмотренных) ;
6) при анализе результатов кождого теста
необходимо проверять, не делает ли программа того, что она не должна
делать ;
7) следует сохранять использованные тесты
(для повышения эффективности повторного тестирования программы после ее
модификации или установки у заказчика) ;
8) тестирования не должно планироваться
исходя из предположения, что в программе не будут обнаружены ошибки (в
частности, следует выделять для тестирования достаточные временные и
материальные ресурсы) ;
9) следует учитывать так называемый “принцип
скопления ошибок” : вероятность наличия не обнаруженных ошибок в некоторой
части программы прямо пропорциональна числу ошибок, уже обнаруженных в
этой части ;
10) следует всегда помнить , что
тестирование - творческий процесс, а не относиться к нему как к рутинному
занятию.
Существует два основных вида тестирования : функциональное и
структурное. При функциональном тестировании программа рассматривается как
“черный ящик” (то есть ее текст не используется). Происходит проверка
соответствия поведения программы ее внешней спецификации. Возможно ли при
этом полное тестирование программы ? Очевидно , что критерием полноты
тестирования в этом случае являлся бы перебор всех возможных значений
входных данных, что невыполнимо .
8
Поскольку исчерпывающее функциональное тестирование невозможно, речь может
идти о разработки методов, позволяющих подбирать тесты не “вслепую”, а с
большой вероятностью обнаружения ошибок в программе.
При структурном тестировании программа рассматривается как “белый
ящик” (т.е. ее текст открыт для пользования ). Происходит проверка логики
программы. Полным тестированием в этом случае будет такое, которое
приведет к перебору всех возможных путей на графе передач управления
программы (ее управляющем графе). Даже для средних по сложности программ
числом таких путей может достигать десятков тысяч. Если ограничиться
перебором только линейных не зависимых путей, то и в этом случае
исчерпывающее структурное тестирование практически невозможно, т. к.
неясно, как подбирать тесты , чтобы обеспечить “покрытие” всех таких
путей. Поэтому при структурном тестировании необходимо использовать другие
критерии его полноты, позволяющие достаточно просто контролировать их
выполнение, но не дающие гарантии полной проверки логики программы.
Но даже если предположить, что удалось достичь полного структурного
тестирования некоторой программы, в ней тем не менее могут содержаться
ошибки, т.к.
1) программа может не соответствовать своей внешней
спецификации, что в частности, может привести к тому, что в ее управляющем
графе окажутся пропущенными некоторые необходимые пути ;
2) не будут обнаружены ошибки, появление которых
зависит от обрабатываемых данных (т.е. на одних исходных данных программа
работает правильно, а на других - с ошибкой).
Таким образом, ни структурное, ни функциональное тестирование не
может быть исчерпывающим. Рассмотрим подробнее основные этапы тестирования
программных комплексов.
В тестирование многомодульных программных комплексов можно выделить
четыре этапа :
1) тестирование отдельных модулей ;
2) совместное тестирование модулей ;
3) тестирование функций программного комплекса (т.е.
поиск различий между разработанной программой и ее внешней спецификацией )
;
4) тестирование всего комплекса в целом (т.е. поиск
несоответствия созданного программного продукта сформулированным ранее
целям проектирования, отраженным обычно в техническом задании).
На первых двух этапах используются прежде всего методы структурного
тестирования, т.к.
на последующих этапах тестирования
| |  скачать работу |
Программа сложной структуры с использованием меню |
